Ethereum (ETH)²

[skunk]

vor 1 Minute schrieb Drayton:

Was genau ist denn falsch?

Einfach alles. Ich habe das Gefühl dir ist nicht bewusst wie Execution und Consensus Client ineinander greifen. Setz gern mal eine eigene Full Node auf dann dürfte es klar werden.

vor 2 Minuten schrieb Drayton:

Was meinst du, was er machen wird?

Wenn 2/3 aller Validatoren von ihren Geth Nodes den gleichen invaliden Block zur Abstimmung vorgelegt bekommen, stimmen sie selbstverständlich zu mit allen daraus resultierenden Konsequenzen sowohl für den Validator selbst als auch für alle Exchanges, Blockexplorer usw die zufällig ebenfalls Geth im Einsatz haben.

[Drayton]

vor 11 Stunden schrieb skunk:

Die einzigen, die den fehlerhaften Block erkennen würden wären die Minderheiten Clients.

Genau so sehe ich es auch. Und dann müssten die Mehrheits-Clients auf die neue Chain umspringen. Wenn dies bei einem Consensus Client passiert, dann werden die Validatoren soweit geslashed, dass sie womöglich ihren gesamten Stake verlieren. So what, wer 32 ETH einsetzt, muss sich der Risiken bewusst sein. Für ETH insgesamt hat das keine Auswirkungen.

Bearbeitet 2. Februar von Drayton

[Drayton]

vor 2 Minuten schrieb skunk:

Einfach alles. Ich habe das Gefühl dir ist nicht bewusst wie Execution und Consensus Client ineinander greifen. Setz gern mal eine eigene Full Node auf dann dürfte es klar werden.

Ne skunk, so einfach lasse ich dich da nicht raus. Wenn du schreibst, dass mein Text falsch sei, dann musst du es begründen. By the way, ich hab auch ein Gefühl und dieses sagt mir, dass ich der einzige hier bin, der zwischen Execution und Consensus Client unterscheidet. Und mit Geth betreibt man keinen Validator. 

[skunk]

vor 17 Minuten schrieb Drayton:

Genau so sehe ich es auch. Und dann müssten die Mehrheits-Clients auf die neue Chain umspringen.

Dafür wird es im Ernstfall zu spät sein. Die 2/3 Mehrheit signalisiert allen im Netzwerk, dass die falsche Chain vermeintlich fehlerfrei ist. Das heißt auch die großen Exchanges, Blockexplorer, Wallets usw werden alle auf die falsche Chain blicken sofern sie ebenfalls auf Geth aufbauen. Da werden Stunden ins Land gehen bis das überhaupt an alle Kommuniziert wurde. Genug Zeit um einiges an Schaden anzurichten.

Nur mal als Beispiel. Ich zahle meine ETH bei Binance ein. Wegen der 2/3 Mehrheit muss Binance annehmen meine Transaktion hätte genug Bestätigungen sodass ich sie gegen BTC verkaufen darf. Die BTC zahle ich selbstverständlich unverzüglich an mein Hardware Wallet aus. Du bist mein Handelspartner und freust dich darüber. Sagen wir du verkaufst deine 0,6 BTC und bekommst von mir 100 ETH dafür. Ein überaus verlockender Deal zu dem du sicherlich nicht nein sagen wirst.
Irgendwann updatet Binance seine Geth Node und schwenkt damit auf die fehlerfreie Chain um auf der die ETH weiterhin beim mir liegen. Effektiv hast du mir deine 0,6 BTC geschenkt. Wenn du Glück hast, wird Binance dich entschädigen. Wenn du Pech hast, stehst du am Ende ohne ETH und ohne BTC da und hast beides verloren.

vor 38 Minuten schrieb Drayton:

Ne skunk, so einfach lasse ich dich da nicht raus. Wenn du schreibst, dass mein Text falsch sei, dann musst du es begründen.

Das fällt mir zunehmend schwerer. Ich schwanke zwischen Aufklärung und "Dont feed the Troll". Du hast keine Full Node am Laufen bildest dir aber trotzdem ein mehr darüber zu verstehen als alle anderen hier. Wenn meine Begründungen bisher nicht bei dir gefruchtet haben, dann werde ich auch durch Wiederholungen nicht zu dir vordringen können. Ich sehe mich auch nicht in der Pflicht dazu. Wenn du Fragen hast, beantworte ich sie gern. Wenn du weiterhin falsche Behauptungen aufstellen möchtest, werde ich auch weiterhin auf die Wiedersprüche hinweisen.

vor einer Stunde schrieb Drayton:

Und mit Geth betreibt man keinen Validator. 

Soll das jetzt ein billiges Wortspiel werden? Ohne Execution Client funktioniert der Validator nicht. Und aktuell wird dafür leider viel zu häufig Geth eingesetzt.

[Drayton]

vor 7 Stunden schrieb skunk:

Dafür wird es im Ernstfall zu spät sein. Die 2/3 Mehrheit signalisiert allen im Netzwerk, dass die falsche Chain vermeintlich fehlerfrei ist. Das heißt auch die großen Exchanges, Blockexplorer, Wallets usw werden alle auf die falsche Chain blicken sofern sie ebenfalls auf Geth aufbauen. Da werden Stunden ins Land gehen bis das überhaupt an alle Kommuniziert wurde. Genug Zeit um einiges an Schaden anzurichten.

