Web3-Handhabung von Vertragsereignissen

Es scheint, dass es ein Problem mit der Behandlung von Vertragsereignissen gibt, und ich bin mir nicht sicher, ob es sich um die EVM-Ebene oder nur um web3js handelt.

Ich habe 2 Verträge "SomeCoin" und "SomeConcert". Beide Verträge geben ein "Transfer"-Ereignis aus, wenn ein Artikel von einer Adresse an eine andere übertragen wird. Bei „SomeCoin“ ist der Übertragungsgegenstand ein Coin/Token, bei „SomeConcert“ sind Konzertkarten (die in „SomeCoins“ bepreist sind) der Übertragungsgegenstand.

Wenn ich die „SomeConcert“-Methode aufgerufen habe, um Tickets zu kaufen, überträgt die Logik einige „SomeCoins“ von meiner Adresse an die „SomeConcert“-Adresse. Bis auf das Event-Handling ist alles schön und gut. Ich habe 2 Ereignisse gesehen, die vom Vertrag „SomeConcert“ und „Transfer“ vom Vertrag „SomeCoin“ gesendet wurden. Wenn ich das Ereignis „Transfer“ im Vertrag „SomeCoin“ in „TransferCoin“ umbenannt habe, sehe ich nur das Ereignis „Kaufen“.

Anscheinend verwechselt also entweder web3 oder die darunter liegende Schicht die Ereignisse, die vom Vertrag der inneren Schicht mit dem Vertrag der äußeren Schicht ausgegeben werden. Zu diesem Schluss bin ich zumindest gekommen.

Ist das ein web3js-Bug? Gibt es etwas, das ich bei der Ereignisbehandlung übersehen habe, das die Verwirrung hätte verhindern können? Der Code, den ich für die Ereignisbehandlung habe, ist eher Standard

... return someConcertInstance.buyTickets(3, {from: customer1}); }).then(function(receipt) { assert.equal(receipt.logs.length, 1, "should have received 1 events for buy-ticket)"); assert.equal(receipt.logs[0].args._numberOfTickets, 3, "Number of tix bought must be 3");

Der Testfall ist beim ersten Assertion fehlgeschlagen und ich habe herausgefunden, dass 2 Ereignisse ausgegeben werden (Transfer und Kauf).

Es wird erwartet, dass der Transaktionsbeleg zwei Protokolleinträge enthält, da in dieser Transaktion zwei Ereignisse protokolliert wurden. Es ist unerwartet, dass Sie nur einen Protokolleintrag sehen, wenn Sie eines der Ereignisse umbenennen. Vielleicht stimmt der Vertragscode nicht mit der von Ihnen verwendeten ABI überein?
Ich habe es überprüft und das ist tatsächlich das Verhalten.
Ich bin mir nicht sicher, was Sie bestätigen. Haben Sie eine Diskrepanz zwischen dem Vertragscode und dem ABI festgestellt?
ABI und Vertrag stimmen überein. Ich habe Truffle v4.1.5 verwendet und alles im Ordner "build" gelöscht, meinen testrpc neu gestartet, ein "Truffle compile --all" und "Trufflemigrate --reset" durchgeführt, obwohl der Truffle-Test eine Reinraumbereitstellung durchführen soll. Aber das Ergebnis bleibt - ich sehe die inneren Vertragsereignisse, wenn ich die gleiche Ereignissignatur beim äußeren Vertrag habe. Es scheint mir, dass es eine gewisse Logik gibt, wie Ereignisse in der Kette nach oben gesprudelt werden, und wahrscheinlich haben sie den Ereignisnamen zum Filtern verwendet. Ich frage mich, ob dies mit web3 oder etwas Grundlegenderem zu tun hat.
Wie gesagt, ich glaube, Sie sollten alle Protokolle sehen, die von Ihrer Transaktion generiert wurden. Die Tatsache, dass eines der Ereignisse basierend auf dem Namen des Ereignisses zu verschwinden scheint, scheint mir ein Fehler in web3.js zu sein ... meine beste Theorie ist, dass web3.js Ihnen nicht alle Protokolle gibt, sondern nur die diejenigen, die mit einer Signatur in der ABI übereinstimmen. Dies mag beabsichtigt sein, aber ich mag dieses Design nicht. :-)
Welche Version von web3.js verwenden Sie? Oder ist das Trüffel?
Ja, es ist entweder beabsichtigt (was ziemlich seltsam ist) oder ein Fehler. Meine Truffle ist 4.1.5 (neueste), die in der Truffle-Konsole angezeigte Web3-Version, wenn ich web3.version ausführe, ist 0.20.6.
Wenn dies tatsächlich Trüffel ist, dann sieht es so aus, als ob das Design meiner Hypothese entspricht: github.com/trufflesuite/truffle-contract/blob/develop/… . Ich würde empfehlen, ein Problem zu melden. Ich persönlich meide Trüffel.
Wenn Sie nur die Ereignisse verarbeiten möchten, die aus einem bestimmten Vertrag stammen, sieht es so aus, als ob sie ein addressFeld verfügbar machen, sodass Sie einfach danach filtern können.
Tut mir leid, ich habe gerade eine Änderung an einem deiner älteren Kommentare gesehen. Es sieht so aus, als wäre dies tatsächlich Trüffel, das ist also das Problem.
hat Truffle ein eigenes web3js? Lassen Sie mich versuchen, die Verträge auf Geth bereitzustellen und zu sehen, ob ich das gleiche Verhalten erhalte
Ich glaube, sie verwenden web3.js darunter, aber sie haben sicherlich ihren eigenen Vertragsgegenstand. (Siehe github.com/trufflesuite/truffle-contract. ) Ich glaube, dass web3.js 1.0.0-beta Protokollnachrichten ähnlich filtern kann , und ich glaube, dass web3.js 0.2xx überhaupt nicht versucht, die Protokollnachrichten zu analysieren (und somit bleiben sie intakt).

Antworten (1)

In den Kommentaren oben aussortiert und zu einer Antwort für zukünftige Leser übergegangen.

Der Code in der Frage verwendet truffle. Wenn Sie eine Transaktion in Trüffel senden, hat das Ergebnis, das Sie zurückerhalten, ein logsFeld, das über diesen Code zusammengestellt wird: https://github.com/trufflesuite/truffle-contract/blob/develop/contract.js#L44 .

Dieser Code verwirft Protokolle mit Themen, die keiner bekannten Ereignissignatur in der ABI des aufgerufenen Vertrags entsprechen. Ich halte dieses Verhalten für einen Designfehler.

Web3-Handhabung von Vertragsereignissen
AntwortenHierDatenschutz-Bestimmungen1y, 0v