Ricevute, e perché una transazione ne diventa molte
Una transazione NEAR è una richiesta. Ciò che effettivamente esegue è una ricevuta, e una transazione può generarne molte.
La ragione è lo sharding. NEAR divide lo stato attraverso gli shard, e un contratto su uno shard che ne chiama uno su un altro non può farlo sincronamente. La chiamata diventa una ricevuta, instradata allo shard di destinazione, eseguita lì, e il suo risultato restituito come un'ulteriore ricevuta.
Quindi una singola azione utente — scambiare token, diciamo — produce un albero: la transazione iniziale, una ricevuta per il primo contratto, ricevute per ogni chiamata cross-contract che fa, e ricevute che riportano i risultati indietro. Ognuna è eseguita separatamente, potenzialmente in blocchi diversi.
Questo è lo stesso pattern asincrono di TON, con vocabolario diverso. E produce la stessa modalità di fallimento: una transazione può avere successo mentre una ricevuta in profondità nell'albero fallisce, e un explorer che mostra solo la transazione riporta successo.
NearBlocks rende l'albero con lo stato di ogni ricevuta. Quello è il prodotto, e senza di esso le interazioni di contratto NEAR sono essenzialmente illeggibili.
Account nominati e chiavi di accesso
Gli account NEAR hanno nomi leggibili dall'uomo — alice.near piuttosto che una stringa esadecimale — implementati a livello di protocollo piuttosto che come un servizio di naming aggiunto sopra. I sub-account seguono lo stesso pattern, quindi app.alice.near è controllato da alice.near.
La funzionalità più interessante sono le chiavi di accesso. Un account NEAR può avere più chiavi con permessi diversi. Una chiave di accesso completo può fare qualsiasi cosa. Una chiave function-call può solo chiamare metodi specificati su un contratto specificato, con un'indennità di spesa.
Questo è un modello di sicurezza genuinamente buono che altre chain non hanno. Un'applicazione può detenere una chiave che le permette di chiamare il proprio contratto per suo conto, con un'indennità limitata, e nient'altro. Non può prosciugare il suo account perché non le è mai stato concesso quel potere — il che è strutturalmente migliore del pattern di approvazione di token illimitata che domina le chain EVM.
NearBlocks elenca le chiavi di accesso su un account con i loro permessi e indennità. Rivedere quella lista periodicamente è l'equivalente NEAR di controllare le approvazioni di token, ed è considerevolmente più facile da ragionare.
Storage staking, che sorprende tutti
NEAR addebita per lo storage di stato richiedendo agli account di bloccare NEAR proporzionale ai dati che occupano. Memorizzi di più, blocchi di più. Elimini dati e l'importo bloccato viene rilasciato.
La conseguenza pratica è che parte del suo saldo non è spendibile. Tenti di inviare tutto e la transazione fallisce perché la porterebbe sotto il suo requisito di storage, il che è confuso se non sa che il meccanismo esiste.
Significa anche che ricevere un token può costarle. Registrarsi con un contratto di token alloca storage, e qualcuno deve pagare il deposito — motivo per cui alcuni trasferimenti di token NEAR richiedono che il destinatario sia registrato prima, e perché un trasferimento verso un account non registrato può fallire.
NearBlocks mostra l'uso di storage e l'importo bloccato sulle pagine di account. È la prima cosa da controllare quando un trasferimento fallisce senza ragione apparente.
API e open source
NearBlocks è open source con un livello API gratuito che richiede una chiave. Poter leggere come vengono assemblati gli alberi di ricevute conta qui, perché quell'assemblaggio coinvolge decisioni reali — quale ricevuta è quella "principale", come attribuire il gas attraverso un albero, come presentare un fallimento parziale.
Il JSON-RPC proprio di NEAR è l'alternativa per i dati grezzi. Le dà transazioni e ricevute senza la ricostruzione dell'albero, che è la parte che richiede lavoro.
Per qualsiasi cosa rivolta all'utente su NEAR, la ricostruzione non è opzionale. Mostrare a un utente la transazione iniziale e chiamarla fatta produrrà ticket di supporto da persone la cui azione è riuscita in cima ed è fallita tre ricevute più in basso.
Cosa hanno mostrato i nostri test di riferimento
Il nostro insieme di riferimento NEAR è stato costruito attorno al problema delle ricevute: un trasferimento semplice, un trasferimento di token verso un account registrato, un trasferimento di token verso un account non registrato, uno scambio cross-contract, e un account con più chiavi di accesso.
Il trasferimento semplice era ordinario. Il trasferimento di token verso un account registrato si è reso come un breve albero di ricevute e si è letto in modo pulito.
Il trasferimento verso un account non registrato era il test che contava, e si è comportato come predice il modello di storage staking: la transazione ha avuto successo, una ricevuta più in profondità nell'albero è fallita perché il destinatario non aveva un deposito di storage registrato con il contratto di token, e i token non si sono mossi. Un utente che guardasse solo la transazione avrebbe concluso che il trasferimento avesse funzionato.
NearBlocks ha mostrato la ricevuta fallita con il suo errore, diversi livelli più in basso, marcata chiaramente. Quella è la singola cosa più preziosa che fa questo explorer, ed è la ragione per cui un explorer NEAR che non rende gli alberi di ricevute non è utilizzabile per nulla oltre confermare un trasferimento semplice.
Lo scambio cross-contract ha prodotto un albero considerevolmente più grande — una dozzina di ricevute attraverso diversi contratti — ed è rimasto leggibile, il che è un vero risultato di interfaccia data la complessità sottostante.
Il test della chiave di accesso ha elencato sia una chiave di accesso completo che una chiave function-call con la sua indennità e i metodi permessi. Confrontare questo con l'esercizio equivalente su una chain EVM, dove rivedere le approvazioni di token significa leggere una lista di permessi illimitati concessi a contratti che potrebbe non riconoscere, ha reso il vantaggio di sicurezza del modello di NEAR concreto piuttosto che teorico.