Ne, das kann nur sein, wenn es einen Bug auf einem Consensus Client mit 2/3-Mehrheit gibt. Das ist aber - zumindest jetzt - nicht der Fall. Geth ist Execution Client. Also sind die von dir beschriebenen Folgen nicht möglich, jedenfalls nicht aufgrund der Dominanz von Geth. 

vor 7 Stunden schrieb skunk:

Ich schwanke zwischen Aufklärung und "Dont feed the Troll".

Nur weil ich eine berechtigte Frage aufgeworfen habe, bin ich jetzt ein Troll? Meine Frage war/ist: Wie kommst du zu der Annahme, dass eine 2/3-Mehrheit bei Geth (also auf dem Execution Client) Probleme beim Consensus Client verursachen wird? 

vor 7 Stunden schrieb skunk:

Ohne Execution Client funktioniert der Validator nicht.

Zum Teil richtig. Denn für den Validator auf dem Consensus Client braucht es einen Execution Client. Aber es braucht NICHT Geth! Die - zugegeben ungesunde - Geth Dominanz betrifft NICHT den Validator.

Es gibt hier zwei Sachen, die du unterscheiden musst:

1. "Bug" auf einem Execution Client mit 2/3-Mehrheit - Keine Auswirkung auf den Consensus Client. "Normale ETH-User" bekommen das gar nicht mit.

2. "Bug" auf einem Consensus Client mit 2/3-Mehrheit - Folge: Eine zweite Chain entsteht. Die 2/3-Mehrheit wird auf die richtige Chain umswitchen müssen, dabei wird die 2/3-Mehrheit geslashed, wodurch das gesamte Stake der Validatoren in Gefahr ist. "Normale ETH-User" müssen da wenig befürchten, ihre ETHs sind davon nicht betroffen. Im schlimmsten Fall wird die ETH Chain kurzfristig angehalten. Die Minderheits-Clients führen diese dann ganz normal weiter. 

Man muss sich bei diesem Problem klar machen, dass es mehrere Faktoren gibt, die zutreffen müssen, um ein Problem auszulösen: (1) zunächst muss es eine 2/3-Mehrheit auf einem Consensus Client geben (gibt es zur Zeit nicht, die 2/3-Mehrheit betrifft Geth, also den Execution Client), (2) wenn es diese 2/3-Mehrheit auf dem Consensus Client gäben sollte, muss dort ein "Bug" auftreten, (3) der "Bug" muss so spät entdeckt werden, als dass es zu einer zweiten Chain kommt, (4) die 2/3-Mehrheits-Validatoren müssen lange brauchen, um von der falschen auf die richtige Chain umzuspringen, um derartig geslashed zu werden, dass sie ihren gesamten Stake verlieren.

Das alles muss erst mal zusammen kommen. Und selbst dann verlieren nur die 2/3-Mehrheits-Validatoren im schlimmsten Fall ihren Stake. Solange man kein Validator ist, ist man safe. Und auch die Validatoren auf den Minderheits-Clients sind safe.  

Bearbeitet 2. Februar von Drayton

[skunk]

vor 51 Minuten schrieb Drayton:

Meine Frage war/ist: Wie kommst du zu der Annahme, dass eine 2/3-Mehrheit bei Geth (also auf dem Execution Client) Probleme beim Consensus Client verursachen wird?

Weil praktisch auf jeder Seite davor gewarnt wird. Weil es in sämtlichen Dokumentationen steht. Und wegen den Logs meiner Full Node.

[Drayton]

vor 8 Minuten schrieb skunk:

Weil praktisch auf jeder Seite davor gewarnt wird. Weil es in sämtlichen Dokumentationen steht. Und wegen den Logs meiner Full Node.

Ja, die ungesunde Geth Dominanz ist ohne Zweifel vorhanden. Diese betrifft aber nur den Execution Client! Deine Antwort beantwortet nicht die Frage, was dich zu der Annahme veranlasst, dass die Geth Dominanz ein Problem für die Consensus Clients darstellen soll.    

[skunk]

vor 4 Minuten schrieb Drayton:

Ja, die ungesunde Geth Dominanz ist ohne Zweifel vorhanden. Diese betrifft aber nur den Execution Client! Deine Antwort beantwortet nicht die Frage, was dich zu der Annahme veranlasst, dass die Geth Dominanz ein Problem für die Consensus Clients darstellen soll.    

Weil praktisch auf jeder Seite davor gewarnt wird. Weil es in sämtlichen Dokumentationen steht. Und wegen den Logs meiner Full Node.

[Drayton]

Also weißt du es nicht, du denkst es dir so, es ist also nur eine Annahme. Ich kann nur sagen, diese Annahme ist nicht zutreffend. Die Unterschiede und die Folgen betreffend der Execution und Consensus Clients hab ich beschrieben. Finde es nur bemerkenswert, dass du meinen Beitrag als "falsch" bezeichnest, ihn downvotest und mich sogar als Troll darstellst, aber die Frage nach dem Warum, kannst du nicht begründen bzw. nur mit irgendwelchen "Logs in deiner Node", "sämtlichen Dokumentationen" und irgendwelchen "Seiten". Schwach.

