Moonbase Alpha v2: New Contract Events and Pub / Sub

(Alberto Viera) (13. okt 2020)

Med utgivelsen av Moonbase Alpha v2 , som nettopp ble kunngjort av PureStake, legger vi til noen nye og spennende funksjoner som hjelper Moonbeam å komme nærmere sitt primære mål å tilby en sømløs opplevelse for prosjekter fra Ethereum på Polkadot-økosystemet. En av hovedfunksjonene som legges til er muligheten til å abonnere på Ethereum-smarte kontrakterhendelser og annen blockchain-informasjon.

Kontrakthendelser er en super viktig del av dApps i Ethereum, ettersom de letter kommunikasjonen mellom smarte kontrakter og brukergrensesnittene deres. Hendelser kan betraktes som asynkrone utløsere med data. Når en kontrakt sender ut en hendelse, kan dette deretter resultere i en handling på front-end-siden.

Use Cases for Events

Et enkelt eksempel på en hendelse du kan spore er en overføre. La oss si at en overføring initieres av en bruker ved hjelp av frontend på en dApp, der en transaksjonshash oppnås når denne er sendt inn. Men for å forsikre brukeren om at betalingen ble sendt, kan dApp lytte til en hendelse (gitt ut av kontrakten) når transaksjonen er forpliktet til blockchain. Dette kan følgelig utløse en skjermmelding til brukeren som varsler dem om at handlingen deres var vellykket.

En annen kraftig bruk av hendelser er billigere lagring. I gjennomsnitt koster logger 8 gass per byte, mens kontraktlagring koster 20 000 gass per 32 byte. Derfor kan hendelser tjene som et verktøy for å lagre og hente nødvendig informasjon som overføringslogger også. De kan imidlertid ikke brukes som lagring for alle brukstilfeller, fordi de for eksempel ikke har tilgang til andre smarte kontrakter.

Betydningen av pub / sub

Gitt all denne konteksten, er vi nå klare til å snakke om pub / sub.

Publish-subscribe, eller pub / sub for kort, er en asynkron meldingstjeneste som fungerer som mellomvare mellom utgivere av meldinger, og folk som abonnerer på dem. Generelt sett kategoriserer forleggere disse meldingene i klasser og publiserer dem uten egentlig å vite hvem som abonnerer på dem. På samme måte registrerer abonnenter seg i klassene som er av interesse, og mottar bare meldinger tilknyttet denne klassen, uten å vite hvem deres utgiver er.

Med utgivelsen av Moonbase Alpha v2 , en pub / sub-tjeneste som er kompatibel med Ethereum-stil-arrangementer er nå tilgjengelig.

Opplæring: Slik bruker du Pub / Sub på Moonbeam

Siden et bilde er tusen ord verdt, la oss hoppe inn i noen eksempler for å vise hvordan pub / sub fungerer på Moonbeam.

For å følge denne demoen trenger du følgende:

Abonnere på hendelseslogger i Moonbase Alpha v2

Enhver kontrakt som følger ERC-20-tokenstandarden, sender ut en hendelse relatert til overføring av tokens, det vil si event Transfer(address indexed from, address indexed to, uint256 value). For dette eksemplet vil vi abonnere på loggene til slike hendelser. Ved å bruke Web3 JS-biblioteket trenger vi følgende kode:

const Web3 = require("web3");
const web3 = new Web3("wss://wss.testnet.moonbeam.network");

web3.eth.subscribe("logs", {
address: "ContractAddress",
topics: ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
}, (error, result) => {
if (error)
console.error(error);
})
.on("connected", function (subscriptionId) {
console.log(subscriptionId);
})
.on("data", function (log) {
console.log(log);
});

Merk at vi kobler til WebSocket-sluttpunktet til Moonbase Alpha. Vi bruker metoden web3.eth.subscribe("logs", options [, callback]) for å abonnere på loggene, filtrert etter de gitte alternativene. I vårt tilfelle er alternativene kontraktens adresse der hendelsene sendes fra, og emnene som brukes til å beskrive arrangementet. Mer informasjon om emner finner du i (dette Medium innlegget). Hvis ingen emner er inkludert, abonnerer du til alle hendelser som sendes ut av kontrakten. Men for å kun filtrere overføringshendelsen, må vi inkludere signaturen til hendelsen, beregnet som:

EventSignature = keccak256(Transfer(address,address,uint256))

Resultatet av forrige beregning er det som er vist i kodebiten fra før. Vi kommer tilbake til filtrering etter emner senere. Resten av koden håndterer tilbakeringingsfunksjonen.Når vi har utført denne koden, får vi en abonnements-ID, og ​​terminalen vil vente på enhver hendelse gjennom dette abonnementet:

Deretter sendes en ERC20-tokenoverføring med følgende parametere:

  • Fra adresse: 0x6Be02d1d3665660d22FF9624b7BE0551ee1Ac91b
  • Til adresse: 0xfcB0B397BB28046C01be6A3d66c7Eda99Fb0f344
  • Verdi (tokens): 10000000000000000000 – det vil si 10 med

