Ereignisverfolgung und -dekodierung von ethereumj

Ich habe ein Ereignis im Vertrag, und wenn das Ereignis ausgelöst wird, kann ich es von einem Java-Listener wie unten sehen

public void onTransactionExecuted(TransactionExecutionSummary summary) {
  List<LogInfo> listLogs= summary.getLogs();// This gives you list of log info
 // now Iterate and print the details
}

Beim Drucken des Login-Objekts bekomme ich so etwas wie LogInfo{address=cd5805d60bbf9afe69a394c2bda10f6dae2c39af, topics=[37637aa70af5cd14eda4054cc4323408c237c26de60d49064db916e476c29e2e 67fad3bfa1e0321bd021ca805ce14876e50acac8ca8532eda8cbf924da565160 ], data=000000000000000000000000cd2a3d9f938e13cd947ec05abc7fe734df8dd826}.

Ich weiß, dass es eine Art abi-codiert oder serialisiert ist, aber ich möchte entschlüsseln, welche Informationen ich in den Protokollen habe.

Antworten (3)

Um die Informationen in der LogInfo zu parsen, benötigen Sie die Vertrags-ABI. Sobald Sie die ABI haben, ist es einfach zu analysieren:

@Override
public void onTransactionExecuted(TransactionExecutionSummary summary) {
  String abi = "[{\"anonymous\":false,\"inputs\":[{\"indexed\":true,\"name\":\"from\",\"type\":\"address\"},{\"indexed\":true,\"name\":\"to\",\"type\":\"address\"},{\"indexed\":false,\"name\":\"amount\",\"type\":\"uint128\"}],\"name\":\"Transfer\",\"type\":\"event\"}]\n";
  for (LogInfo logInfo : summary.getLogs()) {
    CallTransaction.Contract contract = new CallTransaction.Contract(abi);
    CallTransaction.Invocation invocation = contract.parseEvent(logInfo);
    System.out.println(invocation);
  }
}

Ein Beispiel für die hier verwendeten Tests ist der Unit-Test DecodeLogTest

Ich arbeite an genau demselben Problem mit dem Eingabefeld von Ethereum-Transaktionen. Am nächsten komme ich dieser Erkenntnis in Gavin Woods Yellow Paper ( http://gavwood.com/paper.pdf ) unter Anhang 2; Rekursives Längenpräfix. Ich denke, dies ist die verwendete Formatierung, und in einigen Fällen funktioniert sie für das Eingabefeld von Transaktionen in der Kette, aber ich bin mir bei Ereignissen nicht sicher. Ich "sehe" ähnlich aus.

Thomas, ich konnte tatsächlich die Daten im Themenbereich sehen, der Keccak-codiert ist. Ich habe emn178.github.io/online-tools/keccak_256.html verwendet, um zu sehen, ob meine Daten indiziert sind und der Hash übereinstimmt. Aber anscheinend ist dies ein Weg. Angesichts des Hashs kann ich die Zeichenfolge nicht finden
Es ist definitiv ein Weg.

Vielleicht haben die Entwickler dies erkannt und ein Problem gestartet , ein Feature, das es lösen würde.

Allerdings habe ich folgendes gefunden.

Wenn Arrays (einschließlich String und Bytes) als indizierte Argumente verwendet werden, wird stattdessen der Sha3-Hash davon als Topic gespeichert.

Es gibt jedoch Hash-Test: Wie man eine Hash-Ausgabe erzeugt , in der erwähnt wird, dass Keccak und nicht das endgültige SHA3 verwendet wird. Der Wert in den obigen Themen erklärt also, was protokolliert wurde.

Ereignisverfolgung und -dekodierung von ethereumj
AntwortenHierDatenschutz-Bestimmungen1y, 0v