Lesen des Ledgers von der Etherscan-API im Vergleich zum Ausgeben von Ereignissen

Betrachten Sie die folgende Funktion aus einem Soliditätsvertrag:

function createProduct(uint _price, string memory _desc) public payable{ 
   emit UserLedgerUpdated(_desc, -1*int(msg.value));
}

Ich möchte, dass mein Dapp ein einfaches Hauptbuch wie das folgende anzeigt:

Created Shoes priced at 100 Wei for a Total Cost of 2345 Wei

Ich habe hier zwei Möglichkeiten:

  1. Fangen Sie das UserLedgerUpdatedEreignis in der Dapp

  2. Verwenden Sie die Etherscan-API , um die txn-Details abzurufen

Meine Fragen sind:

a) Wenn ich mich für Wahl 2 entscheide (dh txn-Details lesen), kann ich das Ausgeben von Ereignissen vermeiden. Da Ereignisse protokolliert werden und Platz belegen, würden sie Gas kosten und sind daher teurer als das kostenlose Lesen von txn-Details. Ist mein Verständnis richtig?

b) Beim Lesen der ethscan-API erhalte ich die Eingabe für die Funktion als Hex. Ich kann es verwenden web3.toAscii, um es in eine Zeichenfolge zu konvertieren, aber beachten Sie, dass das erste Argument der Funktion tatsächlich eine Zahl ist. Wenn ich daher Eingabedaten in Beispieltransaktion umwandle , erhalte ich {@Shoesanstelle von 123Shoes. Gibt es eine Möglichkeit, die Hex-Daten, die wir von der Ethrscan-API erhalten, richtig umzuwandeln?

Antworten (1)

  1. Ja, Sie sparen definitiv Gas, indem Sie keine Ereignisse ausgeben. Der Preis ist jedoch, dass Sie sich dann auf Etherscan verlassen, damit Ihr Dapp funktioniert. Wenn Etherscan ausgefallen ist, ist Ihr Dapp ausgefallen. Sie verlieren auch alle Benutzer, die Multisigs verwenden, da ihre Aufrufe zu diesem Vertrag niemals in den Transaktionen von Etherscan angezeigt werden (obwohl Etherscan auch interne Transaktionen bedient, sodass Sie dies möglicherweise umgehen können). Es verliert auch definitiv einen Aspekt seiner "Dappness", da es sich jetzt auf einen zentralisierten Dienst zum Lesen von Daten verlässt. Wenn Sie sich an Ereignisse halten, benötigen Benutzer nur Zugriff auf einen synchronisierten Knoten. Dies kann von Infura, einem anderen Knotenanbieter oder einem lokalen Knoten sein.
  2. Dies liegt daran, dass die 123 (7b) die priceVariable ist, die eine Zahl ist, keine Zeichenfolge, und 0x7B ist zufällig { in ASCII. Sie können die abi- und die tx-Daten der Funktion an die web3.eth.abi.decodeParametersFunktion übergeben, nachdem Sie die Funktionssignatur (die ersten 4 Bytes nach 0x) entfernt haben. Dadurch werden die decodierten Daten zurückgegeben.
Ich leihe mir den Begriff 'dappness' für den Rest meines Lebens aus :)
Welche Lösung wäre also stabil bei der Verwendung von Ether Scan API oder Subgraph oder Infura? Ich habe einen intelligenten Vertrag, um Ereignisse zu emittieren.
Lesen des Ledgers von der Etherscan-API im Vergleich zum Ausgeben von Ereignissen
AntwortenHierDatenschutz-Bestimmungen1y, 0v