Ogni account è un contratto
Su Ethereum esistono due tipi di account: account posseduti esternamente controllati da una chiave privata, e account di contratto controllati da codice. Starknet ha solo il secondo tipo.
Il suo portafoglio Starknet è uno smart contract. Definisce la propria validazione di firma, il che significa che può usare schemi di firma che Ethereum non può, supportare più firmatari, implementare chiavi di sessione, o permettere a qualcun altro di pagare le sue commissioni.
Questa è astrazione nativa dell'account, ed è un genuino miglioramento rispetto al modello EVM, dove le stesse capacità richiedono standard aggiunti in un secondo momento. Significa anche che ogni transazione è una chiamata di contratto, senza alcun caso speciale di trasferimento semplice.
Starkscan presenta questo correttamente: le pagine di account mostrano il contratto account e la sua classe, non un finto account posseduto esternamente. Una volta che conosce il modello, l'explorer ha senso; prima di allora, è confuso in un modo che è opera del modello piuttosto che dell'explorer.
Classi e istanze
Starknet separa il codice di contratto dalla distribuzione di contratto. Il codice viene dichiarato come una classe, identificata da un class hash. Le istanze vengono poi distribuite da quella classe, ognuna con il proprio indirizzo e storage.
Molti portafogli condividono una classe di account. Molti token possono condividere una classe di token. Il codice esiste una volta sulla chain; le istanze sono economiche.
Questo è più efficiente dell'approccio EVM di distribuire ripetutamente bytecode identico, e cambia cosa significa la verifica. Verificare una classe verifica ogni istanza di essa — il che è una proprietà considerevolmente più forte della verifica per indirizzo di EVM.
Starkscan mostra entrambe le dimensioni: la classe con il suo codice dichiarato, e le istanze distribuite da essa. Quando valuta un contratto non familiare, controllare se la sua classe è una ampiamente usata e verificata è un controllo rapido e genuinamente informativo senza equivalente EVM.
Cairo e calldata
Cairo è il linguaggio di Starknet, progettato in modo che l'esecuzione possa essere provata con prove STARK. Non è Solidity e non compila in bytecode EVM; la semantica differisce genuinamente.
La conseguenza pratica per leggere le transazioni è il calldata. Il calldata di Starknet è un array di elementi di campo — numeri grezzi — e senza conoscere la firma della funzione di destinazione non ha significato. Starkscan lo decodifica contro l'ABI del contratto, trasformando una lista di interi in argomenti tipizzati nominati.
Dove non può decodificare, mostra l'array grezzo. Quello è il comportamento giusto, e vale la pena controllare la forma grezza quando qualcosa sembra strano, poiché un decodificatore che lavora da un ABI errato produce output sbagliato con sicurezza.
Voyager è la seconda opinione qui, e su un ecosistema così giovane avere due decodificatori indipendenti è più prezioso di quanto lo sarebbe su Ethereum.
Prove di validità, non finestre di contestazione
Starknet è un rollup di validità. Piuttosto che assumere che le transazioni siano corrette e permettere un periodo di contestazione, genera una prova crittografica che un lotto è stato eseguito correttamente e verifica quella prova su Ethereum.
La differenza da Arbitrum e Base è significativa. Non c'è finestra di contestazione di sette giorni, perché non c'è nulla da contestare — la prova o si verifica o non si verifica. I prelievi sono limitati dal tempo di generazione e verifica della prova piuttosto che da un periodo di disputa fisso.
La generazione della prova è computazionalmente pesante, quindi i lotti non sono istantanei, e Starkscan mostra in quale lotto si trova una transazione e se la sua prova è stata verificata su Ethereum. Quello è il campo che le dice se una transazione è regolata nel senso più forte.
La stessa distinzione si applica a Linea e Scroll. Quando confronta rollup, "quanto tempo per prelevare" viene risposto dal sistema di prova, non dal marketing.
Cosa hanno mostrato i nostri test di riferimento
Starknet ha richiesto un insieme di riferimento modificato, perché metà dei nostri soliti elementi EVM non esistono qui — non ci sono account posseduti esternamente e nessun trasferimento semplice che non sia una chiamata di contratto.
Ciò che abbiamo testato invece: una distribuzione di account, un trasferimento di token attraverso un contratto account, una chiamata a una classe ampiamente usata e verificata, una chiamata a un contratto non verificato, e un multicall che raggruppa diverse operazioni.
La distribuzione di account si è resa correttamente, con il class hash identificato e collegato ad altre istanze della stessa classe — che è la vista senza equivalente EVM ed è genuinamente informativa. Vedere che un account non familiare usa la stessa classe di portafoglio ampiamente distribuita di migliaia di altri è un segnale significativo in un modo che un badge di verifica per indirizzo non è.
La decodifica del calldata ha funzionato su ogni classe verificata che abbiamo provato, producendo argomenti tipizzati nominati piuttosto che array di elementi di campo. Sul contratto non verificato è ricaduta sull'array grezzo, chiaramente etichettato come non decodificato piuttosto che presentato come una migliore ipotesi. Quello è il comportamento corretto e l'abbiamo controllato specificamente, perché un decodificatore che indovina silenziosamente è peggio di uno che ammette di non poterlo fare.
Il multicall è stato reso come le sue chiamate componenti, che è ciò che rende possibile l'astrazione dell'account e ciò che rende leggibili affatto le transazioni Starknet.
Abbiamo controllato in modo incrociato tre dei cinque contro Voyager. Tutti e tre corrispondevano. Su un ecosistema così giovane, far girare il confronto occasionalmente vale i trenta secondi, perché una divergenza di decodifica tra due implementazioni indipendenti è il modo più veloce per scoprire che una delle due ha un ABI sbagliato.