Ethereum (ETH)²

[chip]

Was würde dieser heftige Fehler denn für ETH insgesamt bedeuten? Wenn ich hier lese, dass im Fehlerfalle alle ETHs weg sind bei Geth...

[mahatma]

so wie ich das verstanden habe würde die blockchain und das ökosystem an sich weiterlaufen. viele eth geburnt werden. (wird in dem artikel ja vorgerechnet)

das grundsätzliche problem würde bleiben, das mit dem Übergang auf PoS ein komplexes Monster geschaffen wurde, um den "PoW-Einzeiler" von vor der Umstellung zu ersetzen und halbwegs dezentralität beizubehalten.

Dieses Monster fehlerfrei am laufen zu halten scheint langfristig schwierig bis nicht möglich.

So wie ich das sehe wäre die einzige Lösung das sich geth zu nem richtig stabilen Client entwickelt UND es noch mindestens nen zweiten, richtig stabil laufenden Client geben wird. Wenn das einfach zu erreichen wäre, wäre man denk ich schon soweit.

Kann sich jeder selber überlegen was das bedeutet. 

imho wird es zu eth verkäufen führen, wenn die blockchain nen vertrauensverlust und massiv schlechte news erfährt (wie zB der grossteil aller gestakeden ether geht verloren).

was das für mich bedeuten wird:

- eth bestand reduzieren und zT in potentielle eth-killer reinvestieren. am besten vor dem nächsten bullrun.

- bei erc-20 shitcoin tokens aufräumen. 

 

 

[skunk]

Oh es passieren noch Zeichen und Wunder. Meine Erigon Node hat sich tatsächlich gefangen. [INFO] [01-31|09:31:54.092] [4/12 Execution] Unwind done             in=3h27m28.849141842s

Erigon hat nach der Fehlermeldung dieses mal automatisch die Blockchain zurück gedreht und ist jetzt damit beschäftigt die Scherben zu beseitigen. Es wird noch einige Stunden dauern aber mit etwas Glück habe ich dann endlich wieder eine funktionierende Erigon Node.

vor einer Stunde schrieb chip:

Was würde dieser heftige Fehler denn für ETH insgesamt bedeuten? Wenn ich hier lese, dass im Fehlerfalle alle ETHs weg sind bei Geth...

Ich würde die Frage in zwei Teile unterteilen. Da wäre einmal die Frage was bedeutet es für deinen fiktiven Validator im Fehlerfall auf Geth angewiesen zu sein? Und dann wäre noch die Frage welche Auswirkungen es für das komplette Netzwerk hätte.

Für deinen fiktiven Validator ist die Lage recht klar. Im Fehlerfall wird dein fiktiver Geth Validator mit allen anderen Geth Validatoren einer Meinung sein. 2/3 Mehrheit ist erreicht und der fehlerhafte Block erhält Finality. Es kommt zum klassischen Hardfork. Alle Geth Clients nehmen eine falsche Abzweigung und folgen ab jetzt der falschen Chain mit einem oder auch mehreren fehlerhaften Blöcken. Die anderen Clients im Netzwerk folgen derweilen der richtigen Chain, die diese fehlerhaften Blöcke abgewiesen hat. Ihnen fehlt die 2/3 Mehrheit und Finality bleibt aus. Ohne Finality gehen die Strafen in die Höhe. All die Geth Nodes werden dafür bestraft eine falsche Abzweigung genommen zu haben. Es gibt für deinen fiktiven Validator nur zwei Möglichkeiten:

1. Du bekommst Zeitnah Kenntnis von dem Hardfork zum Beispiel in dem du im etherstake Discord Channel auf entsprechende Ankündigungen achtest.
2. Du bekommst vergleichsweise spät Kenntnis von dem Hardfork und hast zu dem Zeitpunkt bereits massive ETH verbrannt. Es reicht auch nicht einfach nur rechtzeitig Kenntnis zu erhalten. Du müsstest deiner Geth Node noch irgendwie erklären die falsche Chain zu vergessen und wieder der richtigen Chain zu folgen. Das ist im Zweifel nicht so einfach und wird dich mehrere Stunden bis hin zu Wochen kosten. Genug Zeit mehr deiner ETH zu verbrennen.

