Geth-Parameter „networkid“ vs. Genesis-Block „chainId“-Konfiguration?

Ich habe ein privates Ethereum-Netzwerk mit einer benutzerdefinierten ChainId (z. B. 67890) eingerichtet, die im Konfigurationsteil der Datei genesis.json angegeben ist, habe Genesis.json gestartet und das private Netz zum Laufen gebracht. Dann sind mir jedoch einige seltsame Dinge aufgefallen, wie z.

Also habe ich einige Tests durchgeführt und herausgefunden, dass beim Ausführen von web3.eth.net.getNetworkType() privatenet zurückgegeben wird, aber wenn ich web3.eth.net.getId() ausführe, wird 1 zurückgegeben. Und nach einigem Fummeln fand ich es heraus dass ich eine --networkid 67890 im geth-Befehlszeilenparameter für web3.eth.net.getId() hinzufügen muss, um den korrekten Wert von 67890 zurückzugeben.

Meine Frage ist also, was ist der Unterschied zwischen der Angabe der networkid in der Geth-Befehlszeile und der Angabe der chainId in genesis.json? Ich dachte, die Netzwerk-ID und die Ketten-ID sind ein und dasselbe, und es scheint, dass web3 den Wert der Netzwerk-ID für den Standardwert der Transaktions-Ketten-ID verwendet, aber irgendwie, wenn ich geth ohne expliziten Netzwerk-ID-Parameter starte, ignoriert es die Ketten-ID-Konfiguration und Verwenden Sie weiterhin 1 als Standard, was zu einer anderen Netzwerk-ID als der Chain-ID führt.

Ist es also für eine Ethereum-Blockchain wirklich sinnvoll, dass sich die Netzwerk-ID und die Ketten-ID voneinander unterscheiden, oder handelt es sich um eine Art Fehler?

Antworten (1)

  1. Netzwerk-ID und Ketten-ID sind dasselbe

  2. NetworkIdSie können in eth/config.go& bearbeiten params/config.gound dieses Problem für immer beseitigen, Sie müssen es nicht network idmehr in der Befehlszeile angeben.

  3. Ethereum gethhat den Wert 1in den Dateien, die ich Ihnen gesagt habe, fest codiert, deshalb haben Sie diese Probleme.

  4. Das chain idist jetzt Teil der Transaktion als Ergebnis des Ethereum Improvement Proposal (EIP) #155, daher invalid senderwird das angezeigt, weil chain ides anders ist. Sie können dies mit EIP155BlockNum deaktivieren, aber Sie wären anfällig für Replay-Angriffe, wenn Sie mehrere Netzwerke verwenden, z. B. ein Testnet.

  5. chain idist nicht Teil des Hashs des Blocks, daher ist es wirklich nutzlos, ihn in der Genesis-Datei anzugeben. Stattdessen müssen Sie die ChainID im Quellcode oder mithilfe von Befehlszeilenparametern angeben.

