geth stellt keine verbindung zum privaten netzwerk her

Ich betreibe eine private Blockchain und habe Paritätsknoten, die sich anscheinend gut verbinden. Ich habe zwar einige Geth-Probleme bekommen, die ich vorher hatte, aber Geth verbindet sich immer noch nicht.

JEDOCH, wenn ich mich vom selben Computer mit Parity verbinde, scheint es gut zu verbinden.

So rufe ich geth das erste Mal auf (nicht wirklich Port 9090, aber das ist zum Beispiel):

./geth --datadir /path/to/custom --networkid 9090 --port 9090 init CustomGenesis.json

Die CustomGenesis.json-Datei enthält Werte, die manuell aus meiner Parity-.json-Datei entnommen wurden, und ich habe erfolgreich eine Verbindung mit Parity hergestellt. Daher halte ich diese Werte für richtig. Ich habe die hier aufgeführten Elemente mit den Paritätswerten verwendet: https://github.com/ethereum/go-ethereum/wiki/Private-network

Ich habe auch eine Datei namens /path/to/custom/static-nodes.json, die die "enodes" von zwei vorhandenen Parity-Knoten auflistet.

AUCH habe ich (manchmal separat und manchmal zusätzlich zur Datei static-nodes.json) das Flag --bootnodes verwendet und die Enodes der Paritätsknoten in der Befehlszeile aufgelistet.

./geth --datadir /path/to/custom --networkid 9090 --port 9090 --ipcpath ~/.ethCustom/geth.ipc

Diese Dinge passieren / passieren jedoch nicht:

1) Meine anderen Knoten zeigen NICHT, dass ein neuer Knoten in das Netzwerk eingetreten ist

2) Wenn ich an die Konsole unter /path/to/custom/geth.ipc anhänge und "admin.peers" ausführe, bekomme ich einfach "[]"

3) AUSSER dass ich hin und wieder einen Peer bekomme, aber es ist keiner der Peers im benutzerdefinierten Netzwerk, sondern irgendein scheinbar zufälliger Knoten mit einem Port von 30303!! So seltsam! Warum würde 30303 mein benutzerdefiniertes Setup infiltrieren?

Aber wenn ich tippe

admin.nodeInfo

Ich bekomme eine sehr zufriedenstellende Ausgabe, die die richtige lokale Enode zeigt; derselbe (richtige) Port für "listenAddr", "Listener" und "Discovery", die richtige Netzwerk-ID und die richtige Schwierigkeit.

Was vermisse ich? Bitte teilen Sie mir mit, ob ich weitere Informationen liefern kann. Vielen Dank.

Ich weiß nicht, ob Sie dieses Problem gelöst haben, aber die Bereitstellung beider Genesis-Konferenzen ist hilfreich. Etwa 3) Es ist normal, weil 9090 IHR Überwachungsport ist, Sie zwingen andere Knoten nicht, diesen Port zu überwachen, also wählt jeder Peer seinen eigenen Port (und 30303 ist der Standardport). Sie sehen ein schnelles Erscheinen/Verschwinden, weil die Knoten sich gegenseitig überprüfen, um zu sehen, ob sie sich im selben Netz befinden, und in diesem Fall mit der Synchronisierung beginnen.
Wenn die Netzwerk-ID unterschiedlich ist, sollten sie nicht füreinander unsichtbar sein? Und wie genau "überprüfen sie sich gegenseitig, um zu sehen, ob sie im selben Netz sind?" Wenn ich das erfahre, erfahre ich vielleicht, warum sich meine Geth-Knoten nicht verbinden.
NetworkId ist eine der Informationen, die Peers sich gegenseitig geben, um zu überprüfen, ob sie an derselben Kette arbeiten (sie prüfen auch, ob sie denselben Genesis-Block haben). Sie MÜSSEN sich also sehen können, auch wenn sie auf verschiedenen Ketten sind, oder sie können diese Informationen überhaupt nicht überprüfen. (Wenn ich nicht mit dir sprechen kann, wie kann ich dann wissen, ob du meine Sprache sprichst?)
Nur zur Überprüfung: Paritätsknoten synchronisieren sich bereits und kontinuierlich? Es gibt mindestens einen Miner und Blöcke in der Kahin, und Sie erwarten nur, dass Geth wie andere Paritätsknoten synchronisiert wird, richtig?
@Giuseppe Bertone Noch kein Bergmann, aber ja, Paritätsknoten zeigen eine Verbindung zueinander. Und ja, ich erwarte, dass Geth eine Verbindung zu den anderen Paritätsknoten herstellt. Was Sie mir über die Genesis-Datei erzählen, sagt mir, dass das Problem vielleicht darin besteht, dass Geth die Paritätsknoten nicht erkennt, weil die Kettenspezifikation zu stark angepasst ist.

Antworten (1)

Was vermisse ich? Bitte teilen Sie mir mit, ob ich weitere Informationen liefern kann. Vielen Dank.

Markieren Sie Ihre Frage das nächste Mal mit Parität , um sicherzustellen, dass ich sie nicht verpasse: p

Clientübergreifende private Netzwerke: Das Problem

