ethereum · corwintines · Jan 7, 2025 · Jan 1, 2025 · Jan 7, 2025
@@ -16,7 +16,7 @@ summaryPoint3: Ein Ort, an dem sich Geldmittel für einen bestimmten Zweck siche
 
 Eine DAO ist eine Organisation im kollektiven Besitz, die auf eine gemeinsame Mission hinarbeitet.
 
-DAOs ermöglichen es uns, mit Gleichgesinnten rund um den Globus zusammenzuarbeiten, ohne auf das Wohlwollen einer Führungskraft vertrauen zu müssen, die unsere Geldmittel oder die Operationen verwaltet. Es gibt keinen CEO, der Geld nach Lust und Laune ausgibt, und keinen Finanzchef, der die Buchhaltung manipulieren kann. Stattdessen bestimmen die in den Code eingebauten, Blockchain-basierten Regeln, wie die Organisation funktioniert und wie Geldmittel ausgegeben werden.
+DAOs ermöglichen es uns, mit Gleichgesinnten rund um den Globus zusammenzuarbeiten, ohne auf das Wohlwollen einer Führungskraft vertrauen zu müssen, die unsere Geldmittel oder die Operationen verwaltet. Es gibt keinen CEO, der Geldmittel nach Lust und Laune ausgibt, und keinen Finanzchef, der die Buchhaltung manipulieren kann. Stattdessen bestimmen die in den Code eingebauten, Blockchain-basierten Regeln, wie die Organisation funktioniert und wie Geldmittel ausgegeben werden.
 
 Die Finanzverwaltung ist integriert und niemand kann ohne die Zustimmung der Gruppe auf die Mittel zugreifen. Entscheidungen werden nach Vorschlägen und Abstimmungen getroffen. So wird sichergestellt, dass jeder in der Organisation eine Stimme hat und dass alles transparent [on-Chain](/glossary/#on-chain) abläuft.
 
@@ -67,7 +67,7 @@ Um DAOs zu verwalten, sind vorher zahlreiche Überlegungen notwendig – etwa wi
 
 ### Delegation {#governance-delegation}
 
-Die Delegation ist die DAO-Variante repräsentativer Demokratie. Tokenbesitzer delegieren Stimmen an Nutzer, die sich selbst nominieren und sich verpflichten, auf dem aktuellen Stand zu bleiben und das Protokoll zu verwalten.
+Die Delegation ist die DAO-Variante repräsentativer Demokratie. Tokenbesitzer delegieren Stimmen an Benutzer, die sich selbst nominieren und sich verpflichten, auf dem aktuellen Stand zu bleiben und das Protokoll zu verwalten.
 
 #### Bekanntes Beispiel {#governance-example}
 
@@ -125,7 +125,7 @@ _Wird üblicherweise für die dezentralisierte Entwicklung und Verwaltung von Pr
 
 #### Bekanntes Beispiel {#reputation-example}
 
-[DXdao](https://DXdao.eth.limo) – DXdao war eine weltweit souveräne Gemeinschaft, die seit 2019 dezentralisierte Protokolle und Applikationen entwickelte und verwaltete. Sie nutzte reputationsbasierte Verwaltung und [holografischen Konsens](/glossary/#holographic-consensus) zur Koordiantion und Verwaltung von Geldmitteln, d. h. niemand konnte sich Einfluss auf ihre Entwicklung oder Verwaltung erkaufen.
+[DXdao](https://DXdao.eth.limo) – DXdao war eine weltweit souveräne Gemeinschaft, die seit 2019 dezentralisierte Protokolle und Anwendungen entwickelte und verwaltete. Sie nutzte reputationsbasierte Verwaltung und [holografischen Konsens](/glossary/#holographic-consensus) zur Koordiantion und Verwaltung von Geldmitteln, d. h. niemand konnte sich Einfluss auf ihre Entwicklung oder Verwaltung erkaufen.
 
 ## DAO – Beitritt und Gründung {#join-start-a-dao}
 

@@ -355,3 +355,7 @@ DeFi ist eine Open-Source-Bewegung. DeFi-Protokolle und -Anwendungen sind für j
 
 - [DeFi Llama Discord Server](https://discord.defillama.com/)
 - [DeFi Pulse Discord Server](https://discord.gg/Gx4TCTk)
+
+<Divider />
+
+<QuizWidget quizKey="defi" />
@@ -14,7 +14,7 @@ Dieser neue Schlüsseltyp verwendet das Signaturschema [**Boneh-Lynn-Shacham (BL
 
 ## Die beiden Arten von Validatorenschlüsseln {#two-types-of-keys}
 
-Vor dem Wechsel zu Proof-of-Stake verfügten Ethereum-Benutzer nur über einen einzigen auf einer elliptischen Kurve basierenden privaten Schlüssel, mit dem sie auf ihre Assets zugreifen konnten. Mit der Einführung von Proof-of-Stake brauchten Benutzer, die Solo-Staker sein wollten, auch einen **Validatorenschlüssel** und einen **Auszahlungsschlüssel**.
+Vor dem Wechsel zu Proof-of-Stake verfügten Ethereum-Benutzer nur über einen einzigen auf einer elliptischen Kurve basierenden privaten Schlüssel, mit dem sie auf ihre Geldmittel zugreifen konnten. Mit der Einführung von Proof-of-Stake brauchten Benutzer, die Solo-Staker sein wollten, auch einen **Validatorenschlüssel** und einen **Auszahlungsschlüssel**.
 
 ### Der Validatorenschlüssel {#validator-key}
 

@@ -12,7 +12,7 @@ Um diese Seite zu verstehen, müssen zuerst die Grundlagen von [Proof-of-Stake](
 
 ## Welche Probleme löst die schwache Subjektivität? {#problems-ws-solves}
 
-Subjektivität ist bei Proof-of-Stake-Blockchains inhärent, da die Auswahl der korrekten Chain aus mehreren Forks durch das Zählen historischer Stimmen erfolgt. Dies setzt die Blockchain mehreren Angriffsvektoren aus. Dazu gehören auch Langstreckenangriffe, bei denen Nodes, die sehr früh an der Chain beteiligt waren, eine alternative Fork aufrechterhalten, die sie viel später zu ihrem eigenen Vorteil freigeben. Wenn 33 % der Validatoren ihren Stake zurückziehen, jedoch weiter attestieren und Blöcke produzieren, könnten diese andererseits eine alternative Fork generieren, die mit der kanonischen Chain in Konflikt steht. Neue Nodes oder Nodes, die lange Zeit offline waren, wissen möglicherweise nicht, dass diese angreifenden Validatoren ihre Geldmittel zurückgezogen haben. Angreifer könnten sie also dazu bringen, einer falschen Chain zu folgen. Ethereum kann dieses Problem mit Angriffsvektoren lösen, indem es Beschränkungen auferlegt, die die subjektiven Aspekte des Mechanismus – und damit die Vertrauensannahmen – auf das absolute Minimum reduziert.
+Subjektivität ist bei Proof-of-Stake-Blockchains inhärent, da die Auswahl der korrekten Chain aus mehreren Abspaltungen durch das Zählen historischer Stimmen erfolgt. Dies setzt die Blockchain mehreren Angriffsvektoren aus. Dazu gehören auch Langstreckenangriffe, bei denen Nodes, die sehr früh an der Chain beteiligt waren, eine alternative Abspaltung aufrechterhalten, die sie viel später zu ihrem eigenen Vorteil freigeben. Wenn 33 % der Validatoren ihren Stake zurückziehen, jedoch weiter attestieren und Blöcke produzieren, könnten diese andererseits eine alternative Abspaltung generieren, die mit der kanonischen Chain in Konflikt steht. Neue Nodes oder Nodes, die lange Zeit offline waren, wissen möglicherweise nicht, dass diese angreifenden Validatoren ihre Geldmittel zurückgezogen haben. Angreifer könnten sie also dazu bringen, einer falschen Chain zu folgen. Ethereum kann dieses Problem mit Angriffsvektoren lösen, indem es Beschränkungen auferlegt, die die subjektiven Aspekte des Mechanismus – und damit die Vertrauensannahmen – auf das absolute Minimum reduziert.
 
 ## Checkpoints von schwacher Subjektivität {#ws-checkpoints}
 
@@ -24,7 +24,7 @@ Finalisierte Blöcke und Checkpoints von schwacher Subjektivität werden von Eth
 
 ## Wie schwach ist schwach? {#how-weak-is-weak}
 
-Der subjektive Aspekt von Proof-of-Stake für Ethereum besteht darin, dass ein aktueller Zustand (Checkpoint von schwacher Subjektivität) aus einer vertrauenswürdigen Quelle erforderlich ist, von der aus die Synchronisierung erfolgen kann. Das Risiko, einen schlechten Checkpoint von schwacher Subjektivität zu erhalten, ist sehr gering, da diese anhand mehrerer unabhängiger öffentlicher Quellen wie Block-Explorer oder mehrerer Nodes überprüft werden können. Jedoch ist immer ein gewisses Maß an Vertrauen für die Ausführung jeder Software-Anwendung erforderlich. Zum Beispiel muss den Software-Entwicklern genug Vertrauen entgegengebracht werden, dass sie eine ehrliche Software produziert programmiert haben.
+Der subjektive Aspekt von Proof-of-Stake für Ethereum besteht darin, dass ein aktueller Zustand (Checkpoint von schwacher Subjektivität) aus einer vertrauenswürdigen Quelle erforderlich ist, von der aus die Synchronisierung erfolgen kann. Das Risiko, einen schlechten Checkpoint von schwacher Subjektivität zu erhalten, ist sehr gering, da diese anhand mehrerer unabhängiger öffentlicher Quellen wie Block-Explorer oder mehrerer Nodes überprüft werden können. Jedoch ist immer ein gewisses Maß an Vertrauen für die Ausführung jeder Software-Anwendung erforderlich. Zum Beispiel muss den Software-Entwicklern genug Vertrauen entgegengebracht werden, dass sie eine ehrliche Software programmiert haben.
 
 Ein Checkpoint von schwacher Subjektivität könnte sogar als Teil der Client-Software kommen. Ein Angreifer kann wohl nicht nur den Checkpoint in der Software, sondern genauso leicht auch die Software selbst korrumpieren. Es gibt keinen echten kryptowirtschaftlichen Weg, dieses Problem zu umgehen. Der Einfluss unseriöser Entwickler wird in Ethereum allerdings dadurch minimiert, dass mehrere unabhängige Client-Teams beteiligt sind. Jedes Team entwickelt äquivalente Software in unterschiedlichen Programmiersprachen und hat ein eigenes Interesse daran, eine ehrliche Blockchain aufrechtzuerhalten. Block-Explorer können auch Checkpoints von schwacher Subjektivität oder eine Möglichkeit zum Abgleich von Checkpoints, die von anderer Stelle stammen, mit einer zusätzlichen Quelle bereitstellen.
 

@@ -31,7 +31,7 @@ Die Client-Vielfalt bietet auch eine gewisse Widerstandsfähigkeit gegen Angriff
 
 Ein Fehler in einem Konsensclient mit mehr als 33 % der Ethereum-Knoten könnte verhindern, dass die Konsensebene finalisieren kann. Das bedeutet, dass die Nutzer nicht darauf vertrauen können, dass Transaktionen nicht irgendwann rückgängig gemacht oder geändert werden. Dies wäre für viele der auf Ethereum aufbauenden Anwendungen, insbesondere DeFi, sehr problematisch.
 
-<Emoji text="🚨" me="1rem" /> Schlimmer noch, ein kritischer Fehler in einem Client mit einer Zweidrittelmehrheit könnte dazu führen, dass die Chain <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">nicht korrekt geteilt und finalisiert wird</a>. Dies wiederum würde dazu führen, dass eine große Anzahl von Validatoren auf einer ungültigen Chain stecken bleibt. Wenn sie sich der korrekten Chain wieder anschließen möchten, müssen diese Validatoren mit Slashing oder einem langsamen und teuren freiwilligen Rückzug und Reaktivierung rechnen. Das Ausmaß eines Slashings skaliert mit der Anzahl der schuldigen Knoten, wobei maximal eine Zweidrittelmehrheit geslashed werden kann (32 ETH).
+<Emoji text="🚨" className="me-4" /> Schlimmer noch, ein kritischer Fehler in einem Client mit einer Zweidrittelmehrheit könnte dazu führen, dass die Chain <a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">nicht korrekt geteilt und finalisiert wird</a>. Dies wiederum würde dazu führen, dass eine große Anzahl von Validatoren auf einer ungültigen Chain stecken bleibt. Wenn sie sich der korrekten Chain wieder anschließen möchten, müssen diese Validatoren mit Slashing oder einem langsamen und teuren freiwilligen Rückzug und Reaktivierung rechnen. Das Ausmaß eines Slashings skaliert mit der Anzahl der schuldigen Knoten, wobei maximal eine Zweidrittelmehrheit geslashed werden kann (32 ETH).
 
 Obwohl dies unwahrscheinliche Szenarien sind, kann das Ethereum-Ökosystem das Risiko mindern, indem es die Verteilung der Clients auf die aktiven Knoten ausgleicht. Im Idealfall würde kein Konsensclient jemals einen Anteil von 33 % an der Gesamtzahl der Nodes erreichen.
 

@@ -46,6 +46,7 @@ Es gibt mehrere Tracker, die einen Echtzeit-Überblick über die Knoten im Ether
 - [Karte der Knotenpunkte](https://etherscan.io/nodetracker) von Etherscan
 - [Ethernodes](https://ethernodes.org/) von Bitfly
 - [Nodewatch](https://www.nodewatch.io/) von Chainsafe, Crawler für Konsensknoten
+- [Monitoreth](https://monitoreth.io/) – von MigaLabs, ein Netzwerküberwachungstool für verteilte Netzwerke
 
 ## Node-Typen {#node-types}
 
@@ -197,6 +198,7 @@ Es gibt mehrere Konsensclients (früher als „Eth2“-Clients bekannt), die daz
 | [Nimbus](https://nimbus.team/)                                | Nim        | Linux, Windows, MacOS | Beacon Chain, Goerli, Sepolia, Ropsten und weitere                  |
 | [Prysm](https://docs.prylabs.network/docs/getting-started/)   | Los        | Linux, Windows, MacOS | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten und weitere |
 | [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java       | Linux, Windows, MacOS | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten und weitere          |
+| [Grandine](https://docs.grandine.io/) (Beta)                  | Rust       | Linux, Windows, MacOS | Beacon Chain, Goerli, Sepolia und mehr                              |
 
 ### Lighthouse {#lighthouse}
 
@@ -230,6 +232,12 @@ Teku bietet sehr flexible Einsatzmöglichkeiten. Der Beacon Node und der Validat
 
 Teku ist in Java unter der Apache 2.0 Lizenz geschrieben. Es wird vom Protokoll-Team bei ConsenSys entwickelt, das auch für Besu und Web3Signer verantwortlich ist. Erfahren Sie mehr in den [Teku-Docs](https://docs.teku.consensys.net/en/latest/).
 
+### Grandine {#grandine}
+
+Grandine ist eine Konsens-Client-Implementierung, geschrieben in Rust und unter der GPL-3.0-Lizenz. Es wird vom Grandine Core Team gepflegt und ist schnell, leistungsstark und leicht. Es ist für eine Vielzahl von Stakern geeignet – von Einzelstakern, die ressourcenarme Geräte wie Raspberry Pi verwenden, bis hin zu großen institutionellen Stakern, die Zehntausende von Validatoren betreiben.
+
+Die entsprechende Dokumentation finden Sie im [Grandine Book](https://docs.grandine.io/)
+
 ## Synchronisationsmodi {#sync-modes}
 
 Um die aktuellen Daten im Netzwerk zu verfolgen und zu überprüfen, muss sich der Ethereum-Client mit dem neuesten Netzwerkstatus synchronisieren. Dazu werden Daten von Peers heruntergeladen, wobei ihre Integrität kryptographisch verifiziert und eine lokale Blockchain-Datenbank aufgebaut wird.

@@ -44,7 +44,7 @@ Es befinden sich mehrere leichte Clients in der Entwicklung, darunter Ausführun
 
 - [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): leichter Konsensclient in TypeScript
 - [Helios](https://github.com/a16z/helios): kombinierter leichter Ausführungs- und Konsensclient in Rust
-- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): Light-Modus für Ausführungsclient (in Entwicklung) in Go
+- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): Light-Modus für Ausführungs-Client (in Entwicklung) in Go
 - [Nimbus](https://nimbus.guide/el-light-client.html): Leichter Konsensclient in Nim
 
 Unseres Wissens nach ist noch keiner dieser Clients produktionsreif.