Arsitektur

Kora adalah workspace Rust dengan tiga crate:

  • kora-lib berisi logika inti dan server RPC,
  • kora-cli membangun biner kora yang dijalankan oleh operator, dan
  • kora-deploy adalah alat deployment program khusus yang versinya dikelola secara terpisah. Semua yang dibahas di bawah ini berada di crates/lib/src kecuali dinyatakan lain.

Siklus hidup permintaan

Diagram di bawah ini menunjukkan alur umum sebuah transaksi melalui Kora. Memahami jalur pemanggilan penting untuk mengonfigurasi node Kora dan menambahkan fitur baru.

A transaction travels from the client app through the gateway, validation, plugins, and signing, before Kora either returns it or broadcasts it. Each stage is governed by a matching section of kora.toml or signers.toml.

Lokasi setiap tahap

Tahap dalam diagramSumberTitik masuk
Gatewayrpc_server/server.rsrun_rpc_server
Dispatchrpc_server/rpc.rsKoraRpc
Logika per metoderpc_server/method/satu file per metode JSON-RPC
Validasivalidator/transaction_validator.rsTransactionValidator
Pluginplugin/mod.rsTransactionPluginRunner
Penandatanganansigner/didukung oleh crate solana-keychain

Dua file lagi yang perlu diketahui: config.rs mendefinisikan seluruh skema kora.toml, dan state.rs menyimpan konfigurasi yang telah dideserialisasi dalam state global proses.

Membaca server RPC

rpc.rs adalah lapisan dispatch tipis, satu metode untuk setiap endpoint JSON-RPC, dan cara tercepat untuk melihat seluruh API. Logika setiap metode berada di file tersendiri di bawah rpc_server/method/. Bacalah sign_transaction.rs dari awal sampai akhir; metode penandatanganan lainnya merupakan variasi darinya.

Membaca validator

transaction_validator.rs dan transaction/instruction_util.rs berisi logika untuk memvalidasi transaksi dan instruksi. Selain itu, ada pengujian properti keamanan fee-payer-policy, yang berada dalam satu file per program yang dibatasi di validator/transaction_validator/fee_payer_policy_props/.

Konvensi yang perlu diketahui

Validasi default. Setiap flag di bawah [validation.fee_payer_policy] secara default bernilai false, dan struct kebijakan membawa #[serde(default)]. Pasangan itu disengaja: menambahkan instruksi baru yang dibatasi tidak boleh merusak konfigurasi operator yang sudah ada, dan harus berstatus penolakan, bukan izin yang tidak disengaja. Pertahankan keduanya saat Anda menambahkan flag.

Validasi transaksi yang telah di-resolve, jangan pernah yang mentah. VersionedTransaction mentah hanya mengekspos kunci akun statis, sehingga memvalidasi atau menghitung biaya transaksi V0 darinya akan melewatkan akun lookup-table secara diam-diam dan menghasilkan biaya yang terlalu rendah. VersionedTransactionResolved::from_transaction me-resolve alamat tersebut di awal, itulah sebabnya setiap tahap berikutnya menerima tipe yang telah di-resolve.

Menambahkan plugin transaksi

Plugin mengimplementasikan trait TransactionPlugin di plugin/mod.rs. Trait ini memiliki dua metode: validate berjalan per transaksi selama alur penandatanganan, dan validate_config berjalan sekali saat startup dan mengembalikan error serta peringatan untuk operator. Sebuah PluginExecutionContext memberi tahu plugin metode mana dari empat metode penandatanganan yang memanggilnya.

TransactionPluginRunner::from_config melakukan pencocokan pada TransactionPluginType, yang didefinisikan di config.rs. Plugin bawaan baru berarti varian baru di sana ditambah match arm baru di runner. Dua plugin yang tersedia saat ini adalah gas_swap dan deploy_authority.

Pengujian

Kora menyimpan konfigurasi dalam state global proses, sehingga tests/ mendeklarasikan satu target [[test]] per fase, dan setiap target menjalankan surfnet tertanam serta node Kora-nya sendiri, yang diinisialisasi dari nol. Satu konfigurasi per biner: fase baru memerlukan target baru, bukan modul baru di target yang sudah ada.

cargo test -p tests --test <target>

Semua hal lainnya terhubung melalui justfile. Bacalah file itu daripada menyusun ulang perintah secara manual.

Is this page helpful?

Daftar Isi

Edit Halaman
© 2026 Yayasan Solana. Semua hak dilindungi.