Arkkitehtuuri

Kora on Rust-workspace, joka koostuu kolmesta crate-paketista:

kora-lib sisältää ydinlogiikan ja RPC-palvelimen,
kora-cli rakentaa kora-binäärin, jota operaattorit ajavat, ja
kora-deploy on erikoistunut ohjelmien käyttöönottotyökalu, jolla on oma versiointinsa. Kaikki alla oleva sijaitsee hakemistossa crates/lib/src, ellei toisin mainita.

Pyynnön elinkaari

Alla oleva kaavio kuvaa transaktion yleisen kulun Koran läpi. Kutsupolun ymmärtäminen on tärkeää Kora-solmun konfiguroinnissa ja uusien ominaisuuksien lisäämisessä.

Missä kukin vaihe sijaitsee

Kaavion vaihe	Lähde	Aloituspiste
Yhdyskäytävä	`rpc_server/server.rs`	`run_rpc_server`
Reititys	`rpc_server/rpc.rs`	`KoraRpc`
Metodikohtainen logiikka	`rpc_server/method/`	yksi tiedosto kutakin JSON-RPC-metodia kohden
Validointi	`validator/transaction_validator.rs`	`TransactionValidator`
Laajennukset	`plugin/mod.rs`	`TransactionPluginRunner`
Allekirjoitus	`signer/`	toteutettu `solana-keychain`-crate-paketilla

Kaksi muuta tiedostoa kannattaa tuntea: config.rs määrittelee koko kora.toml-skeeman, ja state.rs sisältää deserialisoidun konfiguraation prosessin globaalissa tilassa.

rpc.rs on ohut reititystaso, jossa on yksi metodi kutakin JSON-RPC-päätepistettä kohden, ja nopein tapa nähdä koko API. Kunkin metodin logiikka on omassa tiedostossaan hakemistossa rpc_server/method/. Lue sign_transaction.rs alusta loppuun; muut allekirjoitusmetodit ovat sen muunnelmia.

Validointilogiikan lukeminen

transaction_validator.rs ja transaction/instruction_util.rs sisältävät logiikan transaktioiden ja instruktioiden validointiin. Lisäksi mukana ovat fee-payer-policyn turvallisuusominaisuuksien testit, jotka sijaitsevat yhtenä tiedostona kutakin rajattua ohjelmaa kohden hakemistossa validator/transaction_validator/fee_payer_policy_props/.

Hyvä tuntea käytännöt

Oletusvalidointi. Jokaisen [validation.fee_payer_policy]-osion lipun oletusarvo on false, ja policy-structeissa on #[serde(default)]. Tämä yhdistelmä on tarkoituksellinen: uuden rajatun instruktion lisääminen ei saa rikkoa olemassa olevan operaattorin konfiguraatiota, ja sen on päädyttävä estoksi eikä vahingossa sallinnaksi. Säilytä molemmat, kun lisäät lipun.

Validoi resolvoitu transaktio, älä koskaan raakaa. Raaka VersionedTransaction paljastaa vain staattiset tiliavaimet, joten V0-transaktion validointi tai hinnoittelu sen pohjalta ohittaa hiljaa lookup-table-tilit ja veloittaa liian vähän. VersionedTransactionResolved::from_transaction resolvoi nämä osoitteet etukäteen, minkä vuoksi jokainen jatkovaihe ottaa vastaan resolvoidun tyypin.

Transaktiolaajennuksen lisääminen

Laajennukset toteuttavat TransactionPlugin-traitin tiedostossa plugin/mod.rs. Siinä on kaksi metodia: validate ajetaan transaktiokohtaisesti allekirjoitusvirroissa, ja validate_config ajetaan kerran käynnistyksen yhteydessä ja palauttaa virheet ja varoitukset operaattorille. PluginExecutionContext kertoo laajennukselle, mikä neljästä allekirjoitusmetodista sen kutsui.

TransactionPluginRunner::from_config valitsee haaran TransactionPluginType-tyypin mukaan, joka on määritelty tiedostossa config.rs. Uusi sisäänrakennettu laajennus tarkoittaa uutta varianttia siellä sekä uutta match-haaraa runnerissa. Kaksi tällä hetkellä mukana toimitettavaa laajennusta ovat gas_swap ja deploy_authority.

Testaus

Kora säilyttää konfiguraation prosessin globaalissa tilassa, joten tests/-hakemisto määrittelee yhden [[test]]-kohteen kutakin vaihetta kohden, ja jokainen kohde käynnistää oman upotetun surfnetinsä sekä Kora-solmunsa, jotka alustetaan tyhjästä. Yksi konfiguraatio per binääri: uusi vaihe tarvitsee uuden kohteen, ei uutta moduulia olemassa olevaan.

cargo test -p tests --test <target>

Kaikki muu on kytketty justfile-tiedoston kautta. Lue se sen sijaan, että rakentaisit komennot uudelleen käsin.