Nun betrachtet wird das aus Sicht des Netzwerks. Mit Bekanntwerden des Hardforks werden Typen wie ich sofort losrennen und unsere ETH Bestände auf beiden Blockchains auf unterschiedliche Adressen senden. Dazu muss ich mich nur einmal mit einer Geth Node verbinden und dort meine Bestände von A nach B umbuchen. Meiner lokalen Erigon Node sage ich sie soll meine Bestände von A nach C umbuchen. Kannst du schon erahnen wo die Reise hingeht? Ich werde versuchen die nun doppelt vorhandenen Bestände auf beiden Chains zu verkaufen. Ich muss nur rausfinden welches Exchange welcher Chain folgt. Das lässt sich mit kleinen Test Deposits recht schnell austesten. So und ab diesem Zeitpunkt lehne ich mich dann zurück und genieße die Show. Ich besorge mir etwas Popcorn und Platziere meine Wetten welche Chain wohl gewinnen wird. Kann eine Exchange eigentlich to Big to Fail sein? Ich würde Wetten die angeblich so unantastbare Blockchain wird plötzlich einer größeren Änderung unterworfen, die wir alle eigentlich für undenkbar hielten. Exakt so wie damals beim DAO Desaster. Wird sich ETH davon nochmal erholen können?

[chip]

Mist, ich hatte naiverweise immer geglaubt (also vor der Umstellung auf PoS), dass ETH als zweitgrößter Coin recht zuverlässig und sicher ist (klar, es gab schon vorher mal Probleme, aber nicht in den beiden Jahren vor der Umstellung, wenn ich mich nicht irre). Die Umstellung verlief ja auch erstaunlich glatt. Jetzt dieses mögliche Desaster hier - ich habe nicht gestaked und überlege, ob ich nicht in eine andere Chain wechsle. Solana kommt mir in den Sinn (klar, auch da gibt es enorme Risiken). Oder dann doch "konservativ" einfach in den BTC. Bei dem passt mir der Energiebedarf aber überhaupt nicht, das geht heute eigentlich nicht mehr...

Denn eins ist wohl relativ sicher: Wenn es tatsächlich Verluste bei Geth gibt, und dann ja immer Komplettverluste, dann hat ETH seinen Ruf erstmal ruiniert, meine ich. Das dürfte ordentlich Verkaufssignale aussenden, gerade auch bei den großen Investoren (Wale und Institutionen). Hmmmmmm... Ich frage mich, ob die große Masse sich des Problems bewusst ist. Kann ich irgendwie nicht so recht glauben - ich habe auch nur hier davon erfahren (bin aber nicht so viel unterwegs anderswo).

[skunk]

vor 5 Minuten schrieb mahatma:

was das für mich bedeuten wird:

- eth bestand reduzieren und zT in potentielle eth-killer reinvestieren. am besten vor dem nächsten bullrun.

Kurzfristig Ja. Langfristig haben die doch aber alle das gleiche Risiko oder nicht? ETH geht mit dem Risiko nur offen um und mach es transparent.

[mahatma]

vor 3 Stunden schrieb skunk:

Du müsstest deiner Geth Node noch irgendwie erklären die falsche Chain zu vergessen und wieder der richtigen Chain zu folgen. Das ist im Zweifel nicht so einfach und wird dich mehrere Stunden bis hin zu Wochen kosten.

Geht das? Hab den von ngt Artikel dahingehend verstanden, dass man da gar keine Wahl hätte und das wohl oder über aussitzen müsste...

Zitat

In essence, the validators running Geth have committed to the invalid chain and are locked into that chain until the non-Geth chain finalises. This is the critical risk that many misunderstand.

Because the Geth validators are stuck on the invalid chain, they are considered inactive on the non-Geth chain and will suffer the inactivity leak. No software update or bug patch to Geth will save these validators. They will be bled out until their stake represents < ⅓ of the network, allowing the non-Geth chain to finalise.

oder hab ich da was falsch verstanden?

 

vor 2 Stunden schrieb skunk:

Kurzfristig Ja. Langfristig haben die doch aber alle das gleiche Risiko oder nicht? ETH geht mit dem Risiko nur offen um und mach es transparent.

ja, bin ich ganz bei dir. Hatten wir vor Jahren schon mal ausführlich diskutiert, als es um POW vs POS ging. War damals schon der Meinung das das ganze POS gedöns ein grosser Poker ist und noch nicht gezeigt wurde das sowas überhaupt klappen kann. Wohlgemerkt bei der Bedingung, dass das Netz echt DEZENTRAL bleibt! Gibt man die Dezentralität auf gibts keine Probleme. Selbst ETH hat ja mit dem Trennen von Validatoren und Executoren schon kleine Abstriche bei der Dezentralität hingenommen.

Mir persönlich ist das Latte. Mir gehts drum im Bullenmarkt meine BTC zu vermehren und obendrein noch echtes Geld (haha) abzuschöpfen. Das halte ich mit den vielen neuen POS und Smart Contract Coins für sehr gut möglich. Ich werde versuchen keine kritischen Mengen von irgendwas über mehrere Zyklen zu halten, einzige Ausnahme ist BTC, noch sehe ich Bitcoin als gekommen um zu bleiben an.

