Hoe werken transacties op Solana?

Omdat er bij elke transactie een vergoeding wordt betaald, is het nuttig te begrijpen hoe transacties werken. Een transactie bestaat uit drie onderdelen:

één of meer instructies
een array van accounts om van te lezen of naar te schrijven
één of meer handtekeningen
recente blockhash of nonce

Een instructie is de kleinste uitvoeringslogica op Solana. Instructies zijn een aanroep om de globale Solana-status bij te werken. Instructies roepen programma's aan die aanroepen doen naar de Solana-runtime om de status bij te werken (bijvoorbeeld het aanroepen van de token program om tokens van uw account naar een ander account over te maken). U kunt een instructie beschouwen als een functieaanroep op een Ethereum smart contract.

Een belangrijk verschil tussen Ethereum en Solana is het aantal functieaanroepen in één transactie, vanwege het aantal instructies. Meerdere instructies per transactie zijn voordelig voor ontwikkelaars, omdat zij geen aangepaste smart contracts hoeven te maken om functies in één transactie aan elkaar te koppelen. Elke instructie kan een afzonderlijke functieaanroep zijn, in volgorde uitgevoerd binnen de transactie. Transacties zijn atomair, wat betekent dat als een van deze instructies mislukt, de hele transactie mislukt en u alleen de transactievergoeding betaalt. Dit is vergelijkbaar met het mislukken van een transactie doordat de juiste slippage op Ethereum niet is ingesteld.

Een ander belangrijk verschil om te onthouden is het gebruik van een recente blockhash in plaats van een incrementele nonce voor transacties. Wanneer een wallet een transactie wil uitvoeren, wordt een recente blockhash opgehaald uit het cluster om een geldige transactie te maken. Deze recente blockhash maakt de transactie slechts geldig voor 150 blokken nadat de recente blockhash is opgehaald. Dit voorkomt dat langlopende transactiehandtekeningen op een veel later tijdstip worden uitgevoerd.

Cross-Program Invocation (CPI)

Een Cross-Program Invocation (CPI) is wanneer één Solana-programma een instructie aanroept op een ander programma terwijl de oorspronkelijke transactie wordt uitgevoerd. CPI is de belangrijkste manier waarop Solana-programma's met elkaar samenwerken, maar het accountmodel verandert hoe u de aanroepgrafiek ontwerpt: de transactie moet elk account bevatten dat de volledige CPI-keten zal lezen of schrijven voordat de uitvoering begint.

De aangeroepene erft alleen de ondertekenaar- en schrijfrechten die de aanroeper ontving, en de aangeroepene maakt gebruik van hetzelfde transactie-rekenbudget. Gebruik invoke wanneer alle vereiste ondertekenaars de oorspronkelijke transactie hebben ondertekend. Gebruik invoke_signed wanneer het aanroepende programma namens een van zijn PDAs moet ondertekenen met signer seeds.

Bevestigingsniveaus

RPC-leesbewerkingen, abonnementen en transactiebevestigingslogica kunnen een commitment-niveau kiezen. Dit is de Solana-versie van het beslissen hoeveel Ethereum-blokbevestigingen u wilt afwachten, met dat verschil dat de niveaus hier expliciet zijn:

processed: de meest recente verwerkte weergave van het knooppunt. Gebruik dit alleen voor optimistische UI of stromen die terugdraaien kunnen verdragen.
confirmed: een blok waarop een supermeerderheid van de stake heeft gestemd. Gebruik dit als standaard voor de meeste productiebevestigingen en transactiestatussen die aan gebruikers worden getoond.
finalized: de sterkste bevestigingsstatus. Gebruik dit vóór onomkeerbare off-chain acties zoals fiatuitbetalingen, het verzenden van goederen of definitieve vereffeningsregistraties.

Als een RPC-methode commitment accepteert en u dit weglaat, is de standaard doorgaans finalized. Productieclients moeten commitment toch expliciet instellen, zodat UI-latentie, indexergedrag en vereffeningsbeleid bewust worden bepaald.

Offline Transactions