Bearbeitet 2. Februar von Drayton

[skunk]

vor 22 Minuten schrieb Drayton:

Finde es nur bemerkenswert, dass du meinen Beitrag als "falsch" bezeichnest, ihn downvotest und mich sogar als Troll darstellst, aber auf die Frage nach dem warum, kannst du nicht begründen bzw. nur mit irgendwelchen "Logs in deiner Node", "sämtlichen Dokumentationen" und irgendwelchen "Seiten". Schwach.

Es steht in der offiziellen Dokumentation. Ich hatte es bereits verlinkt und sehe keinen Sinn darin den Link jetzt immer wieder zu wiederholen nur weil du noch nicht einmal die offizielle Dokumentation anerkennen willst. Natürlich bekommst du dafür einen Downvote. Auch finde ich es schwach, dass du nicht mal eine Full Node hast. Du weißt ja nicht einmal von welchen Logs ich hier rede. Soll ich sie dir die Logs vielleicht hier rein kopieren?

[Drayton]

vor 9 Minuten schrieb skunk:

Es steht in der offiziellen Dokumentation. Ich hatte es bereits verlinkt und sehe keinen Sinn darin den Link jetzt immer wieder zu wiederholen nur weil du noch nicht einmal die offizielle Dokumentation anerkennen willst. Natürlich bekommst du dafür einen Downvote. Auch finde ich es schwach, dass du nicht mal eine Full Node hast. Du weißt ja nicht einmal von welchen Logs ich hier rede. Soll ich sie dir die Logs vielleicht hier rein kopieren?

Alles gut. Ich habe zu keinem Zeitpunkt die ungesunde Geth Dominanz angezweifelt! Und alles was du schreibst und an Dokumentation vorlegst und auch deine Node, das alles betrifft den Execution Client! 

Nochmal: Mir geht es nur um die Frage: Wenn ein Execution Client eine ungesunde Dominanz hat, was hat das mit dem Consensus Client zu tun?

Ich habe meine Ansicht, mein Verständnis die Unterschiede und die Folgen beschrieben. Von dir kam nur "falsch". Mich interessiert keine Erklärung hinsichtlich der Geth Dominanz, das kenne ich schon. Ich möchte einfach nur diese hier verbreitete Panik verstehen.  

[skunk]

vor 10 Minuten schrieb Drayton:

Wenn ein Execution Client eine ungesunde Dominanz hat, was hat das mit dem Consensus Client zu tun?

Der Consensus Client stimmt dem fehlerhaften Block zu und wegen der 2/3 Mehrheit gibt es dann erstmal kein Zurück. Genau aus diesem Grund wird in der offiziellen Dokumentation vor der Geth Dominanz gewarnt mit der Bitte doch einen der anderen Alternativen zu benutzen.

vor 13 Minuten schrieb Drayton:

Mich interessiert keine Erklärung hinsichtlich der Geth Dominanz, das kenne ich schon.

Danke, dass du es direkt selbst zugibst....

vor 38 Minuten schrieb Drayton:

Ich möchte einfach nur diese hier verbreitete Panik verstehen. 

Die Panik habe ich auch zuvor bereits relativiert. Wir reden hier von den ganz normalen Risiken und Nebenwirkungen von PoS. Ich finde es sogar vorbildlich wie offen und ehrlich Ethereum damit umgeht. Es hilft nicht das Risiko zu verschweigen so wie das andere Blockchains gerne machen. Dann lieber ganz offen und ehrlich in die Dokumentation schreiben. Das gibt mir die Möglichkeit entsprechende Vorsichtsmaßnahmen zu ergreifen.

 

[Drayton]

vor 26 Minuten schrieb skunk:

Der Consensus Client stimmt dem fehlerhaften Block zu und wegen der 2/3 Mehrheit gibt es dann erstmal kein Zurück. Genau aus diesem Grund wird in der offiziellen Dokumentation vor der Geth Dominanz gewarnt mit der Bitte doch einen der anderen Alternativen zu benutzen.

Wie kann ein Consensus Client einem fehlerhaften Block, der von Geth kommt, zustimmen? Geth ist Execution Client. Der Execution Client erstellt NICHT Blöcke, verwaltet NICHT Blöcke, hat nix mit der Konsenslogik zu tun! Vom Execution Client können überhaupt keine fehlerhaften Blöcke an den Consensus Client gehen! Und nicht mal der Consensus Client "erstellt" Blöcke, sondern erhält diese von den Peers, also den Validatoren. Und nur die Validatoren schlagen Blöcke vor. 

Das was du schreibst geht gar nicht.  

[Drayton]

 

Für ein Basis-Verständnis