Gründe: Der einzige echt dezentrale Coin, der das Problem der echt zufälligen Auswahl des nächsten Blockerstellers elegant und sicher gelöst hat, bereits 15 Jahre Bewährungsprobe hinter sich hat, und mittlerweile den Weg in die Finanzwelt gefunden hat. 

 

 

Am 8.5.2022 um 08:50 schrieb mahatma:

Ich persönlich halte eine echt dezentrale PoS Lösung für sehr schwer umzusetzen, und würde da tendenziell Ethereum den grössten Entwicklungsstand zuschreiben, einfach aufgrund seiner Rolle im Markt und der Dauer mit der bereits intensivst daran gearbeitet wird. Alleine wie oft Deadlines und Timelines hier verschoben wurden ist ein guter Hinweis darauf, wie schwer die Sache ist. Der ganze Rest sind Hypes, super um zu Zocken, aber Vorsicht mim feuchten Traum des Long-Term-Investments.

 

 

[PeWi]

53 minutes ago, mahatma said:

Geht das? Hab den von ngt Artikel dahingehend verstanden, dass man da gar keine Wahl hätte und das wohl oder über aussitzen müsste...

Quote

In essence, the validators running Geth have committed to the invalid chain and are locked into that chain until the non-Geth chain finalises. This is the critical risk that many misunderstand.

Because the Geth validators are stuck on the invalid chain, they are considered inactive on the non-Geth chain and will suffer the inactivity leak. No software update or bug patch to Geth will save these validators. They will be bled out until their stake represents < ⅓ of the network, allowing the non-Geth chain to finalise.

oder hab ich da was falsch verstanden?

Das habe ich beim - zugegebenernmaßen - schnellen Lesen des Artikels auch nicht verstehen.

Angenommen, für den hypothetischen Geth-Fehler kommt genauso ein Patch nach 4h. Müsste Geth beim Wiederanlaufen nicht ebenso die fehlerhaften Blöcke erkennen und beim letzten gültigen wiederaufsetzen? Warum ist Geth auf der fehlerhaften Chain gefangen?

[skunk]

vor 52 Minuten schrieb mahatma:

oder hab ich da was falsch verstanden?

Das hast du richtig verstanden. Einfach nur Updaten reicht nicht aus weil die bereits erreichte Finality eine automatische Korrektur eigentlich unmöglich macht. Was aber möglich wäre ist die Blockchain einfach komplett lokal zu löschen und nochmal bei 0 zu beginnen mit einem Client der an der entscheidenden Kreuzung nicht die falsche Abzweigung nimmt und dann weiter der richtigen Chain folgt. Da sprechen wir dann aber von Tagen in denen fleißig weiter ETH verbrannt wird.

vor einer Stunde schrieb PeWi:

Angenommen, für den hypothetischen Geth-Fehler kommt genauso ein Patch nach 4h. Müsste Geth beim Wiederanlaufen nicht ebenso die fehlerhaften Blöcke erkennen und beim letzten gültigen wiederaufsetzen? Warum ist Geth auf der fehlerhaften Chain gefangen?

Bei PoW gewinnt die längste Chain. Die längste Chain hat automatisch die höchste Hashpower und ist zugleich die Absicherung gegen einen 51% Angriff.

Bei PoS geht das so nicht. Wenn ich wollte könnte ich nach beliebig viele Blöcke einfach neu generieren. Das Konzept die längste Chain gewinnt immer, greift hier nicht mehr. Stattdessen gewinnt hier immer die Chain, die von mindestens 2/3 der Validatoren als Final anerkannt wurde. Wenn nach 4 Stunden ein Patch kommt, dürfen die Validatoren die Blöcke, die bereits Finality erreich haben, eigentlich nicht mehr anfassen. Sollte der Patch Code enthalten, der ihnen das doch erlaubt, wäre das zugleich ein Bruch mit der eigentlichen Konsensus Regeln. Soll heiße als nächstes wäre ein 51% Angriff denkbar in dem ein Angreifer erst von der Mehrheit der Validatoren eine Transaktion bestätigen lässt und dann im Nachgang nutzt er die eingebaute Ausnahme in den Geth Clients einfach ein weiteres mal aus. Die Büchse der Pandora sollten wir vielleicht besser geschlossen lassen.

vor 57 Minuten schrieb mahatma:

Mir persönlich ist das Latte. Mir gehts drum im Bullenmarkt meine BTC zu vermehren und obendrein noch echtes Geld (haha) abzuschöpfen. Das halte ich mit den vielen neuen POS und Smart Contract Coins für sehr gut möglich. Ich werde versuchen keine kritischen Mengen von irgendwas über mehrere Zyklen zu halten, einzige Ausnahme ist BTC, noch sehe ich Bitcoin als gekommen um zu bleiben an.

Willkommen im Club. Ich zerbreche mir darüber auch schon die ganze Zeit den Kopf und komme doch nicht zu einem befriedigenden Plan. Auf der einen Seite hat das Danksharding Update durchaus Potential. Dummerweise ist das Mainnet Release in etwa zeitgleich mit dem BTC Halving. Bisher ist mir der mögliche Gewinn von aktuell 0,055 BTC hoch auf 0,08 BTC etwas zu gering. Und bei 0,08 BTC waren wir bereits bei einem beachtlichen Marketcap was mir unrealistisch hoch vorkam. Mir wäre es lieber der ETH fällt nochmal in Richtung 0,04 BTC. Dann würde mir die Entscheidung etwas leichter fallen.

[PeWi]

42 minutes ago, skunk said:

Stattdessen gewinnt hier immer die Chain, die von mindestens 2/3 der Validatoren als Final anerkannt wurde. Wenn nach 4 Stunden ein Patch kommt, dürfen die Validatoren die Blöcke, die bereits Finality erreich haben, eigentlich nicht mehr anfassen. Sollte der Patch Code enthalten, der ihnen das doch erlaubt, wäre das zugleich ein Bruch mit der eigentlichen Konsensus Regeln.

Laut Artikel gibt es das "große" Problem aber nur, wenn Geth einen Fehler derart hätte, dass ungültige Blöcke finalisiert würden.

Where things get bad is if the bug results in a validator producing an invalid block, and Geth accepts it as valid and attests to it. This will result in a fork in the chain. The chain will split into 1 fork with the invalid block (Geth chain) and another fork where the invalid block is ignored (non-Geth chain). The validators running Geth will consider both forks valid and therefore will decide to build on the heaviest chain.

Mir leuchtet nicht ein, dass auch eindeutig ungültige Blöcke in die Finalisierungsheiligkeit einbezogen sind. (Die anderen Clients erkennen sie ja auch nicht an und bauen deswegen ab dieser Stelle ihre eigene Kette weiter.)

Warum muss ein Geth-Client auch nach dem Neustart nach dem Patch diese regelverstoßenden Blöcke weiterhin anerkennen?

Bearbeitet 31. Januar von PeWi

[skunk]

vor 1 Minute schrieb PeWi:

Warum muss ein Geth-Client auch nach dem Patch diese regelverstoßenden Blöcke weiterhin anerkennen?

Weil der Teil mit der Finality außerhalb von Geth liegt. Es gibt hier zwei Prozesse die ineinander greifen. Einmal die Beacon Node und dann Geth selbst. Die Beacon Node würde auch nach dem Patch auf der falschen Chain bleiben einfach weil genau das im Protokoll so vorgesehen ist. Es gibt für Geth keine Funktion mit der es die Beacon Node überzeugen könnte das Protokoll zu verletzten und den Finality Zustand zu vergessen.

Die einzige Option ist hier die Beacon Node per Komandozeile zurück zu setzen. Sofern dieser Fall überhaupt vorgesehen ist. Im schlimmsten Fall hilft sonst nur Beacon Chain wegschmeißen und neu Syncen. Dauert nur einige Tage.

[PeWi]

6 minutes ago, skunk said:

Weil der Teil mit der Finality außerhalb von Geth liegt. Es gibt hier zwei Prozesse die ineinander greifen. Einmal die Beacon Node und dann Geth selbst. Die Beacon Node würde auch nach dem Patch auf der falschen Chain bleiben einfach weil genau das im Protokoll so vorgesehen ist. Es gibt für Geth keine Funktion mit der es die Beacon Node überzeugen könnte das Protokoll zu verletzten und den Finality Zustand zu vergessen.

D.h. die Beacon Node prüft selber nicht und verlässt sich vollkommen darauf, dass von anderen finalisierte Bläcke schon stimmen werden?

Ist das dann nicht eine Verletzung des Blockchain-Matras "don't trust, verify!"?

Und: Betrifft das dann die Nicht-Geth-Validatoren nicht gleichermaßen, wenn die Beacon Node auf einer falschen Chain sitzt?

[skunk]

vor 1 Minute schrieb PeWi:

D.h. die Beacon Node prüft selber nicht und verlässt sich vollkommen darauf, dass von anderen finalisierte Bläcke schon stimmen werden?