Når vi sender transaksjonen, vil loggen over hendelsen som sendes ut av transaksjonen vises i terminalen:

Mye informasjon blir gitt i loggene, men du kan spørre deg selv: hvor er informasjonen i den sendte hendelsen? Og svaret er: i loggene!

Vår målhendelse sender to stykker indeksert informasjon, «fra» og «til» adressene (i den rekkefølgen), som behandles som emner. Den andre dataen som deles av arrangementet vårt, er antall tokens som ikke er indeksert. Derfor er det totalt tre emner (maksimum er fire), som tilsvarer opkoden LOG3:

Derfor kan du se at «fra» og «til» adressene er inneholdt i emnene som returneres av loggene. Ethereum-adresser er 40 sekskantede tegn (1 sekskanttegn er 4 bits, derav 160 bits eller H160-format). Dermed trengs de 24 ekstra nullene for å fylle gapet til H256, som er 64 sekskantede tegn.

Hva med antall tokens? Uindeksert data returneres i «data» -feltet i loggene, men dette er kodet i bytes32 / hex. For å avkode det kan vi for eksempel bruke dette onlineverktøyet , og verifisere at «dataene» faktisk er 10 (pluss 18 nuller).

Hvis hendelsen returnerer flere uindekserte verdier, legges disse til hverandre i samme rekkefølge som hendelsen sender dem ut. Derfor blir hver verdi deretter oppnådd ved å dekonstruere data i separate 32 byte (eller 64 heks tegn lange) brikker.

Dette eksemplet viste hvordan vi bare kunne abonnere på hendelseslogger for en spesifikk kontrakt. Men Web3 JS-biblioteket tilbyr andre abonnementstyper som vi vil gå gjennom i de følgende avsnittene.

Abonner på innkommende ventende transaksjoner

For å abonnere på ventende transaksjoner, kan vi bruke web3.eth.subscribe("pendingTransactions", [, callback]) -metoden, og implementerer den samme tilbakeringingsfunksjonen for å se etter svaret. Dette er mye enklere enn vårt forrige eksempel, og det returnerer transaksjonshashen av de ventende transaksjonene.

Vi kan bekrefte at denne transaksjonshashen er den samme som den som vises i MetaMask (eller Remix).

Abonner på innkommende blokkoverskrifter

En annen type tilgjengelig under Web3 JS-biblioteket er å abonnere på nye blokkoverskrifter. For å gjøre dette bruker vi web3.eth.subscribe("newBlockHeaders" [, callback]) -metoden, og implementerer den samme tilbakeringingsfunksjonen for å se etter svaret. Dette abonnementet inneholder innkommende blokkoverskrifter og kan brukes til å spore endringer i blokkjeden.

Merk at bare en blokkoverskrift vises i bildet. Disse meldingene vises for hver produserte blokk, slik at de kan fylle opp terminalen ganske raskt.

Kontroller om noden er synkronisert med nettverket

Med pub / sub er det også mulig for å sjekke om en bestemt node, som du abonnerer på, for øyeblikket er synkronisert med nettverket. For det kan vi utnytte web3.eth.subscribe("syncing" [, callback]) -metoden og implementere den samme tilbakeringingsfunksjonen for å se etter svaret. Dette abonnementet returnerer et objekt når noden synkroniseres med nettverket.

Nåværende begrensninger

Pub / sub-implementeringen i Frontier er fortsatt i aktiv utvikling. Denne første versjonen lar dApp-utviklere (eller brukere generelt) abonnere på spesifikke hendelsestyper, men det er fortsatt noen begrensninger. Fra de forrige eksemplene har du kanskje lagt merke til at noen av feltene ikke viser riktig informasjon, og det er fordi visse egenskaper ennå ikke skal støttes av Frontier.

En annen begrensning er relatert til loggene til begivenhet. På Ethereum kan du bruke jokertegn og sende inn flere inngangsadresser, for eksempel for å filtrere spesifikke logger. La oss si at vi vil abonnere på alle hendelser i en kontrakt som har to spesifikke adresser i feltet «topic\_1» (husk at topic\_0 er reservert for hendelsessignaturen).Så kunne vi sende inn følgende emne som input:

topics: [null, [address1, address2]]

Her, ved å bruke jokertegnet null på plass for hendelsessignaturen lytter vi til alle hendelsene som sendes ut av kontrakten vi abonnerte på. Men med denne konfigurasjonen kan vi også bruke et andre inndatafelt, det vil si topic\_1, for å definere et filter etter adresse som nevnt før.

Den nåværende Frontier implementering støtter ikke disse funksjonene. Som et alternativ kan du opprette flere abonnementer for alle hendelsene i kontrakten og de forskjellige adressene, men dette øker antall operasjoner som skal utføres. Dette forventes imidlertid å støttes i fremtidige versjoner av Moonbase TestNet.

Kontakt oss

Hvis du har noen tilbakemeldinger angående Moonbase Alpha v2, pub / sub eller andre Moonbeam-relatert emne, vær så snill å besøk vår nettside eller nå ut gjennom vår offisielle utvikling Discord-server .

Opprinnelig publisert på https://www.purestake.com 13. oktober 2020.