Execution Client	Consensus Client	Validator
Gossips transactions over its p2p network	Gossips blocks and attestations over its p2p network	Proposes blocks
Executes/re-executes transactions	Runs the fork choice algorithm	Accrues rewards/penalties
Verifies incoming state changes	Keeps track of the head of the chain	Makes attestations
Manages state and receipts tries	Manages the Beacon state (contains consensus and execution info)	Requires 32 ETH to be staked
Creates execution payload Exposes JSON-RPC API for interacting with Ethereum	Keeps track of accumulated randomness in RANDAO Keeps track of justification and finalization	Can be slashed

Bearbeitet 3. Februar von Drayton

[skunk]

vor 15 Minuten schrieb Drayton:

Wie kann ein Consensus Client einem fehlerhaften Block, der von Geth kommt, zustimmen?

Der Consensus Client hat keine Möglichkeit ankommende Blöcke zu validieren. Er fragt Geth ob der Block valide ist. Er muss Geth fragen weil ihm selbst die Möglichkeit fehlt den Block inhaltlich zu prüfen. Zum Beispiel könnte ein Transaktion einen fehlerhaften Nonce beinhalten. Solche Fehler kann der Consensus Client nicht erkennen und ist auf die Mithilfe des Execution Clients angewiesen. Und wenn der Geth Client den fehlerhaften Block als fehlerfrei zurück meldet dann fängt der Spaß mit der 2/3 Mehrheit an.

vor einer Stunde schrieb Drayton:

Der Execution Client erstellt NICHT Blöcke, verwaltet NICHT Blöcke, hat nix mit der Konsenslogik zu tun!

In deiner eigenen Tabelle steht "Create execution payload" drin. Der Execution Client baut den Block oder alternativ MEV. Der Consensus Client übernimmt dann die Abstimmung mit den anderen Consensus Clients.

Der Execution Client verwaltet auch die Blöcke. Hier mal Logs von meiner Nethermind Node:
 

03 Feb 00:27:13 | ***** JSON RPC report *****
-------------------------------------------------------------------------------------------------------------------------------------------------------------
method                                  | successes |  avg time (µs) |  max time (µs) |    errors |  avg time (µs) |  max time (µs) | avg size | total size |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
engine_exchangeTransitionConfigurationV1|         5 |             66 |             74 |         0 |              0 |              0 |      204 |       1020 |
engine_forkchoiceUpdatedV2              |        26 |           1471 |          12459 |         0 |              0 |              0 |      199 |       5173 |
engine_newPayloadV2                     |        26 |         197349 |         404753 |         0 |              0 |              0 |      164 |       4263 |
eth_getBlockByNumber                    |        44 |            175 |            841 |         0 |              0 |              0 |    14582 |     641590 |
eth_getLogs                             |        22 |            157 |            580 |         0 |              0 |              0 |       38 |        835 |
-------------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL                                   |       123 |          42120 |         404753 |         0 |              0 |              0 |     5308 |     652881 |
-------------------------------------------------------------------------------------------------------------------------------------------------------------

eth_getBlockByNumber macht genau das was der Name schon sagt. Damit kann man den Execution Client um die Herausgabe jedes Blockes bitten.

vor 1 Stunde schrieb Drayton:

Und nicht mal der Consensus Client "erstellt" Blöcke, sondern erhält diese von den Peers, also den Validatoren.

Schau nochmal in deine Tabelle. Ein Validator hat keine Peers. Effektiv läuft es wie folgt:
Beim Start meldet der Validator sich bei seinem Consensus Client mit seinem Public Key. Der Consensus Client filtert aus den eingehenden Events alle raus die diesen Public Key betreffen. Der Conensus Client merkt darüber auch wann es Zeit ist einen Block vorzuschlagen. Der Consensus Client kann sich wahlweise von MEV einen Block geben lassen oder den Execution Client bitten einen Block mit den im Mempool enthaltenen Transaktionen zu bauen. In der Regel wird MEV mehr Gewinn abwerfen. Um diesen Block vorschlagen zu können muss der Validator mit seinem Private Key eine Runde signieren. Der Consensus Client verteilt diese Signatur im Netzwerk an alle anderen Consensus Clients.
Zustimmung zu diesem neuen Block verläuft genauso ab. Der Consensus Client meldet sich beim Validator wenn es Zeit wird etwas zu signieren.

[Drayton]

vor 46 Minuten schrieb skunk:

Der Consensus Client hat keine Möglichkeit ankommende Blöcke zu validieren. Er fragt Geth ob der Block valide ist. Er muss Geth fragen weil ihm selbst die Möglichkeit fehlt den Block inhaltlich zu prüfen. Zum Beispiel könnte ein Transaktion einen fehlerhaften Nonce beinhalten. Solche Fehler kann der Consensus Client nicht erkennen und ist auf die Mithilfe des Execution Clients angewiesen. Und wenn der Geth Client den fehlerhaften Block als fehlerfrei zurück meldet dann fängt der Spaß mit der 2/3 Mehrheit an.

ETH hat zwei Clients (Execution und Consensus). Diese müssen sich deswegen natürlich hinsichtlich der Transaktionen austauschen. ABER Blöcke kommen doch nicht von Geth, die Blöcke kommen von den Peers, von den Validatoren. Oder übergeordnet gesehen, die Blöcke kommen von den Validatoren innerhalb des Consensus Clients und werden an den Execution Client übermittelt. Aber doch nicht umgekehrt, wie du es beschreibst. Also, dass der Consensus Client den Execution Client fragt, ob ein Block valide ist!??