Die Beacon Node fragt geth kurz bevor es darum geht dem fehlerhaften Block zuzustimmen. Wir haben hier eine Aufgabenteilung. Geth validiert die Blöcke und die Beacon Node kümmert sich darum die 2/3 Mehrheit für Finality zu erzielen. Die Beacon Node wird ihre Zustimmung verweigern wenn Geth den Block als fehlerhaft abweist. Da Geth aber Anfangs vor dem Patch fälschlicherweise sein Ok gegeben hatte, ist der Punkt bereits überschritten. Nach dem Patch ist es der Beacon Node egal was Geth gerne hätte. Die 2/3 Mehrheit besagt laut Protokoll, dass dieser invalide Block teil der Blockchain bleibt. Eine Rückabwicklung käme einem 51% Angriff gleich.

vor 12 Minuten schrieb PeWi:

Und: Betrifft das dann die Nicht-Geth-Validatoren nicht gleichermaßen, wenn die Beacon Node auf einer falschen Chain sitzt?

Ja. Auf deren eigentlich fehlerfreien Chain fehlt die Finality. Die wissen dann erstmal nicht warum die Geth Nodes alle ihre Zustimmung verweigern. Sie müssten erstmal annehmen, dass sie selbst einen fehlerhaften Block durchgewunken haben oder irgendwo anders einen Bug haben und würden jetzt fieberhaft die Köpfe zusammen stecken um den Fehler im Code zu finden. Wenn sich dann die Beweise verhärten, dass der Fehler in Geth begraben liegt, können sie sich entspannt zurück lehnen und einfach abwarten was passiert. Gemäß Protokoll würde die Finality solange ausbleiben bis entweder genug Geth Nodes nach Fehlerbehebung inklusive manuellen Nacharbeiten ihre Zustimmung signalisieren und damit eine 2/3 Mehrheit zustande kommt, oder aber die bei ausbleibender Finality stark erhöhten Strafen all das ETH der Geth Nodes verbrennen sodass sie den Status eines Validators verlieren und die verbleibenden Nodes dadurch die 2/3 Mehrheit erreichen.

Ein Blutbad wird es wenn die Ethereum Foundation das DAO Desaster wiederholt. Sollten sie entscheiden, dass Geth mit seiner eigentlich fehlerhaften Chain gewinnt, wären die Nicht Geth Validatoren diejenigen, die mit jedem weiteren Tag ihre ETH verbrennen. Zutrauen würde ich der Foundation eine solche Entscheidung. Auch beim DAO Desaster hat die Foundation eine Entscheidung getroffen die zuvor eigentlich undenkbar war....

[PeWi]

@mahatma hat schon recht, das ganze ist sakrisch kompliziert.

When a minority client fails, the penalty is losing ETH at the same rate as you gained it (as you can see in the graph of my validator above) but if Geth fails, because it instantly stops the chain from finalising, the penalty is much harsher. This increased penalty is called the inactivity leak and is applied to offline validators when the chain stops finalising for 4 epochs (~25 minutes) or more. This harsher penalty is designed to encourage offline validators to get back online as quickly as possible, or in the worst-case scenario, burn the offline validators' stake until they represent < ⅓ of the total stake allowing the online validators to finalise the chain.

Die "hohe" Strafe (inactivity leak) wird laut Artikel dann verhängt, wenn a) der Validator offline ist und b) die Chain seit mindestens 4 Epochen nicht mehr finalisiert wurde.

Solange ein Nicht-Geth-Validator online ist und arbeitet, ist er also vor dieser höheren Strafe sicher.

Aber solange ein Geth aufgrund des Fehlers nicht offline geht, sondern "nur" falsche Blöcke bestätigt - und das ist ja das Szenario unserer letzten Posts - gilt das für ihn doch genauso?

Bzw: Wenn die Geth-Validatoren aufgrund dieses hypothetischen Fehlers alle offline gehen würden, müsste doch die Zählung der gerade aktiven Validatoren dafür sorgen, dass die noch laufenden Nicht-Geth-Validatoren ziemlich schnell die nötige Mehrheit werden (eben weil die Zahl der aktiven Validatoren massiv sinkt)?

Sprich, in beiden Fällen sollten die Stakes der Geth-Validatoren eben nicht ewig ausbluten müssen.

Aber - offensichtlich - ist es noch weitaus komplizierter, als ich mir das hier zusammen reime ...

[skunk]

vor 42 Minuten schrieb PeWi:

Aber - offensichtlich - ist es noch weitaus komplizierter, als ich mir das hier zusammen reime ...