Ich glaube nicht, dass ich Ihre Antwort vollständig verstehe, also meinen Sie, dass wir die chainId nicht in der genesis.json angeben sollten? dass es sinnlos ist, die chainId in der Genesis-Datei anzugeben? Warum wird dann ein ungültiger Absenderfehler zurückgegeben, wenn ich eine ChainId in der Genesis-Datei, aber nicht die Netzwerk-ID in der Geth-Befehlszeile angebe? Außerdem wird die Transaktion korrekt gesendet, wenn ich die ChainId in der Transaktion so angebe, dass sie mit der Genesis-Datei identisch ist. Es scheint also, obwohl web3.eth.net.getId() vom Parameter networkid abhängt, hängt web3.eth.sendSignedTransaction von der chainID in der Genesis-Datei ab?
Das ist richtig, Sie können das chainIDFeld in den Genesis-Block einfügen, aber die Blockchain-Datenbank speichert es nicht. chainIDist nur ein Parameter des gethQuellcodes, nicht der Datenbank. Das ist, was ich meine.
Jedoch wurde ein Jahr später bei Block 2675000 chainIDzur Transactions-Tabelle hinzugefügt, indem EIP155-Vorschlag zu hinzugefügt wurde geth. Dies ist die einzige Speicherung chainIDin der Datenbank.
Wenn Sie also Ihre private Kette konfigurieren, können Sie mit EIP155 oder ohne arbeiten. Ohne EIP155 brauchen Sie nichtchainID
Geben Sie adminin die Konsole ein, im protocolsAbschnitt können Sie das sehen network(das ist das chainID) und überprüfen, ob es richtig eingestellt ist
Ich bin immer noch ziemlich verwirrt über diese EIP155-Sache. Bei EIP155 müssen Sie also eine ChainId in Ihre Genesis-Datei einfügen, sodass Sie beim Senden der Transaktion sicherstellen müssen, dass der ChainId-Parameter mit dem in der Genesis-Datei angegebenen übereinstimmt. Es erzwingt jedoch nicht, dass die chainId in der Genesis-Datei mit der Netzwerk-ID von Geth übereinstimmt, sodass Sie möglicherweise in einer privaten Kette landen, in der web3.eth.getId() eine Zahl zurückgibt, während Sie eine andere Zahl eingeben müssen der chainId-Parameter in der Transaktion, damit er korrekt gesendet wird? Das klingt ziemlich seltsam, warum sollten sie das zulassen?
Liest wahrscheinlich bei der Blockchain-Initialisierung gethIhre genesis.json und speichert die ChainID intern in Parametern. Beim nächsten Start gethliest es die ChainID von dort. Aber chainIDes ist nicht Teil des Block-Hashes, also ist es nicht kryptografisch versiegelt, wenn jemand Ihre Datenbank kopiert und ändert chainID, wird alles gut mit einem anderen chainIDfunktionieren, es sei denn, EIP155 ist aktiviert. Wenn EIP155 aktiviert ist , erhalten gethSie invalid senderbei der Verarbeitung der ersten EIP155-aktivierten Transaktion einen Fehler
Ich denke, um zu verstehen, was ich meine, muss man eine Übung machen. Erstellen Sie 2 private Ketten. chainIdIn der ersten Kette werden Sie in der Genesis-Datei angeben . In der zweiten Kette löschen Sie diese Zeile und initialisieren sie, ohne die ChainID in der Genesis anzugeben. Sie werden feststellen, dass beide Blockchains genau gleich sind.
Ich habe auch die Antwort Nr. 5 bearbeitet, um sie verständlicher zu machen.
Was ich verwirrend finde, ist, wenn ich sage "chainId: 67890" in der Genesis-Datei angebe und geth starte, ohne den Code zu ändern oder die Netzwerk-ID zu setzen (so bleibt es als Standard 1), wenn ich web3.eth.net starte. getId() bekomme ich das Ergebnis als 1. Wenn ich versuche, eine Transaktion mit web3.eth.sendSignedTransaction zu senden, ohne die chainId anzugeben, wird "ungültiger Absender" gemeldet, aber wenn ich eine Transaktion mit web3.eth.sendSignedTransaction sende und die chainId als 67890, es wird erfolgreich sein. Das scheint eine ziemlich seltsame Situation zu sein.
Ich dachte, sie sollten einen Fehler oder so etwas melden, wenn Ihre netwokid in den Geth-Parametern und die chainId in der Genesis-Datei unterschiedlich sind, wenn Sie geth starten, aber anscheinend gibt es keinen Fehler beim Starten von geth, nur dass Sie beim Lesen von networkid mit web3 1 erhalten, Wenn Sie jedoch eine Transaktion mit web3 senden, müssen Sie 67890 als ChainId angeben. Warum sollten sie eine solche Situation zulassen, wenn networkid und chainId dasselbe sein sollen? Warum darf ich eine private Kette starten, bei der die Netzwerk-ID und die Ketten-ID tatsächlich unterschiedlich sind?
Nun, das ist eine Frage an die Ethereum Foundation.
Geth-Parameter „networkid“ vs. Genesis-Block „chainId“-Konfiguration?
AntwortenHierDatenschutz-Bestimmungen1y, 0v