Útmutató az Ethereum intelligens szerződéseinek eseményeihez és naplóihoz

blog 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressHírlevelek

Iratkozzon fel hírlevelünkre.

Email cím

Tiszteletben tartjuk a magánéletét

HomeBlogBlockchain fejlesztés

Útmutató az Ethereum intelligens szerződéseinek eseményeihez és naplóihoz

Műszaki bevezetés az esetek és eseménynaplók használatához az Ethereum blokkláncon Joseph Chow mintakóddal 2016. június 6-án. Feladva: 2016. június 6.

ConsenSys Signal egy útmutató az eseményekhez és a naplókhoz az ethereum intelligens szerződések hősében

Az események és naplók azért fontosak az Ethereumban, mert megkönnyítik az intelligens szerződések és felhasználói felületeik közötti kommunikációt. A hagyományos webfejlesztés során a kiszolgáló válaszát a frontend felé történő visszahívás biztosítja. Az Ethereumban, amikor egy tranzakciót bányásznak, az intelligens szerződések eseményeket bocsáthatnak ki és naplókat írhatnak a blokkláncba, amelyeket azután a frontend feldolgozhat. Az események és a naplók kezelésére különféle módok vannak. Ez a technikai bevezetés elmagyarázza az eseményekkel kapcsolatos zavart és néhány mintakódot az eseményekkel kapcsolatban.

Az események zavaróak lehetnek, mert különböző módon használhatók fel. Előfordulhat, hogy az egyik egyik esemény nem hasonlít a másik eseményére. Az események és naplók 3 fő felhasználási esetet tartalmaznak:

  1. Intelligens szerződés-visszatérítési értékek a felhasználói felülethez
  2. Aszinkron kiváltó adatok
  3. A tárolás olcsóbb formája

Az események és a naplók közötti terminológia a zavarok másik forrása, és ezt a harmadik felhasználási esetben magyarázzuk el.

1) Intelligens szerződés-visszaküldési értékek a felhasználói felülethez

Az esemény legegyszerűbb használata, ha a szerződésekből származó visszatérési értékeket továbbítja az alkalmazás kezelőfelületének. Szemléltetésképpen itt van a probléma:

szerződés ExampleContract {// néhány állapotváltozó … függvény foo (int256 _érték) visszatér (int256) {// állapot manipulálása … return _érték; }} Kód nyelve: JavaScript (javascript)

Feltételezve, hogy a exampleContract egy példa az ExampleContract, a web3.js-t használó kezelőfelület a szerződés végrehajtásának szimulálásával hozhat visszaértéket:

var returnValue = exampleContract.foo.call (2); console.log (returnValue) // 2Kód nyelve: JavaScript (javascript)

Amikor azonban a web3.js tranzakcióként nyújtja be a szerződéses hívást, nem tudja megszerezni a visszatérési értéket [1]:


var returnValue = exampleContract.foo.sendTransaction (2, {from: web3.eth.coinbase}); console.log (returnValue) // tranzakció hashCode nyelv: JavaScript (javascript)

A sendTransaction metódus visszatérési értéke mindig a létrehozott tranzakció kivonata. A tranzakciók nem adják vissza a szerződés értékét a kezelőfelületnek, mert a tranzakciókat nem bányásszák azonnal és nem tartalmazzák a blokklánc.

Az ajánlott megoldás egy esemény használata, és ez az események egyik célja.

szerződés példaContract {event ReturnValue (indexelt cím _from, int256 _value); a foo függvény (int256 _érték) visszatér (int256) {ReturnValue (msg.sender, _value); return _value; }} A kezelőfelület ekkor megkapja a visszatérési értéket: var exampleEvent = exampleContract.ReturnValue ({_ from: web3.eth.coinbase}); exampleEvent.watch (function (err, result) {if (err) {console.log (err) return;} console.log (result.args._value) // ellenőrizze, hogy az result.args._from web3.eth.coinbase akkor // jelenítse meg a result.args._value értéket a felhasználói felületen, és hívja meg a // exampleEvent.stopWatching ()} példátContract.foo.sendTransaction (2, {from: web3.eth.coinbase}) Kód nyelve: JavaScript (javascript)

Ha a foo-ra hivatkozó tranzakciót bányászzák, az óra visszahívása elindul. Ez hatékonyan lehetővé teszi a frontend számára, hogy visszatérési értékeket szerezzen a foo-tól.

2) Aszinkron triggerek adatokkal

A visszatérési értékek az események minimális felhasználási esetei, és az eseményeket általában aszinkron triggereknek tekinthetjük az adatokkal. Amikor egy szerződés ki akarja váltani a kezelőfelületet, a szerződés eseményt bocsát ki. Mivel a kezelőfelület figyeli az eseményeket, műveleteket végezhet, üzenetet jeleníthet meg stb. Erre példa a következő szakaszban található (a felhasználói felület frissíthető, amikor a felhasználó befizet.)

3) A tárolás olcsóbb formája

A harmadik felhasználási eset teljesen eltér a lefedettségtől, és ez az eseményeket lényegesen olcsóbb tárolási formaként használja. Az Ethereum Virtual Machine (EVM) és Ethereum sárga könyv, az eseményeket naplóknak nevezik (vannak LOG opkódok). A tárolásról technikailag pontosabb lenne azt mondani, hogy az adatok naplókban tárolhatók, szemben az eseményekben tárolt adatokkal. Ha azonban egy szinttel meghaladjuk a protokollt, pontosabb azt mondani, hogy a szerződések olyan eseményeket bocsátanak ki vagy váltanak ki, amelyekre a frontend képes reagálni. Amikor egy esemény kiadódik, a megfelelő naplókat a blokkláncba írják. Az események és a naplók közötti terminológia további zavart okoz, mert a kontextus határozza meg, hogy melyik kifejezés pontosabb.

A rönköket olyan tárolási formának tervezték, amely lényegesen kevesebb gázba kerül, mint a szerződéses tárolás. A rönkök [2] bájtonként alapvetően 8 gázba kerülnek, míg a szerződéses tárolás 20 bájtba 20 000 gáz. Bár a rönkök óriási gázmegtakarítást kínálnak, a rönkök egyetlen szerződésből sem érhetők el [3].

Ennek ellenére vannak olyan esetek, amikor a naplókat olcsó tárolóként használják a kezelőfelület kiváltó okai helyett. A naplókra megfelelő példa a frontend által megjeleníthető előzményadatok tárolása.

Egy kriptovaluta-tőzsdénél érdemes megmutatni a felhasználónak az összes betétet, amelyet a tőzsdén teljesítettek. Ahelyett, hogy ezeket a betéti részleteket szerződésben tárolná, sokkal olcsóbb rönkként tárolni. Ez azért lehetséges, mert a tőzsdének szüksége van a felhasználó egyenlegének állapotára, amelyet szerződéses tárolóban tárol, de nem kell tudnia a korábbi betétek részleteiről.

szerződés CryptoExchange {event Deposit (uint256 indexelt _market, cím indexelt _sender, uint256 _amount, uint256 _time); function deposit (uint256 _amount, uint256 _market) visszatér (int256) {// befizetés végrehajtása, a felhasználói egyenleg frissítése stb. Deposit (_market, msg.sender, _amount, now); } Kód nyelve: JavaScript (javascript)

Tegyük fel, hogy frissíteni szeretnénk egy felhasználói felületet, amikor a felhasználó befizet. Íme egy példa egy esemény (Betét) aszinkron triggerként történő felhasználására az adatokkal (_market, msg.sender, _amount, now). Tegyük fel, hogy a cryptoExContract a CryptoExchange példánya:

var depositEvent = cryptoExContract.Deposit ({_ sender: userAddress}); depositEvent.watch (function (err, result) {if (err) {console.log (err) return;} // a result.args részleteinek hozzáfűzése a felhasználói felülethez}) Kód nyelve: JavaScript (javascript)

A felhasználó összes eseményének lekérdezésének hatékonyságának javítása az oka annak, hogy az esemény _sender paraméterét indexelik: event Deposit (uint256 indexelt _market, cím indexelt _sender, uint256 _amount, uint256 _time).

Alapértelmezés szerint az események hallgatása csak ott kezdődik, amikor az esemény példányos. A felhasználói felület első betöltésekor nincsenek hozzáfűzhető betétek. Tehát be akarjuk szerezni az eseményeket a 0 blokk óta, és ez egy fromBlock paraméter hozzáadásával történik az eseményhez.

var depositEventAll = cryptoExContract.Deposit ({_ sender: userAddress}, {fromBlock: 0, toBlock: ‘latest’}); depositEventAll.watch (function (err, result) {if (err) {console.log (err) return;} // a result.args részleteinek hozzáfűzése a felhasználói felülethez}) Kód nyelve: JavaScript (javascript)

A felhasználói felület renderelésekor a depositEventAll.stopWatching () függvényt kell meghívni.

Eltekintve – indexelt paraméterek

Legfeljebb 3 paraméter indexelhető. Például egy javasolt token szabvány rendelkezik az alábbiakkal: eseményátvitel (a cím indexelt _from, cím indexelt _to, uint256 _value). Ez azt jelenti, hogy a kezelőfelület hatékonyan figyelheti a token átviteleket, amelyek:

  • cím által küldött tokenContract.Transfer ({_ from: senderAddress})
  • vagy egy cím tokenContract.Transfer ({_ to: receiverAddress}) címre kapott
  • vagy egy cím által küldött egy adott címre tokenContract.Transfer ({_ from: senderAddress, _to: receiverAddress})

Következtetés

Három felhasználási esetet mutattak be az eseményekhez. Először is, egy esemény segítségével egyszerűen megkapja a visszatérési értéket a sendTransaction () által meghívott szerződéses függvényből. Másodszor, egy eseményt használva aszinkron triggerként adatokkal, amelyek értesíthetik a megfigyelőket, például egy felhasználói felületet. Harmadszor, egy esemény segítségével naplókat írhatunk a blokkláncba, mint olcsóbb tárolási formát. Ez a bevezetés bemutatta a API-k az eseményekkel való együttműködésért. Vannak egyéb megközelítések eseményekkel, naplókkal és nyugtákkal való munkához, és ezekre a témákra a későbbi cikkekben kerülhet sor.

Köszönet Aaron Davisnek, Vincent Gariepynek és Joseph Lubinnek a cikkre adott visszajelzésekért.

Hivatkozások

[1] A web3.js figyelhette, hogy a tranzakció bekerüljön-e a blokkláncba, majd visszajátszhatja a tranzakciót az EVM egyik példányában, hogy megkapja a visszatérési értéket, de ez jelentős mennyiségű logika, amelyet hozzá kell adni a web3.js-hez [2] A LOG művelethez 375, témánként 375 gázköltség tartozik, de ha sok bájtot tárolnak, ezek a költségek a tárolás összköltségének jelentéktelen hányadát jelentik.. [3] A Merkle naplókra vonatkozó igazolásai lehetségesek, így ha egy külső szervezet ilyen bizonyítékkal szállít szerződést, akkor egy szerződés igazolhatja, hogy a napló valóban létezik a blokkláncban.

Szeretne fejlesztői útmutatókat egyenesen a postaládájába?

Iratkozzon fel a ConsenSys fejlesztői hírlevelére

Iratkozzon fel hírlevelünkre a legfrissebb Ethereum hírekről, vállalati megoldásokról, fejlesztői erőforrásokról és egyebekről. E-mail cím Exkluzív tartalomHogyan készítsünk sikeres blokklánc terméketWebinárium

Hogyan készítsünk sikeres blokklánc terméket

Hogyan állítsunk be és futtassunk Ethereum csomópontotWebinárium

Hogyan állítsunk be és futtassunk Ethereum csomópontot

Hogyan készítsünk saját Ethereum API-tWebinárium

Hogyan készítsünk saját Ethereum API-t

Hogyan hozzunk létre közösségi tokentWebinárium

Hogyan hozzunk létre közösségi tokent

Biztonsági eszközök használata az intelligens szerződés-fejlesztésbenWebinárium

Biztonsági eszközök használata az intelligens szerződés-fejlesztésben

A pénzügyi eszközök digitális eszközei és a DeFi jövőjeWebinárium

A pénzügyek jövője: digitális eszközök és DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map