Du bist sehr dicht dran. Es fehlt nur ein kleines Detail. Die Geth Nodes und die Nicht Geth Nodes haben nach dem Hardfork eine jeweils eigene Blockchain auf der die jeweils anderen Clients scheinbar offline sind. Die Strafen sind nur asymmetrisch verteilt. Die Geth Node bekommt die deutlich teurere Strafe während es den Nicht Geth Nodes fast schon egal sein kann ob sie im Recht oder Unrecht sind. Auch gibt es Unterschiede bei der Frage wie schnell die Geth Nodes und die Nicht Geth Nodes sich ihrer Situation bewusst sind. Die Geth Nodes merken nicht eine falsche Abzweigung genommen zu haben während die Nicht Geth Nodes das sofort erkennen und gegensteuern könnten. Ebenfalls können die Geth Nodes einen Fix wegen der schon erteilten Finality nicht so einfach installieren während die Nicht Geth Nodes dank der ausbleibenden Finality jederzeit einen Fix installieren und vermutlich mit minimalen Nacharbeiten wieder lauffähig währen. Das Protkoll sieht so einen Bugfix durchaus vor nur eben nur solange keine Finality erreicht wurde.

Das ganze ist jetzt vom Blickwinkel der jeweiligen Clients beschrieben unter der Annahme, dass die jeweils andere Chain die eigentlich fehlerfreie wäre. Das Risiko für einen solchen Fehler mag 50/50 sein aber die Strafen sind sehr Einseitig zulasten von Geth.

[PeWi]

Wenn ein Validator immer mindestens 32 ETH haben muss, dann wäre ggf auch ein Ausweg, alle Geth-Validatoren nur mit wenig über 32 ETH zu betreiben? Dann muss nicht so viel verschwinden, bis sie aus ihrer Validatorenrolle herausfallen.

Okay, hilft laut Artikel auch nicht:

One important point here is that it’s unlikely that validators on the invalid chain would sit around doing nothing. They still have the option to withdraw their stake and if they don’t, the network will force eject them anyway when their effective balance reaches 16 ETH. But this does not mean that their downside is limited to 16 ETH.

When you exit a validator (even when force ejected) you go into the exit queue and while you are in the exit queue you will still leak ETH!

Klingt alles so, als sollte ETH noch ein bisschen nachforschen und Maßnahmen für ein solchen Fall, dass der Haupt-Client ausfällt, treffen. 

[mahatma]

Die Ursache des ganzen Übels liegt doch darin begraben, dass der geth client so massiv dominiert, oder?

Kann man den nicht "forken", also nen weiteren client mit quasi den gleichen Eigenschaften erzeugen, nur nem anderen Namen?

Wenn dann jeder zweite geth Benutzer auf geth-2 umschalten würde, gäbe es schon keine 2/3 Mehrheit mehr...

 

Wo liegt mein Denkfehler?

 

PS: ok, was für ne schnapsidee von mir, ist wohl noch zu früh für mein hirn...

logischerweise geht es nicht um den Namen des clients, sondern um eventuelle bugs im programm bzw. das sich die beiden programme gleich verhalten würden... Zweimal mehr oder weniger das selbe programm hätte die selben bugs/dasselbe verhalten und würden zB den selben block als gültig/ungültig erklären.

Bearbeitet 1. Februar von mahatma
mir ist der denkfehler eingefallen....

[PeWi]

2 hours ago, mahatma said:

Die Ursache des ganzen Übels liegt doch darin begraben, dass der geth client so massiv dominiert, oder?

Jein - so wie ich den Artikel verstehe, behandelt das Protokoll bisher nur den Fall, dass einzelne Validatoren - aus welchen Gründen auch immer - ausfallen. Das Protokoll scheint aber keine Sicherung dagegen zu haben, dass aufgrund eines systematischen Fehlers eine komplette Validatoren-Art ausfällt, vor allem, wenn sie die absolute Mehrheit stellt.

Das dieses spezielle Problem nicht auftreten würde, wenn man drei ähnlich stark vertretene, unabhängig voneinander entwickelte Validatoren-Arten hätte, heißt nicht, dass man diesen Fall nicht absehen und sinnvoll im Protokoll behandeln sollte.

Würde sowas im Protokoll berücksichtigt, wäre es egal, dass Geth so stark dominiert.

@skunk in seiner hinterfotzigen Art (*) hätte das vielleicht rechtzeitig erkannt, wenn er bei ETH Test-Verantwortlicher gewesen wäre.

(*: positiv gemeint! 👍)

 

[chip]

Wird denn an dem Problem gearbeitet? Das muss doch über kurz oder lang (besser Ersteres) gelöst werden?! Wie soll man Vertrauen in eine Blockchain haben, die ein solches, massives Problem hat, das bekannt ist? Auch eine Stellungnahme wäre nicht verkehrt mit Zeitplan usw.

