Drayton

Nun, heute ist der 06.02.2021. Aktueller Ether Kurs: 1.406,75 € (Stand: 06.02.21 15:00) Nun, ich hab jetzt leider nicht genau das Datum getroffen, aber wenigstens den Monat. Also für die "Nachwelt" Aktueller Ether Kurs: 2.582,07 € (Stand: 18.02.24, 01:45) Von rund 90 € auf rund 1400€ und nun rund 2600€ - das sind rund 2800% Plus. Weitere +50% halte ich bis Jahresende für realistisch.

Wer eigenmächtig seine Truppe oder Dienststelle verläßt oder ihr fernbleibt, um sich der Verpflichtung zum Wehrdienst dauernd oder für die Zeit eines bewaffneten Einsatzes zu entziehen oder die Beendigung des Wehrdienstverhältnisses zu erreichen, wird mit Freiheitsstrafe bis zu fünf Jahren bestraft.

Ne, aber ich bin es leid, es immer wieder hinzuschreiben. Kann sich ja jeder selbst im Netz durchlesen https://ethereum-org-fork.netlify.app/developers/docs Lies du da auch mal selbst, dann wirst du sehen, dass du auch vorher einige Sachen verwechselt hast. z.B.: The execution client is responsible for transaction handling, transaction gossip, state management and supporting the Ethereum Virtual Machine (EVM). However, it is not responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client. oder auch da: The execution client creates execution payloads - the list of transactions, updated state trie, and other execution-related data. Consensus clients include the execution payload in every block. The execution client is also responsible for re-executing transactions in new blocks to ensure they are valid. The execution client creates execution payloads + The execution client is also responsible for re-executing transactions in new blocks to ensure they are valid. Das ist das, was du mit der Blockerstellung verwechselst. Blocks kommen von den Peers auf dem Consensus Client. Ja, aber das Problem besteht weiterhin, weil der Consensus Client nicht erkennt, dass er den gesamten Execution Payload von EINEM Client erhält. Klar, gäbe es nicht die 2/3 Mehrheit ... Mich beschäftigt aber nicht diese 2/3 Mehrheit, mich beschäftigt, dass der Konsensmechanismus einen Schwachpunkt hat. Denn der Konsensmechanismus soll ja gerade Fehler erkennen und das kann er nur bedingt. Finde diese Erkenntnis wichtig, auch wenn ich sie selbst kaum glauben kann. Hättest du Geth nicht erwähnt, wäre ich womöglich nie darauf gekommen. Daher danke für den ganzen Input hier!

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.

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!?? 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. 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?

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

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.

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.

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.

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.

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. 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? 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.

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.

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.

Was genau ist denn falsch? Was meinst du, was er machen wird? 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: Sogar dieser Fall, um den es hier eigentlich gar nicht geht, würde lediglich bedeuten, dass die Validatoren ihren Stake riskieren. Nochmal:

Wenn es in Deutschland ganz schlimm wird und keine Pandemien oder Kriege mehr als Erklärung reichen, dann sind es die Ausländer oder wie hier die Asylbewerber, die an allem schuld sind. So hat dann auch der Bürgergeldempfänger noch etwas, worauf er runterschauen kann. Nach oben buckeln und und nach unten treten. Armes Deutschland. Ich danke dir für diesen Artikel, er gibt mir Hoffnung, dass in diesem Land doch noch einige bei klarem Verstand sind.

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.

Mir geht es nicht um die Probleme, sondern um die Folgen für ETH. Genau das. Hat ETH nicht geschadet.

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 ...

Man beachte, der Beitrag ist aus dem Jahr 2014!

Man beachte, dieser Beitrag ist aus dem Jahr 2015!

Hey, danke!! With this knowledge, it seems crazy that anyone is still running Geth whilst it holds a supermajority. I can only assume that those running Geth don’t fully understand this risk. If you are running a validator with Geth, switch today!

So müsste es sein! So sieht wohl leider die Realität aus.

Vielleicht könnte man in jeder deutschen Schule, jeweils in der 10. Klasse oder auf den Gymnasien jeweils in der 12. Klasse das Fach "Geldsystem" einführen, damit die Kids nach dem Abi zumindest selbst Steuererklärung können oder auch einfach wissen, wie Geldschöpfung geht. Aber vielleicht ist das auch nicht gewollt?

Hey @ngt! Du bist wieder da, was mich freut und daher möchte ich dich gleich in den ETH-Thread einladen!

Danke dir. Würde nur ergänzen: Mittelschicht fängt bei 16k Netto-JAHRES-Einkommen an. Bei 16k im Jahr musst du dir schon wirklich überlegen, entweder "vernünftig" wohnen oder "vernünftig" essen, beides geht kaum.