Ontology Wasm-teknologi reducerer omkostningerne ved at migrere dApp smarte kontrakter med kompleks forretningslogik til blockchain og beriger derved i høj grad dApp-økosystemet.
Nu Understøtter samtidig både Rust og C++ udvikling. Rust-sproget understøtter Wasm bedre, og den genererede bytekode er enklere, hvilket yderligere kan reducere omkostningerne ved kontraktopkald. Så, hvordan bruger man Rust til at udvikle en kontrakt på Ontologi-netværket?
Udvikling af en WASM-kontrakt med Rust
Opret en kontrakt
er et godt projektoprettelse og pakkehåndteringsværktøj til Rust-udvikling, som hjælper udviklere med bedre at organisere samspillet mellem kode og tredjepartsbiblioteker. For at oprette en ny Ontology Wasm-kontrakt skal du blot køre følgende kommando:
Den projektstruktur, det genererer:
Cargo.toml-filen bruges til at opsætte grundlæggende projektinformation og afhængige biblioteksoplysninger. [lib] sektionen af filen skal indstilles til kasse-type = ["cdylib"]. Filen lib.rs bruges til at skrive kontraktlogikkoden. Derudover skal du tilføje afhængighedsparametre til sektionen [afhængigheder] i Cargo.toml-konfigurationsfilen:
Med denne afhængighed kan udviklere kalde grænseflader, der interagerer med Ontology blockchain og værktøjer såsom serialiseringsparameteren.
Funktion til kontraktindtastning
Hvert program har en inputfunktion, ligesom hovedfunktionen vi normalt ser, men kontrakten har ikke en hovedfunktion. Når en Wasm-kontrakt udvikles ved hjælp af Rust, bruges standardinvoke-funktionen som inputfunktion til at bruge kontrakten. Navnet på en funktion i Rust vil være uklart, når Rust-kildekoden kompileres til bytekode, der kan udføres af en virtuel maskine. For at forhindre compileren i at generere redundant kode og reducere størrelsen af kontrakten, tilføjer invoke-funktionen #[no_mangle]-annotationen.
Hvordan får invoke-funktionen parametre til at udføre en transaktion?
Ontio_std-biblioteket giver en runtime::input() funktion til at få parametrene til at udføre en transaktion. Udviklere kan bruge ZeroCopySource til at deserialisere den resulterende byte-array. I hvilket det første array af læste bytes er navnet på invoke-metoden, efterfulgt af metodeparametrene.
Hvordan returneres resultatet af kontraktudførelsen?
Runtime::ret-funktionen leveret af ontio_std-biblioteket returnerer resultatet af en metodeudførelse.
Den afsluttede invoke-funktion ser sådan ud:
Serialisering og deserialisering af kontraktdata
I processen med at udvikle kontrakter støder udviklere altid ind i problemer med serialisering og deserialisering, specifikt med hvordan man gemmer en strukturdatatype i databasen og hvordan man deserialiserer en byte-array læst fra databasen for at få en strukturdatatype.
Ontio_std-biblioteket giver dekoder- og kodergrænseflader til dataserialisering og deserialisering. Felterne i en struktur implementerer også dekoder- og encodergrænseflader, så strukturen kan serialiseres og deserialiseres. Forekomster af Sink-klassen er påkrævet, når forskellige datatyper serialiseres. En forekomst af Sink-klassen har en set-type field buf, der gemmer bytetypedataene, og alle serialiserede data gemmes i buf.
For data med fast længde (f.eks.: byte, u16, u32, u64 osv.), konverteres dataene direkte til et byte-array og gemmes derefter i buf; for data af ikke-fast længde skal længde først serialiseres, derefter Ddata (f.eks. heltal uden fortegn af ukendt størrelse, inklusive u16, u32 eller u64 osv.).
Deserialisering er det stik modsatte. For hver serialiseringsmetode er der en tilsvarende deserialiseringsmetode. Deserialisering kræver brug af forekomster af kildeklassen. Denne klasseinstans har to felter buf og pos. Buf bruges til at lagre de data, der skal deserialiseres, og pos bruges til at gemme den aktuelle læseposition. Når en bestemt type data læses, hvis du kender dens længde, kan du læse den direkte, for data af ukendt længde - læs længden først, og læs derefter indholdet.
Få adgang til og opdatere data i kæden
ontologi-wasm-cdt-rust - indkapslet en operationel metode til at arbejde med data i kæden, som er praktisk for udviklere at implementere operationer såsom tilføjelse, sletning, ændring og forespørgsel om data i kæden som følger:
- database::get(nøgle) - bruges til at anmode om data fra kæden, og nøglen anmoder om implementering af AsRef-grænsefladen;
- database::put(nøgle, værdi) - bruges til at gemme data på netværket. Key anmoder om implementering af AsRef-grænsefladen, og værdi anmoder om implementering af Encoder-grænsefladen;
- database::delete(nøgle) - bruges til at fjerne data fra kæden, og nøglen anmoder om implementering af AsRef-grænsefladen.
Kontrakt test
Når metoderne til en kontrakt implementeres, har vi brug for adgang til dataene på kæden, og vi har brug for en passende virtuel maskine til at udføre kontraktens bytekode, så det er generelt nødvendigt at implementere kontrakten på kæden til test. Men denne testmetode er problematisk. For at gøre det lettere for udviklere at teste kontrakter, tilbyder ontio_std-biblioteket et mock-modul til test. Dette modul giver en simulering af dataene i kredsløbet, hvilket gør det lettere for udviklere at enhedsteste metoderne i kontrakten. Der kan findes konkrete eksempler .
Kontraktfejlfinding
console::debug(msg) viser fejlfindingsoplysninger, mens en kontrakt fejlsøges. Beskedoplysningerne vil blive tilføjet til nodelogfilen. En forudsætning er at indstille logfilniveauet til fejlretningstilstand, når den lokale ontologitestknude kører.
runtime::notify(msg) udsender den relevante fejlretningsinformation, mens kontrakten fejlfindes. Denne metode gemmer de oplysninger, der er indtastet i kæden, og kan forespørges fra kæden ved hjælp af getSmartCodeEvent-metoden.
Artiklen er oversat af redaktørerne af Hashrate&Shares specielt til OntologyRussia.
Er du udvikler? Tilmeld dig vores tech-fællesskab på . Tag også et kig på på vores hjemmeside, hvor du kan finde udviklerværktøjer, dokumentation og meget mere.
Ontologi
- /
- Telegram /
- /
Kilde: www.habr.com