vor 57 Minuten schrieb skunk:

In deiner eigenen Tabelle steht "Create execution payload" drin. Der Execution Client baut den Block oder alternativ MEV. Der Consensus Client übernimmt dann die Abstimmung mit den anderen Consensus Clients.

Na ja, so in etwa, nur anders herum: Der Execution Payload wird vom Execution Client erstellt, aber dann baut der Consensus Client diesen Execution Payload in den Block.

vor einer Stunde schrieb skunk:

Schau nochmal in deine Tabelle. Ein Validator hat keine Peers. Effektiv läuft es wie folgt:
Beim Start meldet der Validator sich bei seinem Consensus Client mit seinem Public Key. Der Consensus Client filtert aus den eingehenden Events alle raus die diesen Public Key betreffen. Der Conensus Client merkt darüber auch wann es Zeit ist einen Block vorzuschlagen. Der Consensus Client kann sich wahlweise von MEV einen Block geben lassen oder den Execution Client bitten einen Block mit den im Mempool enthaltenen Transaktionen zu bauen. In der Regel wird MEV mehr Gewinn abwerfen. Um diesen Block vorschlagen zu können muss der Validator mit seinem Private Key eine Runde signieren. Der Consensus Client verteilt diese Signatur im Netzwerk an alle anderen Consensus Clients.
Zustimmung zu diesem neuen Block verläuft genauso ab. Der Consensus Client meldet sich beim Validator wenn es Zeit wird etwas zu signieren.

Auch hier, teilweise stimme ich zu. Aber Blöcke bekommt der Consensus Client von den Peers, da lege ich mich fest. Ansonsten beschreibst du die Arbeit der Validatoren innerhalb des Consencus Clients. Nur dann verwechselst du erneut den Execution Payload und die "Re-Execution" mit der Blockerstellung. Ich weiß jetzt nicht, ob ich das hier richtig verstanden hab, was du schreibst. Aber wir sind uns ja bestimmt einig, dass jeder Client (Eth1 und Eth2) sein eigenes P2P hat und die Verbindung über die Engine API läuft? Ich frage deswegen, weil du dann schreibst: "den Execution Client bitten einen Block mit den im Mempool enthaltenen Transaktionen zu bauen." Das ist aber definitiv falsch. Wo hast du das her, dass der Execution Client Blöcke baut?

[skunk]

vor 6 Stunden schrieb Drayton:

Wo hast du das her, dass der Execution Client Blöcke baut?

Das steht in deiner Tabelle. Der Payload ist der Block. Der Consensus Client kann nicht entscheiden ob ein Block valide ist oder nicht. Er ist zwingend auf die Mithilfe des Execution Clients angewiesen.

MEV ist eine Ausnahme. Beim MEV wird ein Block erst blind vorgeschlagen, dann validiert und notfalls wenn er invalide sein sollte nicht weiter im Netzwerk verbreitet. In dem Fall geht der Validator einfach nur leer aus aber ansonsten gibt es keine Nachwirkungen.

Problematisch wird es wenn der Geth Client einen invaliden Block als valide anerkennt. Ab da wird es dann lustig....

Edit: Du siehst die Validierung der Blöcke auch in den Logs meines Execution Clients. engine_newPayloadV2 kannst du hier nachschlagen: https://ethereum.github.io/execution-apis/api-documentation/

Dort steht dann Runs Execution Payload Validation mit folgenden Request Parametern:
 

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "engine_newPayloadV2",
  "params": [
    {
      "parentHash": "0x3b8fb240d288781d4aac94d3fd16809ee413bc99294a085798a589dae51ddd4a",
      "feeRecipient": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b",
      "stateRoot": "0xca3149fa9e37db08d1cd49c9061db1002ef1cd58db2210f2115c8c989b2bdf45",
      "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "prevRandao": "0xc130d5e63c61c935f6089e61140ca9136172677cf6aa5800dcc1cf0a02152a14",
      "blockNumber": "0x112720f",
      "gasLimit": "0x1c9c380",
      "gasUsed": "0xbad2e8",
      "timestamp": "0x64e7785b",
      "extraData": "0x",
      "baseFeePerGas": "0x7",
      "blockHash": "0x3559e851470f6e7bbed1db474980683e8c315bfce99b2a6ef47c057c04de7858",
      "transactions": [
        "0x03f88f0780843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a0010657f37554c781402a22917dee2f75def7ab966d7b770905398eba3c44401401a0840650aa8f74d2b07f40067dc33b715078d73422f01da17abdbd11e02bbdfda9a04b2260f6022bf53eadb337b3e59514936f7317d872defb891a708ee279bdca90",
        "0x03f88f0701843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001521d528ad0c760354a4f0496776cf14a92fe1fb5d50e959dcea1a489c7c83101a0a86c1fd8c2e74820686937f5c1bfe836e2fb622ac9fcbebdc4ab4357f2dbbc61a05c3b2b44ff8252f78d70aeb33f8ba09beaeadad1b376a57d34fa720bbc4a18ee",
        "0x03f88f0702843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001453362c360fdd8832e3539d463e6d64b2ee320ac6a08885df6083644a063e701a037a728aec08aefffa702a2ca620db89caf3e46ab7f25f7646fc951510991badca065d846f046357af39bb739b161233fce73ddfe0bb87f2d28ef60dfe6dbb0128d"
      ],
      "withdrawals": [
        {
          "index": "0xf0",
          "validatorIndex": "0xf0",
          "address": "0x00000000000000000000000000000000000010f0",
          "amount": "0x1"
        },
        {
          "index": "0xf1",
          "validatorIndex": "0xf1",
          "address": "0x00000000000000000000000000000000000010f1",
          "amount": "0x1"
        }
      ]
    }
  ]
}

 