[Drayton]

vor 5 Stunden schrieb chip:

ein solches, massives Problem hat, das bekannt ist

Das ist aber eben der Punkt. Ob ein solches Problem vorliegt, wissen wir nicht. Ich kann die Punkte nachvollziehen, aber letztlich müssen wir uns auch klarmachen, dass die Quelle ein Bericht aus dem Internet ist ...

[skunk]

vor 8 Stunden schrieb chip:

Wird denn an dem Problem gearbeitet? Das muss doch über kurz oder lang (besser Ersteres) gelöst werden?! Wie soll man Vertrauen in eine Blockchain haben, die ein solches, massives Problem hat, das bekannt ist?

Die einzig mir bekannte Lösung wäre PoW. Ich dachte davon wollten wir weg?

vor 8 Stunden schrieb chip:

Auch eine Stellungnahme wäre nicht verkehrt mit Zeitplan usw.

Vielleicht sollten wir die Kirche lieber im Dorf lassen. Du stellst gerade Forderungen obwohl du keine Full Node betreibst. Das ist in etwa so wie ein Nichtwähler, der sich dann über den Ausgang der Wahl beklagt. Du selbst kannst jederzeit etwas an dem Problem ändern. Ich fordere daher eine Stellungnahme von dir was dich daran hindert selbst die Geth Dominanz zu reduzieren.

vor 3 Stunden schrieb Drayton:

Das ist aber eben der Punkt. Ob ein solches Problem vorliegt, wissen wir nicht. Ich kann die Punkte nachvollziehen, aber letztlich müssen wir uns auch klarmachen, dass die Quelle ein Bericht aus dem Internet ist ...

Ganz so einfach wegdiskutieren lassen sich die Probleme auch nicht. Das die Geth Dominanz ein Problem ist, steht sogar auf den offiziellen Onboarding Webseiten. Zum Beispiel hier: https://launchpad.ethereum.org/en/geth Und das ist ganz sicher nicht irgend so ein Bericht aus dem Internet. Mir ist praktisch kein einziger Bericht bekannt, der behauptet die Geth Dominanz wäre in Ordnung.

Und selbst wenn es nur irgend eine Internet Seite wäre, so müsste ich nochmal auf den DAO Vorfall hinweisen. Damals waren es eine Handvoll von Stimmen, die auf die Probleme des DAO hingewiesen haben. Einige haben das ernstgenommen und haben sich selbst Gedanken gemacht und andere eben nicht...

[Drayton]

vor 2 Stunden schrieb skunk:

Ganz so einfach wegdiskutieren lassen sich die Probleme auch nicht. Das die Geth Dominanz ein Problem ist, steht sogar auf den offiziellen Onboarding Webseiten.

Mir geht es nicht um die Probleme, sondern um die Folgen für ETH.

vor 2 Stunden schrieb skunk:

müsste ich nochmal auf den DAO Vorfall hinweisen

Genau das. Hat ETH nicht geschadet.

[Drayton]

Am 31.1.2024 um 10:27 schrieb chip:

Was würde dieser heftige Fehler denn für ETH insgesamt bedeuten? Wenn ich hier lese, dass im Fehlerfalle alle ETHs weg sind bei Geth...

1. Für ETH insgesamt mach ich mir keine Sorgen. Geth hängt am Eth1-Client (Execution Client). Aber die Validatoren hängen am Eth2-Client (Consensus Client). 

2. Ein Problem besteht für diejenigen, die über Geth staken. Im schlimmsten Fall verlieren sie ihren kompletten Stake. Spätestens dann hat jeder gecheckt, dass eine Geth-Dominanz ein Problem für die Staker darstellt. So wird es jedenfalls in dem Bericht aus dem Internet beschrieben.

Ich finde den Bericht nachvollziehbar geschrieben, aber er hat aus meiner Sicht einen Fehler, diesen hab ich oben in einem Post schon rauskopiert. Der Bericht spricht davon, dass "running a validator with Geth" zu diesen Folgen führen kann. Aber tatsächlich läuft kein einziger Validator über Geth. Das in dem Bericht beschriebene Problem und die Folgen ergeben nur dann Sinn, wenn der Bug sich auf einem Consensus Client mit einer 2/3-Dominanz ergeben würde. Dann bestünde tatsächlich die Gefahr für die Validatoren, dass sie ihren Stake verlieren. Aber Geth ist NICHT Consensus Client. Geth und die ungesunde Dominanz betrifft den Execution Client.

Bearbeitet 2. Februar von Drayton

[jkl]

