Im folgenden Blog wurde im allerletzten Absatz Folgendes Vitalik Buterinerwähnt:
Daher kann eine Zielblockzeit von 3 Sekunden (und eine tatsächliche Blockzeit von 5 Sekunden) durchaus praktikabel sein. Wie üblich werden wir zunächst konservativer sein und es nicht so weit treiben, aber eine Blockzeit von 12s scheint dennoch sehr gut erreichbar zu sein.
Ich bin mir nicht sicher, ob diese Aussage für den Proof-of-Authority-Konsens gilt. Bitte sehen Sie sich meine Beispieldatei CustomGenesis.json an .
Beim Proof-of-workKonsens ändert sich die Blockzeit dynamisch basierend auf dem Netzwerk, aber beim Proof-of-AuthorityKonsens ist die Blockzeit fest und wir können sie nicht ändern, nachdem die Blockzeit im Genesis-Block definiert wurde.
"clique": {
"period": 15,
"epoch": 30000
}
Zum Beispiel verwendet Rinkeby Ethereum Testnet Proof-of-Authority und seine Blockzeit beträgt 15 Sekunden.
Indem ich diesem Tutorial gefolgt bin, habe ich eine private Kette erstellt, die auf Proof-of-Authorityby using basiert clique consensus engine - proof-of-authority. Standardmäßig werden auch Blöcke von 15 Sekunden empfohlen. Das Problem besteht danach, wenn wir die Blockzeit für die Genesis-Datei festlegen, können wir sie in Zukunft nicht mehr ändern.
$ puppeth
...
How many seconds should blocks take? (default = 15)
> 15
Angenommen, wir haben ein privates Ethereum-Netzwerk mit guter Netzwerkverbindung.
[F] Was könnte die sicherste minimale Blockierungszeit sein, die verwendet werden kann, ohne Probleme mit dem Proof-of-Authority-Konsens zu haben?
Könnte ich beispielsweise 12 Sekunden oder sogar weniger (z. B. 5 Sekunden) für die Blockzeit verwenden, ohne dass es zu Problemen kommt? Wenn nein, mit welchen Problemen werde ich konfrontiert sein?
Vielen Dank für Ihre wertvolle Zeit und Hilfe.
PoA in Aura Consensus Engine of Parity ist standardmäßig auf 5s eingestellt , was getestet wurde, um mit guter Stabilität zu laufen. Das PoA-Netzwerk betreibt eine solche Infrastruktur.
Ich habe einen 1-Sekunden-PoA mit Aura getestet , der über 4 verschiedene geografische Regionen läuft. Dies ist das Minimum, das ich erfolgreich getestet habe :) Stabilitätstests in weiteren Regionen sind noch im Gange. Wird mit weiteren Informationen aktualisiert.
Stabilitätstest war erfolgreich. Es gab nur Probleme bezüglich der Zeitsteuerung, die Server müssen mit der gleichen Zeit synchronisiert werden. Nachdem dieses Problem behoben war, gab es keine Probleme mehr.
Die Hauptsache ist, dass sie alle eine synchronisierte Zeit haben müssen.
Ich persönlich finde 5s eine ordentliche Zeit für PoA und läuft ohne Probleme flüssig. Wenn Sie mehr über Aura erfahren möchten, lesen Sie Aura Consensus Protocol Audit .
Auraund Cliqueengine? Könnte ich auch 5 Sekunden für den PoA im Clique-Setup verwenden? @Ayushyacliqueund Paritätsunterstützungen aura.Sei es eine PoA-, PoW- oder PoS-Kette, die Sie aufbauen möchten, der wichtigste Punkt beim Timing ist, dass Ihre Knoten in der Lage sind, sich zu synchronisieren.
Wenn Ihr Netzwerk privat ist und Sie sicherstellen können, dass Ihr Netzwerk über Knoten mit riesigem Breitband und Ressourcen verfügt, können Sie die Blockzeit erheblich verkürzen.
Es hängt alles von der Infrastruktur ab, auf die sich Ihr Netzwerk stützt. Wenn Ihre verschiedenen Knoten über das weltweite Netzwerk kommunizieren, müssen Sie eine Blockzeit sicherstellen, die lang genug ist, um sicherzustellen, dass die verschiedenen Knoten Zeit haben, sich zwischen jedem Block zu synchronisieren.
Wenn Knoten damit nicht umgehen können, kann es zu unterschiedlichen Netzwerken kommen, da die Knoten in Konflikt geraten und sich möglicherweise gegenseitig ablehnen.
heinob