Ontology Wasm-teknologi reduserer kostnadene ved å migrere dApp smarte kontrakter med kompleks forretningslogikk til blokkjeden, og beriker dermed dApp-økosystemet i stor grad.
Nå Støtter samtidig både Rust og C++ utvikling. Rust-språket støtter Wasm bedre, og den genererte bytekoden er enklere, noe som kan redusere kostnadene for kontraktanrop ytterligere. Så, hvordan bruke Rust til å utvikle en kontrakt på ontologinettverket?
Utvikle en WASM-kontrakt med Rust
Lag en kontrakt
er et godt prosjektopprettings- og pakkehåndteringsverktøy for Rust-utvikling, som hjelper utviklere med å organisere samspillet mellom kode og tredjepartsbiblioteker bedre. For å opprette en ny Ontology Wasm-kontrakt, kjør ganske enkelt følgende kommando:
Prosjektstrukturen den genererer:
Cargo.toml-filen brukes til å sette opp grunnleggende prosjektinformasjon og avhengig bibliotekinformasjon. [lib]-delen av filen må settes til kasse-type = ["cdylib"]. lib.rs-filen brukes til å skrive kontraktslogikkkoden. I tillegg må du legge til avhengighetsparametere i [avhengigheter]-delen av Cargo.toml-konfigurasjonsfilen:
Med denne avhengigheten kan utviklere ringe grensesnitt som samhandler med Ontology-blokkjeden og verktøy som serialiseringsparameteren.
Funksjon for kontraktsinngåelse
Hvert program har en inngangsfunksjon, som hovedfunksjonen vi vanligvis ser, men kontrakten har ikke en hovedfunksjon. Når en Wasm-kontrakt er utviklet ved bruk av Rust, brukes standard invoke-funksjonen som inngangsfunksjon for å bruke kontrakten. Navnet på en funksjon i Rust vil være uklart når Rust-kildekoden kompileres til bytekode som kan kjøres av en virtuell maskin. For å forhindre at kompilatoren genererer redundant kode og redusere størrelsen på kontrakten, legger invoke-funksjonen til #[no_mangle]-kommentaren.
Hvordan får invoke-funksjonen parametere for å utføre en transaksjon?
Ontio_std-biblioteket gir en runtime::input()-funksjon for å få parametrene for å utføre en transaksjon. Utviklere kan bruke ZeroCopySource for å deserialisere den resulterende byte-arrayen. Der den første arrayen med byte som leses er navnet på invoke-metoden, etterfulgt av metodeparameterne.
Hvordan returneres resultatet av kontraktsgjennomføringen?
Runtime::ret-funksjonen levert av ontio_std-biblioteket returnerer resultatet av en metodekjøring.
Den fullførte invoke-funksjonen ser slik ut:
Serialisering og deserialisering av kontraktsdata
I prosessen med å utvikle kontrakter, får utviklere alltid problemer med serialisering og deserialisering, spesielt med hvordan man lagrer en strukturdatatype i databasen og hvordan man deserialiserer en byte-array som leses fra databasen for å få en strukturdatatype.
Ontio_std-biblioteket gir dekoder- og kodergrensesnitt for dataserialisering og deserialisering. Feltene til en struktur implementerer også dekoder- og kodergrensesnittene slik at strukturen kan serialiseres og deserialiseres. Forekomster av Sink-klassen kreves når ulike datatyper serialiseres. En forekomst av Sink-klassen har en set-type felt-buf som lagrer bytetypedataene, og alle serialiserte data lagres i buf.
For data med fast lengde (f.eks.: byte, u16, u32, u64, etc.), blir dataene direkte konvertert til en byte-array og deretter lagret i buf; for data med ikke-fast lengde, må lengden serialiseres først, deretter Ddata (for eksempel heltall uten fortegn av ukjent størrelse, inkludert u16, u32 eller u64 osv.).
Deserialisering er det stikk motsatte. For hver serialiseringsmetode er det en tilsvarende deserialiseringsmetode. Deserialisering krever bruk av forekomster av kildeklassen. Denne klasseforekomsten har to felt buf og pos. Buf brukes til å lagre dataene som skal deserialiseres og pos brukes til å lagre gjeldende leseposisjon. Når en bestemt type data leses, hvis du vet lengden, kan du lese den direkte, for data av ukjent lengde – les lengden først, og les deretter innholdet.
Få tilgang til og oppdater data i kjeden
ontologi-wasm-cdt-rust - innkapslet en operasjonsmetode for å jobbe med data i kjeden, som er praktisk for utviklere å implementere operasjoner som å legge til, slette, endre og spørre om data i kjeden som følger:
- database::get(nøkkel) - brukes til å be om data fra kjeden, og nøkkelen ber om implementering av AsRef-grensesnittet;
- database::put(nøkkel, verdi) - brukes til å lagre data på nettverket. Key ber om implementering av AsRef-grensesnittet, og value ber om implementering av Encoder-grensesnittet;
- database::delete(nøkkel) - brukes til å fjerne data fra kjeden, og nøkkelen ber om implementering av AsRef-grensesnittet.
Kontrakt testing
Når metodene for en kontrakt er implementert, trenger vi tilgang til dataene i kjeden og vi trenger en passende virtuell maskin for å utføre bytekoden til kontrakten, så det er generelt nødvendig å distribuere kontrakten på kjeden for testing. Men denne testmetoden er problematisk. For å gjøre det enklere for utviklere å teste kontrakter, tilbyr ontio_std-biblioteket en mock-modul for testing. Denne modulen gir en simulering av dataene i kretsen, noe som gjør det lettere for utviklere å enhetsteste metodene i kontrakten. Du kan finne spesifikke eksempler .
Kontraktsfeilsøking
console::debug(msg) viser feilsøkingsinformasjon mens du feilsøker en kontrakt. Meldingsinformasjonen vil bli lagt til nodeloggfilen. En forutsetning er å sette loggfilnivået til feilsøkingsmodus når den lokale ontologitestnoden kjører.
runtime::notify(msg) sender ut riktig feilsøkingsinformasjon mens kontrakten feilsøkes. Denne metoden vil lagre informasjonen som er lagt inn i kjeden og kan spørres fra kjeden ved hjelp av getSmartCodeEvent-metoden.
Artikkelen ble oversatt av redaktørene til Hashrate&Shares spesielt for OntologyRussia.
Er du en utvikler? Bli med i vårt tekniske fellesskap på . Ta også en titt på på nettsiden vår, hvor du kan finne utviklerverktøy, dokumentasjon og mer.
ontologi
- /
- Telegram /
- /
Kilde: www.habr.com