vor 12 Stunden schrieb Drayton:

Das ist aber eben der Punkt. Ob ein solches Problem vorliegt, wissen wir nicht.

 

vor 6 Stunden schrieb Drayton:

Mir geht es nicht um die Probleme, sondern um die Folgen für ETH.

Dann hast du deinen Punkt wieder mal nicht mit den korrekten Worten ausgedrückt weswegen du aus deiner Sicht missverstanden wirst.

[skunk]

vor 7 Stunden schrieb Drayton:

Aber tatsächlich läuft kein einziger Validator über Geth. Das in dem Bericht beschriebene Problem und die Folgen ergeben nur dann Sinn, wenn der Bug sich auf einem Consensus Client mit einer 2/3-Dominanz ergeben würde. Dann bestünde tatsächlich die Gefahr für die Validatoren, dass sie ihren Stake verlieren. Aber Geth ist NICHT Consensus Client. Geth und die ungesunde Dominanz betrifft den Execution Client.

Das ist schlicht falsch. Jeder Validator braucht einen Execution Client. Wie am Namen unschwer zu erkennen ist der Consensus Client für die Abstimmung mit den Validatoren zuständig und der Execution Client schreibt die eigentliche Blockchain fort. Ohne Execution Client hat der Consensus Client nichts zum Abstimmen. Und mit einem fehlerhaften Execution Client bekommt der Consensus Client unter Umständen falsche Blöcke zur Abstimmung. Rate was der Consensus Client machen wird...

vor 7 Stunden schrieb Drayton:

1. Für ETH insgesamt mach ich mir keine Sorgen. Geth hängt am Eth1-Client (Execution Client). Aber die Validatoren hängen am Eth2-Client (Consensus Client). 

Die Abhängigkeit geht in beide Richtungen. Seit dem Umstieg auf PoS ist auch der Execution Client auf den Consensus Client angewiesen. Das bedeutet wenn der schlimmste anzunehmende Fall eintrifft und die Validatoren ihre Zustimmung auf einen fehlerhaften Block erteilen, wäre das komplette Netzwerk betroffen. Die einzigen, die den fehlerhaften Block erkennen würden wären die Minderheiten Clients.

Der Grund warum die Berichte sich damit nicht beschäftigen ist recht einfach. Die Validatoren sind wichtiger als der Rest vom Netzwerk. Hätten wir bei den Validatoren keine kritischen Mehrheiten, könnte der Rest vom Netzwerk zu 100% auf Geth setzen. Im Fehlerfall bleibt die 2/3 Mehrheit aus und alles verläuft nach Plan. Jetzt haben wir aber leider bereits eine 2/3 Mehrheit bei den Validatoren. Der Rest vom Netzwerk kann sich somit nicht mehr auf den Schutz der 2/3 Mehrheiten verlassen. Wenn wir diesen Zustand noch etwas länger beibehalten würde ich in Zukunft auch Berichtet bezüglich der zusätzlichen Risiken und Nebenwirkungen dieser neuen Situation erwarten. So schwer ist es ja nicht sich vorzustellen was die eigene Geth Node daheim in der Situation machen wird. Sie folgt natürlich der 2/3 Mehrheit und wird damit ebenfalls zum Risiko auch ohne angeschlossenen Validator.

[Drayton]

vor einer Stunde schrieb skunk:

Das ist schlicht falsch.

Was genau ist denn falsch?

vor einer Stunde schrieb skunk:

Rate was der Consensus Client machen wird...

Was meinst du, was er machen wird?

vor einer Stunde schrieb skunk:

Hätten wir bei den Validatoren keine kritischen Mehrheiten, könnte der Rest vom Netzwerk zu 100% auf Geth setzen.

Wir reden doch hier über Geth und die 2/3-Mehrheit von Geth!? Wenn du über eine "kritische Mehrheit" bei den Validatoren sprichst, dann geht es um die Consensus Clients. Und wenn es darum geht, dann hab ich ja geschrieben: 

vor 10 Stunden schrieb Drayton:

Das in dem Bericht beschriebene Problem und die Folgen ergeben nur dann Sinn, wenn der Bug sich auf einem Consensus Client mit einer 2/3-Dominanz ergeben würde. Dann bestünde tatsächlich die Gefahr für die Validatoren, dass sie ihren Stake verlieren.

Sogar dieser Fall, um den es hier eigentlich gar nicht geht, würde lediglich bedeuten, dass die Validatoren ihren Stake riskieren. 

Nochmal:

vor 10 Stunden schrieb Drayton:

Geth hängt am Eth1-Client (Execution Client). Aber die Validatoren hängen am Eth2-Client (Consensus Client).