Een gids voor evenementen en logboeken in slimme contracten van Ethereum

blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogBlockchain-ontwikkeling

Een gids voor evenementen en logboeken in slimme contracten van Ethereum

Een technische inleiding tot use cases voor evenementen en logboeken op de Ethereum-blockchain met voorbeeldcode door Joseph Chow 6 juni 2016 Gepost op 6 juni 2016

ConsenSys Signal een gids voor evenementen en logs in ethereum smart contracts hero

Gebeurtenissen en logboeken zijn belangrijk in Ethereum omdat ze de communicatie tussen slimme contracten en hun gebruikersinterfaces vergemakkelijken. Bij traditionele webontwikkeling wordt een serverreactie geleverd in een callback naar de frontend. In Ethereum kunnen slimme contracten, wanneer een transactie wordt gedolven, gebeurtenissen uitzenden en logboeken naar de blockchain schrijven die de frontend vervolgens kan verwerken. Er zijn verschillende manieren om gebeurtenissen en logboeken aan te pakken. Deze technische inleiding zal enkele bronnen van verwarring met betrekking tot gebeurtenissen verklaren en enkele voorbeeldcode om ermee te werken.

Gebeurtenissen kunnen verwarrend zijn omdat ze op verschillende manieren kunnen worden gebruikt. Een evenement voor de een lijkt misschien niet een evenement voor een ander. Er zijn drie belangrijke gebruiksscenario’s voor gebeurtenissen en logboeken:

  1. Smart contract-retourwaarden voor de gebruikersinterface
  2. Asynchrone triggers met gegevens
  3. Een goedkopere vorm van opslag

De terminologie tussen gebeurtenissen en logboeken is een andere bron van verwarring en dit zal worden uitgelegd in de derde use case.

1) Smart Contract Return-waarden voor de gebruikersinterface

Het eenvoudigste gebruik van een evenement is om retourwaarden van contracten door te geven aan de frontend van een app. Ter illustratie: hier is het probleem:

contract ExampleContract {// enkele toestandsvariabelen … functie foo (int256 _value) geeft (int256) {// manipuleer toestand … return _value; }} Codetaal: JavaScript (javascript)

Ervan uitgaande dat exampleContract een instantie is van ExampleContract, kan een frontend die web3.js gebruikt, een retourwaarde verkrijgen door de uitvoering van het contract te simuleren:

var returnValue = exampleContract.foo.call (2); console.log (returnValue) // 2Code taal: JavaScript (javascript)

Wanneer web3.js de contractoproep echter als een transactie indient, kan het de retourwaarde [1] niet verkrijgen:


var returnValue = exampleContract.foo.sendTransaction (2, {from: web3.eth.coinbase}); console.log (returnValue) // transactie hash Code taal: JavaScript (javascript)

De retourwaarde van een sendTransaction-methode is altijd de hash van de transactie die is gemaakt. Transacties geven geen contractwaarde terug aan de frontend omdat transacties niet onmiddellijk worden ontgonnen en opgenomen in de blockchain.

De aanbevolen oplossing is om een ​​evenement te gebruiken, en dit is een van de beoogde doeleinden voor evenementen.

contract ExampleContract {event ReturnValue (adres geïndexeerd _from, int256 _value); functie foo (int256 _value) geeft (int256) {ReturnValue (msg.sender, _value); winstwaarde; }} Een frontend kan dan de retourwaarde verkrijgen: var exampleEvent = exampleContract.ReturnValue ({_ from: web3.eth.coinbase}); exampleEvent.watch (function (err, resultaat) {if (err) {console.log (err) return;} console.log (result.args._value) // controleer of result.args._from web3.eth.coinbase is dan // toon resultaat.args._value in de gebruikersinterface en roep // exampleEvent.stopWatching ()}) exampleContract.foo.sendTransaction (2, {from: web3.eth.coinbase}) Codetaal: JavaScript (javascript)

Wanneer de transactie die foo oproept, wordt gedolven, wordt de callback in het horloge geactiveerd. Hierdoor kan de frontend effectief retourwaarden verkrijgen van foo.

2) Asynchrone triggers met gegevens

Retourwaarden zijn een minimaal gebruik van gebeurtenissen, en gebeurtenissen kunnen over het algemeen worden beschouwd als asynchrone triggers met gegevens. Wanneer een contract de frontend wil activeren, zendt het contract een gebeurtenis uit. Omdat de frontend naar gebeurtenissen kijkt, kan deze acties ondernemen, een bericht weergeven, enz. Een voorbeeld hiervan wordt gegeven in de volgende sectie (een gebruikersinterface kan worden bijgewerkt wanneer een gebruiker een storting doet).

3) Een goedkopere vorm van opslag

De derde use-case verschilt nogal van wat er is behandeld, en dat is het gebruik van evenementen als een aanzienlijk goedkopere vorm van opslag. In de Ethereum Virtual Machine (EVM) en Ethereum geel papier, gebeurtenissen worden logboeken genoemd (er zijn LOG-opcodes). Wanneer we het hebben over opslag, zou het technisch nauwkeuriger zijn om te zeggen dat gegevens kunnen worden opgeslagen in logboeken, in tegenstelling tot gegevens die worden opgeslagen in gebeurtenissen. Als we echter een niveau boven het protocol gaan, is het nauwkeuriger om te zeggen dat contracten gebeurtenissen uitzenden of triggeren waarop de frontend kan reageren. Telkens wanneer een gebeurtenis wordt verzonden, worden de bijbehorende logboeken naar de blockchain geschreven. De terminologie tussen gebeurtenissen en logboeken is een andere bron van verwarring, omdat de context bepaalt welke term nauwkeuriger is.

Houtblokken zijn ontworpen als een vorm van opslag die aanzienlijk minder gas kost dan contractopslag. Logboeken [2] kosten in principe 8 gas per byte, terwijl contractopslag 20.000 gas per 32 bytes kost. Hoewel logboeken gigantische gasbesparingen opleveren, zijn logboeken niet toegankelijk vanuit contracten [3].

Desalniettemin zijn er use-cases voor het gebruik van logboeken als goedkope opslag, in plaats van triggers voor de frontend. Een geschikt voorbeeld voor logboeken is het opslaan van historische gegevens die door de frontend kunnen worden weergegeven.

Een cryptocurrency-exchange wil een gebruiker misschien alle stortingen laten zien die ze op de exchange hebben gedaan. In plaats van deze depositogegevens in een contract op te slaan, is het veel goedkoper om ze als logboeken op te slaan. Dit is mogelijk omdat een beurs de staat van het saldo van een gebruiker nodig heeft, die het opslaat in contractopslag, maar niet hoeft te weten over details van historische stortingen.

contract CryptoExchange {event Deposit (uint256 geïndexeerd _market, adres geïndexeerd _sender, uint256 _amount, uint256 _time); functiestorting (uint256 _amount, uint256 _market) retourneert (int256) {// voer storting uit, update het saldo van de gebruiker, enz. Storting (_market, msg.sender, _amount, nu); } Codetaal: JavaScript (javascript)

Stel dat we een gebruikersinterface willen bijwerken terwijl de gebruiker geld stort. Hier is een voorbeeld van het gebruik van een gebeurtenis (Deposit) als een asynchrone trigger met gegevens (_market, msg.sender, _amount, nu). Stel dat cryptoExContract een instantie is van CryptoExchange:

var depositEvent = cryptoExContract.Deposit ({_ afzender: userAddress}); depositEvent.watch (function (err, resultaat) {if (err) {console.log (err) return;} // voeg details van result.args toe aan UI}) Code taal: JavaScript (javascript)

Het verbeteren van de efficiëntie van het ophalen van alle gebeurtenissen voor een gebruiker is de reden waarom de parameter _sender voor de gebeurtenis wordt geïndexeerd: event Deposit (uint256 geïndexeerd _market, adres geïndexeerd _sender, uint256 _amount, uint256 _time).

Standaard begint het luisteren naar gebeurtenissen pas op het moment dat de gebeurtenis wordt geïnstantieerd. Wanneer de gebruikersinterface voor het eerst wordt geladen, zijn er geen aanbetalingen om aan toe te voegen. We willen dus de gebeurtenissen sinds blok 0 ophalen en dat doen we door een parameter fromBlock aan de gebeurtenis toe te voegen.

var depositEventAll = cryptoExContract.Deposit ({_ sender: userAddress}, {fromBlock: 0, toBlock: ‘latest’}); depositEventAll.watch (function (err, result) {if (err) {console.log (err) return;} // voeg details van result.args toe aan UI}) Code taal: JavaScript (javascript)

Wanneer de gebruikersinterface wordt weergegeven, moet depositEventAll.stopWatching () worden aangeroepen.

Terzijde – Geïndexeerde parameters

Er kunnen maximaal 3 parameters worden geïndexeerd. Een voorgestelde tokenstandaard heeft bijvoorbeeld: event Transfer (adres geïndexeerd _from, adres geïndexeerd _to, uint256 _value). Dit betekent dat een frontend efficiënt kan kijken naar tokenoverdrachten die:

  • verzonden door een adres tokenContract.Transfer ({_ from: senderAddress})
  • of ontvangen door een adres tokenContract.Transfer ({_ to: receiverAddress})
  • of verzonden door een adres naar een specifiek adres tokenContract.Transfer ({_ from: senderAddress, _to: receiverAddress})

Gevolgtrekking

Er zijn drie use-cases gepresenteerd voor evenementen. Ten eerste, het gebruik van een gebeurtenis om eenvoudig een retourwaarde te krijgen van een contractfunctie die wordt aangeroepen met sendTransaction (). Ten tweede, het gebruik van een gebeurtenis als een asynchrone trigger met gegevens, die een waarnemer kan informeren, zoals een gebruikersinterface. Ten derde, het gebruik van een gebeurtenis om logboeken in de blockchain te schrijven als een goedkopere vorm van opslag. Deze inleiding heeft enkele van de API’s voor het werken met evenementen. Er zijn andere benaderingen aan het werken met gebeurtenissen, logboeken en ontvangstbewijzen en deze onderwerpen kunnen in toekomstige artikelen worden behandeld.

Met dank aan Aaron Davis, Vincent Gariepy en Joseph Lubin voor feedback op dit artikel.

Referenties

[1] web3.js kan kijken of de transactie wordt opgenomen in de blockchain, en vervolgens de transactie opnieuw afspelen in een instantie van de EVM om de geretourneerde waarde te krijgen, maar dit is een aanzienlijke hoeveelheid logica die moet worden toegevoegd aan web3.js [2] Er zijn gaskosten van 375 voor een LOG-bewerking en 375 gas per onderwerp, maar wanneer er veel bytes worden opgeslagen, vertegenwoordigen deze kosten een onbeduidend deel van de totale kosten van de opslag.. [3] Merkle-bewijzen voor logboeken zijn mogelijk, dus als een externe entiteit een contract met een dergelijk bewijs levert, kan een contract verifiëren dat het logboek daadwerkelijk in de blockchain bestaat.

Wil je gidsen voor ontwikkelaars rechtstreeks in je inbox?

Abonneer u op de nieuwsbrief voor ontwikkelaars van ConsenSys

Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.Hoe u een succesvol blockchain-product bouwtWebinar

Hoe u een succesvol blockchain-product bouwt

Hoe u een Ethereum-knooppunt instelt en uitvoertWebinar

Hoe u een Ethereum-knooppunt instelt en uitvoert

Hoe u uw eigen Ethereum-API kunt bouwenWebinar

Hoe u uw eigen Ethereum-API kunt bouwen

Hoe u een sociaal token maaktWebinar

Hoe u een sociaal token maakt

Beveiligingshulpmiddelen gebruiken bij slimme contractontwikkelingWebinar

Beveiligingshulpmiddelen gebruiken bij slimme contractontwikkeling

De toekomst van digitale activa en defiWebinar

De toekomst van financiën: digitale activa en 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