Receipts, und warum eine Transaktion zu vielen wird
Eine NEAR-Transaktion ist eine Anfrage. Was tatsächlich ausgeführt wird, ist ein Receipt, und eine Transaktion kann viele erzeugen.
Der Grund ist Sharding. NEAR teilt den Zustand über Shards auf, und ein Vertrag auf einem Shard, der einen Vertrag auf einem anderen aufruft, kann das nicht synchron tun. Der Aufruf wird zu einem Receipt, an den Ziel-Shard geleitet, dort ausgeführt, und sein Ergebnis als weiteres Receipt zurückgegeben.
Eine einzelne Nutzeraktion — etwa ein Token-Tausch — erzeugt also einen Baum: die ursprüngliche Transaktion, ein Receipt für den ersten Vertrag, Receipts für jeden Cross-Contract-Aufruf, den er tätigt, und Receipts, die Ergebnisse zurücktragen. Jedes wird separat ausgeführt, möglicherweise in unterschiedlichen Blöcken.
Das ist dasselbe asynchrone Muster wie bei TON, mit anderem Vokabular. Und es erzeugt denselben Fehlermodus: Eine Transaktion kann erfolgreich sein, während ein Receipt tief im Baum fehlschlägt, und ein Explorer, der nur die Transaktion zeigt, meldet Erfolg.
NearBlocks stellt den Baum mit dem Status jedes Receipts dar. Das ist das Produkt, und ohne es sind NEAR-Vertragsinteraktionen im Grunde unlesbar.
Benannte Konten und Access Keys
NEAR-Konten haben menschenlesbare Namen — alice.near statt einer Hex-Zeichenkette —, auf Protokollebene umgesetzt statt als aufgesetzter Namensdienst. Unterkonten folgen demselben Muster, app.alice.near wird also von alice.near kontrolliert.
Die interessantere Funktion sind Access Keys. Ein NEAR-Konto kann mehrere Schlüssel mit unterschiedlichen Berechtigungen haben. Ein Full-Access-Key kann alles. Ein Function-Call-Key kann nur bestimmte Methoden eines bestimmten Vertrags aufrufen, mit einer Ausgabengrenze.
Das ist ein wirklich gutes Sicherheitsmodell, das anderen Chains fehlt. Eine Anwendung kann einen Schlüssel halten, der ihr erlaubt, in Ihrem Namen ihren eigenen Vertrag aufzurufen, mit gedeckelter Grenze, und sonst nichts. Sie kann Ihr Konto nicht leeren, weil ihr diese Macht nie erteilt wurde — strukturell besser als das unbegrenzte Token-Freigabe-Muster, das EVM-Chains dominiert.
NearBlocks listet die Access Keys eines Kontos mit ihren Berechtigungen und Grenzen. Diese Liste regelmäßig zu prüfen ist das NEAR-Äquivalent zum Prüfen von Token-Freigaben, und deutlich leichter nachzuvollziehen.
Storage Staking, das jeden überrascht
NEAR berechnet Speicherung von Zustand, indem es Konten zwingt, NEAR proportional zu ihrer belegten Datenmenge zu sperren. Mehr Speichern, mehr Sperren. Löschen Sie Daten, wird der gesperrte Betrag freigegeben.
Die praktische Folge: Ein Teil Ihres Guthabens ist nicht ausgabefähig. Versuchen Sie, alles zu senden, schlägt die Transaktion fehl, weil sie Sie unter Ihre Speicheranforderung drücken würde — verwirrend, wenn man den Mechanismus nicht kennt.
Es bedeutet auch, dass der Empfang eines Tokens Sie etwas kosten kann. Die Registrierung bei einem Token-Vertrag belegt Speicher, und jemand muss die Kaution zahlen — weshalb manche NEAR-Token-Transfers verlangen, dass der Empfänger zuerst registriert ist, und warum ein Transfer an ein nicht registriertes Konto fehlschlagen kann.
NearBlocks zeigt Speichernutzung und den gesperrten Betrag auf Kontoseiten. Das ist das Erste, was man prüft, wenn ein Transfer ohne erkennbaren Grund fehlschlägt.
API und Open Source
NearBlocks ist Open Source mit kostenlosem, schlüsselpflichtigem API-Tarif. Lesen zu können, wie Receipt-Bäume zusammengesetzt werden, zählt hier, denn diese Zusammensetzung verlangt echte Entscheidungen — welches Receipt das „Haupt“-Receipt ist, wie Gas über einen Baum zugeordnet wird, wie ein teilweiser Fehlschlag präsentiert wird.
NEARs eigene JSON-RPC ist die Alternative für Rohdaten. Sie liefert Transaktionen und Receipts ohne die Baum-Rekonstruktion — genau der aufwendige Teil.
Für alles Nutzer-orientierte auf NEAR ist die Rekonstruktion nicht optional. Einem Nutzer nur die ursprüngliche Transaktion zu zeigen und das als erledigt zu betrachten erzeugt Support-Tickets von Menschen, deren Aktion oben erfolgreich war und drei Receipts tiefer fehlschlug.
Was unsere Referenztests zeigten
Unser NEAR-Referenzsatz war um das Receipt-Problem herum gebaut: eine einfache Überweisung, ein Token-Transfer an ein registriertes Konto, ein Token-Transfer an ein nicht registriertes Konto, ein Cross-Contract-Tausch, und ein Konto mit mehreren Access Keys.
Die einfache Überweisung war unauffällig. Der Token-Transfer an ein registriertes Konto rendere als kurzer Receipt-Baum und las sich klar.
Der Transfer an ein nicht registriertes Konto war der entscheidende Test und verhielt sich wie vom Storage-Staking-Modell vorhergesagt: Die Transaktion war erfolgreich, ein Receipt tiefer im Baum schlug fehl, weil der Empfänger keine Speicherkaution beim Token-Vertrag registriert hatte, und die Token bewegten sich nicht. Ein Nutzer, der nur die Transaktion betrachtet, hätte geschlossen, der Transfer habe funktioniert.
NearBlocks zeigte das fehlschlagende Receipt mit seinem Fehler, mehrere Ebenen tiefer, klar markiert. Das ist mit Abstand das Wertvollste, was dieser Explorer leistet, und der Grund, warum ein NEAR-Explorer, der Receipt-Bäume nicht darstellt, für nichts über eine einfache Überweisung hinaus nutzbar ist.
Der Cross-Contract-Tausch erzeugte einen deutlich größeren Baum — ein Dutzend Receipts über mehrere Verträge — und blieb lesbar, angesichts der zugrunde liegenden Komplexität eine echte Leistung der Oberfläche.
Der Access-Key-Test listete sowohl einen Full-Access-Key als auch einen Function-Call-Key mit seiner Grenze und den erlaubten Methoden. Verglichen mit der entsprechenden Übung auf einer EVM-Chain, wo das Prüfen von Token-Freigaben bedeutet, eine Liste unbegrenzter Berechtigungen an möglicherweise unbekannte Verträge zu lesen, machte das den Sicherheitsvorteil von NEARs Modell konkret statt theoretisch.