Sui (SUI): Come funzionano i costi di gas e di archiviazione

Oggetti invece di un account generico

Ogni oggetto Sui ha un ID univoco, versione, proprietario e metadati che descrivono il suo ultimo utilizzo. Gli oggetti Move contengono dati applicativi tipizzati, mentre gli oggetti pacchetto contengono bytecode Move pubblicato. Un pacchetto non è la stessa cosa di un portafoglio o saldo token, e un nome di pacchetto familiare non è prova che il suo ID sia canonico.

Gli oggetti di proprietà di un indirizzo possono essere autorizzati dall'indirizzo controllante. Gli oggetti possono anche essere di proprietà di altri oggetti, condivisi per accesso coordinato, immutabili o avvolti all'interno di un altro oggetto. Queste forme influenzano trasferibilità ed esecuzione. Un riepilogo del portafoglio che elenca solo importi di monete può nascondere i cambi di oggetti che una chiamata applicativa farà.

Le versioni prevengono usi conflittuali

Una versione di un oggetto cambia quando l'oggetto viene mutato. Le transazioni fanno riferimento a input specifici, consentendo al sistema di rilevare tentativi di utilizzare versioni obsolete o già consumate. Gli utenti che riprovano un'azione applicativa fallita dovrebbero ricostruire dallo stato corrente dell'oggetto piuttosto che firmare ripetutamente un vecchio payload di transazione.

Comandi, input ed effetti

Una transazione Sui identifica oggetti di input, valori puri, un oggetto gas e comandi come trasferimenti, divisioni di monete, fusioni di monete o chiamate Move. I comandi possono alimentare risultati in comandi successivi. La transazione completa riesce atomicamente o i suoi cambi di stato previsti non vengono committati, sebbene il gas possa essere comunque addebitato per l'elaborazione.

I pacchetti Move definiscono i tipi e le funzioni che possono operare sugli oggetti. Le regole di abilità e le firme delle funzioni vincolano se un oggetto può essere copiato, eliminato, memorizzato o utilizzato come chiave. I portafogli dovrebbero visualizzare ogni chiamata di pacchetto e trasferimento di oggetto; gli utenti dovrebbero essere cauti quando un'interfaccia riduce una transazione multi-comando a un'unica etichetta di pulsante vaga.

Percorsi di esecuzione posseduti e condivisi

Le transazioni che usano solo oggetti indipendentemente posseduti possono evitare l'ordinamento globale quando le loro dipendenze sono chiare. Gli oggetti condivisi richiedono ordinamento tramite consenso affinché gli utenti concorrenti concordino sulla sequenza dei cambi. Questa differenza supporta l'esecuzione parallela ma non garantisce che ogni transazione abbia la stessa latenza.

Su cosa concordano i validatori

I validatori elaborano le transazioni e partecipano al protocollo di consenso Mysticeti. La delega di stake contribuisce al potere di voto dei validatori e alle ricompense secondo le regole di rete correnti. Il consenso ordina l'attività che necessita di una sequenza comune, in particolare le transazioni con oggetti condivisi, mentre la proprietà degli oggetti consente alle transazioni più semplici di utilizzare percorsi ottimizzati.

L'esecuzione finale non certifica che un pacchetto sia affidabile o che un oggetto abbia valore economico. Conferma che la rete ha accettato la transazione secondo le regole del protocollo. Le applicazioni dovrebbero attendere gli effetti di transazione richiesti dal loro flusso di lavoro e verificarli da un nodo completo corrente o servizio RPC.

Limiti dello staking

Delegare SUI espone gli utenti alle prestazioni del validatore, ai tempi delle ricompense e alle regole del protocollo. Non concede il controllo dei pacchetti applicativi né protegge da una richiesta di firma dannosa. Le decisioni su validatori e staking dovrebbero basarsi su dati di rete attuali piuttosto che su tassi storici.

Checklist di transazione

Verifica mainnet, mittente, oggetto gas, budget gas, ID pacchetto, oggetti di input, chiamate a oggetti condivisi, suddivisioni di monete, trasferimenti e proprietà risultante. Conferma il tipo di token e l'indirizzo del pacchetto invece di fidarti di un ticker. Ricostruisci transazioni obsolete dalle versioni correnti degli oggetti.

• Mantieni SUI disponibile per il gas.
• Ispeziona ogni comando programmabile.
• Verifica ID del pacchetto e del tipo di token.
• Tratta la simulazione come una stima, non come una verifica.

Cosa dovrebbero verificare gli utenti Sui e perché questo design è diverso

Confronta Aptos per vedere un'altra implementazione di Move con un modello di stato diverso. Gli sviluppatori dovrebbero consultare la documentazione corrente sui pacchetti e sulle transazioni Sui. Sfoglia la directory degli strumenti per validatori e convertitori generali piuttosto che trattare una pagina di mercato come un ispettore di oggetti.