Geth ist ein Client, der für Ethereum geschrieben wurde. Es war eine der ersten offiziellen Referenzimplementierungen und sollte nie etwas anderes als Ethereum ausführen. Wenn Sie Geth für eine andere Kettenkonfiguration konfigurieren möchten, müssten Sie den Quellcode forken und Ihre eigene Client-Implementierung basierend auf Ihrem gewünschten Regelsatz erstellen. Dies geschah beispielsweise für Expanse ( Gexp ) und Ethereum Classic ( Getc ).

Parity wurde jedoch viel später als Ethereum selbst von einem Team entwickelt, das ursprünglich mit dem C++ Ethereum-Client ( Eth ) zu tun hatte. Nachdem sie (Gavin Wood, et al.) Ethcore (jetzt Parity) gegründet haben, haben sie einen Kunden mit einer viel breiteren Vision geschaffen, einen Kunden, der nicht nur Ethereum betreiben soll.

Parität ermöglicht mehr Abstraktion im Kern und daher brauchen Sie zum Starten einer neuen Kette nur eine sogenannte Kettenspezifikationsdatei , die die gesamten Kettenparameter beschreibt, einschließlich Konsensregeln, Validator-Engines und so weiter. Die sichtbarste Folge ist, dass Ethereum, Ethereum Classic und Expanse (um nur das obige Beispielformular aufzugreifen) keine eigene Kopie des Parity-Quellcodes pflegen müssen, um ihr Projekt und ihre Konsensregeln zu unterstützen. Die Parität funktioniert einfach sofort mit den --chainParametern foundation, classic, oder expanse.

Darüber hinaus ermöglicht der --chainParameter die Konfiguration einer vollständig benutzerdefinierten Kette mit austauschbarem Konsens, benutzerdefinierten Übergängen und der von Ihnen bevorzugten Validator-Engine.

Im Gegensatz dazu erlaubt Geth nur die Spezifikation einer benutzerdefinierten Genesis , die nur ein Teil des Puzzles für eine vollständige Kettenspezifikation ist. Und deshalb werden Sie Schwierigkeiten haben, einen Geth-Knoten mit einem benutzerdefinierten Netzwerk von Paritätsknoten zu verbinden. Sie haben jedoch grundsätzlich zwei Möglichkeiten, ein benutzerdefiniertes clientübergreifendes Netzwerk mit Geth- und Parity-Knoten zu betreiben, wie unten erläutert.

Best Practice: „Geth First“

Da Sie nun in Geth weniger Kettenkonfigurationsoptionen haben als in Parity, nenne ich die naheliegendste Idee "Geth First". Sie wählen eine Netzwerk-ID und erstellen eine benutzerdefinierte Genesis und initialisieren Ihr neues Netzwerk mit geth init. Sie können an dieser Stelle einen Miner-Thread und ein paar weitere Geth-Knoten starten, um zu überprüfen, ob das Netzwerk genau das ist, was Sie brauchen.

Jetzt können Sie mit der Integration von Paritätsknoten beginnen. Es gibt ein winziges Rost-Tool keorn/parity-spec , das Ihre benutzerdefinierte Geth-Genesis-Datei in eine vollständige Paritätsketten-Spezifikationsdatei konvertiert.

cargo run -- geth-genesis.json

Sie können die Ausgabe mit dem Parameter parity-spec.jsondirekt an Ihren Parity-Knoten übergeben. --chainFür die Erkennung können Sie die Befehle von Gethadmin.addPeer() oder die Funktionen von Parity--reserved-peers verwenden .

Sowohl Geth als auch Parity sind jedoch aktiv entwickelte Codebasen, und das Konvertierungstool ist anfällig für Fehler, und häufig berichten Benutzer, dass generierte Kettenspezifikationsdateien immer noch zu Konsensproblemen führen. Wenn Ihnen dies häufig passiert, sehen Sie sich die andere Option unten an.

Best-Practice: „Ropsten Revived – Revived“

Die wahrscheinlich stabilste und offensichtlichste Option, ein privates Netzwerk zu betreiben, das mit Geth, Parity und wahrscheinlich allen anderen Clients da draußen kompatibel ist, ist etwas, das ich "Ropsten Revived - Revived" nennen würde.

Nehmen Sie einfach ein bekanntes, funktionierendes Netzwerk, das von allen Clients unterstützt wird, wie das öffentliche Testnetz von Ropsten , und modifizieren Sie es leicht. Um diesen Vorgang zu vereinfachen, habe ich Voreinstellungen sowohl für die Genesis- als auch für die Parity-Chain-Spezifikation unter 5chdn/crossclient-chainsepc erstellt . Es enthält ein geth.jsonund ein parity.jsonRopsten-Revival mit der Netzwerk-ID 1337 ( 0x539).

Die Kehrseite davon ist wahrscheinlich der unbefriedigte Wunsch, Ihrem benutzerdefinierten privaten Entwicklungsnetzwerk komplexere Änderungen hinzuzufügen. Die vordefinierten Genesis- und Kettenspezifikationen bieten jedoch einen guten Ausgangspunkt, um Sie mit dem gewünschten Netzwerk zu booten.

Wow. Erstaunliche Antwort. Beantwortet so vieles. Vielen Dank.
geth stellt keine verbindung zum privaten netzwerk her
AntwortenHierDatenschutz-Bestimmungen1y, 0v