Ontology Wasm-teknologin minskar kostnaderna för att migrera dApps smarta kontrakt med komplex affärslogik till blockkedjan och berikar därmed dApps ekosystem avsevärt.
Nu Stöder samtidigt både Rust och C++ utveckling. Rust-språket stöder Wasm bättre, och den genererade bytekoden är enklare, vilket ytterligare kan minska kostnaden för avtalssamtal. Så, hur man använder Rust för att utveckla ett kontrakt på ontologinätverket?
Utveckla ett WASM-kontrakt med Rust
Skapa ett kontrakt
är ett bra verktyg för projektskapande och pakethantering för Rust-utveckling, som hjälper utvecklare att bättre organisera interaktionen mellan kod och tredjepartsbibliotek. För att skapa ett nytt Ontology Wasm-kontrakt, kör helt enkelt följande kommando:
Projektstrukturen den genererar:
Filen Cargo.toml används för att ställa in grundläggande projektinformation och beroende biblioteksinformation. [lib]-delen av filen måste vara inställd på crate-type = ["cdylib"]. Filen lib.rs används för att skriva kontraktslogikkoden. Dessutom måste du lägga till beroendeparametrar i avsnittet [beroenden] i konfigurationsfilen Cargo.toml:
Med detta beroende kan utvecklare anropa gränssnitt som interagerar med Ontology blockchain och verktyg som serialiseringsparametern.
Avtalsinförande funktion
Varje program har en ingångsfunktion, som huvudfunktionen vi vanligtvis ser, men kontraktet har ingen huvudfunktion. När ett Wasm-kontrakt utvecklas med hjälp av Rust, används standardinvoke-funktionen som indatafunktion för att använda kontraktet. Namnet på en funktion i Rust kommer att vara oklart när Rust källkod kompileras till bytekod som kan köras av en virtuell maskin. För att förhindra att kompilatorn genererar redundant kod och minska storleken på kontraktet, lägger invoke-funktionen till #[no_mangle]-anteckningen.
Hur får invoke-funktionen parametrar för att utföra en transaktion?
Ontio_std-biblioteket tillhandahåller en runtime::input()-funktion för att få parametrarna för att exekvera en transaktion. Utvecklare kan använda ZeroCopySource för att deserialisera den resulterande byte-arrayen. I vilken den första arrayen av byte som läses är namnet på anropsmetoden, följt av metodparametrarna.
Hur returneras resultatet av kontraktsutförandet?
Runtime::ret-funktionen som tillhandahålls av ontio_std-biblioteket returnerar resultatet av en metodexekvering.
Den färdiga anropsfunktionen ser ut så här:
Serialisering och avserialisering av kontraktsdata
I processen att utveckla kontrakt stöter utvecklare alltid på problem med serialisering och deserialisering, särskilt med hur man lagrar en strukturdatatyp i databasen och hur man deserialiserar en byte-array som läses från databasen för att få en strukturdatatyp.
Ontio_std-biblioteket tillhandahåller avkodar- och kodargränssnitt för dataserialisering och deserialisering. Fälten i en struktur implementerar också avkodar- och kodargränssnitten så att strukturen kan serialiseras och deserialiseras. Förekomster av Sink-klassen krävs när olika datatyper serialiseras. En instans av Sink-klassen har en set-type field buf som lagrar bytetypdata, och all serialiserad data lagras i buf.
För data med fast längd (t.ex.: byte, u16, u32, u64, etc.), konverteras data direkt till en byte-array och lagras sedan i buf; för data av icke-fast längd måste längden serialiseras först, sedan Ddata (till exempel heltal utan tecken av okänd storlek, inklusive u16, u32 eller u64, etc.).
Deserialisering är raka motsatsen. För varje serialiseringsmetod finns det en motsvarande deserialiseringsmetod. Deserialisering kräver användning av instanser av klassen Source. Denna klassinstans har två fält buf och pos. Buf används för att lagra data som ska deserialiseras och pos används för att lagra den aktuella läspositionen. När en viss typ av data läses, om du vet dess längd, kan du läsa den direkt, för data av okänd längd – läs först längden och läs sedan innehållet.
Få tillgång till och uppdatera data i kedjan
ontologi-wasm-cdt-rust - inkapslade en operativ metod för att arbeta med data i kedjan, vilket är bekvämt för utvecklare att implementera operationer som att lägga till, ta bort, ändra och fråga data i kedjan enligt följande:
- databas::get(nyckel) - används för att begära data från kedjan, och nyckeln begär implementering av AsRef-gränssnittet;
- database::put(nyckel, värde) - används för att lagra data på nätverket. Key begär implementering av AsRef-gränssnittet och värde begär implementering av kodargränssnittet;
- database::delete(nyckel) - används för att ta bort data från kedjan, och nyckeln begär implementering av AsRef-gränssnittet.
Kontraktsprovning
När metoderna för ett kontrakt implementeras behöver vi tillgång till data i kedjan och vi behöver en lämplig virtuell maskin för att exekvera bytekoden för kontraktet, så det är i allmänhet nödvändigt att distribuera kontraktet på kedjan för testning. Men denna testmetod är problematisk. För att göra det lättare för utvecklare att testa kontrakt tillhandahåller ontio_std-biblioteket en låtsasmodul för testning. Denna modul ger en simulering av data i kretsen, vilket gör det lättare för utvecklare att enhetstesta metoderna i kontraktet. Specifika exempel kan hittas .
Kontraktsfelsökning
console::debug(msg) visar felsökningsinformation under felsökning av ett kontrakt. Meddelandeinformationen kommer att läggas till i nodloggfilen. En förutsättning är att ställa in loggfilsnivån till felsökningsläge när den lokala ontologitestnoden körs.
runtime::notify(msg) matar ut lämplig felsökningsinformation medan kontraktet felsöks. Denna metod kommer att lagra informationen som skrivs in i kedjan och kan frågas från kedjan med metoden getSmartCodeEvent.
Artikeln översattes av redaktörerna för Hashrate&Shares speciellt för OntologyRussia.
Är du en utvecklare? Gå med i vår tekniska community på . Ta också en titt på på vår webbplats, där du kan hitta utvecklarverktyg, dokumentation med mera.
Ontologi
- /
- Telegram /
- /
Källa: will.com