Come funzionano le transazioni su Solana?

Poiché ogni commissione viene pagata al momento dell'esecuzione di una transazione, è utile capire come funzionano le transazioni. Una transazione è composta da tre parti:

una o più istruzioni
un array di account da cui leggere o su cui scrivere
una o più firme
un blockhash recente o un nonce

Un' istruzione è la più piccola unità di logica esecutiva su Solana. Le istruzioni sono chiamate per aggiornare lo stato globale di Solana. Le istruzioni invocano programmi che effettuano chiamate al runtime di Solana per aggiornare lo stato (ad esempio, chiamando il token program per trasferire token dal proprio account a un altro account). Puoi pensare a un'istruzione come a una chiamata di funzione su uno smart contract Ethereum.

Una differenza significativa tra Ethereum e Solana riguarda il numero di chiamate di funzione in una singola transazione, determinato dal numero di istruzioni. Avere più istruzioni per transazione è vantaggioso per gli sviluppatori, poiché non devono creare smart contract personalizzati per concatenare funzioni in una singola transazione. Ogni istruzione può essere una chiamata di funzione separata, eseguita in ordine nella transazione. Le transazioni sono atomiche: se una qualsiasi di queste istruzioni fallisce, l'intera transazione fallirà e verrà addebitata solo la commissione di transazione. È come quando una transazione fallisce su Ethereum per aver impostato uno slippage errato.

Un'altra differenza chiave da tenere a mente è l'utilizzo di un blockhash recente al posto di un nonce incrementale per le transazioni. Quando un wallet vuole effettuare una transazione, viene recuperato un blockhash recente dal cluster per creare una transazione valida. Questo blockhash recente rende la transazione valida solo per 150 blocchi successivi al momento del suo recupero. Ciò impedisce che firme di transazione di lunga durata vengano eseguite molto tempo dopo.

Cross-Program Invocation (CPI)

Una Cross-Program Invocation (CPI) si verifica quando un programma Solana chiama un'istruzione su un altro programma mentre la transazione originale è in esecuzione. La CPI è il principale meccanismo di composizione tra programmi Solana, ma il modello degli account influenza la progettazione del call graph: la transazione deve includere ogni account che l'intera catena CPI leggerà o scriverà prima che l'esecuzione abbia inizio.

Il callee eredita solo i privilegi di firma e scrittura che il caller ha ricevuto, e il callee utilizza lo stesso budget di calcolo della transazione. Usa invoke quando tutti i firmatari richiesti hanno firmato la transazione originale. Usa invoke_signed quando il programma chiamante deve firmare per uno dei suoi Program Derived Address con i relativi signer seeds.

Livelli di commitment

Le letture RPC, le sottoscrizioni e la logica di conferma delle transazioni possono scegliere un livello di commitment. Questa è la versione Solana della scelta di quante conferme di blocco Ethereum attendere, con la differenza che i livelli sono espliciti:

processed: la visione più recente elaborata dal nodo. Usalo solo per UI ottimistiche o flussi che possono tollerare un rollback.
confirmed: un blocco votato da una supermajority dello stake. Usalo come predefinito per la maggior parte delle conferme in produzione e per lo stato delle transazioni visibile agli utenti.
finalized: lo stato di conferma più solido. Usalo prima di azioni off-chain irreversibili come pagamenti in valuta fiat, spedizione di merci o registrazioni di liquidazione finale.

Se un metodo RPC accetta il commitment e non viene specificato, il valore predefinito è generalmente finalized. I client in produzione dovrebbero comunque impostare il commitment in modo esplicito, affinché la latenza dell'interfaccia utente, il comportamento degli indexer e la policy di liquidazione siano deliberati.