Solana (SOL): Cara Kerja Transaksi dan Validator

Status berada di akun

Setiap bagian status Solana yang persisten disimpan dalam akun yang diidentifikasi oleh alamat 32-byte. Akun mencatat lamports, data, program pemilik, dan bidang terkait eksekusi. Pemilik adalah program yang diizinkan untuk mengubah data akun tersebut; itu belum tentu manusia yang mengontrol kunci dompet.

Program Solana adalah akun yang dapat dieksekusi yang berisi bytecode sBPF. Program umumnya diperlakukan sebagai tanpa status karena status aplikasi yang dapat diubah berada di akun terpisah yang disediakan untuk setiap instruksi. Ini memungkinkan runtime melihat akun mana yang akan dibaca atau ditulis oleh transaksi sebelum eksekusi dan menjadwalkan pekerjaan yang tidak bersaing untuk status yang dapat ditulis yang sama.

Dompet, akun token, dan PDA

Alamat dompet dapat memiliki SOL dan mengotorisasi transaksi, tetapi saldo token SPL biasanya berada di akun token yang terkait dengan mint dan pemilik. Alamat Turunan Program diturunkan secara deterministik dari program ID dan seed; program dapat mengotorisasi untuk itu melalui aturan runtime meskipun tidak ada kunci pribadi untuk alamat tersebut.

Sebelum mengirim token, konfirmasikan mint, akun token tujuan, dan program yang dipanggil. Ticker atau label dompet yang familiar bukanlah bukti bahwa mint itu kanonik. Menutup, membuat, atau mengalokasikan ulang akun juga dapat memindahkan lamports, jadi ringkasan transaksi harus ditinjau di luar jumlah token utama.

Pesan, tanda tangan, dan instruksi

Pesan mencantumkan alamat akun, blockhash terbaru, dan instruksi yang dikompilasi. Setiap instruksi menamai program dan mengidentifikasi akun yang dapat digunakannya. Penandatangan yang diperlukan mengotorisasi pesan, dan transaksi berversi dapat menggunakan tabel pencarian alamat untuk mereferensikan lebih banyak akun tanpa menempatkan setiap alamat langsung di paket.

Kesegaran dan konfirmasi

Blockhash terbaru mencegah transaksi biasa tetap valid tanpa batas waktu. Jika kedaluwarsa sebelum diproses, transaksi harus dibangun ulang dan ditandatangani lagi; menyiarkan ulang tanda tangan lama tidak membuat transaksi baru. Alur kerja nonce tahan lama ada untuk penandatanganan offline atau tertunda khusus dan memerlukan penanganan terpisah.

Klien RPC mengekspos tingkat komitmen yang diproses, dikonfirmasi, dan difinalisasi. Antarmuka cepat dapat menampilkan hasil yang diproses sebelum kesepakatan klaster yang lebih kuat tercapai. Deposit, jembatan, dan tindakan aplikasi dependen harus menunggu tingkat yang disyaratkan oleh layanan tersebut dan harus memverifikasi tanda tangan melalui RPC atau penjelajah saat ini.

Komponen dasar dan prioritas

Setiap transaksi membayar biaya dasar dalam SOL untuk tanda tangan yang diperlukan. Protokol menyatakan SOL dalam lamports, dan jumlah dasar karena itu bergantung pada jumlah tanda tangan daripada nilai pembayaran atau pertukaran token. Transaksi yang gagal dapat menghabiskan biaya dasar karena verifikasi tanda tangan dan eksekusi dicoba.

Biaya prioritas opsional didasarkan pada batas unit komputasi yang diminta dan harga unit komputasi yang dipilih. Batas adalah anggaran, bukan prediksi penggunaan aktual, jadi menetapkannya jauh lebih tinggi dari yang diperlukan dapat membayar lebih komponen prioritas. Estimasi dompet harus menggunakan kondisi terbaru dan simulasi transaksi alih-alih menyalin biaya tetap dari aplikasi lain.

Pemeriksaan operasional

Sisakan cukup SOL untuk biaya bahkan ketika aset yang ditransfer adalah token SPL. Tinjau instruksi anggaran komputasi apa pun, karena dapat mengubah batas yang diminta dan harga prioritas. Juga bedakan biaya transaksi dari pendanaan akun, saldo terkait sewa, dampak harga swap, dan biaya aplikasi; itu adalah biaya terpisah meskipun satu dompet merangkumnya bersama-sama.