Ontology Wasm tækni dregur úr kostnaði við að flytja dApp snjallsamninga með flóknum viðskiptarökfræði yfir í blockchain og auðgar þar með dApp vistkerfið til muna.
Nú Styður samtímis bæði Rust og C++ þróun. Rust tungumálið styður Wasm betur og bækikóði sem myndast er einfaldari, sem getur dregið enn frekar úr kostnaði við samningssímtöl. Svo, hvernig á að nota Rust til að þróa samning um verufræðinetið?
Að þróa WASM samning við Rust
Búðu til samning
er gott verkefnagerð og pakkastjórnunartæki fyrir Rust þróun, sem hjálpar forriturum að skipuleggja betur samspil kóða og þriðja aðila bókasöfn. Til að búa til nýjan Ontology Wasm samning skaltu einfaldlega keyra eftirfarandi skipun:
Verkefnaskipulagið sem það býr til:
Cargo.toml skráin er notuð til að setja upp grunnupplýsingar um verkefni og háðar upplýsingar um bókasafn. [lib] hluti skráarinnar verður að vera stilltur á crate-type = ["cdylib"]. lib.rs skráin er notuð til að skrifa samningsrökfræðikóðann. Að auki þarftu að bæta breytum fyrir ósjálfstæði við [ósjálfstæði] hluta Cargo.toml stillingarskrárinnar:
Með þessari ósjálfstæði geta verktaki hringt í viðmót sem hafa samskipti við Ontology blockchain og verkfæri eins og serialization færibreytuna.
Virkni samningsfærslu
Sérhvert forrit hefur inntaksaðgerð, eins og aðalaðgerðin sem við sjáum venjulega, en samningurinn hefur ekki aðalhlutverk. Þegar Wasm samningur er þróaður með því að nota Rust er sjálfgefna uppkallsaðgerðin notuð sem inntaksaðgerð til að nota samninginn. Nafn falls í Rust verður óljóst þegar Rust frumkóða er sett saman í bækikóða sem hægt er að keyra með sýndarvél. Til að koma í veg fyrir að þýðandinn myndi óþarfa kóða og minnka umfang samningsins, bætir invoke fallið við #[no_mangle] skýringunni.
Hvernig fær invoke aðgerðin færibreytur til að framkvæma viðskipti?
Ontio_std bókasafnið býður upp á runtime::input() aðgerð til að fá færibreytur til að framkvæma viðskipti. Hönnuðir geta notað ZeroCopySource til að deserialize bætafylki sem myndast. Þar sem fyrsta fylkið af lesnum bætum er heiti ákallaaðferðarinnar, fylgt eftir af aðferðarbreytunum.
Hvernig er niðurstöðu samningsframkvæmdarinnar skilað?
Runtime::ret aðgerðin sem ontio_std bókasafnið gefur upp skilar niðurstöðu aðferðar keyrslu.
Lokaða ákallsaðgerðin lítur svona út:
Serializing og deserializing samningsgögn
Í því ferli að þróa samninga, lenda verktaki alltaf í vandræðum með raðgreiningu og afserialization, sérstaklega með hvernig á að geyma struct gagnategund í gagnagrunninum og hvernig á að deserialize bæta fylki lesið úr gagnagrunninum til að fá struct gagnategund.
Ontio_std bókasafnið býður upp á afkóðara og umrita tengi fyrir raðgreiningu og raðgreiningu gagna. Reitir structur útfæra einnig afkóðara og kóðara tengi þannig að hægt sé að raða og afserða uppbygginguna. Tilvik af Sink-flokknum eru nauðsynleg þegar ýmsar gagnagerðir eru raðaðar. Tilvik af Sink bekknum er með set-type field buf sem geymir bætategund gögnin og öll raðnúmeruð gögn eru geymd í buf.
Fyrir gögn með fastri lengd (td: bæti, u16, u32, u64, o.s.frv.), er gögnunum beint breytt í bætafylki og síðan geymt í buf; fyrir gögn sem eru ekki með fastri lengd, verður að setja lengd fyrst í röð, síðan Ddata (til dæmis óundirritaðar heiltölur af óþekktri stærð, þar á meðal u16, u32 eða u64, o.s.frv.).
Deserialization er akkúrat andstæðan. Fyrir hverja raðgreiningaraðferð er samsvarandi raðgreiningaraðferð. Afserialization krefst notkunar á tilvikum af Source-flokknum. Þetta klasatilvik hefur tvö reiti buf og pos. Buf er notað til að geyma gögnin sem á að deserialized og pos er notað til að geyma núverandi lesstöðu. Þegar tiltekin tegund gagna er lesin, ef þú veist lengd þeirra, geturðu lesið þau beint, fyrir gögn af óþekktri lengd - lestu lengdina fyrst, lestu síðan innihaldið.
Fáðu aðgang að og uppfærðu gögn í keðjunni
verufræði-wasm-cdt-ryð - hjúpað rekstraraðferð til að vinna með gögn í keðjunni, sem er þægilegt fyrir þróunaraðila að innleiða aðgerðir eins og að bæta við, eyða, breyta og spyrjast fyrir um gögn í keðjunni sem hér segir:
- gagnagrunnur::get(lykill) - er notað til að biðja um gögn frá keðjunni og lykill biður um innleiðingu AsRef viðmótsins;
- gagnagrunnur::put(lykill, gildi) - notað til að geyma gögn á netinu. Key biður um innleiðingu á AsRef viðmótinu og gildi biður um innleiðingu á Encoder viðmótinu;
- gagnagrunnur :: eyða (lykill) - er notað til að fjarlægja gögn úr keðjunni og lykill biður um innleiðingu á AsRef viðmótinu.
Samningsprófun
Þegar aðferðir samnings eru innleiddar þurfum við aðgang að gögnum í keðjunni og við þurfum viðeigandi sýndarvél til að framkvæma bækikóða samningsins, svo það er almennt nauðsynlegt að dreifa samningnum á keðjunni til að prófa. En þessi prófunaraðferð er erfið. Til að auðvelda forriturum að prófa samninga, býður ontio_std bókasafnið upp á sýndareiningu til að prófa. Þessi eining veitir eftirlíkingu af gögnum í hringrásinni, sem gerir það auðveldara fyrir þróunaraðila að einingaprófa aðferðirnar í samningnum. Sérstök dæmi má finna .
Samningur villuleit
console::debug(msg) sýnir villuleitarupplýsingar meðan verið er að kemba samning. Skilaboðunum verður bætt við hnútaskrána. Forsenda er að stilla skráarstigið á villuleitarham þegar staðbundinn Verufræðiprófunarhnútur er í gangi.
runtime::notify(msg) gefur út viðeigandi villuleitarupplýsingar á meðan verið er að kemba samninginn. Þessi aðferð mun geyma upplýsingarnar sem færðar eru inn í keðjuna og hægt er að spyrjast fyrir um þær frá keðjunni með getSmartCodeEvent aðferðinni.
Greinin var þýdd af ritstjórum Hashrate&Shares sérstaklega fyrir OntologyRussia.
Ertu verktaki? Vertu með í tæknisamfélaginu okkar á . Skoðaðu líka á vefsíðu okkar, þar sem þú getur fundið verkfæri fyrir þróunaraðila, skjöl og fleira.
Ontology
- /
- Telegram /
- /
Heimild: www.habr.com