Architectuur

Kora is een Rust-workspace met drie crates:

• kora-lib bevat de kernlogica en de RPC-server,
• kora-cli bouwt de kora-binary die operators draaien, en
• kora-deploy is een gespecialiseerde tool voor het uitrollen van programma's, met een eigen versiebeheer. Alles hieronder bevindt zich in crates/lib/src, tenzij anders vermeld.

De levenscyclus van een verzoek

Het onderstaande diagram toont de algemene stroom van een transactie door Kora. Het begrijpen van het aanroeppad is belangrijk om een Kora-node te configureren en nieuwe functies toe te voegen.

Waar elke fase zich bevindt

Nog twee bestanden om te kennen: config.rs definieert het volledige kora.toml-schema en state.rs bewaart de gedeserialiseerde configuratie in een procesbrede globale status.

De RPC-server doorlezen

rpc.rs is een dunne dispatchlaag, met één methode per JSON-RPC-endpoint, en de snelste manier om de hele API te overzien. De logica van elke methode staat in een eigen bestand onder rpc_server/method/. Lees sign_transaction.rs van begin tot eind; de andere ondertekeningsmethoden zijn variaties daarop.

De validatiemodule doorlezen

transaction_validator.rs en transaction/instruction_util.rs bevatten de logica voor het valideren van transacties en instructies. Daarnaast zijn er de veiligheidseigenschapstests voor het fee-payer-beleid, die per afgeschermd programma in één bestand staan onder validator/transaction_validator/fee_payer_policy_props/.

Conventies die je moet kennen

Standaardvalidatie. Elke vlag onder [validation.fee_payer_policy] staat standaard op false, en de beleidsstructs dragen #[serde(default)]. Die combinatie is bewust: het toevoegen van een nieuw afgeschermde instructie mag de configuratie van een bestaande operator niet breken, en moet resulteren in een weigering in plaats van een onbedoelde toestemming. Behoud beide wanneer je een vlag toevoegt.

Valideer de opgeloste transactie, nooit de ruwe. De ruwe VersionedTransaction toont alleen statische accountsleutels, dus het valideren of prijzen van een V0-transactie op basis daarvan slaat lookup-table-accounts stilzwijgend over en berekent te weinig. VersionedTransactionResolved::from_transaction lost die adressen vooraf op, en daarom accepteert elke daaropvolgende fase het opgeloste type.

Een transactieplug-in toevoegen

Plug-ins implementeren de TransactionPlugin-trait in plugin/mod.rs. Die heeft twee methoden: validate draait per transactie tijdens de ondertekeningsflows, en validate_config draait eenmalig bij het opstarten en geeft fouten en waarschuwingen terug aan de operator. Een PluginExecutionContext vertelt de plug-in welke van de vier ondertekeningsmethoden hem heeft aangeroepen.

TransactionPluginRunner::from_config matcht op TransactionPluginType, gedefinieerd in config.rs. Een nieuwe ingebouwde plug-in is een nieuwe variant daar plus een nieuwe match-arm in de runner. De twee plug-ins die nu worden meegeleverd, zijn gas_swap en deploy_authority.

Testen

Kora bewaart de configuratie in procesbrede globale status, dus tests/ declareert één [[test]]-target per fase, en elke target start zijn eigen ingebedde surfnet plus Kora-node, vanaf nul opgezet. Eén configuratie per binary: een nieuwe fase vraagt om een nieuwe target, niet om een nieuwe module in een bestaande.

cargo test -p tests --test <target>

Al het andere is aangesloten via de justfile. Lees die in plaats van commando's met de hand te reconstrueren.