Bearbeitet 3. Februar von skunk

[skunk]

Am 1.2.2024 um 12:49 schrieb PeWi:

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

Der Satz ging mir seit 2 Tagen nicht mehr aus dem Kopf. Ähnlich haben es auch @chip und @mahatma formuliert. Es hat eine Weile gedauert aber ich habe endlich eine für mich zufriedenstellende Antwort gefunden.

Etwas übertrieben formuliert: Man hat schlicht die Ignoranz und Bequemlichkeit der Validatoren unterschätz. Der Fehler liegt nicht im Protokoll sondern im Verhalten der Validatoren. Würden sie sich so verhalten wie es von ihnen erwartet wird, hätten wir das Problem nicht.

Ich würde sogar soweit gehen und behaupten Ethereum ist die Beste aller möglichen PoS Implementierungen. Ethereum macht es richtig und spricht den menschlichen Faktor offen an. Es liegt an uns das Protokoll vollumfänglich zu erfüllen und damit das Problem dauerhaft zu beseitigen.

Zugegeben ich habe wenig Hoffnung, dass die Geth Dominanz so schnell gebrochen wird. Wenn man genau hinhört dann ist den Validatoren das Problem zwar teilweise bewusst aber noch überwiegen andere Überlegungen. Einfaches Setup, vertrauter Client oder auch "ich wähle den Pool mit den geringsten Gebühren für maximalen Profit". Ich habe bisher noch niemanden gehört der einen Pool danach ausgewählt hätte welcher Execution Client im Hintergrund läuft.

Ich habe inzwischen meine lokale Geth Node erfolgreich gegen Nethermind ausgetauscht. Bisher sieht es positiv aus. Vielleicht erledigt sich das Problem langfristig von selbst. Es bedarf nur etwas mehr Wissenstransfer.

So oder so sehe ich die Situation positiv. Mein aktuelles Investment in ETH ist klein genug um einen Totalverlust zu verkraften. Gleichzeitig ist es groß genug um dafür extra eine Full Node aufzusetzen und aktiv zu hinterfragen wie gut PoS wirklich ist und welche Probleme noch gelöst werden müssen. Ich werde mein kleines ETH Investment wohl noch etwas halten einfach um ein Grund zu haben mich weiter mit dem Thema beschäftigen. Etwas Weiterbildung schadet nie. Ich erhoffe mir davon einen Wissensvorsprung den ich irgendwann in der Zukunft wieder zu Geld machen kann.

Ich muss mich die Tage etwas mehr mit Danksharding bzw Layer 2 beschäftigen. Da habe ich noch viele ungeklärte Fragen.

Bearbeitet 3. Februar von skunk

[PeWi]

25 minutes ago, skunk said:

Man hat schlicht die Ignoranz und Bequemlichkeit der Validatoren unterschätz. Der Fehler liegt nicht im Protokoll sondern im Verhalten der Validatoren.

Meinst du mit "Validator" die Software oder den Menschen, der ihn betreibt?

26 minutes ago, skunk said:

Etwas übertrieben formuliert: Man hat schlicht die Ignoranz und Bequemlichkeit der Validatoren unterschätz. Der Fehler liegt nicht im Protokoll sondern im Verhalten der Validatoren. Würden sie sich so verhalten wie es von ihnen erwartet wird, hätten wir das Problem nicht.

Die Beschreibungen, die ich bei euch und in dem Artikel gelesen habe, klingen nicht danach, dass der "Ausfall der Finalisierung" ein im Protokoll vorhergesehenes Ereignis ist, auf das spezifisch reagiert wird.

Es wird darauf nur sehr unspezifisch (siehe Artikel) reagiert, und bestraft auch die "kleinen Leute", die ihre ETH-Krümel einem Validator anvertraut haben. Das finde ich noch keine adäquate Reaktion auf das Ereignis "keine Finalisierung mehr" - könnte man darauf nicht spezifischer und geschickter reagieren? (Ernstgemeint, nicht rethorisch.)

[skunk]

vor 3 Stunden schrieb PeWi:

Meinst du mit "Validator" die Software oder den Menschen, der ihn betreibt?

Ja ich meine den Menschen vor der Maschine.

vor 3 Stunden schrieb PeWi:

Die Beschreibungen, die ich bei euch und in dem Artikel gelesen habe, klingen nicht danach, dass der "Ausfall der Finalisierung" ein im Protokoll vorhergesehenes Ereignis ist, auf das spezifisch reagiert wird.

Ich kann dir nicht ganz folgen. In einer perfekten Welt ohne Geth Dominanz würde im Fehlerfall die Finalisierung einfach zeitweise ausbleiben. Selbst wenn es zu einem Chainsplit kommt, würde keine der beiden Chains die Finalisierung erlangen. Der Vorteil ist, dass sofort alle Nodes im Netzwerk gewarnt sind. Binance könnte zum Beispiel Deposits kurzzeitig pausieren und das völlig automatisch in dem Moment in dem der Chainsplit stattfindet.

Die erhöhten Strafen für die Validatoren sollen dafür sorgen, dass sie sich zügig darauf einigen welche der beiden Chains jetzt die richtige ist. Die fehlerhaften Validatoren installieren ein Update,  innerhalb von Stunden funktioniert die Finalisierung wieder und das ist das Signal für alle anderen Nodes genau dieser Chain zu folgen.

Problematisch wird das ganze erst in Verbindung mit einer zu hohen Geth Dominanz. Dann ist eine der beiden Chains durchgängig Finalisiert und dieser Schutzmechanismus greift nicht. Ab da wird es dann Spaßig...

Bearbeitet 3. Februar von skunk

[PeWi]

1 hour ago, skunk said:

Ich kann dir nicht ganz folgen.

Kein Wunder - ich war ja auch falsch abgebogen. 

In dem hier diskutierten Fehlerfall läuft ja die Finalisierung weiter (nur eben auf fehlerhaften Blöcken).

[skunk]

Sieht so aus als müssten wir vielleicht gar nicht so lange warten bis die Geth Dominanz reduziert wird. Einige der Pools stellen gerade um: https://blockworks.co/news/ethereum-geth-client-diversity 

Hintergrund ist, dass vor 2 Wochen einer der Execution Clients tatsächlich ausgefallen ist. Nur kurz und zum Glück einer der Minderheiten Clients. Der Warnschuss wurde gehört und jetzt handeln die Pools. Wenn noch ein paar mehr folgen, könnten wir es unter die 66% schaffen.

@Drayton ^ Das ist zugleich auch der Beweis, dass der Execution Client nicht so unwichtig ist wie du bisher glaubst. Wenn du diesem Bericht nicht glaubst dann findest du über die letzten 2 Wochen verteilt noch ganz viele andere davon. Alle mit der gleichen Botschaft.

Bearbeitet 3. Februar von skunk

[mahatma]

vor 40 Minuten schrieb skunk:

Der Warnschuss wurde gehört und jetzt handeln die Pools. Wenn noch ein paar mehr folgen, könnten wir es unter die 66% schaffen.

hmmm.... dann wart ich wohl noch bischen mit meiner "strategischen entscheidung"...  

Vielen Dank @skunk dass du uns hier so kompetent auf dem laufenden hältst!!!

Bearbeitet 3. Februar von mahatma

[Drayton]

vor 22 Stunden schrieb Drayton:

Na ja, so in etwa, nur anders herum: Der Execution Payload wird vom Execution Client erstellt, aber dann baut der Consensus Client diesen Execution Payload in den Block.

 

vor 16 Stunden schrieb skunk:

Du siehst die Validierung der Blöcke auch in den Logs meines Execution Clients. engine_newPayloadV2 kannst du hier nachschlagen: https://ethereum.github.io/execution-apis/api-documentation/

Ok:

1. Danke, damit hab ich verstanden, worum es dir ging und wo du das mögliche Risiko siehst.

2. Trotzdem bleibe ich bei allen meinen Aussagen, beschriebenen Folgen und insbesondere dabei, dass der Execution Client (also auch Geth) keine Blöcke erzeugt! Der Execution Client erstellt (wie ich auch oben geschrieben hab) den Execution Payload, bestätigt ja auch deine Dokumentation. Dann baut der Consensus Client diesen Execution Payload in den Block.

3. Aber, ich muss zugeben, dass ich jetzt das Problem auch als ein "reales" Problem sehe. Denn tatsächlich hatte ich den Execution Payload nicht als eine derartige Fehlerquelle gesehen. Denn:

Der Execution Payload wird vom Execution Client erstellt, dann baut der Consensus Client diesen Execution Payload in den Block. Dabei wird der Execution Payload validiert. Soweit so gut.

Aber, wenn eine 2/3-Mehrheit bei einem Execution Client erlaubt ist und dann mehr als 2/3 der Execution Clients (was ja Geth mit seiner Dominanz ausmacht) einen fehlerhaften Execution Payload erstellen, dann kann der Consensus Client nicht erkennen, dass der gesamte Execution Payload tatsächlich nur von EINEM Client kommt. Das ist echt ein fragwürdiger Konsensmechanismus. 

