Mimari

Kora, üç crate'ten oluşan bir Rust çalışma alanıdır (workspace):

kora-lib çekirdek mantığı ve RPC sunucusunu barındırır,
kora-cli operatörlerin çalıştırdığı kora ikili dosyasını derler ve
kora-deploy ayrı olarak sürümlenen, özelleşmiş bir program dağıtım aracıdır. Aksi belirtilmedikçe aşağıdaki her şey crates/lib/src içinde bulunur.

İstek yaşam döngüsü

Aşağıdaki diyagram, bir işlemin Kora üzerinden geçen genel akışını gösterir. Çağrı yolunu anlamak, bir Kora düğümünü yapılandırmak ve yeni özellikler eklemek için önemlidir.

Her aşama nerede yer alır

Diyagramdaki aşama	Kaynak	Giriş noktası
Ağ geçidi	`rpc_server/server.rs`	`run_rpc_server`
Yönlendirme	`rpc_server/rpc.rs`	`KoraRpc`
Metot başına mantık	`rpc_server/method/`	her JSON-RPC metodu için bir dosya
Doğrulama	`validator/transaction_validator.rs`	`TransactionValidator`
Eklentiler	`plugin/mod.rs`	`TransactionPluginRunner`
İmzalama	`signer/`	`solana-keychain` crate'i tarafından desteklenir

Bilinmesi gereken iki dosya daha var: config.rs tüm kora.toml şemasını tanımlar ve state.rs seri durumdan çıkarılmış (deserialized) yapılandırmayı süreç genelindeki durumda tutar.

rpc.rs, her JSON-RPC uç noktası için bir metot içeren ince bir yönlendirme katmanıdır ve tüm API'yi görmenin en hızlı yoludur. Her metodun mantığı, rpc_server/method/ altında kendi dosyasında yer alır. sign_transaction.rs dosyasını baştan sona okuyun; diğer imzalama metotları bunun varyasyonlarıdır.

Doğrulayıcıyı okumak

transaction_validator.rs ve transaction/instruction_util.rs, işlemleri ve talimatları doğrulamaya yönelik mantığı barındırır. Ayrıca, kapsama alınan her program için bir dosya olacak şekilde validator/transaction_validator/fee_payer_policy_props/ altında bulunan fee-payer-policy güvenlik özelliği testleri de vardır.

Bilmeye değer kurallar

Varsayılan doğrulama. [validation.fee_payer_policy] altındaki her bayrak varsayılan olarak false değerindedir ve politika yapıları #[serde(default)] taşır. Bu ikili bilinçli bir tercihtir: yeni kapsama alınan bir talimat eklemek mevcut bir operatörün yapılandırmasını bozmamalı ve yanlışlıkla izin verilmesi yerine bir ret olarak devreye girmelidir. Bir bayrak eklediğinizde her ikisini de koruyun.

Ham işlemi değil, çözümlenmiş işlemi doğrulayın. Ham VersionedTransaction yalnızca statik hesap anahtarlarını sunar; bu nedenle bir V0 işlemini bundan doğrulamak veya ücretlendirmek, arama tablosu (lookup-table) hesaplarını sessizce atlar ve eksik ücret hesaplar. VersionedTransactionResolved::from_transaction bu adresleri baştan çözümler; bu yüzden sonraki her aşama çözümlenmiş türü alır.

İşlem eklentisi ekleme

Eklentiler, plugin/mod.rs içindeki TransactionPlugin trait'ini uygular. İki metodu vardır: validate imzalama akışları sırasında her işlem için çalışır ve validate_config başlangıçta bir kez çalışarak operatör için hataları ve uyarıları döndürür. PluginExecutionContext, eklentiye dört imzalama metodundan hangisinin onu çağırdığını bildirir.

TransactionPluginRunner::from_config, config.rs içinde tanımlı TransactionPluginType üzerinde eşleştirme yapar. Yeni bir yerleşik eklenti, orada yeni bir varyant ve çalıştırıcıda yeni bir eşleştirme kolu (match arm) anlamına gelir. Bugün sunulan iki eklenti gas_swap ve deploy_authority'dir.

Test etme

Kora yapılandırmayı süreç genelindeki durumda tuttuğundan, tests/ her aşama için bir [[test]] hedefi tanımlar ve her hedef kendi gömülü surfnet'ini ve Kora düğümünü sıfırdan tohumlanmış şekilde başlatır. Her ikili dosya için tek yapılandırma: yeni bir aşama, mevcut bir hedefte yeni bir modül değil, yeni bir hedef gerektirir.

cargo test -p tests --test <target>

Geri kalan her şey justfile üzerinden bağlanır. Komutları elle yeniden oluşturmak yerine onu okuyun.