Solana (SOL): hoe transacties en validators werken

Staat leeft in accounts

Elke persistente Solana-staat wordt bewaard in een account geïdentificeerd door een 32-byte-adres. Een account registreert lamports, data, een eigenaarprogramma en uitvoeringsgerelateerde velden. De eigenaar is het programma dat die accountdata mag wijzigen; het is niet noodzakelijkerwijs de mens die een wallet-sleutel beheert.

Solana-programma's zijn uitvoerbare accounts met sBPF-bytecode. Een programma wordt over het algemeen als stateless behandeld omdat veranderlijke applicatiestaat in afzonderlijke accounts leeft die aan elke instructie worden geleverd. Dit stelt de runtime in staat om te zien welke accounts een transactie zal lezen of schrijven vóór uitvoering en werk te plannen dat niet concurreert voor dezelfde beschrijfbare staat.

Wallets, token accounts en PDAs

Een wallet-adres kan SOL bezitten en transacties autoriseren, maar een SPL-tokensaldo bevindt zich normaal gesproken in een token-account dat is gekoppeld aan een mint en eigenaar. Een Program Derived Address wordt deterministisch afgeleid van een programma ID en seeds; het programma kan ervoor autoriseren via runtime-regels, ook al bestaat er geen privésleutel voor het adres.

Controleer vóór het verzenden van een token de mint, het bestemmings-token-account en het aangeroepen programma. Een bekende ticker of wallet-label is geen bewijs dat een mint canoniek is. Het sluiten, creëren of heralloceren van accounts kan ook lamports verplaatsen, dus de transactiesamenvatting moet worden bekeken naast het hoofdtokenbedrag.

Bericht, handtekeningen en instructies

Het bericht bevat accountadressen, een recente blockhash en gecompileerde instructies. Elke instructie noemt een programma en identificeert de accounts die het kan gebruiken. Vereiste ondertekenaars autoriseren het bericht, en versiebeheerde transacties kunnen adresopzoektabellen gebruiken om meer accounts te refereren zonder elk adres rechtstreeks in het pakket te plaatsen.

Versheid en bevestiging

Een recente blockhash voorkomt dat een gewone transactie onbeperkt geldig blijft. Als deze verloopt vóór verwerking, moet de transactie opnieuw worden opgebouwd en opnieuw worden ondertekend; het opnieuw uitzenden van de oude handtekening creëert geen nieuwe transactie. Durable nonce-workflows bestaan voor gespecialiseerde offline of vertraagde ondertekening en vereisen afzonderlijke afhandeling.

RPC-clients stellen processed, confirmed en finalized commitment-niveaus bloot. Een snelle interface kan processed-resultaten tonen vóór sterkere cluster-overeenstemming is bereikt. Stortingen, bruggen en afhankelijke applicatieacties moeten wachten op het niveau dat door die service wordt vereist en moeten de handtekening verifiëren via een actuele RPC of explorer.

Basis- en prioriteitscomponenten

Elke transactie betaalt een basisvergoeding in SOL voor vereiste handtekeningen. Het protocol drukt SOL uit in lamports, en het basisbedrag hangt daarom af van het aantal handtekeningen in plaats van de waarde van een betaling of token-swap. Een mislukte transactie kan de basisvergoeding verbruiken omdat handtekeningverificatie en uitvoering zijn geprobeerd.

Een optionele prioriteitsvergoeding is gebaseerd op de aangevraagde compute-unit-limiet en gekozen compute-unit-prijs. De limiet is een budget, geen voorspelling van feitelijk gebruik, dus het instellen ervan veel hoger dan nodig kan de prioriteitscomponent te veel betalen. Wallet-schattingen moeten recente omstandigheden en transactiesimulatie gebruiken in plaats van een vaste vergoeding van een andere applicatie te kopiëren.

Operationele controles

Houd voldoende SOL voor de vergoeding, zelfs wanneer het overgedragen asset een SPL-token is. Bekijk eventuele compute-budget-instructies, omdat deze de aangevraagde limiet en prioriteitsprijs kunnen wijzigen. Onderscheid ook transactiekosten van accountfinanciering, rent-gerelateerde saldi, swap-prijsimpact en applicatiekosten; het zijn afzonderlijke kosten, zelfs als één wallet ze samen samenvat.