Der Consensus Client ist ja gerade für die Blockerstellung und die konsensrelevante Logik zuständig. Der Consensus Client kann zwar den Bug erkennen, wenn ein anderer Execution Client (also nicht Geth-Client) einen abweichenden Execution Payload erstellt. Der Consensus Client müsste eigentlich den Execution Payload von mehreren Clients abwarten. Aber wenn der Consensus Client nicht erkennen kann, dass der gesamte Execution Payload tatsächlich nur von EINEM Client kommt, dann funktioniert die ganze Logik nicht und dann wird der fehlerhafte Execution Payload vom Consensus Client in den Block eingebaut. 

Meine Meinung: Ist zwar schön, dass die ersten ihren Client umstellen, die Geth-Dominanz sehe ich aber ohnehin und weiterhin nicht als das Problem, sondern ich sehe jetzt einen enormen Schwachpunkt beim Consensus Client, der nicht in der Lage ist (1) zu erkennen, wenn der gesamte Execution Payload tatsächlich nur von EINEM Client kommt und (2) nicht den Execution Payload von einem anderen Client abwartet. 

 

Bearbeitet 4. Februar von Drayton

[skunk]

vor 7 Stunden schrieb Drayton:

2. Trotzdem bleibe ich bei allen meinen Aussagen, beschriebenen Folgen und insbesondere dabei, dass der Execution Client (also auch Geth) keine Blöcke erzeugt! Der Execution Client erstellt (wie ich auch oben geschrieben hab) den Execution Payload, bestätigt ja auch deine Dokumentation. Dann baut der Consensus Client diesen Execution Payload in den Block.

Der Payload ist auch weiterhin der Block. In der Dokumentation steht sogar die Funktion drin, die im Ernstfall den Block bauen würde. engine_getPayloadV2 mit folgenden Rückgabeparametern:
 

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "executionPayload": {
      "parentHash": "0x3b8fb240d288781d4aac94d3fd16809ee413bc99294a085798a589dae51ddd4a",
      "feeRecipient": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b",
      "stateRoot": "0xca3149fa9e37db08d1cd49c9061db1002ef1cd58db2210f2115c8c989b2bdf45",
      "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "prevRandao": "0xc130d5e63c61c935f6089e61140ca9136172677cf6aa5800dcc1cf0a02152a14",
      "blockNumber": "0x112720f",
      "gasLimit": "0x1c9c380",
      "gasUsed": "0xbad2e8",
      "timestamp": "0x64e7785b",
      "extraData": "0x",
      "baseFeePerGas": "0x7",
      "blockHash": "0x1256f99fb899c2de0aeac0c5aa6aad69de188b6a0f4ac29f2d075a53aa3ed0e4",
      "transactions": [
        "0x03f88f0780843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a0010657f37554c781402a22917dee2f75def7ab966d7b770905398eba3c44401401a0840650aa8f74d2b07f40067dc33b715078d73422f01da17abdbd11e02bbdfda9a04b2260f6022bf53eadb337b3e59514936f7317d872defb891a708ee279bdca90",
        "0x03f88f0701843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001521d528ad0c760354a4f0496776cf14a92fe1fb5d50e959dcea1a489c7c83101a0a86c1fd8c2e74820686937f5c1bfe836e2fb622ac9fcbebdc4ab4357f2dbbc61a05c3b2b44ff8252f78d70aeb33f8ba09beaeadad1b376a57d34fa720bbc4a18ee",
        "0x03f88f0702843b9aca008506fc23ac00830186a09400000000000000000000000000000000000001008080c001e1a001453362c360fdd8832e3539d463e6d64b2ee320ac6a08885df6083644a063e701a037a728aec08aefffa702a2ca620db89caf3e46ab7f25f7646fc951510991badca065d846f046357af39bb739b161233fce73ddfe0bb87f2d28ef60dfe6dbb0128d"
      ],
      "withdrawals": [
        {
          "index": "0xf0",
          "validatorIndex": "0xf0",
          "address": "0x00000000000000000000000000000000000010f0",
          "amount": "0x1"
        },
        {
          "index": "0xf1",
          "validatorIndex": "0xf1",
          "address": "0x00000000000000000000000000000000000010f1",
          "amount": "0x1"
        }
      ]
    },
    "blockValue": "0x10a741a46278014d"
  }
}

Parent Hash, Block Number, Block Hash, Transactions usw. Ich sehe nicht ein einziges Feld was dort fehlen würde. Der Execution Client liefert einen fertigen Block an den Consensus Client.

vor 7 Stunden schrieb Drayton:

dann kann der Consensus Client nicht erkennen, dass der gesamte Execution Payload tatsächlich nur von EINEM Client kommt.

Genau dafür ist die 2/3 Mehrheit da. Jeder Validator schaut sich den neuen Block an stimmt ihm zu oder verweigert seine Zustimmung. Nur wenn 2/3 aller Validatoren den Block als fehlerfrei ansehen, wird er Teil der Blockchain. Wegen der hohen Geth Dominanz kann es passieren, dass auch ein fehlerhafter Block die 2/3 Mehrheit bekommen könnte. Wenn die Geth Dominanz auf ein gesundes Maß reduziert wird, würde die 2/3 Mehrheit ausbleiben und damit hätten dann alle Gewissheit.

Bearbeitet 4. Februar von skunk