@@ -32,7 +32,7 @@ Staking erfüllt einen ähnlichen Zweck wie einst [Mining](/developers/docs/cons
Der Wechsel zu Proof-of-Stake machte Ethereum wesentlich sicherer und dezentralisierte im Vergleich zu Proof-of-Work. Je mehr Menschen sich am Netzwerk beteiligen, desto dezentralisierter und sicherer wird es vor Angriffen.
-Und die Verwendung von Proof-of-Stake als Konsensmechanismus ist eine grundlegende Komponente für [das sichere, umweltfreundliche und skalierbare Ethereum, das wir jetzt haben](/roadmap/vision/).
+Und die Verwendung von Proof-of-Stake als Konsensmechanismus ist eine grundlegende Komponente für [das sichere, umweltfreundliche und skalierbare Ethereum, das wir jetzt haben](/staking/).
diff --git a/public/content/translations/de/roadmap/danksharding/index.md b/public/content/translations/de/roadmap/danksharding/index.md
index b5cf55a83fe..e7786416458 100644
--- a/public/content/translations/de/roadmap/danksharding/index.md
+++ b/public/content/translations/de/roadmap/danksharding/index.md
@@ -1,6 +1,6 @@
---
title: Danksharding
-description: Erfahre mehr über Proto-Danksharding und Danksharding - zwei aufeinanderfolgende Upgrades zur Skalierung von Ethereum.
+description: "Erfahre mehr über Proto-Danksharding und Danksharding - zwei aufeinanderfolgende Upgrades zur Skalierung von Ethereum."
lang: de
summaryPoints:
- Danksharding ist ein mehrphasiges Upgrade, um die Skalierbarkeit und Kapazität von Ethereum zu verbessern.
@@ -22,13 +22,11 @@ Das ist kostspielig, da dies von allen Ethereum-Knoten verarbeitet wird und für
Rollups sind eine Möglichkeit, Ethereum zu skalieren, indem Transaktionen außerhalb der Kette gebündelt und dann die Ergebnisse zu Ethereum gepostet werden. Ein Rollup besteht im Wesentlichen aus zwei Teilen: Daten und Ausführungsprüfung. Die Daten sind die vollständige Abfolge von Transaktionen, die von einem Rollup verarbeitet werden, um die Zustandsänderung zu erzeugen, die zu Ethereum gepostet wird. Die Ausführungsprüfung ist die Wiederholung dieser Transaktionen durch einen ehrlichen Akteur (einen "Prover"), um sicherzustellen, dass die vorgeschlagene Zustandsänderung korrekt ist. Um die Ausführungsprüfung durchführen zu können, müssen die Transaktionsdaten lange genug verfügbar sein, damit sie von jedem heruntergeladen und überprüft werden können. Das bedeutet, dass jedes unehrliche Verhalten des Rollup-Sequenzierers vom Beweiser erkannt und herausgefordert werden kann. Allerdings muss es nicht für immer verfügbar sein.
-
Rollups posten Verpflichtungen zu ihren Transaktionsdaten on-chain und stellen die tatsächlichen Daten auch in Datenblobs zur Verfügung. Das bedeutet, dass Beweiser überprüfen können, ob die Verpflichtungen gültig sind, oder Daten herausfordern können, von denen sie glauben, dass sie falsch sind. Auf Node-Ebene werden die Datenblobs im Konsens-Client gehalten. Die Konsens-Clients bezeugen, dass sie die Daten gesehen haben und dass sie im Netzwerk verbreitet wurden. Wenn die Daten für immer aufbewahrt würden, würden diese Clients aufgebläht und zu hohen Hardwareanforderungen für den Betrieb von Nodes führen. Stattdessen werden die Daten alle 18 Tage automatisch aus dem Knoten gelöscht. Die Beglaubigungen des Konsens-Clients belegen, dass Beweisende ausreichend Gelegenheit hatten, die Daten zu überprüfen. Die tatsächlichen Daten können außerhalb der Kette von Rollup-Betreibern, Benutzern oder anderen gespeichert werden.
-
### Wie werden Blob-Daten überprüft? {#how-are-blobs-verified}
@@ -48,13 +46,11 @@ Die EIP-4844 KZG-Zeremonie war für die Öffentlichkeit zugänglich. Zehntausend
Wenn ein Rollup Daten in einem Blob veröffentlicht, geben diese ein „Commitment“ ab, diese „on-chain“ zu veröffentlichen. Dieses Commitment ist das Ergebnis der Auswertung eines an die Daten angepassten Polynoms an bestimmten Punkten. Diese Punkte werden durch die in der KZG-Zeremonie erzeugten Zufallszahlen definiert. Beweiser können dann das Polynom an denselben Punkten auswerten, um die Daten zu überprüfen - wenn sie zu denselben Werten kommen, dann sind die Daten korrekt.
-
Das ist korrekt. Wenn jemand die zufälligen Punkte kennt, die für das Commitment verwendet werden, könnte er tatsächlich ein neues Polynom erstellen, das an diesen spezifischen Punkten passt (also eine "Kollision" erzeugen). Das bedeutet, sie könnten Daten zum Blob hinzufügen oder daraus entfernen und dennoch einen gültigen Nachweis liefern. Um dies zu verhindern, erhalten die Beweiser statt der tatsächlichen geheimen Positionen diese Positionen eingehüllt in eine kryptographische "Black Box" unter Verwendung elliptischer Kurven. Diese verzerren die Werte effektiv auf eine Weise, dass die ursprünglichen Werte nicht rückentwickelt werden können, aber mit einiger cleverer Algebra können Beweiser und Verifizierer immer noch Polynome an den Punkten auswerten, die sie repräsentieren.
-
@@ -70,13 +66,11 @@ Dies funktioniert, indem die an die Blöcke angehängten Blobs von sechs (6) bei
Die Trennung von Vorschlagenden und Erstellenden ist notwendig, um zu verhindern, dass einzelne Validatoren teure Verpflichtungen und Nachweise für 32MB Blob-Daten erzeugen müssen. Dies würde zu einer zu großen Belastung für Heim-Staker führen und sie dazu zwingen, in leistungsfähigere Hardware zu investieren, was die Dezentralisierung beeinträchtigen würde. Stattdessen übernehmen spezialisierte Blockersteller die Verantwortung für diese aufwändige Rechenarbeit. Dann stellen sie ihre Blöcke den Blockvorschlägern zur Verfügung, um sie zu senden. Der Blockvorschläger wählt einfach den Block aus, der am rentabelsten ist. Jeder kann die Blobs kostengünstig und schnell überprüfen, was bedeutet, dass jeder normale Validator überprüfen kann, ob die Blockersteller ehrlich handeln. Dies ermöglicht die Verarbeitung der großen Blobs, ohne die Dezentralisierung zu opfern. Block Builder, die sich schlecht verhalten, könnten einfach aus dem Netzwerk geworfen und bestraft werden - andere würden ihren Platz einnehmen, weil Block Building eine profitable Tätigkeit ist.
-
Validators only have to download a small piece of each blob in order to verify its availability, rather than the entire thing. Mithilfe des Data Availability Samplings können die Validatoren sehr sicher sein, dass die Blob-Daten verfügbar waren und korrekt bestätigt wurden. Jeder Validator kann zufällig nur einige Datenpunkte abrufen und einen Nachweis erstellen, was bedeutet, dass kein Validator den gesamten Blob überprüfen muss. Fehlen irgendwelche Daten, wird dies schnell erkannt und der Blob abgelehnt.
-
### Aktueller Fortschritt {#current-progress}
diff --git a/public/content/translations/de/roadmap/dencun/index.md b/public/content/translations/de/roadmap/dencun/index.md
index ea2b15a9f44..491da05bd91 100644
--- a/public/content/translations/de/roadmap/dencun/index.md
+++ b/public/content/translations/de/roadmap/dencun/index.md
@@ -1,14 +1,14 @@
---
title: FAQs zu Cancun-Deneb (Dencun)
-description: Häufig gestellte Fragen zum Netzwerk-Upgrade Cancun-Deneb (Dencun)
+description: "Häufig gestellte Fragen zum Netzwerk-Upgrade Cancun-Deneb (Dencun)"
lang: de
---
# Cancun-Deneb (Dencun) {#dencun}
-Cancun-Deneb (Dencun) ist ein Upgrade des Ethereum-Netzwerks, bei dem **Proto-Danksharding (EIP-4844)** aktiviert wird. Im Zuge dessen werden temporäre Daten **Blobs** für günstigere [Layer 2 (L2)](/Glossar/#layer-2)-Rollup-Speicherung einführt.
+Cancun-Deneb (Dencun) ist ein Upgrade des Ethereum-Netzwerks, bei dem **Proto-Danksharding (EIP-4844)** aktiviert wird. Im Zuge dessen werden temporäre Daten **Blobs** für günstigere [Layer 2 (L2)](/glossary/#layer-2)-Rollup-Speicherung einführt.
-Ein neuer Transaktionstyp ermöglicht es Rollup-Anbietern, Daten kostengünstiger in sogenannten „Blobs“ zu speichern. Diese Blobs stehen dem Netzwerk etwa 18 Tage lang garantiert zur Verfügung (genauer gesagt 4096 [Epochen](/Glossar/#epoch)). Nach Ablauf dieser Zeit werden die Blobs aus dem Netzwerk entfernt, aber die Anwendungen können die Gültigkeit ihrer Daten immer noch mithilfe von Nachweisen verifizieren.
+Ein neuer Transaktionstyp ermöglicht es Rollup-Anbietern, Daten kostengünstiger in sogenannten „Blobs“ zu speichern. Diese Blobs stehen dem Netzwerk etwa 18 Tage lang garantiert zur Verfügung (genauer gesagt 4096 [Epochen](/glossary/#epoch)). Nach Ablauf dieser Zeit werden die Blobs aus dem Netzwerk entfernt, aber die Anwendungen können die Gültigkeit ihrer Daten immer noch mithilfe von Nachweisen verifizieren.
Dies senkt die Kosten für Rollups erheblich, begrenzt das Wachstum der Chain und sorgt dafür, das mehr Nutzer unterstützt werden. Gleichzeitig bleibt die Sicherheit und eine dezentralisierte Gruppe von Knotenpunktbetreibern erhalten.
@@ -23,7 +23,7 @@ Dies senkt die Kosten für Rollups erheblich, begrenzt das Wachstum der Chain un
- **Kein Handlungsbedarf für Ihre ETH**: Nach dem Upgrade Ethereum Dencun besteht keine Notwendigkeit, Ihre ETH umzuwandeln oder zu aktualisieren. Ihre Kontoguthaben bleiben unverändert und die ETH, die Sie derzeit besitzen, bleiben auch nach dem Hard Fork in der bestehenden Form zugänglich.
- **Vorsicht vor Betrug!** **Jeder, der Sie anweist, Ihre ETH zu „aktualisieren“, versucht, Sie zu betrügen.** Es gibt nichts, was Sie in Bezug auf dieses Upgrade tun müssen. Ihre Assets bleiben davon völlig unberührt. Denken Sie daran: Informiert zu sein ist der beste Schutz vor Betrug.
-[Mehr zur Erkennung und Vermeidung von Betrug](/Sicherheit/)
+[Mehr zur Erkennung und Vermeidung von Betrug](/security/)
## Welches Problem wird durch das Update des Dencun-Netzwerks gelöst? {#network-impact}
@@ -31,7 +31,7 @@ Dencun zielt in erster Linie auf **Skalierbarkeit** (Handhabung von mehr Nutzern
Die Ethereum-Community hat sich für ihr Wachstum für einen „Rollup-zentrierten“ Ansatz entschlossen, bei dem Layer-2-Rollups das wichtigste Mittel für die sichere Unterstützung von mehr Nutzern sind.
-Rollup-Netzwerke wickeln die _Verarbeitung_ (oder „Ausführung“) von Transaktionen getrennt vom Mainnet ab und veröffentlichen dann zur Aufbewahrung einen kryptografischen Beweis und/oder komprimierte Transaktionsdaten der Ergebnisse zurück im Mainnet. Die Speicherung dieser Nachweise ist mit Kosten verbunden (in Form von [Gas](/Glossar/#gas)). Diese mussten vor dem Proto-Danksharding von allen Betreibern von Netzwerkknoten dauerhaft gespeichert werden, was eine teure Angelegenheit ist.
+Rollup-Netzwerke wickeln die _Verarbeitung_ (oder „Ausführung“) von Transaktionen getrennt vom Mainnet ab und veröffentlichen dann zur Aufbewahrung einen kryptografischen Beweis und/oder komprimierte Transaktionsdaten der Ergebnisse zurück im Mainnet. Die Speicherung dieser Nachweise ist mit Kosten verbunden (in Form von [Gas](/glossary/#gas)). Diese mussten vor dem Proto-Danksharding von allen Betreibern von Netzwerkknoten dauerhaft gespeichert werden, was eine teure Angelegenheit ist.
Durch die Einführung von Proto-Danksharding im Dencun-Upgrade wird die Datenspeicherung für diese Nachweise kostengünstiger, da die Betreiber der Knoten diese Daten nur noch etwa 18 Tage lang speichern müssen. Nach diesem Zeitraum können die Daten sicher entfernt werden, um eine Ausweitung der Hardwareanforderungen zu verhindern. Da Rollups in der Regel eine Abhebungsfrist von 7 Tagen haben, bleibt ihr Sicherheitsmodell unverändert, solange Blobs für diesen Zeitraum auf L1 verfügbar sind. Das 18-tägige Zeitfenster für die Löschung bietet einen erheblichen Puffer für diesen Zeitraum.
diff --git a/public/content/translations/de/roadmap/future-proofing/index.md b/public/content/translations/de/roadmap/future-proofing/index.md
index 35b62cfdef6..36534c2e129 100644
--- a/public/content/translations/de/roadmap/future-proofing/index.md
+++ b/public/content/translations/de/roadmap/future-proofing/index.md
@@ -1,6 +1,6 @@
---
title: Zukunftssicherung von Ethereum
-description: Diese Verbesserungen festigen Ethereum als widerstandsfähige und dezentrale Grundlage für die ungewisse Zukunft.
+description: "Diese Verbesserungen festigen Ethereum als widerstandsfähige und dezentrale Grundlage für die ungewisse Zukunft."
lang: de
image: /images/roadmap/roadmap-future.png
alt: "Ethereum-Roadmap"
diff --git a/public/content/translations/de/roadmap/merge/index.md b/public/content/translations/de/roadmap/merge/index.md
index 604930744fd..ac9b61a1fdd 100644
--- a/public/content/translations/de/roadmap/merge/index.md
+++ b/public/content/translations/de/roadmap/merge/index.md
@@ -1,13 +1,13 @@
---
-title: Die Zusammenführung
-description: Erfahren Sie mehr über die Zusammenführung, als Mainnet Ethereum Proof-of-Stake einführte.
+title: "Die Zusammenführung"
+description: "Erfahren Sie mehr über die Zusammenführung, als Mainnet Ethereum Proof-of-Stake einführte."
lang: de
template: upgrade
image: /images/upgrades/merge.png
alt:
summaryPoint1: Im Ethereum Mainnet wird Proof-of-Stake verwendet, aber dies war nicht immer der Fall.
-summaryPoint2: Der Wechsel vom ursprünglichen Proof-of-Work-Mechanismus zu Proof-of-Stake wurde The Merge genannt.
-summaryPoint3: The Merge bezieht sich darauf, dass das ursprüngliche Ethereum Mainnet mit einer separaten Proof-of-Stake-Blockchain namens Beacon Chain zusammengeführt wurde und somit nun beide als eine Blockchain existieren.
+summaryPoint2: "Der Wechsel vom ursprünglichen Proof-of-Work-Mechanismus zu Proof-of-Stake wurde The Merge genannt."
+summaryPoint3: "The Merge bezieht sich darauf, dass das ursprüngliche Ethereum Mainnet mit einer separaten Proof-of-Stake-Blockchain namens Beacon Chain zusammengeführt wurde und somit nun beide als eine Blockchain existieren."
summaryPoint4: Nach The Merge reduzierte sich Ethereums Energieverbrauch um ~99,95 %.
---
@@ -88,7 +88,6 @@ Schlüssel-Aktionen beinhalten:
- Authentifizieren Sie die Ausführung und Konsens-Clients mit einem gemeinsam genutzten JWT-Geheimnis, so dass sie sicher miteinander kommunizieren können.
Wenn Sie die ersten beiden obigen Elemente nicht abschließen, wird Ihre Node als "offline" betrachtet, bis beide Ebenen synchronisiert und authentifiziert sind.
-
Weitere Informationen findest Du in diesem Blogartikel von Tim Heiko zum Thema The Merge Update: Welche Auswirkungen hat das Ereignis auf die Ethereum-Execution Layer?.
-
## Die Zusammenführung und der Energieverbrauch {#merge-and-energy}
@@ -116,7 +114,7 @@ The Merge markierte das Ende von Proof-of-Work für Ethereum und läutete die Ä
## Die Zusammenführung und Skalierbarkeit {#merge-and-scaling}
-Die Zusammenführung ebnet auch den Weg für weitere Skalierungsupgrades, welche unter Proof-of-Work nicht möglich waren. Dies bringt Ethereum einen Schritt näher die volle Skalierung, Sicherheit und Nachhaltigkeit zu erreichen, die in der [Ethereum Vision](/roadmap/vision/) beschrieben ist.
+Die Zusammenführung ebnet auch den Weg für weitere Skalierungsupgrades, welche unter Proof-of-Work nicht möglich waren. Dies bringt Ethereum einen Schritt näher die volle Skalierung, Sicherheit und Nachhaltigkeit zu erreichen, die in der [Ethereum Vision](/energy-consumption/) beschrieben ist.
## Misverständnisse über die Zusammenführung {#misconceptions}
@@ -135,7 +133,6 @@ Jeder kann einen Knoten betreiben, der allerdings nicht erlaubt, andere Blöcke
Die Möglichkeit für jeden, einen eigenen Node zu betreiben, ist absolut essentiell zur Aufrechterhaltung der Dezentralisierung des Ethereum-Netzwerks.
[Mehr zum Betrieb eines eigenen Nodes](/run-a-node/)
-
Rollup-zentrierten Roadmap, die Bemühungen konzentrieren sich auf die Ausweitung der Nutzeraktivitäten auf [Ebene 2](/layer-2/), und gleichzeitig das Ebene 1 Mainnet als sichere dezentrale Abwicklungsschicht zu etablieren, die für die Speicherung von Rollup-Daten optimiert ist und dazu beiträgt, Rollup-Transaktionen exponentiell billiger zu machen. Der Übergang zu Proof-of-Stake ist ein entscheidender Vorläufer für die Umsetzung. [Mehr zum Thema Gas-Kosten.](/developers/docs/gas/)
-
Abhebungsadresse um automatische Auszahlungen von überschüssigem für Staking eingesetzten ETH zu erhalten (ETH über 32 aus Protokollbelohnungen). Mit diesem Upgrade wurde auch die Möglichkeit geschaffen, dass ein Validator sein gesamtes Guthaben beim Verlassen des Netzwerkes entsperren und zurückfordern kann.
[Mehr zu Staking-Auszahlungen](/staking/withdrawals/)
-
-
-- Vor der Umstellung auf Proof-of-Stake erhielten Miner etwa 13.000 ETH/Tag
-- Staker erhalten etwa 1.700 ETH/Tag, basierend auf etwa 14 Millionen insgesamt gestakten ETH
-- Die genaue Staking-Ausgabe schwankt je nach der Gesamtmenge an gestakten ETH
-- Seit The Merge bleibt nur noch die ~1.700 ETH/Tag, wodurch die gesamte neue ETH-Ausgabe um ~88% gesunken ist
-- Das Verbrennen: Dies schwankt je nach Netzwerkanforderung. _Wenn_ für einen bestimmten Tag ein durchschnittlicher Gaspreis von mindestens 16 Gwei beobachtet wird, kompensiert dies effektiv die ~1.700 ETH, die an die Validatoren ausgegeben werden, und bringt die Netto-ETH-Inflation für diesen Tag auf Null oder weniger.
+title="ETH-Emission kurz erklärt">
+- Vor dem Übergang zu Proof-of-Stake betrug die Emission für Miner ungefähr 13.000 ETH/Tag.
+- Die Emission für Staker beträgt ungefähr 1.700 ETH/Tag, basierend auf insgesamt etwa 14 Millionen gestaketen ETH.
+- Die genaue Staking-Emission schwankt je nach der Gesamtmenge der gestaketen ETH.
+- **Seit The Merge verbleiben nur noch die ~1.700 ETH/Tag, wodurch die gesamte neue ETH-Emission um ~88 % sinkt.**
+- Die Verbrennung: Diese schwankt je nach Netzwerknachfrage. _Wenn_ für einen bestimmten Tag ein durchschnittlicher Gaspreis von mindestens 16 Gwei beobachtet wird, kompensiert dies effektiv die ~1.700 ETH, die an die Validatoren ausgegeben werden, und bringt die Netto-ETH-Inflation für diesen Tag auf Null oder weniger.
## Vor dem Merge (historisch) {#pre-merge}
-### Ausgabe auf der Ausführungsschicht {#el-issuance-pre-merge}
+### Emission der Ausführungsebene {#el-issuance-pre-merge}
-Unter dem Proof-of-Work-System interagierten die Miner nur mit der Ausführungsschicht und wurden mit Blockbelohnungen belohnt, wenn sie die ersten Miner waren, die den nächsten Block gelöst haben. Seit dem [Constantinople-Upgrade](/ethereum-forks/#constantinople) im Jahr 2019 betrug diese Belohnung 2 ETH pro Block. Miner wurden auch für die Veröffentlichung von [Ommer-Blöcken](/glossary/#ommer) belohnt, das waren gültige Blöcke, die nicht in der längsten/kanonischen Kette landeten. Diese Belohnungen erreichten maximal 1,75 ETH pro Ommer und wurden zusätzlich zu der Belohnung aus dem kanonischen Block ausgegeben. Das Mining war eine wirtschaftlich intensive Tätigkeit, die historisch gesehen ein hohes Niveau an ETH-Ausgabe erforderte, um sie aufrechtzuerhalten.
+Unter dem Proof-of-Work-System interagierten die Miner nur mit der Ausführungsschicht und wurden mit Blockbelohnungen belohnt, wenn sie die ersten Miner waren, die den nächsten Block gelöst haben. Seit dem [Constantinople-Upgrade](/ethereum-forks/#constantinople) im Jahr 2019 betrug diese Belohnung 2 ETH pro Block. Miner wurden auch für die Veröffentlichung von [ommer](/glossary/#ommer)-Blöcken belohnt, das waren gültige Blöcke, die nicht in der längsten/kanonischen Kette landeten. Diese Belohnungen betrugen maximal 1,75 ETH pro Ommer und wurden _zusätzlich zu_ der Belohnung aus dem kanonischen Block emittiert. Das Mining war eine wirtschaftlich intensive Tätigkeit, die historisch gesehen ein hohes Niveau an ETH-Ausgabe erforderte, um sie aufrechtzuerhalten.
-### Ausgabe der Konsensschicht {#cl-issuance-pre-merge}
+### Emission der Konsensebene {#cl-issuance-pre-merge}
-Die [Beacon Chain](/ethereum-forks/#beacon-chain-genesis) wurde 2020 gestartet. Anstelle von Minern wird sie durch Validatoren mittels Proof-of-Stake gesichert. Diese Kette wurde initiiert, indem Ethereum-Nutzer ETH in einen Smart Contract auf dem Mainnet (der Ausführungsschicht) einzahlten. Die Beacon Chain reagiert darauf und schreibt den Nutzern eine entsprechende Menge ETH auf der neuen Kette gut. Bis zur Durchführung von The Merge verarbeiteten die Validatoren der Beacon Chain keine Transaktionen und kamen im Wesentlichen zu einem Konsens über den Zustand des Validator-Pools selbst.
+Die [Beacon Chain](/ethereum-forks/#beacon-chain-genesis) ging 2020 live. Anstelle von Minern wird sie durch Validatoren mittels Proof-of-Stake gesichert. Diese Kette wurde initiiert, indem Ethereum-Nutzer ETH in einen Smart Contract auf dem Mainnet (der Ausführungsschicht) einzahlten. Die Beacon Chain reagiert darauf und schreibt den Nutzern eine entsprechende Menge ETH auf der neuen Kette gut. Bis zur Durchführung von The Merge verarbeiteten die Validatoren der Beacon Chain keine Transaktionen und kamen im Wesentlichen zu einem Konsens über den Zustand des Validator-Pools selbst.
-Validatoren auf der Beacon Chain werden mit ETH belohnt, wenn sie den Zustand der Kette bestätigen und Blöcke vorschlagen. Belohnungen (oder Strafen) werden bei jedem Zeitalter (alle 6,4 Minuten) basierend auf der Leistung der Validatoren berechnet und verteilt. Die Belohnungen für Validatoren sind erheblich geringer als die zuvor unter dem Proof-of-Work-Verfahren ausgeschütteten Mining-Belohnungen (2 ETH alle etwa 13,5 Sekunden), da der Betrieb eines Validierungsknotens nicht so wirtschaftlich intensiv ist und daher keine so hohe Belohnung erfordert oder rechtfertigt.
+Validatoren auf der Beacon Chain werden mit ETH belohnt, wenn sie den Zustand der Kette bestätigen und Blöcke vorschlagen. Belohnungen (oder Strafen) werden bei jedem Zeitalter (alle 6,4 Minuten) basierend auf der Leistung der Validatoren berechnet und verteilt. Die Belohnungen für Validatoren sind **deutlich** geringer als die Mining-Belohnungen, die zuvor unter Proof-of-Work emittiert wurden (2 ETH alle ~13,5 Sekunden), da der Betrieb eines Validierungsknotens wirtschaftlich nicht so intensiv ist und daher keine so hohe Belohnung erfordert oder rechtfertigt.
-### Die Verteilung der Ausgabe vor dem Merge lässt sich wie folgt darstellen: {#pre-merge-issuance-breakdown}
+### Aufschlüsselung der Emissionen vor dem Merge {#pre-merge-issuance-breakdown}
-Gesamt ETH Angebot: **~120,520,000 ETH** (zum Zeitpunkt von The Merge im September 2022)
+Gesamtes ETH-Angebot: **~120.520.000 ETH** (zum Zeitpunkt von The Merge im September 2022)
-**Ausgabe in der Ausführungsschicht:**
+**Ausgabe der Ausführungs-Ebene:**
-- Wurde auf 2,08 ETH pro 13,3 Sekunden* geschätzt: **~4,930,000** ETH wurden in einem Jahr ausgegeben
-- Führte zu einer Inflationsrate von **etwa 4.09%** (4,93 Mio. pro Jahr / 120,5 Mio. Gesamt)
-- \*Dies beinhaltet die 2 ETH pro kanonischem Block, plus durchschnittlich 0,08 ETH über die Zeit von Ommer-Blöcken. Es verwendet auch 13,3 Sekunden, die Zielzeit für den Baseline-Block ohne jeglichen Einfluss durch eine ["Difficulty Bomb"](/glossary/#difficulty-bomb). ([Siehe Quelle](https://bitinfocharts.com/ethereum/))
+- Wurde auf 2,08 ETH pro 13,3 Sekunden\* geschätzt: **~4.930.000** ETH pro Jahr emittiert
+- Ergab eine Inflationsrate von **ungefähr 4,09 %** (4,93 Mio. pro Jahr / 120,5 Mio. gesamt)
+- \*Dies beinhaltet die 2 ETH pro kanonischem Block, plus durchschnittlich 0,08 ETH über die Zeit von Ommer-Blöcken. Verwendet ebenfalls 13,3 Sekunden, die angestrebte Basis-Blockzeit ohne jeglichen Einfluss durch eine [Difficulty Bomb](/glossary/#difficulty-bomb). ([Quelle ansehen](https://bitinfocharts.com/ethereum/))
**Konsensschicht-Ausgabe:**
-- Bei insgesamt 14.000.000 gestakten ETH beträgt die Rate der ETH-Ausgabe etwa 1700 ETH/Tag ([Quelle siehe hier](https://ultrasound.money/))
-- Ergibt **~620,500** ETH herausgegeben in einem Jahr
-- Daraus ergibt sich eine Inflationsrate von **ungefähr 0.52%** (620.5K pro Jahr / 119.3M insgesamt)
+- Bei insgesamt 14.000.000 gestaketen ETH beträgt die ETH-Emissionsrate ungefähr 1700 ETH/Tag ([Quelle ansehen](https://ultrasound.money/))
+- Ergibt **~620.500** ETH, die pro Jahr emittiert werden
+- Ergab eine Inflationsrate von **ungefähr 0,52 %** (620,5 Tsd. pro Jahr / 119,3 Mio. gesamt)
-**Jährlicher Gesamtausgabesatz (Pre-Merge): ~4.61%** (4.09% + 0.52%)
+**Gesamte annualisierte Emissionsrate (vor dem Merge): ~4,61 %** (4,09 % + 0,52 %)
-**~88.7%** der Ausgabe ging an die Miner auf der Ausführungs-Ebene (4.09 / 4.61 * 100)
+**~88,7 %** der Emission ging an Miner auf der Ausführungsebene (4,09 / 4,61 \* 100)
-**~11.3%** wurde an Staker auf der Konsensus-Ebene ausgegeben (0.52 / 4.61 * 100)
+**~11,3 %** wurden an Staker auf der Konsensebene emittiert (0,52 / 4,61 \* 100)
+
+
-## Post-Merge (Gegenwart) {#post-merge}
+## Nach dem Merge (heute) {#post-merge}
-### Ausgabe auf der Ausführungsschicht {#el-issuance-post-merge}
+### Emission der Ausführungsebene {#el-issuance-post-merge}
-Ausgabe auf der Ausführungs-Ebene seit dem Merge ist Null. Proof-of-Work ist nach den verbesserten KonsensusRegeln kein gültiges Mittel zur Blockproduktion mehr. Alle Aktivitäten der Ausführungsebene werden in "Beacon-Blöcke" verpackt, die veröffentlicht und von Proof-of-Stake-Validatoren bestätigt werden. Belohnungen für die Bescheinigung und Veröffentlichung von Beacon-Blöcken werden auf der Konsensus-Ebene separat berücksichtigt.
+Die Emission der Ausführungsebene seit The Merge ist null. Proof-of-Work ist nach den aktualisierten Konsensregeln kein gültiges Mittel zur Blockproduktion mehr. Alle Aktivitäten der Ausführungsebene werden in „Beacon-Blöcke“ verpackt, die von Proof-of-Stake-Validatoren veröffentlicht und bezeugt werden. Belohnungen für das Bezeugen und Veröffentlichen von Beacon-Blöcken werden auf der Konsensebene separat verbucht.
-### Ausgabe der Konsensschicht {#cl-issuance-post-merge}
+### Emission der Konsensebene {#cl-issuance-post-merge}
-Die Ausgabe der Konsensus-Ebene wird heute wie vor dem Merge fortgesetzt, mit kleinen Belohnungen für Validatoren, die Blöcke bestätigen und vorschlagen. Validatoren-Belohnungen fließen weiterhin in _Validatoren-Guthaben_ ein, die innerhalb der Konsensus-Ebene verwaltet werden. Im Gegensatz zu den laufenden Konten ("Ausführungskonten"), die im Mainnet Transaktionen durchführen können, sind diese separaten Ethereum-Konten nicht in der Lage, frei mit anderen Ethereum-Konten zu handeln. Die Gelder auf diesen Konten können nur an eine einzige angegebene Ausführungsadresse abgehoben werden.
+Die Emission der Konsensebene wird heute wie vor The Merge fortgesetzt, mit kleinen Belohnungen für Validatoren, die Blöcke bezeugen und vorschlagen. Validatoren-Belohnungen fließen weiterhin in _Validatoren-Guthaben_, die innerhalb der Konsensebene verwaltet werden. Im Gegensatz zu den aktuellen Konten („Ausführungskonten“), mit denen auf dem Mainnet Transaktionen durchgeführt werden können, können diese separaten Ethereum-Konten keine freien Transaktionen mit anderen Ethereum-Konten durchführen. Die Gelder auf diesen Konten können nur an eine einzige angegebene Ausführungsadresse abgehoben werden.
-Seit des Shanghai/Capella Upgrades im April 2023 sind diese Rücknahmen für Staker möglich. Für Staker besteht ein Anreiz, ihre _Gewinne/Belohnungen (Guthaben über 32 ETH)_ zu entfernen, da diese Gelder ansonsten nicht zu ihren Einsätzen (die maximal 32 beträgt) beitragen.
+Seit dem Shanghai/Capella-Upgrade, das im April 2023 stattfand, sind diese Abhebungen für Staker möglich. Staker haben einen Anreiz, ihre _Erträge/Belohnungen (Guthaben über 32 ETH)_ abzuheben, da diese Gelder andernfalls nicht zu ihrer Stake-Gewichtung beitragen (die bei 32 gedeckelt ist).
Die Staker können sich auch dafür entscheiden, auszusteigen und ihr gesamtes Validatoren-Guthaben abzuheben. Um die Stabilität von Ethereum zu gewährleisten, ist die Anzahl der gleichzeitig ausscheidenden Validatoren begrenzt.
-Etwa 0,33 % der Gesamtzahl der Validatoren können an einem bestimmten Tag ausscheiden. Standardmäßig können vier (4) Validatoren pro Epoche aussteigen (alle 6,4 Minuten oder 900 pro Tag). Ein weiterer (1) Validator darf für jeden 65,536 (216) zusätzlichen Validator über 262,144 (218) aussteigen. Bei über 327.680 Validatoren können zum Beispiel fünf (5) pro Epoche (1.125 pro Tag) ausscheiden. Sechs (6) werden zugelassen, wenn die Gesamtzahl der aktiven Validatoren 393.216 übersteigt, und so weiter.
+Ungefähr 0,33 % der Gesamtzahl der Validatoren können an einem bestimmten Tag aussteigen. Standardmäßig können vier (4) Validatoren pro Epoche (alle 6,4 Minuten oder 900 pro Tag) aussteigen. Ein zusätzlicher (1) Validator darf pro 65.536 (216) zusätzlicher Validatoren über 262.144 (218) aussteigen. Bei über 327.680 Validatoren können zum Beispiel fünf (5) pro Epoche (1.125 pro Tag) ausscheiden. Sechs (6) werden zugelassen, wenn die Gesamtzahl der aktiven Validatoren 393.216 übersteigt, und so weiter.
-Wenn mehr Validatoren aussteigen, wird die maximale Anzahl der ausscheidenden Validatoren schrittweise auf ein Minimum von vier reduziert, um absichtlich zu verhindern, dass große, destabilisierende Mengen an eingesetztem ETH gleichzeitig abgezogen werden.
+Wenn mehr Validatoren aussteigen, wird die maximale Anzahl der ausscheidenden Validatoren schrittweise auf ein Minimum von vier reduziert, um absichtlich zu verhindern, dass große, destabilisierende Mengen an gestaketem ETH gleichzeitig abgehoben werden.
-### Post-Merge Aufschlüsselung der Inflation {#post-merge-inflation-breakdown}
+### Inflationsaufschlüsselung nach dem Merge {#post-merge-inflation-breakdown}
-- Gesamt ETH Angebot: **~120,520,000 ETH** (zum Zeitpunkt von The Merge im September 2022)
-- Ausgabe der Ausführungs-Ebene: **0**
-- Ausgabe der Konsensus-Ebene: Wie oben beschrieben, **~0.52%** Jährliche Emissionsrate (mit insgesamt 14 Millionen ETH in Staking)
+- Gesamtes ETH-Angebot: **~120.520.000 ETH** (zum Zeitpunkt von The Merge im September 2022)
+- Emission der Ausführungsebene: **0**
+- Emission der Konsensebene: Wie oben, **~0,52 %** annualisierte Emissionsrate (bei 14 Millionen gestaketen ETH insgesamt)
-Jährlicher Gesamtausgabesatz: **~0.52%**
+Gesamte annualisierte Emissionsrate: **~0,52 %**
-Netto-Reduktion der jährlichen ETH-Emissionen: **~88.7%** ((4.61% - 0.52%) / 4.61% * 100)
+Nettorückgang der jährlichen ETH-Emission: **~88,7 %** ((4,61 % - 0,52 %) / 4,61 % \* 100)
+
+
-## Der Burn {#the-burn}
+## Die Verbrennung {#the-burn}
-Die Gegenkraft zur ETH-Ausgabe ist die Geschwindigkeit, mit der die ETH verbrannt wird. Damit eine Transaktion auf Ethereum ausgeführt werden kann, muss eine Mindestgebühr (die so genannte "Grundgebühr") entrichtet werden, die je nach Netzwerkaktivität kontinuierlich (von Block zu Block) schwankt. Die Gebühr wird in ETH bezahlt und ist _erforderlich_, damit die Transaktion als gültig betrachtet wird. Diese Gebühr wird während des Transaktionsprozesses _verbrannt_, wodurch sie aus dem Verkehr gezogen wird.
+Die Gegenkraft zur ETH-Ausgabe ist die Geschwindigkeit, mit der die ETH verbrannt wird. Damit eine Transaktion auf Ethereum ausgeführt werden kann, muss eine Mindestgebühr (die so genannte "Grundgebühr") entrichtet werden, die je nach Netzwerkaktivität kontinuierlich (von Block zu Block) schwankt. Die Gebühr wird in ETH bezahlt und ist _erforderlich_, damit die Transaktion als gültig angesehen wird. Diese Gebühr wird während des Transaktionsprozesses _verbrannt_, wodurch sie aus dem Umlauf genommen wird.
-Die Verbrennung von Gebühren wurde mit dem [the London Upgrade](/ethereum-forks/#london) im August 2021 in Betrieb genommen und bleibt seit dem Merge unverändert.
+
+Das Verbrennen von Gebühren wurde mit dem [London-Upgrade](/ethereum-forks/#london) im August 2021 eingeführt und ist seit The Merge unverändert.
+
+
Zusätzlich zu den Gebühren, die durch das London Upgrade verbrannt werden, können Validatoren auch mit Strafen belegt werden, wenn sie offline sind, oder schlimmer noch, ihr Stake kann gekürzt werden, wenn sie gegen bestimmte Regeln verstoßen, die die Netzsicherheit gefährden. Diese Strafen führen zu einer Verringerung des ETH-Guthabens dieses Validators, das nicht auf ein anderes Konto überwiesen wird, sondern effektiv verbrannt/aus dem Verkehr gezogen wird.
-### Berechnung des durchschnittlichen Gaspreises bei Deflation {#calculating-average-gas-price-for-deflation}
+### Berechnung des durchschnittlichen Gaspreises für die Deflation {#calculating-average-gas-price-for-deflation}
Wie bereits erwähnt, hängt die Menge der an einem bestimmten Tag ausgegebenen ETH von den insgesamt für Staking eingesetzten ETH ab. Zum Zeitpunkt der Erstellung dieses Artikels sind dies etwa 1700 ETH/Tag.
@@ -124,26 +130,26 @@ Um den durchschnittlichen Gaspreis zu ermitteln, der erforderlich ist, um diese
- `(5 Blöcke/Minute) * (60 Minuten/Stunde) = 300 Blöcke/Stunde`
- `(300 Blöcke/Stunde) * (24 Stunden/Tag) = 7200 Blöcke/Tag`
-Jeder Block zielt darauf ab `15x10^6 Gas/Block` ([mehr zum Thema Gas](/developers/docs/gas/)). Auf diese Weise können wir den durchschnittlichen Gaspreis (in Einheiten von gwei/Gas) ermitteln, der erforderlich ist, um die Ausgabe auszugleichen, wenn die tägliche ETH-Ausgabe insgesamt 1700 ETH beträgt:
+Jeder Block zielt auf `15x10^6 Gas/Block` ab ([mehr zu Gas](/developers/docs/gas/)). Auf diese Weise können wir den durchschnittlichen Gaspreis (in Einheiten von gwei/Gas) ermitteln, der erforderlich ist, um die Ausgabe auszugleichen, wenn die tägliche ETH-Ausgabe insgesamt 1700 ETH beträgt:
-- `7200 Blöcke/Tag * 15x10^6 Gas/Block *`**`Y gwei/gas`**`* 1 ETH/ 10^9 gwei = 1700 ETH/Tag`
+- `7200 Blöcke/Tag * 15x10^6 Gas/Block * `**`Y Gwei/Gas`**` * 1 ETH/ 10^9 Gwei = 1700 ETH/Tag`
Auflösen nach `Y`:
-- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (Rundung auf nur zwei signifikante Ziffern)
+- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 Gwei` (Rundung auf nur zwei signifikante Ziffern)
-Eine andere Möglichkeit, diesen letzten Schritt umzugestalten, wäre die Ersetzung von `1700` mit einer Variablen `X` die die tägliche ETH-Ausgabe darstellt, und den Rest zu vereinfachen:
+Eine andere Möglichkeit, diesen letzten Schritt umzustellen, wäre, `1700` durch eine Variable `X` zu ersetzen, die die tägliche ETH-Emission darstellt, und den Rest zu vereinfachen zu:
- `Y = (X(10^3)/(7200 * 15)) = X/108`
-Wir können dies vereinfachen als eine Funktion von `X`:
+Wir können dies vereinfachen und als eine Funktion von `X` schreiben:
-- `f(X) = X/108` wobei `X` ist die tägliche ETH-Ausgabe, und `f(X)` stellt die Menge an gwei/Gaspreis dar, die erforderlich ist, um alle neu ausgegebenen ETH auszugleichen.
+- `f(X) = X/108`, wobei `X` die tägliche ETH-Emission ist und `f(X)` den Gwei/Gas-Preis darstellt, der erforderlich ist, um alle neu emittierten ETH auszugleichen.
-Wenn also zum Beispiel `X` (tägliche ETH-Ausgabe) auf 1800 basierend auf der Summe der eingesetzten ETH ansteigt, `f(X)` (gwei, die erforderlich sind, um die gesamte Emission auszugleichen) wäre dann `17 gwei` (mit 2 signifikanten Ziffern)
+Wenn also zum Beispiel `X` (tägliche ETH-Emission) basierend auf der Gesamtzahl der gestaketen ETH auf 1800 ansteigt, wäre `f(X)` (Gwei, die erforderlich sind, um die gesamte Emission auszugleichen) dann `17 Gwei` (bei Verwendung von 2 signifikanten Ziffern).
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Der Zusammenschluss](/roadmap/merge/)
-- [Ultrasound.money](https://ultrasound.money/) - _Dashboards zur Visualisierung von ETH-Ausgabe und -Verbrauch in Echtzeit verfügbar_
-- [Kartierung der Ethereum-Ausgabe](https://www.attestant.io/posts/charting-ethereum-issuance/) - _Jim McDonald 2020_
+- [Die Zusammenführung](/roadmap/merge/)
+- [Ultrasound.money](https://ultrasound.money/) – _Verfügbare Dashboards zur Visualisierung der ETH-Emission und -Verbrennung in Echtzeit_
+- [Charting Ethereum Issuance](https://www.attestant.io/posts/charting-ethereum-issuance/) – _Jim McDonald 2020_
diff --git a/public/content/translations/de/roadmap/pbs/index.md b/public/content/translations/de/roadmap/pbs/index.md
index d62b51fa43e..5f56b2c803d 100644
--- a/public/content/translations/de/roadmap/pbs/index.md
+++ b/public/content/translations/de/roadmap/pbs/index.md
@@ -1,51 +1,50 @@
---
title: Proposer-Builder-Trennung
-description: Lerne wie und warum die Ethereum-Validatoren ihre Verantwortung für die Blockproduktion und Blockübertragung aufteilen.
+description: "Lerne wie und warum die Ethereum-Validatoren ihre Verantwortung für die Blockproduktion und Blockübertragung aufteilen."
lang: de
---
# Proposer-Builder-Trennung {#proposer-builder-separation}
-Gegenwärtig werden Blöcke von Ethereum Validatoren gleichzeitig produziert _ und _ übertragen. Sie bündeln die Transaktionen, die sie über das Gossip-Netzwerk erhalten haben und fassen diese in einem Block zusammen, welcher sodann an die Peers des Ethereumnetzwerks versendet wird. **Vorschlags-Produzent Separation(PBS)** verteilt diese Aufgaben an mehrere Validatoren. Blockproduzenten werden dafür verantwortlich sein, Blöcke zu erstellen und diese den Blocküberträgern in jedem Slot zur Verfügung zu stellen. Der Block-Vorschlagende kann den Inhalt der Blöcke nicht sehen, sie entscheiden sich lediglich für den profitabelsten und zahlen dem Blockproduzenten eine Gebühr bevor sie den Block an die Peers versendet.
+Heutige Ethereum-Validatoren erstellen _und_ verbreiten Blöcke. Sie bündeln die Transaktionen, die sie über das Gossip-Netzwerk erhalten haben und fassen diese in einem Block zusammen, welcher sodann an die Peers des Ethereumnetzwerks versendet wird. **Proposer-Builder-Trennung (PBS)** teilt diese Aufgaben auf mehrere Validatoren auf. Blockproduzenten werden dafür verantwortlich sein, Blöcke zu erstellen und diese den Blocküberträgern in jedem Slot zur Verfügung zu stellen. Der Block-Vorschlagende kann den Inhalt der Blöcke nicht sehen, sie entscheiden sich lediglich für den profitabelsten und zahlen dem Blockproduzenten eine Gebühr bevor sie den Block an die Peers versendet.
Das ist aus mehreren Gründen ein wichtiges Update. Erstens, schafft es Möglichkeiten die Zensur von Transaktionen auf der Protokollebene zu verhindern. Zweitens, schützt es Hobby-Validatoren davor, von institutionellen Mitspielern, die auf eine bessere Rentabilität optimieren können, verdrängt zu werden. Und drittens, hilft es dabei Ethereum zu skalieren, weil es Upgrades für Danksharding ermöglicht.
-## PPT und Zensurresistenz {#pbs-and-censorship-resistance}
+## PBS und Zensurresistenz {#pbs-and-censorship-resistance}
Die Trennung von Block-Erstellern und Block-Antragstellern macht es schwieriger für Block-Antragsteller, Transaktionen zu zensieren. Das liegt daran, dass vergleichsweise komplexe Einschlusskriterien hinzugefügt werden können, die sicherstellen, dass keine Zensur stattgefunden hat, bevor der Block vorgeschlagen wird. Da der Blockvorschlagende eine eigenständige Einheit vom Blockersteller ist, kann er die Rolle eines Beschützers gegen die Zensur der Blockersteller übernehmen.
Ein Beispiel hierfür sind Einschlusslisten, die verwendet werden können, damit Validatoren über Transaktionen informiert sind, aber wenn sie sehen, dass diese nicht in Blöcken enthalten sind, können sie verlangen, dass sie im nächsten Block unbedingt enthalten sein müssen. Die Einschlussliste wird aus dem lokalen Mempool des Block-Vorschlagstellers generiert (der Liste der ihm bekannten Transaktionen) und kurz vor dem Vorschlagen eines Blocks an seine Peers gesendet. Falls Transaktionen aus der Einschlussliste fehlen, könnte der Vorschlagende entweder den Block ablehnen, die fehlenden Transaktionen hinzufügen, bevor er ihn vorschlägt, oder ihn vorschlagen und es anderen Validatoren überlassen, ihn abzulehnen, wenn sie ihn empfangen. Es gibt auch eine möglicherweise effizientere Version dieser Idee, die besagt, dass die Block-Ersteller den verfügbaren Blockplatz vollständig nutzen müssen. Falls sie das nicht tun, werden Transaktionen aus der Einschlussliste des Vorschlagenden hinzugefügt. Diese Idee ist nach wie vor Gegenstand aktiver Forschung, und die optimale Konfiguration für die Einschlusslisten ist noch nicht endgültig festgelegt.
-[Verschlüsselte Mempools](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) könnten auch dazu führen, dass Ersteller und Vorschlagende von Blöcken erst nach der Übertragung des Blocks wissen, welche Transaktionen darin enthalten sind.
+[Verschlüsselte Mempools](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) könnten es für Builder und Proposer auch unmöglich machen zu wissen, welche Transaktionen sie in einen Block aufnehmen, bis der Block bereits verbreitet wurde.
-
+
Einflussreiche Organisationen können Validatoren dazu drängen, Transaktionen zu zensieren, die von oder zu bestimmten Adressen erfolgen. Die Validatoren geben diesem Druck nach, indem sie Adressen auf der schwarzen Liste in ihrem Transaktionspool erkennen und sie auf den von ihnen vorgeschlagenen Blöcken auslassen. Nach der Einführung von PBS wird dies nicht mehr möglich sein, da Block-Vorschlagende nicht mehr wissen werden, welche Transaktionen sie in ihren Blöcken übertragen. Für bestimmte Personen oder Anwendungen könnte es wichtig sein, die Zensurvorschriften einzuhalten, z. B. wenn sie in ihrer Region gesetzlich vorgeschrieben sind. In solchen Fällen erfolgt die Einhaltung auf Anwendungsebene, während das Protokoll weiterhin erlaubnis- und zensurfrei bleibt.
-
## PBS und MEV {#pbs-and-mev}
-**Maximal extrahierbarer Wert (MEV)** bezieht sich darauf, dass Validatoren ihre Rentabilität maximieren, indem sie Transaktionen in vorteilhafter Weise anordnen. Zu den gängigen Beispielen gehören das Arbitrieren von Trades an dezentralen Börsen (z. B. das Vorauslaufen eines großen Verkaufs oder Kaufs) oder die Identifizierung von Möglichkeiten zur Liquidierung von DeFi-Positionen. Die Maximierung von MEV erfordert hoch entwickeltes technisches Wissen und kundenspezifische Software, die normalen Validatoren hinzugefügt wird. Dadurch wird es deutlich wahrscheinlicher, dass institutionelle Betreiber bei der MEV-Extraktion Einzelpersonen und Hobby-Validatoren übertreffen. Das hat zur Folge, dass die Einkommen aus dem Staking (Einsetzen) mit zentralisierten Betreibern voraussichtlich höher ausfallen, was einen zentralisierenden Effekt erzeugt, der das Staking von Privatpersonen weniger attraktiv macht.
+**Maximal extrahierbarer Wert (MEV)** bezieht sich darauf, dass Validatoren ihre Rentabilität maximieren, indem sie Transaktionen in vorteilhafter Weise anordnen. Gängige Beispiele sind Arbitragegeschäfte mit Swaps an dezentralen Börsen (z. B. Frontrunning eines großen Verkaufs oder Kaufs) oder das Erkennen von Möglichkeiten zur Liquidierung von DeFi-Positionen. Die Maximierung von MEV erfordert hoch entwickeltes technisches Wissen und kundenspezifische Software, die normalen Validatoren hinzugefügt wird. Dadurch wird es deutlich wahrscheinlicher, dass institutionelle Betreiber bei der MEV-Extraktion Einzelpersonen und Hobby-Validatoren übertreffen. Das hat zur Folge, dass die Einkommen aus dem Staking (Einsetzen) mit zentralisierten Betreibern voraussichtlich höher ausfallen, was einen zentralisierenden Effekt erzeugt, der das Staking von Privatpersonen weniger attraktiv macht.
Das PBS löst dieses Problem, indem es die Wirtschaftlichkeit von MEV neu konfiguriert. Anstatt dass der Blockvorschlager selbst nach MEV-Möglichkeiten sucht, wählt er einfach einen Block aus vielen Blöcken aus, die ihm von Block-Erstellern angeboten werden. Die Block-Ersteller könnten eine ausgeklügelte MEV-Extraktion durchgeführt haben, aber die Belohnung dafür erhält der Blockvorschlager. Das bedeutet, dass selbst, wenn ein kleiner Pool spezialisierter Block-Ersteller die MEV-Extraktion dominiert, die Belohnung dafür an jeden Validator im Netzwerk gehen könnte, einschließlich einzelner Heim-Staker (Privat-Einsetzer/Staker).
-
+
Aufgrund der verbesserten Belohnungen durch ausgeklügelte MEV-Strategien könnten Einzelpersonen dazu angeregt werden, sich Pools anzuschließen, anstatt alleine zu staken. Die Trennung der Block-Erstellung vom Block-Vorschlagsverfahren führt dazu, dass die extrahierte MEV auf eine größere Anzahl von Validatoren verteilt wird, anstatt sich bei dem effektivsten MEV-Sucher zu zentralisieren. Gleichzeitig nimmt das Erlauben von spezialisierten Blockproduzenten die Last der Blockerstellung weg vom Einzelnen und verhindert das Stehlen von MEV einzelner für sich selber, während die Anzahl individueller, unabhängiger Validatoren, die Blöcke auf ehrliche weise überprüfen, maximiert wird. Das wichtige Konzept ist die "Beweiser-Verifizierer Asymetrie", welche die Idee beschreibt, dass zentralisierte Blockproduktion okay ist, solange es ein robustes und maximal dezentralisiertes Netzwerk von ehrlichen Validatoren gibt, die die Blöcke überprüfen. Dezentralisierung ist ein Mittel, kein Endziel - worauf es uns ankommt, sind ehrliche Blöcke.
## PBS und Danksharding {#pbs-and-danksharding}
-Danksharding ist der Weg, auf dem Ethereum zu >100000 Transaktionen pro Sekunde skalieren wird, während Gebühren für Rollup-Benutzer minimiert werden. Es baut auf PBS auf, weil es Arbeitslast für die Blockproduzenten hinzufügt, welche Beweise für bis zu 64 MB an Rollup-Daten in weniger als 1 Sekunde berechnen müssen. Dies wird wahrscheinlich spezialisierte Produzenten benötigen, die dieser Aufgabe einiges an Hardware-Power zur Verfügung stellen. Nichtsdestotrotz, in der derzeitigen Situation könnte die Blockproduktion mehr und mehr auf fortschrittlichere, stärkere Hardwareoperator wegen der MEV-Extraktion zentralisiert werden. Vorschlager-Produzenten-Trennung ist ein Weg, dieser Realität zu begegnen und zentralisierende Kräfte auf die Blockprüfung (der wichtige Teil) oder die Verteilung der Staking-Auszahlungen zu verhindern. Ein großer weiterer Vorteil ist zudem, dass die spezialisierten Blockproduzenten bereit und in der Lage sind, die nötigen Datenbeweise für Danksharding zu berechnen.
+Danksharding ist der Weg, wie Ethereum auf >100.000 Transaktionen pro Sekunde skalieren und die Gebühren für Rollup-Benutzer minimieren wird. Es baut auf PBS auf, weil es Arbeitslast für die Blockproduzenten hinzufügt, welche Beweise für bis zu 64 MB an Rollup-Daten in weniger als 1 Sekunde berechnen müssen. Dies wird wahrscheinlich spezialisierte Produzenten benötigen, die dieser Aufgabe einiges an Hardware-Power zur Verfügung stellen. Nichtsdestotrotz, in der derzeitigen Situation könnte die Blockproduktion mehr und mehr auf fortschrittlichere, stärkere Hardwareoperator wegen der MEV-Extraktion zentralisiert werden. Vorschlager-Produzenten-Trennung ist ein Weg, dieser Realität zu begegnen und zentralisierende Kräfte auf die Blockprüfung (der wichtige Teil) oder die Verteilung der Staking-Auszahlungen zu verhindern. Ein großer weiterer Vorteil ist zudem, dass die spezialisierten Blockproduzenten bereit und in der Lage sind, die nötigen Datenbeweise für Danksharding zu berechnen.
## Aktueller Fortschritt {#current-progress}
-PBS ist in einer fortgeschrittenen Phase der Forschung, aber es gibt immer noch ein paar wichtige Designfragen, die gelöst werden müssen, bevor es in Ethereum Clients implementiert werden kann. Es gibt noch keine endgültige Spezifikation. Das heißt, dass PBS wahrscheinlich noch mindestens ein Jahr oder länger entfernt ist. Informieren Sie sich über den neuesten [Forschungsstand](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance).
+PBS ist in einer fortgeschrittenen Phase der Forschung, aber es gibt immer noch ein paar wichtige Designfragen, die gelöst werden müssen, bevor es in Ethereum Clients implementiert werden kann. Es gibt noch keine endgültige Spezifikation. Das heißt, dass PBS wahrscheinlich noch mindestens ein Jahr oder länger entfernt ist. Sehen Sie sich den neuesten [Stand der Forschung](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) an.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Forschungsstand: Zensurwiderstand unter PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
-- [PBS-freundliche Gebührenmarktkonzepte](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
-- [PPT und Zensurresistenz](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions)
-- [Einschlusslisten](https://notes.ethereum.org/@fradamt/H1ZqdtrBF)
+- [Forschungsstand: Zensurresistenz unter PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
+- [PBS-freundliche Gebührenmarktdesigns](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
+- [PBS und Zensurresistenz](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions)
+- [Inklusionslisten](https://notes.ethereum.org/@fradamt/H1ZqdtrBF)
diff --git a/public/content/translations/de/roadmap/pectra/7702/index.md b/public/content/translations/de/roadmap/pectra/7702/index.md
new file mode 100644
index 00000000000..8ff65bd87dd
--- /dev/null
+++ b/public/content/translations/de/roadmap/pectra/7702/index.md
@@ -0,0 +1,149 @@
+---
+title: Pectra 7702-Richtlinien
+description: "Erfahren Sie mehr über 7702 in der Pectra-Version"
+lang: de
+---
+
+# Pectra 7702
+
+## Zusammenfassung {#abstract}
+
+EIP 7702 definiert einen Mechanismus, um einem EOA Code hinzuzufügen. Dieser Vorschlag ermöglicht es EOAs, den alten Ethereum-Konten, kurzfristige Funktionsverbesserungen zu erhalten, was die Benutzerfreundlichkeit von Anwendungen erhöht. Dies geschieht durch das Setzen eines Zeigers auf bereits bereitgestellten Code mithilfe eines neuen Transaktionstyps: 4.
+
+Dieser neue Transaktionstyp führt eine Autorisierungsliste ein. Jedes Autorisierungstupel in der Liste ist definiert als
+
+```
+[ chain_id, address, nonce, y_parity, r, s ]
+```
+
+**address** ist die Delegation (bereits bereitgestellter Bytecode, der vom EOA verwendet wird)
+**chain_id** sperrt die Autorisierung auf eine bestimmte Kette (oder 0 für alle Ketten)
+**nonce** sperrt die Autorisierung auf eine bestimmte Konto-Nonce
+(**y_parity, r, s**) ist die Signatur des Autorisierungstupels, die durch den privaten Schlüssel des EOA, auf den sich die Autorisierung bezieht (auch als Autorität bezeichnet), als keccak(0x05 || rlp ([chain_id ,address, nonce])) definiert wird
+
+Eine Delegation kann zurückgesetzt werden, indem an die Null-Adresse delegiert wird.
+
+Der private Schlüssel des EOA behält nach der Delegation die volle Kontrolle über das Konto. Wenn Sie zum Beispiel an ein Safe delegieren, wird das Konto nicht zu einem Multisig, da es immer noch einen einzigen Schlüssel gibt, der jede Signierrichtlinie umgehen kann. In Zukunft sollten Entwickler davon ausgehen, dass jeder Teilnehmer im System ein Smart Contract sein könnte. Für Smart-Contract-Entwickler ist es nicht mehr sicher anzunehmen, dass sich `tx.origin` auf einen EOA bezieht.
+
+## Bewährte Praktiken {#best-practices}
+
+**Kontoabstraktion**: Ein Delegationsvertrag sollte mit den breiteren Kontoabstraktionsstandards (AA) von Ethereum übereinstimmen, um die Kompatibilität zu maximieren. Insbesondere sollte er idealerweise ERC-4337-konform oder kompatibel sein.
+
+**Erlaubnisfreies und zensurresistentes Design**: Ethereum schätzt die erlaubnisfreie Teilnahme. Ein Delegationsvertrag DARF KEINEN einzelnen „vertrauenswürdigen“ Relayer oder Dienst fest programmieren oder sich darauf verlassen. Dies würde das Konto lahmlegen, wenn der Relayer offline geht. Funktionen wie Batching (z. B. approve+transferFrom) können vom EOA selbst ohne einen Relayer verwendet werden. Für Anwendungsentwickler, die erweiterte Funktionen nutzen möchten, die durch 7702 (Gasabstraktion, datenschutzwahrende Abhebungen) ermöglicht werden, benötigen Sie einen Relayer. Obwohl es verschiedene Relayer-Architekturen gibt, empfehlen wir die Verwendung von [4337 Bundlern](https://www.erc4337.io/bundlers), die mindestens auf den [Einstiegspunkt 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) verweisen, denn:
+
+- Sie bieten standardisierte Schnittstellen für das Relaying
+- Sie enthalten eingebaute Paymaster-Systeme
+- Sie gewährleisten die Vorwärtskompatibilität
+- Sie können Zensurresistenz durch einen [öffentlichen Mempool](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) unterstützen
+- Sie können erfordern, dass die init-Funktion nur vom [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) aufgerufen wird
+
+Mit anderen Worten, jeder sollte als Transaktionssponsor/Relayer agieren können, solange er die erforderliche gültige Signatur oder UserOperation vom Konto bereitstellt. Dies gewährleistet Zensurresistenz: Wenn keine benutzerdefinierte Infrastruktur erforderlich ist, können die Transaktionen eines Benutzers nicht willkürlich durch ein kontrollierendes Relais blockiert werden. Zum Beispiel arbeitet [MetaMasks Delegation Toolkit](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) explizit mit jedem ERC-4337-Bundler oder Paymaster auf jeder Kette zusammen, anstatt einen MetaMask-spezifischen Server zu erfordern.
+
+**Dapps-Integration über Wallet-Schnittstellen**:
+
+Da Wallets spezifische Delegationsverträge für EIP-7702 auf die Whitelist setzen werden, sollten Dapps nicht erwarten, 7702-Autorisierungen direkt anzufordern. Stattdessen sollte die Integration über standardisierte Wallet-Schnittstellen erfolgen:
+
+- **ERC-5792 (`wallet_sendCalls`)**: Ermöglicht Dapps, Wallets aufzufordern, gebündelte Aufrufe auszuführen, was Funktionalitäten wie Transaktionsbündelung und Gas-Abstraktion erleichtert.
+
+- **ERC-6900**: Ermöglicht Dapps, modulare Smart-Account-Funktionen wie Sitzungsschlüssel und Kontowiederherstellung über von Wallets verwaltete Module zu nutzen.
+
+Durch die Nutzung dieser Schnittstellen können Dapps auf Smart-Account-Funktionalitäten zugreifen, die von EIP-7702 bereitgestellt werden, ohne Delegationen direkt zu verwalten, was Kompatibilität und Sicherheit über verschiedene Wallet-Implementierungen hinweg gewährleistet.
+
+> Hinweis: Es gibt keine standardisierte Methode für Dapps, 7702-Autorisierungssignaturen direkt anzufordern. Dapps müssen sich auf spezifische Wallet-Schnittstellen wie ERC-6900 verlassen, um die Funktionen von EIP-7702 zu nutzen.
+
+Weitere Informationen:
+
+- [ERC-5792-Spezifikation](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md)
+- [ERC-6900-Spezifikation](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md)
+
+**Vermeidung von Herstellerbindung**: Im Einklang mit dem oben Genannten ist eine gute Implementierung herstellerneutral und interoperabel. Dies bedeutet oft, sich an aufkommende Standards für Smart Accounts zu halten. Zum Beispiel verwendet [Alchemys modulares Konto](https://github.com/alchemyplatform/modular-account) den ERC-6900-Standard für modulare Smart Accounts und wurde mit Blick auf eine „erlaubnisfreie interoperable Nutzung“ konzipiert.
+
+**Datenschutz**: Obwohl der Datenschutz on-chain begrenzt ist, sollte ein Delegationsvertrag bestrebt sein, die Datenexposition und Verknüpfbarkeit zu minimieren. Dies kann durch die Unterstützung von Funktionen wie Gas-Zahlungen in ERC-20-Tokens (sodass Benutzer kein öffentliches ETH-Guthaben halten müssen, was den Datenschutz und die UX verbessert) und einmaligen Sitzungsschlüsseln (die die Abhängigkeit von einem einzigen Langzeitschlüssel verringern) erreicht werden. Zum Beispiel ermöglicht EIP-7702 das Bezahlen von Gas in Tokens über gesponserte Transaktionen, und eine gute Implementierung wird es einfach machen, solche Paymaster zu integrieren, ohne mehr Informationen als nötig preiszugeben. Darüber hinaus bedeutet die Off-Chain-Delegation bestimmter Genehmigungen (unter Verwendung von Signaturen, die on-chain verifiziert werden), dass weniger On-Chain-Transaktionen mit dem Primärschlüssel des Benutzers stattfinden, was dem Datenschutz dient. Konten, die die Verwendung eines Relayers erfordern, zwingen Benutzer, ihre IP-Adressen preiszugeben. Öffentliche Mempools verbessern dies. Wenn eine Transaktion/UserOp sich durch den Mempool ausbreitet, können Sie nicht feststellen, ob sie von der IP stammt, die sie gesendet hat, oder ob sie nur über das p2p-Protokoll weitergeleitet wurde.
+
+**Erweiterbarkeit und modulare Sicherheit**: Kontenimplementierungen sollten erweiterbar sein, damit sie sich mit neuen Funktionen und Sicherheitsverbesserungen weiterentwickeln können. Upgrade-Fähigkeit ist mit EIP-7702 von Natur aus möglich (da ein EOA in Zukunft immer an einen neuen Vertrag delegieren kann, um seine Logik zu aktualisieren). Über die Upgrade-Fähigkeit hinaus ermöglicht ein gutes Design Modularität – z. B. Plug-in-Module für verschiedene Signaturschemata oder Ausgabenrichtlinien –, ohne dass eine vollständige Neuausbringung erforderlich ist. Das Account Kit von Alchemy ist ein Paradebeispiel, das Entwicklern die Installation von Validierungsmodulen (für verschiedene Signaturtypen wie ECDSA, BLS usw.) ermöglicht. und Ausführungsmodule für benutzerdefinierte Logik. Um eine größere Flexibilität und Sicherheit in EIP-7702-fähigen Konten zu erreichen, werden Entwickler ermutigt, an einen Proxy-Vertrag zu delegieren, anstatt direkt an eine spezifische Implementierung. Dieser Ansatz ermöglicht nahtlose Upgrades und Modularität, ohne dass für jede Änderung zusätzliche EIP-7702-Autorisierungen erforderlich sind.
+
+Vorteile des Proxy-Musters:
+
+- **Upgrade-Fähigkeit**: Aktualisieren Sie die Vertragslogik, indem Sie den Proxy auf einen neuen Implementierungsvertrag verweisen.
+
+- **Benutzerdefinierte Initialisierungslogik**: Integrieren Sie Initialisierungsfunktionen in den Proxy, um die notwendigen Zustandsvariablen sicher einzurichten.
+
+Zum Beispiel zeigt der [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe), wie ein Proxy genutzt werden kann, um Delegationen in EIP-7702-kompatiblen Konten sicher zu initialisieren und zu verwalten.
+
+Nachteile des Proxy-Musters:
+
+- **Abhängigkeit von externen Akteuren**: Sie müssen sich darauf verlassen, dass ein externes Team kein Upgrade auf einen unsicheren Vertrag durchführt.
+
+## Sicherheitsüberlegungen {#security-considerations}
+
+**Re-Entrancy-Schutz**: Mit der Einführung der EIP-7702-Delegation kann das Konto eines Benutzers dynamisch zwischen einem extern verwalteten Konto (EOA) und einem Smart Contract (SC) wechseln. Diese Flexibilität ermöglicht es dem Konto, sowohl Transaktionen zu initiieren als auch Ziel von Aufrufen zu sein. Infolgedessen werden Szenarien, in denen ein Konto sich selbst aufruft und externe Aufrufe tätigt, dazu führen, dass `msg.sender` gleich `tx.origin` ist, was bestimmte Sicherheitsannahmen untergräbt, die zuvor darauf beruhten, dass `tx.origin` immer ein EOA ist.
+
+Für Smart-Contract-Entwickler ist es nicht mehr sicher anzunehmen, dass sich `tx.origin` auf einen EOA bezieht. Ebenso ist die Verwendung von `msg.sender == tx.origin` als Schutzmaßnahme gegen Re-Entrancy-Angriffe keine zuverlässige Strategie mehr.
+
+In Zukunft sollten Entwickler davon ausgehen, dass jeder Teilnehmer im System ein Smart Contract sein könnte. Alternativ könnten sie einen expliziten Re-Entrancy-Schutz unter Verwendung von Re-Entrancy-Guards mit `nonReentrant`-Modifikator-Mustern implementieren. Wir empfehlen, einen auditierten Modifikator zu verwenden, z. B. [OpenZeppelins Reentrancy Guard](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). Sie könnten auch eine [transiente Speichervariable](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) verwenden.
+
+**Sicherheitsüberlegungen zur Initialisierung**
+
+Die Implementierung von EIP-7702-Delegationsverträgen bringt spezifische Sicherheitsherausforderungen mit sich, insbesondere im Hinblick auf den Initialisierungsprozess. Eine kritische Schwachstelle entsteht, wenn die Initialisierungsfunktion (`init`) atomar mit dem Delegationsprozess gekoppelt ist. In solchen Fällen könnte ein Frontrunner die Delegationssignatur abfangen und die `init`-Funktion mit geänderten Parametern ausführen, wodurch er möglicherweise die Kontrolle über das Konto übernimmt.
+
+Dieses Risiko ist besonders relevant, wenn versucht wird, bestehende Smart-Contract-Konto-Implementierungen (SCA) mit EIP-7702 zu verwenden, ohne deren Initialisierungsmechanismen zu ändern.
+
+**Lösungen zur Minderung von Initialisierungsschwachstellen**
+
+- Implement `initWithSig`
+ Ersetzen Sie die Standard-`init`-Funktion durch eine `initWithSig`-Funktion, bei der der Benutzer die Initialisierungsparameter signieren muss. Dieser Ansatz stellt sicher, dass die Initialisierung nur mit ausdrücklicher Zustimmung des Benutzers erfolgen kann, wodurch das Risiko einer unbefugten Initialisierung gemindert wird.
+
+- Nutzen Sie den EntryPoint von ERC-4337
+ Verlangen Sie, dass die Initialisierungsfunktion ausschließlich vom ERC-4337 EntryPoint-Vertrag aufgerufen wird. Diese Methode nutzt das standardisierte Validierungs- und Ausführungsframework von ERC-4337 und fügt dem Initialisierungsprozess eine zusätzliche Sicherheitsebene hinzu.
+ _(Siehe: [Safe Docs](https://docs.safe.global/advanced/eip-7702/7702-safe))_
+
+Durch die Anwendung dieser Lösungen können Entwickler die Sicherheit von EIP-7702-Delegationsverträgen verbessern und sich vor potenziellen Frontrunning-Angriffen während der Initialisierungsphase schützen.
+
+**Speicherkollisionen** Das Delegieren von Code löscht nicht den vorhandenen Speicher. Bei der Migration von einem Delegationsvertrag zu einem anderen bleiben die Restdaten des vorherigen Vertrags erhalten. Wenn der neue Vertrag dieselben Speicher-Slots verwendet, diese aber unterschiedlich interpretiert, kann dies zu unbeabsichtigtem Verhalten führen. Wenn beispielsweise die ursprüngliche Delegation an einen Vertrag erfolgte, bei dem ein Speicher-Slot einen `bool`-Wert darstellt, und die nachfolgende Delegation an einen Vertrag, bei dem derselbe Slot einen `uint`-Wert darstellt, kann die Nichtübereinstimmung zu unvorhersehbaren Ergebnissen führen.
+
+**Phishing-Risiken** Mit der Implementierung der EIP-7702-Delegation können die Vermögenswerte auf dem Konto eines Benutzers vollständig von Smart Contracts kontrolliert werden. Wenn ein Benutzer sein Konto unwissentlich an einen bösartigen Vertrag delegiert, könnte ein Angreifer leicht die Kontrolle erlangen und Gelder stehlen. Bei Verwendung von `chain_id=0` wird die Delegation auf alle Chain-IDs angewendet. Delegieren Sie nur an einen unveränderlichen Vertrag (niemals an einen Proxy) und nur an Verträge, die mit CREATE2 bereitgestellt wurden (mit Standard-Initcode – keine metamorphen Verträge), damit der Bereitsteller nicht etwas anderes an dieselbe Adresse an anderer Stelle bereitstellen kann. Andernfalls gefährdet Ihre Delegation Ihr Konto auf allen anderen EVM-Ketten.
+
+Wenn Benutzer delegierte Signaturen durchführen, sollte der Zielvertrag, der die Delegation erhält, klar und deutlich angezeigt werden, um Phishing-Risiken zu mindern.
+
+**Minimale vertrauenswürdige Oberfläche & Sicherheit**: Obwohl ein Delegationsvertrag Flexibilität bietet, sollte seine Kernlogik minimal und auditierbar gehalten werden. Der Vertrag ist praktisch eine Erweiterung des EOA des Benutzers, sodass jeder Fehler katastrophale Folgen haben kann. Implementierungen sollten den besten Praktiken der Smart-Contract-Sicherheits-Community folgen. Zum Beispiel müssen Konstruktor- oder Initialisierungsfunktionen sorgfältig gesichert werden – wie von Alchemy hervorgehoben, könnte bei Verwendung eines Proxy-Musters unter 7702 ein ungeschützter Initialisierer einem Angreifer ermöglichen, das Konto zu übernehmen. Teams sollten darauf abzielen, den On-Chain-Code einfach zu halten: Der 7702-Vertrag von Ambire umfasst nur ~200 Zeilen Solidity, um die Komplexität bewusst zu minimieren und Fehler zu reduzieren. Es muss ein Gleichgewicht zwischen funktionsreicher Logik und der Einfachheit, die die Auditierung erleichtert, gefunden werden.
+
+### Bekannte Implementierungen {#known-implementations}
+
+Aufgrund der Natur von EIP 7702 wird empfohlen, dass Wallets Vorsicht walten lassen, wenn sie Benutzern helfen, an einen Drittanbietervertrag zu delegieren. Nachfolgend finden Sie eine Sammlung bekannter Implementierungen, die auditiert wurden:
+
+| Vertragsadresse | Quelle | Audits (Prüfungen) |
+| ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [Audits](https://github.com/Uniswap/calibur/tree/main/audits) |
+| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [Audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) |
+| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [Audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) |
+| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [Audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) |
+| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [AA-Team der Ethereum Foundation](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [Audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) |
+| 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract) | [Audits](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) |
+
+## Hardware-Wallet-Richtlinien {#hardware-wallet-guidelines}
+
+Hardware-Wallets sollten keine beliebige Delegation ermöglichen. Der Konsens im Bereich der Hardware-Wallets ist die Verwendung einer Liste vertrauenswürdiger Delegator-Verträge. Wir schlagen vor, die oben aufgeführten bekannten Implementierungen zuzulassen und andere von Fall zu Fall zu prüfen. Da die Delegation Ihres EOA an einen Vertrag die Kontrolle über alle Vermögenswerte gibt, sollten Hardware-Wallets bei der Implementierung von 7702 vorsichtig sein.
+
+### Integrationsszenarien für Begleit-Apps {#integration-scenarios-for-companion-apps}
+
+#### Lazy {#lazy}
+
+Da der EOA weiterhin wie gewohnt funktioniert, gibt es nichts zu tun.
+
+Hinweis: Einige Vermögenswerte könnten vom Delegationscode automatisch abgelehnt werden, wie z. B. ERC-1155-NFTs, und der Support sollte sich dessen bewusst sein.
+
+#### Bewusst {#aware}
+
+Benachrichtigen Sie den Benutzer, dass für den EOA eine Delegation vorhanden ist, indem Sie dessen Code überprüfen, und bieten Sie optional an, die Delegation zu entfernen.
+
+#### Gängige Delegation {#common-delegation}
+
+Der Hardware-Anbieter setzt bekannte Delegationsverträge auf die Whitelist und implementiert deren Unterstützung in der Software-Begleit-App. Es wird empfohlen, einen Vertrag mit voller ERC-4337-Unterstützung zu wählen.
+
+EOAs, die an einen anderen delegiert wurden, werden als Standard-EOAs behandelt.
+
+#### Benutzerdefinierte Delegation {#custom-delegation}
+
+Der Hardware-Anbieter implementiert seinen eigenen Delegationsvertrag, fügt ihn den Listen hinzu und implementiert seine Unterstützung in der Software-Begleit-App. Es wird empfohlen, einen Vertrag mit voller ERC-4337-Unterstützung zu erstellen.
+
+EOAs, die an einen anderen delegiert wurden, werden als Standard-EOAs behandelt.
diff --git a/public/content/translations/de/roadmap/pectra/index.md b/public/content/translations/de/roadmap/pectra/index.md
new file mode 100644
index 00000000000..2ce0db16fa2
--- /dev/null
+++ b/public/content/translations/de/roadmap/pectra/index.md
@@ -0,0 +1,127 @@
+---
+title: Prag-Electra (Pectra)
+description: "Erfahre mehr über das Pectra-Protokoll-Upgrade"
+lang: de
+---
+
+# Pectra {#pectra}
+
+Das Pectra-Netzwerk-Upgrade folgte auf [Dencun](/roadmap/dencun/) und brachte Änderungen sowohl an der Ausführungsebene als auch an der Konsens-Ebene von Ethereum. Der verkürzte Name Pectra ist eine Kombination aus Prag und Electra, den jeweiligen Namen für die Spezifikationsänderungen der Ausführungs- und der Konsens-Ebene. Zusammen bringen diese Änderungen eine Reihe von Verbesserungen für Ethereum-Nutzer, Entwickler und Validatoren.
+
+Dieses Upgrade wurde erfolgreich im Ethereum-Mainnet bei Epoche `364032` am **7. Mai 2025 um 10:05 (UTC)** aktiviert.
+
+
+
+
+Das Pectra-Upgrade ist nur ein einziger Schritt in den langfristigen Entwicklungszielen von Ethereum. Erfahre mehr über die [Protokoll-Roadmap](/roadmap/) und [frühere Upgrades](/ethereum-forks/).
+
+
+
+
+## Verbesserungen in Pectra {#new-improvements}
+
+Pectra bringt die größte Anzahl an [EIPs](https://eips.ethereum.org/) aller bisherigen Upgrades mit sich! Es gibt viele kleinere Änderungen, aber auch einige wichtige neue Funktionen. Die vollständige Liste der Änderungen und technischen Details findet sich in den einzelnen enthaltenen EIPs.
+
+### EOA-Konto-Code {#7702}
+
+[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) stellt einen wichtigen Schritt in Richtung einer weitreichenden [Kontoabstraktion](/roadmap/account-abstraction/) dar. Mit dieser Funktion können Nutzer ihre Adresse ([EOA](/glossary/#eoa)) so einstellen, dass sie um einen Smart Contract erweitert wird. Der EIP führt einen neuen Transaktionstyp mit einer spezifischen Funktion ein: Adressinhabern wird es ermöglicht, eine Autorisierung zu unterzeichnen, die ihre Adresse so einstellt, dass sie einen ausgewählten Smart Contract nachahmt.
+
+Mit diesem EIP können sich Nutzer für programmierbare Wallets entscheiden, die neue Funktionen wie Transaktionsbündelung, gaslose Transaktionen und benutzerdefinierten Asset-Zugriff für alternative Wiederherstellungsschemata ermöglichen. Dieser hybride Ansatz kombiniert die Einfachheit von EOAs mit der Programmierbarkeit von vertragsbasierten Konten.
+
+Eine ausführlichere Beschreibung von 7702 findest du [hier](/roadmap/pectra/7702/)
+
+### Erhöhung des maximalen effektiven Guthabens {#7251}
+
+Das aktuelle effektive Guthaben des Validators beträgt genau 32 ETH. Das ist der minimal notwendige Betrag, um am Konsens teilzunehmen, aber gleichzeitig das Maximum, das ein einzelner Validator staken kann.
+
+[EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) erhöht das maximal mögliche effektive Guthaben auf 2048 ETH, was bedeutet, dass ein einzelner Validator nun zwischen 32 und 2048 ETH staken kann. Anstatt Vielfache von 32 zu staken, können Staker nun einen beliebigen ETH-Betrag zum Staken wählen und erhalten Belohnungen für jeden ETH über dem Minimum. Wenn zum Beispiel das Guthaben eines Validators mit seinen Belohnungen auf 33 ETH anwächst, wird der zusätzliche 1 ETH ebenfalls als Teil des effektiven Guthabens betrachtet und erhält Belohnungen.
+
+Aber der Vorteil eines besseren Belohnungssystems für Validatoren ist nur ein Teil dieser Verbesserung. [Staker](/staking/), die mehrere Validatoren betreiben, können diese nun zu einem einzigen zusammenfassen, was den Betrieb erleichtert und den Netzwerk-Overhead reduziert. Da jeder Validator in der Beacon Chain in jeder Epoche eine Signatur einreicht, wachsen die Bandbreitenanforderungen mit mehr Validatoren und einer großen Anzahl zu verbreitender Signaturen. Die Zusammenfassung von Validatoren wird das Netzwerk entlasten und neue Skalierungsoptionen eröffnen, während die gleiche wirtschaftliche Sicherheit erhalten bleibt.
+
+Eine ausführlichere Beschreibung von maxEB findest du [hier](/roadmap/pectra/maxeb/)
+
+### Erhöhung des Blob-Durchsatzes {#7691}
+
+Blobs bieten [Datenverfügbarkeit](/developers/docs/data-availability/#data-availability-and-layer-2-rollups) für L2s. Sie wurden im [vorherigen Netzwerk-Upgrade](/roadmap/dencun/) eingeführt.
+
+Derzeit zielt das Netzwerk auf durchschnittlich 3 Blobs pro Block mit einem Maximum von 6 Blobs ab. Mit [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691) wird die durchschnittliche Blob-Anzahl auf 6 erhöht, mit einem Maximum von 9 pro Block, was zu einer erhöhten Kapazität für Ethereum-Rollups führt. Dieses EIP hilft, die Lücke zu überbrücken, bis [PeerDAS](https://eips.ethereum.org/EIPS/eip-7594) noch höhere Blob-Anzahlen ermöglicht.
+
+### Erhöhung der Calldata-Kosten {#7623}
+
+Vor der Einführung von [Blobs im Dencun-Upgrade](/roadmap/danksharding) verwendeten L2s [Calldata](/developers/docs/data-availability/blockchain-data-storage-strategies/#calldata), um ihre Daten in Ethereum zu speichern. Sowohl Blobs als auch Calldata beeinflussen die Bandbreitennutzung von Ethereum. Während die meisten Blöcke nur eine minimale Menge an Calldata verwenden, können datenintensive Blöcke, die auch viele Blobs enthalten, schädlich für das P2P-Netzwerk von Ethereum sein.
+
+Um dieses Problem zu beheben, erhöht [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) die Preise für Calldata, aber nur für datenintensive Transaktionen. Dies begrenzt die Blockgröße im schlimmsten Fall, bietet einen Anreiz für L2s, nur Blobs zu verwenden, und lässt über 99 % der Transaktionen unberührt.
+
+### Auslösbare Exits der Ausführungsebene {#7002}
+
+Derzeit ist das Verlassen eines Validators und das [Abheben von gestakten ETH](/staking/withdrawals/) ein Vorgang der Konsens-Ebene, der einen aktiven Validator-Schlüssel erfordert, denselben BLS-Schlüssel, den der Validator zur Erfüllung aktiver Aufgaben wie Attestierungen verwendet. Die „Withdrawal Credentials“ sind ein separater Cold Key, der den ausgetretenen Stake empfängt, aber den Austritt nicht auslösen kann. Die einzige Möglichkeit für Staker, auszusteigen, besteht darin, eine spezielle Nachricht an das Beacon-Chain-Netzwerk zu senden, die mit dem aktiven Validator-Schlüssel signiert ist. Dies ist in Szenarien einschränkend, in denen die „Withdrawal Credentials“ und der Validator-Schlüssel von verschiedenen Entitäten gehalten werden oder wenn der Validator-Schlüssel verloren geht.
+
+[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) führt einen neuen Vertrag ein, der verwendet werden kann, um den Austritt unter Verwendung der „Withdrawal Credentials“ der Ausführungsebene auszulösen. Staker können ihren Validator verlassen, indem sie eine Funktion in diesem speziellen Vertrag aufrufen, ohne dass sie ihren Validator-Signierschlüssel benötigen oder überhaupt auf die Beacon Chain zugreifen müssen. Wichtig ist, dass die Aktivierung von Validator-Abhebungen on-chain Staking-Protokolle mit reduzierten Vertrauensannahmen gegenüber Node-Betreibern ermöglicht.
+
+### Validator-Einzahlungen on-chain {#6110}
+
+Validator-Einzahlungen werden derzeit durch das [eth1data-Polling](https://eth2book.info/capella/part2/deposits-withdrawals/deposit-processing/) verarbeitet, einer Funktion auf der Beacon Chain, die Daten von der Ausführungsebene abruft. Es handelt sich um eine Art technische Schuld aus der Zeit vor The Merge, als die Beacon Chain ein separates Netzwerk war und sich mit Proof-of-Work-Re-Orgs befassen musste.
+
+[EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) ist eine neue Methode zur Übermittlung von Einzahlungen von der Ausführungs- an die Konsens-Ebene, die eine sofortige Verarbeitung mit geringerer Implementierungskomplexität ermöglicht. Es ist eine sicherere Art, Einzahlungen zu handhaben, die für das vereinte Ethereum nativ ist. Es hilft auch, das Protokoll zukunftssicher zu machen, da es keine historischen Einzahlungen zum Bootstrapping der Node benötigt, was für den Ablauf der Historie notwendig ist.
+
+### Precompile für BLS12-381 {#2537}
+
+Precompiles sind ein spezieller Satz von Smart Contracts, die direkt in die Ethereum Virtual Machine ([EVM](/developers/docs/evm/)) integriert sind. Im Gegensatz zu regulären Verträgen werden Precompiles nicht von Nutzern bereitgestellt, sondern sind Teil der Client-Implementierung selbst und in deren nativer Sprache geschrieben (z. B. Go, Java, etc., nicht Solidity). Precompiles dienen für weit verbreitete und standardisierte Funktionen wie kryptografische Operationen. Smart-Contract-Entwickler können Precompiles wie einen regulären Vertrag aufrufen, aber mit mehr Sicherheit und Effizienz.
+
+[EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) fügt neue Precompiles für Kurvenoperationen über [BLS12-381](https://hackmd.io/@benjaminion/bls12-381) hinzu. Diese elliptische Kurve ist dank ihrer praktischen Eigenschaften in Kryptowährungs-Ökosystemen weit verbreitet. Genauer gesagt wurde sie von der Konsens-Ebene von Ethereum übernommen, wo sie von Validatoren verwendet wird.
+
+Der neue Precompile gibt jedem Entwickler die Möglichkeit, kryptografische Operationen mit dieser Kurve einfach, effizient und sicher durchzuführen, zum Beispiel die Überprüfung von Signaturen. On-Chain-Anwendungen, die von dieser Kurve abhängen, können gas-effizienter und sicherer werden, indem sie sich auf einen Precompile anstatt auf einen benutzerdefinierten Vertrag verlassen. Dies gilt hauptsächlich für Anwendungen, die über Validatoren innerhalb der EVM nachdenken möchten, z. B. Staking-Pools, [Restaking](/restaking/), Light Clients, kettenübergreifende Brücken, aber auch Zero-Knowledge.
+
+### Bereitstellung historischer Block-Hashes aus dem State {#2935}
+
+Die EVM stellt derzeit den `BLOCKHASH`-Opcode zur Verfügung, der es Vertragsentwicklern ermöglicht, den Hash eines Blocks direkt in der Ausführungsebene abzurufen. Dies ist jedoch nur auf die letzten 256 Blöcke beschränkt und könnte in Zukunft für zustandslose Clients problematisch werden.
+
+[EIP-2935](https://eips.ethereum.org/EIPS/eip-2935) erstellt einen neuen Systemvertrag, der die letzten 8192 Block-Hashes als Storage-Slots bereitstellen kann. Dies trägt dazu bei, das Protokoll für eine zustandslose Ausführung zukunftssicher zu machen, und wird effizienter, wenn Verkle-Tries übernommen werden. Abgesehen davon können Rollups jedoch sofort davon profitieren, da sie den Vertrag direkt mit einem längeren historischen Fenster abfragen können.
+
+### Verschieben des Komitee-Index außerhalb der Attestierung {#7549}
+
+Der Konsens der Beacon Chain basiert darauf, dass Validatoren ihre Stimmen für den neuesten Block und die finalisierte Epoche abgeben. Die Attestierung enthält 3 Elemente, von denen 2 Stimmen und das dritte der Wert des Komitee-Index ist.
+
+[EIP-7549](https://eips.ethereum.org/EIPS/eip-7549) verschiebt diesen Index aus der signierten Attestierungsnachricht heraus, was die Überprüfung und Aggregation von Konsens-Stimmen erleichtert. Dies ermöglicht mehr Effizienz in jedem Konsens-Client und kann erhebliche Leistungsverbesserungen für Zero-Knowledge-Schaltungen zum Beweis des Ethereum-Konsens bringen.
+
+### Blob-Zeitplan zu EL-Konfigurationsdateien hinzufügen {#7840}
+
+[EIP-7840](https://eips.ethereum.org/EIPS/eip-7840) ist eine einfache Änderung, die ein neues Feld zur Client-Konfiguration der Ausführungsebene hinzufügt. Es konfiguriert die Anzahl der Blöcke und ermöglicht die dynamische Einstellung der Ziel- und Maximalanzahl von Blobs pro Block sowie die Anpassung der Blob-Gebühr. Mit einer direkt definierten Konfiguration können Clients die Komplexität des Austauschs dieser Informationen über die Engine-API vermeiden.
+
+
+
+
+Um mehr darüber zu erfahren, wie Pectra dich speziell als Ethereum-Nutzer, Entwickler oder Validator betrifft, schau in die Pectra-FAQ.
+
+
+
+
+## Betrifft dieses Upgrade alle Ethereum-Nodes und -Validatoren? {#client-impact}
+
+Ja, das Pectra-Upgrade erfordert Updates sowohl für [Ausführungs-Clients als auch für Konsens-Clients](/developers/docs/nodes-and-clients/). Alle wichtigen Ethereum-Clients werden Versionen veröffentlichen, die den als hochprioritär eingestuften Hard Fork unterstützen. Um nach dem Upgrade die Synchronisation mit dem Ethereum-Netzwerk aufrechtzuerhalten, müssen die Knotenbetreiber sicherstellen, dass die von ihnen eingesetzte Client-Version unterstützt wird. Beachten Sie, dass die Informationen zu Client-Versionen zeitkritisch sind, und Benutzer sollten die neuesten Updates konsultieren, um die die aktuellsten Details zu erfahren.
+
+## Wie können ETH nach der harten Abspaltung umgewandelt werden? {#scam-alert}
+
+- **Keine Aktion für deine ETH erforderlich**: Nach dem Ethereum-Pectra-Upgrade ist es nicht notwendig, deine ETH umzuwandeln oder zu aktualisieren. Ihre Kontoguthaben bleiben unverändert und die ETH, die Sie derzeit besitzen, bleiben auch nach der harten Abspaltung in der bestehenden Form zugänglich.
+- **Vorsicht vor Betrug!** **Jeder, der Sie anweist, Ihre ETH zu „aktualisieren“, versucht, Sie zu betrügen.** Es gibt nichts, was Sie in Bezug auf dieses Upgrade tun müssen. Ihre Assets bleiben davon völlig unberührt. Denken Sie daran: Informiert zu sein ist der beste Schutz vor Betrug.
+
+[Mehr zur Erkennung und Vermeidung von Betrug](/security/)
+
+## Eher der visuelle Lernende? {#visual-learner}
+
+
+
+_Was beinhaltet das Pectra-Upgrade? – Christine Kim_
+
+
+
+_Ethereum-Pectra-Upgrade: Was Staker wissen müssen – Blockdaemon_
+
+## Weiterführende Lektüre {#further-reading}
+
+- [Ethereum-Roadmap](/roadmap/)
+- [Pectra-FAQ](https://epf.wiki/#/wiki/pectra-faq)
+- [Pectra.wtf-Infoseite](https://pectra.wtf)
+- [Wie Pectra die Erfahrung für Staker verbessert](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience)
+- [EIP7702-Infoseite](https://eip7702.io/)
+- [Pectra-Devnets](https://github.com/ethereum/pm/blob/master/Pectra/pectra-pm.md)
diff --git a/public/content/translations/de/roadmap/pectra/maxeb/index.md b/public/content/translations/de/roadmap/pectra/maxeb/index.md
new file mode 100644
index 00000000000..21b9253d02e
--- /dev/null
+++ b/public/content/translations/de/roadmap/pectra/maxeb/index.md
@@ -0,0 +1,204 @@
+---
+title: Pectra MaxEB
+description: "Erfahren Sie mehr über MaxEB in der Pectra-Version"
+lang: de
+---
+
+# MaxEB {#maxeb}
+
+_tl;dr:_ Der Pectra Hard Fork ermöglicht es Ethereum-Validatoren, sich für ein höheres maximales effektives Guthaben und eine Aufzinsung zu entscheiden, indem sie von **Typ 1** auf **Typ 2** Auszahlungs-Zugangsdaten umstellen. Das offizielle Tool hierfür ist das Launchpad. Dieser Vorgang kann nicht rückgängig gemacht werden.
+
+## Überblick {#overview}
+
+### Wer ist betroffen? {#who-is-affected}
+
+Jeder, der einen Validator betreibt – dies ist wahrscheinlich jemand, der den Index (z. B. [Validator #12345](https://beaconcha.in/validator/12345)) eines Validators kennt, den er kontrolliert. Wenn Sie ein Protokoll zum Betreiben eines Validators verwenden (z. B. Lido CSM oder Rocket Pool), müssen Sie sich bei diesem erkundigen, ob und wann es maxEB unterstützt.
+
+Wenn Sie mittels eines Liquid-Staking-Tokens (z. B. rETH oder stETH) staken, ist keine Aktion erforderlich oder empfohlen.
+
+### Was ist „maxEB“? {#what-is-maxeb}
+
+maxEB = das MAXimale Effektive Guthaben eines Validators. Bis zum Pectra Hard Fork verdient jeder Validator auf maximal 32 ETH. Nach Pectra haben Validatoren die Möglichkeit, auf jedes Guthaben zwischen 32 und 2048 ETH in 1-ETH-Schritten zu verdienen, indem sie sich für die Änderung entscheiden.
+
+### Wie kann sich ein Validator anmelden? {#how-does-a-validator-opt-in}
+
+Ein Validator entscheidet sich für die maxEB-Änderung, indem er von **Typ 1** zu **Typ 2** Auszahlungs-Zugangsdaten konvertiert. Dies kann auf dem [Launchpad (Validator-Aktionen)](https://launchpad.ethereum.org/validator-actions) erfolgen, nachdem der Pectra Hard Fork live geht. Wie bei **Typ 0** → **Typ 1** ist die Konvertierung von **Typ 1** → **Typ 2** ein unumkehrbarer Prozess.
+
+### Was sind Auszahlungs-Zugangsdaten? {#whats-a-withdrawal-credential}
+
+Wenn Sie einen Validator betreiben, haben Sie einen Satz von Auszahlungs-Zugangsdaten. Diese finden Sie in Ihrer Einzahlungsdaten-JSON-Datei oder Sie können sie auf dem [Einzahlungs-Tab](https://beaconcha.in/validator/12345#deposits) Ihres Validators auf beaconcha.in einsehen.
+
+1. **Typ 0** Auszahlungs-Zugangsdaten: Wenn die Auszahlungs-Zugangsdaten Ihres Validators mit `0x00...` beginnen, haben Sie vor dem Shapella Hard Fork eingezahlt und noch keine Auszahlungsadresse festgelegt.
+
+
+
+2. **Typ 1** Auszahlungs-Zugangsdaten: Wenn die Auszahlungs-Zugangsdaten Ihres Validators mit `0x01...` beginnen, haben Sie nach dem Shapella Hard Fork eingezahlt oder Ihre **Typ 0**-Zugangsdaten bereits in **Typ 1**-Zugangsdaten umgewandelt.
+
+
+
+3. **Typ 2** Auszahlungs-Zugangsdaten: Dieser neue Typ von Auszahlungs-Zugangsdaten beginnt mit `0x02...` und wird nach Pectra aktiviert. Validatoren mit **Typ 2** Auszahlungs-Zugangsdaten werden manchmal als „**Compounding-Validatoren**“ bezeichnet.
+
+| **Erlaubt** | **Nicht erlaubt** |
+| --------------- | ----------------- |
+| ✅ Typ 0 → Typ 1 | ❌ Typ 0 → Typ 2 |
+| ✅ Typ 1 → Typ 2 | ❌ Typ 1 → Typ 0 |
+| | ❌ Typ 2 → Typ 1 |
+| | ❌ Typ 2 → Typ 0 |
+
+### Risiken {#risks}
+
+MaxEB ermöglicht es einem Validator, sein gesamtes Guthaben an einen anderen Validator zu senden. Benutzer, die einen Konsolidierungsantrag einreichen, sollten die Quelle und den Inhalt der Transaktion, die sie unterzeichnen, überprüfen. Das offizielle Tool zur Nutzung der maxEB-Funktionen ist das Launchpad. Wenn Sie sich für die Verwendung eines Drittanbieter-Tools entscheiden, sollten Sie Folgendes überprüfen:
+
+- Der Pubkey und die Auszahlungsadresse des Quell-Validators mit dem von ihnen kontrollierten Validator übereinstimmen
+- Der Pubkey des Ziel-Validators korrekt ist und ihnen gehört
+- Die Anfrage eine Konvertierung und keine Konsolidierung ist, wenn sie nicht beabsichtigen, Gelder an einen anderen Validator zu senden
+- Die Transaktion von der korrekten Auszahlungsadresse unterzeichnet wird
+
+Wir **empfehlen dringend**, jedes Drittanbieter-Tool, das Sie verwenden möchten, mit der [EthStaker-Community](https://ethstaker.org/about) zu besprechen. Es ist ein hilfreicher Ort, um Ihren Ansatz auf Plausibilität zu prüfen und Fehler zu vermeiden. Wenn Sie ein bösartiges oder falsch konfiguriertes Tool verwenden, **könnte Ihr gesamtes Validator-Guthaben an einen Validator gesendet werden, den Sie nicht kontrollieren** – ohne eine Möglichkeit, es zurückzubekommen.
+
+## Technische Details {#technical-details}
+
+### Der Ablauf {#the-flow}
+
+Es wird zwei Verwendungszwecke für die `ConsolidationRequest`-Operation geben:
+
+1. Konvertierung eines bestehenden Validators von einem **Typ-1**- in einen **Typ-2**-Validator
+2. Konsolidierung anderer Validatoren in einen bestehenden **Typ-2**-Validator
+
+Bei der Umwandlung eines **Typ-1**- in einen **Typ-2**-Validator sind sowohl die _Quelle_ als auch das _Ziel_ der Validator, den Sie umwandeln. Die Operation kostet Gas und wird hinter anderen Konsolidierungsanfragen in die Warteschlange gestellt. Diese Warteschlange ist **getrennt** von der Einzahlungswarteschlange und wird von neuen Validator-Einzahlungen nicht beeinflusst. Sie kann auf [pectrified.com](https://pectrified.com/) eingesehen werden.
+
+Um Validatoren zu konsolidieren, benötigen Sie einen _Ziel-Validator_, der über **Typ-2**-Auszahlungs-Zugangsdaten verfügt. Dies ist das Ziel aller konsolidierten Validator-Guthaben und der Index, der beibehalten wird.
+
+### Anforderungen für die Konvertierung in Typ 2 {#requirements-for-converting-to-type-2}
+
+Dies ist für den ersten Validator erforderlich, den Sie in **Typ 2** umwandeln. Der Index dieses Validators wird beibehalten und ist aktiv. Für eine Konvertierung gilt: _Quell-Validator_ == _Ziel-Validator_.
+
+Der Validator muss...
+
+- aktiv sein
+- **Typ 1**-Auszahlungs-Zugangsdaten haben
+- sich nicht in einem Ausstiegszustand befinden (oder von Slashing betroffen sein)
+- keine ausstehenden manuell ausgelösten Auszahlungen haben (gilt nicht für Sweeps)
+
+
+
+### Anforderungen für die Konsolidierung {#requirements-for-consolidating}
+
+Dies ist die _gleiche Operation_ wie die Konvertierung, aber der _Quell-Validator_ ist ein anderer als der _Ziel-Validator_. Der Index des Ziel-Validators wird beibehalten und nimmt das Guthaben vom Quell-Validator an. Der Index des Quell-Validators wird in den `EXITED`-Zustand versetzt.
+
+In diesem Fall gelten für den Quell-Validator alle oben genannten Anforderungen sowie:
+
+- muss seit mindestens ~27,3 Stunden aktiv sein (eine `SHARD_COMMITTEE_PERIOD`)
+
+Der Ziel-Validator muss
+
+- **Typ 2**-Auszahlungs-Zugangsdaten haben
+- sich nicht in einem Ausstiegszustand befinden.
+
+
+
+### Der Konsolidierungsantrag {#the-consolidation-request}
+
+Der Konsolidierungsantrag wird von der mit dem Quell-Validator verbundenen Auszahlungsadresse unterzeichnet und enthält:
+
+1. Adresse des Quell-Validators (z. B. `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`)
+2. Öffentlicher Schlüssel des Quell-Validators (z. B. `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`)
+3. Öffentlicher Schlüssel dieses Ziel-Validators
+
+Bei einer Konvertierung sind 2 & 3 identisch. Diese Operation kann über [das Launchpad](https://launchpad.ethereum.org/) durchgeführt werden.
+
+### Anforderungen an die Signatur {#signing-requirements}
+
+Um einen `ConsolidationRequest` einzureichen, muss die **Auszahlungsadresse des Quell-Validators** die Anfrage signieren. Dies beweist die Kontrolle über die Validator-Gelder.
+
+### Was wird unterzeichnet? {#what-is-signed}
+
+Es wird ein Domain-getrennter [Signing-Root](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_signing_root) des `ConsolidationRequest`-Objekts verwendet.
+
+- **Domain:** `DOMAIN_CONSOLIDATION_REQUEST`
+- **Felder des Signaturstamms:**
+ - `source_pubkey`: `BLSPubkey`
+ - `target_pubkey`: `BLSPubkey`
+ - `source_address`: `ExecutionAddress`
+
+Die resultierende **BLS-Signatur** wird zusammen mit der Anfrage eingereicht.
+
+Hinweis: Die Signatur erfolgt durch die Auszahlungsadresse, nicht durch den Validator-Schlüssel.
+
+### Teilauszahlungen {#partial-withdrawals}
+
+Validatoren mit **Typ 1**-Zugangsdaten erhalten automatische, gasfreie Sweeps ihres überschüssigen Guthabens (alles über 32 ETH) an ihre Auszahlungsadresse. Da **Typ 2** es einem Validator ermöglicht, Guthaben in 1-ETH-Schritten aufzuzinsen, werden Guthaben nicht automatisch als Sweep ausgezahlt, bis sie 2048 ETH erreichen. Teilauszahlungen bei **Typ-2**-Validatoren müssen manuell ausgelöst werden und kosten Gas.
+
+## Konsolidierungs-Werkzeuge {#consolidation-tooling}
+
+Es stehen mehrere Tools zur Verwaltung von Konsolidierungen zur Verfügung. Das offizielle, von der Ethereum Foundation entwickelte Tool ist das [Launchpad](https://launchpad.ethereum.org/en/validator-actions). Es gibt auch Tools von Drittanbietern aus der Staking-Community, die möglicherweise Funktionen bieten, die das Launchpad nicht bereitstellt. Obwohl die hier vorgestellten Tools nicht von der Ethereum Foundation geprüft oder unterstützt werden, handelt es sich bei den folgenden um Open-Source-Tools von bekannten Mitgliedern der Community.
+
+| Werkzeug | Website | Offene Quelle (Open Source) | Ersteller | Geprüft | Schnittstelle | Bemerkenswerte Funktionen |
+| ------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
+| Pectra Staking Manager | pectrastaking.com | Ja, Apache 2.0 | [Pier Two](https://piertwo.com/) | Nein | Web-UI | Wallet Connect, funktioniert mit SAFE |
+| Pectra Validator Ops CLI Tool | [GitHub](https://github.com/Luganodes/Pectra-Batch-Contract) | Ja, MIT | [Luganodes](https://www.luganodes.com/) | Ja, Quantstamp [Mai 2025](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | Kommandozeile | Batch-Verarbeitung für viele Validatoren auf einmal |
+| Ethereal | [GitHub](https://github.com/wealdtech/ethereal) | Ja, Apache 2.0 | [Jim McDonald](https://www.attestant.io/team/) | Nein | Kommandozeile | Vollständiger Funktionsumfang für die Verwaltung von Validatoren und Nodes |
+| Siren | [GitHub](https://github.com/sigp/siren) | Ja, Apache 2.0 | [Sigma Prime](https://sigmaprime.io/) | Nein | Einige Befehlszeilen, aber hauptsächlich Web-UI | Funktioniert nur, wenn Sie den Lighthouse Konsens-Client verwenden |
+| Consolideth.app | https://consolideth.app/ [GitHub](https://github.com/Stakely/consolideth) | Ja, MIT-Lizenzen | [Stakely](https://stakely.io/) | Nein | Web-UI, gehostet von stakely und bereit, frei selbst gehostet zu werden | Unterstützt die wichtigsten Wallet-Verbindungen einschließlich Safe mit WalletConnect |
+
+## FAQ {#faq}
+
+### Ändert die Teilnahme mein Vorschlagsglück oder meine Belohnungen? {#change-luck-or-rewards}
+
+Nein. Die Teilnahme verringert nicht Ihre Chance auf einen Vorschlag – Ihre Aufgaben und die Auswahl der Vorschläge bleiben gleich. Wenn Sie beispielsweise zwei 32-ETH-Validatoren im Vergleich zu einem 64-ETH-Validator haben, haben Sie die gleichen Gesamtchancen, für einen Blockvorschlag ausgewählt zu werden und Belohnungen zu erhalten.
+
+### Ändert die Teilnahme mein Slashing-Risiko? {#change-slashing-risk}
+
+Für kleinere oder unprofessionelle Betreiber lautet die kurze Antwort: Nein. Die längere Antwort ist, dass für professionelle Betreiber, die viele Validatoren pro Node mit schneller Alarmierung betreiben, die Konsolidierung in weniger Validatoren ihre Fähigkeit, auf ein Slashing zu reagieren und Kaskadenereignisse zu verhindern, verringern kann. Die anfängliche Slashing-_Strafe_ für alle Validatoren wurde drastisch von 1 ETH (pro 32 ETH) auf 0,0078125 ETH (pro 32 ETH) reduziert, um dieses Risiko auszugleichen.
+
+### Muss ich meinen Validator verlassen, um ihn zu konvertieren? {#exit-validator}
+
+Nein. Sie können die Konvertierung ohne Beenden durchführen.
+
+### Wie lange dauert die Konvertierung / Konsolidierung? {#how-long}
+
+Mindestens 27,3 Stunden, aber Konsolidierungen unterliegen auch einer Warteschlange. Diese Warteschlange ist unabhängig von den Ein- und Auszahlungswarteschlangen und wird von diesen nicht beeinflusst.
+
+### Kann ich meinen Validator-Index behalten? {#keep-validator-index}
+
+Ja. Bei der In-Place-Konvertierung wird derselbe Validator-Index beibehalten. Wenn Sie mehrere Validatoren konsolidieren, können Sie nur den Index des _Ziel-Validators_ behalten.
+
+### Werde ich Attestierungen verpassen? {#miss-attestations}
+
+Während einer Konsolidierung in einen anderen Validator wird der Quell-Validator beendet, und es gibt eine Wartezeit von ca. 27 Stunden, bevor das Guthaben auf dem Ziel-Validator aktiv ist. Dieser Zeitraum **beeinflusst die Leistungsmetriken nicht**.
+
+### Werde ich Strafen erhalten? {#incur-penalties}
+
+Nein. Solange Ihr Validator online ist, werden Sie keine Strafen erhalten.
+
+### Müssen die Auszahlungsadressen der zu konsolidierenden Validatoren übereinstimmen? {#withdrawal-addresses-match}
+
+Nein. Aber die _Quelle_ muss die Anfrage von ihrer eigenen Adresse aus autorisieren.
+
+### Werden meine Belohnungen nach der Konvertierung auf- oder verzinst? {#rewards-compound}
+
+Ja. Mit **Typ 2**-Zugangsdaten werden Belohnungen über 32 ETH automatisch wieder gestaked – aber nicht sofort. Aufgrund eines kleinen Puffers (genannt [_Hysterese_](https://eth2book.info/capella/part2/incentives/balances/#hysteresis)) muss Ihr Guthaben **etwa 1,25 ETH mehr** erreichen, bevor der zusätzliche Betrag erneut gestakt wird. Statt also bei 33,0 ETH zu verzinsen, geschieht dies bei 33,25 (effektives Guthaben = 33 ETH), dann bei 34,25 (effektives Guthaben = 34 ETH) und so weiter.
+
+### Kann ich nach der Konvertierung weiterhin automatische Sweeps erhalten? {#automatic-sweep}
+
+Automatische Sweeps werden nur bei überschüssigen Guthaben von über 2048 stattfinden. Für alle anderen Teilauszahlungen müssen Sie diese manuell auslösen.
+
+### Kann ich meine Meinung ändern und von Typ 2 zu Typ 1 zurückkehren? {#go-back-to-type1}
+
+Nein. Die Konvertierung in **Typ 2** ist unumkehrbar.
+
+### Wenn ich mehrere Validatoren konsolidieren möchte, muss ich jeden zuerst auf Typ 2 umstellen? {#consolidate-multiple-validators}
+
+Nein! Konvertieren Sie einen Validator zu Typ 2 und verwenden Sie diesen dann als Ziel. Alle anderen Validatoren, die in dieses Typ-2-Ziel konsolidiert werden, können Typ 1 oder Typ 2 sein.
+
+### Mein Validator ist offline oder unter 32 ETH - kann ich ihn trotzdem konvertieren? {#offline-or-below-32eth}
+
+Ja. Solange er aktiv ist (nicht beendet) und Sie mit seiner Auszahlungsadresse signieren können, können Sie ihn konvertieren.
+
+## Ressourcen {#resources}
+
+- [Electra Konsens-Spezifikationen](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md): Dies ist die ‚wahrste‘ Version, auf die Sie sich verlassen sollten. Im Zweifelsfall die Spezifikationen lesen
+- Nicht jeder fühlt sich wohl dabei, sich durch Code zu wühlen, daher kann [dieser maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) helfen, die Spezifikationen zu interpretieren. _Haftungsausschluss: Man sollte sich auf die Spezifikationen als Wahrheit verlassen, nicht auf die KI, da die KI Informationen falsch interpretieren oder Antworten halluzinieren kann_
+- [pectrified.com](https://pectrified.com/): Sehen Sie sich den Status von Konsolidierungen, Einzahlungen und Wartezeiten in der Warteschlange an
+- [Ethereal](https://github.com/wealdtech/ethereal): Von der Community erstelltes CLI-Tool zur Verwaltung gängiger Validator-Aufgaben
+- [batch-validator-depositor](https://github.com/attestantio/batch-validator-depositor): Von der Community erstellter Vertrag, der die Einzahlung mehrerer Ethereum-Validatoren in einer einzigen Transaktion ermöglicht
diff --git a/public/content/translations/de/roadmap/scaling/index.md b/public/content/translations/de/roadmap/scaling/index.md
index bb6aa5b6b9e..997847da60b 100644
--- a/public/content/translations/de/roadmap/scaling/index.md
+++ b/public/content/translations/de/roadmap/scaling/index.md
@@ -1,13 +1,13 @@
---
title: Ethereum zu skalieren
-description: Rollups fassen Transaktionen off-chain zusammen und senken so die Kosten für den Nutzer. Die derzeitige Art und Weise, wie Rollups Daten verwenden, ist jedoch zu teuer und schränkt ein, wie günstig Transaktionen sein könnten. Proto-Danksharding behebt das.
+description: "Durch das Bündeln von Transaktionen off-chain verringern Rollups die Kosten für den Anwender. Die derzeitige Art und Weise, wie Rollups Daten verwenden, ist jedoch zu teuer und schränkt ein, wie günstig Transaktionen sein könnten. Proto-Danksharding behebt das."
lang: de
image: /images/roadmap/roadmap-transactions.png
alt: "Ethereum-Roadmap"
template: roadmap
---
-Ethereum wird mit Hilfe von [Layer 2s](/layer-2/#rollups) (auch bekannt als Rollups) skaliert, die Transaktionen zusammenfassen und den Output an Ethereum senden. Obwohl Rollups bis zu achtmal günstiger sind als das Ethereum Mainnet, kann man Rollups noch weiter optimieren, um die Kosten für die Endnutzer zu senken. Rollups stützen sich auch auf einige zentralisierte Komponenten, die mit zunehmender Reife der Rollups von den Entwicklern entfernt werden können.
+Ethereum wird mit Hilfe von Layer 2s (auch bekannt als Rollups) skaliert, die Transaktionen zusammenfassen und den Output an Ethereum senden. Obwohl Rollups bis zu achtmal günstiger sind als das Ethereum Mainnet, kann man Rollups noch weiter optimieren, um die Kosten für die Endnutzer zu senken. Rollups stützen sich auch auf einige zentralisierte Komponenten, die mit zunehmender Reife der Rollups von den Entwicklern entfernt werden können.
@@ -31,26 +31,28 @@ Rollups sammeln eine große Anzahl von Transaktionen, führen sie aus und überm
Rollup-Daten wurden in der Vergangenheit dauerhaft auf Ethereum gespeichert, was teuer ist. Über 90 % der Transaktionskosten, die die Nutzer für Rollups zahlen, sind auf diese Datenspeicherung zurückzuführen. Um die Transaktionskosten zu senken, können wir die Daten in einen neuen temporären "Blob"-Speicher verschieben. Blobs sind billiger, weil sie nicht dauerhaft sind; sie werden aus Ethereum gelöscht, sobald sie nicht mehr benötigt werden. Die langfristige Speicherung von Rollup-Daten liegt in der Veranwortung derjenigen, die sie benötigen, wie z. B. Rollup-Betreibern, Börsen, Indexierungsdiensten usw. Das Hinzufügen von Blob-Transaktionen zu Ethereum ist Teil eines Upgrades, das als "Proto-Danksharding" bekannt ist.
-Mit Proto-Danksharding lassen sich viele Blobs zu Ethereum-Blöcken hinzufügen. Dadurch wird eine weitere signifikante (>100x) Erhöhung des Ethereum-Durchsatzes und eine deutliche Reduzierung der Transaktionskosten möglich.
+Mit Proto-Danksharding lassen sich viele Blobs zu Ethereum-Blöcken hinzufügen. Dies ermöglicht eine weitere erhebliche (>100x) Steigerung des Ethereum-Durchsatzes und Senkung der Transaktionskosten.
### Danksharding {#danksharding}
-Die zweite Stufe der Erweiterung von Blob-Daten ist kompliziert, weil dafür neue Methoden zur Überprüfung der Verfügbarkeit von Rollup-Daten im Netz erforderlich sind. Außerdem wird dafür vorausgesetzt, dass [Validatoren](/glossary/#validator) ihre Verantwortung für [Block](/glossary/#block)-Bau und Blockvorschläge auseinanderhalten. Außerdem muss kryptografisch nachgewiesen werden, dass die Validatoren kleine Teilmengen der Blobdaten überprüft haben.
+Die zweite Stufe der Erweiterung von Blob-Daten ist kompliziert, weil sie neue Methoden zur Überprüfung der Verfügbarkeit von Rollup-Daten im Netzwerk erfordert und davon abhängt, dass [Validatoren](/glossary/#validator) ihre Zuständigkeiten für die [Block](/glossary/#block)bildung und den Blockvorschlag voneinander trennen. Außerdem muss kryptografisch nachgewiesen werden, dass die Validatoren kleine Teilmengen der Blobdaten überprüft haben.
-Dieser zweite Schritt ist bekannt unter dem Namen [“Danksharding”](/roadmap/danksharding/). **Es wird wahrscheinlich noch einige Jahre dauern, bis es zu einer vollständigen Umsetzung kommt**. Danksharding stützt sich auf andere Entwicklungen wie die [Trennung von Blockbildung und Blockvorschlag](/roadmap/pbs) und neue Netzwerkdesigns, die es dem Netzwerk ermöglichen, die Verfügbarkeit von Daten effizient zu bestätigen, indem jeweils einige Kilobyte zufällig abgetastet werden, was als [data availability sampling (DAS)](/developers/docs/data-availability) bekannt ist.
+Dieser zweite Schritt ist als ["Danksharding"](/roadmap/danksharding/) bekannt. Die Implementierungsarbeiten werden fortgesetzt, wobei Fortschritte bei Voraussetzungen wie der [Trennung von Blockerstellung und Blockvorschlag](/roadmap/pbs) und bei neuen Netzwerkdesigns gemacht werden, die es dem Netzwerk ermöglichen, die Datenverfügbarkeit durch zufälliges Abtasten einiger Kilobytes auf einmal effizient zu bestätigen, bekannt als [Data Availability Sampling (DAS)](/developers/docs/data-availability).
Mehr zu Danksharding
-## Rollups dezentralisieren {#decentralizing-rollups}
+## Dezentralisierung von Rollups {#decentralizing-rollups}
-[Rollups](/layer-2) sind bereits dabei, Ethereum zu skalieren. Ein [reichhaltiges Ökosystem von Rollup-Projekten](https://l2beat.com/scaling/tvl) ermöglicht es den Nutzern, schnell und kostengünstig Transaktionen durchzuführen und dabei eine Reihe von Sicherheitsgarantien zu bieten. Rollups wurden jedoch mit zentralisierten Sequenzern (Computer, die die gesamte Transaktionsverarbeitung und -aggregation durchführen, bevor sie an Ethereum übermittelt werden) gebootet. Dies ist anfällig für Zensur, da die Betreiber der Sequenzer sanktioniert, bestochen oder anderweitig kompromittiert werden können. Gleichzeitig unterscheiden sich [Rollups](https://l2beat.com) in der Art und Weise, wie sie die eingehenden Daten validieren. Am besten ist es, wenn die „Prüfer“ [Betrugsnachweise](/glossary/#fraud-proof) oder Gültigkeitsnachweise einreichen, aber noch sind nicht alle Rollups so weit. Selbst die Rollups, die Gültigkeits-/Betrugsnachweise verwenden, nutzen einen kleinen Pool von bekannten Prüfern. Daher besteht der nächste kritische Schritt bei der Skalierung von Ethereum darin, die Verantwortung für den Betrieb von Sequenzern und Prüfern auf mehr Personen zu verteilen.
+[Rollups](/layer-2) skalieren bereits Ethereum. Ein [reichhaltiges Ökosystem von Rollup-Projekten](https://l2beat.com/scaling/tvs) ermöglicht es Nutzern, mit einer Reihe von Sicherheitsgarantien schnell und kostengünstig Transaktionen durchzuführen. Rollups wurden jedoch mit zentralisierten Sequenzern (Computer, die die gesamte Transaktionsverarbeitung und -aggregation durchführen, bevor sie an Ethereum übermittelt werden) gebootet. Dies ist anfällig für Zensur, da die Betreiber der Sequenzer sanktioniert, bestochen oder anderweitig kompromittiert werden können. Gleichzeitig [variieren Rollups](https://l2beat.com/scaling/summary) in der Art und Weise, wie sie eingehende Daten validieren. Am besten ist es, wenn "Prover" [Betrugsbeweise](/glossary/#fraud-proof) oder Gültigkeitsnachweise einreichen, aber noch sind nicht alle Rollups so weit. Selbst die Rollups, die Gültigkeits-/Betrugsnachweise verwenden, nutzen einen kleinen Pool von bekannten Prüfern. Daher besteht der nächste kritische Schritt bei der Skalierung von Ethereum darin, die Verantwortung für den Betrieb von Sequenzern und Prüfern auf mehr Personen zu verteilen.
-Mehr zu Rollups
+Mehr über Rollups
## Aktueller Fortschritt {#current-progress}
-Proto-Danksharding ist das erste dieser Roadmap-Elemente, das im Rahmen des Netzwerk-Upgrades Cancun-Deneb („Dencun“) im März 2024 implementiert wird. **Zur vollständigen Umsetzung von Danksharding kommt es wahrscheinlich erst in einigen Jahren**, da hierfür zunächst mehrere andere Roadmap-Elemente abgeschlossen werden müssen. Die Dezentralisierung der Rollup-Infrastruktur wird wahrscheinlich ein schrittweiser Prozess sein - es gibt viele verschiedene Rollups, die leicht unterschiedliche Systeme aufbauen und in unterschiedlichem Tempo vollständig dezentralisieren werden.
+Mit dem Netzwerk-Upgrade Cancun-Deneb („Dencun“) im März 2024 erfolgte die erfolgreiche Einführung von Proto-Danksharding. Seit seiner Implementierung haben Rollups begonnen, Blob-Speicher zu nutzen, was zu geringeren Transaktionskosten für Nutzer und Millionen von in Blobs verarbeiteten Transaktionen geführt hat.
-[Weitere Informationen zum Dencun-Netzwerk-Upgrade](/roadmap/dencun/)
+Die Arbeiten an Full Danksharding werden fortgesetzt, und es werden Fortschritte bei dessen Voraussetzungen wie PBS (Proposer-Builder Separation) und DAS (Data Availability Sampling) erzielt. Die Dezentralisierung der Rollup-Infrastruktur ist ein schrittweiser Prozess – es gibt viele verschiedene Rollups, die geringfügig unterschiedliche Systeme aufbauen und sich in unterschiedlichem Tempo vollständig dezentralisieren werden.
+
+[Mehr über das Dencun-Netzwerk-Upgrade und seine Auswirkungen](/roadmap/dencun/)
diff --git a/public/content/translations/de/roadmap/secret-leader-election/index.md b/public/content/translations/de/roadmap/secret-leader-election/index.md
index babf9f84b15..907d7607163 100644
--- a/public/content/translations/de/roadmap/secret-leader-election/index.md
+++ b/public/content/translations/de/roadmap/secret-leader-election/index.md
@@ -1,6 +1,6 @@
---
-title: Geheime Führungswahl
-description: Erklärung wie geheime Führungswahlen helfen können, Validatoren von Angreifen zu schützen
+title: "Geheime Führungswahl"
+description: "Erklärung wie geheime Führungswahlen helfen können, Validatoren von Angreifen zu schützen"
lang: de
summaryPoints:
- Die IP-Adresse von Blockantragstellern (Proposern) kann im Vorne herein bekannt sein, was sie Angriffen aussetzt
@@ -10,17 +10,17 @@ summaryPoints:
# Geheime Führungswahl {#single-secret-leader-election}
-Im heutigen [Proof-of-Stake](/developers/docs/consensus-mechanisms/pos) basierten Konsensmechanismus ist die Liste der bevorstehenden Blockantragsteller öffentlich und es ist möglich ihre IP-Adressen herauszufinden. Das heißt, dass Angreifer herausfinden könnten, welche Validatoren an der Reihe sind einen Block vorzuschlagen und diesen mit einer Denial-of-Service (DOS) Attacke angreifen. Dadurch könnte der Validator nicht mehr rechtzeitig einen Block vorschlagen.
+Im heutigen, auf [Proof-of-Stake](/developers/docs/consensus-mechanisms/pos) basierenden Konsensmechanismus ist die Liste der bevorstehenden Block-Vorschlagenden öffentlich und es ist möglich, deren IP-Adressen zu ermitteln. Das heißt, dass Angreifer herausfinden könnten, welche Validatoren an der Reihe sind einen Block vorzuschlagen und diesen mit einer Denial-of-Service (DOS) Attacke angreifen. Dadurch könnte der Validator nicht mehr rechtzeitig einen Block vorschlagen.
-Das könnte eine Gelegenheit erzeugen, aus der der Angreifer profitieren könnte. Ein Blockantragsteller, der für Slot `n+1` gewählt wurde, könnte den Blockantragsteller in Slot `n` gewählt wurde mit einer DOS-Attacke angreifen. Dadurch verliert dieser in Slot `n` die Möglichkeit einen neuen Block vorzuschlagen. Das würde dem angreifenden Blockantragsteller erlauben, MEV aus beiden Slots zu ziehen, oder alle Transaktionen, welche zwischen zwei Blöcken geteilt werden hätten sollen, nehmen. Das führt dazu, dass der Angreifer alle zugehörigen Gebühren verdienen würde. Das trifft wahrscheinlich Validatoren, die Einzelpersonen zu Hause gehören, mehr als ausgefeilten institutionellen Validatoren, welche fortgeschrittenere Methoden nutzen können, um sich vor DOS-Attacken zu schützen. Das könnte sie zu einer zentralisierenden Macht machen.
+Das könnte eine Gelegenheit erzeugen, aus der der Angreifer profitieren könnte. Beispielsweise könnte ein für Slot `n+1` ausgewählter Block-Vorschlagender den Vorschlagenden in Slot `n` mit einem DoS-Angriff attackieren, sodass dieser seine Möglichkeit verpasst, einen Block vorzuschlagen. Das würde dem angreifenden Blockantragsteller erlauben, MEV aus beiden Slots zu ziehen, oder alle Transaktionen, welche zwischen zwei Blöcken geteilt werden hätten sollen, nehmen. Das führt dazu, dass der Angreifer alle zugehörigen Gebühren verdienen würde. Das trifft wahrscheinlich Validatoren, die Einzelpersonen zu Hause gehören, mehr als ausgefeilten institutionellen Validatoren, welche fortgeschrittenere Methoden nutzen können, um sich vor DOS-Attacken zu schützen. Das könnte sie zu einer zentralisierenden Macht machen.
-Es gibt mehrere Lösungsansätze für dieses Problem. Eines ist die [Verteilte Validatoren Technologie](https://github.com/ethereum/distributed-validator-specs) welche versucht mehrere Aufgaben, die für den Betrieb von Validatoren wichtig sind, auf mehrere Maschinen mit Redundanz zu verteilen. Dadurch wird es für einen Angreifer viel schwerer einem Block zu verhindern in einem bestimmten Slot vorgeschlagen zu werden. Jedoch ist die robusteste Lösung die **Einzelne geheime Führungswahl (SSLE)**.
+Es gibt mehrere Lösungsansätze für dieses Problem. Eine davon ist die [Distributed Validator Technology](https://github.com/ethereum/distributed-validator-specs), die darauf abzielt, die verschiedenen Aufgaben im Zusammenhang mit dem Betrieb eines Validators mit Redundanz auf mehrere Maschinen zu verteilen, sodass es für einen Angreifer viel schwieriger ist, zu verhindern, dass ein Block in einem bestimmten Slot vorgeschlagen wird. Die robusteste Lösung ist jedoch die **einzelne geheime Führungswahl (SSLE)**.
-## Geheime Einzelwahl des Leiters {#secret-leader-election}
+## Einzelne geheime Führungswahl {#secret-leader-election}
In der SSLE wird kluge Kryptographie genutzt, um sicherzustellen, dass nur der gewählte Validator weiß, dass er gewählt wurde. Dies funktioniert, indem jeder Validator eine Verpflichtung zu einem gemeinsamen Geheimnis abgibt. Die Verpflichtungen werden gemischt und neu konfiguriert, sodass niemand die einzelnen Verpflichtungen zu Validatoren herausfinden kann. Jeder Validator weiß jedoch welche Verpflichtung zu ihm gehört. Dann wird eine Verpflichtung zufällig ausgewählt. Wenn der Validator bemerkt, dass seine Verpflichtung gewählt wurde, weiß er, dass er einen Block vorschlagen darf.
-Die führende Implementation dieser Idee nennt sich [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Welche wie folgt funktioniert:
+Die führende Implementierung dieser Idee nennt sich [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Welche wie folgt funktioniert:
1. Validatoren verpflichten sich zu einem gemeinsamen Geheimnis. Das Verpflichtungssystem ist so konzipiert, dass es zu der Identität eines Validatoren gebunden werden kann, jedoch gleichzeitig so zufällig aufgebaut ist, dass es nicht reversibel ist. Das heißt, dass kein Dritter den Bund rekonstruieren und so eine spezifische Verpflichtung zu einem spezifischen Validator herstellen kann.
2. Beim Start jeder Epoche wird eine zufällige Teilmenge an Validatoren gewählt, um Verpflichtungen von 16384 Validatoren mit RANDAO zu sampeln.
@@ -31,14 +31,14 @@ Die führende Implementation dieser Idee nennt sich [Whisk](https://ethresear.ch
Das hindert Angreifer davon, im Vorne herein zu wissen, welcher Validator den nächsten Block vorschlagen wird, was DOS-Attacken verhindert.
-## Nicht-Einzelne geheime Führungswahl (SnSLE) {#secret-non-single-leader-election}
+## Geheime nicht-einzelne Führungswahl (SnSLE) {#secret-non-single-leader-election}
-Es gibt auch einen anderen Vorschlag, welcher versucht ein Szenario zu erstellen, in dem Validatoren in jedem Slot eine zufällige Chance haben, einen Validator vorzuschlagen. Das wäre ähnlich wie Blockanträge beim Proof-of-Work Algorithmus gewählt wurden, bekannt als **Nicht-Einzelne geheime Führungswahl (SnSLE)**. Ein einfacher Weg dies zu tun ist, die RANDAO Funktion zu nutzen, um zufällig Validatoren im heutigen Protokoll auszuwählen. Die Idee von RANDAO ist, dass eine ausreichend zufällige Zahl durch das Mischen von Hashes von vielen unabhängigen Validatoren eingereicht werden. Bei SnSLE könnten diese Hashes genutzt werden, um den nächsten Blockantragsteller zu wählen, beispielsweise den Hash mit dem niedrigsten Wert. Die Spanne von validen Hashes könnte eingeschränkt werden, um die Wahrscheinlichkeit, dass ein individueller Validator in einen Slot gewählt wird anzupassen. Indem man festlegt, dass der Hash kleiner als `2^256 * 5 / N` sein muss, wobei `N` der Anzahl an aktiven Validatoren entspricht, würde die Chance, dass jeder einzelne Validator gewählt wird `5/N` entsprechen. In diesem Beispiel gäbe es eine 99,3 % Chance, dass mindestens ein Antragsteller einen validen Hash in jedem Slot generiert.
+Es gibt auch einen separaten Vorschlag, der darauf abzielt, ein Szenario zu schaffen, in dem Validatoren in jedem Slot eine zufällige Chance haben, einen Block vorzuschlagen. Dies ist ähnlich der Art und Weise, wie unter Proof-of-Work über die Blockvorschläge entschieden wurde, bekannt als **geheime nicht-einzelne Führungswahl (SnSLE)**. Ein einfacher Weg dies zu tun ist, die RANDAO Funktion zu nutzen, um zufällig Validatoren im heutigen Protokoll auszuwählen. Die Idee von RANDAO ist, dass eine ausreichend zufällige Zahl durch das Mischen von Hashes von vielen unabhängigen Validatoren eingereicht werden. Bei SnSLE könnten diese Hashes genutzt werden, um den nächsten Blockantragsteller zu wählen, beispielsweise den Hash mit dem niedrigsten Wert. Die Spanne von validen Hashes könnte eingeschränkt werden, um die Wahrscheinlichkeit, dass ein individueller Validator in einen Slot gewählt wird anzupassen. Indem festgelegt wird, dass der Hash kleiner als `2^256 * 5 / N` sein muss, wobei `N` der Anzahl der aktiven Validatoren entspricht, würde die Chance, dass ein einzelner Validator in jedem Slot ausgewählt wird, `5/N` betragen. In diesem Beispiel gäbe es eine 99,3 % Chance, dass mindestens ein Antragsteller einen validen Hash in jedem Slot generiert.
## Aktueller Fortschritt {#current-progress}
SSLE und SnSLE sind beide in der Forschungsphase. Es gibt noch keine finalen Spezifikationen für diese Idee. SSLE und SnSLE sind konkurrierende Vorschläge, von denen nur einer implementiert werden könnte. Vor der Veröffentlichung muss mehr Forschung, Entwicklung, Prototypenherstellung und Implementierung auf öffentlichen Testnetzen durchgeführt werden.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789)
diff --git a/public/content/translations/de/roadmap/security/index.md b/public/content/translations/de/roadmap/security/index.md
index 548e51333ac..718d56ee887 100644
--- a/public/content/translations/de/roadmap/security/index.md
+++ b/public/content/translations/de/roadmap/security/index.md
@@ -1,48 +1,48 @@
---
title: Ein sichereres Ethereum Netzwerk
-description: Ethereum ist die sicherste und dezentralisierte Smart-Contract-Plattform, die es gibt. Es gibt jedoch immer noch Verbesserungen, die vorgenommen werden können, um Ethereum bis weit in die Zukunft hinein gegen jegliche Art von Angriffen zu wappnen.
+description: "Ethereum ist die sicherste und dezentralisierte Smart-Contract-Plattform, die es gibt. Es gibt jedoch immer noch Verbesserungen, die vorgenommen werden können, um Ethereum bis weit in die Zukunft hinein gegen jegliche Art von Angriffen zu wappnen."
lang: de
image: /images/roadmap/roadmap-security.png
alt: "Ethereum-Roadmap"
template: roadmap
---
-**Ethereum ist bereits eine sehr sichere**, dezentrale Plattform für [Smart-Contracts](/glossary/#smart-contract). Es gibt jedoch immer noch Verbesserungen, die vorgenommen werden können, um Ethereum bis weit in die Zukunft hinein gegen jegliche Art von Angriffen zu wappnen. Dazu gehören subtile Änderungen an der Art und Weise, wie [Ethereum-Clients](/glossary/#consensus-client) mit konkurrierenden [Blöcken](/glossary/#block) umgehen, sowie eine Erhöhung der Geschwindigkeit, mit der das Netzwerk Blöcke als [„finalisiert“](/developers/docs/consensus-mechanisms/pos/#finality) betrachtet (was bedeutet, dass sie nicht geändert werden können, ohne dass einem Angreifer extreme wirtschaftliche Verluste entstehen).
+**Ethereum ist bereits eine sehr sichere**, dezentralisierte [Smart-Contract](/glossary/#smart-contract)-Plattform. Es gibt jedoch immer noch Verbesserungen, die vorgenommen werden können, um Ethereum bis weit in die Zukunft hinein gegen jegliche Art von Angriffen zu wappnen. Dazu gehören subtile Änderungen an der Art und Weise, wie [Ethereum-Clients](/glossary/#consensus-client) mit konkurrierenden [Blöcken](/glossary/#block) umgehen, sowie eine Erhöhung der Geschwindigkeit, mit der das Netzwerk Blöcke als [„finalisiert“](/developers/docs/consensus-mechanisms/pos/#finality) betrachtet (was bedeutet, dass sie nicht ohne extreme wirtschaftliche Verluste für einen Angreifer geändert werden können).
-Es gibt zudem Verbesserungen, die das Zensieren von Transaktionen erheblich erschweren, indem sie den Block-Konstrukteur blind für den tatsächlichen Inhalt ihrer Blöcke machen, und neue Möglichkeiten, zu erkennen, wann ein Block-Prüfer zensiert. Zusammen werden diese Verbesserungen das [Proof-of-Stake](/glossary/#pos)-Protokoll aktualisieren, sodass Benutzer – von Einzelpersonen bis hin zu Unternehmen – sofortiges Vertrauen in ihre Apps, Daten und Vermögenswerte auf Ethereum haben können.
+Es gibt zudem Verbesserungen, die das Zensieren von Transaktionen erheblich erschweren, indem sie den Block-Konstrukteur blind für den tatsächlichen Inhalt ihrer Blöcke machen, und neue Möglichkeiten, zu erkennen, wann ein Block-Prüfer zensiert. Zusammen werden diese Verbesserungen das [Proof-of-Stake](/glossary/#pos)-Protokoll verbessern, sodass Benutzer – von Einzelpersonen bis hin zu Unternehmen – sofortiges Vertrauen in ihre Apps, Daten und Vermögenswerte auf Ethereum haben.
## Staking-Auszahlungen {#staking-withdrawals}
-Das Upgrade von [Proof-of-Work](/glossary/#pow) auf Proof-of-Stake nahm damit seinen Anfang, dass Wegbereiter auf Ethereum ihre ETH per „Staking“ in einem Einzahlungsvertrag deponierten. Dieses ETH wird zum Schutz des Netzes verwendet. Am 12. April 2023 gab es ein zweites Update, um das Abheben der eingesetzten ETH zu ermöglichen. Seither können Validatoren ETH frei „staken “ oder abheben.
+Das Upgrade von [Proof-of-Work](/glossary/#pow) auf Proof-of-Stake begann damit, dass Ethereum-Pioniere ihre ETH durch „Staking“ in einem Einzahlungsvertrag hinterlegten. Dieses ETH wird zum Schutz des Netzes verwendet. Am 12. April 2023 gab es ein zweites Update, das es Validatoren ermöglichte, gestakte ETH abzuheben. Seither können Validatoren ETH frei „staken “ oder abheben.
-Lesen Sie mehr über Auszahlungen
+Informationen zu Auszahlungen
-## Angriff abwehren {#defending-against-attacks}
+## Schutz vor Angriffen {#defending-against-attacks}
-Es gibt Verbesserungen, die am Proof-of-Stake-Protokoll von Ethereum vorgenommen werden können. Eine davon ist als [View-Merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) bekannt – ein sicherer [Abspaltungs](/glossary/#fork)-Wahlalgorithmus, der bestimmte ausgefeilte Angriffsarten erschwert.
+Es gibt Verbesserungen, die am Proof-of-Stake-Protokoll von Ethereum vorgenommen werden können. Einer davon ist als [View-Merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) bekannt – ein sichererer [Fork](/glossary/#fork)-Auswahlalgorithmus, der bestimmte komplexe Angriffsarten erschwert.
-Eine Verkürzung der Zeit, die Ethereum für die [Finalisierung](/glossary/#finality) von Blöcken benötigt, würde für eine bessere Benutzererfahrung sorgen. Außerdem würde sie ausgefeilte „Reorg“-Angriffe verhindern, bei denen Angreifer versuchen, kürzlich erstellte Blöcke umzuorganisieren, um Profit zu machen oder bestimmte Transaktionen zu zensieren. [**Einzelplatzendgültigkeit („Single Slot Finality“, SSF)**](/roadmap/single-slot-finality/) ist eine **Möglichkeit zur Minimierung der Finalisierungsverzögerung**. Zurzeit besteht die Möglichkeit, dass ein Angreifer andere Validierer dazu bewegt, Blöcke in einem Zeitraum von 15 Minuten neu zu konfigurieren. Mit SSF ist dieser Zeitrahmen gleich 0. Nutzer, von Einzelpersonen bis hin zu Anwendungen und Börsen, profitieren von der schnellen Gewissheit, dass ihre Transaktionen nicht rückgängig gemacht werden, und das Netzwerk profitiert davon, dass eine ganze Klasse von Angriffen unterbunden wird.
+Die Verkürzung der Zeit, die Ethereum benötigt, um Blöcke zu [finalisieren](/glossary/#finality), würde eine bessere Benutzererfahrung bieten und komplexe „Reorg“-Angriffe verhindern, bei denen Angreifer versuchen, die neuesten Blöcke neu zu ordnen, um Profit zu erzielen oder bestimmte Transaktionen zu zensieren. [**Single-Slot Finality (SSF)**](/roadmap/single-slot-finality/) ist eine **Möglichkeit, die Finalisierungsverzögerung zu minimieren**. Zurzeit besteht die Möglichkeit, dass ein Angreifer andere Validierer dazu bewegt, Blöcke in einem Zeitraum von 15 Minuten neu zu konfigurieren. Mit SSF ist dieser Zeitrahmen gleich 0. Nutzer, von Einzelpersonen bis hin zu Anwendungen und Börsen, profitieren von der schnellen Gewissheit, dass ihre Transaktionen nicht rückgängig gemacht werden, und das Netzwerk profitiert davon, dass eine ganze Klasse von Angriffen unterbunden wird.
-Lesen Sie mehr über die Endgültigkeit voneinzelnen Slots
+Informationen zu Single-Slot Finality
-## Verteidigung gegen Zensur {#defending-against-censorship}
+## Schutz vor Zensur {#defending-against-censorship}
-Durch die Dezentralisierung wird verhindert, dass Einzelpersonen oder kleine Gruppen von [Validatoren](/glossary/#validator) zu einflussreich werden. Neue Staking-Technologien können dazu beitragen, dass die Ethereum-Validatoren so dezentralisiert wie möglich bleiben und gleichzeitig vor Hardware-, Software- und Netzwerkausfällen geschützt sind. Hierzu gehört Software, die die Verantwortlichkeiten von Validatoren auf mehrere [Knoten](/glossary/#node) verteilt. Dies wird als **verteilte Validierungstechnologie (distributed validator technology / DVT)** bezeichnet. [Staking-Pools](/glossary/#staking-pool) werden zur Verwendung von DVT angeregt, da dadurch mehrere Computer gemeinsam an der Validierung teilnehmen können, was zu mehr Redundanz und Fehlertoleranz führt. Außerdem werden die Validierungsschlüssel auf mehrere Systeme aufgeteilt, anstatt dass ein einzelner Operator mehrere Validatoren betreibt. Dies erschwert es unredlichen Betreibern, Angriffe auf Ethereum zu koordinieren. Insgesamt besteht die Idee darin, Sicherheitsvorteile zu erzielen, indem die Validatoren als _Gemeinschaften_ und nicht als Einzelpersonen betrieben werden.
+Dezentralisierung verhindert, dass Einzelpersonen oder kleine Gruppen von [Validatoren](/glossary/#validator) zu einflussreich werden. Neue Staking-Technologien können dazu beitragen, dass die Ethereum-Validatoren so dezentralisiert wie möglich bleiben und gleichzeitig vor Hardware-, Software- und Netzwerkausfällen geschützt sind. Dazu gehört Software, die die Zuständigkeiten von Validatoren auf mehrere [Nodes](/glossary/#node) verteilt. Dies ist als **verteilte Validatortechnologie (DVT)** bekannt. Für [Staking-Pools](/glossary/#staking-pool) besteht ein Anreiz, DVT zu verwenden, da es mehreren Computern ermöglicht, gemeinsam an der Validierung teilzunehmen, was zu zusätzlicher Redundanz und Fehlertoleranz führt. Außerdem werden die Validierungsschlüssel auf mehrere Systeme aufgeteilt, anstatt dass ein einzelner Operator mehrere Validatoren betreibt. Dies erschwert es unredlichen Betreibern, Angriffe auf Ethereum zu koordinieren. Insgesamt besteht die Idee darin, Sicherheitsvorteile zu erzielen, indem Validatoren als _Gemeinschaften_ und nicht als Einzelpersonen betrieben werden.
-Lesen Sie mehr über verteilte Validierungstechnologie
+Informationen zur verteilten Validatortechnologie
-Die Implementierung der **Proposer-Builder-Separation (PBS)** wird die in Ethereum eingebauten Schutzmechanismen gegen Zensur drastisch verbessern. PBS ermöglicht es einem Validator, einen Block zu erstellen, und einem anderen, ihn über das Ethereum-Netzwerk zu veröffentlichen. Dadurch wird sichergestellt, dass die Gewinne aus professionellen, gewinnmaximierenden Blockbildungsalgorithmen gerechter über das Netzwerk verteilt werden und **verhindern, dass sich der Gewinn im Laufe der Zeit bei den leistungsstärksten institutionellen Stakern konzentriert**. Der Blockanbieter kann den profitabelsten Block auswählen, der ihm von einem Markt von Blockbauern angeboten wird. Um zu zensieren, müsste ein Blockvorschläger oft einen weniger profitablen Block wählen, was **wirtschaftlich betrachtet unlogisch und auch für den Rest der Validierer** im Netz offensichtlich wäre.
+Die Implementierung der **Proposer-Builder Separation (PBS)** wird die in Ethereum integrierten Schutzmechanismen gegen Zensur drastisch verbessern. PBS ermöglicht es einem Validator, einen Block zu erstellen, und einem anderen, ihn über das Ethereum-Netzwerk zu veröffentlichen. Dies stellt sicher, dass die Gewinne aus professionellen, gewinnmaximierenden Algorithmen zur Blockerstellung gerechter im Netzwerk verteilt werden, **was die Konzentration von Stakes** bei den leistungsstärksten institutionellen Stakern im Laufe der Zeit **verhindert**. Der Blockanbieter kann den profitabelsten Block auswählen, der ihm von einem Markt von Blockbauern angeboten wird. Um zu zensieren, müsste ein Block-Proposer oft einen weniger profitablen Block wählen, was **wirtschaftlich irrational und für die übrigen Validatoren** im Netzwerk **offensichtlich wäre**.
Es gibt potenzielle Erweiterungen zu PBS, wie verschlüsselte Transaktionen und Inklusionslisten, die die Zensurresistenz von Ethereum weiter verbessern könnten. Diese machen den Blockersteller und den Vorschlagenden blind für die tatsächlichen Transaktionen, die in ihren Blöcken enthalten sind.
-Lesen Sie über die Trennung von Proposer und Builder
+Informationen zur Proposer-Builder Separation
## Schutz für Validatoren {#protecting-validators}
-Es ist möglich, dass ein raffinierter Angreifer bevorstehende Prüfer identifiziert und sie mit Spam attackiert, um sie daran zu hindern, Blöcke vorzuschlagen; dies ist als **Denial of Service (DoS)** Angriff bekannt. Die Implementierung von [**secret-leader-election (SLE)**](/roadmap/secret-leader-election) schützt vor dieser Art von Angriffen, indem verhindert wird, dass die Blockvorschläger im Voraus bekannt gegeben werden. Dabei wird eine Reihe von kryptografischen Zusagen, die Kandidaten für Blockvorschläge darstellen, ständig gemischt und deren Reihenfolge verwendet, um zu bestimmen, welcher Prüfer ausgewählt wird, und zwar so, dass nur die Prüfer selbst ihre Reihenfolge im Voraus erfahren.
+Es ist möglich, dass ein raffinierter Angreifer bevorstehende Validatoren identifiziert und sie mit Spam-Nachrichten angreift, um sie daran zu hindern, Blöcke vorzuschlagen. Dies wird als **Denial-of-Service-Angriff (DoS)** bezeichnet. Die Implementierung von [**Secret Leader Election (SLE)**](/roadmap/secret-leader-election) schützt vor dieser Art von Angriff, indem verhindert wird, dass Block-Proposer im Voraus bekannt sind. Dabei wird eine Reihe von kryptografischen Zusagen, die Kandidaten für Blockvorschläge darstellen, ständig gemischt und deren Reihenfolge verwendet, um zu bestimmen, welcher Prüfer ausgewählt wird, und zwar so, dass nur die Prüfer selbst ihre Reihenfolge im Voraus erfahren.
-Lesen Sie über die geheime Wahl des Leiters
+Informationen zur Secret Leader Election
## Aktueller Fortschritt {#current-progress}
-**Die auf der Roadmap aufgeführten Sicherheitsupgrades befinden sich in fortgeschrittenen Forschungsstadien**, sie werden aber voraussichtlich erst in einiger Zeit implementiert werden. Die nächsten Schritte für view-merge, PBS, SSF und SLE sind die Fertigstellung von Spezifikationen und der Beginn der Entwicklung von Prototypen.
+**Sicherheitsupgrades auf der Roadmap befinden sich in fortgeschrittenen Forschungsphasen**, aber ihre Implementierung wird voraussichtlich erst in einiger Zeit erfolgen. Die nächsten Schritte für View-Merge, PBS, SSF und SLE sind die Finalisierung einer Spezifikation und der Beginn der Entwicklung von Prototypen.
diff --git a/public/content/translations/de/roadmap/single-slot-finality/index.md b/public/content/translations/de/roadmap/single-slot-finality/index.md
index 6770e858d5c..833e15c5bad 100644
--- a/public/content/translations/de/roadmap/single-slot-finality/index.md
+++ b/public/content/translations/de/roadmap/single-slot-finality/index.md
@@ -1,12 +1,12 @@
---
-title: Einzelplatzfinalität (single slot finality)
-description: Erklärung von Einzelplatzfinalität (single slot finality)
+title: "Einzelplatzfinalität (single slot finality)"
+description: "Erklärung von Einzelplatzfinalität (single slot finality)"
lang: de
---
-# Einzelplatzfinalität (single slot finality) {#single-slot-finality}
+# Single-Slot-Finalität {#single-slot-finality}
-Es braucht ungefähr 15 Minuten einen Ethereum Block zu finalisieren. Jedoch können wir Ethereums Konsensmechanismus Blöcke effizienter validieren lassen und dadurch die Zeit, die für das Finalisieren benötigt wird, dramatisch verringern. Statt für 15 Minuten zu warten, könnten Blöcke im selben Platz (slot) vorgeschlagen und finalisiert werden. Dieses Konzept nennt sich **Einzelplatzfinalität (SSF)**.
+Es braucht ungefähr 15 Minuten einen Ethereum Block zu finalisieren. Jedoch können wir Ethereums Konsensmechanismus Blöcke effizienter validieren lassen und dadurch die Zeit, die für das Finalisieren benötigt wird, dramatisch verringern. Statt für 15 Minuten zu warten, könnten Blöcke im selben Platz (slot) vorgeschlagen und finalisiert werden. Dieses Konzept ist als **Single-Slot-Finalität (SSF)** bekannt.
## Was ist Endgültigkeit? {#what-is-finality}
@@ -16,9 +16,9 @@ In Ethereums auf Proof-of-Stake basierenden Konsensmechanismus bezieht sich die
Die derzeitige Zeit zur Endlichkeit hat sich als zu lang herausgestellt. Die meisten Nutzer wollen nicht 15 Minuten auf Endlichkeit warten, und es ist für Anwendungen und Austausche, welche einen hohen Transaktionsdurchsatz wollen ungünstig so lange zu warten, um sicher zu sein, dass ihre Transaktionen permanent sind. Eine Verzögerung zwischen dem Vorschlagen eines Blocks und dessen Finalisierung zu haben ermöglicht auch kurze Neuorganisationen, welche ein Angreifer nutzen könnte einzelne Blöcke zu zensieren oder MEV zu extrahieren. Der Mechanismus, der das stufenweise Verbessern von Blöcken regelt, ist ebenfalls recht komplex und wurde mehrfach gepatcht, um Sicherheitslücken zu schließen, was ihn zu einem der Teile der Ethereum-Codebasis macht, in dem subtile Fehler wahrscheinlicher sind. Diese Probleme könnten alle eliminiert werden, wäre die Zeit, die für das finalisieren eines einzigen Platzes gebraucht wird, geringer.
-## Der Kompromiss von Dezentralisation / Zeit / Overhead {#the-decentralization-time-overhead-tradeoff}
+## Der Kompromiss zwischen Dezentralisierung / Zeit / Overhead {#the-decentralization-time-overhead-tradeoff}
-Die Endlichkeitsgarantie ist keine direkte Eigenschaft eines neuen Blocks; es braucht Zeit, einen neuen Block zu finalisieren. Der Grund dafür ist, dass Validatoren, die mindestens 2/3 der gesamten staked ETH auf dem Netzwerk für den Block abstimmen müssen ("Bestätigung"), dafür dass er als endlich gesehen werden kann. Jeder validierende Node auf dem Netzwerk muss Attestierungen anderer Nodes verarbeiten, um zu wissen, ob ein Block diese 2/3 Voraussetzung erreicht hat.
+Die Endlichkeitsgarantie ist keine direkte Eigenschaft eines neuen Blocks; es braucht Zeit, einen neuen Block zu finalisieren. Der Grund dafür ist, dass Validatoren, die mindestens 2/3 der gesamten gestaketen ETH im Netzwerk repräsentieren, für den Block stimmen müssen („bestätigen“), damit dieser als finalisiert gilt. Jeder validierende Node auf dem Netzwerk muss Attestierungen anderer Nodes verarbeiten, um zu wissen, ob ein Block diese 2/3 Voraussetzung erreicht hat.
Je kürzer die Zeit zur Endlichkeit ist, desto mehr Rechenleistung wird an jedem einzelnen Node benötigt, da die Attestierung schneller verarbeitet werden muss. Außerdem müssen mit mehr validierenden Nodes auch mehr Attestierungen für jeden Block verarbeitet, was auch die benötigte Gesamtrechenleistung erhöht. Je mehr Rechenleistung benötigt wird, desto weniger Menschen können sich ins Ethereum Netzwerk einbringen, da teurere Hardware benötigt wird, um jeden validierenden Node zu betreiben. Die Zeit zwischen Blöcken zu erhöhen, verringert die an jedem Node benötigte Rechenleistung, erhöht jedoch auch die Zeit zu Endlichkeit, da mehr Attestierungen langsam verarbeitet werden.
@@ -33,34 +33,34 @@ Mit dem derzeitigen Aufbau des Mechanismus müssen, um die Zeit zur Endlichkeit
## Wege zu SSF {#routes-to-ssf}
-
+
Der derzeitige Konsensmechanismus verbindet Attestierungen mehrerer Validatoren, welche Komitees genannt werden, um die Anzahl an Nachrichten, die jeder Validator in einem Block verarbeiten muss, um jenen zu validieren, zu verringern. Jeder Validator hat in jeder Epoche (32 Plätze) die Möglichkeit zur Attestierung. In jedem Platz haben jedoch nur eine Untergruppe von Validatoren, bekannt als Komitee-Attestierung diese Möglichkeit. Das machen sie, indem sie in Unternetzwerke unterteilt werden, in denen wenige Validatoren als "Aggregatoren" ausgewählt werden. Diese Aggregatoren verbinden alle die Unterschriften, welche sie von anderen Validatoren bekommen in, in ihrem Netzwerk zu einer einzelnen aggregierten Unterschrift. Der Aggregator, welcher die größte Anzahl an einzelnen Teilnahmen beinhaltet, gibt dann die aggregierte Unterschrift an den Blockantragsteller (Block Proposer) weiter, welcher sie dann in seinem Block mit den aggregierten Unterschriften anderer Komitees einschließt.
-Dieser Prozess gibt für jeden Validatoren ausreichende Kapazität, in jeder Epoche abzustimmen, da 32 Plätze * 64 Komitees * 256 Validator pro Komitee 524 288 Validatoren pro Epoche ergeben. Zum Zeitpunkt der Erstellung dieses Artikels (Februar 2023) gibt es ~513 000 aktive Validatoren.
+Dieser Prozess gibt für jeden Validatoren ausreichende Kapazität, in jeder Epoche abzustimmen, da 32 Plätze \* 64 Komitees \* 256 Validator pro Komitee 524 288 Validatoren pro Epoche ergeben. Zum Zeitpunkt der Erstellung dieses Artikels (Februar 2023) gibt es ~513 000 aktive Validatoren.
In diesem Schema ist es für jeden Validatoren möglich für einen Block abzustimmen, indem er seine Attestierungen über die gesamte Epoche verteilen. Jedoch gibt es potentielle Wege diesen Mechanismus zu verbessern, sodass _jeder Validator die Chance hat in jedem Platz zu attestieren_.
Seit der Ethereum Konsensmechanismus entwickelt wurde, hat sich das Unterschriften-Aggregationsschema (BLS) als deutlich skalierbarer als erwartet erwiesen, dabei wurde auch die Fähigkeit von Clients, die Unterschriften zu verarbeiten und unterschreiben, verbessert. Es stellt sich heraus, dass das Verarbeiten von Attestierungen in großer Anzahl von Validatoren in einem einzelnen Platz möglich ist. Zum Beispiel müssten Nodes, bei einer Million Validatoren, die zweimal pro Platz wählen und dem Verändern von der Zeit pro Slot (Platz) auf 16 Sekunden, Unterschriften mit mindestens 125 000 Aggregationen pro Sekunde funktionieren, um alle Attestierungen innerhalb des Platzes zu verarbeiten. In Wirklichkeit benötigt ein gewöhnlicher Computer ungefähr 500 Nanosekunden um eine Unterschrift zu verifizieren, das heißt, dass 125 000 Verifikationen in ~62,5 ms durchgeführt werden könnten. Das wäre weit unter der Ein-Sekunden-Grenze.
-Weitere Effizienzgewinne könnten durch die Erstellung von Superkomitees von beispielsweise 125 000 zufällig gewählten Validatoren pro Platz erreicht werden. Nur diese Validatoren könnten für einen Block abstimmen und dadurch könnte nur eine Untermenge an Validatoren entscheiden, ob ein Block endlich ist. Ob das eine gute Idee ist, kommt darauf an, wie teuer ein Angriff auf Ethereum nach der Community sein sollte. Das liegt daran, dass Angreifer einen unehrlichen Block statt mit 2/3 der gesamten staked Ether mit 2/3 der staked Ether _in diesem Superkomitee_ finalisieren könnten. Dies ist immer noch ein aktives Forschungsgebiet, jedoch scheint es plausibel, dass für eine Validatorenmenge, die groß genug wäre um Superkomitees zu brauchen, würden die Kosten für das Angreifen eines dieser Superkomitees extrem hoch sein (Zum Beispiel beträgen die ETH genannten Kosten eines Angriffs `2/3 * 125 000 * 32 = ~2,6 Millionen ETH`). Die Kosten eines Angriffs können angepasst werden, indem die Größe einer einzelnen Validatorenmenge (z.B. das Anpassen der Validatorengröße, sodass der Angriff 1 Million Ether, 4 Millionen Ether, 10 Millionen Ether, etc. kosten würde). [Vorläufige Abstimmungen](https://youtu.be/ojBgyFl6-v4?t=755) der Community legen nahe, dass 1-2 Millionen Ether akzeptable Angriffskosten darstellen würden, das bedeutet, man bräuchte ~65 636 - ~97 152 Validatoren pro Superkomitee.
+Weitere Effizienzgewinne könnten durch die Einrichtung von Supercommittees aus z. B. 125.000 zufällig ausgewählten Validatoren pro Slot erzielt werden. Nur diese Validatoren könnten für einen Block abstimmen und dadurch könnte nur eine Untermenge an Validatoren entscheiden, ob ein Block endlich ist. Ob das eine gute Idee ist, kommt darauf an, wie teuer ein Angriff auf Ethereum nach der Community sein sollte. Das liegt daran, dass ein Angreifer anstelle von 2/3 des gesamten gestaketen Ethers einen unehrlichen Block mit 2/3 des gestaketen Ethers _in diesem Supercommittee_ finalisieren könnte. Dies ist nach wie vor ein aktives Forschungsgebiet, aber es scheint plausibel, dass bei einem Validator-Set, das groß genug ist, um überhaupt Supercommittees zu benötigen, die Kosten für einen Angriff auf eines dieser Subcommittees extrem hoch sein werden (z. B. würden die auf ETH lautenden Angriffskosten `2/3 * 125.000 * 32 = ~2,6 Millionen ETH` betragen). Die Angriffskosten können durch eine Erhöhung der Größe des Validator-Sets angepasst werden (z. B. durch Anpassen der Validator-Größe, sodass die Angriffskosten 1 Million Ether, 4 Millionen Ether, 10 Millionen Ether usw. betragen). [Vorläufige Umfragen](https://youtu.be/ojBgyFl6-v4?t=755) in der Community deuten darauf hin, dass 1–2 Millionen Ether akzeptable Angriffskosten sind, was ~65.536–97.152 Validatoren pro Supercommittee impliziert.
-Jedoch ist die Verifikation noch nicht das wahre Problem, die Aggregation von Unterschriften ist was Validatoren Nodes wirklich herausfordert. Um die Aggregation der Unterschriften zu skalieren, muss man wahrscheinlich die Validatorenmenge jedes Unternetzwerks oder die Anzahl an Unternetzwerke erhöhen oder zusätzliche Ebenen der Aggregation hinzufügen (d.h. Komitees von Komitees zu implementieren). Ein Teil der Lösung könnte das Erlauben von spezialisierten Aggregatoren sein - ähnlich dazu wie das Blockerzeugen und das Generieren von Verpflichtungen für Rollup Daten zu spezialisierten Blockerzeugern unter Proposer-Builder Separation (PBS) und Danksharding ausgelagert wird.
+Jedoch ist die Verifikation noch nicht das wahre Problem, die Aggregation von Unterschriften ist was Validatoren Nodes wirklich herausfordert. Um die Signaturaggregation zu skalieren, muss wahrscheinlich die Anzahl der Validatoren in jedem Subnetz erhöht, die Anzahl der Subnetze erhöht oder zusätzliche Aggregationsebenen hinzugefügt werden (d. h. es werden Komitees von Komitees implementiert). Ein Teil der Lösung könnte das Erlauben von spezialisierten Aggregatoren sein - ähnlich dazu wie das Blockerzeugen und das Generieren von Verpflichtungen für Rollup Daten zu spezialisierten Blockerzeugern unter Proposer-Builder Separation (PBS) und Danksharding ausgelagert wird.
-## Was ist die Rolle der Abspaltungsregel (fork-choice rule) innerhalb SSF? {#role-of-the-fork-choice-rule}
+## Was ist die Rolle der Abspaltungsregel (fork-choice rule) innerhalb SSF? Rolle der Fork-Choice-Regel {#role-of-the-fork-choice-rule}
-Der heutige Konsensmechanismus beruht auf engen Verbindungen zwischen dem Finality Gadget (Algorithmus, welcher bestimmt ob 2/3 der Validatoren eine bestimmte Kette attestiert haben) und der Abspaltungsregel (Algorithmus, der bestimmt welche Kette die richtige ist, sollte es mehrere geben). Der Abspaltungsalgorithmus (fork choice algorithm) betrachtet nur Blöcke _seit_ dem letzten finalisierten Block. Unter SSF gäbe es keine Blöcke, welche die Abspaltungsregel erwähnen müsste, da die Endgültigkeit im selben Slot, in der der Block vorgeschlagen wurde, aufkommt. Das bedeutet, dass unter SSF _entweder_ der Abspaltungsalgorithmus _oder_ das Finality Gadget zu jeder Zeit aktiv sein müssten. Das Finality Gadget würde Blöcke, bei denen 2/3 der Validatoren online sind und ehrlich attestieren finalisieren. Wenn ein Block die 2/3 Grenze nicht überschreiten könnte, würde die Abspaltungsregel bestimmen welcher Kette zu folgen ist. Das erzeugt auch eine Möglichkeit den Inaktivität-Leck-Mechanismus, welcher eine Kette wiederherstellt, bei der >1/3 der Validatoren offline gegangen sind, wenn auch mit einigen zusätzlichen Nuancen.
+Der heutige Konsensmechanismus beruht auf engen Verbindungen zwischen dem Finality Gadget (Algorithmus, welcher bestimmt ob 2/3 der Validatoren eine bestimmte Kette attestiert haben) und der Abspaltungsregel (Algorithmus, der bestimmt welche Kette die richtige ist, sollte es mehrere geben). Der Fork-Choice-Algorithmus berücksichtigt nur Blöcke _seit_ dem letzten finalisierten Block. Unter SSF gäbe es keine Blöcke, welche die Abspaltungsregel erwähnen müsste, da die Endgültigkeit im selben Slot, in der der Block vorgeschlagen wurde, aufkommt. Das bedeutet, dass unter SSF _entweder_ der Fork-Choice-Algorithmus _oder_ das Finality-Gadget jederzeit aktiv wäre. Das Finality Gadget würde Blöcke, bei denen 2/3 der Validatoren online sind und ehrlich attestieren finalisieren. Wenn ein Block die 2/3 Grenze nicht überschreiten könnte, würde die Abspaltungsregel bestimmen welcher Kette zu folgen ist. Dies schafft auch die Möglichkeit, den Mechanismus des Inaktivitäts-Lecks beizubehalten, der eine Kette wiederherstellt, bei der >1/3 der Validatoren offline gehen, wenn auch mit einigen zusätzlichen Nuancen.
-## Offenstehende Probleme {#outstanding-issues}
+## Offene Fragen {#outstanding-issues}
-Das Problem mit dem Skalieren von Aggregationen mit einer Erhöhung der Validatorenmenge pro Unternetz ist, dass es zu einer größeren Last auf dem Peer-to-Peer Netzwerk führt. Das Problem damit, Ebenen der Aggregation hinzuzufügen, ist, dass es sehr komplex aufzubauen ist und Verzögerungen mit sich bringt (d.h. es könnte für einen Block Proposer länger dauern von allen Unternetz-Aggregatoren zu hören). Es ist auch nicht klar, wie man mit dem Szenario umgeht, dass mehr aktive Validatoren auf dem Netzwerk sind, als in jedem Platz verarbeitbar sind, sogar mit der BLS Unterschriftenaggregation. Eine mögliche Lösung ist das, da alle Validatoren in jedem Platz attestieren müssen und es keine Komitees unter SSF gibt. Das 32 ETH Limit zum effektiven Guthaben könnte komplett entfernt werden, was bedeutet, dass Operatoren, welche mehrere Validatoren verwalten ihren Staking Einsatz konsolidieren und weniger laufen könnten. Das würde die Anzahl der Nachrichten, welche validierende Nodes verarbeiten müssen, um alle Validatoren zu berücksichtigen reduzieren. Das beruht auf große Staker, welche zustimmen ihre Validatoren zu konsolidieren. Es ist auch möglich eine Obergrenze für die Anzahl an Validatoren oder der Anzahl von staked ETH zu jeder Zeit festzulegen. Jedoch erfordert dies irgendeinen Mechanismus, um zu entscheiden, welche Validatoren erlaubt sind teilzunehmen und welche nicht, was verantwortlich für das Erzeugen ungewollter Nebeneffekte ist.
+Das Problem mit dem Skalieren von Aggregationen mit einer Erhöhung der Validatorenmenge pro Unternetz ist, dass es zu einer größeren Last auf dem Peer-to-Peer Netzwerk führt. Das Problem beim Hinzufügen von Aggregationsebenen ist, dass die Entwicklung sehr komplex ist und Latenz hinzufügt (d. h., es könnte länger dauern, bis der Block-Vorschlagende von allen Subnetz-Aggregatoren eine Rückmeldung erhält). Es ist auch nicht klar, wie man mit dem Szenario umgeht, dass mehr aktive Validatoren auf dem Netzwerk sind, als in jedem Platz verarbeitbar sind, sogar mit der BLS Unterschriftenaggregation. Eine mögliche Lösung ist das, da alle Validatoren in jedem Platz attestieren müssen und es keine Komitees unter SSF gibt. Das 32 ETH Limit zum effektiven Guthaben könnte komplett entfernt werden, was bedeutet, dass Operatoren, welche mehrere Validatoren verwalten ihren Staking Einsatz konsolidieren und weniger laufen könnten. Das würde die Anzahl der Nachrichten, welche validierende Nodes verarbeiten müssen, um alle Validatoren zu berücksichtigen reduzieren. Das beruht auf große Staker, welche zustimmen ihre Validatoren zu konsolidieren. Es ist auch möglich eine Obergrenze für die Anzahl an Validatoren oder der Anzahl von staked ETH zu jeder Zeit festzulegen. Jedoch erfordert dies irgendeinen Mechanismus, um zu entscheiden, welche Validatoren erlaubt sind teilzunehmen und welche nicht, was verantwortlich für das Erzeugen ungewollter Nebeneffekte ist.
## Aktueller Fortschritt {#current-progress}
-SSF ist in der Forschungsphase. Es ist davon auszugehen, dass ihre Veröffentlichung noch einige Jahre auf sich warten lässt. Wahrscheinlich wird es erst nach anderen wesentlichen Upgrades wie [Verkle Trees](/roadmap/verkle-trees/) und [Danksharding](/roadmap/danksharding/) dazu kommen.
+SSF ist in der Forschungsphase. Es wird nicht erwartet, dass es vor einigen Jahren ausgeliefert wird, wahrscheinlich nach anderen wesentlichen Upgrades wie [Verkle-Trees](/roadmap/verkle-trees/) und [Danksharding](/roadmap/danksharding/).
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Vitalik zu SSF auf der EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI)
-- [Vitaliks Notizen: Wege zur Einzelplatzfinalität (SSF)](https://notes.ethereum.org/@vbuterin/single_slot_finality)
+- [Vitalik über SSF bei der EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI)
+- [Vitaliks Notizen: Wege zur Single-Slot-Finalität](https://notes.ethereum.org/@vbuterin/single_slot_finality)
diff --git a/public/content/translations/de/roadmap/statelessness/index.md b/public/content/translations/de/roadmap/statelessness/index.md
index f6b7e6711a2..72b96654c0c 100644
--- a/public/content/translations/de/roadmap/statelessness/index.md
+++ b/public/content/translations/de/roadmap/statelessness/index.md
@@ -1,10 +1,10 @@
---
title: Zustandslosigkeit, Zustandsverfall und Verfall des Vergangenen (history expiry)
-description: Erklärung vom Verfall des Vergangenen (history expiry) und der Zustandslosigkeit auf Ethereum
+description: "Erklärung vom Verfall des Vergangenen (history expiry) und der Zustandslosigkeit auf Ethereum"
lang: de
---
-# Zustandslosigkeit, Zustandsverfall und Verfall des Vergangenen (history expiry) {#statelessness}
+# Zustandslosigkeit, Zustandsablauf und Historienablauf {#statelessness}
Die Möglichkeit Ethereum Nodes auf einfacher Hardware betreiben zu können ist für wahre Dezentralisation entscheidend. Das liegt daran, dass das Betreiben eines Nodes Nutzern die Möglichkeit gibt Informationen verifizieren zu können, indem sie kryptografische Überprüfungen unabhängig ausführen können, statt von den Daten eines Dritten abhängig zu sein. Einen Node zu betreiben erlaubt Nutzern Transaktionen direkt zum Ethereum Peer-to-Peer Netzwerk einzuschicken, statt einem Vermittler vertrauen zu müssen. Dezentralisation ist nicht möglich, wenn diese Vorteile nur Nutzern mit teurer Hardware zur Verfügung stehen. Stattdessen sollten Nodes in der Lage sein, mit extrem einfachen Rechen- und Speichervoraussetzungen betrieben zu werden. Dadurch könnten sie auf Handys, Mikrocomputern oder unbemerkt auf einem Standrechner laufen.
@@ -12,18 +12,18 @@ Heute ist der hohe Speicherplatzbedarf das, was den Zugriff auf Nodes für alle
Günstigere Festplatten können für das Speichern alter Daten verwendet werden, sie sind jedoch zu langsam, um mit eingehenden Blöcken mithalten zu können. Die Beibehaltung der aktuellen Speichermodelle für Clients, bei gleichzeitiger Verbilligung und Vereinfachung der Datenspeicherung ist nur eine vorübergehende und partielle Lösung des Problems, da das Zustandswachstum von Ethereum "unbegrenzt" ist, was bedeutet, dass die Speicheranforderungen immer weiter steigen werden und die technologischen Verbesserungen immer mit dem kontinuierlichen Zustandswachstum Schritt halten müssen. Stattdessen müssen Klienten einen neuen Weg finden, Blöcke und Transaktionen zu verifizieren, während keine Daten von lokalen Datenbanken gespeichert werden müssen.
-## Speicherreduzierung für Nodes {#reducing-storage-for-nodes}
+## Reduzierung des Speichers für Nodes {#reducing-storage-for-nodes}
Es gibt verschiedene Wege, um die Datenmengen, die jeder Knoten speichern muss, zu reduzieren. Für jede dieser Möglichkeiten muss Ethereums Kernprotokoll in unterschiedlichem Umfang aktualisiert werden:
-- **Verfall des Vergangenen (history expiry)**: Dies ermöglicht Nodes Zustandsdaten, welche älter als X Blöcke sind, wegzuschmeißen, jedoch verändert es nicht, wie Ethereums Client mit Zustandsdaten umgeht
-- **Zustandsverfall** Dies erlaubt Daten, welche selten verwendet werden, inaktiv zu werden. Inaktive Daten können von Clients ignoriert werden, bis sie wiederbelebt werden.
-- **Schwache Zustandslosigkeit**: Hier müssen nur Blockproduzenten Zugriff auf die vollständigen Zustandsdaten haben, andere Nodes können Blöcke ohne eine lokale Zustandsdatenbank verifizieren.
-- **Starke Zustandslosigkeit**: Hier können keine Nodes auf die vollständigen Zustandsdaten zugreifen.
+- **Historienablauf**: Ermöglicht Nodes, Zustandsdaten zu verwerfen, die älter als X Blöcke sind, ändert aber nichts daran, wie Ethereum-Clients mit Zustandsdaten umgehen.
+- **Zustandsablauf**: Ermöglicht, dass Zustandsdaten, die nicht häufig verwendet werden, inaktiv werden. Inaktive Daten können von Clients ignoriert werden, bis sie wiederbelebt werden.
+- **Schwache Zustandslosigkeit**: Nur Block-Produzenten benötigen Zugriff auf die vollständigen Zustandsdaten, andere Nodes können Blöcke ohne eine lokale Zustandsdatenbank verifizieren.
+- **Starke Zustandslosigkeit**: Keine Nodes benötigen Zugriff auf die vollständigen Zustandsdaten.
-## Datenverfall {#data-expiry}
+## Datenablauf {#data-expiry}
-### Verfall des Vergangenen (history expiry) {#history-expiry}
+### Historienablauf {#history-expiry}
Dass das Vergangene verfällt, bedeutet im Einfachen, dass Clients ältere Daten, die sie unwahrscheinlich brauchen werden, abschneiden. Dadurch müssen sie nur noch kleine Mengen der vergangenen Daten behalten und können alte Daten wegschmeißen, sobald neue hinzugefügt werden. Es gibt zwei Gründe dafür, dass Clients veraltete Daten brauchen könnten: dem Synchronisieren und Bedienen von Datenanfragen. Früher mussten Clients vom jeden Block Genesis bis zum Kopf der Kette synchronisieren und dabei alle nach Richtigkeit überprüfen. Heute nutzen Clients "schwache subjektive Kontrollpunkte" um ihren Weg an die Spitze der Blockchain zu bootstrappen. Diese Kontrollpunkte sind vertraute Startpunkte, als würde man den Genesis Block näher die Gegenwart statt dem Startpunkt von Ethereum legen. Das bedeutet, dass Clients alle Informationen vor ihrem letzten schwachen subjektiven Kontrollpunkt löschen können, ohne dabei die Fähigkeit zu verlieren, den Kopf der Kette zu synchronisieren. Clients liefern zurzeit Anfragen (die über JSON-RPC ankommen) für vergangene Daten, indem sie sie von ihren lokalen Datenbanken nehmen. Jedoch wird das mit dem Verfall des Vergangenen nicht möglich sein, wenn die angefragten Daten abgeschnitten wurden. Um diese vergangenen Daten zu liefern, bedarf es innovativer Lösungen.
@@ -35,16 +35,16 @@ EIP-4444 ist bis jetzt nicht bereit, aber unter aktiver Diskussion. Interessante
Dieses Upgrade ändert nicht die fundamentale Art der Ethereum Nodes, Zustandsdaten zu speichern, sondern nur die Art auf vergangene Daten zuzugreifen.
-### Zustandsverfall {#state-expiry}
+### Zustandsablauf {#state-expiry}
Zustandsverfall bezieht sich auf das Entfernen der Zustände von individuellen Nodes, wenn sie nicht vor kurzer Zeit aufgerufen wurden. Es gibt mehrere Wege, wie das implementiert werden könnte, dazu gehören:
-- **Verfall nach Leihe**: Das bedeutet, dass von Accounts "Leihgebühren" verlangt und sie verfallen lässt sollten sie Null erreichen
-- **Verfall nach Zeit**: Account inaktiv machen, wenn auf ihnen seit einer bestimmten Zeit kein Lesen/Schreiben mehr stattfindet
+- **Ablauf durch Miete**: Erhebung einer "Miete" von Konten und deren Ablauf, wenn die Miete Null erreicht
+- **Ablauf nach Zeit**: Konten werden inaktiv, wenn für einen bestimmten Zeitraum keine Lese- oder Schreibvorgänge auf dieses Konto stattfinden.
-Der Verfall nach Leihe könnte eine direkt eingezogene Leihgebühr sein, welche die Accounts in der Datenbank der aktiven Zustände behält. Der Verfall nach Zeit könnte ein Countdown seit der letzten Account-Interaktion, oder ein periodischer Verfall aller Accounts sein. Es könnte auch Mechanismen geben, welche beide Elemente der Zeit- und Leihbasierenden Modelle miteinander verbindet. Zum Beispiel könnten individuelle Accounts im aktiven Zustand verbleiben, wenn sie einen kleinen Betrag vor dem Datum ihres Verfalls zahlen. Mit dem Zustandsverfall ist es wichtig zu beachten, dass inaktive Zustände **nicht gelöscht**, sondern einfach separat vom aktiven Zustand gespeichert werden. Der inaktive Zustand kann einfach wieder in den aktiven Zustand gebracht werden.
+Der Verfall nach Leihe könnte eine direkt eingezogene Leihgebühr sein, welche die Accounts in der Datenbank der aktiven Zustände behält. Der Verfall nach Zeit könnte ein Countdown seit der letzten Account-Interaktion, oder ein periodischer Verfall aller Accounts sein. Es könnte auch Mechanismen geben, welche beide Elemente der Zeit- und Leihbasierenden Modelle miteinander verbindet. Zum Beispiel könnten individuelle Accounts im aktiven Zustand verbleiben, wenn sie einen kleinen Betrag vor dem Datum ihres Verfalls zahlen. Beim Zustandsablauf ist es wichtig zu beachten, dass der inaktive Zustand **nicht gelöscht** wird, sondern nur getrennt vom aktiven Zustand gespeichert wird. Der inaktive Zustand kann einfach wieder in den aktiven Zustand gebracht werden.
-Das würde wahrscheinlich durch Zustandsbäume für verschiedene Zeiträume (vielleicht ~1 Jahr) funktionieren. Wenn ein neuer Zeitraum beginnt, beginnt auch ein neuer Zustandsbaum. Nur der derzeitige Zustandsbaum kann modifiziert werden, alle anderen sind unveränderlich. Von Ethereum Nodes wird erwartet, den derzeitigen und letzten Zustandsbaum zu halten. Die erfordert eine Möglichkeit einer Adresse einen Zeitstempel mit der zugehörigen Periode zu geben. Es gibt [mehrere Möglichkeiten](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) dies zu machen, die führende Option erfordert jedoch [das Verlängern von Adressen](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), um die zusätzlichen Informationen unterzubringen. Das hätte den zusätzlichen Vorteil, dass längere Adressen sicherer wären. Das Roadmap-Eintrag, welcher dies macht, nennt sich [Ethereum Raumerweiterung](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485).
+Das würde wahrscheinlich durch Zustandsbäume für verschiedene Zeiträume (vielleicht ~1 Jahr) funktionieren. Wenn ein neuer Zeitraum beginnt, beginnt auch ein neuer Zustandsbaum. Nur der derzeitige Zustandsbaum kann modifiziert werden, alle anderen sind unveränderlich. Von Ethereum Nodes wird erwartet, den derzeitigen und letzten Zustandsbaum zu halten. Die erfordert eine Möglichkeit einer Adresse einen Zeitstempel mit der zugehörigen Periode zu geben. Es gibt [mehrere mögliche Wege](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607), dies zu tun, aber die führende Option erfordert eine [Verlängerung der Adressen](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), um die zusätzlichen Informationen unterzubringen, mit dem zusätzlichen Vorteil, dass längere Adressen viel sicherer sind. Der Fahrplanpunkt, der dies umsetzt, wird als [Erweiterung des Adressraums](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) bezeichnet.
Ähnlich zum Verfallen des Vergangenen würde die Verantwortung für das Speichern alter Daten für individuelle Nutzer wegfallen und auf andere Entitäten wie zentralisierten Anbieter, selbstlosen Mitgliedern der Community oder futuristischeren dezentralen Lösungsansätzen wie dem Portal Netzwerk verteilt.
@@ -56,7 +56,7 @@ Zustandslosigkeit ist fast eine falsche Bezeichnung, da nicht das Konzept des Zu
- Beinahe direkte Synchronisation
- Die Fähigkeit Blöcke ohne Reihenfolge zu validieren
-- Das Betreiben von Nodes mit sehr geringen Hardware Voraussetzung (z.B. Handys)
+- Nodes, die mit sehr geringen Hardwareanforderungen (z. B. auf Handys) laufen können
- Das Betreiben von Nodes auf günstigen Festplatten, da kein schreiben/lesen auf dem Speicher nötig ist
- Kompatibilität mit zukünftigen Verbesserungen der Kryptographie Ethereums
@@ -66,9 +66,9 @@ Schwache Zustandslosigkeit beinhaltet Änderungen dazu, wie Ethereum Nodes Zusta
**Bei der schwachen Zustandslosigkeit brauchen Blöcke Zugriff auf die vollen Zustandsdaten, jedoch benötigt das Verifizieren von Blöcken keine Zustandsdaten**
-Damit dies passieren kann, müssen [Verkle Trees](/roadmap/verkle-trees/) bereits in Ethereum Clients implementiert sein. Verkle-Bäume sind eine Datenersetzungsstruktur um Ethereums Zustandsdaten zu speichern. Sie erlauben kleine "Zeugen" fester Größe, die dazu da sind Daten zwischen Peers zu vermitteln und Blöcke direkt, anstatt gegen lokale Datenbanken zu verifizieren. [Proposer-Builder Separation](/roadmap/pbs/) wird zudem benötigt, da es Blockerzeugern erlaubt spezialisierte Nodes mit leistungsfähigerer Hardware zu sein und da sie es sind, die Zugriff auf die vollen Zustandsdaten brauchen.
+Damit dies geschehen kann, müssen [Verkle-Trees](/roadmap/verkle-trees/) bereits in Ethereum-Clients implementiert worden sein. Verkle-Bäume sind eine Datenersetzungsstruktur um Ethereums Zustandsdaten zu speichern. Sie erlauben kleine "Zeugen" fester Größe, die dazu da sind Daten zwischen Peers zu vermitteln und Blöcke direkt, anstatt gegen lokale Datenbanken zu verifizieren. [Proposer-Builder Separation](/roadmap/pbs/) ist ebenfalls erforderlich, da dies Block-Buildern ermöglicht, spezialisierte Nodes mit leistungsstärkerer Hardware zu sein, und genau diese benötigen Zugriff auf die vollständigen Zustandsdaten.
-
+
Zustandslosigkeit stützt sich auf Blockerzeuger, welche eine Kopie der vollen Zustandsdaten pflegen, sodass sie Zeugen generieren können, welche genutzt werden um Blöcke zu verifizieren. Andere Nodes müssen die Zustandsdaten nicht abrufen, da alle benötigten Informationen für das Verifizieren eines Blocks im Zeugen vorhanden sind. Das erzeugt eine Situation, in der das Vorschlagen eines Blocks teuer, das Verifizieren jedoch günstig ist, was bedeutet, das weniger Operatoren einen blockvorschlagenden Node betreiben werden. Jedoch ist die Dezentralisation von Block Proposern nicht kritisch, solange möglichst viele Teilnehmende unabhängig voneinander verifizieren können, dass der vorgeschlagene Block valide ist.
@@ -87,17 +87,19 @@ Starke Zustandslosigkeit wurde von Forschern untersucht, wird aber wahrscheinlic
## Aktueller Fortschritt {#current-progress}
-Schwache Zustandslosigkeit, Verfall des Vergangenen und Zustandsverfall sind alle in der Forschungsphase und können voraussichtlich in einigen Jahren ausgesendet werden. Es gibt keine Garantie dafür, dass all diese Vorschläge implementiert werden, zum Beispiel wird es eventuell nicht nötig sein den Verfall des Vergangenen nach dem Zustandsverfall zu implementieren. Es gibt auch andere Punkte der Roadmap, so wie [Verkle Bäume](/roadmap/verkle-trees) und [Proposer-Builder Separation](/roadmap/pbs), welche zuerst fertiggestellt werden müssen.
+Schwache Zustandslosigkeit, Verfall des Vergangenen und Zustandsverfall sind alle in der Forschungsphase und können voraussichtlich in einigen Jahren ausgesendet werden. Es gibt keine Garantie dafür, dass all diese Vorschläge implementiert werden, zum Beispiel wird es eventuell nicht nötig sein den Verfall des Vergangenen nach dem Zustandsverfall zu implementieren. Es gibt auch andere Fahrplanpunkte, wie [Verkle-Trees](/roadmap/verkle-trees) und die [Proposer-Builder Separation](/roadmap/pbs), die zuerst abgeschlossen werden müssen.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Vitalik Zustandslosigkeit AMA](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/)
-- [Eine Theorie der Zustandsgrößenverwaltung](https://hackmd.io/@vbuterin/state_size_management)
-- [Die Konflikt-minimierte Zustandsbünde wiederherstellen](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739)
-- [Wege zur Zustandslosigkeit und zum Zustandsverfall](https://hackmd.io/@vbuterin/state_expiry_paths)
+- [Was ist zustandsloses Ethereum?](https://stateless.fyi/)
+- [Vitaliks AMA zur Zustandslosigkeit](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/)
+- [Eine Theorie zur Verwaltung der Zustandsgröße](https://hackmd.io/@vbuterin/state_size_management)
+- [Resurrection-conflict-minimized state bounding](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739)
+- [Wege zur Zustandslosigkeit und zum Zustandsablauf](https://hackmd.io/@vbuterin/state_expiry_paths)
- [EIP-4444 Spezifikation](https://eips.ethereum.org/EIPS/eip-4444)
-- [Alex Stokes zu EIP-4444](https://youtu.be/SfDC_qUZaos)
-- [Warum es so wichtig ist zustandslos zu werden](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html)
-- [Die originalen zustandsloser Client Konzeptnotizen](https://ethresear.ch/t/the-stateless-client-concept/172)
-- [Mehr zum Zustandsverfall](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry)
-- [Noch mehr zum Zustandsverfall](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry)
+- [Alex Stokes über EIP-4444](https://youtu.be/SfDC_qUZaos)
+- [Warum es so wichtig ist, zustandslos zu werden](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html)
+- [Die ursprünglichen Konzeptnotizen zum zustandslosen Client](https://ethresear.ch/t/the-stateless-client-concept/172)
+- [Mehr zum Zustandsablauf](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry)
+- [Noch mehr zum Zustandsablauf](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry)
+- [Informationsseite zu zustandslosem Ethereum](https://stateless.fyi)
diff --git a/public/content/translations/de/roadmap/user-experience/index.md b/public/content/translations/de/roadmap/user-experience/index.md
index 760342bd6cb..54bc14a5972 100644
--- a/public/content/translations/de/roadmap/user-experience/index.md
+++ b/public/content/translations/de/roadmap/user-experience/index.md
@@ -1,36 +1,36 @@
---
title: Verbesserung der Benutzererfahrung
-description: Für die meisten Menschen ist es immer noch zu kompliziert Ethereum zu benutzen. Um die Massenakzeptanz von Ethereum zu fördern, müssen die Eintrittsbarrieren drastisch gesenkt werden - die Nutzer müssen die Vorteile eines dezentralisierten, erlaubnisfreien und zensurresistenten Zugangs zu Ethereum nutzen können, der jedoch so reibungslos sein muss wie die Nutzung einer herkömmlichen Web2-App.
+description: "Für die meisten Menschen ist es immer noch zu kompliziert Ethereum zu benutzen. Um die Massenakzeptanz von Ethereum zu fördern, müssen die Eintrittsbarrieren drastisch gesenkt werden - die Nutzer müssen die Vorteile eines dezentralisierten, erlaubnisfreien und zensurresistenten Zugangs zu Ethereum nutzen können, der jedoch so reibungslos sein muss wie die Nutzung einer herkömmlichen Web2-App."
lang: de
image: /images/roadmap/roadmap-ux.png
alt: "Ethereum-Roadmap"
template: roadmap
---
-**Die Nutzung von Ethereum muss vereinfacht werden**; von der Verwaltung von [Schlüsseln](/glossary/#key) und [Wallets](/glossary/#wallet) bis zur Initiierung von Transaktionen. Um die Massenakzeptanz zu erleichtern, muss sich die Benutzerfreundlichkeit für Ethereum drastisch erhöhen. Benutzer müssen ohne Berechtigungen und zensurresistent auf Ethereum zugreifen können und dabei von derselben reibungslosen Erfahrung profitieren, die sie von der Nutzung von [Web2](/glossary/#web2)-Anwendungen kennen.
+**Die Nutzung von Ethereum muss vereinfacht werden**; von der Verwaltung von [Schlüsseln](/glossary/#key) und [Wallets](/glossary/#wallet) bis zur Initiierung von Transaktionen. Um die Massenakzeptanz zu erleichtern, muss Ethereum die Benutzerfreundlichkeit drastisch erhöhen, sodass die Nutzer einen erlaubnisfreien und zensurresistenten Zugang zu Ethereum mit der reibungslosen Erfahrung wie bei der Nutzung von [Web2](/glossary/#web2)-Apps erleben können.
-## Jenseits von Seed-Phrasen {#no-more-seed-phrases}
+## Über Seed-Phrases hinaus {#no-more-seed-phrases}
Ethereum-Konten sind durch ein Schlüsselpaar geschützt, das zur Identifizierung von Konten (öffentlicher Schlüssel) und zum Signieren von Nachrichten (privater Schlüssel) verwendet wird. Ein privater Schlüssel ist wie ein Master-Passwort; er ermöglicht den vollständigen Zugang zu einem Ethereum-Konto. Für Menschen, die eher mit Banken und Web2-Apps vertraut sind, welche die Konten im Namen des Nutzers verwalten, ist dies eine andere Art der Bedienung. Damit Ethereum die Massenakzeptanz erreicht, ohne sich auf zentralisierte Dritte zu verlassen, muss es einen unkomplizierten, reibungslosen Weg geben, wie ein Nutzer sein Vermögen in Verwahrung nehmen und die Kontrolle über seine Daten behalten kann, ohne sich mit Public-Private-Key-Kryptografie und Schlüsselverwaltung auskennen zu müssen.
-Die Lösung hierfür ist die Verwendung von [Smart-Contract](/glossary/#smart-contract)-Wallets für die Interaktion mit Ethereum. Smart Contract Wallets bieten die Möglichkeit, Konten bei Verlust oder dem Diebstahl der Schlüssel zu schützen, Betrug besser aufzudecken und abzuwehren und ermöglichen neue Funktionen für Wallets. Obwohl es heute bereits Smart Contract Wallets gibt, ist es schwierig, diese zu erstellen, da das Ethereum-Protokoll sie besser unterstützen muss. Diese zusätzliche Unterstützung wird als Kontoabstraktion bezeichnet.
+Die Lösung für dieses Problem ist die Verwendung von [Smart Contract](/glossary/#smart-contract)-Wallets zur Interaktion mit Ethereum. Smart Contract Wallets bieten die Möglichkeit, Konten bei Verlust oder dem Diebstahl der Schlüssel zu schützen, Betrug besser aufzudecken und abzuwehren und ermöglichen neue Funktionen für Wallets. Obwohl es heute bereits Smart Contract Wallets gibt, ist es schwierig, diese zu erstellen, da das Ethereum-Protokoll sie besser unterstützen muss. Diese zusätzliche Unterstützung wird als Kontoabstraktion bezeichnet.
Mehr zum Thema Kontenabstraktion
## Nodes für jedermann
-Benutzer, die [Knoten](/glossary/#node) betreiben, müssen sich nicht darauf verlassen, dass Dritte ihnen Daten bereitstellen, und können schnell, privat und ohne Berechtigungen mit der Ethereum-[Blockchain](/glossary/#blockchain) interagieren. Allerdings erfordert der Betrieb einer Node derzeit technische Kenntnisse und viel Speicherplatz, so dass viele Menschen stattdessen auf Intermediäre vertrauen müssen.
+Benutzer, die [Nodes](/glossary/#node) betreiben, müssen sich nicht darauf verlassen, dass Dritte ihnen Daten bereitstellen, und können schnell, privat und erlaubnisfrei mit der Ethereum-[Blockchain](/glossary/#blockchain) interagieren. Allerdings erfordert der Betrieb einer Node derzeit technische Kenntnisse und viel Speicherplatz, so dass viele Menschen stattdessen auf Intermediäre vertrauen müssen.
-Es gibt mehrere Upgrades, die den Betrieb von Nodes wesentlich einfacher und weniger ressourcenintensiv machen werden. Die Art und Weise, wie Daten gespeichert werden, wird geändert, um eine platzsparendere Struktur zu verwenden, die als **Verkle Tree** bekannt ist. Außerdem werden mit [ statelessness](/roadmap/statelessness) oder [data expiry](/roadmap/statelessness/#data-expiry), Ethereum-Nodes nicht mehr Kopie der gesamten Ethereum-Statusdaten speichern müssen, was den Speicherplatzbedarf auf der Festplatte drastisch reduziert. [Light nodes](/developers/docs/nodes-and-clients/light-clients/) bietet viele Vorteile eine Full Node, kann aber problemlos auf Mobiltelefonen oder in einfachen Browseranwendungen ausgeführt werden.
+Es gibt mehrere Upgrades, die den Betrieb von Nodes wesentlich einfacher und weniger ressourcenintensiv machen werden. Die Art und Weise, wie Daten gespeichert werden, wird geändert, um eine platzsparendere Struktur zu verwenden, die als **Verkle Tree** bekannt ist. Mit [Zustandslosigkeit](/roadmap/statelessness) oder [Datenablauf](/roadmap/statelessness/#data-expiry) müssen Ethereum-Nodes zudem keine Kopie der gesamten Ethereum-Zustandsdaten mehr speichern, was den Speicherplatzbedarf auf der Festplatte drastisch reduziert. [Light Nodes](/developers/docs/nodes-and-clients/light-clients/) bieten viele der Vorteile des Betriebs eines Full Nodes, können aber problemlos auf Mobiltelefonen oder in einfachen Browser-Apps ausgeführt werden.
-Lesen Sie über Verkle-Trees
+Mehr über Verkle-Trees
Mit diesen Upgrades werden die Hürden für den Betrieb einer Node praktisch auf Null reduziert. Die Nutzer werden von einem sicheren, erlaubnisfreien Zugang zu Ethereum profitieren, ohne dass sie nennenswerten Speicherplatz oder CPU auf ihrem Computer oder Mobiltelefon opfern müssen, und sie werden nicht auf Dritte angewiesen sein, wenn es um den Daten- oder Netzwerkzugang geht, wenn sie Apps verwenden.
## Aktueller Fortschritt {#current-progress}
-Smart-Contract-Wallets sind bereits verfügbar, aber es sind noch weitere Verbesserungen erforderlich, um sie so dezentralisiert und erlaubnislos wie möglich zu gestalten. EIP-4337 ist ein ausgereifter Vorschlag, der keine Änderungen am Ethereum-Protokoll erfordert. Der wichtigste für EIP-4337 erforderliche Smart Contract wurde **im März 2023 bereitgestellt**.
+Smart-Contract-Wallets sind bereits verfügbar, aber es sind noch weitere Verbesserungen erforderlich, um sie so dezentralisiert und erlaubnislos wie möglich zu gestalten. EIP-4337 ist ein ausgereifter Vorschlag, der keine Änderungen am Ethereum-Protokoll erfordert. Der wichtigste Smart Contract, der für EIP-4337 benötigt wird, wurde **im März 2023 bereitgestellt**.
-**Die vollständige Zustandslosigkeit ist noch in der Forschungsphase** und es wird wahrscheinlich noch einige Jahre dauern, bis sie implementiert wird. Es gibt mehrere Meilensteine auf dem Weg zur vollständigen Statelessness, einschließlich data expiry, welche früher umgesetzt werden können. Andere Punkte der Roadmap wie zum Beispiel [ Verkle Trees](/roadmap/verkle-trees/) und [Proposer-builder separation](/roadmap/pbs/) müssen zuerst abgeschlossen werden.
+**Die vollständige Zustandslosigkeit ist noch in der Forschungsphase** und es wird wahrscheinlich noch einige Jahre dauern, bis sie implementiert wird. Es gibt mehrere Meilensteine auf dem Weg zur vollständigen Statelessness, einschließlich data expiry, welche früher umgesetzt werden können. Andere Roadmap-Punkte, wie [Verkle-Trees](/roadmap/verkle-trees/) und die [Trennung von Proposer und Builder](/roadmap/pbs/), müssen zuerst abgeschlossen werden.
Verkle Tree Testnets sind bereits in Betrieb, und die nächste Phase besteht darin, Verkle Tree fähige Clients in privaten und dann in öffentlichen Testnets einzusetzen. Sie können dazu beitragen, den Fortschritt zu beschleunigen, indem Sie Kontrakte in die Testnets einbringen oder Testnet-Clients betreiben.
diff --git a/public/content/translations/de/roadmap/verkle-trees/index.md b/public/content/translations/de/roadmap/verkle-trees/index.md
index 20abb653934..b529c4a6431 100644
--- a/public/content/translations/de/roadmap/verkle-trees/index.md
+++ b/public/content/translations/de/roadmap/verkle-trees/index.md
@@ -7,7 +7,7 @@ summaryPoints:
- Lesen Sie, warum Verkle Trees eine Bereicherung für Ethereum sind.
---
-# Verkle Trees {#verkle-trees}
+# Verkle-Trees {#verkle-trees}
Verkle Trees (ein Schachtelwort aus "Vektor-Verpflichtung" und "Merkle Bäumen") sind eine Datenstruktur, die zum Upgrade von Ethereum Nodes genutzt werden kann, so dass keine großen Mengen an Zustandsdaten mehr gespeichert werden müssen, ohne dass die Fähigkeit der Blockvalidierung verloren geht.
@@ -15,15 +15,14 @@ Verkle Trees (ein Schachtelwort aus "Vektor-Verpflichtung" und "Merkle Bäumen")
Verkle Bäume sind ein kritischer Schritt hin zu Zustandsfreien Ethereum Clients. Zustandsfreie Clients müssen nicht den ganzen Zustand der Datenbank speichern, um hereinkommende Blöcke prüfen zu können. Anstatt ihre eigene Lokale Kopie von Ethereums' Zustand zur Verifizierung zu verwenden, nutzen zustandsfreie Clients einen "Zeugen" der Zustandsdaten, die mit dem Block ankommen. Ein Zeuge ist eine Ansammlung von Einzelteilen an Zustandsdaten, die benötigt werden, um bestimmte Transaktionen auszuführen und gleichzeitig ein kryptographischer Beweis das der Zeuge wirklich Teil der ganzen Daten ist. Der Zeuge wird _anstatt_ der Zustandsdatenbank verwendet. Damit dies funktioniert, müssen Zeugen sehr klein sein, so dass sie sicher und rechtzeitig über das Netzwerk verteilt werden können, damit Validatoren sie innerhalb des 12 Sekunden Zeitfensters bearbeiten können. Die momentane Zustandsdatenstruktur ist dafür nicht geeignet, weil Zeugen zu groß sind. Verkle Trees lösen dieses Problem, indem sie kleine Zeugen ermöglichen und damit eines der Hauptprobleme der zustandsfreien Clienten entfernen.
-
+
Ethereum Clients nutzen momentan eine Datenstruktur, die als Patricia Merkle Trie bekannt ist, um ihre Zustandsdaten zu speichern. Informationen über einzelne Accounts sind als Blätter auf der Baumstruktur gespeichert und Paare von Blättern werden wiederholt gehashed, bis nur ein einzelner Hash bleibt. Der endgültige Hash ist bekannt als die "Wurzel". Um Blöcke zu überprüfen, führen Ethereum Clients alle Transaktionen in einem Block aus und aktualisieren ihren lokalen Zustandsbaum. Der Block wird als gültig angesehen, wenn die Wurzel des lokalen Baumes identisch zu der vom Block-Vorschlagenden ist, weil jeder Unterschied in der Berechnung des Block-Vorschlagenden und der überprüfenden Node einen komplett anderen Wurzelhash ergeben würde. Das Problem hierbei ist, dass die Überprüfung der Blockchain erfordert, dass jeder Client den gesamten Zustandsbaum des Kopf-Blocks und mehrere historische Blöcke (der Standard in Geth ist, die Zustandsdaten für 128 Blöcke hinter dem Kopf zu behalten) erfordert. Dies setzt voraus, dass Clients über große Mengen an Speicherplatz verfügen, was wiederum eine Barriere für günstige ressourcenschonende Hardware ist. Eine Lösung hierfür ist ein Update des Zutandsbaumes auf eine effizientere Struktur (Verkle Tree), die Daten effizient über kleine "Zeugen" teilen kann, anstatt den vollständigen Zustand von Ethereum zu übertragen. Den Datenzustand in Verkle Trees umzuschreiben, ist ein großer Schritt hin zu Zustandsfreien Clients.
-
## Was ist ein Zeuge und warum brauchen wir sie? {#what-is-a-witness}
-Einen Block zu verifizieren bedeutet, die Transaktionen des blockes auszuführen, die Änderungen vollständig in Ethereum's Zustandsbaum zu übertragen und den neuen Wurzelhash zu berechnen. Der berechnete Wurzelhash eines verifizierten Blockes ist identisch zu dem, der mit dem Block geliefert wurde (weil dies bedeutet, dass der Block-Vorschlagende die Berechnung exakt wie der Verifizierende ausgeführt hat). In heutigen Ethereum Clients wird Zugang zum gesamten Zustandsbaum benötigt, der eine große lokal gespeicherte Datenstruktur ist. Ein Zeuge enthält nur Fragmente der Zustandsdaten, die benötigt werden, um die Transaktionen im aktuellen Block auszuführen. Ein Validator kann nur mit diesen Datenfragmenten verifizieren, dass der Block-Vorschlagende die Block-Transaktionen korrekt ausgeführt und den Zustand aktualisiert hat. Dies bedeutet jedoch, dass der Zeuge zwischen Netzwerkteilnehmern des Ethereumnetzwerks schnell genug übertragen werden muss, um innerhalb eines 12 Sekunden Zeitrahmens empfangen und von jeder Node sicher verarbeitet werden zu können. Wenn der Zeuge zu groß ist, könnte das Herunterladen auf manchen Nodes zu lange dauern, so dass diese den Anschluss verlieren könnten. Dies würde Zentralisierung forcieren, da nur Nodes mit sehr schneller Internetverbindung in der Lage wären, erfolgreich bei der Blockvalidierung zu partizipieren. Mit Verkle Trees muss der Zustand nicht mehr auf einem lokalen Speichermedium gespeichert werden; _Alles_ was gebraucht wird, befindet sich im Block selber. Unglücklicherweise sind die Zeugen, die aus Merkle-Bäumen erstellt werden können, viel zu groß, um zustandsfreie Clients zu ermöglichen.
+Einen Block zu verifizieren bedeutet, die Transaktionen des blockes auszuführen, die Änderungen vollständig in Ethereum's Zustandsbaum zu übertragen und den neuen Wurzelhash zu berechnen. Der berechnete Wurzelhash eines verifizierten Blockes ist identisch zu dem, der mit dem Block geliefert wurde (weil dies bedeutet, dass der Block-Vorschlagende die Berechnung exakt wie der Verifizierende ausgeführt hat). In heutigen Ethereum Clients wird Zugang zum gesamten Zustandsbaum benötigt, der eine große lokal gespeicherte Datenstruktur ist. Ein Zeuge enthält nur Fragmente der Zustandsdaten, die benötigt werden, um die Transaktionen im aktuellen Block auszuführen. Ein Validator kann nur mit diesen Datenfragmenten verifizieren, dass der Block-Vorschlagende die Block-Transaktionen korrekt ausgeführt und den Zustand aktualisiert hat. Dies bedeutet jedoch, dass der Zeuge zwischen Netzwerkteilnehmern des Ethereumnetzwerks schnell genug übertragen werden muss, um innerhalb eines 12 Sekunden Zeitrahmens empfangen und von jeder Node sicher verarbeitet werden zu können. Wenn der Zeuge zu groß ist, könnte das Herunterladen auf manchen Nodes zu lange dauern, so dass diese den Anschluss verlieren könnten. Dies würde Zentralisierung forcieren, da nur Nodes mit sehr schneller Internetverbindung in der Lage wären, erfolgreich bei der Blockvalidierung zu partizipieren. Mit Verkle-Trees muss der Zustand nicht auf Ihrer Festplatte gespeichert werden; _alles_, was Sie zur Verifizierung eines Blocks benötigen, ist im Block selbst enthalten. Unglücklicherweise sind die Zeugen, die aus Merkle-Bäumen erstellt werden können, viel zu groß, um zustandsfreie Clients zu ermöglichen.
## Warum erlauben Verkle Bäume kleinere Zeugen? {#why-do-verkle-trees-enable-smaller-witnesses}
@@ -31,36 +30,35 @@ Die Struktur eines Merkle Trie erzeugt sehr große Zeugen - zu groß, um sicher
In einem Polynombindungs-Schema haben die Zeugen überschaubare Größen, die leicht unter Netzwerkteilnehmern versendet werden können. Dies erlaubt Clients, Zustandsveränderungen in jedem Block mit minimaler Menge an Daten zu verifizieren.
-
+
Die Größe des Zeugen variiert abhängig von der Anzahl der Blätter, die er enthält. Davon ausgehend, dass ein Zeuge 1000 Blätter abdeckt, wäre ein Zeuge für einen Merkle Baum ungefähr 3,5 MB (von 7 Ebenen im Trie ausgehend). Ein Zeuge für die selben Daten in einem Verkle Baum (von 4 Ebenen zum Baum ausgehend) würde ungefähr 150 kB an Daten ergeben -**etwa 23x kleiner**. Diese Reduktion der Zeugengröße wird Zeugen in zustandsfreien Clients ermöglichen, akzeptabel klein zu sein. Polynomzeugen sind 0,128–1 kB groß; abhängig davon, welches spezifische Polynom-Commitment verwendet wird.
-
-## Wie sieht die Struktur von Verkle Bäumen aus? {#what-is-the-structure-of-a-verkle-tree}
+## Wie sieht die Struktur von Verkle Bäumen aus? Was ist die Struktur eines Verkle-Trees? {#what-is-the-structure-of-a-verkle-tree}
-Verkle Bäume sind `(key,value)` Paare, in denen die keys 32-byte Elemente zusammengestellt aus einem 31-byte _stem_ und einem einzelnen byte _suffix_ sind. Diese Schlüssel sind in _extension_ Knoten und _inner_ Knoten organisiert. Erweiterungsknoten repräsentieren einen einzelnen Stamm für 256 Kinder mit verschiedenen Suffixes. Innere-Knoten haben auch 256 Kinder, aber sie können andere Erweiterungsknoten sein. Der Hauptunterschied zwischen Verklebaum- und Merklebaum-Struktur ist, dass der Verkle Baum viel flacher mit weniger Zwischenknoten ist, die das Blatt zur Wurzel verbinden und so insgesamt weniger Daten benötigen, um einen Beweis zu generieren.
+Verkle-Trees sind `(key,value)`-Paare, bei denen die Schlüssel 32-Byte-Elemente sind, die sich aus einem 31-Byte-_Stamm_ und einem einzelnen Byte-_Suffix_ zusammensetzen. Diese Schlüssel sind in _Extension-Nodes_ und _Inner-Nodes_ organisiert. Erweiterungsknoten repräsentieren einen einzelnen Stamm für 256 Kinder mit verschiedenen Suffixes. Innere-Knoten haben auch 256 Kinder, aber sie können andere Erweiterungsknoten sein. Der Hauptunterschied zwischen Verklebaum- und Merklebaum-Struktur ist, dass der Verkle Baum viel flacher mit weniger Zwischenknoten ist, die das Blatt zur Wurzel verbinden und so insgesamt weniger Daten benötigen, um einen Beweis zu generieren.
-[Lesen Sie mehr üner die Struktur von Verkle Bäumen](https://blog.ethereum.org/2021/12/02/verkle-tree-structure)
+[Lesen Sie mehr über die Struktur von Verkle-Trees](https://blog.ethereum.org/2021/12/02/verkle-tree-structure)
## Aktueller Fortschritt {#current-progress}
Verkle Tree Testnetzwerke laufen bereits, aber es sind noch substantielle Updates der Clients vonnöten, um Verkle Bäume zu unterstützen. Sie können dazu beitragen, den Fortschritt zu beschleunigen, indem Sie Kontrakte in die Testnets einbringen oder Testnet-Clients betreiben.
-[Entdecken Sie das Verkle Gen Devnet 2-Testnetz](https://verkle-gen-devnet-2.ethpandaops.io/)
-
-[Sehen Sie sich an, wie Guillaume Ballet das Condrieu Verkle-Testnetz erklärt](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (beachten Sie, dass das Condrieu-Testnetz Proof-of-Work war und durch das Verkle Gen Devnet 2-Testnetz ersetzt wurde).
-
-## Weiterführende Informationen {#further-reading}
-
-- [Verkle Trees für Zustandslosigkeit](https://verkle.info/)
-- [Dankrad Feist erklärt Verkle Trees bei PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ)
-- [Guillaume Ballet erklärt Verkle Trees bei ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o)
-- ["Wie Verkle Trees Ethereum schlank und super machen" von Guillaume Ballet bei Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs)
-- [Piper Merriam über zustandsfreie Clients bei ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4)
-- [Dankrad Fiest erklärt Verkle Trees und Zustandslosigkeit im Podcast zu Null-Wissen](https://zeroknowledge.fm/podcast/202/)
-- [Vitalik Buterin über Verkle Trees](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
-- [Dankrad Feist über Verkle Trees](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)
-- [Verkle Trees EIP Dokumentation](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration)
+[Sehen Sie sich an, wie Guillaume Ballet das Condrieu Verkle-Testnet erklärt](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (beachten Sie, dass das Condrieu-Testnet Proof-of-Work war und inzwischen durch das Verkle Gen Devnet 6 Testnet ersetzt wurde).
+
+## Weiterführende Lektüre {#further-reading}
+
+- [Verkle-Trees für Zustandslosigkeit](https://verkle.info/)
+- [Dankrad Feist erklärt Verkle-Trees auf PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ)
+- [Verkle-Trees für alle](https://web.archive.org/web/20250124132255/https://research.2077.xyz/verkle-trees)
+- [Anatomie eines Verkle-Proofs](https://ihagopian.com/posts/anatomy-of-a-verkle-proof)
+- [Guillaume Ballet erklärt Verkle-Trees bei ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o)
+- ["Wie Verkle-Trees Ethereum schlank und leistungsstark machen" von Guillaume Ballet bei Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs)
+- [Piper Merriam über zustandslose Clients von der ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4)
+- [Dankrad Fiest erklärt Verkle-Trees und Zustandslosigkeit im Zero-Knowledge-Podcast](https://zeroknowledge.fm/podcast/202/)
+- [Vitalik Buterin über Verkle-Trees](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
+- [Dankrad Feist über Verkle-Trees](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)
+- [Verkle-Tree-EIP-Dokumentation](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration)
diff --git a/public/content/translations/de/security/index.md b/public/content/translations/de/security/index.md
index 5caf5e8a2e0..ae63e484602 100644
--- a/public/content/translations/de/security/index.md
+++ b/public/content/translations/de/security/index.md
@@ -1,16 +1,18 @@
---
-title: Ethereum – Sicherheits- und Betrugsvorbeugung
+title: "Ethereum – Sicherheits- und Betrugsvorbeugung"
description: Ethereum sicher nutzen
lang: de
---
-# Ethereum – Sicherheits- und Betrugsvorbeugung {#introduction}
+# Ethereum-Sicherheit und Betrugsprävention {#introduction}
Das zunehmende Interesse an Kryptowährungen bringt ein wachsendes Risiko durch Betrüger und Hacker mit sich. In diesem Artikel geht es um bewährte Praktiken, um diese Risiken einzugrenzen.
+**Denken Sie daran: Niemand von ethereum.org wird Sie jemals kontaktieren. Beantworten Sie keine E-Mails, die angeblich vom offiziellen Ethereum-Support stammen.**
+
-## Das Einmaleins der Krypto-Sicherheit {#crypto-security}
+## Grundlagen der Krypto-Sicherheit {#crypto-security}
### Erweitern Sie Ihr Wissen {#level-up-your-knowledge}
@@ -27,7 +29,7 @@ Missverständnisse über die Funktionsweise von Krypto können zu kostspieligen
## Wallet-Sicherheit {#wallet-security}
-### Geben Sie Ihre privaten Schlüssel nicht heraus {#protect-private-keys}
+### Geben Sie Ihre privaten Schlüssel nicht weiter {#protect-private-keys}
**Teilen Sie niemals – aus welchem Grund auch immer – Ihre privaten Schlüssel!**
@@ -37,38 +39,39 @@ Der private Schlüssel zu Ihrem Wallet ist ein Passwort für Ihr Ethereum-Wallet
Was ist eine Ethereum-Wallet?
-#### Nehmen Sie niemals Screenshots Ihrer Seed-Phrasen oder privaten Schlüssel auf {#screenshot-private-keys}
+#### Erstellen Sie keine Screenshots Ihrer Seed-Phrasen/privaten Schlüssel {#screenshot-private-keys}
Ein Screenshot Ihrer Seed-Phrase oder Ihrer privaten Schlüssel könnte mit einem Cloud-Datenanbieter synchronisiert werden, was sie für Hacker zugänglich machen könnte. Über die Cloud auf private Schlüssel zuzugreifen ist ein gängiger Angriffsvektoren für Hacker.
-### Eine Hardware-Wallet verwenden {#use-hardware-wallet}
+### Verwenden Sie eine Hardware-Wallet {#use-hardware-wallet}
Eine Hardware-Wallet bietet einen Offline-Speicherplatz für Ihre Private-Keys. Sie gelten als die sicherste Wallet-Option zum Speichern Ihrer privaten Schlüssel: Ihr privater Schlüssel berührt niemals das Internet und bleibt vollständig lokal auf Ihrem Gerät.
Ihre Private-Keys offline aufzubewahren reduziert das Risiko gehackt zu werden, auch wenn ein Hacker Zugang zu Ihrem Computer bekommt.
-#### Überzeugen Sie sich selbst von einer Hardware-Wallet: {#try-hardware-wallet}
+#### Probieren Sie eine Hardware-Wallet aus: {#try-hardware-wallet}
- [Ledger](https://www.ledger.com/)
- [Trezor](https://trezor.io/)
-### Transaktionen vor dem Absenden immer prüfen {#double-check-transactions}
+### Überprüfen Sie Transaktionen vor dem Senden doppelt {#double-check-transactions}
-Es kommt häufig vor, dass Kryptowährung versehentlich an eine falsche Wallet-Adresse gesendet wird. **Eine Transaktion, die auf Ethereum verschickt wird, ist unumkehrbar.** Sie werden ihr Geld nicht zurückholen können, solange Sie den Adresseninhaber nicht kennen und ihn davon überzeugen können, Ihnen die Summe zurückzuschicken.
+Es kommt häufig vor, dass Kryptowährung versehentlich an eine falsche Wallet-Adresse gesendet wird. **Eine Transaktion, die auf Ethereum verschickt wird, ist unumkehrbar.** Sie werden Ihr Geld nicht zurückholen können, solange Sie den Adresseninhaber nicht kennen und ihn davon überzeugen können, Ihnen die Summe zurückzuschicken.
-Stellen Sie immer sicher, dass die Adresse, an die Sie Geld überweisen, genau die Adresse des Empfängers ist. Bei einer Interaktion mit einem Smart Contract ist es eine bewährte Vorgehensweise, vor der Unterschrift die Transaktionsnachricht zu lesen.
+Stellen Sie immer sicher, dass die Adresse, an die Sie Geld überweisen, genau die Adresse des Empfängers ist.
+Bei einer Interaktion mit einem Smart Contract ist es eine bewährte Vorgehensweise, vor der Unterschrift die Transaktionsnachricht zu lesen.
-### Ausgabelimits für Smart Contracts festlegen {#spend-limits}
+### Ausgabenlimits für Smart Contracts festlegen {#spend-limits}
Wenn Sie mit Smart Contracts interagieren, sollten Sie keine unbegrenzten Ausgabelimits zulassen. Ein unbegrenztes Ausgabelimit könnte einem Smart Contract ermöglichen, Ihre Wallet komplett zu leeren. Legen Sie stattdessen für die Ausgabelimits nur den Wert fest, der für die Transaktion erforderlich ist.
Viele Ethereum-Wallets bieten Schutz gegen die komplette Entleerung durch Hackerangriffe an.
-[So widerrufen Sie den Smart-Contract-Zugriff auf Ihre Krypto-Gelder](/guides/how-to-revoke-token-access/)
+[So widerrufen Sie den Zugriff von Smart Contracts auf Ihre Krypto-Gelder](/guides/how-to-revoke-token-access/)
-## Häufige Betrugsversuche {#common-scams}
+## Häufige Betrugsmaschen {#common-scams}
Es ist unmöglich, Betrüger vollständig aufzuhalten. Allerdings können wir dafür sorgen, dass sie weniger effektiv sind, indem wir ihre am meisten genutzten Techniken kennen. Es gibt viele Variationen von Betrugsversuchen, aber die meisten folgen denselben Mustern. Merken Sie sich auf jeden Fall Folgendes:
@@ -76,45 +79,45 @@ Es ist unmöglich, Betrüger vollständig aufzuhalten. Allerdings können wir da
- Niemand wird Ihnen ETH kostenlos oder zu einem günstigeren Preis geben
- Niemand benötigt Zugang zu Ihren Private-Keys oder anderen persönlichen Informationen!
-### Phishing mit Twitter-Werbung {#ad-phishing}
+### Twitter-Anzeigen-Phishing {#ad-phishing}
-
+
-Es gibt eine Methode, um die Linkvorschau-Funktion auf Twitter (auch bekannt als X) zu fälschen („Unfurling“), sodass Benutzer unter Umständen glauben gemacht wird, dass sie eine seriöse Website besuchen. Diese Technik nutzt Twitters Mechanismus für das Generieren von URL-Vorschauen aus, die in Tweets geteilt wurden. Es wird dann zum Beispiel _von ethereum.org_ (siehe oben) angezeigt, obwohl die Nutzer eigentlich auf eine schädliche Website weitergeleitet werden.
+Es gibt eine Methode, um die Linkvorschau-Funktion auf Twitter (auch bekannt als X) zu fälschen („Unfurling“), sodass Benutzer unter Umständen glauben gemacht wird, dass sie eine seriöse Website besuchen. Diese Technik nutzt den Mechanismus von Twitter zur Erstellung von URL-Vorschauen, die in Tweets geteilt werden. Dadurch wird zum Beispiel _von ethereum.org_ angezeigt (siehe oben), obwohl Nutzer tatsächlich auf eine bösartige Seite weitergeleitet werden.
Gehen Sie immer sicher, dass Sie sich auf der richtigen Domain befinden, vor allem, nachdem Sie auf einen Link geklickt haben.
-[Weitere Informationen dazu hier](https://harrydenley.com/faking-twitter-unfurling).
+[Weitere Informationen hier](https://harrydenley.com/faking-twitter-unfurling).
### Giveaway-Betrug {#giveaway}
-Einer der häufigsten Betrugsfälle in der Welt der Kryptowährungen ist der Giveaway-Betrug. Der Giveaway-Betrug kann viele Formen annehmen. Die Grundidee ist jedoch, dass Sie ETH an die angegebene Wallet-Adresse schicken, woraufhin Sie Ihre ETH doppelt zurückbekommen. *Aus diesem Grund wird dieser Betrug auch häufig als „2-für-1“-Betrug bezeichnet.*
+Einer der häufigsten Betrugsfälle in der Welt der Kryptowährungen ist der Giveaway-Betrug. Der Giveaway-Betrug kann viele Formen annehmen. Die Grundidee ist jedoch, dass Sie ETH an die angegebene Wallet-Adresse schicken, woraufhin Sie Ihre ETH doppelt zurückbekommen._Aus diesem Grund wird dieser Betrug auch häufig als „2-für-1“-Betrug bezeichnet._
Bei diesen Betrügereien wird normalerweise ein begrenztes Zeitfenster für die Inanspruchnahme des Giveaways vorgetäuscht, um ein falsches Gefühl der Dringlichkeit vorzutäuschen.
-### Social-Media-Hacks {#social-media-hacks}
+### Hacks in sozialen Medien {#social-media-hacks}
Eine namhafte Variante des Giveaway-Betrugs gab es im Juli 2020, als die Twitter-Konten prominenter Personen und Organisationen gehackt wurden. Die Hacker veröffentlichten ein Bitcoin-Giveaway auf allen gehackten Konten gleichzeitig. Obwohl die betrügerischen Tweets schnell bemerkt und gelöscht wurden, gelang es den Hackern dennoch, 11 Bitcoin (oder umgerechnet 500.000 Dollar, Stand September 2021) zu erbeuten.
-### Promi-Giveaway {#celebrity-giveaway}
+### Prominenten-Giveaway {#celebrity-giveaway}
-Ein Promi-Giveaway ist eine andere häufige Form des Giveaway-Betrugs. Betrüger nehmen ein aufgezeichnetes Video-Interview oder einen Konferenz-Vortrag mit einer prominenten Person und streamen es live auf YouTube. Das erweckt den Anschein, als ob die Person ein Live-Interview zur Unterstützung eines Kryptowährungs-Giveaway gibt.
+Ein Promi-Giveaway ist eine andere häufige Form des Giveaway-Betrugs. Die Betrüger nehmen ein aufgezeichnetes Videointerview oder einen Konferenzvortrag eines Prominenten auf und streamen es live auf YouTube – so entsteht der Eindruck, dass der Prominente in einem Live-Videointerview ein Kryptowährungs-Giveaway bewirbt.
-Vitalik Buterin wird am häufigsten für diese Art von Giveaway-Betrug benutzt, aber viele andere prominente Personen in der Kryptoszene (z. B. Elon Musk oder Charles Hoskinson) ebenso. Eine berühmte Person in diesen Betrug hineinzuziehen, verleiht dem Livestream der Betrüger eine gewisse Legitimität (das sieht eigentlich unglaubwürdig aus, aber da Vitalik involviert ist, muss es in Ordnung sein!).
+Vitalik Buterin wird bei dieser Betrugsmasche am häufigsten benutzt, aber auch viele andere bekannte Personen aus der Kryptoszene werden verwendet (z. B. Elon Musk oder Charles Hoskinson). Eine berühmte Person in diesen Betrug hineinzuziehen, verleiht dem Livestream der Betrüger eine gewisse Legitimität (das sieht eigentlich unglaubwürdig aus, aber da Vitalik involviert ist, muss es in Ordnung sein!).
**Giveaways sind immer Betrug. Wenn Sie Ihre Kryptowährung an diese betrügerischen Konten senden, ist das Geld für immer weg.**
-### Unterstützungsbetrug {#support-scams}
+### Support-Betrug {#support-scams}
Kryptowährung ist eine relativ junge und missverstandene Technologie. Eine gängige Betrugsmasche, die davon profitiert, ist der Unterstützungsbetrug. Dabei imitieren Betrüger die Mitarbeiter häufig benutzter Wallets, Exchanges oder Blockchains.
Ein Großteil der Diskussion über Ethereum findet auf der Plattform Discord statt. Unterstützungsbetrüger finden Ihre Opfer, indem sie in öffentlichen Discord-Kanälen nach Fragen suchen, und der Person eine private Nachricht senden, die etwas gefragt hat, um Unterstützung anzubieten. Indem die Betrüger Vertrauen aufbauen, versuchen sie, Sie dazu zu bringen, Ihren Private-Key offenzulegen oder auch direkt Geld (in Form von Kryptowährung) an ihre Konten zu schicken.
-
+
Allgemein gilt: Mitarbeiter kommunizieren mit Ihnen nie über private, inoffizielle Kanäle. Ein paar einfache Dinge, die Sie beim Umgang mit Mitarbeitern im Hinterkopf behalten sollten:
@@ -126,20 +129,20 @@ Allgemein gilt: Mitarbeiter kommunizieren mit Ihnen nie über private, inoffizie
- Achtung: Obwohl Unterstützungsbetrug oft auf Discord erfolgt, ist es auch möglich, dass diese und auch andere Arten von Betrug auf anderen Chat-Plattformen, einschließlich per E-Mail, vorkommen können.
+ Achtung: Obwohl Betrugsmaschen im Support-Stil häufig auf Discord vorkommen, können sie auch in jeder Chat-Anwendung, in der über Kryptowährungen diskutiert wird, einschließlich E-Mails, verbreitet sein.
### „Eth2“-Token-Betrug {#eth2-token-scam}
-Im Vorfeld der [Zusammenführung](/roadmap/merge/) haben Betrüger die Chance ergriffen, die Verwirrung um den Begriff „Eth2“ für sich zu nutzen, indem sie Benutzer dazu brachten, ihr ETH gegen „ETH2“-Token einzutauschen. Es gibt kein „ETH2", und es wurde auch kein anderer legitimer Token zusammen mit der Zusammenführung eingeführt. Das ETH, welches Sie vor der Zusammenführung besaßen, ist jetzt weiterhin das gleiche ETH. Es ist in Bezug auf den Wechsel von Proof-of-Work zu Proof-of-Stake **nicht nötig, im Zusammenhang mit Ihren ETH aktiv zu werden**.
+Im Vorfeld von [Die Zusammenführung](/roadmap/merge/) nutzten Betrüger die Verwirrung um den Begriff „Eth2“ aus, um Nutzer dazu zu bringen, ihre ETH gegen einen „ETH2“-Token einzutauschen. Es gibt kein „ETH2", und es wurde auch kein anderer legitimer Token zusammen mit der Zusammenführung eingeführt. Das ETH, welches Sie vor der Zusammenführung besaßen, ist jetzt weiterhin das gleiche ETH. **Es ist nicht notwendig, bezüglich Ihrer ETH irgendwelche Maßnahmen für den Wechsel von Proof-of-Work zu Proof-of-Stake zu ergreifen**.
-Betrüger könnten sich als „Support" ausgeben, und Sie dazu auffordern Ihr ETH einzuzahlen, um im Gegenzug „ETH2" zu erhalten. Es gibt kein [offizielles Ethereum-Support-Team](/community/support/) und auch keinen neuen Token. Teilen Sie niemals Ihre Ethereum-Wallet-Seed-Phrasen.
+Betrüger könnten sich als „Support" ausgeben, und Sie dazu auffordern Ihr ETH einzuzahlen, um im Gegenzug „ETH2" zu erhalten. Es gibt keinen [offiziellen Ethereum-Support](/community/support/) und es gibt keinen neuen Token. Teilen Sie niemals Ihre Ethereum-Wallet-Seed-Phrasen.
-_Hinweis: Es gibt abgeleitete (derivative) Token/Ticker, die staked ETH darstellen können (z. B. rETH von Rocket Pool, stETH von Lido, ETH2 von Coinbase). Doch diese abgeleiteten Token sind nichts, zu dem Sie „migrieren“ müssen._
+_Hinweis: Es gibt derivative Token/Ticker, die gestakte ETH repräsentieren können (d. h. rETH von Rocket Pool, stETH von Lido, ETH2 von Coinbase), aber zu diesen müssen Sie nicht „migrieren“._
-### Phishing-Betrug {#phishing-scams}
+### Phishing-Betrugsmaschen {#phishing-scams}
Phishing ist eine Betrugsmasche, die sich immer stärker ausbreitet. Betrüger setzen darauf, um das Geld aus Ihrer Wallet zu stehlen.
@@ -151,9 +154,9 @@ Wenn Sie eine E-Mail von einem unbekannten Absender erhalten, denken Sie daran:
- Geben Sie niemals Ihre persönlichen Daten oder Kennwörter an Dritte weiter
- Löschen Sie E-Mails von unbekannten Absendern
-[Mehr zur Vermeidung von Phishing-Betrugsversuchen](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico)
+[Mehr zur Vermeidung von Phishing-Betrugsmaschen](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico)
-### Krypto-Makler-Betrug {#broker-scams}
+### Krypto-Broker-Betrug {#broker-scams}
Betrügerische Krypto-Börsenmakler geben sich als fachmännische Makler für Kryptowährungen aus, die Ihnen anbieten, Ihr Geld zu nehmen und es in Ihrem Namen zu investieren. Nachdem der Betrüger Ihr Geld bekommen hat, könnte er Sie bitten, ihm noch mehr Geld zu senden, damit Sie keine weiteren Anlagegewinne verpassen. Oder der Betrüger verschwindet einfach sofort komplett.
@@ -161,9 +164,9 @@ Diese Betrüger finden ihre Zielpersonen oft, indem sie gefälschte Konten auf Y
**Vertrauen Sie keiner fremden Person im Internet, Investitionen in Ihrem Namen zu tätigen. Sie werden so Ihre Krypto verlieren.**
-
+
-### Krypto-Mining-Pool-Betrug {#mining-pool-scams}
+### Betrugsmaschen mit Krypto-Mining-Pools {#mining-pool-scams}
Seit September 2022 ist Mining auf Ethereum nicht mehr möglich. Jedoch gibt es noch immer Mining-Pool-Betrug. Beim Mining-Pool-Betrug werden Sie unaufgefordert von anderen Personen kontaktiert, die vorgeben, dass Sie große Gewinne erzielen können, wenn Sie einem Ethereum-Mining-Pool beitreten. Die Betrüger tischen Ihnen eine Lüge nach der anderen auf und werden solange mit Ihnen in Kontakt bleiben, wie es erforderlich ist. Im Grunde wird der Betrüger versuchen, Sie davon zu überzeugen, einem Mining-Pool für Ethereum beizutreten. Mit Ihrer Kryptowährung würden dann ETH geschaffen und Ihnen ETH-Dividenden ausgezahlt. Sie werden dann erkennen, dass Ihre Kryptowährung kleine Erträge abwirft. Das ist natürlich so gedacht, um Sie dazu zu bringen, mehr Kryptowährung zu investieren. Am Ende wird Ihre Kryptowährung an eine unbekannte Adresse gesendet und der Betrüger wird entweder verschwinden oder, wie kürzlich zu beobachten war, vielleicht sogar weiter mit Ihnen in Kontakt bleiben.
@@ -175,68 +178,68 @@ Folgendes sollten Sie beachten:
- Recherchieren Sie selbst umfassend zu Themen wie Staking, Liquiditäts-Pools und andere Investitionsmöglichkeiten für Ihre Kryptowährung
- Solche Pläne sind selten, wenn überhaupt, echt. Wären sie es, dann würden viele darüber Bescheid wissen und Sie hätten eventuell schon einmal etwas davon gehört.
-[Mann verliert 200.000 US-Dollar in einem Mining-Pool-Betrug](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/)
+[Mann verliert 200.000 $ durch Mining-Pool-Betrug](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/)
-### Airdrop-Betrug {#airdrop-scams}
+### Airdrop-Betrugsmaschen {#airdrop-scams}
Beim Airdrop-Betrug wird über ein Betrugsprojekt ein Asset (z. B. ein NFT/Token) per Airdrop an Ihre Wallet gesendet. Sie werden daraufhin zu einer Betrugs-Website weitergeleitet, damit Sie die per Airdrop versendeten Assets beanspruchen können. Sie werden aufgefordert, sich mit Ihrer Ethereum-Wallet anzumelden, um eine Transaktion zu „autorisieren“, wenn Sie versuchen, den Besitz an dem Asset zu beanspruchen. Diese Transaktion ist eine Gefährdung für Ihr Konto, denn dabei werden Ihre öffentlichen und privaten Schlüssel an den Betrüger gesendet. In einer alternativen Form dieses Betrugs werden Sie dazu aufgefordert, eine Transaktion zu genehmigen, über die Geld direkt zu dem Wallet des Betrügers gesendet wird.
-[Mehr zu Airdrop-Betrugsversuchen](https://www.youtube.com/watch?v=LLL_nQp1lGk)
+[Mehr zu Airdrop-Betrugsmaschen](https://www.youtube.com/watch?v=LLL_nQp1lGk)
-## Das Einmaleins der Sicherheit im Internet {#web-security}
+## Grundlagen der Websicherheit {#web-security}
-### Starke Kennwörter verwenden {#use-strong-passwords}
+### Verwenden Sie starke Passwörter {#use-strong-passwords}
-[In mehr als 80 % der Fälle von gehackten Konten waren die Kennwörter entweder zu schwach oder gestohlen.](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Eine lange Kombination aus Buchstaben, Zahlen und Sonderzeichen hilft Ihnen dabei, Ihre Konten zu schützen.
+[Über 80 % der Konto-Hacks sind auf schwache oder gestohlene Passwörter zurückzuführen](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Eine lange Kombination aus Buchstaben, Zahlen und Sonderzeichen hilft Ihnen dabei, Ihre Konten zu schützen.
Ein typischer Fehler ist das Verwenden einer Kombination aus ein paar geläufigen Wörtern, die miteinander in Beziehung stehen. Passwörter wie diese sind unsicher, weil sie anfällig für eine Hacking-Technik namens „Wörterbuchangriff“ sind.
```md
-Beispiel eines schwachen Kennworts: SüßeWeicheKätzchen!
+Beispiel für ein schwaches Passwort: CuteFluffyKittens!
-Beispiel eines starken Kennworts: ymv\*azu.EAC8eyp8umf
+Beispiel für ein starkes Passwort: ymv\*azu.EAC8eyp8umf
```
-Ein weiterer üblicher Fehler ist das Nutzen von Passwörtern, die einfach erraten oder durch [Social Engineering](https://wikipedia.org/wiki/Social_engineering_(security)) entdeckt werden können. Die Verwendung des Geburtsnamens Ihrer Mutter, der Namen Ihrer Kinder oder Haustiere oder Ihrer Geburtsdaten in Ihrem Passwort erhöht das Risiko, gehackt zu werden.
+Ein weiterer häufiger Fehler ist die Verwendung von Passwörtern, die leicht erraten oder durch [Social Engineering](https://wikipedia.org/wiki/Social_engineering_\(security\)) aufgedeckt werden können. Die Verwendung des Geburtsnamens Ihrer Mutter, der Namen Ihrer Kinder oder Haustiere oder Ihrer Geburtsdaten in Ihrem Passwort erhöht das Risiko, gehackt zu werden.
-#### Guter Umgang mit Kennwörtern: {#good-password-practices}
+#### Bewährte Methoden für Passwörter: {#good-password-practices}
- Erstellen Sie Kennwörter, welche die maximal mögliche Länge im Kennwortgenerator oder dem Formular, das Sie ausfüllen, in Anspruch nehmen
- Verwenden Sie eine Kombination aus Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen
- Verwenden Sie in Ihrem Kennwort keine persönlichen Daten, wie beispielsweise Familiennamen
- Meiden Sie gängige Wörter
-[Mehr zum Erstellen starker Kennwörter](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/)
+[Mehr zum Erstellen starker Passwörter](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/)
-### Verwendung einzigartiger Kennwörter {#use-unique-passwords}
+### Verwenden Sie für alles einzigartige Passwörter {#use-unique-passwords}
-Ein starkes Passwort, das im Rahmen einer Datenpanne offenbart wurde, ist kein starkes Passwort mehr. Die Website [Have I Been Pwned](https://haveibeenpwned.com) ermöglicht Ihnen, zu prüfen, ob Ihre Konten in eine öffentliche Datenpanne involviert waren. Wenn dies der Fall ist, **ändern Sie diese Passwörter unverzüglich**. Die Verwendung unterschiedlicher Passwörter für jedes Konto mindert das Risiko, dass Hacker Zugriff auf alle Ihre Konten erhalten, wenn eines Ihrer Passwörter kompromittiert wird.
+Ein starkes Passwort, das im Rahmen einer Datenpanne offenbart wurde, ist kein starkes Passwort mehr. Die Website [Have I Been Pwned](https://haveibeenpwned.com) ermöglicht es Ihnen, zu überprüfen, ob Ihre Konten von öffentlichen Datenlecks betroffen waren. Falls ja, **ändern Sie diese Passwörter sofort**. Die Verwendung unterschiedlicher Passwörter für jedes Konto mindert das Risiko, dass Hacker Zugriff auf alle Ihre Konten erhalten, wenn eines Ihrer Passwörter kompromittiert wird.
-### Verwendung von Kennwortmanagern {#use-password-manager}
+### Verwenden Sie einen Passwort-Manager {#use-password-manager}
- Ein Kennwortmanager ist hilfreich bei der Erstellung starker, einzigartiger Kennwörter und dabei sich diese zu merken! Wir empfehlen dringend die Verwendung eines Kennwortmanagers! Es gibt viele gute, kostenlose Angebote.
+ Ein Passwort-Manager erstellt starke, einzigartige Passwörter für Sie und merkt sie sich! Wir empfehlen dringend, einen zu verwenden, und die meisten davon sind kostenlos!
Es ist nicht möglich, sich starke, einzigartige Kennwörter für jedes Konto zu merken, das Sie eingerichtet haben. Ein Kennwortmanager bietet Ihnen einen sicheren, verschlüsselten Speicher für all Ihre Kennwörter, auf den Sie über ein starkes Master-Kennwort zugreifen können. Ein solches Tool schlägt Ihnen auch starke Kennwörter vor, wenn Sie sich für einen neuen Dienst anmelden, sodass Sie keine eigenen erstellen müssen. Viele Kennwortmanager informieren Sie auch, wenn Sie von einem Datenleck betroffen sind, sodass Sie Ihre Kennwörter vor böswilligen Angriffen ändern können.
-
+
-#### Überzeugen Sie sich selbst von einem Kennwortmanager: {#try-password-manager}
+#### Probieren Sie einen Passwort-Manager aus: {#try-password-manager}
- [Bitwarden](https://bitwarden.com/)
- [KeePass](https://keepass.info/)
- [1Password](https://1password.com/)
-- Oder sehen Sie sich andere [empfohlene Passwortmanager](https://www.privacytools.io/secure-password-manager) an
+- Oder sehen Sie sich andere [empfohlene Passwort-Manager](https://www.privacytools.io/secure-password-manager) an
-### Zwei-Faktor-Authentifizierung verwenden {#two-factor-authentication}
+### Verwenden Sie die Zwei-Faktor-Authentifizierung {#two-factor-authentication}
Sie werden möglicherweise gelegentlich aufgefordert, Ihre Identität mit einzigartigen Nachweisen zu authentifizieren. Diese werden als **Faktoren** bezeichnet. Die drei Hauptfaktoren lauten:
@@ -244,26 +247,26 @@ Sie werden möglicherweise gelegentlich aufgefordert, Ihre Identität mit einzig
- Etwas, das nur Sie sind (wie ein Fingerabdruck oder ein Iris-/Gesichts-Scan)
- Etwas, das nur Sie besitzen (wie ein Sicherheitsschlüssel, oder eine Authentifizierungs-App auf Ihrem Smartphone)
-Die Nutzung der **Zwei-Faktor-Authentifizierung (2FA)** bietet einen zusätzlichen *Sicherheitsfaktor* für Ihre Online-Konten. 2FA sorgt dafür, dass Ihr Passwort allein nicht reicht, um auf ein Konto zuzugreifen. Meist ist der zweite Faktor ein zufälliger 6-stelliger Code, bekannt als ein **zeitabhängiges einmaliges Kennwort (Time-based One-time Password, TOTP)**, auf das Sie über eine Authentifizierungs-App wie Google Authenticator oder Authy Zugriff haben. Solche Apps funktionieren als „etwas, das Sie besitzen“-Faktor, da der Seed, der den Zeitcode generiert, auf Ihrem Gerät gespeichert ist.
+Die Nutzung der **Zwei-Faktor-Authentifizierung (2FA)** bietet einen zusätzlichen _Sicherheitsfaktor_ für Ihre Online-Konten. 2FA sorgt dafür, dass Ihr Passwort allein nicht reicht, um auf ein Konto zuzugreifen. Am häufigsten ist der zweite Faktor ein zufälliger 6-stelliger Code, bekannt als **zeitbasiertes Einmalpasswort (TOTP)**, auf den Sie über eine Authenticator-App wie Google Authenticator oder Authy zugreifen können. Solche Apps funktionieren als „etwas, das Sie besitzen“-Faktor, da der Seed, der den Zeitcode generiert, auf Ihrem Gerät gespeichert ist.
- Hinweis: SMS-basierte 2FA ist anfällig für SIM Jacking und daher nicht sicher. Für das höchste Maß an Sicherheit nutzen Sie am besten einen Dienst wie Google Authenticator oder Authy.
+ Hinweis: SMS-basierte 2FA ist anfällig für SIM-Jacking und ist nicht sicher. Für die beste Sicherheit verwenden Sie einen Dienst wie Google Authenticator oder Authy.
#### Sicherheitsschlüssel {#security-keys}
-Ein Sicherheitsschlüssel ist eine fortschrittlichere und sicherere Art der 2FA. Sicherheitsschlüssel sind physische Hardware-Authentifizierungsgeräte, die wie Authentifizierungsapps funktionieren. Einen Sicherheitsschlüssel zu verwenden, ist die sicherste Variante der 2FA. Viele dieser Schlüssel verwenden den Standard „FIDO Universal 2nd Factor (U2F)“. [Mehr erfahren über FIDO U2F](https://www.yubico.com/authentication-standards/fido-u2f/).
+Ein Sicherheitsschlüssel ist eine fortschrittlichere und sicherere Art der 2FA. Sicherheitsschlüssel sind physische Hardware-Authentifizierungsgeräte, die wie Authentifizierungsapps funktionieren. Einen Sicherheitsschlüssel zu verwenden, ist die sicherste Variante der 2FA. Viele dieser Schlüssel verwenden den Standard „FIDO Universal 2nd Factor (U2F)“. [Erfahren Sie mehr über FIDO U2F](https://www.yubico.com/resources/glossary/fido-u2f/).
Mehr zur 2FA ansehen:
-### Browsererweiterungen entfernen {#uninstall-browser-extensions}
+### Deinstallieren Sie Browser-Erweiterungen {#uninstall-browser-extensions}
Browsererweiterungen wie Chrome-Erweiterungen oder Add-ons für Firefox können die Browserfunktionalität verbessern, bringen aber auch Risiken mit sich. Standardgemäß fragen die meisten Browsererweiterungen nach dem Zugriff „Website-Daten lesen und ändern“. Damit können Sie mit Ihren Daten fast alles machen. Chrome-Erweiterungen werden eigentlich immer automatisch aktualisiert. Das bedeutet, dass eine bisher sichere Erweiterung zu einem späteren Zeitpunkt eventuell bösartig werden kann. Die meisten Browsererweiterungen versuchen nicht, Ihre Daten zu stehlen. Aber Sie sollten sich darüber im Klaren sein, dass sie das könnten.
@@ -273,30 +276,30 @@ Browsererweiterungen wie Chrome-Erweiterungen oder Add-ons für Firefox können
- Unbenutzte Browsererweiterungen entfernen
- Chrome-Erweiterungen lokal installieren, um die automatische Aktualisierung der Erweiterungen zu stoppen (fortgeschritten)
-[Mehr zu den Risiken von Browsererweiterungen](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/)
+[Mehr zu den Risiken von Browser-Erweiterungen](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/)
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-### Web-Sicherheit {#reading-web-security}
+### Websicherheit {#reading-web-security}
-- [Up to 3 million devices infected by malware-laced Chrome and Edge add-ons](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) (Bis zu 3 Millionen Geräte durch Malware-verseuchte Chrome- und Edge-Add-ons infiziert) – _Dan Goodin_
-- [How to Create a Strong Password — That You Won’t Forget](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) (So erstellen Sie ein starkes Passwort, dass Sie nicht vergessen) – _AVG_
-- [What is a security key?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) (Was ist ein Sicherheitsschlüssel?) – _Coinbase_
+- [Bis zu 3 Millionen Geräte mit Malware-verseuchten Chrome- und Edge-Add-ons infiziert](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) – _Dan Goodin_
+- [Wie man ein starkes Passwort erstellt – das man nicht vergisst](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) – _AVG_
+- [Was ist ein Sicherheitsschlüssel?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) – _Coinbase_
-### Kryptosicherheit {#reading-crypto-security}
+### Krypto-Sicherheit {#reading-crypto-security}
-- [Schützen Sie sich und Ihr Geld](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) - _MyCrypto_
-- [Sicherheitsprobleme in gängiger Krypto-Kommunikationssoftware](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) – _Salus_
-- [Sicherheitshandbuch für Dummies und erfahrene Personen](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) - _MyCrypto_
-- [Kryptosicherheit: Kennwörter und Authentifizierung](https://www.youtube.com/watch?v=m8jlnZuV1i4) - _Andreas M. Antonopoulos_
+- [Schützen Sie sich und Ihr Geld](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) – _MyCrypto_
+- [Sicherheitsprobleme in gängiger Krypto-Kommunikationssoftware](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) – _Salus_
+- [Sicherheitsleitfaden für Dummies und auch für schlaue Leute](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) – _MyCrypto_
+- [Krypto-Sicherheit: Passwörter und Authentifizierung](https://www.youtube.com/watch?v=m8jlnZuV1i4) – _Andreas M. Antonopoulos_
-### Aufklärung über Betrug {#reading-scam-education}
+### Aufklärung über Betrugsmaschen {#reading-scam-education}
-- [Leitfaden: Wie man betrügerische Token erkennt](/guides/how-to-id-scam-tokens/)
-- [Bleiben Sie sicher: gängige Betrugsmaschen](https://support.mycrypto.com/staying-safe/common-scams) - _MyCrypto_
-- [Betrug vermeiden](https://bitcoin.org/en/scams) - _Bitcoin.org_
-- [Twitter-Thread über häufige Phishing-E-Mails und Nachrichten](https://twitter.com/tayvano_/status/1516225457640787969) - _Taylor Monahan_
+- [Anleitung: Wie man Betrugs-Token erkennt](/guides/how-to-id-scam-tokens/)
+- [Sicher bleiben: Häufige Betrugsmaschen](https://support.mycrypto.com/staying-safe/common-scams) – _MyCrypto_
+- [Betrugsmaschen vermeiden](https://bitcoin.org/en/scams) – _Bitcoin.org_
+- [Twitter-Thread zu häufigen Krypto-Phishing-E-Mails und -Nachrichten](https://twitter.com/tayvano_/status/1516225457640787969) – _Taylor Monahan_
diff --git a/public/content/translations/de/smart-contracts/index.md b/public/content/translations/de/smart-contracts/index.md
index 4b2089dbb09..d4e94949277 100644
--- a/public/content/translations/de/smart-contracts/index.md
+++ b/public/content/translations/de/smart-contracts/index.md
@@ -1,16 +1,21 @@
---
title: Smart Contracts
-description: Eine nicht-technische Einführung in Smart Contracts
+metaTitle: "Smart Contracts: Was sie sind und ihre Vorteile"
+description: "Eine nicht-technische Einführung in Smart Contracts"
lang: de
---
# Einführung in Smart Contracts {#introduction-to-smart-contracts}
-Smart Contracts sind die grundlegenden Bausteine der Anwendungsebene von Ethereum. Sie sind Computerprogramme, die auf der [Blockchain](/glossary/#blockchain) gespeichert sind und der „Wenn dies, dann das“-Logik folgen. Sie werden garantiert nach den Regeln ausgeführt, die durch ihren Code definiert sind, die nach der Erstellung nicht mehr geändert werden können.
+
+
+
-Nick Szabo hat den Begriff „Smart Contract" geprägt. Im Jahr 1994 schrieb er eine [Einführung in das Konzept](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html) und 1996 eine [Untersuchung der Möglichkeiten von Smart Contracts](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html).
+Smart Contracts sind die grundlegenden Bausteine der Anwendungsebene von Ethereum. Es handelt sich um Computerprogramme, die auf der [Blockchain](/glossary/#blockchain) gespeichert sind und einer „Wenn dies, dann das“-Logik folgen. Sie werden garantiert gemäß den Regeln ausgeführt, die durch ihren Code definiert sind, welcher nach der Erstellung nicht mehr geändert werden kann.
-Szabo stellte sich einen digitalen Marktplatz vor, auf dem automatische, [kryptografisch sichere](/glossary/#cryptography) Prozesse Transaktionen und Geschäftsfunktionen ermöglichen, ohne dass vertrauenswürdige Vermittlungsinstanzen benötigt werden. Smart Contracts auf Ethereum realisieren eben diese Vision.
+Nick Szabo hat den Begriff „Smart Contract" geprägt. 1994 schrieb er [eine Einführung in das Konzept](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html) und 1996 [eine Untersuchung darüber, was Smart Contracts leisten könnten](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html).
+
+Szabo stellte sich einen digitalen Marktplatz vor, auf dem automatische, [kryptografisch sichere](/glossary/#cryptography) Prozesse Transaktionen und Geschäftsfunktionen ohne vertrauenswürdige Vermittler ermöglichen. Smart Contracts auf Ethereum realisieren eben diese Vision.
Dann sehen Sie sich an, wie Finematics Smart Contracts erklären:
@@ -52,7 +57,7 @@ Herkömmliche Verträge sind mehrdeutig, weil sie von Menschen ausgelegt und umg
Smart Contracts sind nützlich für Prüfungen und die Nachverfolgung. Da sich die Smart Contracts von Ethereum auf einer öffentlichen Blockchain befinden, kann jeder umgehend die Übertragung von Vermögenswerten und weiterer damit verbundenen Informationen nachvollziehen. So können Sie beispielsweise überprüfen, ob jemand Geld an Ihre Adresse geschickt hat.
-## Schutz der Privatsphäre {#privacy-protection}
+## Datenschutz {#privacy-protection}
Smart Contracts schützen zudem Ihre Daten. Da Ethereum ein pseudonymes Netzwerk ist (Transaktionen sind öffentlich an eine eindeutige kryptographische Adresse gebunden, nicht an eine Identität), können Sie Ihre Privatsphäre vor Beobachtern schützen.
@@ -64,19 +69,22 @@ Letztlich können Sie wie bei herkömmlichen Verträgen prüfen, was in einem Sm
Smart Contracts können im Grunde alles, was auch Computerprogramme ausführen können.
-Sie können Berechnungen durchführen, Währungen erstellen, Daten speichern, [NFTs](/glossary/#nft) prägen, Kommunikationen senden und sogar Grafiken generieren. Hier sind einige gängige reale Anwendungen:
+Sie können Berechnungen durchführen, Währungen erstellen, Daten speichern, [NFTs](/glossary/#nft) prägen, Mitteilungen senden und sogar Grafiken generieren. Hier sind einige gängige reale Anwendungen:
- [Stablecoins](/stablecoins/)
-- [Einzigartige digitale Vermögenswerte erstellen und verteilen](/nft/)
+- [Erstellen und Verteilen einzigartiger digitaler Vermögenswerte](/nft/)
- [Ein automatischer, offener Währungsumtausch](/get-eth/#dex)
- [Dezentralisiertes Gaming](/apps/categories/gaming)
- [Eine Versicherungspolice mit automatisierter Auszahlung](https://etherisc.com/)
-- [Ein Standard, der es Menschen ermöglicht, individuelle, interoperable Währungen zu schaffen](/developers/docs/standards/tokens/)
+- [Ein Standard, der es Nutzern ermöglicht, individuelle, interoperable Währungen zu schaffen](/developers/docs/standards/tokens/)
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [So verändern Smart Contracts die Welt](https://www.youtube.com/watch?v=pA6CGuXEKtQ)
-- [Smart Contracts: die Blockchain-Technologie, die Anwälte ersetzen wird](https://blockgeeks.com/guides/smart-contracts/)
+- [Wie Smart Contracts die Welt verändern werden](https://www.youtube.com/watch?v=pA6CGuXEKtQ)
- [Smart Contracts für Entwickler](/developers/docs/smart-contracts/)
-- [Lernen Sie, Smart Contracts zu programmieren](/developers/learning-tools/)
-- [Ethereum-Experte werden – was ist ein Smart Contract?](https://github.com/ethereumbook/ethereumbook/blob/openedition/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract)
+- [Smart Contracts schreiben lernen](/developers/learning-tools/)
+- [Mastering Ethereum – Was ist ein Smart Contract?](https://github.com/ethereumbook/ethereumbook/blob/openedition/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract)
+
+
+
+
diff --git a/public/content/translations/de/social-networks/index.md b/public/content/translations/de/social-networks/index.md
index 04cfcc71f7b..fc9b2ffa397 100644
--- a/public/content/translations/de/social-networks/index.md
+++ b/public/content/translations/de/social-networks/index.md
@@ -1,13 +1,13 @@
---
title: Dezentralisierte soziale Netzwerke
-description: Eine Übersicht über dezentralisierte soziale Netzwerke in der Ethereum-Blockchain
+description: "Eine Übersicht über dezentralisierte soziale Netzwerke in der Ethereum-Blockchain"
lang: de
template: use-cases
emoji: ":mega:"
sidebarDepth: 2
image: /images/ethereum-learn.png
-summaryPoint1: Blockchain-basierte Plattformen für soziale Interaktionen und Content-Erstellung und -Verteilung.
-summaryPoint2: Dezentralisierte Social-Media-Netzwerke schützen die Privatsphäre der Benutzer und erhöhen Datensicherheit.
+summaryPoint1: "Blockchain-basierte Plattformen für soziale Interaktionen und Content-Erstellung und -Verteilung."
+summaryPoint2: "Dezentralisierte Social-Media-Netzwerke schützen die Privatsphäre der Benutzer und erhöhen Datensicherheit."
summaryPoint3: Token und NFTs erschaffen neue Wege zur Monetarisierung von Inhalten.
---
@@ -15,7 +15,7 @@ Soziale Netzwerke spielen in unserer täglichen Kommunikation und Interaktion ei
## Was sind dezentralisierte soziale Netzwerke? {#what-are-decentralized-social-networks}
-Dezentralisierte soziale Netzwerke sind [Blockchain-basierte](/glossary/#blockchain) Plattformen, die es Nutzern ermöglichen, sowohl Informationen auszutauschen, als auch Inhalte zu veröffentlichen und mit Zuschauern zu teilen. Da diese Anwendungen auf der Blockchain laufen, sind sie dezentral und widerstandsfähig gegen Zensur und übermäßige Kontrolle.
+Dezentralisierte soziale Netzwerke sind [Blockchain-basierte](/glossary/#blockchain) Plattformen, die es Nutzern ermöglichen, Informationen auszutauschen sowie Inhalte zu veröffentlichen und zu verbreiten. Da diese Anwendungen auf der Blockchain laufen, sind sie dezentral und widerstandsfähig gegen Zensur und übermäßige Kontrolle.
Viele dezentrale soziale Netzwerke existieren als Alternative zu schon etablierten Social-Media-Diensten wie Facebook, LinkedIn, Twitter und Medium. Aber soziale Netzwerke, die über die Blockchain laufen, verfügen über eine Reihe von Funktionen, die sie traditionellen sozialen Plattformen überlegen machen.
@@ -23,29 +23,29 @@ Viele dezentrale soziale Netzwerke existieren als Alternative zu schon etabliert
### Wie funktionieren dezentralisierte soziale Netzwerke? {#decentralized-social-networks-overview}
-Dezentralisierte soziale Netzwerke sind eine Art von [dezentralisierten Anwendungen (dapps)](/apps/), die mit [Smart Contracts](/glossary/#smart-contract) betrieben werden und auf der Blockchain laufen. Der Vertragscode dient als Backend für diese Apps und definiert ihre Geschäftslogik.
+Dezentralisierte soziale Netzwerke sind eine Klasse von [dezentralisierten Anwendungen (Dapps)](/apps/) – Anwendungen, die von [Smart Contracts](/glossary/#smart-contract) angetrieben werden, die auf der Blockchain bereitgestellt werden. Der Vertragscode dient als Backend für diese Apps und definiert ihre Geschäftslogik.
-Traditionelle Social-Media-Plattformen basieren auf Datenbanken, um Benutzerinformationen, Programm-Code und andere Datenformen zu speichern. Dies jedoch führt zu immensen Risiken, da diese Systeme Einzelfehlerpunkte haben. Zum Beispiel sind Facebooks Server berüchtigt dafür, im Oktober 2021 [stundenlang offline gegangen zu sein](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact), was Nutzer von der Plattform abschnitt.
+Traditionelle Social-Media-Plattformen basieren auf Datenbanken, um Benutzerinformationen, Programm-Code und andere Datenformen zu speichern. Dies jedoch führt zu immensen Risiken, da diese Systeme Einzelfehlerpunkte haben. Zum Beispiel waren die Server von Facebook im Oktober 2021 bekanntermaßen [stundenlang offline](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact), wodurch die Nutzer von der Plattform abgeschnitten wurden.
-Dezentralisierte soziale Netzwerke existieren auf einem [Peer-to-Peer-Netzwerk](/glossary/#peer-to-peer-network), was weltweit Tausende Knoten umfasst. Selbst wenn einige dieser Knoten brechen, kann das Netzwerk weiterlaufen, daher sind Anwendungen gegen Ausfälle resistenter.
+Dezentralisierte soziale Netzwerke existieren in einem [Peer-to-Peer-Netzwerk](/glossary/#peer-to-peer-network), das aus Tausenden von Nodes auf der ganzen Welt besteht. Selbst wenn einige dieser Knoten brechen, kann das Netzwerk weiterlaufen, daher sind Anwendungen gegen Ausfälle resistenter.
-Mit der Verwendung von dezentralisierten Speichersystemen, wie [dem InterPlanetary File System (IPFS)](https://ipfs.io/), können soziale Netzwerke, die auf Ethereum aufgebaut sind, Benutzerinformationen vor Ausbeutung und böswilliger Nutzung schützen. Niemand wird Ihre persönlichen Informationen an Werbetreibende verkaufen, ebenso wenig können Hacker Ihre vertraulichen Daten stehlen.
+Durch die Nutzung dezentraler Speichersysteme wie dem [InterPlanetary File System (IPFS)](https://ipfs.io/) können auf Ethereum basierende soziale Netzwerke Nutzerinformationen vor Ausbeutung und böswilliger Verwendung schützen. Niemand wird Ihre persönlichen Informationen an Werbetreibende verkaufen, ebenso wenig können Hacker Ihre vertraulichen Daten stehlen.
Viele Blockchain-basierte soziale Plattformen haben native Token, die die Monetarisierung ohne Werbeeinnahmen antreiben. Benutzer können diese Token kaufen, um auf bestimmte Funktionen zugreifen zu können, In-App-Käufe abzuschließen oder ihre liebsten Content-Ersteller zu unterstützen.
## Vorteile dezentralisierter sozialer Netzwerke {#benefits}
-1. Dezentralisierte soziale Netzwerke sind zensurresistent und offen für alle. Dies bedeutet, dass **Nutzer nicht gebannt**, von der Plattform ausgeschlossen oder willkürlich eingeschränkt werden können.
+1. Dezentralisierte soziale Netzwerke sind zensurresistent und offen für alle. Das bedeutet, dass **Nutzer nicht willkürlich gesperrt**, von der Plattform entfernt oder eingeschränkt werden können.
-2. Dezentralisierte soziale Netzwerke **bauen auf Open Source-Idealen auf** und machen den Quelltext für Applikationen frei zugänglich für öffentliche Einsichtnahme. Durch die Abschaffung der Implementation von nicht-transparenten Algorithmen, die bei traditionellen Social Media üblich sind, können Blockchain-basierte soziale Netzwerke die Interessen von Benutzern und Erstellern verbinden.
+2. Dezentralisierte soziale Netzwerke **bauen auf Open-Source-Idealen auf** und stellen den Quellcode für Anwendungen zur öffentlichen Einsichtnahme zur Verfügung. Durch die Abschaffung der Implementation von nicht-transparenten Algorithmen, die bei traditionellen Social Media üblich sind, können Blockchain-basierte soziale Netzwerke die Interessen von Benutzern und Erstellern verbinden.
-3. Dezentralisierte soziale Netzwerke eliminieren somit den „Zwischenhändler". Content **Creator sind die direkten Eigentümer ihrer Inhalte** und interagieren direkt mit ihren Followern, Fans, Käufern und anderen Gruppen mit nichts als einem Smart Contract dazwischen.
+3. Dezentralisierte soziale Netzwerke eliminieren somit den „Zwischenhändler". Content-**Ersteller haben das direkte Eigentum an ihren Inhalten** und treten direkt mit Followern, Fans, Käufern und anderen Parteien in Kontakt, wobei nur ein Smart Contract dazwischen liegt.
-4. Da DApps auf dem Ethereum-Netzwerk laufen, welches durch ein globales Peer-to-Peer-Netzwerk von Knoten aufrechterhalten wird, sind dezentralisierte soziale Netzwerke **weniger anfällig für Serverausfälle**.
+4. Als Dapps, die im Ethereum-Netzwerk laufen, das von einem globalen Peer-to-Peer-Netzwerk von Nodes getragen wird, sind dezentrale soziale Netzwerke **weniger anfällig für Serverausfallzeiten** und Störungen.
-5. Dezentralisierte soziale Plattformen bieten einen **verbesserten Monetarisierungs**-Rahmen für Content Creator durch [nicht-austauschbare Token (NFTs)](/glossary/#nft), in-App-Kryptozahlungen und vieles mehr.
+5. Dezentralisierte soziale Plattformen bieten einen **verbesserten Monetarisierungsrahmen** für Content-Ersteller über [nicht-fungible Token (NFTs)](/glossary/#nft), In-App-Kryptozahlungen und mehr.
-6. Dezentralisierte soziale Netzwerke bieten Nutzern **ein hohes Level an Privatsphäre und Anonymität**. Zum Beispiel kann sich eine Einzelperson bei einem Ethereum-basierten sozialen Netzwerk mit einem [ENS](/glossary/#ens)-Profil oder -[Wallet](/glossary/#wallet) anmelden — ohne persönlich identifizierbare Informationen (PII), wie Namen, E-Mail-Adressen, etc. angeben zu müssen.
+6. Dezentralisierte soziale Netzwerke bieten den Nutzern **ein hohes Maß an Privatsphäre und Anonymität**. Zum Beispiel kann sich eine Person bei einem Ethereum-basierten sozialen Netzwerk mit einem [ENS](/glossary/#ens)-Profil oder einer [Wallet](/glossary/#wallet) anmelden, ohne personenbezogene Daten (PII) wie Namen, E-Mail-Adressen usw. teilen zu müssen.
7. Dezentralisierte soziale Netzwerke basieren auf dezentralisierter Speicherung und nicht auf zentralisierten Datenbanken, die wesentlich besser für die Sicherung von Benutzerdaten sind.
@@ -55,52 +55,86 @@ Das Ethereum-Netzwerk ist aufgrund der Beliebtheit seiner Tokens und seiner gro
### Mirror {#mirror}
-[Mirror](https://mirror.xyz/) ist eine web3-fähige Schreib-Plattform. Sie soll dezentralisiert sein und den Benutzern gehören. Benutzer können kostenlos auf Mirror lesen und schreiben, indem sie einfach ihre Wallets verbinden. Benutzer können auch Abfassungen sammeln und ihre Lieblingsschriftsteller abonnieren.
+[Mirror](https://mirror.xyz/) ist eine Web3-fähige Schreibplattform, die darauf abzielt, dezentralisiert und nutzereigen zu sein. Benutzer können kostenlos auf Mirror lesen und schreiben, indem sie einfach ihre Wallets verbinden. Benutzer können auch Abfassungen sammeln und ihre Lieblingsschriftsteller abonnieren.
-Auf Mirror veröffentlichte Beiträge werden dauerhaft auf Arweave, einer dezentralen Speicherplattform, gespeichert und können als Sammlerstücke [nicht-fungible Token (NFTs)](/nft/) mit dem Namen „Writing NFTs" geprägt werden. Writing NFTs können komplett kostenlos von Autoren kreiert werden und das Sammeln findet auf einer Ethereum-[L2](/glossary/#layer-2) statt — wodurch Transaktionen günstig, schnell und umweltfreundlich sind.
+Auf Mirror veröffentlichte Beiträge werden dauerhaft auf Arweave, einer dezentralen Speicherplattform, gespeichert und können als sammelbare [nicht-fungible Token (NFTs)](/nft/), bekannt als Writing NFTs, geprägt werden. Writing NFTs können von Autoren völlig kostenlos erstellt werden, und die Sammlung findet auf einer Ethereum-[L2](/glossary/#layer-2) statt – was Transaktionen kostengünstig, schnell und umweltfreundlich macht.
### MINDS {#minds}
-[MINDS](https://www.minds.com/) ist eines der am häufigsten genutzten dezentralisierten sozialen Netzwerke. Es funktioniert wie Facebook und hat bereits Millionen von Benutzern gewonnen.
+[MINDS](https://www.minds.com/) ist eines der meistgenutzten dezentralen sozialen Netzwerke. Es funktioniert wie Facebook und hat bereits Millionen von Benutzern gewonnen.
-Nutzer verwenden die plattformeigenen [ERC-20](/glossary/#erc-20) Token $MIND, um für Produkte zu bezahlen. Benutzer können außerdem $MIND-Token verdienen, indem sie populäre Inhalte veröffentlichen, zum Ökosystem beitragen und andere auf die Plattform verweisen.
+Nutzer verwenden den nativen [ERC-20](/glossary/#erc-20)-Token $MIND der Plattform, um für Artikel zu bezahlen. Benutzer können außerdem $MIND-Token verdienen, indem sie populäre Inhalte veröffentlichen, zum Ökosystem beitragen und andere auf die Plattform verweisen.
-## Nutzen Sie dezentralisierte soziale Netzwerke {#use-decentralized-social-networks}
+### Farcaster {#farcaster}
-- **[Status.im](https://status.im/)** - _Status ist eine sichere Messaging-App, die quelloffen ist und Peer-to-Peer-Protokolle sowie Ende-zu-Ende-Verschlüsselung verwendet, um Ihre Nachrichten vor Dritten zu schützen._
-- **[Mirror.xyz](https://mirror.xyz/)** - _Mirror ist eine dezentralisierte, eigene Publishing-Plattform basierend auf Ethereum, die hilft, Ideen zu finanzieren, Inhalte zu monetarisieren und wertvolle Communitys aufzubauen._
-- **[Lens Protocol](https://lens.xyz/)** - _Lens Protocol ist ein zusammengesetztes und dezentralisiertes soziales Diagramm, welches Erstellern dabei hilft, das Eigentumsrecht ihres Inhalts zu behalten/zu übernehmen._
-- **[Farcaster](https://farcaster.xyz/)** - _Farcaster ist ein ausreichend dezentralisiertes soziales Netzwerk. Es ist ein offenes Protokoll, das viele Clients unterstützen kann, genau wie E-Mail._
+[Farcaster](https://farcaster.xyz/) ist ein „ausreichend dezentralisiertes“ soziales Netzwerk, ähnlich wie X und Reddit, das es den Nutzern ermöglicht, „Casts“ zu teilen und zu entdecken. Es ist auf dem Optimism L2-Netzwerk aufgebaut, um die Transaktionen relativ günstig zu halten.
-## Soziale Web2-Netzwerke auf Ethereum {#web2-social-networks-and-ethereum}
+## Nutzen Sie dezentrale soziale Netzwerke {#use-decentralized-social-networks}
-Native soziale [Web3](/glossary/#web3)-Plattformen sind nicht die einzigen, die versichern, Blockchain--Technologien in Social Media zu integrieren. Viele zentralisierte Plattformen planen auch, Ethereum in ihre Infrastruktur zu integrieren:
+- **[Status.app](https://status.app/)** – _Status ist eine sichere Messaging-App, die ein quelloffenes Peer-to-Peer-Protokoll und eine Ende-zu-Ende-Verschlüsselung verwendet, um Ihre Nachrichten vor Dritten zu schützen._
+- **[Mirror.xyz](https://mirror.xyz/)** – _Mirror ist eine dezentrale, nutzereigene Publishing-Plattform, die auf Ethereum aufbaut, damit Nutzer Ideen per Crowdfunding finanzieren, Inhalte monetarisieren und hochwertige Gemeinschaften aufbauen können._
+- **[Lens Protocol](https://lens.xyz/)** – _Das Lens Protocol ist ein zusammensetzbarer und dezentraler sozialer Graph, der Erstellern hilft, das Eigentum an ihren Inhalten zu behalten, wo auch immer sie sich im digitalen Garten des dezentralen Internets bewegen._
+- **[Farcaster](https://farcaster.xyz/)** – _Farcaster ist ein ausreichend dezentralisiertes soziales Netzwerk. Es ist ein offenes Protokoll, das viele Clients unterstützen kann, genau wie E-Mail._
+- **[Ethereum Follow Protocol](https://efp.app/)** – _Das Ethereum Follow Protocol ist ein vollständig dezentralisierter Onchain-Social-Graph für Ethereum-Konten, der die Vision eines modularen Ethereum-Identitäts-Stacks vorantreibt und ENS und SIWE ergänzt._
+- **[Ethereum Comments Protocol](https://www.ethcomments.xyz/)** – _Ein neues, programmierbares Primitiv für soziale Inhalte auf Ethereum, um deine Gedanken onchain zu bringen._
-### Reddit {#reddit}
+## Web2-soziale Netzwerke auf Ethereum {#web2-social-networks-and-ethereum}
-Reddit [bietet Community Points an](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users), welche ERC-20 Token sind, die Nutzer verdienen können, indem sie qualitative Inhalte posten und zu Online-Gemeinschaften (Subreddits) beitragen. Man kann diese Token innerhalb eines Subreddits verdienen, um exklusive Privilegien zu erhalten. Bei diesem Projekt arbeitet Reddit mit Arbitrum, einem [Layer 2](/glossary/#layer-2)-Netzwerk, zusammen, dass Ethereum-Transaktionen skaliert.
+Native soziale [Web3](/glossary/#web3)-Plattformen sind nicht die einzigen, die versuchen, die Blockchain-Technologie in soziale Medien zu integrieren. Viele zentralisierte Plattformen untersuchen derzeit die Integration von Ethereum in ihre Infrastruktur oder haben bereits damit experimentiert:
-Das Programm ist bereits im Subreddit r/CryptoCurrency aktiv, [diese Version läuft mit ihrer Version von Community-Punkten namens "Moons"](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki). Gemäß der offiziellen Beschreibung belohnen Moons "Plakate, Kommentatoren und Moderatoren für deren Beiträge zum Subreddit". Da diese Token auf der Blockchain sind (Benutzer erhalten sie in Wallets), sind sie unabhängig von Reddit und können nicht entfernt werden.
+### Brave Browser {#brave}
-Neben der Verwendung von Community-Punkten zum Freischalten spezieller Funktionen können Nutzer sie auch auf Börsen gegen Papierwährung tauschen. Außerdem bestimmt die Anzahl der Community-Punkte, die ein Benutzer besitzt, seinen Einfluss auf den Entscheidungsprozess innerhalb der Community.
+- Brave hat den **[Basic Attention Token (BAT)](https://basicattentiontoken.org/)**, einen auf Ethereum basierenden ERC-20-Token, in sein Browser-Ökosystem integriert, um die digitale Werbung und die Unterstützung von Content-Erstellern zu revolutionieren.
-## Weiterführende Informationen {#further-reading}
+- Das **[Brave Rewards-Programm](https://brave.com/brave-rewards/)** ermöglicht es Nutzern, BAT zu verdienen, indem sie datenschutzfreundliche Werbung ansehen und dann basierend auf der Aufmerksamkeitsdauer automatisch an Websites und Content-Ersteller auf verschiedenen Plattformen wie YouTube, Twitter und GitHub spenden.
+
+- Content-Ersteller können sich als **[verifizierte Brave-Ersteller](https://creators.brave.com/)** registrieren, um diese Beiträge direkt in ihren Ethereum-Wallets zu erhalten, was eine Brücke zwischen traditionellen Web-Plattformen und der Blockchain-basierten Monetarisierung schlägt.
+
+- BAT-Token existieren unabhängig auf der Ethereum-Blockchain, sodass Nutzer sie, sobald sie verdient wurden, auf persönliche Wallets oder Börsen übertragen können.
+
+### Audius Musikplattform {#audius}
+
+- **[Audius](https://audius.co/)** ist eine Musik-Streaming-Plattform, die die Ethereum-Blockchain-Technologie nutzt, um Künstler direkt mit ihren Fans zu verbinden.
+
+- Die Plattform verfügt über eine hybride dezentrale Architektur, bei der die Inhalte auf IPFS gespeichert werden, während die Blockchain für Eigentumsrechte und den **[AUDIO-Token](https://eth.blockscout.com/token/0x18aaa7115705e8be94bffebde57af9bfc265b998)** genutzt wird.
+
+- Audius ist eine **[Partnerschaft mit TikTok](https://audius.co/tiktok)** eingegangen, wodurch die Web3-Funktionalität einem breiten Publikum zugänglich gemacht wird und Künstler ihre Inhalte durch Blockchain-Technologie monetarisieren können.
+
+- Die technischen Details der Plattform sind in ihrem **[Whitepaper](https://whitepaper.audius.co/)** verfügbar, das zeigt, wie sie auf der Infrastruktur von Ethereum aufbauen.
+
+### Sorare Fantasy Sports {#sorare}
+
+- **[Sorare](https://sorare.com/)** ist eine **[Fantasy-Sport-Plattform, die auf Ethereum aufbaut](https://sorare.com/help/a/4402888626577/what-is-a-sorare-wallet)**, die es Nutzern ermöglicht, offizielle NFT-Spielerkarten zu sammeln, zu handeln und mit ihnen zu spielen.
+
+- Die Spielerkarten sind verifizierbare NFTs auf der Ethereum-Blockchain, und die Smart Contracts der Plattform können auf **[Etherscan](https://eth.blockscout.com/address/0x629a673a8242c2ac4b7b8c5d8735fbeac21a6205?tab=contract)** eingesehen werden.
+
+- Sorare kombiniert traditionelles Fantasy-Sport-Gameplay mit dem Blockchain-Eigentum an digitalen Vermögenswerten und macht die Funktionalität zur **[Finanzierung über Ethereum](https://sorare.com/help/a/10969733392797/what-network-should-i-use-to-fund-my-eth-wallet)** für Mainstream-Sportfans zugänglich.
+
+### Twitter/X (Krypto-Trinkgelder) {#twitter}
+
+**[Twitter](https://x.com)** (jetzt X) hat die Blockchain-Technologie auf verschiedene Weisen integriert, um die Monetarisierung für Ersteller und die Verifizierung der digitalen Identität zu verbessern:
+
+- **Krypto-Trinkgelder**: Die Plattform hat die **[Trinkgeldfunktion für Ethereum](https://help.x.com/en/using-x/tips)** integriert, die es Nutzern ermöglicht, Zahlungen über Ethereum-basierte Wallets wie Strike zu senden.
+
+Durch die Integration von Blockchain-Funktionen überbrückt X die Lücke zwischen den sozialen Web2-Erlebnissen und dezentralisiertem digitalen Eigentum.
+
+## Weiterführende Lektüre {#further-reading}
### Artikel {#articles}
-- [Dezentralisierung sozialer Medien: eine Anleitung zum Web3 Social Stack](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_
-- [Soziale Netzwerke sind die nächste große Dezentralisierungsmöglichkeit](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Ben Goertzel_
-- [Web3 verspricht dezentralisierte, Community-betriebene soziale Netzwerke](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_
-- [Eine Übersicht über die Social-Media-Landschaft auf der Blockchain](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_
-- [Wie Blockchain den Schutz der Privatsphäre in Social Media ermöglicht](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_
-- [Ausreichende Dezentralisierung für soziale Netzwerke](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_
+- [Dezentralisierung sozialer Medien: ein Leitfaden zum Web3 Social Stack](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) – _Coinbase Ventures_
+- [Soziale Netzwerke sind die nächste große Chance für die Dezentralisierung](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) – _Ben Goertzel_
+- [Web3 birgt das Versprechen dezentraler, von der Community betriebener sozialer Netzwerke](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) – _Sumit Ghosh_
+- [Ein Überblick über die Blockchain-Social-Media-Landschaft](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) – _Gemini Cryptopedia_
+- [Wie die Blockchain das Datenschutzproblem in sozialen Medien lösen kann](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) – _Prableen Bajpai_
+- [Ausreichende Dezentralisierung für soziale Netzwerke](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) – _Varun Srinivasan_
### Videos {#videos}
-- [Dezentralisierte Social Media erklärt](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_
-- [DeSo Blockchain möchte Social Media dezentralisieren](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_
-- [Die Zukunft von dezentralisierten Social Media mit Balaji Srinivasan, Vitalik Buterin, Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_
+- [Dezentrale soziale Medien erklärt](https://www.youtube.com/watch?v=UdT2lpcGvcQ) – _Coinmarketcap_
+- [DeSo Blockchain will soziale Medien dezentralisieren](https://www.youtube.com/watch?v=SG2HUiVp0rE) – _Bloomberg Technology_
+- [Die Zukunft der dezentralen sozialen Medien mit Balaji Srinivasan, Vitalik Buterin, Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) – _ETHGlobal_
-### Communities {#communities}
+### Communitys {#communities}
-- [r/Kryptowährung-Subreddit](https://www.reddit.com/r/CryptoCurrency/)
+- [r/CryptoCurrency Subreddit](https://www.reddit.com/r/CryptoCurrency/)
diff --git a/public/content/translations/de/staking/dvt/index.md b/public/content/translations/de/staking/dvt/index.md
index 92096849b7b..9c848501488 100644
--- a/public/content/translations/de/staking/dvt/index.md
+++ b/public/content/translations/de/staking/dvt/index.md
@@ -1,16 +1,16 @@
---
title: Verteilte Validierungstechnologie (VVT)
-description: Verteilte Validierungstechnologie (VVT) ermöglicht den verteilten Betrieb eines Ethereum-Validators durch mehrere Parteien.
+description: "Verteilte Validierungstechnologie (VVT) ermöglicht den verteilten Betrieb eines Ethereum-Validators durch mehrere Parteien."
lang: de
---
-# Verteilte Validierungstechnologie (VVT) {#distributed-validator-technology}
+# Verteilte Validator-Technologie {#distributed-validator-technology}
Verteilte Validatortechnologie (VVT) ist ein Ansatz zur Sicherheit für Validatoren, bei dem die Verwaltung von Schlüsseln und die Verantwortlichkeit für Unterschriften auf mehrere Parteien verteilt wird, um einzelne Fehler zu reduzieren und die Belastbarkeit des Validators zu erhöhen.
-Das geschieht durch die **Aufteilung des privaten Schlüssels**, der zur Absicherung eines Validators verwendet wird, **über viele Computer hinweg**, die in einem "Cluster" organisiert sind. Der Vorteil dabei: Für Angreifer wird es äußerst schwierig, Zugriff auf den Schlüssel zu erlangen, da er nicht vollständig auf einer einzigen Maschine gespeichert ist. Es ermöglicht auch, dass einige Knoten offline gehen können, da die erforderliche Signierung von einer Teilmenge der Maschinen in jedem Cluster durchgeführt werden kann. Das reduziert einzelne Fehlerpunkte im Netzwerk und macht das gesamte Validator-Set robuster.
+Dies geschieht durch die **Aufteilung des privaten Schlüssels**, der zur Absicherung eines Validators verwendet wird, **auf viele Computer**, die in einem "Cluster" organisiert sind. Der Vorteil dabei: Für Angreifer wird es äußerst schwierig, Zugriff auf den Schlüssel zu erlangen, da er nicht vollständig auf einer einzigen Maschine gespeichert ist. Es ermöglicht auch, dass einige Knoten offline gehen können, da die erforderliche Signierung von einer Teilmenge der Maschinen in jedem Cluster durchgeführt werden kann. Das reduziert einzelne Fehlerpunkte im Netzwerk und macht das gesamte Validator-Set robuster.
-
+
## Wofür ist VVT erforderlich? {#why-do-we-need-dvt}
@@ -20,7 +20,7 @@ Die Validatoren generieren sowohl zwei öffentliche als auch private Schlüsselp
Durch die Verwendung von VVT können Staker am Staking teilnehmen, während sie den privaten Schlüssel des Validators im Offline-Speicher (Cold Storage) aufbewahren. Erreicht wird das, indem der ursprüngliche, vollständige Validator-Schlüssel verschlüsselt und dann in Schlüsselteile aufgeteilt wird. Die Schlüsselteile sind online und werden an mehrere Knoten verteilt, was den verteilten Betrieb des Validators ermöglicht. Das ist möglich, weil Ethereum-Validatoren BLS-Signaturen verwenden, die additiv sind, d. h. der vollständige Schlüssel kann rekonstruiert werden, indem ihre Bestandteile zusammengefügt werden. So kann der Staker den vollständigen, ursprünglichen "Master"-Validator-Schlüssel sicher offline aufbewahren.
-### Kein einzelner Ausfallpunkt {#no-single-point-of-failure}
+### Keine einzelnen Ausfallpunkte {#no-single-point-of-failure}
Wenn ein Validator auf mehrere Operatoren und Maschinen verteilt ist, kann er einzelne Hardware- und Softwareausfälle überstehen, ohne offline zu gehen. Das Ausfallrisiko kann außerdem durch den Einsatz unterschiedlicher Hardware- und Softwarekonfigurationen über Knotenpunkte in einem Cluster gesenkt werden. Diese Ausfallsicherheit ist für Konfigurationen mit nur einem Knotenpunkt nicht verfügbar – sie bedingt sich durch die DVT-Schicht.
@@ -34,27 +34,27 @@ Ohne VVT ist es für Staking-Anbieter einfacher, nur eine oder zwei Client-Konfi
**VVT bietet für Ethereum folgende Vorteile:**
-1. **Dezentralisierung** von Ethereums Proof-of-Stake-Konsens
-2. Sichert den **aktiven Status** des Netzwerks
+1. **Dezentralisierung** des Proof-of-Stake-Konsens von Ethereum
+2. Gewährleistet die **Betriebsbereitschaft** des Netzwerks
3. Schafft **Fehlertoleranz** für Validatoren
-4. **Minimiertes Vertrauen** beim Betrieb von Validatoren
-5. **Weniger Slashing** und Risiko von Ausfallzeiten
-6. **Verbesserte Vielfalt** (Client, Datenzentrum, Standort, Regulierung, etc.)
-7. **Erhöhte Sicherheit** bei der Verwaltung von Validatorschlüsseln
+4. **Vertrauensminimierter** Validator-Betrieb
+5. **Minimiertes Slashing-** und Ausfallzeitenrisiko
+6. **Verbesserte Vielfalt** (Client, Rechenzentrum, Standort, Regulierung usw.)
+7. **Erhöhte Sicherheit** bei der Verwaltung von Validator-Schlüsseln
## Wie funktioniert VVT? {#how-does-dvt-work}
Ein VVT-Lösungsansatz beinhaltet folgende Komponenten:
-- **[Shamir's geheimes Teilen](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - Validatoren nutzen [BLS Schlüssel](https://en.wikipedia.org/wiki/BLS_digital_signature). Individuelle BLS-"Anteile eines Schlüssels" ("Schlüsselanteile") können kombiniert werden zu einem einzigen vereinigten Schlüssel (Signatur). Bei VVT ist der private Schlüssel für einen Validator die kombinierte BLS-Signatur jedes Operators im Cluster.
-- **[Schwellenwert eines Signatur-Schemas](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** – Bestimmt die Anzahl der einzelnen Schlüsselanteile, die für Signieraufgaben erforderlich sind, z. B. 3 von 4.
-- **[Verteilte Schlüsselgenerierung (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** – Kryptografischer Prozess, der die Schlüsselteile generiert und dazu dient, die Teile eines bestehenden oder neuen Validatorschlüssels an die Knoten in einem Cluster zu verteilen.
-- **[Mehrparteienberechnung (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** – Der vollständige Validierungsschlüssel wird im Geheimen mithilfe einer Mehrparteienberechnung generiert. Der vollständige Schlüssel ist keinem einzelnen Betreiber bekannt – sie kennen immer nur ihren eigenen Teil (ihren "Anteil").
+- **[Shamir's Secret Sharing](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** – Validatoren verwenden [BLS-Schlüssel](https://en.wikipedia.org/wiki/BLS_digital_signature). Individuelle BLS-"Anteile eines Schlüssels" ("Schlüsselanteile") können kombiniert werden zu einem einzigen vereinigten Schlüssel (Signatur). Bei VVT ist der private Schlüssel für einen Validator die kombinierte BLS-Signatur jedes Operators im Cluster.
+- **[Schwellenwert-Signaturschema](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** – Bestimmt die Anzahl der einzelnen Schlüsselanteile, die für Signieraufgaben erforderlich sind, z. B. 3 von 4.
+- **[Verteilte Schlüsselgenerierung (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** – Kryptografischer Prozess, der die Schlüsselanteile generiert und dazu dient, die Anteile eines bestehenden oder neuen Validator-Schlüssels an die Knoten in einem Cluster zu verteilen.
+- **[Mehrparteienberechnung (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** – Der vollständige Validator-Schlüssel wird mithilfe von Mehrparteienberechnung im Geheimen generiert. Der vollständige Schlüssel ist keinem einzelnen Betreiber bekannt – sie kennen immer nur ihren eigenen Teil (ihren "Anteil").
- **Konsensprotokoll** – Das Konsensprotokoll wählt einen Knoten aus, der den Block vorschlägt. Sie teilen den Block mit den anderen Knoten des Clusters, die ihre Schlüsselteile zur Gesamtsignatur hinzufügen. Wenn ausreichend Schlüsselteile zusammengekommen sind, wird der Block auf Ethereum vorgeschlagen.
Verteilte Validatoren verfügen über eine eingebaute Fehlertoleranz und können selbst dann weiterarbeiten, wenn einige der einzelnen Knoten offline gehen. Das bedeutet, dass der Cluster selbst dann belastbar ist, wenn sich einige der Knoten darin als böswillig oder träge erweisen.
-## Anwendungsfälle von VVT {#dvt-use-cases}
+## DVT-Anwendungsfälle {#dvt-use-cases}
VVT hat erhebliche Auswirkungen auf die breite Staking-Branche:
@@ -68,24 +68,24 @@ Betreiber (zum Beispiel Staking-Gemeinschaften (Staking Pools) und institutionel
VVT verteilt die Verantwortung der Schlüsselverwaltung auf mehrere Knoten. So kann ein Teil der operativen Kosten geteilt werden. VVT kann zudem sowohl das Risiko als auch die Versicherungskosten für Staking-Anbieter verringern.
-### Staking-Pool {#staking-pools}
+### Staking-Pools {#staking-pools}
Aufgrund von Standard-Validatoren sind Staking-Pools und Anbieter von Liquid Staking gezwungen, einzelen Betreibern in unterschiedlichem Maße Vertrauen entgegen zu bringen, da Gewinne und Verluste im gesamten Pool sozialisiert werden. Außerdem sind sie auf die Betreiber angewiesen, um die Signaturschlüssel zu sichern, da bis dato keine alternative Möglichkeit dazu bestand.
Auch wenn seit jeher versucht wird, das Risiko zu streuen, indem die Anteile auf mehrere Betreiber verteilt werden, verwaltet jeder Betreiber nach wie vor einen erheblichen Anteil unabhängig. Sich auf einen einzigen Betreiber zu verlassen, birgt immense Risiken, wenn dieser nicht die gewünschten Leistungen erbringt, Ausfallzeiten hat, kompromittiert wird oder mit böswilligen Absichten agiert.
-Durch den Einsatz von VVT ist es in geringerem Umfang erforderlich, den Betreibern zu vertrauen. **Pools können es den Betreibern ermöglichen, Einsätze zu halten, ohne dass sie die Schlüssel der Validatoren verwahren müssen** (da nur Schlüsselanteile verwendet werden). Außerdem können verwaltete Einsätze auf mehrere Betreiber verteilt werden (z. B. kann ein einzelner Betreiber 1000 Validatoren verwalten, während diese Validatoren von mehreren Betreibern gemeinsam betrieben werden). Verschiedene Betreiberkonfigurationen stellen sicher, dass im Falle des Ausfalls eines Betreibers die anderen noch in der Lage sind, die Bescheinigung auszustellen. Das steigert Redundanz und Diversifizierung, die zu einer besseren Leistung und Widerstandsfähigkeit führt und gleichzeitig die Erträge maximiert.
+Durch den Einsatz von VVT ist es in geringerem Umfang erforderlich, den Betreibern zu vertrauen. **Pools können es Betreibern ermöglichen, Stakes zu halten, ohne die Validator-Schlüssel verwahren zu müssen** (da nur Schlüsselanteile genutzt werden). Außerdem können verwaltete Einsätze auf mehrere Betreiber verteilt werden (z. B. kann ein einzelner Betreiber 1000 Validatoren verwalten, während diese Validatoren von mehreren Betreibern gemeinsam betrieben werden). Verschiedene Betreiberkonfigurationen stellen sicher, dass im Falle des Ausfalls eines Betreibers die anderen noch in der Lage sind, die Bescheinigung auszustellen. Das steigert Redundanz und Diversifizierung, die zu einer besseren Leistung und Widerstandsfähigkeit führt und gleichzeitig die Erträge maximiert.
Ein weiterer Vorteil, einem einzelnen Betreiber weniger vertrauen zu müssen, besteht darin, dass Staking-Pools eine offenere und genehmigungsfreie Teilnahme von Betreibern ermöglichen können. Auf diese Weise können Dienste ihr Risiko reduzieren und die Dezentralisierung von Ethereum unterstützen, indem sie sowohl kuratierte als auch genehmigungsfreie Gruppen von Betreibern verwenden, z. B. durch die Verbindung von Home- oder kleineren Stakern mit größeren.
-## Mögliche Nachteile der Verwendung von DVT {#potential-drawbacks-of-using-dvt}
+## Mögliche Nachteile der DVT-Nutzung {#potential-drawbacks-of-using-dvt}
-- **Zusätzliche Komponente** – mit der Einführung eines VVT-Knotens wird ein weiteres Teil hinzugefügt, das möglicherweise fehlerhaft oder anfällig sein kann. Eine Möglichkeit, das abzumildern, besteht darin, mehrere Implementierungen eines VVT-Knotens anzustreben, d. h. mehrere VVT-Clients (ähnlich wie es mehrere Clients für die Konsens- und Ausführungsebene gibt).
-- **Operative Kosten** – da VVT den Validator auf mehrere Parteien verteilt, sind mehr Knoten für den Betrieb erforderlich als nur ein einziger Knoten und das bedingt höhere Betriebskosten.
-- **Potenziell erhöhte Latenzzeit** – da VVT ein Konsensprotokoll verwendet, um einen Konsens zwischen mehreren Knoten zu erreichen, die einen Validator betreiben, kann es potenziell zu einer erhöhten Latenzzeit kommen.
+- **Zusätzliche Komponente** – Die Einführung eines DVT-Knotens fügt eine weitere Komponente hinzu, die fehlerhaft oder anfällig sein kann. Eine Möglichkeit, das abzumildern, besteht darin, mehrere Implementierungen eines VVT-Knotens anzustreben, d. h. mehrere VVT-Clients (ähnlich wie es mehrere Clients für die Konsens- und Ausführungsebene gibt).
+- **Betriebskosten** – Da DVT den Validator auf mehrere Parteien verteilt, sind für den Betrieb mehr Knoten als nur ein einziger erforderlich, was zu erhöhten Betriebskosten führt.
+- **Potenziell erhöhte Latenz** – Da DVT ein Konsensprotokoll verwendet, um einen Konsens zwischen den mehreren Knoten zu erreichen, die einen Validator betreiben, kann dies potenziell zu einer erhöhten Latenz führen.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Spezifikationen der verteilten Ethereum-Validatoren (hohe Stufe)](https://github.com/ethereum/distributed-validator-specs)
-- [Technische Daten der verteilten Ethereum-Validatoren](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec)
-- [Shamir secret sharing – Demo-App](https://iancoleman.io/shamir/)
+- [Spezifikationen für verteilte Ethereum-Validatoren (allgemein)](https://github.com/ethereum/distributed-validator-specs)
+- [Technische Spezifikationen für verteilte Ethereum-Validatoren](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec)
+- [Shamir Secret Sharing Demo-App](https://iancoleman.io/shamir/)
diff --git a/public/content/translations/de/staking/pools/index.md b/public/content/translations/de/staking/pools/index.md
index 2a84f857034..9559d5db6c9 100644
--- a/public/content/translations/de/staking/pools/index.md
+++ b/public/content/translations/de/staking/pools/index.md
@@ -1,6 +1,6 @@
---
title: Gepooltes Staking
-description: Eine Übersicht darüber, wie man mit ETH-Pool-Staking beginnen kann
+description: "Erfahren Sie mehr über Staking-Pools"
lang: de
template: staking
emoji: ":money_with_wings:"
@@ -17,21 +17,21 @@ summaryPoints:
Staking-Pools sind ein kollaborativer Ansatz, um es vielen Menschen mit kleineren ETH-Beträgen zu ermöglichen, die 32 ETH zu erhalten, die zur Aktivierung eines Satzes von Validator-Schlüsseln erforderlich sind. Die Pooling-Funktionalität wird innerhalb des Protokolls nicht nativ unterstützt, daher wurden separate Lösungen entwickelt, um diesen Bedarf zu decken.
-Einige Pools arbeiten mit Smart Contracts, bei denen Gelder in einen Vertrag eingezahlt werden können, der Ihren Einsatz (Stake) vertrauenswürdig verwaltet und verfolgt und Ihnen einen Token ausstellt, der diesen Wert widerspiegelt. Andere Pools beinhalten möglicherweise keine Smart Contracts und werden stattdessen außerhalb der Chain vermittelt.
+Einige Pools arbeiten mit Smart Contracts, bei denen Gelder in einen Vertrag eingezahlt werden können, der Ihren Einsatz (Stake) vertrauenswürdig verwaltet und verfolgt und Ihnen einen Token ausstellt, der diesen Wert widerspiegelt. Andere Pools beinhalten möglicherweise keine Smart-Contracts und werden stattdessen off-chain vermittelt.
-## Warum in einem Pool staken? {#why-stake-with-a-pool}
+## Warum in einem Pool staken? Warum mit einem Pool staken? {#why-stake-with-a-pool}
-Zusätzlich zu den Vorteilen, die wir in unserer [Einführung zum Staking](/staking/) beschrieben haben, bietet das Staking mit einem Pool einige konkrete Vorteile.
+Zusätzlich zu den Vorteilen, die wir in unserer [Einführung zum Staking](/staking/) beschrieben haben, bietet das Staking mit einem Pool eine Reihe von besonderen Vorteilen.
-
-
-
+
+
+
-## Bitte beachten {#what-to-consider}
+## Was zu beachten ist {#what-to-consider}
Gepooltes oder delegiertes Staking wird vom Ethereum-Protokoll nicht nativ unterstützt, aber angesichts der Nachfrage nach Benutzern, weniger als 32 ETH einzusetzen, wurde eine wachsende Zahl von Lösungen entwickelt, um diesen Bedarf zu befriedigen.
@@ -39,13 +39,13 @@ Jeder Pool und die von verschiedenen Teams entwickelten Tools oder Smart Contrac
Allerdings kommt es mit diesen gestaketen ETH-Token zu kartellähnlichem Verhalten. Eine große Menge an gestaketem ETH gelangt unter Kontrolle einiger weniger zentralisierter Organisationen, anstatt sich auf viele unabhängige Individuen zu verteilen. Dies schafft die Möglichkeit für Zensur oder Wertentzug. Der Goldstandard für Staking sollte darin bestehen, dass Einzelpersonen Validatoren, wann immer möglich, auf ihrer eigenen Hardware betreiben.
-[Mehr zu den Risiken von Staking-Token](https://notes.ethereum.org/@djrtwo/risks-of-lsd).
+[Mehr über die Risiken von Staking-Tokens](https://notes.ethereum.org/@djrtwo/risks-of-lsd).
Attributindikatoren werden unten verwendet, um auf nennenswerte Stärken oder Schwächen hinzuweisen, die ein gelisteter Staking-Pool enthalten kann. Verwenden Sie diesen Abschnitt als Referenz dafür, wie wir diese Attribute definieren, während Sie einen Pool auswählen, dem Sie beitreten möchten.
-## Staking-Pools entdecken {#explore-staking-pools}
+## Staking-Pools erkunden {#explore-staking-pools}
Es gibt eine Vielzahl von Optionen, die Ihnen bei der Einrichtung helfen. Anhand der Indikatoren oben können Sie die Tools unten besser beurteilen.
@@ -53,9 +53,9 @@ Es gibt eine Vielzahl von Optionen, die Ihnen bei der Einrichtung helfen. Anhand
-Hinweis: Es ist wichtig, einen Dienst zu wählen, der [Client-Diversität](/developers/docs/nodes-and-clients/client-diversity/) ernst nimmt, da das die Sicherheit des Netzwerks verbessert und Ihr Risiko begrenzt. Dienste, die nachweislich die Nutzung von Mehrheits-Clients einschränken, sind gekennzeichnet mit "Vielfalt der Ausführungs-Clients" and "Vielfalt der Konsens-Clients".
+Bitte beachten Sie, wie wichtig es ist, einen Dienst zu wählen, der die [Client-Diversität](/developers/docs/nodes-and-clients/client-diversity/) ernst nimmt, da dies die Sicherheit des Netzwerks verbessert und Ihr Risiko begrenzt. Dienste, die nachweislich die Nutzung von Mehrheits-Clients einschränken, sind gekennzeichnet mit "Vielfalt der Ausführungskunden" and "Vielfalt der Konsenskunden".
-Haben Sie einen Vorschlag für einen Staking-Tool, der noch fehlt? Machen Sie sich mit unserer [Richtlinie zum Aufführen von Produkten](/contributing/adding-staking-products/) vertraut, um beurteilen zu können, ob Ihr Vorschlag geeignet ist. Senden Sie ihn uns dann zur Prüfung zu.
+Haben Sie einen Vorschlag für einen Staking-Tool, der noch fehlt? Sehen Sie sich unsere [Produktlistungsrichtlinie](/contributing/adding-staking-products/) an, um zu prüfen, ob sie passt, und um sie zur Überprüfung einzureichen.
## Häufig gestellte Fragen {#faq}
@@ -63,24 +63,24 @@ Haben Sie einen Vorschlag für einen Staking-Tool, der noch fehlt? Machen Sie si
Typischerweise werden ERC-20-Staking-Token an die Staker ausgegeben und repräsentieren den Wert ihres eingesetzten ETH sowie Belohnungen. Denken Sie daran, dass Staking-Belohnungen grundsätzlich etabliert sind, verschiedene Pools Staking-Belohnungen allerdings nach leicht unterschiedlichen Methoden an ihre Benutzer verteilen.
-
+
Sofort! Die Aktualisierung des Netzwerks auf Shanghai/Capella erfolgte im April 2023 und führte das Auszahlen von Staking-Mitteln ein. Validatoren haben nun die Möglichkeit, Staking-Pools, die sie unterstützen, zu verlassen und eine Auszahlung von ETH an ihre angegebene Adresse anzuweisen. Dies macht es möglich, Ihren Anteil am Stake gegen das zugrundeliegende ETH einzulösen. Bitte wenden Sie sich an Ihren Anbieter, um zu erfahren, wie er diese Funktionalität unterstützt.
Alternativ dazu ermöglichen Pools, die einen ERC-20 Staking-Token verwenden, den Handel mit diesem Token auf dem freien Markt, so dass Sie Ihre Staking-Position verkaufen können, ohne tatsächlich ETH aus dem Staking-Vertrag zu entnehmen.
-Mehr zum Abheben von Staking
+Mehr zu Staking-Auszahlungen\n
-
-Es gibt viele Ähnlichkeiten zwischen diesen gepoolten Staking-Optionen und zentralisierten Börsen, wie z. B. die Möglichkeit, kleine ETH-Beträge zu staken und sie zu bündeln, um Validatoren zu aktivieren.
+
+\nEs gibt viele Ähnlichkeiten zwischen diesen gepoolten Staking-Optionen und zentralisierten Börsen, wie z. B. die Möglichkeit, kleine ETH-Beträge zu staken und sie zu bündeln, um Validatoren zu aktivieren.
Im Gegensatz zu zentralisierten Börsen nutzen viele andere gepoolte Staking-Optionen Smart Contracts und/oder Staking-Token, bei denen es sich in der Regel um ERC-20-Token handelt, die Sie in Ihrer eigenen Wallet halten und wie jeden anderen Token kaufen oder verkaufen können. Dies bietet eine gewisse Souveränität und Sicherheit, da Sie die Kontrolle über Ihre Token besitzen. Allerdings haben Sie immer noch keine direkte Kontrolle über den Validator-Client, der in Ihrem Namen im Hintergrund Attestierungen ausgibt.
Einige Pooling-Optionen sind im Hinblick auf die Nodes, die sie unterstützen, stärker dezentralisiert als andere. Um die Gesundheit und Dezentralisierung des Netzwerks zu fördern, werden Staker immer dazu ermutigt, einen Pooling-Service auszuwählen, der eine genehmigungsfreie, dezentrale Gruppe von Node-Betreibern ermöglicht.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
- [Das Ethereum-Staking-Verzeichnis](https://www.staking.directory/) - _Eridian und Spacesider_
-- [Staking mit Rocket Pool – Staking-Übersicht](https://docs.rocketpool.net/guides/staking/overview.html) – _RocketPool-Dokumentation_
-- [Staking von Ethereum mit Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _Lido Hilfedokumente_
+- [Staken mit Rocket Pool - Staking-Überblick](https://docs.rocketpool.net/guides/staking/overview.html) - _RocketPool-Dokumentation_
+- [Ethereum staken mit Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _Lido-Hilfedokumente_
diff --git a/public/content/translations/de/staking/saas/index.md b/public/content/translations/de/staking/saas/index.md
index 73acdc8cf65..c141b6873c9 100644
--- a/public/content/translations/de/staking/saas/index.md
+++ b/public/content/translations/de/staking/saas/index.md
@@ -1,6 +1,6 @@
---
title: Staking als Service
-description: Eine Übersicht darüber, wie man mit gepooltem ETH-Staking beginnen kann
+description: "Erfahren Sie mehr über Staking als Service"
lang: de
template: staking
emoji: ":money_with_wings:"
@@ -22,14 +22,14 @@ Staking-as-a-Service („SaaS“) stellt eine Kategorie von Staking-Diensten dar
Das Ethereum-Protokoll unterstützt keine Delegation von Staking, daher wurden diese Serviceleistungen aufgebaut, um die entsprechende Nachfrage zu befriedigen. Wenn Sie über 32 ETH zum Staking verfügen, sich aber davor scheuen, mit Hardware umzugehen, bieten SaaS-Dienste Ihnen die Möglichkeit, den schwierigen Teil zu delegieren, während Sie native Blockbelohnungen erhalten.
-
-
-
+
+
+
-## Bitte beachten {#what-to-consider}
+## Was zu beachten ist {#what-to-consider}
Es kommen immer mehr SaaS-Anbieter auf den Markt, die Ihnen beim Staking Ihrer ETH helfen. Doch alle haben ihre eigenen Vorteile und Risiken. Bei allen SaaS-Optionen müssen Sie im Vergleich zum Home-Staking mehr Vertrauen aufbringen. SaaS-Optionen können zusätzlichen Code haben, der die Ethereum-Clients umgibt, der nicht offen oder überprüfbar ist. SaaS beeinträchtigt zudem die Dezentralisierung des Netzwerks. Je nach Einstellung haben Sie möglicherweise keine Kontrolle über Ihren Validator – der Betreiber könnte mit Ihrem ETH unehrlich handeln.
@@ -47,13 +47,13 @@ Hier sind einige verfügbare SaaS-Anbieter. Verwenden Sie die obigen Indikatoren
-Hinweis: Es ist wichtig, dass sie die [Client-Diversität](/developers/docs/nodes-and-clients/client-diversity/) unterstützen, denn das erhöht die Netzsicherheit und begrenzt Ihre Risiken. Dienste, die nachweislich die Nutzung von Mehrheits-Clients einschränken, sind gekennzeichnet mit "Vielfalt der Ausführungs-Clients" and "Vielfalt der Konsens-Clients".
+Bitte beachten Sie, wie wichtig es ist, die [Client-Diversität](/developers/docs/nodes-and-clients/client-diversity/) zu unterstützen, da dies die Sicherheit des Netzwerks verbessert und Ihr Risiko begrenzt. Dienste, die nachweislich die Nutzung von Mehrheits-Clients einschränken, sind gekennzeichnet mit "Vielfalt der Ausführungskunden" and "Vielfalt der Konsenskunden".
### Schlüssel-Generatoren
-Sie haben einen Vorschlag zu einem SaaS-Anbieter, den wir noch nicht haben? Machen Sie sich mit unserer [Richtlinie zum Aufführen von Produkten](/contributing/adding-staking-products/) vertraut, um beurteilen zu können, ob Ihr Vorschlag geeignet ist. Senden Sie ihn uns dann zur Prüfung zu.
+Sie haben einen Vorschlag zu einem SaaS-Anbieter, den wir noch nicht haben? Sehen Sie sich unsere [Produktlistungsrichtlinie](/contributing/adding-staking-products/) an, um zu prüfen, ob sie passt, und um sie zur Überprüfung einzureichen.
## Häufig gestellte Fragen {#faq}
@@ -61,35 +61,35 @@ Sie haben einen Vorschlag zu einem SaaS-Anbieter, den wir noch nicht haben? Mach
Die Vereinbarungen unterscheiden sich von Anbieter zu Anbieter. In der Regel werden Sie durch die Einrichtung aller benötigten Signaturschlüssel (einer pro 32 ETH) und das Hochladen dieser Schlüssel zu Ihrem Anbieter geleitet, damit dieser in Ihrem Namen validieren kann. Die Signaturschlüssel allein bieten nicht die Möglichkeit, Ihr Geld abzuheben, zu überweisen oder auszugeben. Sie bieten jedoch die Möglichkeit, Stimmen für einen Konsens abzugeben, was, wenn es nicht richtig gemacht wird, zu Offline-Strafen oder Slashing führen kann.
-
+
Ja. Jedes Konto besteht aus BLS-Signaturschlüsseln und BLS-Abhebungsschlüsseln. Damit ein Validator den Zustand der Blockchain attestieren, an Synchronisierungsausschüssen teilnehmen und Blöcke vorschlagen kann, müssen die Signaturschlüssel für einen Validator-Kunden leicht zugänglich sein. Diese müssen in irgendeiner Form mit dem Internet verbunden sein und werden daher naturgemäß als "Hot Keys" betrachtet. Dies ist eine Voraussetzung für Ihren Validator, um attestieren zu können. Daher werden die Schlüssel, die zum Überweisen oder Abheben von Geldern verwendet werden, aus Sicherheitsgründen getrennt.
Die BLS-Abhebungsschlüssel werden verwendet, um eine einmalige Nachricht zu signieren, die angibt, an welches Execution-Layer-Konto Staking-Belohnungen und ausgetretene Mittel gehen sollen. Sobald diese Nachricht gesendet wurde, werden die BLS-Abhebungsschlüssel nicht mehr benötigt. Stattdessen wird die Kontrolle über abgehobene Mittel dauerhaft an die von Ihnen angegebene Adresse delegiert. Auf diese Weise können Sie eine Abhebungsadresse festlegen, die durch Ihre eigene Cold Storage gesichert ist, um das Risiko für Ihre Validator-Fonds zu minimieren, selbst wenn jemand anderes die Signaturschlüssel Ihres Validators kontrolliert.
Das Aktualisieren der Auszahlungsberechtigungen ist ein erforderlicher Schritt, um Auszahlungen zu ermöglichen\*. Dieser Prozess beinhaltet das Generieren der Abhebungsschlüssel mit Hilfe Ihrer Mnemonic Seed Phrase.
-Stellen Sie unbedingt sicher, dass Sie diesen Seed-Satz sicher aufbewahren, sonst können Sie Ihre Auszahlungsschlüssel nicht erstellen, wenn es soweit ist.
+Stellen Sie sicher, dass Sie diese Seed-Phrase sicher aufbewahren, sonst können Sie Ihre Auszahlungsschlüssel nicht generieren, wenn es soweit ist.
-\*Staker, die eine Auszahlungsadresse bei der ersten Einzahlung angegeben haben, müssen dies nicht einstellen. Bitte wenden Sie sich an Ihren SaaS-Anbieter, um Unterstützung bei der Vorbereitung Ihres Validators zu erhalten.
+\*Staker, die bei der Ersteinzahlung eine Auszahlungsadresse angegeben haben, müssen dies nicht festlegen. Bitte wenden Sie sich an Ihren SaaS-Anbieter, um Unterstützung bei der Vorbereitung Ihres Validators zu erhalten.
-
-Staking Auszahlungen wurden mit der Shanghai/Capella Aktualisierung im April 2023 eingeführt. Staker müssen (sofern nicht bereits bei der Ersteinzahlung geschehen) eine Auszahlungsadresse bereitstellen. Belohnungen werden daraufhin automatisch alle paar Tage in regelmäßigen Abständen ausgezahlt.
+
+\nStaker müssen (sofern nicht bereits bei der Ersteinzahlung geschehen) eine Auszahlungsadresse bereitstellen. Belohnungen werden daraufhin automatisch alle paar Tage in regelmäßigen Abständen ausgezahlt.
Validatoren haben auch die Möglichkeit, ihre Tätigkeit als Validator zu beenden. Das ermöglicht die Auszahlung ihres restlichen ETH-Guthabens. Konten, die eine Auszahlungsadresse angegeben und den Austrittsprozess abgeschlossen haben, erhalten ihr gesamtes Guthaben bei der nächsten Validatorendurchsicht auf die angegebene Auszahlungsadresse.
-Mehr zu Staking-Abhebungen
+Mehr zu Staking-Auszahlungen\n
-
+
Durch die Nutzung eines SaaS-Anbieters vertrauen Sie den Betrieb Ihrer Nodes jemand anderem an. Dies birgt das Risiko einer schlechten Node-Leistung, auf die Sie keinen Einfluss haben. Falls Ihr Validator geslashed wird, wird Ihr Validator-Guthaben bestraft und zwangsweise aus dem Validator-Pool entfernt.
Nach Abschluss des Slashing-/Austrittsprozesses werden diese Mittel an die dem Validator zugewiesene Auszahlungsadresse übertragen. Dies erfordert die Angabe einer Auszahlungsadresse zur Aktivierung. Diese Adresse kann bei der anfänglichen Einzahlung angegeben worden sein. Falls nicht, müssen die Auszahlungsschlüssel des Validators verwendet werden, um eine Nachricht zu unterschreiben, die eine Auszahlungsadresse angibt. Wenn keine Auszahlungsadresse angegeben wurde, bleibt das Guthaben bis zur Angabe gesperrt.
-Für weitere Informationen zu Garantien oder Versicherungsoptionen sowie zur Anleitung zur Bereitstellung einer Abhebungsadresse wenden Sie sich bitte an Ihren individuellen SaaS-Anbieter. Wenn Sie es vorziehen, die volle Kontrolle über Ihre Validator-Konfiguration zu haben, [erfahren Sie mehr darüber, wie Sie Ihre ETH alleine einsetzen können](/staking/solo/).
+Für weitere Informationen zu Garantien oder Versicherungsoptionen sowie zur Anleitung zur Bereitstellung einer Abhebungsadresse wenden Sie sich bitte an Ihren individuellen SaaS-Anbieter. Wenn Sie lieber die volle Kontrolle über Ihr Validator Setup haben möchten, [erfahren Sie mehr darüber, wie Sie Ihr ETH alleine einsetzen](/staking/solo/).
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
- [Das Ethereum-Staking-Verzeichnis](https://www.staking.directory/) - _Eridian und Spacesider_
-- [Bewertung von Staking-Diensten](https://www.attestant.io/posts/evaluating-staking-services/) – _Jim McDonald 2020_
+- [Bewertung von Staking-Diensten](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_
diff --git a/public/content/translations/de/staking/solo/index.md b/public/content/translations/de/staking/solo/index.md
index 33bc117aabf..b1b97634da7 100644
--- a/public/content/translations/de/staking/solo/index.md
+++ b/public/content/translations/de/staking/solo/index.md
@@ -1,6 +1,6 @@
---
-title: Solo-Staking Ihres ETH
-description: Ein Überblick darüber, wie Sie mit dem Solo-Staking Ihres ETH beginnen können
+title: Setzen Sie Ihre ETH zu Hause ein
+description: "Eine Übersicht über die ersten Schritte beim Home-Staking Ihres ETH"
lang: de
template: staking
emoji: ":money_with_wings:"
@@ -13,95 +13,96 @@ summaryPoints:
- Vertrauen Sie niemandem und geben Sie niemals den Zugang zu Ihren Geldern weiter
---
-## Was ist Solo-Staking? {#what-is-solo-staking}
+## Was ist Home-Staking? {#what-is-solo-staking}
-Solo-Staking ist das [Betreiben eines Ethereum-Knotens](/run-a-node/), der mit dem Internet verbunden ist, und das Hinterlegen von 32 ETH, um einen [Validator zu aktivieren](#faq), wodurch Sie direkt am Netzwerkkonsens teilnehmen können.
+Home-Staking ist der Vorgang, einen mit dem Internet verbundenen [Ethereum-Knoten](/run-a-node/) zu betreiben und 32 ETH einzuzahlen, um einen [Validator](#faq) zu aktivieren, wodurch Sie die Möglichkeit erhalten, direkt am Netzwerkkonsens teilzunehmen.
-**Das Solo-Staking erhöht die Dezentralisierung des Ethereum-Netzwerks **, damit Ethereum gegen Zensur resistenter und gegen Angriffe robuster wird. Andere Staking-Methoden können das Netzwerk nicht auf die gleiche Weise unterstützen. Das Solo-Staking ist die beste Staking-Option zur Absicherung von Ethereum.
+**Home-Staking erhöht die Dezentralisierung des Ethereum-Netzwerks**, wodurch Ethereum zensurresistenter und robuster gegen Angriffe wird. Andere Staking-Methoden unterstützen das Netzwerk möglicherweise nicht auf die gleiche Weise. Home-Staking ist die beste Staking-Option zur Sicherung von Ethereum.
-Ein Ethereum-Knoten besteht sowohl aus einem Client der Ausführungsschicht (Execution Layer, EL) als auch aus einem Client der Konsensschicht (Client Layer, CL). Diese Kunden sind Software, die mit einem gültigen Satz von Signaturschlüsseln zusammenarbeiten, um Transaktionen und Blöcke zu verifizieren, den korrekten Kopf der Kette zu bestätigen, Bestätigungen zu attestieren und Blöcke vorzuschlagen.
+Ein Ethereum-Knoten besteht sowohl aus einem Client der Ausführungsebene (EL) als auch aus einem Client der Konsensebene (CL). Diese Clients sind Software, die zusammen mit einem gültigen Satz von Signaturschlüsseln zusammenarbeitet, um Transaktionen und Blöcke zu verifizieren, den korrekten Head der Chain zu bestätigen, Bestätigungen zu aggregieren und Blöcke vorzuschlagen.
-Solo-Staker sind für den Betrieb der Hardware verantwortlich, die zum Ausführen dieser Clients erforderlich ist. Es wird dringend empfohlen, dafür einen fest zugeordneten Computer zu verwenden, den Sie von zu Hause aus betreiben, denn dies ist für die Gesundheit des Netzwerks sehr vorteilhaft.
+Home-Staker sind für den Betrieb der Hardware verantwortlich, die für die Ausführung dieser Clients erforderlich ist. Es wird dringend empfohlen, hierfür einen dedizierten Computer zu verwenden, den Sie von zu Hause aus betreiben – dies ist für die Gesundheit des Netzwerks äußerst vorteilhaft.
-Ein Solo-Staker erhält Belohnungen direkt vom Protokoll dafür, dass sein Validator ordnungsgemäß funktioniert und online bleibt.
+Ein Hausbesitzer erhält Belohnungen direkt vom Protokoll dafür, dass er dafür sorgt, dass sein Validator ordnungsgemäß funktioniert und online ist.
-## Warum Solo-Staken? {#why-stake-solo}
+## Warum von zu Hause aus staken? {#why-stake-solo}
-Das Solo-Staking bringt mehr Verantwortung mit sich, bietet Ihnen aber die maximale Kontrolle über Ihre Mittel und Ihre Staking-Einstellungen.
+Home Staking bringt mehr Verantwortung mit sich, bietet Ihnen jedoch maximale Kontrolle über Ihre Gelder und Ihr Abstecken aufstellen.
-
-
-
+
+
+
-## Überlegungen vor dem Solo-Staking {#considerations-before-staking-solo}
+## Überlegungen vor dem Home-Staking {#considerations-before-staking-solo}
-So sehr wir uns wünschen, dass das Solo-Staking für alle zugänglich und risikofrei wäre, spiegelt dies nicht die Realität wider. Es gibt einige praktische und ernsthafte Überlegungen, die Sie beachten sollten, bevor Sie sich entscheiden, Ihre ETH solo zu staken.
+So sehr wir uns auch wünschen, dass Home-Staking für jeden zugänglich und risikofrei wäre, so ist dies nicht die Realität. Es gibt einige praktische und ernsthafte Überlegungen, die Sie berücksichtigen sollten, bevor Sie sich für das Home-Staking Ihrer ETH entscheiden.
-
-Wenn Sie Ihren eigenen Knoten betreiben, sollten Sie einige Zeit damit verbringen, die Verwendung der von Ihnen gewählten Software zu erlernen. Dies umfasst das Lesen der relevanten Dokumentation und das Einstimmen auf die Kommunikationskanäle dieser Entwicklerteams.
+
+Wenn Sie Ihren eigenen Knoten betreiben, sollten Sie sich etwas Zeit nehmen, um zu lernen, wie Sie die von Ihnen gewählte Software verwenden. Dazu gehört das Lesen der relevanten Dokumentation und die Kenntnis der Kommunikationskanäle dieser Entwicklerteams.
-Je mehr Sie über die von Ihnen verwendete Software und die Funktionsweise von Proof-of-Stake (Stake-Nachweis) verstehen, desto weniger riskant ist es als Staker und desto einfacher wird es, alle Probleme zu beheben, die auf dem Weg als Node-Betreiber auftreten können.
+Je mehr Sie über die von Ihnen verwendete Software und die Funktionsweise von Proof-of-Stake verstehen, desto weniger riskant ist es als Staker und desto einfacher wird es, als Knotenbetreiber alle auftretenden Probleme zu beheben.
-
-Das Einrichten von Nodes erfordert ein angemessenes Maß an Sicherheit bei der Arbeit mit Computern, obwohl neue Tools dies im Laufe der Zeit einfacher machen. Das Verständnis der Befehlszeilenschnittstelle ist hilfreich, aber nicht mehr unbedingt erforderlich.
+
+Das Einrichten von Knoten erfordert einen gewissen Grad an Vertrautheit im Umgang mit Computern, obwohl neue Tools dies im Laufe der Zeit einfacher machen. Das Verständnis der Kommandozeilenschnittstelle ist hilfreich, aber nicht mehr zwingend erforderlich.
-Es erfordert auch eine sehr einfache Hardware-Konfiguration und ein gewisses Verständnis der empfohlenen Mindestspezifikationen.
+Es erfordert auch eine sehr einfache Hardware-Einrichtung und ein gewisses Verständnis der empfohlenen Mindestspezifikationen.
-
-Genauso wie private Schlüssel Ihre Ethereum-Adresse sichern, müssen Sie Schlüssel speziell für Ihren Validator generieren. Sie müssen sich informieren, wie Sie Seed-Phrasen oder private Schlüssel sicher aufbewahren.{' '}
+
+So wie private Schlüssel Ihre Ethereum-Adresse sichern, müssen Sie auch speziell für Ihren Validator Schlüssel generieren. Sie müssen verstehen, wie Sie Seed-Phrases oder private Schlüssel sicher aufbewahren.{' '}
[Ethereum-Sicherheit und Betrugsprävention](/security/)
-Hardware fällt gelegentlich aus, Netzwerkverbindungen fallen aus und Client-Software muss gelegentlich aktualisiert werden. Die Node-Wartung ist unvermeidlich und erfordert von Zeit zu Zeit Ihre Aufmerksamkeit. Sie sollten sicher sein, dass Sie über alle erwarteten Netzwerk-Upgrades oder andere wichtige Client-Upgrades informiert sind.
+Hardware fällt gelegentlich aus, Netzwerkverbindungen schlagen fehl und Client-Software muss gelegentlich aktualisiert werden. Die Wartung von Knoten ist unvermeidlich und erfordert gelegentlich Ihre Aufmerksamkeit. Sie sollten sicherstellen, dass Sie über alle erwarteten Netzwerk-Upgrades oder andere wichtige Client-Upgrades informiert bleiben.
-Ihre Belohnungen sind proportional zu der Zeit, in der Ihr Validator online ist und ordnungsgemäß attestiert. Ausfallzeiten führen zu Strafen, die proportional dazu sind, wie viele andere Validatoren gleichzeitig offline sind, aber führen nicht zum Slashing. Auch die Bandbreite spielt eine Rolle, da die Belohnungen für Bescheinigungen, die nicht rechtzeitig eingehen, gekürzt werden. Die Anforderungen sind unterschiedlich, es wird jedoch ein Minimum von 10 Mb/s Upload und Download empfohlen.
+Ihre Belohnungen sind proportional zu der Zeit, in der Ihr Validator online ist und ordnungsgemäß Bestätigungen abgibt. Ausfallzeiten führen zu Strafen, die proportional zur Anzahl der gleichzeitig offline geschalteten Validatoren sind, aber führen nicht zu Slashing. Auch die Bandbreite ist wichtig, da die Belohnungen für nicht rechtzeitig erhaltene Bestätigungen verringert werden. Die Anforderungen variieren, aber es wird ein Minimum von 10 Mbit/s für Up- und Download empfohlen.
-Im Gegensatz zu Strafen für Inaktivität in Offline-Zeiten ist Slashing eine viel schwerwiegendere Strafe, die auf böswillige Vergehen beschränkt ist. Wenn Sie einen Minderheiten-Client mit Ihren Schlüsseln jeweils auf nur einer Maschine laden, wird das Risiko des Schrumpfens minimiert. Davon abgesehen müssen sich alle Staker der Risiken von Slashing bewusst sein.
+Im Gegensatz zu Inaktivitätsstrafen für das Offline-Sein ist Slashing eine wesentlich schwerwiegendere Strafe, die böswilligen Verstößen vorbehalten ist. Indem Sie einen Minderheits-Client betreiben und Ihre Schlüssel nur auf einem einzigen Gerät geladen haben, wird Ihr Risiko eines Slashings minimiert. Dennoch müssen sich alle Staker der Risiken des Slashings bewusst sein.
Mehr über Slashing und den Lebenszyklus von Validatoren
+
-## Wie es funktioniert {#how-it-works}
+## Funktionsweise {#how-it-works}
Während Sie aktiv sind, erhalten Sie ETH-Prämien, die regelmäßig in Ihre Auszahlungsadresse eingezahlt werden.
-Wenn Sie möchten, können Sie als Validator aussteigen, wodurch die Notwendigkeit entfällt, online zu sein, und alle weiteren Belohnungen gestoppt werden. Ihr verbleibendes Guthaben wird dann an die Auszahlungsadresse, die Sie bei der Einrichtung angeben, ausgezahlt.
+Wenn Sie es wünschen, können Sie Ihre Rolle als Validator beenden, wodurch die Online-Pflicht entfällt und keine weiteren Belohnungen mehr gezahlt werden. Ihr verbleibendes Guthaben wird dann an die Auszahlungsadresse ausgezahlt, die Sie bei der Einrichtung angeben.
[Mehr zu Staking-Auszahlungen](/staking/withdrawals/)
-## Beginnen Sie mit dem Staking-Launchpad {#get-started-on-the-staking-launchpad}
+## Erste Schritte mit dem Staking Launchpad {#get-started-on-the-staking-launchpad}
-Das Staking-Launchpad ist eine Open-Source-Anwendung, die Ihnen hilft, ein Staker zu werden. Es führt Sie durch die Auswahl Ihrer Clients, die Generierung Ihrer Schlüssel und die Hinterlegung Ihrer ETH nach Maßgabe des Staking-Einlagenvertrags. Eine Checkliste wird bereitgestellt, um sicherzustellen, dass Sie alles abgedeckt haben, um Ihren Validator sicher einzurichten.
+Das Staking Launchpad ist eine Open-Source-Anwendung, die Ihnen hilft, ein Staker zu werden. Es führt Sie durch die Auswahl Ihrer Clients, die Generierung Ihrer Schlüssel und die Einzahlung Ihrer ETH in den Staking-Einzahlungsvertrag. Es wird eine Checkliste bereitgestellt, um sicherzustellen, dass Sie alles berücksichtigt haben, um Ihren Validator sicher einzurichten.
-## Was bei Node- und Client-Konfigurations-Tools zu beachten ist {#node-tool-considerations}
+## Was bei Node- und Client-Setup-Tools zu beachten ist {#node-tool-considerations}
-Es gibt eine wachsende Zahl von Tools und Dienstleistungen, die Ihnen helfen, Ihre ETH solo zu staken, aber sie sind mit unterschiedlichen Risiken und Vorteilen verbunden.
+Es gibt eine wachsende Zahl von Tools und Diensten, die Ihnen beim Home Staking Ihres ETH helfen, aber jedes davon ist mit unterschiedlichen Risiken und Vorteilen verbunden.
-Attributindikatoren werden unten verwendet, um auf nennenswerte Stärken oder Schwächen hinzuweisen, die ein gelistetes Staking-Tool haben kann. Verwenden Sie diesen Abschnitt als Referenz dafür, wie wir diese Attribute definieren, während Sie auswählen, welche Tools Sie bei Ihrer Staking-Reise unterstützen.
+Die unten aufgeführten Attributindikatoren werden verwendet, um auf nennenswerte Stärken oder Schwächen hinzuweisen, die ein aufgeführtes Staking-Tool aufweisen kann. Nutzen Sie diesen Abschnitt als Referenz dafür, wie wir diese Attribute definieren, während Sie auswählen, welche Tools Sie auf Ihrer Staking-Reise unterstützen.
-## Erkunden Sie Tools zum Einrichten von Nodes und Clients {#node-and-client-tools}
+## Node- und Client-Setup-Tools erkunden {#node-and-client-tools}
-Es gibt eine Vielzahl von Optionen, die Ihnen bei der Einrichtung helfen. Verwenden Sie die obigen Indikatoren, um Sie durch die folgenden Tools zu führen.
+Es gibt eine Vielzahl von Optionen, die Ihnen bei der Einrichtung helfen. Anhand der Indikatoren oben können Sie die Tools unten besser beurteilen.
@@ -109,17 +110,17 @@ Es gibt eine Vielzahl von Optionen, die Ihnen bei der Einrichtung helfen. Verwen
-Bitte beachten Sie, wie wichtig es ist, einen [Minderheits-Client](/developers/docs/nodes-and-clients/client-diversity/) zu wählen, da er die Sicherheit des Netzwerks verbessert und Ihr Risiko begrenzt. Tools, mit denen Sie einen Minderheits-Client einrichten können, werden als „Multi-Client" bezeichnet.
+Bitte beachten Sie, wie wichtig die Wahl eines [Minderheits-Clients](/developers/docs/nodes-and-clients/client-diversity/) ist, da dies die Sicherheit des Netzwerks verbessert und Ihr Risiko begrenzt. Tools, mit denen Sie einen Minderheits-Client einrichten können, werden als "Multi-Client" bezeichnet.
### Schlüssel-Generatoren
-Diese Tools können als Alternative zur [Staking-Einlage-CLI](https://github.com/ethereum/staking-deposit-cli/) genutzt werden, um bei der Schlüsselgenerierung zu helfen.
+Diese Tools können als Alternative zum [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) verwendet werden, um bei der Schlüsselgenerierung zu helfen.
-Haben Sie einen Vorschlag für einen Staking-Tool, der noch fehlt? Machen Sie sich mit unserer [Richtlinie zum Aufführen von Produkten](/contributing/adding-staking-products/) vertraut, um beurteilen zu können, ob Ihr Vorschlag geeignet ist. Senden Sie ihn uns dann zur Prüfung zu.
+Haben Sie einen Vorschlag für einen Staking-Tool, der noch fehlt? Sehen Sie sich unsere [Produktlistungsrichtlinie](/contributing/adding-staking-products/) an, um zu prüfen, ob sie passt, und um sie zur Überprüfung einzureichen.
-## Erkunden Sie Solo-Staking-Anleitungen {#staking-guides}
+## Leitfäden zum Home-Staking erkunden {#staking-guides}
@@ -129,78 +130,80 @@ Das sind einige der häufigsten Fragen zum Thema Staking. Es ist lohnenswert sic
-Ein Validator ist eine virtuelle Einheit, die auf Ethereum existiert und am Konsens des Ethereum-Protokolls teilnimmt. Validatoren werden durch ein Guthaben, einen öffentlichen Schlüssel und andere Eigenschaften dargestellt. Ein Validator-Client ist die Software, die im Namen des Validators handelt, indem sie seinen privaten Schlüssel hält und verwendet. Ein einzelner Validator-Client kann viele Schlüsselpaare enthalten und viele Validatoren steuern.
-
+Ein Validator ist eine virtuelle Entität, die auf Ethereum lebt und am Konsens des Ethereum-Protokolls teilnimmt. Validatoren werden durch ein Guthaben, einen öffentlichen Schlüssel und andere Eigenschaften dargestellt. Ein Validator-Client ist die Software, die im Namen des Validators handelt, indem sie dessen privaten Schlüssel hält und verwendet. Ein einzelner Validator-Client kann viele Schlüsselpaare enthalten und somit viele Validatoren steuern.
-
-Jedes Schlüsselpaar, das einem Validator zugeordnet ist, erfordert genau 32 ETH, um aktiviert zu werden. Mehr ETH, die in einen einzigen Schlüsselsatz eingezahlt werden, erhöhen das Belohnungspotenzial nicht, da jeder Validator auf ein effektives Guthaben von 32 ETH begrenzt ist. Dies bedeutet, dass das Staking in Schritten von 32 ETH erfolgt, von denen jeder seinen eigenen Schlüsselsatz und sein eigenes Guthaben hat.
+
+Ja, moderne Validator-Konten können bis zu 2048 ETH halten. Zusätzliche ETH über 32 werden schrittweise verzinst und erhöhen sich in ganzzahligen Schritten, wenn Ihr tatsächliches Guthaben steigt. Dies wird als Ihr effektives Guthaben bezeichnet.
+
+Um das effektive Guthaben eines Kontos und damit die Belohnungen zu erhöhen, muss ein Puffer von 0,25 ETH über einer beliebigen Ganzzahl-ETH-Schwelle überschritten werden. Beispielsweise müsste ein Konto mit einem tatsächlichen Guthaben von 32,9 und einem effektiven Guthaben von 32 weitere 0,35 ETH verdienen, um sein tatsächliches Guthaben über 33,25 zu bringen, bevor eine Erhöhung des effektiven Guthabens ausgelöst wird.
+
+Dieser Puffer verhindert auch, dass ein effektiver Saldo sinkt, bis er 0,25 ETH unter seinen aktuellen effektiven Saldo gefallen ist.
-Zahlen Sie nicht mehr als 32 ETH für einen einzelnen Validator ein. Sie wird Ihre Belohnungen nicht erhöhen. Wenn eine Auszahlungsadresse für den Validator festgelegt wurde, werden überschüssige Gelder über 32 ETH während des nächsten [Validator-Sweeps](/staking/withdrawals/#validator-sweeping) automatisch an diese Adresse überwiesen.
+Jedes Schlüsselpaar, das einem Validator zugeordnet ist, benötigt mindestens 32 ETH, um aktiviert zu werden. Jedes darüber hinausgehende Guthaben kann jederzeit durch eine mit dieser Adresse signierte Transaktion an die zugehörige Auszahlungsadresse ausgezahlt werden. Alle Gelder, die das maximale effektive Guthaben übersteigen, werden in regelmäßigen Abständen automatisch ausgezahlt.
-Wenn Ihnen Solo-Staking zu anspruchsvoll erscheint, ziehen Sie die Nutzung eines [Staking-as-a-Service](/staking/saas/)-Anbieters in Betracht, oder wenn Sie mit weniger als 32 ETH arbeiten, schauen Sie sich die [Staking-Pools](/staking/pools/) an.
+Wenn Ihnen Home-Staking zu anspruchsvoll erscheint, ziehen Sie die Nutzung eines [Staking-as-a-Service](/staking/saas/)-Anbieters in Betracht, oder sehen Sie sich die [Staking-Pools](/staking/pools/) an, wenn Sie mit weniger als 32 ETH arbeiten.
-
-Wenn man offline geht, während das Netzwerk ordnungsgemäß abgeschlossen wird, führt dies NICHT zu Slashing. Es fallen kleine Strafen für Inaktivität an, wenn Ihr Validator für eine bestimmte Epoche (jeweils 6,4 Minuten lang) nicht verfügbar ist, um dies zu bestätigen, aber dies unterscheidet sich stark von Slashing. Diese Strafen sind etwas geringer als die Belohnung, die Sie verdient hätten, wenn der Validator zur Bestätigung verfügbar gewesen wäre, und Verluste können mit ungefähr der gleichen Zeit zurückerstattet werden, wenn Sie wieder online sind.
+
+Offline zu gehen, während das Netzwerk ordnungsgemäß finalisiert, führt NICHT zu Slashing. Geringe Inaktivitätsstrafen fallen an, wenn Ihr Validator für eine bestimmte Epoche (jeweils 6,4 Minuten lang) nicht für Bestätigungen zur Verfügung steht, was sich jedoch stark von Slashing unterscheidet. Diese Strafen sind etwas geringer als die Belohnung, die Sie erhalten hätten, wenn der Validator für Bestätigungen zur Verfügung gestanden hätte. Die Verluste können durch eine ungefähr gleich lange Zeit, in der Sie wieder online sind, ausgeglichen werden.
-Beachten Sie, dass Strafen für Inaktivität proportional dazu sind, wie viele Validatoren gleichzeitig offline sind. In Fällen, in denen ein großer Teil des Netzwerks auf einmal offline ist, sind die Strafen für jeden dieser Validatoren größer, als wenn ein einzelner Validator nicht verfügbar ist.
+Beachten Sie, dass die Strafen für Inaktivität proportional zur Anzahl der gleichzeitig offline geschalteten Validatoren sind. In Fällen, in denen ein großer Teil des Netzwerks gleichzeitig offline ist, sind die Strafen für jeden dieser Validatoren höher als bei der Nichtverfügbarkeit eines einzelnen Validators.
-In extremen Fällen, wenn das Netzwerk nicht mehr fertig gestellt wird, weil mehr als ein Drittel der Validatoren offline sind, werden diese Benutzer unter einem sogenannten quadratischen Inaktivitätsleck leiden, das einen exponentiellen Abfluss von ETH von Offline-Validierungskonten darstellt. Dies ermöglicht es dem Netzwerk, sich schließlich selbst zu heilen, indem es die ETH von inaktiven Validatoren verbrennt, bis deren Kontostand 16 ETH erreicht. An diesem Punkt werden sie automatisch aus dem Validator-Pool herausgeworfen werden. Die verbleibenden Online-Validatoren werden schließlich wieder über 2/3 des Netzwerks verfügen und die qualifizierte Mehrheit haben, die erforderlich ist, um die Kette erneut abzuschließen.
+In extremen Fällen, wenn das Netzwerk die Finalisierung einstellt, weil mehr als ein Drittel der Validatoren offline ist, erleiden diese Benutzer einen sogenannten quadratischen Inaktivitätsverlust, der einen exponentiellen Abfluss von ETH von Offline-Validator-Konten darstellt. Dies ermöglicht es dem Netzwerk, sich schließlich selbst zu heilen, indem die ETH inaktiver Validatoren verbrannt werden, bis ihr Guthaben 16 ETH erreicht. An diesem Punkt werden sie automatisch aus dem Validator-Pool entfernt. Die verbleibenden Online-Validatoren werden schließlich wieder mehr als 2/3 des Netzwerks ausmachen und so die erforderliche Supermajorität erreichen, um die Kette erneut zu finalisieren.
-
-Kurz gesagt, dies kann nie vollständig garantiert werden, aber wenn Sie in gutem Glauben handeln, einen Minderheits-Client betreiben und Ihre Signaturschlüssel jeweils nur auf einem Computer aufbewahren, liegt das Slashing-Risiko bei nahezu null.
+
+Kurz gesagt, dies kann nie vollständig garantiert werden, aber wenn Sie in gutem Glauben handeln, einen Minderheits-Client betreiben und Ihre Signaturschlüssel jeweils nur auf einem Computer aufbewahren, ist das Risiko eines Slashings nahezu null.
-Es gibt nur wenige spezifische Möglichkeiten, die dazu führen können, dass ein Validator geslashed und aus dem Netzwerk herausgeworfen wird. Zum Zeitpunkt des Verfassens dieses Artikels waren die aufgetretenen Slashings ausschließlich ein Produkt redundanter Hardware-Konfigurationen, bei denen Signaturschlüssel gleichzeitig auf zwei separaten Computern gespeichert werden. Dies kann unbeabsichtigt zu einer doppelten Abstimmung Ihrer Schlüssel führen. Das wiederum stellt ein strafbares Vergehen dar.
+Es gibt nur wenige spezifische Vorgehensweisen, die dazu führen können, dass ein Validator einem Slashing unterzogen und aus dem Netzwerk entfernt wird. Zum Zeitpunkt der Erstellung dieses Dokuments waren die aufgetretenen Slashings ausschließlich auf redundante Hardware-Setups zurückzuführen, bei denen Signaturschlüssel gleichzeitig auf zwei separaten Maschinen gespeichert wurden. Dies kann unbeabsichtigt zu einer doppelten Abstimmung (Double Vote) durch Ihre Schlüssel führen, was ein durch Slashing strafbares Vergehen ist.
-Das Ausführen eines Clients mit qualifizierter Mehrheit (jeder Client, der von mehr als 2/3 des Netzwerks verwendet wird) birgt auch das Risiko eines potenziellen Slashing, falls dieser Client einen Fehler aufweist, der zu einer Chain-Fork führt. Dies kann zu einer fehlerhaften Fork führen, die abgeschlossen wird. Um zur beabsichtigten Kette zurückzukehren, müsste eine Surround-Abstimmung durchgeführt werden, indem man versucht, einen abgeschlossenen Block rückgängig zu machen. Auch dies ist ein strafbares Vergehen und kann einfach dadurch vermieden werden, dass stattdessen ein Minderheits-Client ausgeführt wird.
+Der Betrieb eines Supermajoritäts-Clients (jeder Client, der von über 2/3 des Netzwerks verwendet wird) birgt auch das Risiko eines potenziellen Slashings, falls dieser Client einen Fehler aufweist, der zu einem Chain-Fork führt. Dies kann zu einem fehlerhaften Fork führen, der finalisiert wird. Um zur beabsichtigten Kette zurückzukehren, müsste eine Surround Vote abgegeben werden, indem versucht wird, einen finalisierten Block rückgängig zu machen. Dies ist ebenfalls ein durch Slashing strafbares Vergehen und kann einfach durch den Betrieb eines Minderheits-Clients vermieden werden.
Äquivalente Fehler in einem Minderheits-Client würden niemals abgeschlossen und würden daher niemals zu einer Surround-Abstimmung, sondern einfach zu Inaktivitätsstrafen, nicht zu Slashing.
-
-Einzelne Clients können in Bezug auf Leistung und Benutzeroberfläche leicht variieren, da jeder von verschiedenen Teams mit einer Vielzahl von Programmiersprachen entwickelt wird. Davon abgesehen ist keiner von ihnen „am besten" Bei allen Produktions-Clients handelt es sich um eine hervorragende Software, die alle die gleichen Kernfunktionen zur Synchronisierung und Interaktion mit der Blockchain ausführen.
+
+Einzelne Clients können sich in Bezug auf Leistung und Benutzeroberfläche geringfügig unterscheiden, da sie von verschiedenen Teams unter Verwendung einer Vielzahl von Programmiersprachen entwickelt werden. Dennoch ist keiner von ihnen der "Beste". Alle Produktions-Clients sind ausgezeichnete Software-Komponenten, die alle die gleichen Kernfunktionen zur Synchronisierung und Interaktion mit der Blockchain ausführen.
-Da alle Produktions-Clients die gleiche Grundfunktionalität bieten, ist es sehr wichtig, dass Sie einen Minderheits-Client wählen, d. h. jeden Client, der derzeit NICHT von einer Mehrheit der Validatoren im Netzwerk verwendet wird. Dies mag kontraintuitiv klingen, aber wenn Sie einen Mehrheits- oder einen Client mit qualifizierter Mehrheit betreiben, besteht für Sie ein erhöhtes Risiko des Slashing im Falle eines Fehlers in diesem Client. Der Betrieb eines Minderheits-Client begrenzt diese Risiken drastisch.
+Da alle Produktions-Clients die gleiche Grundfunktionalität bieten, ist es sehr wichtig, dass Sie einen Minderheits-Client wählen, d. h. einen Client, der derzeit NICHT von einer Mehrheit der Validatoren im Netzwerk verwendet wird. Dies mag kontraintuitiv klingen, aber der Betrieb eines Majoritäts- oder Supermajoritäts-Clients setzt Sie einem erhöhten Slashing-Risiko aus, falls in diesem Client ein Fehler auftritt. Der Betrieb eines Minderheits-Clients begrenzt diese Risiken drastisch.
Erfahren Sie mehr darüber, warum Client-Diversität entscheidend ist
-
-Obwohl ein virtueller privater Server (VPS) als Ersatz für Heim-Hardware verwendet werden kann, spielen der physische Zugang und Standort Ihres Validator-Client eine Rolle. Zentralisierte Cloud-Lösungen wie Amazon Web Services oder Digital Ocean bieten den Vorteil, dass keine Hardware angeschafft und betrieben werden muss, was zur Zentralisierung des Netzwerks beiträgt.
+
+Obwohl ein virtueller privater Server (VPS) als Ersatz für die Hardware zu Hause verwendet werden kann, sind der physische Zugang und der Standort Ihres Validator-Clients sehr wohl von Bedeutung. Zentralisierte Cloud-Lösungen wie Amazon Web Services oder Digital Ocean bieten den Komfort, keine Hardware beschaffen und betreiben zu müssen, gehen aber auf Kosten der Zentralisierung des Netzwerks.
-Je mehr Validator-Clients auf einer einzigen zentralisierten Cloud-Speicherlösung laufen, desto gefährlicher wird es für diese Benutzer. Jedes Ereignis, das diese Anbieter offline schaltet, sei es durch einen Angriff, behördliche Anforderungen oder nur Strom-/Internetausfälle, führt dazu, dass jeder Validator-Client, der sich auf diesen Server verlässt, gleichzeitig offline geht.
+Je mehr Validator-Clients auf einer einzigen zentralisierten Cloud-Speicherlösung laufen, desto gefährlicher wird es für diese Benutzer. Jedes Ereignis, das diese Anbieter offline schaltet, sei es durch einen Angriff, regulatorische Anforderungen oder einfach nur Strom-/Internetausfälle, führt dazu, dass jeder Validator-Client, der auf diesen Server angewiesen ist, gleichzeitig offline geht.
-Offline-Strafen sind proportional dazu, wie viele andere gleichzeitig offline sind. Die Verwendung eines VPS erhöht das Risiko, dass Offline-Strafen schwerwiegender sind, und erhöht Ihr Risiko von quadratischen Lecks oder Slashing, falls der Ausfall groß genug ist. Um Ihr eigenes Risiko und das Risiko für das Netzwerk zu minimieren, wird Benutzern dringend empfohlen, ihre eigene Hardware zu erwerben und zu betreiben.
+Offline-Strafen sind proportional zur Anzahl der anderen, die gleichzeitig offline sind. Die Verwendung eines VPS erhöht das Risiko, dass Offline-Strafen schwerwiegender ausfallen, und erhöht Ihr Risiko von quadratischem Verlust oder Slashing, falls der Ausfall groß genug ist. Um Ihr eigenes Risiko und das Risiko für das Netzwerk zu minimieren, wird den Benutzern dringend empfohlen, ihre eigene Hardware zu beschaffen und zu betreiben.
-
+
Abhebungen jeglicher Art aus der Beaconchain erfordern die Angabe von Rücktrittsberechtigungen.
-Neue Staker setzen dies bei der Schlüsselgenerierung und Einzahlung. Bestehende Staker, die dies noch nicht eingestellt haben, können ihre Schlüssel aktualisieren, um diese Funktion zu unterstützen.
+Neue Staker legen dies zum Zeitpunkt der Schlüsselgenerierung und Einzahlung fest. Bestehende Staker, die dies noch nicht festgelegt haben, können ihre Schlüssel upgraden, um diese Funktionalität zu unterstützen.
Sobald die Auszahlungsdaten festgelegt sind, werden Prämienzahlungen (über den ursprünglichen 32) periodisch an die Auszahlungsadresse ausgezahlt.
Um Ihr gesamtes Guthaben zu entsperren und zu erhalten, müssen Sie auch den Prozess des Verlassens Ihres Validators abschließen.
-Mehr zu Staking-Auszahlungen
+Mehr zu Staking-Auszahlungen\n
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
- [Das Ethereum-Staking-Verzeichnis](https://www.staking.directory/) - _Eridian und Spacesider_
-- [Ethereums Client-Diversitätsproblem](https://hackernoon.com/Ethereums-Client-Diversitätsproblem) – _@emmanuelawosika 2022_
-- [Client-Diversität fördern](https://www.attestant.io/Posts/Client-Diversität-fördern/) – _Jim McDonald 2022_
-- [Client-Diversität auf der Konsensebene von Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) – _jmcook.eth 2022_
-- [Anleitung: Ethereum-Validator-Hardware kaufen](https://www.youtube.com/watch?v=C2wwu1IlhDc) – _EthStaker 2022_
-- [Schritt für Schritt: Wie man dem Ethereum 2.0 Testnetz beitritt](https://kb.beaconcha.in/Guides/Tutorium-eth2-Multi-Client) - _ Butta_
-- [Eth2-Slashing-Präventionstipps](https://medium.com/prysmatic-labs/eth2-Slashing-Präventionstipps-f6faa5025f50) – _Raul Jordan 2020 _
+- [Das Problem der Client-Diversität bei Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_
+- [Hilfe für die Client-Diversität](https://www.attestant.io/posts/helping-client-diversity/) - _Jim McDonald 2022_
+- [Client-Diversität auf der Konsensebene von Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_
+- [Anleitung: Kauf von Ethereum-Validator-Hardware](https://www.youtube.com/watch?v=C2wwu1IlhDc) - _EthStaker 2022_
+- [Eth2-Tipps zur Slashing-Prävention](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _Raul Jordan 2020_
diff --git a/public/content/translations/de/staking/withdrawals/index.md b/public/content/translations/de/staking/withdrawals/index.md
index 60e6a7aee9b..f6c6f67b40f 100644
--- a/public/content/translations/de/staking/withdrawals/index.md
+++ b/public/content/translations/de/staking/withdrawals/index.md
@@ -1,6 +1,6 @@
---
title: Staking-Auszahlungen
-description: Seite mit einer Zusammenfassung zu Staking-Push-Auszahlungen, wie sie funktionieren und was Staker tun müssen, um ihre Belohnungen zu erhalten
+description: "Seite mit einer Zusammenfassung zu Staking-Push-Auszahlungen, wie sie funktionieren und was Staker tun müssen, um ihre Belohnungen zu erhalten"
lang: de
template: staking
image: /images/staking/leslie-withdrawal.png
@@ -13,13 +13,9 @@ summaryPoints:
- Validatoren, die nicht mehr staken, erhalten ihr verbleibendes Guthaben
---
-
-Staking-Auszahlungen wurden mit dem Shanghai/Capella-Upgrade aktiviert, welches am 12. April 2023 durchgeführt wurde. Mehr über Shanghai/Capella erfahren
-
+**Staking-Auszahlungen** beziehen sich auf Übertragungen von ETH von einem Validatorkonto auf der Konsensebene von Ethereum (der Beacon Chain) an die Ausführungsebene, auf der damit Transaktionen durchgeführt werden können.
-**Staking-Auszahlungen** beziehen sich auf die Übertragung von ETH von einem Validator-Konto in der Konsensschicht von Ethereum (der Beacon Chain) zur Ausführungsschicht, in der damit Transaktionen durchgeführt werden können.
-
-**Belohnungszahlungen für überschüssige Guthaben** über 32 ETH werden automatisch und regelmäßig an eine mit jedem Validator verknüpfte Auszahlungsadresse gesendet, sobald sie vom Benutzer angegeben wurde. Benutzer können auch das **Staking vollständig beenden** und damit ihr gesamtes Validator-Guthaben freigeben.
+\*\*Belohnungszahlungen für Guthabenüberschüsse über 32 ETH werden automatisch und regelmäßig an eine mit jedem Validator verknüpfte Auszahlungsadresse gesendet, sobald diese vom Benutzer angegeben wurde. Benutzer können das **Staking auch vollständig beenden** und damit ihr gesamtes Validator-Guthaben freigeben.
## Staking-Belohnungen {#staking-rewards}
@@ -47,30 +43,30 @@ Die Angabe einer Auszahlungsadresse ist ein erforderlicher Schritt für jedes Va
- Jedem Validatoren-Konto kann nur eine einzige Abhebungsadresse zugewiesen werden, und zwar nur einmal. Sobald eine Adresse ausgewählt und an die Konsensus-Ebene übermittelt wurde, lässt sich dieser Vorgang nicht mehr rückgängig machen. Überprüfen Sie die Besitzverhältnisse und die Richtigkeit der angegebenen Adresse, bevor Sie sie einreichen.
+Jedem Validatorkonto kann nur ein einziges Mal eine Auszahlungsadresse zugewiesen werden. Sobald eine Adresse ausgewählt und an die Konsensebene übermittelt wurde, kann dies nicht mehr rückgängig gemacht oder geändert werden. Überprüfen Sie die Besitzverhältnisse und die Richtigkeit der angegebenen Adresse, bevor Sie sie einreichen.
In der Zwischenzeit besteht keine Bedrohung für Ihre Gelder, wenn Sie dies nicht tun, vorausgesetzt, Ihre Mnemonic-/Seed-Phrase ist offline sicher aufbewahrt und wurde in keiner Weise kompromittiert. Wenn keine Auszahlungsinformationen hinzugefügt werden, bleibt das ETH einfach im Validator-Konto gesperrt, wie es bislang der Fall war, bis eine Auszahlungsadresse angegeben wird.
-## Das vollständige Beenden des Staking {#exiting-staking-entirely}
+## Staking vollständig beenden {#exiting-staking-entirely}
-Die Angabe einer Auszahlungsadresse ist erforderlich, bevor _irgendwelche_ Gelder aus dem Guthaben eines Validator-Kontos übertragen werden können.
+Die Angabe einer Auszahlungsadresse ist erforderlich, bevor _irgendwelche_ Gelder vom Guthaben eines Validatorkontos überwiesen werden können.
Benutzer, die das Staking vollständig beenden und ihr gesamtes Guthaben abheben möchten, müssen auch eine „freiwillige Ausstiegsnachricht" mit Validator-Schlüsseln unterzeichnen und übermitteln, die den Prozess des Ausstiegs aus dem Staking einleitet. Der Vorgang erfolgt mit Ihrem Validator-Client und wird an Ihren Konsens-Node übermittelt. Dafür fallen keine Gas-Kosten an.
Der Prozess, bei dem ein Validator aus dem Staking aussteigt, dauert je nachdem, wie viele andere gleichzeitig aussteigen, unterschiedlich lange. Sobald der Vorgang abgeschlossen ist, ist dieses Konto nicht mehr dafür verantwortlich, Validator-Netzwerkaufgaben auszuführen, ist nicht mehr für Belohnungen berechtigt und hat sein ETH nicht mehr „aufs Spiel gesetzt". Zu diesem Zeitpunkt wird das Konto als vollständig „abhebbar" gekennzeichnet.
-Sobald ein Konto als „abhebbar" markiert wurde und Auszahlungsinformationen bereitgestellt wurden, gibt es nichts mehr, was ein Benutzer tun muss, außer zu warten. Konten werden automatisch und kontinuierlich von Block-Proposern auf berechtigte freigegebene Gelder durchsucht, und Ihr Kontoguthaben wird in voller Höhe (auch als „vollständiger Abzug" bekannt) während des nächsten Sweeps übertragen.
+Sobald ein Konto als „abhebbar" markiert wurde und Auszahlungsinformationen bereitgestellt wurden, gibt es nichts mehr, was ein Benutzer tun muss, außer zu warten. Konten werden automatisch und kontinuierlich von Block-Proposern auf berechtigte, freigegebene Gelder durchsucht, und Ihr Kontoguthaben wird vollständig (auch als „vollständige Auszahlung“ bekannt) während des nächsten Sweeps übertragen.
-## Wann sind Staking-Abhebungen aktiviert? {#when}
+## Wann wurden Auszahlungen beim Staking freigeschaltet? {#when}
-Staking-Abhebungen sind live! Die Funktionalität für das Abheben wurden als Teil des Shanghai/Capella Upgrades vom 12. April 2023 aktiviert.
+Die Auszahlungsfunktionalität wurde als Teil des Shanghai/Capella-Upgrades aktiviert, das am **12. April 2023** stattfand.
Das Shanghai/Capella Upgrade ermöglicht ETH, das gestaked wurde, mit regulären Ethereum-Konten zurückzufordern. Dies schloss den Kreis hinsichtlich der Bereitstellung von Liquidität und brachte Ethereum einen Schritt näher auf seinem Weg, ein nachhaltiges, skalierbares, sicheres dezentralisiertes Ökosystem zu schaffen.
-- [Mehr zur Geschichte von Ethereum](/ethereum-forks/)
+- [Mehr zur Ethereum-Geschichte](/ethereum-forks/)
- [Mehr zur Ethereum-Roadmap](/roadmap/)
## Wie funktionieren Auszahlungen? {#how-do-withdrawals-work}
@@ -83,7 +79,7 @@ Sehen Sie sich diese Erklärung für die Abhebungen von Ethereum von Finematics
-### Validator „Sweeping" {#validator-sweeping}
+### Validator-„Sweeping“ {#validator-sweeping}
Es ist notwendig, dass ein Validator, der den nächsten Block vorschlagen soll, eine Warteschlange mit bis zu 16 zugelassenen Auszahlungen erstellt. Ursprünglich beginnt man mit dem Validator-Index 0 und prüft, ob es gemäß den Protokollregeln eine berechtigte Auszahlung für dieses Konto gibt. Ist dies der Fall, wird sie zur Warteschlange hinzugefügt. Der für den nächsten Block vorgesehene Validator knüpft ununterbrochen dort an, wo der vorherige aufgehört hat, und verfährt dabei in stetiger Reihenfolge.
@@ -91,29 +87,29 @@ Es ist notwendig, dass ein Validator, der den nächsten Block vorschlagen soll,
-Stellen Sie sich eine analoge Uhr vor. Der Zeiger der Uhr zeigt auf die Stunde, bewegt sich in eine Richtung, lässt keine Stunden aus und kehrt schließlich nach Erreichen der letzten Zahl wieder an den Anfang zurück.
-Stellen Sie sich nun vor, dass die Uhr statt 1 bis 12 die Zahlen 0 bis N hat (die Gesamtzahl der jemals auf der Konsensus-Ebene registrierten Validatoren-Konten, über 500.000 im Januar 2023).
-Der Zeiger auf der Uhr zeigt auf den nächstenValidator, der auf zulässige Abhebungen geprüft werden muss. Es beginnt bei 0 und schreitet rundherum fort, ohne irgendwelche Konten zu überspringen. Wenn der letzte Validator erreicht ist, beginnt der Zyklus von vorne.
+Stellen Sie sich eine analoge Uhr vor. Der Zeiger auf der Uhr zeigt auf die Stunde, bewegt sich in eine Richtung, überspringt keine Stunden und läuft schließlich wieder zum Anfang zurück, nachdem die letzte Zahl erreicht wurde.
+Stellen Sie sich nun statt 1 bis 12 vor, die Uhr hätte die Zahlen von 0 bis N (die Gesamtzahl der Validatorkonten, die jemals auf der Konsensebene registriert wurden; über 500.000 mit Stand Januar 2023).
+Der Zeiger auf der Uhr zeigt auf den nächsten Validator, der auf berechtigte Auszahlungen geprüft werden muss. Er beginnt bei 0 und schreitet rundherum fort, ohne irgendwelche Konten zu überspringen. Wenn der letzte Validator erreicht ist, beginnt der Zyklus von vorne.
-#### Überprüfung eines Kontos auf Auszahlungen {#checking-an-account-for-withdrawals}
+#### Prüfung eines Kontos auf Auszahlungen {#checking-an-account-for-withdrawals}
Bei der Durchsicht der Validatoren auf mögliche Auszahlungen bewertet der Vorschlagende jeden überprüften Validator mit einer kurzen Fragenreihe. Auf diese Weise wird entschieden, ob eine Auszahlung ausgelöst werden sollte und falls ja, wie viel ETH abgehoben werden soll.
1. **Wurde eine Auszahlungsadresse angegeben?** Wenn keine Auszahlungsadresse angegeben wurde, wird das Konto übersprungen und keine Auszahlung eingeleitet.
-2. **Hat der Validator den Prozess verlassen und ist das Guthaben abhebbar?** Sobald der Validator den Prozess komplett verlassen hat und der Zeitpunkt erreicht ist, in dem das Guthaben des Kontos als „abhebbar" gilt, wird eine vollständige Auszahlung veranlasst. Dies wird das gesamte verbleibende Guthaben an die Auszahlungsadresse übertragen.
-3. **Ist der effektive Kontostand auf 32 begrenzt?** Falls das Konto Auszahlungsberechtigungen besitzt, noch nicht vollständig beendet ist und über 32 anstehende Belohnungen hat, wird eine teilweise Auszahlung vorgenommen. Dabei werden lediglich die über 32 hinausgehenden Belohnungen an die Auszahlungsadresse des Benutzers übertragen.
+2. **Ist der Validator ausgestiegen und ist das Guthaben auszahlbar?** Wenn der Validator vollständig ausgestiegen ist und wir die Epoche erreicht haben, in der sein Konto als „auszahlbar“ gilt, wird eine vollständige Auszahlung verarbeitet. Dies wird das gesamte verbleibende Guthaben an die Auszahlungsadresse übertragen.
+3. **Ist das effektive Guthaben auf 32 begrenzt?** Wenn das Konto über Auszahlungsberechtigungen verfügt, nicht vollständig ausgestiegen ist und auf Belohnungen von über 32 ETH wartet, wird eine Teilauszahlung verarbeitet, bei der nur die Belohnungen über 32 ETH an die Auszahlungsadresse des Benutzers überwiesen werden.
Es gibt nur zwei Aktionen, die von Validatoren während des Lebenszyklus eines Validators durchgeführt werden, die diesen Ablauf direkt beeinflussen:
- Bereitstellung von Auszahlungsberechtigungen, um eine Form von Auszahlung zu ermöglichen
- Verlassen des Netzwerks, was eine vollständige Auszahlung anstößt
-### Kostenfreies Gas {#gas-free}
+### Gasfrei {#gas-free}
-Dieser Ansatz für Staking-Auszahlungen vermeidet, dass Staker manuell eine Transaktion einreichen müssen, die eine bestimmte Menge an ETH zur Auszahlung anfordert. Das bedeutet, dass **kein Gas (Transaktionsgebühr) erforderlich** ist und Auszahlungen auch nicht um den bestehenden Blockplatz der Ausführungsschicht konkurrieren.
+Dieser Ansatz für Staking-Auszahlungen vermeidet, dass Staker manuell eine Transaktion einreichen müssen, die eine bestimmte Menge an ETH zur Auszahlung anfordert. Das bedeutet, dass kein Gas (Transaktionsgebühr) erforderlich ist und Auszahlungen auch nicht um den bestehenden Blockplatz der Ausführungsebene konkurrieren.
### Wie oft erhalte ich meine Staking-Belohnungen? {#how-soon}
@@ -123,13 +119,13 @@ Indem wir diese Berechnung erweitern, können wir die Zeit abschätzen, die ben
-| Anzahl der Auszahlungen | Zeit bis zum Abschluss |
-| :-------------------: | :--------------: |
-| 400,000 | 3,5 Tage |
-| 500,000 | 4,3 Tage |
-| 600,000 | 5,2 Tage |
-| 700,000 | 6,1 Tage |
-| 800,000 | 7,0 Tage |
+| Anzahl der Auszahlungen | Dauer bis zum Abschluss |
+| :---------------------: | :---------------------: |
+| 400.000 | 3,5 Tage |
+| 500.000 | 4,3 Tage |
+| 600.000 | 5,2 Tage |
+| 700.000 | 6,1 Tage |
+| 800.000 | 7,0 Tage |
@@ -138,7 +134,7 @@ Wie Sie sehen, verlangsamt sich dieser Prozess, wenn mehr Validatoren im Netzwer
## Häufig gestellte Fragen {#faq}
@@ -150,7 +146,7 @@ title="Warum kann eine Auszahlungsadresse nur einmal festgelegt werden?"
eventCategory="FAQ"
eventAction="Why can a withdrawal address only be set once?"
eventName="read more">
-Durch die Einstellung einer Ausführungsebene wurden die Auszahlungsberechtigungen für diesen Validator dauerhaft geändert. Das bedeutet, dass die alten Berechtigungen nicht mehr funktionieren, und die neuen Berechtigungen zu einem Ausführungsschicht-Konto führen.
+Durch das Festlegen einer Auszahlungsadresse auf der Ausführungsebene werden die Auszahlungsberechtigungen für diesen Validator dauerhaft geändert. Das bedeutet, dass die alten Berechtigungen nicht mehr funktionieren, und die neuen Berechtigungen zu einem Ausführungsschicht-Konto führen.
Abhebungsadressen können entweder ein intelligenter Vertrag sein (durch seinen Code kontrolliert), oder ein externes Konto (EOA, kontrolliert durch seinen privaten Schlüssel). Aktuell existiert keine Möglichkeit für diese Konten, eine Nachricht zur Konsensschicht zurückzusenden, die eine Änderung der Validator-Anmeldeinformationen anzeigen würde. Eine solche Funktion einzuführen, würde das Protokoll unnötig komplizieren.
@@ -158,15 +154,14 @@ Als Alternative zur Änderung der Auszahlungsadresse für einen bestimmten Valid
-Wenn Sie Teil eines [Staking-Pools](/staking/pools/) sind oder Staking-Token besitzen, sollten Sie sich bei Ihrem Anbieter erkundigen, wie Staking-Auszahlungen gehandhabt werden, da jeder Dienst anders funktioniert.
-
-Im Allgemeinen sollten Benutzer in der Lage sein, ihr zugrundeliegendes gestaktes ETH zurückzufordern oder zu ändern, welchen Staking-Anbieter sie nutzen. Wenn ein bestimmter Pool zu groß wird, können Mittel abgezogen, eingelöst und mit einem kleineren Anbieter neu gestaked werden. Oder, wenn Sie genug ETH angesammelt haben, könnten Sie [von zu Hause aus staken](/staking/solo/).
+Bist du in einem [Staking-Pool](/staking/pools/) oder hältst Staking-Token? Dann frage bei deinem Anbieter nach den Details zur Auszahlung, da die Handhabung je nach Dienst variiert.
+Im Allgemeinen sollten Benutzer in der Lage sein, ihr zugrundeliegendes gestaktes ETH zurückzufordern oder zu ändern, welchen Staking-Anbieter sie nutzen. Wenn ein bestimmter Pool zu groß wird, können Mittel abgezogen, eingelöst und mit einem kleineren Anbieter neu gestaked werden. Alternativ kannst du, wenn du genügend ETH besitzt, auch [von zu Hause aus staken](/staking/solo/).
-Ja, solange Ihr Validator eine Auszahlungsadresse bereitgestellt hat. Diese muss einmal bereitgestellt werden, um Auszahlungen zu ermöglichen, danach werden Belohnungszahlungen automatisch alle paar Tage mit jedem Durchlauf des Validators ausgelöst.
+Ja, solange Ihr Validator eine Auszahlungsadresse angegeben hat. Diese muss einmal bereitgestellt werden, um Auszahlungen zu ermöglichen, danach werden Belohnungszahlungen automatisch alle paar Tage mit jedem Durchlauf des Validators ausgelöst.
Nein, wenn Ihr Validator noch aktiv im Netzwerk ist, erfolgt keine automatische Auszahlung. Dies erfordert das manuelle Einleiten eines freiwilligen Ausstiegs.
Sobald ein Validator den Ausstiegsprozess abgeschlossen hat und vorausgesetzt, das Konto verfügt über Auszahlungsberechtigungen, wird das verbleibende Guthaben dann während des nächsten Validator-Durchlaufs abgehoben.
-
-
-Auszahlungen sind darauf ausgelegt, automatisch durchgeführt zu werden und jegliches ETH zu übertragen, das nicht aktiv zum Staking beiträgt. Dies beinhaltet vollständige Salden für Konten, die den Ausstiegsprozess abgeschlossen haben.
+Auszahlungen sind darauf ausgelegt, automatisch angestoßen zu werden, wobei alle ETH übertragen werden, die nicht aktiv zum Stake beitragen. Dies beinhaltet vollständige Salden für Konten, die den Ausstiegsprozess abgeschlossen haben.
Es ist nicht möglich, manuell spezifische Mengen an ETH zur Auszahlung anzufordern.
Validator-Betreibern wird empfohlen, die Seite Startplattform für Staking-Auszahlungen zu besuchen. Dort können sie mehr Details darüber erfahren, wie Sie Ihren Validator auf Auszahlungen vorbereiten, sowie Informationen zum Zeitpunkt der Ereignisse und zur Funktionsweise von Auszahlungen erhalten.
-Um Ihr Setup zuerst auf einem Testnet auszuprobieren, besuchen Sie das Holesky Testnet Staking Launchpad, um zu beginnen.
-
+Um Ihr Setup zuerst auf einem Testnet auszuprobieren, besuchen Sie das Hoodi Testnet Staking Launchpad, um zu beginnen.
Nein. Sobald ein Validator ausgetreten ist und sein gesamtes Guthaben abgehoben wurde, werden alle zusätzlichen Einzahlungen auf diesen Validator automatisch während des nächsten Validator-Durchlaufs an die Auszahlungsadresse übertragen. Um ETH erneut zu staken, muss ein neuer Validator aktiviert werden.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Startplattform für Staking-Auszahlungen](https://launchpad.ethereum.org/withdrawals)
-- [EIP-4895: Beacon-Kette implementiert Abhebungen als Operationen](https://eips.ethereum.org/EIPS/eip-4895)
-- [PEEPanEIP #94: Auszahlung von gestaktem ETH (Testing) mit Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE)
-- [PEEPanEIP#68: EIP-4895: Auszahlungen per Beacon Chain Push als Operationen mit Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs)
-- [Verständnis der effektiven Bilanz des Validators](https://www.attestant.io/posts/understanding-validator-effective-balance/)
+- [Staking Launchpad-Auszahlungen](https://launchpad.ethereum.org/withdrawals)
+- [EIP-4895: Auszahlungen per Beacon-Chain-Push als Operationen](https://eips.ethereum.org/EIPS/eip-4895)
+- [PEEPanEIP #94: Auszahlung von gestaktem ETH (Test) mit Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE)
+- [PEEPanEIP#68: EIP-4895: Auszahlungen per Beacon-Chain-Push als Operationen mit Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs)
+- [Das effektive Guthaben eines Validators verstehen](https://www.attestant.io/posts/understanding-validator-effective-balance/)
diff --git a/public/content/translations/de/web3/index.md b/public/content/translations/de/web3/index.md
index 557487446cc..c1d8efa8b4d 100644
--- a/public/content/translations/de/web3/index.md
+++ b/public/content/translations/de/web3/index.md
@@ -1,22 +1,27 @@
---
title: Was ist Web3 und warum ist es wichtig?
-description: Eine Einführung in Web3 – die nächste Entwicklung des Internets – und warum es wichtig ist.
+description: "Eine Einführung in Web3 – die nächste Entwicklung des Internets – und warum es wichtig ist."
lang: de
---
# Einführung in Web3 {#introduction}
+
+
+
+
Zentralisierung hat es ermöglicht, dass Milliarden von Menschen Zugang zum Internet haben, und daraus hat sich die stabile, robuste Infrastruktur entwickelt, von der das Internet lebt. Gleichzeitig nimmt eine Handvoll zentralisierter Einheiten eine starke Stellung in weiten Teilen des Internets ein und entscheidet einseitig, was erlaubt sein soll und was nicht.
-Web3 ist die Antwort auf diese Misere. Anstelle eines Internets, das von großen Technologieunternehmen monopolisiert wird, setzt Web3 auf Dezentralisierung und wird von seinen Benutzern aufgebaut, betrieben und gehalten. Web3 legt die Macht in die Hände von Einzelpersonen und nicht von Unternehmen. Bevor wir über Web3 sprechen, sehen wir uns an, wie wir hierher gekommen sind.
+Web3 ist die Antwort auf diese Misere. Anstelle eines Internets, das von großen Technologieunternehmen monopolisiert wird, setzt Web3 auf Dezentralisierung und wird von seinen Benutzern aufgebaut, betrieben und gehalten. Web3 legt die Macht in die Hände von Einzelpersonen und nicht von Unternehmen.
+Bevor wir über Web3 sprechen, sehen wir uns an, wie wir hierher gekommen sind.
-## Das frühe Internet {#early-internet}
+## Das frühe Web {#early-internet}
Die meisten Menschen betrachten das Internet als eine immerwährende Säule des modernen Lebens – es wurde erfunden und existiert seitdem einfach. Doch das Internet, das die meisten von uns heute kennen, ist ganz anders, als es ursprünglich gedacht war. Um das besser zu verstehen, ist es hilfreich, die kurze Geschichte des Internets in lose Phasen zu unterteilen: Web 1.0 und Web 2.0.
-### Web 1.0: nur lesen (1990-2004) {#web1}
+### Web 1.0: Nur Lesen (1990-2004) {#web1}
1989 war Tim Berners-Lee im CERN in Genf mit der Entwicklung der Protokolle beschäftigt, aus denen das Internet entstehen sollte. Was war seine Idee? Offene, dezentrale Protokolle zu schaffen, die einen Informationsaustausch von jedem Ort der Erde aus ermöglichen.
@@ -24,7 +29,7 @@ Die Anfänge des Internets, heute als „Web 1.0" bekannt, liegen etwa zwischen
-### Web 2.0: lesen und schreiben (2004 bis heute) {#web2}
+### Web 2.0: Lesen-Schreiben (2004-heute) {#web2}
Die Zeit des Web 2.0 begann 2004 mit dem Aufkommen der Social-Media-Plattformen. Anstelle eines Nur-Lese-Web entwickelte sich das Internet zu einem Lese-Schreib-Web. Anstatt den Nutzern Inhalte zur Verfügung zu stellen, begannen die Unternehmen, Plattformen für den Austausch von Nutzer-generierten Inhalten und für die Interaktion zwischen den Nutzern anzubieten. Als immer mehr Menschen online gingen, begann eine Handvoll großer Unternehmen einen unverhältnismäßig großen Teil des Datenverkehrs und der im Internet generierten Werte zu kontrollieren. Web 2.0 war auch die Geburtsstunde des werbefinanzierten Umsatzmodells. Nutzer konnten zwar Inhalte erstellen, besaßen sie aber nicht und profitierten auch nicht von deren Verwertung.
@@ -32,24 +37,24 @@ Die Zeit des Web 2.0 begann 2004 mit dem Aufkommen der Social-Media-Plattformen.
-## Web 3.0: lesen, schreiben, besitzen {#web3}
+## Web 3.0: Lesen-Schreiben-Besitzen {#web3}
-Der Begriff "Web 3.0" wurde von [Ethereum](/what-is-ethereum/)-Mitbegründer Gavin Wood kurz nach dem Start von Ethereum im Jahr 2014 geprägt. Gavin formulierte eine Lösung für ein Problem, das viele frühzeitige Krypto-Anwender empfanden: Das Internet erforderte zu viel Vertrauen. Das heißt, der größte Teil des Internets, das die Menschen heute kennen und nutzen, beruht auf dem Vertrauen in eine Handvoll privater Unternehmen, die im Interesse der Öffentlichkeit handeln.
+Die Prämisse von 'Web 3.0' wurde vom [Ethereum](/what-is-ethereum/)-Mitbegründer Gavin Wood kurz nach dem Start von Ethereum im Jahr 2014 geprägt. Gavin formulierte eine Lösung für ein Problem, das viele frühzeitige Krypto-Anwender empfanden: Das Internet erforderte zu viel Vertrauen. Das heißt, der größte Teil des Internets, das die Menschen heute kennen und nutzen, beruht auf dem Vertrauen in eine Handvoll privater Unternehmen, die im Interesse der Öffentlichkeit handeln.
-
+
### Was ist Web3? {#what-is-web3}
-Web3 wurde zu einem Sammelbegriff für die Vision eines neuen, besseren Internets. Im Kern nutzt Web3 Blockchains, Kryptowährungen und NFTs, um den Nutzern Macht in Form von Eigentum zurückzugeben. [Ein Twitter-Beitrag aus dem Jahr 2021](https://twitter.com/j1mmyeth/status/1459003044067258370) bringt es auf den Punkt: Web1 war nur lesen, Web2 ist lesen und schreiben, Web3 wird lesen, schreiben und besitzen sein.
+Web3 wurde zu einem Sammelbegriff für die Vision eines neuen, besseren Internets. Im Kern nutzt Web3 Blockchains, Kryptowährungen und NFTs, um den Nutzern Macht in Form von Eigentum zurückzugeben. [Ein Beitrag auf Twitter aus dem Jahr 2020](https://twitter.com/himgajria/status/1266415636789334016) bringt es auf den Punkt: Web1 war nur lesen, Web2 ist lesen und schreiben, Web3 wird lesen, schreiben und besitzen sein.
-#### Der Kern von Web3 {#core-ideas}
+#### Kerngedanken von Web3 {#core-ideas}
Obwohl es schwierig ist, sich auf eine eindeutige Definition von Web3 festzulegen, gibt es doch einige Grundprinzipien, die für seine Entwicklung maßgeblich sind.
-- **Web3 ist dezentralisiert:** Statt große Teile des Internets von zentralisierten Einrichtungen kontrollieren und in deren Besitz zu lassen, wird das Eigentum unter seinen Erstellern und Nutzern verteilt.
-- **Web3 ist berechtigungsfrei:** Jeder hat den gleichen Zugang zur Teilnahme an Web3 und niemand wird ausgeschlossen.
-- **Web3 verfügt über native Zahlungen:** Es verwendet Kryptowährungen, um online Geld auszugeben oder zu versenden, anstatt sich auf die veraltete Infrastruktur von Banken und Zahlungsdienstleistern zu verlassen.
-- **Im Web3 braucht es kein Vertrauen:** Es arbeitet mit Anreizen und wirtschaftlichen Mechanismen, anstatt sich auf vertrauenswürdige Dritte zu verlassen.
+- **Web3 ist dezentralisiert:** Statt dass große Teile des Internets von zentralisierten Einrichtungen kontrolliert und besessen werden, wird das Eigentum unter seinen Erbauern und Nutzern verteilt.
+- **Web3 ist genehmigungsfrei:** Jeder hat den gleichen Zugang zur Teilnahme an Web3, und niemand wird ausgeschlossen.
+- **Web3 verfügt über native Zahlungen:** Es verwendet Kryptowährung, um online Geld auszugeben und zu versenden, anstatt sich auf die veraltete Infrastruktur von Banken und Zahlungsabwicklern zu verlassen.
+- **Web3 ist vertrauenslos:** Es arbeitet mit Anreizen und wirtschaftlichen Mechanismen, anstatt sich auf vertrauenswürdige Dritte zu verlassen.
### Warum ist Web3 wichtig? {#why-is-web3-important}
@@ -59,7 +64,7 @@ Obwohl sich die großartigen Funktionen von Web3 nicht klar voneinander abgrenze
Web3 verschafft Ihnen auf eine beispiellose Weise das Eigentum an Ihren digitalen Ressourcen. Nehmen wir beispielsweise an, Sie spielen ein Web2-Spiel. Kaufen Sie einen Gegenstand im Spiel, ist dieser direkt an Ihr Konto gebunden. Wenn die Anbieter des Spiels Ihr Konto löschen, verlieren Sie diese Gegenstände. Oder wenn Sie das Spiel nicht mehr spielen, verlieren Sie den Wert, den Sie in die Spielgegenstände investiert haben.
-Web3 ermöglicht direktes Eigentum durch [nicht-austauschbare Token (NFTs)](/glossary/#nft). Niemand, nicht einmal die Macher des Spiels, hat die Macht, Ihnen Ihr Eigentum wegzunehmen. Und sollten Sie mit dem Spielen aufhören, können Sie Ihre Spielgegenstände auf offenen Märkten verkaufen oder tauschen und so ihren Wert zurückerlangen.
+Web3 ermöglicht direktes Eigentum durch [nicht-fungible Token (NFTs)](/glossary/#nft). Niemand, nicht einmal die Macher des Spiels, hat die Macht, Ihnen Ihr Eigentum wegzunehmen. Und sollten Sie mit dem Spielen aufhören, können Sie Ihre Spielgegenstände auf offenen Märkten verkaufen oder tauschen und so ihren Wert zurückerlangen. Entdecke [Onchain-Gaming](/gaming/), um dies in Aktion zu sehen.
@@ -71,7 +76,7 @@ Web3 ermöglicht direktes Eigentum durch [nicht-austauschbare Token (NFTs)](/glo
-#### Resistent gegenüber Zensur {#censorship-resistance}
+#### Zensurresistenz {#censorship-resistance}
Die Machtverteilung zwischen Plattformen und den Urhebern von Inhalten ist äußerst unausgewogen.
@@ -81,11 +86,11 @@ Bei Web3 befinden sich die Daten in der Blockchain. Wenn Sie sich entscheiden, e
Im Web 2.0 müssen die Urheber von Inhalten darauf vertrauen, dass die Plattformen die Regeln nicht ändern. Doch Resistenz gegenüber Zensur ist eine grundlegende Eigenschaft von Web3-Plattformen.
-#### Dezentralisierte Autonome Organisationen (DAO) {#daos}
+#### Dezentrale autonome Organisationen (DAOs) {#daos}
Neben dem Besitz Ihrer Daten in Web3 können Sie die Plattform als Kollektiv besitzen und dabei Token verwenden, die wie Aktien eines Unternehmens wirken. Mit DAOs können Sie dezentrale Eigentumsverhältnisse einer Plattform koordinieren und Entscheidungen über dessen Zukunft treffen.
-DAOs werden technisch definiert als vereinbarte [Smart Contracts](/glossary/#smart-contract), die eine dezentralisierte Entscheidungsfindung über einen Pool von Ressourcen (Tokens) automatisieren. Benutzer mit Token stimmen darüber ab, wie Ressourcen verwendet werden, und der Code führt automatisch das Abstimmungsergebnis aus.
+DAOs sind technisch als vereinbarte [Smart Contracts](/glossary/#smart-contract) definiert, die die dezentralisierte Entscheidungsfindung über einen Pool von Ressourcen (Tokens) automatisieren. Benutzer mit Token stimmen darüber ab, wie Ressourcen verwendet werden, und der Code führt automatisch das Abstimmungsergebnis aus.
Allerdings definieren Menschen viele Web3-Communities als DAOs. Diese Gemeinschaften haben alle unterschiedliche Ebenen der Dezentralisierung und Automatisierung per Code. Derzeit untersuchen wir, was DAOs sind und wie sie sich in Zukunft entwickeln könnten.
@@ -103,33 +108,34 @@ Allerdings definieren Menschen viele Web3-Communities als DAOs. Diese Gemeinscha
Normalerweise würden Sie für jede von Ihnen genutzte Plattform ein Konto anlegen. Vielleicht haben Sie zum Beispiel ein Twitter-Konto, ein YouTube-Konto und ein Reddit-Konto. Möchten Sie Ihren Anzeigenamen oder Ihr Profilbild ändern? Dann müssen Sie das für jedes einzelne Konto tun. In einigen Fällen können Sie sich über soziale Netzwerke anmelden, aber das birgt ein bekanntes Problem: Zensur. Mit einem einzigen Klick können diese Plattformen Sie aus Ihrem gesamten Online-Leben aussperren. Schlimmer noch, viele Plattformen verlangen, dass Sie ihnen persönliche Daten anvertrauen, um ein Konto zu erstellen.
-Web3 löst diese Probleme, indem es Ihnen ermöglicht, Ihre digitale Identität mit einer Ethereum-Adresse und einem Profil für Ihren [Ethereum Name Service (ENS)](/glossary/#ens) zu steuern. Wenn Sie eine Ethereum-Adresse benutzen, können Sie eine einzige plattformübergreifende Anmeldung nutzen, die sicher, zensurresistent und anonym ist.
+Web3 löst diese Probleme, indem es dir ermöglicht, deine digitale Identität mit einer Ethereum-Adresse und einem [Ethereum Name Service (ENS)](/glossary/#ens)-Profil zu steuern. Wenn Sie eine Ethereum-Adresse benutzen, können Sie eine einzige plattformübergreifende Anmeldung nutzen, die sicher, zensurresistent und anonym ist.
-### Ursprüngliche Zahlungen {#native-payments}
+### Native Zahlungen {#native-payments}
-Die Zahlungsinfrastruktur von Web2 stützt sich auf Banken und Zahlungsdienstleister und schließt Menschen ohne Bankkonto oder solche, die zufällig im falschen Land leben, aus. Web3 verwendet Token wie [ETH](/glossary/#ether), um Geld direkt im Browser zu senden, und benötigt keine vertrauenswürdige dritte Partei.
+Die Zahlungsinfrastruktur von Web2 stützt sich auf Banken und Zahlungsdienstleister und schließt Menschen ohne Bankkonto oder solche, die zufällig im falschen Land leben, aus.
+Web3 verwendet Token wie [ETH](/glossary/#ether), um Geld direkt im Browser zu senden, und benötigt keine vertrauenswürdige dritte Partei.
Mehr zu ETH
-## Web3-Einschränkungen {#web3-limitations}
+## Einschränkungen von Web3 {#web3-limitations}
Trotz der zahlreichen Vorteile von Web3 in seiner jetzigen Form gibt es nach wie vor viele Einschränkungen, die das Ökosystem überwinden muss, um sich weiter zu entfalten.
### Zugänglichkeit {#accessibility}
-Wichtige Web3-Funktionen, wie z. B. das Anmelden mit Ethereum, sind bereits für jedermann zum Nulltarif verfügbar. Doch die relativen Transaktionskosten sind für viele noch immer unerschwinglich. Es ist wahrscheinlich, dass Web3 aufgrund der hohen Transaktionsgebühren in weniger wohlhabenden Entwicklungsländern womöglich weniger genutzt wird. Bei Ethereum werden diese Herausforderungen durch [die Roadmap](/roadmap/) und [Layer-2-Skalierungslösungen](/glossary/#layer-2) bewältigt. Die Technologie steht bereit. Doch wir benötigen einen höheren Grad an Akzeptanz auf Ebene 2, um Web3 allen zugänglich zu machen.
+Wichtige Web3-Funktionen, wie z. B. das Anmelden mit Ethereum, sind bereits für jedermann zum Nulltarif verfügbar. Doch die relativen Transaktionskosten sind für viele noch immer unerschwinglich. Es ist wahrscheinlich, dass Web3 aufgrund der hohen Transaktionsgebühren in weniger wohlhabenden Entwicklungsländern womöglich weniger genutzt wird. Auf Ethereum werden diese Herausforderungen durch [die Roadmap](/roadmap/) und [Layer-2-Skalierungslösungen](/glossary/#layer-2) bewältigt. Die Technologie steht bereit. Doch wir benötigen einen höheren Grad an Akzeptanz auf Ebene 2, um Web3 allen zugänglich zu machen.
### Benutzererfahrung {#user-experience}
-Die technische Hürde für den Einstieg in die Nutzung von Web3 ist derzeit zu hoch. Benutzer müssen sich mit Sicherheitsfragen auseinandersetzen, komplexe technische Dokumentationen verstehen und sich auf Benutzeroberflächen zurechtfinden, die keine intuitive Navigation bieten. Insbesondere [Wallet-Anbieter](/wallets/find-wallet/) arbeiten an der Lösung dieses Problems, doch es sind noch weitere Fortschritte nötig, bevor sich Web3 großflächig etabliert.
+Die technische Hürde für den Einstieg in die Nutzung von Web3 ist derzeit zu hoch. Benutzer müssen sich mit Sicherheitsfragen auseinandersetzen, komplexe technische Dokumentationen verstehen und sich auf Benutzeroberflächen zurechtfinden, die keine intuitive Navigation bieten. Insbesondere [Wallet-Anbieter](/wallets/find-wallet/) arbeiten an der Lösung dieses Problems, aber es sind noch weitere Fortschritte nötig, bevor sich Web3 großflächig durchsetzt.
### Bildung {#education}
-Web3 führt neue Paradigmen ein, für die es erforderlich ist, andere Denkmuster als die im Web2.0 verwendeten zu erlernen. Eine ähnliche Aufklärungskampagne fand statt, als das Web1.0 in den späten 1990er Jahren an Popularität gewann. Die Befürworter des World Wide Web nutzten eine Reihe von Aufklärungstechniken, um die Öffentlichkeit aufzuklären, von einfachen Metaphern (die Datenautobahn, Browser, Surfen im Web) bis hin zu [TV-Übertragungen](https://www.youtube.com/watch?v=SzQLI7BxfYI). Web3 ist nicht schwierig, es ist einfach anders. Aufklärungsinitiativen, die Web2-Nutzer über diese Web3-Paradigmen informieren, sind für den Erfolg von entscheidender Bedeutung.
+Web3 führt neue Paradigmen ein, für die es erforderlich ist, andere Denkmuster als die im Web2.0 verwendeten zu erlernen. Eine ähnliche Aufklärungskampagne fand statt, als Web1.0 in den späten 1990er Jahren an Popularität gewann; Befürworter des World Wide Web nutzten eine Reihe von Bildungstechniken, um die Öffentlichkeit aufzuklären, von einfachen Metaphern (die Datenautobahn, Browser, Surfen im Web) bis hin zu [Fernsehübertragungen](https://www.youtube.com/watch?v=SzQLI7BxfYI). Web3 ist nicht schwierig, es ist einfach anders. Aufklärungsinitiativen, die Web2-Nutzer über diese Web3-Paradigmen informieren, sind für den Erfolg von entscheidender Bedeutung.
-Ethereum.org trägt zur Aufklärung über Web3 durch unser [Übersetzungsprogramm](/contributing/translation-program/) bei, das darauf abzielt, wichtige Ethereum-Inhalte in so viele Sprachen wie möglich zu übersetzen.
+Ethereum.org trägt durch unser [Übersetzungsprogramm](/contributing/translation-program/) zur Web3-Bildung bei, das darauf abzielt, wichtige Ethereum-Inhalte in so viele Sprachen wie möglich zu übersetzen.
### Zentralisierte Infrastruktur {#centralized-infrastructure}
@@ -141,23 +147,23 @@ Web3 ist ein junges und sich weiterentwickelndes Ökosystem. Gavin Wood prägte
Wir stehen erst am Anfang der Entwicklung eines besseren Internets mit Web3, doch mit der weiteren Verbesserung der dafür erforderlichen Infrastruktur sieht die Zukunft des Internets rosig aus.
-## Wie kann ich mich einbringen {#get-involved}
+## Wie kann ich mitmachen? {#get-involved}
-- [Eine Wallet wählen](/wallets/)
-- [Eine Community finden](/community/)
-- [Web3-Anwendungen erkunden](/apps/)
-- [Einer DAO beitreten](/dao/)
-- [Web3 als Grundlage nutzen](/developers/)
+- [Hol dir eine Wallet](/wallets/)
+- [Finde eine Community](/community/)
+- [Erkunde Web3-Anwendungen](/apps/)
+- [Tritt einer DAO bei](/dao/)
+- [Entwickle auf Web3](/developers/)
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
Web3 ist nicht starr definiert. Zahlreiche Community-Teilnehmer haben unterschiedliche Ansichten dazu. Hier sind einige von ihnen:
-- [Was ist Web3? Das dezentralisierte Internet der Zukunft erklärt](https://www.freecodecamp.org/news/what-is-web3) – _Nader Dabit_
-- [Sinnhaftigkeit von Web3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) _, Josh Stark_
-- [Warum Web3 wichtig ist](https://future.a16z.com/why-web3-matters/) – _Chris Dixon_
-- [Warum Dezentralisierung wichtig ist](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) – _Chris Dixon_
-- [Die Web3-Landschaft](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_
-- [Die Web3-Debatte](https://www.notboring.co/p/the-web3-debate) – _Packy McCormick_
+- [Was ist Web3? The Decentralized Internet of the Future Explained](https://www.freecodecamp.org/news/what-is-web3) – _Nader Dabit_
+- [Making Sense of Web 3](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _Josh Stark_
+- [Why Web3 Matters](https://a16zcrypto.com/posts/article/why-web3-matters/) — _Chris Dixon_
+- [Why Decentralization Matters](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) - _Chris Dixon_
+- [The Web3 Landscape](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_
+- [The Web3 Debate](https://www.notboring.co/p/the-web3-debate) – _Packy McCormick_
diff --git a/public/content/translations/de/what-are-apps/index.md b/public/content/translations/de/what-are-apps/index.md
new file mode 100644
index 00000000000..7799ff1e5a5
--- /dev/null
+++ b/public/content/translations/de/what-are-apps/index.md
@@ -0,0 +1,80 @@
+---
+title: Ethereum-Anwendungen
+metaTitle: Ethereum Anwendungen | Dezentrale Anwendungen auf Ethereum
+description: "Ethereum-Apps sind kostenlos, global nutzbar und basieren auf öffentlichen Blockchains statt auf privaten Unternehmensservern. Das heißt, Sie können in allen Projekten das gleiche Konto nutzen, und gleichzeitig Ihre Privatsphäre wahren."
+lang: de
+template: use-cases
+emoji: ":handshake:"
+sidebarDepth: 2
+showDropdown: false
+image: /images/doge-computer.png
+summary: "Ethereum-Apps sind kostenlos, global nutzbar und basieren auf öffentlichen Blockchains statt auf privaten Unternehmensservern. Das heißt, Sie können in allen Projekten das gleiche Konto nutzen, und gleichzeitig Ihre Privatsphäre wahren."
+---
+
+## Apps mit Superpower {#apps-with-superpowers}
+
+Ethereum-Anwendungen können sich wie normale Apps anfühlen. Doch im Hintergrund verfügen sie über besondere Eigenschaften.
+
+Einmal auf der Ethereum-Blockchain veröffentlicht, kann eine App nicht mehr gestoppt werden. Das liegt daran, dass das Ethereum-Netzwerk über Tausende von Computern weltweit dezentral verteilt ist. Apps auf Ethereum können nicht gestoppt werden, da es keinen einzelnen Server gibt, der angegriffen werden könnte. Ethereum ist neutral, sodass jeder, überall auf der Welt darauf zugreifen, benutzen, und eigene Erweiterungen darauf entwickeln kann.
+
+## Was ist eine dApp? {#what-is-a-dapp}
+
+Die Logik von Ethereum-Anwendungen läuft auf der Ethereum-Blockchain und nicht auf zentralen Servern. Deswegen werden sie häufig als dezentrale Anwendungen, kurz dApps, bezeichnet.
+
+
+
+
+
+
+
+## Warum ist das wichtig? {#why-does-this-matter}
+
+Ethereum-Apps können Dinge tun, die mit traditionellen Apps unmöglich wären. Zum Beispiel Geld an einen völlig Fremden verleihen, mit der Garantie, dass man das Geld inklusive Zinsen zurückbekommt. Ganz ohne einen 'vertrauenswürdigen' Mittelsmann wie einen Anwalt, der die Transaktion abwickelt.
+
+Es gibt Apps für alles: Gaming, Finanzen, Arbeit, Messaging, Speicher und viele mehr. Die meisten Apps laufen werbefrei und sind nicht durch eingeschränkten Zugang begrenzt.
+
+Sie benötigen lediglich eine Ethereum-Wallet und ein wenig ETH, um jede beliebige Ethereum-App nutzen zu können.
+
+## Wie funktioniert das? {#how-does-it-work}
+
+Apps laufen über Smart Contracts - Programmcodes, die auf der Ethereum-Blockchain ausgeführt werden. Anders als herkömmliche Apps brauchen sie kein Unternehmen, um zu funktionieren.
+
+| Funktion | Traditionelle Apps | Ethereum-Apps |
+| ----------------------------- | ---------------------------- | ------------------------------- |
+| **Wer kontrolliert sie?** | Ein Unternehmen | Keiner |
+| **Läuft auf** | Privaten Unternehmensservern | Öffentliche Ethereum-Blockchain |
+| **Kann sie zensiert werden?** | Ja | Nein |
+| **Wer besitzt Ihr Daten?** | Normalerweise nicht Sie | Sie besitzen Ihre Daten |
+
+
+
+
+
+
+
+
+## Ethereum-Apps sind wie Legosteine {#ethereum-apps-are-like-legos}
+
+Alle Apps auf Ethereum sind kompatibel miteinander. Ein Token für eine App funktioniert problemlos in einer anderen. Das ist, als würden Sie Tweets direkt auf Ihrer Facebook-Wand posten können. Sie können sogar dieselben Profile in vielen verschiedenen Ethereum-Apps nutzen, ohne sich überall separat zu registrieren.
+
+
+
+## Weiterführende Lektüre {#further-reading}
+
+- [Ethereum für Anfänger](/what-is-ethereum)
+- [Was ist ein Smart Contract?](/developers/docs/smart-contracts/)
+- [Technische Dapp Dokumentation](/developers/docs/dapps/)
+
+## Häufig gestellte Fragen {#faq}
+
+
+ Dapp steht für dezentrale Anwendungen. Diese werden auf Blockchain-Netzwerken wie Ethereum gebaut. Man nennt sie dezentral, da das darunterliegende Netzwerk dezentralisiert ist.
+
+
+
+ Mit einigen Anwendungen können Sie Krypto-Tokens verhandeln oder kaufen, aber nicht alle Apps sind dafür gedacht. Wenn Sie Ihre ersten Token kaufen möchten, besuchen Sie [ETH kaufen](/get-eth).
+
+
+
+ Mit einer Krypto-Wallet können Sie Ihre Tokens sicher aufbewahren und Ihr Ethereum-Account einfach verwalten. Es gibt zahlreiche gute Wallets, die jeweils für unterschiedliche Zwecke entwickelt wurden. Um herauszufinden, welche Wallet für Sie am besten geeignet ist, besuchen Sie unsere [Liste der Wallets](/wallets/find-wallet).
+
\ No newline at end of file
diff --git a/public/content/translations/de/whitepaper/index.md b/public/content/translations/de/whitepaper/index.md
index ac993b51584..55187467578 100644
--- a/public/content/translations/de/whitepaper/index.md
+++ b/public/content/translations/de/whitepaper/index.md
@@ -1,6 +1,6 @@
---
title: Ethereum Whitepaper
-description: Eine einleitende Arbeit zu Ethereum, veröffentlicht im Jahr 2013 vor seiner Einführung.
+description: "Eine einleitende Arbeit zu Ethereum, veröffentlicht im Jahr 2013 vor seiner Einführung."
lang: de
sidebarDepth: 2
hideEditButton: true
@@ -8,32 +8,32 @@ hideEditButton: true
# Ethereum Whitepaper {#ethereum-whitepaper}
-_Diese einleitende Arbeit wurde ursprünglich 2014 von Vitalik Buterin, dem Gründer von [Ethereum](/what-is-ethereum/), vor dem Projektstart im Jahr 2015 veröffentlicht. Es ist erwähnenswert, dass sich Ethereum, wie viele gemeinschaftlich gesteuerte Open-Source-Softwareprojekte, seit seiner anfänglichen Einführung weiterentwickelt hat._
+_Dieses Einführungspapier wurde ursprünglich 2014 von Vitalik Buterin, dem Gründer von [Ethereum](/what-is-ethereum/), vor dem Start des Projekts im Jahr 2015 veröffentlicht. Es ist erwähnenswert, dass sich Ethereum, wie viele gemeinschaftlich gesteuerte Open-Source-Softwareprojekte, seit seiner anfänglichen Einführung weiterentwickelt hat._
-_Obwohl diese Arbeit schon einige Jahre alt ist, pflegen wir sie nach wie vor, weil sie weiterhin als nützliche Referenz und präzise Darstellung von Ethereum und seiner Vision dient. Um mehr über die neuesten Entwicklungen von Ethereum und dazu zu erfahren, wie Änderungen am Protokoll vorgenommen werden, empfehlen wir [diese Anleitung](/learn/)._
+_Obwohl diese Arbeit schon einige Jahre alt ist, pflegen wir sie nach wie vor, weil sie weiterhin als nützliche Referenz und präzise Darstellung von Ethereum und seiner Vision dient. _Um mehr über die neuesten Entwicklungen von Ethereum und darüber zu erfahren, wie Änderungen am Protokoll vorgenommen werden, empfehlen wir [diesen Leitfaden](/learn/)._
-[Forscher und Akademiker, die eine historische oder kanonische Version des Whitepapers [vom Dezember 2014] suchen, sollten diese PDF-Datei verwenden.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf)
+[Forscher und Akademiker, die eine historische oder kanonische Version des Whitepapers [vom Dezember 2014] suchen, sollten dieses PDF verwenden.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf)
-## Eine Plattform der nächsten Generation für Smart Contracts und dezentralisierte Anwendungen {#a-next-generation-smart-contract-and-decentralized-application-platform}
+## Eine Smart-Contract- und dezentralisierte Anwendungsplattform der nächsten Generation {#a-next-generation-smart-contract-and-decentralized-application-platform}
-Satoshi Nakamotos Entwicklung von Bitcoin im Jahr 2009 wurde oft als radikale Weiterentwicklung von Geld und Währung gefeiert, da es sich dabei um das erste Beispiel eines digitalen Assets handelt, das weder eine Besicherung noch einen "[intrinsischen Wert](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)" oder einen zentralisierten Herausgeber oder Kontrolleur hat. Ein anderer, wohl wichtigerer Teil des Bitcoin-Experiments ist jedoch die zugrunde liegende Blockchain-Technologie als Instrument des verteilten Konsenses, und so verlagert sich die Aufmerksamkeit rasch auf diesen anderen Aspekt von Bitcoin. Zu den häufig zitierten alternativen Anwendungen der Blockchain-Technologie gehören die Verwendung digitaler Assets auf der Blockchain zur Darstellung benutzerdefinierter Währungen und Finanzinstrumente („[Colored Coins](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)“), das Eigentum an einem zugrunde liegenden physischen Gerät („[Smart Property](https://en.bitcoin.it/wiki/Smart_Property)“), nicht vertretbare Assets wie Domänennamen („[Namecoin](http://namecoin.org)“) sowie komplexere Anwendungen, bei denen digitale Assets direkt von einem Stück Code kontrolliert und beliebige Regeln ("[Smart Contracts](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") oder sogar Blockchain-basierte „[dezentralisierte autonome Organisationen](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)“ (DAOs) implementiert werden. Ethereum beabsichtigt, eine Blockchain mit einer eingebauten, vollwertigen, Turing-kompletten Programmiersprache bereitzustellen, die zur Erstellung von „Verträgen“ verwendet werden kann, mit denen beliebige Statusübergangsfunktionen kodiert werden können, so dass Benutzer jedes der oben beschriebenen Systeme sowie viele andere, die wir uns noch nicht vorstellen können, erstellen können. Dazu muss nur eine entsprechende Logik in ein paar Zeilen Code geschrieben werden.
+Satoshi Nakamotos Entwicklung von Bitcoin im Jahr 2009 wurde oft als radikale Entwicklung in Geld und Währung gefeiert, da es das erste Beispiel eines digitalen Vermögenswerts ist, der gleichzeitig keine Deckung oder "[intrinsischen Wert](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it)" und keinen zentralisierten Emittenten oder Kontrolleur hat. Ein anderer, wohl wichtigerer Teil des Bitcoin-Experiments ist jedoch die zugrunde liegende Blockchain-Technologie als Instrument des verteilten Konsenses, und so verlagert sich die Aufmerksamkeit rasch auf diesen anderen Aspekt von Bitcoin. Häufig genannte alternative Anwendungen der Blockchain-Technologie umfassen die Verwendung von On-Blockchain-Digital-Assets zur Darstellung benutzerdefinierter Währungen und Finanzinstrumente ("[Colored Coins](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)"), das Eigentum an einem zugrunde liegenden physischen Gerät ("[Smart Property](https://en.bitcoin.it/wiki/Smart_Property)"), nicht-fungible Vermögenswerte wie Domainnamen ("[Namecoin](http://namecoin.org)") sowie komplexere Anwendungen, bei denen digitale Vermögenswerte direkt von einem Stück Code gesteuert werden, das beliebige Regeln implementiert ("[Smart Contracts](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)") oder sogar blockchainbasierte "[dezentrale autonome Organisationen](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)" (DAOs). Ethereum beabsichtigt, eine Blockchain mit einer eingebauten, vollwertigen, Turing-kompletten Programmiersprache bereitzustellen, die zur Erstellung von „Verträgen“ verwendet werden kann, mit denen beliebige Statusübergangsfunktionen kodiert werden können, so dass Benutzer jedes der oben beschriebenen Systeme sowie viele andere, die wir uns noch nicht vorstellen können, erstellen können. Dazu muss nur eine entsprechende Logik in ein paar Zeilen Code geschrieben werden.
## Einführung in Bitcoin und bestehende Konzepte {#introduction-to-bitcoin-and-existing-concepts}
-### Historie {#history}
+### Geschichte {#history}
-Das Konzept der dezentralisierten digitalen Währung sowie alternativer Anwendungen wie Eigentumsregistern gibt es seit Jahrzehnten. Die anonymen E-Cash-Protokolle der 1980er und 1990er Jahre, die sich hauptsächlich auf ein kryptografisches Primitiv stützten, das als Chaumian Blinding bekannt ist, boten eine Währung mit einem hohen Maß an Datenschutz, aber die Protokolle konnten sich aufgrund ihrer Abhängigkeit von einem zentralisierten Vermittler größtenteils nicht durchsetzen. 1998 war Wei Dais [b-money](http://www.weidai.com/bmoney.txt) der erste Vorschlag, der die Idee der Geldschöpfung durch das Lösen von Rechenrätseln und einen dezentralen Konsens vorstellte, aber der Vorschlag enthielt nur wenige Details darüber, wie der dezentralisiertee Konsens tatsächlich umgesetzt werden könnte. 2005 stellte Hal Finney das Konzept der „[wiederverwendbaren Proofs of Work](https://nakamotoinstitute.org/finney/rpow/)“ vor, ein System, das Ideen von b-money zusammen mit Adam Backs schwierig zu berechnenden Hashcash-Puzzles verwendet, um ein Konzept für eine Kryptowährung zu schaffen, aber auch hier blieb es hinter dem Ideal zurück, da es sich auf vertrauenswürdige Rechner als Backend stützte. 2009 setzte Satoshi Nakamoto zum ersten Mal eine dezentralisierte Währung durch die Kombination von Kryptografie mit öffentlichem Schlüssel und einem Konsensalgorithmus zur Nachverfolgung der Eigentumsverhältnisse von Coins, dem sogenannten „Proof-of-Work“, in die Praxis umgesetzt.
+Das Konzept der dezentralisierten digitalen Währung sowie alternativer Anwendungen wie Eigentumsregistern gibt es seit Jahrzehnten. Die anonymen E-Cash-Protokolle der 1980er und 1990er Jahre, die sich hauptsächlich auf ein kryptografisches Primitiv stützten, das als Chaumian Blinding bekannt ist, boten eine Währung mit einem hohen Maß an Datenschutz, aber die Protokolle konnten sich aufgrund ihrer Abhängigkeit von einem zentralisierten Vermittler größtenteils nicht durchsetzen. 1998 wurde Wei Dais [b-money](http://www.weidai.com/bmoney.txt) der erste Vorschlag, der die Idee der Geldschöpfung durch die Lösung von Rechenrätseln sowie eines dezentralen Konsens einführte, aber der Vorschlag enthielt nur wenige Details darüber, wie ein dezentraler Konsens tatsächlich umgesetzt werden könnte. Im Jahr 2005 führte Hal Finney ein Konzept von „[wiederverwendbaren Proofs of Work](https://nakamotoinstitute.org/finney/rpow/)“ ein, ein System, das Ideen von b-money zusammen mit Adam Backs rechnerisch schwierigen Hashcash-Puzzles verwendet, um ein Konzept für eine Kryptowährung zu schaffen, das aber wieder einmal hinter dem Ideal zurückblieb, da es auf Trusted Computing als Backend angewiesen war. 2009 setzte Satoshi Nakamoto zum ersten Mal eine dezentralisierte Währung durch die Kombination von Kryptografie mit öffentlichem Schlüssel und einem Konsensalgorithmus zur Nachverfolgung der Eigentumsverhältnisse von Coins, dem sogenannten „Proof-of-Work“, in die Praxis umgesetzt.
-Der Mechanismus hinter Proof-of-Work war ein Durchbruch in diesem Bereich, da er zwei Probleme gleichzeitig löste. Erstens bot er einen einfachen und einigermaßen effektiven Konsensalgorithmus, der es den Knoten im Netzwerk ermöglichte, sich gemeinsam auf eine Reihe kanonischer Aktualisierungen des Status des Bitcoin-Ledgers zu einigen. Zweitens wurde ein Mechanismus bereitgestellt, der den freien Eintritt in den Konsensprozess ermöglicht und das politische Problem der Entscheidung darüber, wer den Konsens beeinflussen darf, löst, während gleichzeitig Sybil-Angriffe verhindert werden. Dies geschieht, indem eine formale Barriere für die Teilnahme, wie z. B. das Erfordernis, als eindeutige Einheit auf einer bestimmten Liste registriert zu sein, durch eine wirtschaftliche Barriere ersetzt wird – das Gewicht eines einzelnen Knotens im Konsensabstimmungsprozess ist direkt proportional zur Rechenleistung, die der Knoten bereitstellt. Seitdem wurde ein alternativer Ansatz namens _Proof-of-Stake_ vorgeschlagen, bei dem die Gewichtung eines Knotens proportional zu seinen Währungsbeständen und nicht zu seinen Rechenressourcen erfolgt; die Erörterung der relativen Vorzüge der beiden Ansätze würde den Rahmen dieser Arbeit sprengen, aber es sei darauf hingewiesen, dass beide Ansätze als Rückgrat einer Kryptowährung dienen können.
+Der Mechanismus hinter Proof-of-Work war ein Durchbruch in diesem Bereich, da er zwei Probleme gleichzeitig löste. Erstens bot er einen einfachen und einigermaßen effektiven Konsensalgorithmus, der es den Knoten im Netzwerk ermöglichte, sich gemeinsam auf eine Reihe kanonischer Aktualisierungen des Status des Bitcoin-Ledgers zu einigen. Zweitens wurde ein Mechanismus bereitgestellt, der den freien Eintritt in den Konsensprozess ermöglicht und das politische Problem der Entscheidung darüber, wer den Konsens beeinflussen darf, löst, während gleichzeitig Sybil-Angriffe verhindert werden. Dies geschieht, indem eine formale Barriere für die Teilnahme, wie z. B. das Erfordernis, als eindeutige Einheit auf einer bestimmten Liste registriert zu sein, durch eine wirtschaftliche Barriere ersetzt wird – das Gewicht eines einzelnen Knotens im Konsensabstimmungsprozess ist direkt proportional zur Rechenleistung, die der Knoten bereitstellt. Seitdem wurde ein alternativer Ansatz namens _Proof-of-Stake_ vorgeschlagen, bei dem das Gewicht eines Knotens proportional zu seinen Währungsbeständen und nicht zu den Rechenressourcen berechnet wird; die Diskussion der relativen Vorzüge der beiden Ansätze würde den Rahmen dieses Papiers sprengen, aber es sollte beachtet werden, dass beide Ansätze als Rückgrat einer Kryptowährung dienen können.
-### Bitcoin als Statusübergangssystem {#bitcoin-as-a-state-transition-system}
+### Bitcoin als Zustandsübergangssystem {#bitcoin-as-a-state-transition-system}
-
+
Aus technischer Sicht kann man sich das Ledger einer Kryptowährung wie Bitcoin als ein Statusübergangssystem vorstellen, bei dem es einen „Status“ gibt, der aus dem Eigentumsstatus aller vorhandenen Bitcoins besteht, und eine „Statusübergangsfunktion“, die einen Status und eine Transaktion annimmt und einen neuen Status als Ergebnis ausgibt. In einem Standard-Banksystem beispielsweise ist der Status eine Bilanzaufstellung, eine Transaktion ist eine Anforderung, X $ von A nach B zu verschieben, und die Statusübergangsfunktion verringert den Wert auf dem Konto von A um X $ und erhöht den Wert auf dem Konto von B um X $. Wenn das Konto von A von vornherein weniger als X $ aufweist, gibt die Statusfunktion einen Fehler zurück. Daher kann man formell definieren:
```
-APPLY(S,TX) -> S' or ERROR
+APPLY(S,TX) -> S' oder ERROR
```
In dem oben definierten Bankensystem:
@@ -50,11 +50,11 @@ APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR
Der „Status“ in Bitcoin ist die Sammlung aller Münzen (technisch gesehen „unverbrauchte Transaktionsausgaben“ oder UTXO), die geprägt und noch nicht ausgegeben wurden, wobei jede UTXO einen Nennwert und einen Eigentümer hat (definiert durch eine 20-Byte-Adresse, die im Wesentlichen ein kryptografischer öffentlicher Schlüssel ist[fn1](#notes)). Eine Transaktion enthält eine oder mehrere Eingaben, wobei jede Eingabe eine Referenz auf einen bestehenden UTXO und eine kryptografische Signatur enthält, die durch den privaten Schlüssel erzeugt wurde, der mit der Adresse des Eigentümers verknüpft ist, sowie eine oder mehrere Ausgaben, wobei jede Ausgabe einen neuen UTXO enthält, der dem Status hinzugefügt werden soll.
-Die Statusübergangsfunktion `APPLY(S,TX) -> S'` kann in etwa wie folgt definiert werden:
+Die Zustandsübergangsfunktion `APPLY(S,TX) -> S'` kann grob wie folgt definiert werden:
-
- Für jede Eingabe in
TX:
+ Für jeden Input in TX:
-
Wenn der referenzierte UTXO nicht in
S ist, wird ein Fehler zurückgegeben.
@@ -65,10 +65,10 @@ Die Statusübergangsfunktion `APPLY(S,TX) -> S'` kann in etwa wie folgt definier
-
- Wenn die Summe der Nennwerte aller Eingangs-UTXO kleiner ist als die Summe der Nennwerte aller Ausgangs-UTXO, wird ein Fehler zurückgegeben.
+ Wenn die Summe der Nennwerte aller Eingabe-UTXO kleiner ist als die Summe der Nennwerte aller Ausgabe-UTXO, wird ein Fehler zurückgegeben.
-
-
S ausgeben, wobei alle Eingangs-UTXO entfernt und alle Ausgangs-UTXO hinzugefügt wurden.
+ Gibt S zurück, wobei alle Eingabe-UTXOs entfernt und alle Ausgabe-UTXOs hinzugefügt wurden.
@@ -78,16 +78,16 @@ Die erste Hälfte des ersten Schritts verhindert, dass Transaktionsabsender, Coi
-Wenn wir Zugang zu einem vertrauenswürdigen zentralisierten Dienst hätten, wäre dieses System leicht zu implementieren; es könnte einfach genau wie beschrieben kodiert werden, wobei die Festplatte eines zentralisierten Servers verwendet wird, um den Status zu verfolgen. Da wir jedoch mit Bitcoin versuchen, ein dezentralisiertes Währungssystem aufzubauen, müssen wir das Status-Transaktionssystem mit einem Konsenssystem kombinieren, um sicherzustellen, dass alle über die Reihenfolge der Transaktionen übereinstimmen. Der dezentralisierte Konsensprozess von Bitcoin erfordert, dass die Knoten im Netzwerk kontinuierlich versuchen, Pakete von Transaktionen, sogenannte „Blöcke“, zu erzeugen. Das Netzwerk ist darauf ausgelegt, ungefähr alle zehn Minuten einen Block zu erzeugen, wobei jeder Block einen Zeitstempel, eine Nonce, einen Verweis auf den vorherigen Block (also den entsprechenden Hash) und eine Liste aller Transaktionen enthält, die seit dem vorherigen Block stattgefunden haben. Im Laufe der Zeit entsteht so eine persistente, ständig wachsende „Blockchain“, die sich kontinuierlich aktualisiert, um den neuesten Status des Bitcoin-Ledgers darzustellen.
+Wenn wir Zugang zu einem vertrauenswürdigen zentralisierten Dienst hätten, wäre dieses System leicht zu implementieren; es könnte einfach genau wie beschrieben kodiert werden, wobei die Festplatte eines zentralisierten Servers verwendet wird, um den Status zu verfolgen. Da wir jedoch mit Bitcoin versuchen, ein dezentralisiertes Währungssystem aufzubauen, müssen wir das Status-Transaktionssystem mit einem Konsenssystem kombinieren, um sicherzustellen, dass alle über die Reihenfolge der Transaktionen übereinstimmen. Der dezentralisierte Konsensprozess von Bitcoin erfordert, dass die Knoten im Netzwerk kontinuierlich versuchen, Pakete von Transaktionen, sogenannte „Blöcke“, zu erzeugen. Das Netzwerk soll etwa alle zehn Minuten einen Block produzieren, wobei jeder Block einen Zeitstempel, eine Nonce, einen Verweis auf den vorherigen Block (d. h. den Hash des vorherigen Blocks) und eine Liste aller Transaktionen enthält, die seit dem vorherigen Block stattgefunden haben. Im Laufe der Zeit entsteht so eine persistente, ständig wachsende „Blockchain“, die sich kontinuierlich aktualisiert, um den neuesten Status des Bitcoin-Ledgers darzustellen.
Der Algorithmus zur Überprüfung der Gültigkeit eines Blocks, ausgedrückt in diesem Paradigma, lautet wie folgt:
1. Prüfen, ob der vorherige Block, auf den der Block verweist, existiert und gültig ist.
2. Prüfen, ob der Zeitstempel des Blocks größer ist als der des vorherigen Blocks[fn2](#notes) und weniger als 2 Stunden in der Zukunft liegt.
3. Prüfen, ob der Proof-of-Work des Blocks gültig ist.
-4. Der Status am Ende des vorherigen Blocks soll `S[0]` lauten.
-5. Annehmen, dass `TX` die Transaktionsliste des Blocks mit `n` Transaktionen ist. Für alle `i` in `0...n-1` `S[i+1] = APPLY(S[i],TX[i])` festlegen. Falls eine Anwendung einen Fehler zurückgibt, abbrechen und „false“ zurückgeben.
-6. „true“ zurückgeben und `S[n]` als den Status am Ende dieses Blocks registrieren.
+4. Sei `S[0]` der Zustand am Ende des vorherigen Blocks.
+5. Angenommen, `TX` ist die Transaktionsliste des Blocks mit `n` Transaktionen. Für alle `i` in `0...n-1`, setze `S[i+1] = APPLY(S[i],TX[i])`. Wenn eine Anwendung einen Fehler zurückgibt, beende und gib false zurück.
+6. Gib true zurück und registriere `S[n]` als Zustand am Ende dieses Blocks.
Im Wesentlichen muss jede Transaktion im Block einen gültigen Statusübergang von dem ursprünglich kanonischen Status vor der Ausführung der Transaktion zu einem neuen Status bereitstellen. Beachten Sie, dass der Status auf keine Weise im Block kodiert ist; er ist eine reine Abstraktion, die sich der validierende Knoten merken muss und die nur (sicher) für einen Block berechnet werden kann, indem man vom Genesis-Status ausgeht und jede Transaktion in jedem Block nacheinander anwendet. Zusätzlich sei darauf hingewiesen, dass die Reihenfolge, in der der Miner Transaktionen in den Block einfügt, wichtig ist; wenn es zwei Transaktionen A und B in einem Block gibt, wobei B einen von A geschaffenen UTXO ausgibt, ist der Block gültig, wenn A vor B kommt, aber nicht umgekehrt.
@@ -102,9 +102,9 @@ Um den Zweck des Minings besser zu verstehen, wollen wir untersuchen, was im Fal
3. Eine weitere Transaktion durchführen, die dieselben 100 BTC an ihn selbst sendet
4. Versuchen, das Netzwerk davon zu überzeugen, dass seine Transaktion an sich selbst zuerst kam.
-Sobald Schritt (1) erfolgt ist, nimmt nach ein paar Minuten ein Miner die Transaktion in einen Block auf, beispielsweise in Block Nummer 270000. Nach etwa einer Stunde werden der Kette nach diesem Block fünf weitere Blöcke hinzugefügt worden sein, wobei jeder dieser Blöcke indirekt auf die Transaktion verweist und sie somit „bestätigt“. An diesem Punkt akzeptiert der Händler die Zahlung als abgeschlossen und liefert das Produkt; da wir davon ausgehen, dass es sich um eine digitale Ware handelt, erfolgt die Lieferung sofort. Nun erstellt der Angreifer eine weitere Transaktion, die die 100 BTC an ihn selbst sendet. Wenn der Angreifer sie einfach in die freie Wildbahn entlässt, wird die Transaktion nicht verarbeitet; Miner werden versuchen, `APPLY(S,TX)` auszuführen, und feststellen, dass `TX` ein UTXO verbraucht, das sich nicht mehr im Status befindet. Stattdessen erstellt der Angreifer eine „Abspaltung“ der Blockchain, indem er zu Beginn eine andere Version von Block 270000 mint, die auf denselben Block 269999 als übergeordneten Block verweist, aber mit der neuen Transaktion anstelle der alten. Da die Blockdaten unterschiedlich sind, muss der Proof-of-Work neu erstellt werden. Außerdem hat die neue Version des Blocks 270000 des Angreifers einen anderen Hash, sodass die ursprünglichen Blöcke 270001 bis 270005 nicht auf ihn „verweisen“; somit sind die ursprüngliche Kette und die neue Kette des Angreifers völlig getrennt. Die Regel besagt, dass bei einer Abspaltung die längste Blockchain als Wahrheit angesehen wird, sodass legitime Minder an der Kette 270005 arbeiten, während der Angreifer allein an der Kette 270000 arbeitet. Damit der Angreifer seine Blockchain zur längsten machen kann, müsste er über mehr Rechenleistung verfügen als der Rest des Netzwerks zusammen, um aufholen zu können (daher „51-%-Attacke“).
+Sobald Schritt (1) erfolgt ist, nimmt nach ein paar Minuten ein Miner die Transaktion in einen Block auf, beispielsweise in Block Nummer 270000. Nach etwa einer Stunde werden der Kette nach diesem Block fünf weitere Blöcke hinzugefügt worden sein, wobei jeder dieser Blöcke indirekt auf die Transaktion verweist und sie somit „bestätigt“. An diesem Punkt akzeptiert der Händler die Zahlung als abgeschlossen und liefert das Produkt; da wir davon ausgehen, dass es sich um eine digitale Ware handelt, erfolgt die Lieferung sofort. Nun erstellt der Angreifer eine weitere Transaktion, die die 100 BTC an ihn selbst sendet. Wenn der Angreifer sie einfach veröffentlicht, wird die Transaktion nicht verarbeitet; Miner werden versuchen, `APPLY(S,TX)` auszuführen und feststellen, dass `TX` einen UTXO verbraucht, der sich nicht mehr im Zustand befindet. Stattdessen erstellt der Angreifer eine „Abspaltung“ der Blockchain, indem er zu Beginn eine andere Version von Block 270000 mint, die auf denselben Block 269999 als übergeordneten Block verweist, aber mit der neuen Transaktion anstelle der alten. Da die Blockdaten unterschiedlich sind, muss der Proof-of-Work neu erstellt werden. Außerdem hat die neue Version des Blocks 270000 des Angreifers einen anderen Hash, sodass die ursprünglichen Blöcke 270001 bis 270005 nicht auf ihn „verweisen“; somit sind die ursprüngliche Kette und die neue Kette des Angreifers völlig getrennt. Die Regel besagt, dass bei einer Abspaltung die längste Blockchain als Wahrheit angesehen wird, sodass legitime Minder an der Kette 270005 arbeiten, während der Angreifer allein an der Kette 270000 arbeitet. Damit der Angreifer seine Blockchain zur längsten machen kann, müsste er über mehr Rechenleistung verfügen als der Rest des Netzwerks zusammen, um aufholen zu können (daher „51-%-Attacke“).
-### Merkle Trees {#merkle-trees}
+### Merkle-Bäume {#merkle-trees}
@@ -118,11 +118,11 @@ Das Merkle Tree-Protokoll ist für die langfristige Nachhaltigkeit wohl unerläs
### Alternative Blockchain-Anwendungen {#alternative-blockchain-applications}
-Die Idee, den Grundgedanken der Blockchain auf andere Konzepte zu übertragen, hat ebenfalls eine lange Geschichte. 2005 veröffentlichte Nick Szabo das Konzept von „[sicheren Eigentumstiteln mit Eigentümerauthorität](https://nakamotoinstitute.org/secure-property-titles/)“ – ein Dokument, welches beschreibt, wie „neue Fortschritte in der replizierten Datenbanktechnologie“ ein Blockchain-basiertes Sytem für die Speicherung eines Registers darüber, wer der Eigentümer wovon ist, ermöglichen, wobei ein ausgeklügeltes Framework mit Konzepten wie Homesteading, Adverse Possession und georgischer Grundsteuer geschaffen wird. Leider gab es zu dieser Zeit kein effektives repliziertes Datenbanksystem, sodass das Protokoll nie in die Praxis umgesetzt wurde. Nach 2009, nachdem der dezentralisierte Konsens von Bitcoin entwickelt wurde, entstand jedoch schnell eine Reihe von alternativen Anwendungen.
+Die Idee, den Grundgedanken der Blockchain auf andere Konzepte zu übertragen, hat ebenfalls eine lange Geschichte. Im Jahr 2005 veröffentlichte Nick Szabo das Konzept der „[sicheren Eigentumstitel mit Eigentümerautorität](https://nakamotoinstitute.org/library/secure-property-titles/)“, ein Dokument, das beschreibt, wie „neue Fortschritte in der replizierten Datenbanktechnologie“ ein blockchainbasiertes System zur Speicherung eines Registers darüber ermöglichen, wer welches Land besitzt, und dabei ein ausgeklügeltes Rahmenwerk mit Konzepten wie Homesteading, Ersitzung (Adverse Possession) und der georgianischen Grundsteuer schaffen. Leider gab es zu dieser Zeit kein effektives repliziertes Datenbanksystem, sodass das Protokoll nie in die Praxis umgesetzt wurde. Nach 2009, nachdem der dezentralisierte Konsens von Bitcoin entwickelt wurde, entstand jedoch schnell eine Reihe von alternativen Anwendungen.
-- **Namecoin** – [Namecoin](https://namecoin.org/) wurde 2010 erschaffen und lässt sich am besten als eine dezentralisierte Datenbank zur Namensregistrierung beschrieben. In dezentralen Protokollen wie Tor, Bitcoin und BitMessage muss es eine Möglichkeit geben, Konten zu identifizieren, damit andere Leute mit ihnen interagieren können. Aber in allen bisherigen Lösungen ist der einzige verfügbare Identifikator ein pseudo-zufälliger Hash wie `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Im Idealfall möchte man ein Konto mit einem Namen wie „george“ haben können. Das Problem ist jedoch, dass, wenn eine Person ein Konto mit dem Namen „george“ einrichten kann, eine andere Person das gleiche Verfahren nutzen kann, um sich ebenfalls als „george“ zu registrieren und sich als diese Person auszugeben. Die einzige Lösung ist ein First-to-File-Paradigma, bei dem der erste Registrant erfolgreich ist und der zweite scheitert – ein Problem, das sich perfekt für das Bitcoin-Konsensprotokoll eignet. Namecoin ist die älteste und erfolgreichste Implementierung eines Namensregistrierungssystems, das auf einer solchen Idee beruht.
-- **Colored Coins** – [Colored Coins](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) dienen als Protokoll, das die Möglichkeit bietet, eine eigene digitale Währung zu erschaffen oder – in dem wichtigen trivialen Fall einer Währung mit einer Einheit – digitale Token, auf der Bitcoin-Blockchain. Im Colored-Coins-Protokoll wird eine neue Währung „veröffentlicht“, indem man einem bestimmten Bitcoin-UTXO öffentlich eine Farbe zuweist. Das Protokoll definiert rekursiv die Farbe anderer UTXO als die gleiche wie die der Eingaben, die die Transaktion ausgegeben hat, welche diese erzeugte (bei Eingaben mit gemischten Farben gelten einige spezielle Regeln). Dies ermöglicht es den Benutzern, Wallets zu verwalten, die nur UTXO einer bestimmten Farbe enthalten, und sie wie ähnlich wie reguläre Bitcoins zu versenden und über die Blockchain zurückzuverfolgen, um die Farbe eines UTXO zu ermitteln, den sie erhalten haben.
-- **Metacoins** – die Idee hinter Metacoin ist ein Protokoll, das auf Bitcoin aufbaut und Bitcoin-Transaktionen nutzt, um Metacoin-Transaktionen mit einer anderen Statusübergangsfunktion zu speichern: `APPLY'`. Da das Metacoin-Protokoll nicht verhindern kann, dass ungültige Metacoin-Transaktionen in der Bitcoin-Blockchain auftreten, wird eine Regel hinzugefügt, die besagt, dass, wenn `APPLY'(S,TX)` einen Fehler zurückgibt, das Protokoll standardmäßig auf `APPLY'(S,TX) = S` festgelegt wird. Dies bietet einen einfachen Mechanismus zur Erstellung eines willkürlichen Kryptowährungsprotokolls, möglicherweise mit fortgeschrittenen Funktionen, die nicht in Bitcoin selbst implementiert werden können, jedoch mit sehr geringen Entwicklungskosten, da die Komplexität des Minings und der Vernetzung bereits durch das Bitcoin-Protokoll verarbeitet wird. Metacoins wurden verwendet, um einige Klassen von Finanzverträgen, Namensregistrierung und dezentralisierten Austausch zu implementieren.
+- **Namecoin** – 2010 erstellt, wird [Namecoin](https://namecoin.org/) am besten als eine dezentrale Namensregistrierungsdatenbank beschrieben. In dezentralen Protokollen wie Tor, Bitcoin und BitMessage muss es eine Möglichkeit geben, Konten zu identifizieren, damit andere Personen mit ihnen interagieren können, aber in allen bestehenden Lösungen ist die einzige Art von verfügbarem Identifikator ein pseudozufälliger Hash wie `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Im Idealfall möchte man ein Konto mit einem Namen wie „george“ haben können. Das Problem ist jedoch, dass, wenn eine Person ein Konto mit dem Namen „george“ einrichten kann, eine andere Person das gleiche Verfahren nutzen kann, um sich ebenfalls als „george“ zu registrieren und sich als diese Person auszugeben. Die einzige Lösung ist ein First-to-File-Paradigma, bei dem der erste Registrant erfolgreich ist und der zweite scheitert – ein Problem, das sich perfekt für das Bitcoin-Konsensprotokoll eignet. Namecoin ist die älteste und erfolgreichste Implementierung eines Namensregistrierungssystems, das auf einer solchen Idee beruht.
+- **Colored Coins** – Der Zweck von [Colored Coins](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) ist es, als Protokoll zu dienen, das es Menschen ermöglicht, ihre eigenen digitalen Währungen zu erstellen – oder, im wichtigen trivialen Fall einer Währung mit einer Einheit, digitale Token auf der Bitcoin-Blockchain. Im Colored-Coins-Protokoll wird eine neue Währung „veröffentlicht“, indem man einem bestimmten Bitcoin-UTXO öffentlich eine Farbe zuweist. Das Protokoll definiert rekursiv die Farbe anderer UTXO als die gleiche wie die der Eingaben, die die Transaktion ausgegeben hat, welche diese erzeugte (bei Eingaben mit gemischten Farben gelten einige spezielle Regeln). Dies ermöglicht es den Benutzern, Wallets zu verwalten, die nur UTXO einer bestimmten Farbe enthalten, und sie wie ähnlich wie reguläre Bitcoins zu versenden und über die Blockchain zurückzuverfolgen, um die Farbe eines UTXO zu ermitteln, den sie erhalten haben.
+- **Metacoins** – die Idee hinter einem Metacoin ist, ein Protokoll zu haben, das auf Bitcoin aufbaut, Bitcoin-Transaktionen verwendet, um Metacoin-Transaktionen zu speichern, aber eine andere Zustandsübergangsfunktion, `APPLY'`, hat. Da das Metacoin-Protokoll ungültige Metacoin-Transaktionen nicht daran hindern kann, in der Bitcoin-Blockchain zu erscheinen, wird eine Regel hinzugefügt, dass, wenn `APPLY'(S,TX)` einen Fehler zurückgibt, das Protokoll standardmäßig `APPLY'(S,TX) = S` annimmt. Dies bietet einen einfachen Mechanismus zur Erstellung eines willkürlichen Kryptowährungsprotokolls, möglicherweise mit fortgeschrittenen Funktionen, die nicht in Bitcoin selbst implementiert werden können, jedoch mit sehr geringen Entwicklungskosten, da die Komplexität des Minings und der Vernetzung bereits durch das Bitcoin-Protokoll verarbeitet wird. Metacoins wurden verwendet, um einige Klassen von Finanzverträgen, Namensregistrierung und dezentralisierten Austausch zu implementieren.
Im Allgemeinen gibt es also zwei Ansätze für den Aufbau eines Konsensprotokolls: Aufbau eines unabhängigen Netzwerks und Aufbau eines Protokolls auf Bitcoin. Der erste Ansatz, der bei Anwendungen wie Namecoin zwar einigermaßen erfolgreich war, ist schwer umzusetzen; jede einzelne Implementierung muss eine unabhängige Blockchain starten sowie den gesamten notwendigen Code für Statusübergänge und Netzwerkverbindungen entwickeln und testen. Außerdem prognostizieren wir, dass die Menge an Anwendungen für die Technologie des dezentralisierten Konsenses einer Potenzgesetzverteilung folgen wird, bei der die überwiegende Mehrheit der Anwendungen für eine eigene Blockchain zu klein sein wird, und stellen fest, dass es große Klassen von dezentralisierten Anwendungen gibt, insbesondere autonome dezentralisierte Organisationen, die miteinander interagieren müssen.
@@ -134,10 +134,10 @@ Auch ohne jegliche Erweiterungen ermöglicht das Bitcoin-Protokoll tatsächlich
Die Skriptsprache, wie sie in Bitcoin implementiert ist, hat jedoch mehrere wichtige Einschränkungen:
-- **Mangel an Turing-Completeness** – das heißt, dass die Bitcoin-Skriptsprache zwar eine große Teilmenge von Berechnungen unterstützt, aber nicht annähernd alle. Die Hauptkategorie, die fehlt, sind Schleifen. Dies geschieht zur Vermeidung von Endlosschleifen während der Transaktionsverifizierung; theoretisch ist dies ein überwindbares Hindernis für Skriptprogrammierer, da jede Schleife simuliert werden kann, indem man den zugrunde liegenden Code einfach mehrmals mit einer if-Aussage wiederholt, aber dies führt zu Skripten, die sehr ineffizient im Platzverbrauch sind. Zum Beispiel würde die Implementierung eines alternativen Signaturalgorithmus für elliptische Kurven wahrscheinlich 256 wiederholte Multiplikationsrunden erfordern, die alle einzeln im Code enthalten sind.
-- **Werteblindheit** – es gibt keine Möglichkeit für ein UTXO-Skript, eine feingranulare Kontrolle über den Betrag zu ermöglichen, der abgehoben werden kann. Zum Beispiel wäre ein leistungsfähiges Anwendungsbeispiel für einen Oracle-Vertrag ein Hedging-Vertrag, bei dem A und B BTC im Wert von 1000 $ einbringen und nach 30 Tagen das Skript 1000 $ in BTC an A und den Rest an B sendet. Dafür wäre ein Oracle erforderlich, um den Wert von 1 BTC in USD zu bestimmen, aber selbst dann stellt es eine massive Verbesserung in Bezug auf Vertrauen und Infrastrukturanforderungen gegenüber den vollständig zentralisierten Lösungen dar, die jetzt verfügbar sind. Allerdings ist dies aufgrund der Tatsache, dass UTXO nicht teilbar sind, nur durch einen sehr ineffizienten Kniff möglich. Dabei werden viele UTXO mit unterschiedlichen Nennwerten erstellt (z. B. ein UTXO mit dem Wert 2k für jedes k bis 30). Der Oracle entscheidet dann, welcher UTXO an A und welcher an B geschickt wird.
-- **Nicht vorhandener Status** – UTXO können entweder ausgegeben oder nicht ausgegeben sein; es gibt keine Möglichkeit für mehrstufige Verträge oder Skripte, die einen anderen internen Status als diesen speichern. Dies erschwert die Erstellung von mehrstufigen Optionskontrakten, dezentralisierten Austauschangeboten oder zweistufigen kryptografischen Commitment-Protokollen (notwendig für sichere Berechnungskopfgelder). Es bedeutet auch, dass UTXO nur verwendet werden können, um einfache, einmalige Verträge zu erstellen und keine komplexeren „statusbehafteten“ Verträge wie dezentralisierte Organisationen, und die Implementierung von Meta-Protokollen wird erschwert. Ein binärer Status in Verbindung mit Werteblindheit bedeutet auch, dass eine weitere wichtige Anwendung, nämlich Abhebungslimits, unmöglich ist.
-- **Blockchain-Blindheit** – UTXO sind blind für Blockchain-Daten wie die Nonce, den Zeitstempel und den vorherigen Block-Hash. Dies schränkt Anwendungen im Glücksspiel und in mehreren anderen Kategorien erheblich ein, da der Skriptsprache eine potenziell wertvolle Quelle der Zufälligkeit entzogen wird.
+- **Mangel an Turing-Vollständigkeit** – das heißt, obwohl es eine große Teilmenge von Berechnungen gibt, die die Bitcoin-Skriptsprache unterstützt, unterstützt sie bei weitem nicht alles. Die Hauptkategorie, die fehlt, sind Schleifen. Dies geschieht zur Vermeidung von Endlosschleifen während der Transaktionsverifizierung; theoretisch ist dies ein überwindbares Hindernis für Skriptprogrammierer, da jede Schleife simuliert werden kann, indem man den zugrunde liegenden Code einfach mehrmals mit einer if-Aussage wiederholt, aber dies führt zu Skripten, die sehr ineffizient im Platzverbrauch sind. Zum Beispiel würde die Implementierung eines alternativen Signaturalgorithmus für elliptische Kurven wahrscheinlich 256 wiederholte Multiplikationsrunden erfordern, die alle einzeln im Code enthalten sind.
+- **Werteblindheit** – es gibt für ein UTXO-Skript keine Möglichkeit, eine feingranulare Kontrolle über den Betrag zu ermöglichen, der abgehoben werden kann. Zum Beispiel wäre ein leistungsfähiges Anwendungsbeispiel für einen Oracle-Vertrag ein Hedging-Vertrag, bei dem A und B BTC im Wert von 1000 $ einbringen und nach 30 Tagen das Skript 1000 $ in BTC an A und den Rest an B sendet. Dafür wäre ein Oracle erforderlich, um den Wert von 1 BTC in USD zu bestimmen, aber selbst dann stellt es eine massive Verbesserung in Bezug auf Vertrauen und Infrastrukturanforderungen gegenüber den vollständig zentralisierten Lösungen dar, die jetzt verfügbar sind. Da UTXOs jedoch alles oder nichts sind, besteht die einzige Möglichkeit, dies zu erreichen, in dem sehr ineffizienten Hack, viele UTXOs mit unterschiedlichen Nennwerten zu haben (z. B. ein UTXO von 2k für jedes k bis 30) und das Orakel auswählen zu lassen, welche UTXOs an A und welche an B gesendet werden.
+- **Fehlender Zustand** – UTXO können entweder ausgegeben oder nicht ausgegeben sein; es gibt keine Möglichkeit für mehrstufige Verträge oder Skripte, die einen anderen internen Zustand als diesen beibehalten. Dies erschwert die Erstellung von mehrstufigen Optionskontrakten, dezentralisierten Austauschangeboten oder zweistufigen kryptografischen Commitment-Protokollen (notwendig für sichere Berechnungskopfgelder). Es bedeutet auch, dass UTXO nur verwendet werden können, um einfache, einmalige Verträge zu erstellen und keine komplexeren „statusbehafteten“ Verträge wie dezentralisierte Organisationen, und die Implementierung von Meta-Protokollen wird erschwert. Ein binärer Status in Verbindung mit Werteblindheit bedeutet auch, dass eine weitere wichtige Anwendung, nämlich Abhebungslimits, unmöglich ist.
+- **Blockchain-Blindheit** – UTXO sind blind für Blockchain-Daten wie die Nonce, den Zeitstempel und den vorherigen Block-Hash. Dies schränkt Anwendungen im Glücksspiel und in mehreren anderen Kategorien erheblich ein, da der Skriptsprache eine potenziell wertvolle Quelle der Zufälligkeit entzogen wird.
Es gibt also drei Ansätze für die Entwicklung fortschrittlicher Anwendungen auf der Grundlage von Kryptowährungen: der Aufbau einer neuen Blockchain, die Verwendung von Skripten auf Bitcoin und der Aufbau eines Meta-Protokolls auf Bitcoin. Der Aufbau einer neuen Blockchain bietet unbegrenzte Freiheit bei der Entwicklung von Funktionssätzen, allerdings auf Kosten von Entwicklungszeit, Bootstrapping-Aufwand und Sicherheit. Scripting ist leicht zu implementieren und zu standardisieren, hat jedoch nur sehr begrenzte Möglichkeiten, und Meta-Protokolle haben trotz ihrer Einfachheit Probleme mit der Skalierbarkeit. Mit Ethereum wollen wir ein alternatives Framework schaffen, das sowohl die Entwicklungsfreundlichkeit erheblich verbessert als auch die Eigenschaften für leichte Clients weiter stärkt, während es Anwendungen gleichzeitig ermöglicht, eine gemeinsame wirtschaftliche Umgebung und die Sicherheit der Blockchain zu nutzen.
@@ -149,12 +149,12 @@ Die Absicht von Ethereum besteht darin, ein alternatives Protokoll zur Erstellun
In Ethereum wird der Status durch Objekte namens „Konten“ gebildet. Jedes Konto hat eine 20-Byte-Adresse, und Statusübergänge erfolgen durch direkte Übertragungen von Wert und Informationen zwischen den Konten. Ein Ethereum-Konto beinhaltet vier Felder:
-- Die **Nonce** – ein Zähler, der sicherstellt, dass jede Transaktion nur einmal verarbeitet werden kann
-- Der aktuelle **Ether-Saldo** des Kontos
+- Die **Nonce**, ein Zähler, der sicherstellt, dass jede Transaktion nur einmal verarbeitet werden kann
+- Das aktuelle **Ether-Guthaben** des Kontos
- Der **Vertragscode** des Kontos, falls vorhanden
-- Der **Speicherplatz** des Kontos (standardmäßig leer)
+- Der **Speicher** des Kontos (standardmäßig leer)
-„Ether“ ist der Krypto-Haupttreibstoff von Ethereum und wird verwendet, um Transaktionsgebühren zu bezahlen. Allgemein gibt es zwei Arten von Konten: **Konten in externem Eigentum**, die durch private Schlüssel kontrolliert werden, und **Vertragskonten**, die durch deren Vertragscode kontrolliert werden. Ein Konto in externem Eigentum besitzt keinen Code, und man kann Nachrichten von einem solchen Konto aus verschicken, indem man eine Transaktion erschafft und signiert. Jedes Mal, wenn ein Vertragskonto eine Nachricht erhält, wird dessen Code aktiviert, was es erlaubt, den internen Speicher zu lesen und zu bearbeiten und andere Nachrichten zu senden oder Vertragskonten im Gegenzug zu erschaffen.
+„Ether“ ist der Krypto-Haupttreibstoff von Ethereum und wird verwendet, um Transaktionsgebühren zu bezahlen. Im Allgemeinen gibt es zwei Arten von Konten: **extern verwaltete Konten**, die durch private Schlüssel gesteuert werden, und **Vertragskonten**, die durch ihren Vertragscode gesteuert werden. Ein Konto in externem Eigentum besitzt keinen Code, und man kann Nachrichten von einem solchen Konto aus verschicken, indem man eine Transaktion erschafft und signiert. Jedes Mal, wenn ein Vertragskonto eine Nachricht erhält, wird dessen Code aktiviert, was es erlaubt, den internen Speicher zu lesen und zu bearbeiten und andere Nachrichten zu senden oder Vertragskonten im Gegenzug zu erschaffen.
Beachten Sie, dass „Verträge“ in Ethereum nicht als etwas betrachtet werden sollten, das „erfüllt“ oder „eingehalten“ werden muss; vielmehr ähneln sie eher „autonomen Agenten“, die innerhalb der Ethereum-Ausführungsumgebung existieren, stets ein bestimmtes Stück Code ausführen, wenn sie durch eine Nachricht oder Transaktion „angesprochen“ werden, und die direkte Kontrolle über ihr eigenes Ether-Saldo sowie ihren eigenen Schlüssel-/Wertespeicher haben, um persistente Variablen zu verfolgen.
@@ -166,8 +166,8 @@ In Ethereum wird der Begriff „Transaktion“ verwendet, um das signierte Daten
- Eine Signatur, die den Absender identifiziert
- Den Ether-Betrag, der vom Absender an den Empfänger übertragen werden soll
- Ein optionales Datenfeld
-- Einen `STARTGAS`-Wert, welcher für die maximale Anzahl an Berechnungsschritten für die Transaktionsausführung steht
-- Einen `GASPRICE`-Wert, welcher für die Gebühr steht, die der Absender pro Berechnungsschritt bezahlt
+- Ein `STARTGAS`-Wert, der die maximale Anzahl von Rechenschritten darstellt, die die Transaktionsausführung durchführen darf
+- Ein `GASPRICE`-Wert, der die Gebühr darstellt, die der Absender pro Rechenschritt bezahlt
Bei den ersten drei handelt es sich um Standardfelder, die bei jeder Kryptowährung erwartet werden. Das Datenfeld hat standardmäßig keine Funktion, aber die virtuelle Maschine hat einen Opcode, mit dem ein Vertrag auf die Daten zugreifen kann; als Beispielanwendung: Wenn ein Vertrag als On-Blockchain-Domain-Registrierungsdienst fungiert, könnte er die an ihn übermittelten Daten so interpretieren, dass sie zwei „Felder“ enthalten – das erste Feld eine zu registrierende Domain und das zweite Feld die IP-Adresse, auf die sie registriert werden soll. Der Vertrag liest diese Werte aus den Nachrichtendaten und speichert sie in geeigneter Weise ab.
@@ -178,24 +178,24 @@ Die Felder `STARTGAS` und `GASPRICE` sind entscheidend für das Anti-Denial-of-S
Verträge haben die Möglichkeit, „Nachrichten“ an andere Verträge zu senden. Nachrichten sind virtuelle Objekte, die niemals serialisiert werden und nur in der Ethereum-Ausführungsumgebung existieren. Eine Nachricht enthält:
- Den Absender der Nachricht (implizit)
-- Der Empfänger der Nachricht
+- Den Empfänger der Nachricht
- Die Menge an Ether, die mit der Nachricht übertragen werden soll
- Ein optionales Datenfeld
-- Einen `STARTGAS`-Wert
+- Ein `STARTGAS`-Wert
Eine Nachricht ist im Grunde genommen wie eine Transaktion, nur dass sie von einem Vertrag und nicht von einem externen Akteur erzeugt wird. Eine Nachricht wird erzeugt, wenn ein Vertrag, der gerade Code ausführt, den Opcode `CALL` ausführt, der eine Nachricht erzeugt und ausführt. Eine Nachricht führt wie eine Transaktion dazu, dass das Empfängerkonto den Code ausführt. Somit können Verträge auf genau die gleiche Weise wie externe Akteure Beziehungen zu anderen Verträgen haben.
Beachten Sie, dass das Gas-Limit, das einer Transaktion oder einem Vertrag zugewiesen wird, für das gesamte Gas gilt, das von dieser Transaktion und allen Unterausführungen verbraucht wird. Wenn beispielsweise ein externer Akteur A eine Transaktion an B mit 1000 Gas sendet und B 600 Gas verbraucht, bevor er eine Nachricht an C sendet, während die interne Ausführung von C 300 Gas verbraucht, bevor sie zurückkehrt, kann B noch 100 Gas ausgeben, bevor das Gas aufgebraucht ist.
-### Ethereum-Statusübergangfunktion {#ethereum-state-transition-function}
+### Ethereum-Zustandsübergangsfunktion {#ethereum-state-transition-function}
-
+
-Die Ethereum-Statusübergangsfunktion `APPLY(S,TX) -> S'` kann wie folgt definiert werden:
+Die Ethereum-Zustandsübergangsfunktion, `APPLY(S,TX) -> S'` kann wie folgt definiert werden:
-1. Prüfen, ob die Transaktion korrekt aufgebaut ist (sprich, die richtige Anzahl von Werten enthält), ob die Signatur gültig ist und ob die Nonce mit der im Konto des Absenders übereinstimmt. Falls nicht, einen Fehler zurückgeben.
-2. Die Transaktionsgebühr als `STARTGAS * GASPRICE` berechnen und die Absenderadresse aus der Signatur bestimmen. Die Gebühr vom Saldo des Absenders abziehen und die Nonce des Absenders erhöhen. Wenn nicht genügend zu verbrauchender Saldo vorhanden ist, einen Fehler zurückgeben.
-3. `GAS = STARTGAS` initialisieren und eine bestimmte Gas-Menge pro Byte abziehen, um für die Bytes in der Transaktion zu bezahlen.
+1. Überprüfen Sie, ob die Transaktion wohlgeformt ist (d. h. die richtige Anzahl von Werten hat), die Signatur gültig ist und die Nonce mit der Nonce im Konto des Absenders übereinstimmt. Falls nicht, einen Fehler zurückgeben.
+2. Berechne die Transaktionsgebühr als `STARTGAS * GASPRICE`, und bestimme die Absenderadresse aus der Signatur. Die Gebühr vom Saldo des Absenders abziehen und die Nonce des Absenders erhöhen. Wenn nicht genügend zu verbrauchender Saldo vorhanden ist, einen Fehler zurückgeben.
+3. Initialisiere `GAS = STARTGAS`, und ziehe eine bestimmte Menge an Gas pro Byte ab, um für die Bytes in der Transaktion zu bezahlen.
4. Den Transaktionswert vom Konto des Absenders auf das Konto des Empfängers übertragen. Falls das Empfängerkonto noch nicht existiert, dieses erstellen. Wenn das Empfängerkonto ein Vertrag ist, den Code des Vertrags entweder bis zum Abschluss oder bis zur Gas-Erschöpfung ausführen.
5. Wenn die Wertübertragung fehlgeschlagen ist, weil der Absender nicht genügend Geld hatte oder die Codeausführung das Gas aufgebraucht hat, alle Statusänderungen zurücksetzen, mit Ausnahme der Zahlung der Gebühren, und die Gebühren dem Konto des Miners hinzufügen.
6. Andernfalls die Gebühren für das verbleibende Gas an den Absender erstatten und die Gebühren für das verbrauchte Gas an den Miner senden.
@@ -207,49 +207,49 @@ if !self.storage[calldataload(0)]:
self.storage[calldataload(0)] = calldataload(32)
```
-Beachten Sie, dass der tatsächliche Vertragscode als Low-Level-EVM-Code geschrieben ist; dieses Beispiel ist zur Klarheit in Serpent, einer unserer High-Level-Sprachen, verfasst und kann in EVM-Code kompiliert werden. Angenommen, der Speicher des Vertrags beginnt leer und eine Transaktion wird mit einem Wert von 10 Ether, 2000 Gas, einem Gas-Preis von 0,001 Ether und 64 Byte Daten gesendet, wobei die Bytes 0–31 für die Zahl `2` und die Bytes 32–63 für den String `CHARLIE` stehen. In diesem Fall ist der Prozess der Statusübergangsfunktion wie folgt:
+Beachten Sie, dass der tatsächliche Vertragscode als Low-Level-EVM-Code geschrieben ist; dieses Beispiel ist zur Klarheit in Serpent, einer unserer High-Level-Sprachen, verfasst und kann in EVM-Code kompiliert werden. Angenommen, der Speicher des Vertrags ist anfangs leer, und eine Transaktion wird mit einem Wert von 10 Ether, 2000 Gas, einem Gaspreis von 0,001 Ether und 64 Bytes an Daten gesendet, wobei die Bytes 0-31 die Zahl `2` und die Bytes 32-63 die Zeichenkette `CHARLIE` darstellen. In diesem Fall ist der Prozess der Statusübergangsfunktion wie folgt:
1. Sicherstellen, dass die Transaktion gültig und korrekt aufgebaut ist.
2. Überprüfen Sie, ob der Absender der Transaktion mindestens 2000 \* 0,001 = 2 Ether besitzt. Wenn ja, dann 2 Ether vom Konto des Absenders abziehen.
3. Gas = 2000 initialisieren; vorausgesetzt, die Transaktion ist 170 Byte lang und die Gebühren pro Byte betragen 5, 850 abziehen, sodass noch 1150 Gas verbleibt.
4. 10 weitere Ether vom Konto des Absenders abziehen und sie dem Konto des Vertrags hinzufügen.
-5. Den Code ausführen. In diesem Fall ist es einfach: Es wird überprüft, ob der Speicher des Vertrags an Index `2` verwendet wird, und festgestellt, dass dies nicht der Fall ist, und daher wird der Speicher an Index `2` auf den Wert `CHARLIE` gesetzt. Angenommen, dies verbraucht 187 Gas – dann beträgt der verbleibende Gasbetrag 1150 - 187 = 963.
+5. Den Code ausführen. In diesem Fall ist dies einfach: Es wird geprüft, ob der Speicher des Vertrags am Index `2` verwendet wird, festgestellt, dass dies nicht der Fall ist, und so wird der Speicher am Index `2` auf den Wert `CHARLIE` gesetzt. Angenommen, dies verbraucht 187 Gas – dann beträgt der verbleibende Gasbetrag 1150 - 187 = 963.
6. 963 \* 0,001 = 0,963 Ether zurück auf das Konto des Senders hinzufügen und den dadurch entstandenen Status zurückgeben.
-Wenn am empfangenden Ende der Transaktion kein Vertrag vorhanden war, wäre die gesamte Transaktionsgebühr einfach das Produkt aus dem angegebenen `GASPRICE` und der Länge der Transaktion in Bytes, wobei die bei der Transaktion gesendeten Daten irrelevant wären.
+Wenn am empfangenden Ende der Transaktion kein Vertrag vorhanden war, entspräche die gesamte Transaktionsgebühr einfach dem angegebenen `GASPRICE` multipliziert mit der Länge der Transaktion in Bytes, und die mit der Transaktion gesendeten Daten wären irrelevant.
-Beachten Sie, dass Nachrichten in Bezug auf Zurücksetzungen wie Transaktionen funktionieren: Wenn eine Nachrichtenausführung das Gas-Limit erreicht, wird die Ausführung dieser Nachricht sowie aller anderen durch diese Ausführung ausgelösten Ausführungen zurückgesetzt, jedoch müssen übergeordnete Ausführungen nicht zurückgesetzt werden. Das bedeutet, dass es für einen Vertrag „sicher“ ist, einen anderen Vertrag aufzurufen; wenn A B mit G Gas aufruft, ist garantiert, dass As Ausführung höchstens G Gas verliert. Schließlich sei darauf hingewiesen, dass es einen Opcode `CREATE` gibt, der einen Vertrag erstellt; seine Ausführungsmechanik ist grundsätzlich ähnlich wie bei `CALL`, mit dem Unterschied, dass die Ausgabe der Ausführung den Code eines neu erstellten Vertrags bestimmt.
+Beachten Sie, dass Nachrichten in Bezug auf Zurücksetzungen wie Transaktionen funktionieren: Wenn eine Nachrichtenausführung das Gas-Limit erreicht, wird die Ausführung dieser Nachricht sowie aller anderen durch diese Ausführung ausgelösten Ausführungen zurückgesetzt, jedoch müssen übergeordnete Ausführungen nicht zurückgesetzt werden. Das bedeutet, dass es für einen Vertrag „sicher“ ist, einen anderen Vertrag aufzurufen; wenn A B mit G Gas aufruft, ist garantiert, dass As Ausführung höchstens G Gas verliert. Beachten Sie schließlich, dass es einen Opcode, `CREATE`, gibt, der einen Vertrag erstellt; seine Ausführungsmechanik ist im Allgemeinen ähnlich wie `CALL`, mit der Ausnahme, dass die Ausgabe der Ausführung den Code eines neu erstellten Vertrags bestimmt.
### Codeausführung {#code-execution}
-Der Code in Ethereum-Verträgen ist in einer Low-Level-, Stack-basierten Bytecode-Sprache geschrieben, die als „Code der virtuellen Maschine von Ethereum“ oder „EVM-Code“ bezeichnet wird. Der Code besteht aus einer Reihe von Bytes, wobei jedes Byte für eine Operation steht. Im Allgemeinen ist die Codeausführung eine Endlosschleife, die darin besteht, wiederholt die Operation am aktuellen Programmzähler (der bei null beginnt) auszuführen und anschließend den Programmzähler um eins zu erhöhen, bis das Ende des Codes erreicht ist oder ein Fehler bzw. ein `STOP`- oder `RETURN`-Befehl erkannt wird. Die Operationen haben Zugang zu drei Arten von Speicher, in denen Daten gespeichert werden können:
+Der Code in Ethereum-Verträgen ist in einer Low-Level-, Stack-basierten Bytecode-Sprache geschrieben, die als „Code der virtuellen Maschine von Ethereum“ oder „EVM-Code“ bezeichnet wird. Der Code besteht aus einer Reihe von Bytes, wobei jedes Byte für eine Operation steht. Im Allgemeinen ist die Codeausführung eine Endlosschleife, die darin besteht, die Operation am aktuellen Programmzähler (der bei Null beginnt) wiederholt auszuführen und dann den Programmzähler um eins zu erhöhen, bis das Ende des Codes erreicht ist oder ein Fehler oder eine `STOP`- oder `RETURN`-Anweisung erkannt wird. Die Operationen haben Zugang zu drei Arten von Speicher, in denen Daten gespeichert werden können:
-- Der **Stack**, ein Last-in-First-out-Container, in den Werte gepusht und aus dem Werte gepoppt werden können
-- **Gedächtnis**, ein unendlich erweiterbares Byte-Array
-- Der langfristige **Speicher** des Vertrags, ein Schlüssel-/Wertespeicher. Anders als bei Stack und Gedächtnis, die nach Beendigung der Berechnung zurückgesetzt werden, bleibt der Speicher auf lange Sicht bestehen.
+- Der **Stack**, ein Last-In-First-Out-Container, in den Werte gepusht und aus dem sie gepoppt werden können
+- **Speicher**, ein unendlich erweiterbares Byte-Array
+- Der langfristige **Speicher** des Vertrags, ein Schlüssel/Wert-Speicher. Anders als bei Stack und Gedächtnis, die nach Beendigung der Berechnung zurückgesetzt werden, bleibt der Speicher auf lange Sicht bestehen.
Der Code kann auch auf den Wert, Absender und die Daten der eingehenden Nachricht sowie auf Block-Header-Daten zugreifen, und der Code kann auch ein Byte-Array von Daten als Ausgabe zurückgeben.
-Das formale Ausführungsmodell von EVM-Codes ist erstaunlich einfach. Während die virtuelle Maschine von Ethereum läuft, kann ihr vollständiger Berechnungsstatus durch das Tupel `(block_state, transaction, message, code, memory, stack, pc, gas)` definiert werden, wobei `block_state` den globalen Status darstellt, der alle Konten mit Salden und Speicher enthält. Zu Beginn jeder Ausführungsrunde wird die aktuelle Anweisung bestimmt, indem man das `pc`-te Byte des `code` nimmt (oder 0, wenn `pc >= len(code)`), und jede Anweisung hat ihre eigene Definition, wie sie das Tupel beeinflusst. Zum Beispiel entfernt `ADD` zwei Elemente vom Stack und pusht ihre Summe, reduziert `gas` um 1 und erhöht `pc` um 1, während `SSTORE` die obersten zwei Elemente vom Stack entfernt und das zweite Element im Speicher des Vertrags am durch das erste Element angegebenen Index einfügt. Obwohl es viele Möglichkeiten gibt, die Ausführung der virtuellen Maschine von Ethereum durch Just-in-Time-Kompilierung zu optimieren, kann eine grundlegende Implementierung von Ethereum in einigen Hundert Zeilen Code umgesetzt werden.
+Das formale Ausführungsmodell von EVM-Codes ist erstaunlich einfach. Während die Ethereum Virtual Machine läuft, kann ihr vollständiger Berechnungszustand durch das Tupel `(block_state, transaction, message, code, memory, stack, pc, gas)` definiert werden, wobei `block_state` der globale Zustand ist, der alle Konten enthält und Salden und Speicher umfasst. Zu Beginn jeder Ausführungsrunde wird die aktuelle Anweisung gefunden, indem das `pc`-te Byte von `code` genommen wird (oder 0, wenn `pc >= len(code)`), und jede Anweisung hat ihre eigene Definition in Bezug darauf, wie sie das Tupel beeinflusst. `ADD` zum Beispiel poppt zwei Elemente vom Stack und pusht ihre Summe, reduziert `gas` um 1 und inkrementiert `pc` um 1, und `SSTORE` poppt die obersten beiden Elemente vom Stack und fügt das zweite Element in den Speicher des Vertrags an dem vom ersten Element angegebenen Index ein. Obwohl es viele Möglichkeiten gibt, die Ausführung der virtuellen Maschine von Ethereum durch Just-in-Time-Kompilierung zu optimieren, kann eine grundlegende Implementierung von Ethereum in einigen Hundert Zeilen Code umgesetzt werden.
### Blockchain und Mining {#blockchain-and-mining}
-
+
Die Ethereum-Blockchain ähnelt in vielerlei Hinsicht der Bitcoin-Blockchain, obwohl sie auch einige Unterschiede aufweist. Der Hauptunterschied zwischen Ethereum und Bitcoin in Bezug auf die Blockchain-Architektur besteht darin, dass Ethereum-Blöcke im Gegensatz zu Bitcoin eine Kopie der Transaktionsliste und des aktuellen Status enthalten. Darüber hinaus werden zwei weitere Werte, Blocknummer und Schwierigkeit, ebenfalls im Block gespeichert. Der grundlegende Blockvalidierungsalgorithmus in Ethereum gestaltet sich wie folgt:
1. Prüfen, ob der vorherige Block, auf den verwiesen wird, existiert und gültig ist.
2. Sicherstellen, dass der Zeitstempel des Blocks größer ist als der des referenzierten vorherigen Blocks und weniger als 15 Minuten in der Zukunft liegt.
3. Sicherstellen, dass Blocknummer, Schwierigkeit, Transaktionswurzel, Onkelwurzel und Gas-Limit (verschiedene Ethereum-spezifische Low-Level-Konzepte) gültig sind.
-4. Prüfe, ob der Proof-of-Work des Blocks gültig ist.
+4. Prüfen, ob der Proof-of-Work des Blocks gültig ist.
5. Sei `S[0]` der Zustand am Ende des vorherigen Blocks.
-6. `TX` die Transaktionsliste des Blocks, die `n` Transaktionen umfasst, sein lassen. Für alle `i` in `0...n-1` `S[i+1] = APPLY(S[i],TX[i])` festlegen. Wenn irgendeine Anwendung einen Fehler zurückgibt oder wenn das insgesamt im Block verbrauchte Gas bis zu diesem Zeitpunkt das `GASLIMIT` überschreitet, einen Fehler zurückgeben.
-7. `S_FINAL` gleich `S[n]` sein lassen, jedoch unter Hinzufügung der Blockbelohnung, die an den Miner gezahlt wird.
-8. Prüfen, ob die Merkle-Tree-Wurzel des Status `S_FINAL` der im Block-Header angegebenen endgültigen Statuswurzel gleicht. Wenn dies der Fall ist, ist der Block gültig; andernfalls ist er nicht gültig.
+6. Sei `TX` die Transaktionsliste des Blocks mit `n` Transaktionen. Für alle `i` in `0...n-1`, setze `S[i+1] = APPLY(S[i],TX[i])`. Wenn eine Anwendung einen Fehler zurückgibt, oder wenn das bis zu diesem Zeitpunkt im Block verbrauchte Gesamt-Gas das `GASLIMIT` überschreitet, wird ein Fehler zurückgegeben.
+7. Sei `S_FINAL` gleich `S[n]`, aber mit Hinzufügung der an den Miner gezahlten Block-Belohnung.
+8. Prüfen Sie, ob die Merkle-Baumwurzel des Zustands `S_FINAL` mit der im Block-Header angegebenen finalen Zustands-Wurzel übereinstimmt. Wenn dies der Fall ist, ist der Block gültig; andernfalls ist er nicht gültig.
-Auf den ersten Blick könnte der Ansatz äußerst ineffizient erscheinen, weil er den gesamten Status mit jedem Block speichern muss – tatsächlich sollte die Effizienz jedoch mit der von Bitcoin vergleichbar sein. Der Grund dafür ist, dass der Status in der Baumstruktur gespeichert wird und nach jedem Block nur ein kleiner Teil des Baums geändert werden muss. Daher sollte im Allgemeinen zwischen zwei benachbarten Blöcken der Großteil des Baums identisch sein, und die Daten können somit einmal gespeichert und zweimal über Verweiser (also Hashes von Teilbäumen) referenziert werden. Um dies zu erreichen, wird eine spezielle Art von Baum, bekannt als „Patricia-Baum“, verwendet. Er beinhaltet eine Modifikation des Merkle-Tree-Konzepts, die es ermöglicht, Knoten effizient einzufügen und zu löschen, und nicht nur zu ändern. Darüber hinaus ist es, weil alle Statusinformationen Teil des letzten Blocks sind, nicht notwendig, die gesamte Blockchain-Historie zu speichern – eine Strategie, die, sofern sie auf Bitcoin angewendet werden kann, kalkulierte 5- bis 20-fache Einsparungen im Speicher bieten könnte.
+Auf den ersten Blick könnte der Ansatz äußerst ineffizient erscheinen, weil er den gesamten Status mit jedem Block speichern muss – tatsächlich sollte die Effizienz jedoch mit der von Bitcoin vergleichbar sein. Der Grund dafür ist, dass der Status in der Baumstruktur gespeichert wird und nach jedem Block nur ein kleiner Teil des Baums geändert werden muss. Im Allgemeinen sollte also zwischen zwei benachbarten Blöcken die große Mehrheit des Baumes gleich sein, und daher können die Daten einmal gespeichert und zweimal über Zeiger (d. h. Hashes von Teilbäumen) referenziert werden. Um dies zu erreichen, wird eine spezielle Art von Baum, bekannt als „Patricia-Baum“, verwendet. Er beinhaltet eine Modifikation des Merkle-Tree-Konzepts, die es ermöglicht, Knoten effizient einzufügen und zu löschen, und nicht nur zu ändern. Darüber hinaus ist es, weil alle Statusinformationen Teil des letzten Blocks sind, nicht notwendig, die gesamte Blockchain-Historie zu speichern – eine Strategie, die, sofern sie auf Bitcoin angewendet werden kann, kalkulierte 5- bis 20-fache Einsparungen im Speicher bieten könnte.
-Es wird häufig danach gefragt, „wo“ der Vertragscode in Bezug auf physische Hardware ausgeführt wird. Die Antwort darauf ist einfach: Der Vorgang der Ausführung des Vertragcodes ist Teil der Definition der Statusübergangsfunktion, die Teil des Blockvalidierungsalgorithmus ist. Wenn eine Transaktion also in Block `B` hinzugefügt wird, wird die durch diese Transaktion ausgelöste Codeausführung von allen Knoten, die Block `B` herunterladen und validieren, jetzt und in Zukunft ausgeführt.
+Es wird häufig danach gefragt, „wo“ der Vertragscode in Bezug auf physische Hardware ausgeführt wird. Die Antwort ist einfach: Der Prozess der Ausführung von Vertragscode ist Teil der Definition der Zustandsübergangsfunktion, die wiederum Teil des Blockvalidierungsalgorithmus ist. Wenn also eine Transaktion in Block `B` hinzugefügt wird, wird die durch diese Transaktion ausgelöste Codeausführung von allen Nodes, jetzt und in Zukunft, ausgeführt, die Block `B` herunterladen und validieren.
## Anwendungen {#applications}
@@ -272,7 +272,7 @@ Dies ist im Wesentlichen eine buchstäbliche Implementierung der Statussübergan
### Finanzderivate und wertstabile Währungen {#financial-derivatives-and-stable-value-currencies}
-Finanzderivate sind die häufigste Anwendung von „Smart Contracts“ und eine der am einfachsten in Code umzusetzenden. Die größte Herausforderung bei der Implementierung von Finanzverträgen besteht darin, dass die Mehrheit von ihnen auf einen externen Preisticker angewiesen ist; ein sehr begehrenswerter Anwendungsfall ist beispielsweise ein Smart Contract, der gegen die Volatilität von Ether (oder einer anderen Kryptowährung) im Verhältnis zum US-Dollar absichert. Dafür muss der Vertrag jedoch den Wert von ETH/USD kennen. Der einfachste Weg, dies zu erreichen, ist über einen „Datenfeed“-Vertrag, der von einer bestimmten Partei (z. B. NASDAQ) betrieben wird. Er ist so konzipiert, dass diese Partei in der Lage ist, den Vertrag nach Bedarf zu aktualisieren, und stellt eine Schnittstelle bereit, die es anderen Verträgen ermöglicht, eine Nachricht an diesen Vertrag zu senden und eine Rückmeldung zu erhalten, die den Preis enthält.
+Finanzderivate sind die häufigste Anwendung von „Smart Contracts“ und eine der am einfachsten in Code umzusetzenden. Die größte Herausforderung bei der Implementierung von Finanzverträgen besteht darin, dass die Mehrheit von ihnen auf einen externen Preisticker angewiesen ist; ein sehr begehrenswerter Anwendungsfall ist beispielsweise ein Smart Contract, der gegen die Volatilität von Ether (oder einer anderen Kryptowährung) im Verhältnis zum US-Dollar absichert. Dafür muss der Vertrag jedoch den Wert von ETH/USD kennen. Der einfachste Weg, dies zu tun, ist über einen „Datenfeed“-Vertrag, der von einer bestimmten Partei (z. B. NASDAQ) unterhalten wird und so konzipiert ist, dass diese Partei die Möglichkeit hat, den Vertrag nach Bedarf zu aktualisieren, und eine Schnittstelle bereitstellt, die es anderen Verträgen ermöglicht, eine Nachricht an diesen Vertrag zu senden und eine Antwort zu erhalten, die den Preis liefert.
Unter dieser Voraussetzung würde der Hedging-Vertrag wie folgt aussehen:
@@ -281,13 +281,13 @@ Unter dieser Voraussetzung würde der Hedging-Vertrag wie folgt aussehen:
3. Den USD-Wert von 1000 Ether, der durch das Abfragen des Datenfeed-Vertrags ermittelt wurde, im Speicher festhalten. Sagen wir, es sind x $.
4. Nach 30 Tagen A oder B erlauben, den Vertrag zu „ reaktivieren“, um x $ wertäquivalente Ether (berechnet durch erneutes Abfragen des Datenfeed-Vertrags, um den neuen Preis zu erhalten) an A und den Rest an B zu senden.
-Ein solcher Vertrag hätte ein erhebliches Potenzial im Kryptohandel. Eines der Hauptprobleme, die im Zusammenhang mit Kryptowährungen angeführt werden, ist die Tatsache, dass sie volatil sind; obwohl viele Benutzer und Händler die Sicherheit und Bequemlichkeit im Umgang mit kryptografischen Assets wünschen, möchten sie möglicherweise nicht riskieren, innerhalb eines einzigen Tages 23 % des Wertes ihrer Mittel zu verlieren. Bis jetzt war die häufigste vorgeschlagene Lösung durch Herausgeber unterstützte Assets; die Idee ist, dass ein Herausgeber eine Unterwährung schafft, in der er das Recht hat, Einheiten auszugeben und zurückzuziehen, und einem beliebigen Benutzer eine Einheit der Währung bereitstellt, der ihm (offline) eine Einheit eines bestimmten zugrunde liegenden Assets (z. B. Gold oder USD) gibt. Der Herausgeber verspricht dann, eine Einheit des zugrunde liegenden Assets an jeden zu liefern, der ihm eine Einheit des Krypto-Assets zurücksendet. Dieser Mechanismus ermöglicht es, jedes nicht-kryptografische Asset in ein kryptografisches Asset „aufzuwerten“, vorausgesetzt, dem Herausgeber kann vertraut werden.
+Ein solcher Vertrag hätte ein erhebliches Potenzial im Kryptohandel. Eines der Hauptprobleme, die im Zusammenhang mit Kryptowährungen angeführt werden, ist die Tatsache, dass sie volatil sind; obwohl viele Benutzer und Händler die Sicherheit und Bequemlichkeit im Umgang mit kryptografischen Assets wünschen, möchten sie möglicherweise nicht riskieren, innerhalb eines einzigen Tages 23 % des Wertes ihrer Mittel zu verlieren. Bisher war die am häufigsten vorgeschlagene Lösung emittentengestützte Vermögenswerte; die Idee ist, dass ein Emittent eine Unterwährung schafft, in der er das Recht hat, Einheiten auszugeben und zu widerrufen, und jedem, der ihm (offline) eine Einheit eines bestimmten zugrunde liegenden Vermögenswerts (z. B. Gold, USD) zur Verfügung stellt, eine Einheit der Währung bereitstellt. Der Herausgeber verspricht dann, eine Einheit des zugrunde liegenden Assets an jeden zu liefern, der ihm eine Einheit des Krypto-Assets zurücksendet. Dieser Mechanismus ermöglicht es, jedes nicht-kryptografische Asset in ein kryptografisches Asset „aufzuwerten“, vorausgesetzt, dem Herausgeber kann vertraut werden.
-In der Praxis sind Herausgeber jedoch nicht immer vertrauenswürdig, und in einigen Fällen ist die Bankinfrastruktur zu schwach oder zu feindlich, als dass solche Dienstleistungen existieren könnten. Finanzderivate bieten eine Alternative. Hier spielt anstelle eines einzelnen Herausgebers, der die Mittel zur Deckung eines Assets bereitstellt, ein dezentraler Markt von Spekulanten diese Rolle, die darauf wetten, dass der Preis eines kryptografischen Referenz-Assets (z. B. ETH) steigen wird. Anders als Herausgeber haben Spekulanten keine Option, ihren Verpflichtungen nicht nachzukommen, da der Hedging-Vertrag ihre Mittel in einem Treuhandkonto hält. Beachten Sie, dass dieser Ansatz nicht vollständig dezentralisiert ist, da eine vertrauenswürdige Quelle weiterhin benötigt wird, um den Preisticker bereitzustellen. Dennoch ist dies in Bezug auf die Reduzierung der Infrastrukturanforderungen (im Gegensatz zum Herausgeber, der für die Ausgabe der Preisfeeds keine Lizenzen benötigt und wahrscheinlich als freie Meinungsäußerung eingestuft werden kann) und die Verringerung des Betrugsrisikos eine erhebliche Verbesserung.
+In der Praxis sind Herausgeber jedoch nicht immer vertrauenswürdig, und in einigen Fällen ist die Bankinfrastruktur zu schwach oder zu feindlich, als dass solche Dienstleistungen existieren könnten. Finanzderivate bieten eine Alternative. Hier spielt anstelle eines einzelnen Emittenten, der die Mittel zur Deckung eines Vermögenswerts bereitstellt, ein dezentraler Markt von Spekulanten, die darauf wetten, dass der Preis eines kryptografischen Referenzvermögenswerts (z. B. ETH) steigen wird, diese Rolle. Anders als Herausgeber haben Spekulanten keine Option, ihren Verpflichtungen nicht nachzukommen, da der Hedging-Vertrag ihre Mittel in einem Treuhandkonto hält. Beachten Sie, dass dieser Ansatz nicht vollständig dezentralisiert ist, da eine vertrauenswürdige Quelle weiterhin benötigt wird, um den Preisticker bereitzustellen. Dennoch ist dies in Bezug auf die Reduzierung der Infrastrukturanforderungen (im Gegensatz zum Herausgeber, der für die Ausgabe der Preisfeeds keine Lizenzen benötigt und wahrscheinlich als freie Meinungsäußerung eingestuft werden kann) und die Verringerung des Betrugsrisikos eine erhebliche Verbesserung.
### Identitäts- und Reputationssysteme {#identity-and-reputation-systems}
-Die früheste alternative Kryptowährung, [Namecoin](http://namecoin.org/), versuchte, eine Bitcoin-ähnliche Blockchain zu nutzen, um ein Namensregistrierungssystem bereitzustellen, in dem Benutzer ihre Namen in einer öffentlichen Datenbank zusammen mit anderen Daten registrieren können. Ein häufig zitierter Anwendungsfall ist ein [DNS](https://wikipedia.org/wiki/Domain_Name_System)-System, das einen Domänennamen wie „bitcoin.org“ (oder „bitcoin.bit“ bei Namecoin) mit einer IP-Adresse verknüpft. Weitere Anwendungsfälle umfassen die E-Mail-Authentifizierung und potenziell fortschrittlichere Reputationssysteme. Hier ist der grundlegende Vertrag, um ein Namecoin-ähnliches Namensregistrierungssystem auf Ethereum bereitzustellen:
+Die früheste alternative Kryptowährung von allen, [Namecoin](http://namecoin.org/), versuchte, eine Bitcoin-ähnliche Blockchain zu verwenden, um ein Namensregistrierungssystem bereitzustellen, bei dem Benutzer ihre Namen in einer öffentlichen Datenbank zusammen mit anderen Daten registrieren können. Der wichtigste angeführte Anwendungsfall ist ein [DNS](https://wikipedia.org/wiki/Domain_Name_System)-System, das Domainnamen wie „bitcoin.org“ (oder im Fall von Namecoin „bitcoin.bit“) einer IP-Adresse zuordnet. Weitere Anwendungsfälle umfassen die E-Mail-Authentifizierung und potenziell fortschrittlichere Reputationssysteme. Hier ist der grundlegende Vertrag, um ein Namecoin-ähnliches Namensregistrierungssystem auf Ethereum bereitzustellen:
```py
def register(name, value):
@@ -295,33 +295,33 @@ def register(name, value):
self.storage[name] = value
```
-Der Vertrag ist sehr einfach; er ist lediglich eine Datenbank innerhalb des Ethereum-Netzwerks, die ergänzt, aber nicht verändert oder entfernt werden kann. Jeder kann einen Namen mit einem gewissen Wert registrieren, und diese Registrierung bleibt dann für immer bestehen. Ein ausgeklügelterer Namensregistrierungsvertrag besitzt auch eine „Funktionsklausel“, die es anderen Verträgen ermöglicht, Abfragen vorzunehmen, sowie einen Mechanismus für den „Eigentümer“ (d. h. den ersten Registrierer) eines Namens, um die Daten zu ändern oder das Eigentum zu übertragen. Darüber hinaus kann man sogar noch Reputations- und Web-of-Trust-Funktionalitäten hinzufügen.
+Der Vertrag ist sehr einfach; er ist lediglich eine Datenbank innerhalb des Ethereum-Netzwerks, die ergänzt, aber nicht verändert oder entfernt werden kann. Jeder kann einen Namen mit einem gewissen Wert registrieren, und diese Registrierung bleibt dann für immer bestehen. Ein anspruchsvollerer Namensregistrierungsvertrag wird auch eine „Funktionsklausel“ haben, die es anderen Verträgen ermöglicht, ihn abzufragen, sowie einen Mechanismus für den „Eigentümer“ (d. h. den ersten Registranten) eines Namens, um die Daten zu ändern oder das Eigentum zu übertragen. Darüber hinaus kann man sogar noch Reputations- und Web-of-Trust-Funktionalitäten hinzufügen.
-### Dezentralisierter Dateispeicher {#decentralized-file-storage}
+### Dezentraler Dateispeicher {#decentralized-file-storage}
In den letzten Jahren sind eine Reihe beliebter Online-Dateispeicher-Startups entstanden, wobei das bekannteste Dropbox ist. Diese Dienste erlauben es dem Benutzer, ein Backup seiner Festplatte hochzuladen, das dann gespeichert wird, sodass der Benutzer gegen eine monatliche Gebühr darauf zugreifen kann. Derzeit ist der Dateispeichermarkt jedoch manchmal relativ ineffizient; ein oberflächlicher Blick auf verschiedene vorhandene Lösungen zeigt, dass insbesondere im „uncanny valley“-Bereich von 20–200 GB, in dem weder kostenlose Quoten noch Rabatte für Unternehmen greifen, die monatlichen Preise für gängige Dateispeicherlösungen so hoch sind, dass man mehr für einen Monat bezahlt als für die gesamte Festplatte. Ethereum-Verträge können die Entwicklung eines dezentralisierten Dateispeicher-Ökosystems ermöglichen, in dem einzelne Benutzer kleine Beträge verdienen können, indem sie ihre eigenen Festplatten vermieten. Ungenutzter Speicherplatz kann dazu verwendet werden, die Kosten für den Dateispeicher weiter zu senken.
-Das zentrale Element eines solchen Systems wäre das, was wir als den „dezentralisierten Dropbox-Vertrag“ nennen. Dieser Vertrag funktioniert wie folgt. Zuerst wird die gewünschte Datenmenge in Blöcke aufgeteilt, wobei jeder Block im Sinne des Datenschutzes verschlüsselt wird, und daraus wird ein Merkle Tree erstellt. Anschließend wird ein Vertrag erstellt, der die Regel enthält, dass der Vertrag alle N Blöcke einen zufälligen Index im Merkle Tree auswählt (unter Verwendung des Hashes des vorherigen Blocks, der im Vertragscode zugänglich ist, als Zufallsquelle) und X Ether an die erste Entität vergibt, die eine Transaktion mit einem vereinfachten Nachweis über das Eigentum am Block an diesem bestimmten Index im Baum vorlegt. Wenn ein Benutzer seine Datei erneut herunterladen möchte, kann er ein Mikrozahlungsprotokoll verwenden (z. B. 1 Szabo pro 32 Kilobyte zahlen), um die Datei wiederherzustellen. Der gebühreneffizienteste Ansatz besteht darin, dass der Zahler die Transaktion bis zum Ende nicht veröffentlicht, sondern die Transaktion nach jeweils 32 Kilobyte durch eine etwas lukrativere mit demselben Nonce ersetzt.
+Das zentrale Element eines solchen Systems wäre das, was wir als den „dezentralisierten Dropbox-Vertrag“ nennen. Dieser Vertrag funktioniert wie folgt. Zuerst wird die gewünschte Datenmenge in Blöcke aufgeteilt, wobei jeder Block im Sinne des Datenschutzes verschlüsselt wird, und daraus wird ein Merkle Tree erstellt. Anschließend wird ein Vertrag erstellt, der die Regel enthält, dass der Vertrag alle N Blöcke einen zufälligen Index im Merkle Tree auswählt (unter Verwendung des Hashes des vorherigen Blocks, der im Vertragscode zugänglich ist, als Zufallsquelle) und X Ether an die erste Entität vergibt, die eine Transaktion mit einem vereinfachten Nachweis über das Eigentum am Block an diesem bestimmten Index im Baum vorlegt. Wenn ein Benutzer seine Datei erneut herunterladen möchte, kann er ein Micropayment-Channel-Protokoll (z. B. 1 Szabo pro 32 Kilobyte) verwenden, um die Datei wiederherzustellen; der gebühreneffizienteste Ansatz ist, dass der Zahler die Transaktion nicht bis zum Ende veröffentlicht, sondern die Transaktion nach jeweils 32 Kilobyte durch eine etwas lukrativere mit derselben Nonce ersetzt.
Eine wichtige Eigenschaft des Protokolls ist, dass man, obwohl es scheinen mag, als vertraue man zahlreichen zufälligen Knoten dabei, die Datei nicht zu vergessen, dieses Risiko auf nahezu null reduzieren kann, indem man die Datei durch geheimes Teilen in viele Stücke aufteilt und die Verträge überwacht, um sicherzustellen, dass jedes Stück noch im Besitz eines Knotens ist. Wenn ein Vertrag weiterhin Geld auszahlt, ist dies ein kryptografischer Beweis dafür, dass jemand da draußen die Datei noch speichert.
-### Dezentralisierte autonome Organisationen {#decentralized-autonomous-organizations}
+### Dezentrale autonome Organisationen {#decentralized-autonomous-organizations}
Das allgemeine Konzept einer „dezentralisierten autonomen Organisation“ bezieht sich auf eine virtuelle Entität, die eine bestimmte Gruppe von Mitgliedern oder Aktionären hat, die möglicherweise mit einer 67-%-Mehrheit das Recht haben, die Mittel der Entität auszugeben und ihren Code zu ändern. Die Mitglieder entscheiden gemeinsam, wie die Organisation ihre Mittel einsetzen sollte. Methoden zur Zuteilung der Mittel einer DAO könnten von Kopfgeldern und Gehältern bis hin zu exotischeren Mechanismen wie einer internen Währung reichen, um Arbeit zu belohnen. Dies stellt im Grunde die rechtlichen Rahmenbedingungen eines herkömmlichen Unternehmens oder einer Nonprofit-Organisation nach, nutzt dabei jedoch ausschließlich kryptografische Blockchain-Technologie zur Durchsetzung. Bisher hat sich viel von der Diskussion über DAOs um das „kapitalistische“ Modell einer „dezentralisierten autonomen Corporation“ (DAC) gedreht, mit dividendenberechtigten Aktionären und handelbaren Anteilen; eine Alternative, die vielleicht als „dezentralisierte autonome Community“ beschrieben werden kann, würde vorsehen, dass alle Mitglieder ein gleiches Mitspracherecht bei Entscheidungen haben und 67 % der bestehenden Mitglieder zustimmen müssen, um ein Mitglied hinzuzufügen oder zu entfernen. Die Anforderung, dass eine Person nur eine Mitgliedschaft haben kann, müsste dann kollektiv von der Gruppe durchgesetzt werden.
Ein allgemeiner Überblick über die Codierung einer DAO sieht folgendermaßen aus. Das einfachste Design besteht aus einem Stück selbstmodifizierendem Code, der sich ändert, wenn zwei Drittel der Mitglieder einer Änderung zustimmen. Obwohl Code theoretisch unveränderlich ist, kann man dies leicht umgehen und de facto Veränderlichkeit erreichen, indem man Teile des Codes in separaten Verträgen speichert und die Adressen der aufzurufenden Verträge im veränderbaren Speicher ablegt. In einer einfachen Implementierung eines solchen DAO-Vertrags gibt es drei Transaktionsarten, die anhand der in der Transaktion bereitgestellten Daten unterschieden werden:
-- `[0,i,K,V]`, um einen Vorschlag mit Index `i` zu registrieren, um die Adresse am Speicherindex `K` auf den Wert `V` zu ändern
+- `[0,i,K,V]`, um einen Vorschlag mit dem Index `i` zu registrieren, die Adresse am Speicherindex `K` auf den Wert `V` zu ändern
- `[1,i]`, um eine Stimme für den Vorschlag `i` zu registrieren
-- `[2,i]`, um den Vorschlag `i` abzuschließen, wenn genügend Stimmen abgegeben worden sind
+- `[2,i]`, um den Vorschlag `i` abzuschließen, wenn genügend Stimmen abgegeben wurden
-Der Vertrag hätte dann Klauseln für jeden Fall. Es würde eine Aufzeichnung aller offenen Änderungen am Speicher sowie eine Liste der entsprechenden Abstimmenden führen. Er würde auch eine Liste aller Mitglieder enthalten. Wenn eine Speicheränderung von zwei Dritteln der Mitglieder unterstützt wird, könnte eine abschließende Transaktion die Änderung ausführen. Ein ausgeklügelteres Gerüst würde auch eine integrierte Abstimmung für Funktionen wie das Senden einer Transaktion und das Hinzufügen und Entfernen von Mitgliedern beinhalten und könnte sogar eine [Liquid Democracy](https://wikipedia.org/wiki/Liquid_democracy)-ähnliche Stimmdelegation ermöglichen (d. h., jeder kann jemanden ernennen, der für ihn abstimmt, und die Ernennung ist transitiv, sodass, wenn A B ernennt und B C ernennt, C über As Stimme entscheidet). Dieses Design würde es der DAO ermöglichen, organisch als dezentralisierte Community zu wachsen, wodurch die Menschen letztendlich die Aufgabe an Spezialisten delegieren können, herauszufiltern, wer ein Mitglied ist. Anders als im „aktuellen System“ können Spezialisten jedoch im Laufe der Zeit leicht ein- und ausgehen, während sich die Ausrichtungen einzelner Community-Mitglieder ändern.
+Der Vertrag hätte dann Klauseln für jeden Fall. Es würde eine Aufzeichnung aller offenen Änderungen am Speicher sowie eine Liste der entsprechenden Abstimmenden führen. Er würde auch eine Liste aller Mitglieder enthalten. Wenn eine Speicheränderung von zwei Dritteln der Mitglieder unterstützt wird, könnte eine abschließende Transaktion die Änderung ausführen. Ein anspruchsvolleres Gerüst hätte auch eine eingebaute Abstimmungsfähigkeit für Funktionen wie das Senden einer Transaktion, das Hinzufügen und Entfernen von Mitgliedern und könnte sogar eine Stimmrechtsdelegation im Stil der [Liquid Democracy](https://wikipedia.org/wiki/Liquid_democracy) vorsehen (d. h., jeder kann jemanden beauftragen, für ihn zu stimmen, und die Beauftragung ist transitiv, sodass, wenn A B beauftragt und B C beauftragt, C über die Stimme von A entscheidet). Dieses Design würde es der DAO ermöglichen, organisch als dezentralisierte Community zu wachsen, wodurch die Menschen letztendlich die Aufgabe an Spezialisten delegieren können, herauszufiltern, wer ein Mitglied ist. Anders als im „aktuellen System“ können Spezialisten jedoch im Laufe der Zeit leicht ein- und ausgehen, während sich die Ausrichtungen einzelner Community-Mitglieder ändern.
Ein alternatives Modell ist das einer dezentralisierten Corporation, bei der jedes Konto null oder mehr Anteile haben kann und zwei Drittel der Anteile erforderlich sind, um eine Entscheidung zu treffen. Ein vollständiges Gerüst würde Funktionen für das Asset-Management beinhalten, die Möglichkeit, ein Angebot zum Kauf oder Verkauf von Aktien zu machen, sowie die Fähigkeit, Angebote zu akzeptieren (idealerweise mit einem Ordermatching-Mechanismus im Vertrag). Es würde auch eine Delegation im Stil der Liquid Democracy geben, die das Konzept eines „Vorstands“ verallgemeinert.
### Weitere Anwendungen {#further-applications}
-**1. Spar-Wallets**. Nehmen wir an, Alice möchte ihre Mittel schützen, ist jedoch besorgt, dass sie ihren privaten Schlüssel verlieren oder jemand ihn hacken könnte. Sie schließt mit Bob, einer Bank, einen Vertrag über Ether ab, und zwar wie folgt:
+**1. Spar-Wallets**. Nehmen wir an, Alice möchte ihre Mittel schützen, ist jedoch besorgt, dass sie ihren privaten Schlüssel verlieren oder jemand ihn hacken könnte. Sie schließt mit Bob, einer Bank, einen Vertrag über Ether ab, und zwar wie folgt:
- Alice allein kann maximal 1 % der Mittel pro Tag abheben.
- Bob allein kann maximal 1 % der Mittel pro Tag abheben, aber Alice hat die Möglichkeit, eine Transaktion mit ihrem Schlüssel durchzuführen, die diese Möglichkeit ausschaltet.
@@ -331,23 +331,23 @@ Normalerweise ist 1 % pro Tag genug für Alice, und wenn sie mehr abheben möcht
**2. Ernteversicherung**. Man kann leicht einen Vertrag für Finanzderivate erstellen, indem man anstelle eines Preisindexes einen Datenfeed über das Wetter verwendet. Wenn ein Landwirt in Iowa ein Derivat kauft, das umgekehrt auf die Niederschläge in Iowa basiert, erhält der Landwirt im Falle einer Dürre automatisch Geld, und wenn es genug regnet, wird der Landwirt glücklich sein, weil die Ernte gut gedeiht. Dies kann auf die Naturkatastrophenversicherung im Allgemeinen ausgeweitet werden.
-**3. Ein dezentralisierter Datenfeed**. Bei Finanzverträgen über Differenzen könnte es tatsächlich möglich sein, den Datenfeed über ein Protokoll namens „[SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)“ zu dezentralisieren. SchellingCoin funktioniert im Wesentlichen wie folgt: N Parteien geben alle den Wert eines bestimmten Datums in das System ein (z. B. den ETH-USD-Preis), die Werte werden sortiert, und jeder, der zwischen dem 25. und dem 75. Perzentil liegt, erhält als Belohnung ein Token. Jeder hat den Anreiz, die Antwort zu geben, die auch alle anderen geben werden, und der einzige Wert, auf den sich eine große Anzahl von Spielern realistisch einigen kann, ist der offensichtliche Standard: die Wahrheit. Dies schafft ein dezentralisiertes Protokoll, das theoretisch beliebig viele Werte liefern kann, einschließlich des ETH-USD-Preises, der Temperatur in Berlin oder sogar des Ergebnisses einer bestimmten rechenintensiven Berechnung.
+**3. Ein dezentralisierter Datenfeed**. Bei finanziellen Differenzkontrakten könnte es tatsächlich möglich sein, den Daten-Feed über ein Protokoll namens „[SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)“ zu dezentralisieren. SchellingCoin funktioniert im Grunde wie folgt: N Parteien geben alle den Wert eines gegebenen Datums (z. B. den ETH/USD-Preis) in das System ein, die Werte werden sortiert, und jeder zwischen dem 25. und 75. Perzentil erhält einen Token als Belohnung. Jeder hat den Anreiz, die Antwort zu geben, die auch alle anderen geben werden, und der einzige Wert, auf den sich eine große Anzahl von Spielern realistisch einigen kann, ist der offensichtliche Standard: die Wahrheit. Dies schafft ein dezentralisiertes Protokoll, das theoretisch beliebig viele Werte liefern kann, einschließlich des ETH-USD-Preises, der Temperatur in Berlin oder sogar des Ergebnisses einer bestimmten rechenintensiven Berechnung.
**4. Intelligentes Mehrfachsignatur-Treuhandkonto**. Bitcoin ermöglicht Mehrfachsignatur-Transaktionsverträge, bei denen beispielsweise drei von fünf Schlüsseln die Mittel ausgeben können. Ethereum erlaubt eine genauere Granularität; zum Beispiel können vier von fünf alles ausgeben, drei von fünf können bis zu 10 % pro Tag ausgeben, und zwei von fünf können bis zu 0,5 % pro Tag ausgeben. Zusätzlich ist die Ethereum-Mehrfachsignatur asynchron – zwei Parteien können ihre Signaturen zu unterschiedlichen Zeiten auf der Blockchain registrieren, und die letzte Signatur sendet automatisch die Transaktion.
-**5. Cloud-Computing**. Die EVM-Technologie kann auch genutzt werden, um eine verifizierbare Rechenumgebung zu schaffen, die es Benutzern ermöglicht, andere zu bitten, Berechnungen durchzuführen, und dann optional nach Beweisen zu fragen, dass Berechnungen an bestimmten zufällig ausgewählten Kontrollpunkten korrekt durchgeführt wurden. Dies erlaubt die Einrichtung eines Marktes für Cloud-Computing, in dem jeder Benutzer mit seinem Desktop, Laptop oder spezialisierten Server teilnehmen kann, und Stichprobenkontrollen sowie Sicherheitsanforderungen können verwendet werden, um sicherzustellen, dass das System vertrauenswürdig ist (d. h., Knoten können nicht profitabel betrügen). Obwohl ein solches System möglicherweise nicht für alle Aufgaben geeignet ist, können Aufgaben, die ein hohes Maß an Zwischenprozesskommunikation erfordern, beispielsweise nicht leicht in einer großen Cloud von Knoten durchgeführt werden. Andere Aufgaben lassen sich jedoch viel leichter parallelisieren; Projekte wie SETI@home, folding@home und genetische Algorithmen können leicht auf einer solchen Plattform implementiert werden.
+**5. Cloud-Computing**. Die EVM-Technologie kann auch genutzt werden, um eine verifizierbare Rechenumgebung zu schaffen, die es Benutzern ermöglicht, andere zu bitten, Berechnungen durchzuführen, und dann optional nach Beweisen zu fragen, dass Berechnungen an bestimmten zufällig ausgewählten Kontrollpunkten korrekt durchgeführt wurden. Dies ermöglicht die Schaffung eines Cloud-Computing-Marktes, an dem jeder Benutzer mit seinem Desktop, Laptop oder spezialisierten Server teilnehmen kann, und Stichprobenkontrollen zusammen mit Sicherheitsleistungen können verwendet werden, um sicherzustellen, dass das System vertrauenswürdig ist (d. h., Nodes können nicht gewinnbringend betrügen). Obwohl ein solches System möglicherweise nicht für alle Aufgaben geeignet ist, können Aufgaben, die ein hohes Maß an Zwischenprozesskommunikation erfordern, beispielsweise nicht leicht in einer großen Cloud von Knoten durchgeführt werden. Andere Aufgaben lassen sich jedoch viel leichter parallelisieren; Projekte wie SETI@home, folding@home und genetische Algorithmen können leicht auf einer solchen Plattform implementiert werden.
-**6. Peer-to-Peer-Glücksspiel**. Eine beliebige Anzahl von Peer-to-Peer-Glücksspielprotokollen, wie zum Beispiel Frank Stajano und Richard Claytons [Cyberdice](http://www.cl.cam.ac.uk/\~fms27/papers/2008-StajanoCla-cyberdice.pdf), kann auf der Ethereum-Blockchain implementiert werden. Das einfachste Glücksspielprotokoll ist tatsächlich einfach ein Differenzvertrag auf den nächsten Block-Hash, und fortgeschrittenere Protokolle können darauf aufbauen, um Glücksspieldienste mit nahezu null Gebühren zu schaffen, die keine Betrugsmöglichkeiten bieten.
+**6.** Peer-to-Peer-Glücksspiel\*\*. Beliebig viele Peer-to-Peer-Glücksspielprotokolle, wie z. B. Frank Stajanos und Richard Claytons [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf), können auf der Ethereum-Blockchain implementiert werden. Das einfachste Glücksspielprotokoll ist tatsächlich einfach ein Differenzvertrag auf den nächsten Block-Hash, und fortgeschrittenere Protokolle können darauf aufbauen, um Glücksspieldienste mit nahezu null Gebühren zu schaffen, die keine Betrugsmöglichkeiten bieten.
-**7. Prognosemärkte**. Wenn ein Oracle oder SchellingCoin vorhanden ist, lassen sich Prognosemärkte ebenfalls leicht implementieren, und in Kombination mit SchellingCoin könnten Prognosemärkte die erste gängige Anwendung von [Futarchie](http://hanson.gmu.edu/futarchy.html) als Governance-Protokoll für dezentralisierte Organisationen darstellen.
+**7.** Prognosemärkte\*\*. Sofern ein Oracle oder SchellingCoin vorhanden ist, sind auch Prognosemärkte einfach zu implementieren, und Prognosemärkte zusammen mit SchellingCoin könnten sich als die erste Mainstream-Anwendung der [Futarchie](https://mason.gmu.edu/~rhanson/futarchy.html) als Governance-Protokoll für dezentrale Organisationen erweisen.
-**8. On-Chain-dezentralisierte Marktplätze**, die das Identitäts- und Reputationssystem als Basis nutzen.
+**8. On-Chain dezentrale Marktplätze**, die das Identitäts- und Reputationssystem als Basis nutzen.
## Verschiedenes und Bedenken {#miscellanea-and-concerns}
### Modifizierte GHOST-Implementierung {#modified-ghost-implementation}
-Das „Greedy Heaviest Observed Subtree“(GHOST)-Protokoll ist eine Innovation, die erstmals von Yonatan Sompolinsky und Aviv Zohar im [Dezember 2013](https://eprint.iacr.org/2013/881.pdf) vorgestellt wurde. Die Motivation hinter GHOST ist, dass Blockchains mit schnellen Bestätigungszeiten derzeit unter einer verringerten Sicherheit leiden, aufgrund einer hohen Veralterungsrate – weil Blöcke eine bestimmte Zeit benötigen, um sich im Netzwerk auszubreiten. Wenn Miner A einen Block mint und dann Miner B zufällig einen weiteren Block mint, bevor der Block von Miner A zu B propagiert, wird der Block von Miner B letztlich verschwendet und trägt nicht zur Netzwerksicherheit bei. Darüber hinaus gibt es ein Zentralisierungsproblem: Wenn Miner A ein Mining-Pool mit 30 % Hash-Power ist und B 10 % Hash-Power hat, hat A ein Risiko von 70 %, einen veralteten Block zu erzeugen (da A die letzten 30 % der Zeit den letzten Block produziert hat und somit die Mining-Daten sofort erhält), während B ein Risiko von 90 % hat, einen veralteten Block zu erzeugen. Wenn das Blockintervall also kurz genug ist, um die Veralterungsrate hoch zu halten, wird A folglich allein aufgrund seiner Größe wesentlich effizienter sein. Durch die Kombination dieser beiden Effekte ist es sehr wahrscheinlich, dass Blockchains, die schnell Blöcke produzieren, dazu führen, dass ein Mining-Pool einen ausreichend großen Anteil der Netzwerk-Hash-Power hat, um de facto die Kontrolle über den Mining-Prozess zu übernehmen.
+Das „Greedy Heaviest Observed Subtree“ (GHOST)-Protokoll ist eine Innovation, die erstmals von Yonatan Sompolinsky und Aviv Zohar im [Dezember 2013](https://eprint.iacr.org/2013/881.pdf) vorgestellt wurde. Die Motivation hinter GHOST ist, dass Blockchains mit schnellen Bestätigungszeiten derzeit unter einer verringerten Sicherheit leiden, aufgrund einer hohen Veralterungsrate – weil Blöcke eine bestimmte Zeit benötigen, um sich im Netzwerk auszubreiten. Wenn Miner A einen Block mint und dann Miner B zufällig einen weiteren Block mint, bevor der Block von Miner A zu B propagiert, wird der Block von Miner B letztlich verschwendet und trägt nicht zur Netzwerksicherheit bei. Darüber hinaus gibt es ein Zentralisierungsproblem: Wenn Miner A ein Mining-Pool mit 30 % Hash-Power ist und B 10 % Hash-Power hat, hat A ein Risiko von 70 %, einen veralteten Block zu erzeugen (da A die letzten 30 % der Zeit den letzten Block produziert hat und somit die Mining-Daten sofort erhält), während B ein Risiko von 90 % hat, einen veralteten Block zu erzeugen. Wenn das Blockintervall also kurz genug ist, um die Veralterungsrate hoch zu halten, wird A folglich allein aufgrund seiner Größe wesentlich effizienter sein. Durch die Kombination dieser beiden Effekte ist es sehr wahrscheinlich, dass Blockchains, die schnell Blöcke produzieren, dazu führen, dass ein Mining-Pool einen ausreichend großen Anteil der Netzwerk-Hash-Power hat, um de facto die Kontrolle über den Mining-Prozess zu übernehmen.
Wie von Sompolinsky und Zohar beschrieben, löst GHOST das erste Problem des Verlusts an Netzwerksicherheit, indem er veraltete Blöcke in die Berechnung einbezieht, welche Kette die „längste“ ist; das heißt, nicht nur die übergeordneten und noch früheren Vorgänger eines Blocks, sondern auch die veralteten Nachfolger der Vorgänger des Blocks (in der Ethereum-Sprache „Uncles“) werden in die Berechnung einbezogen, welcher Block die größte Gesamtmenge an Proof-of-Work unterstützt. Um das zweite Problem des Zentralisierungs-Bias zu lösen, gehen wir über das von Sompolinsky und Zohar beschriebene Protokoll hinaus und bieten auch Blockbelohnungen für veraltete Blöcke an: Ein veralteter Block erhält 87,5 % seiner Grundbelohnung, und der Neffe, der den veralteten Block enthält, erhält die verbleibenden 12,5 %. Die Transaktionsgebühren werden jedoch nicht an die Onkel vergeben.
@@ -355,7 +355,7 @@ Ethereum implementiert eine vereinfachte Version von GHOST, die nur sieben Ebene
- Ein Block muss einen übergeordneten Block sowie 0 oder mehr Onkel angeben
- Ein Onkel, der im Block B enthalten ist, muss die folgenden Eigenschaften haben:
- - Es muss ein direkter Nachfahre des Vorfahren der k. Generation von B sein, wobei `2 <= k <= 7`.
+ - Es muss ein direkter Nachkomme des Vorfahren der k-ten Generation von B sein, wobei `2 <= k <= 7`.
- Er kann kein Vorfahre von B sein
- Ein Onkel muss ein gültiger Block-Header sein, muss aber kein zuvor verifizierter oder gar gültiger Block sein
- Ein Onkel muss sich von allen Onkeln unterscheiden, die in früheren Blöcken enthalten waren, sowie von allen anderen Onkeln, die im selben Block enthalten sind (keine doppelte Aufnahme)
@@ -369,12 +369,12 @@ Da jede Transaktion, die in die Blockchain veröffentlicht wird, Kosten für das
Wie sich jedoch herausstellt, hebt dieser Mangel im marktgestützten Mechanismus, bei einer bestimmten ungenauen vereinfachenden Annahme, sich selbst magisch auf. Das Argument lautet wie folgt. Nehmen wir an:
-1. Eine Transaktion führt zu `k` Operationen und bietet eine Belohnung von `kR` für jeden Miner, der sie einfügt, wobei `R` vom Absender festgelegt wird und `k` und `R` (grob gesagt) im Voraus für den Miner sichtbar sind.
-2. Eine Operation hat für jeden Knoten Verarbeitungskosten von `C` (d. h., alle Knoten haben die gleiche Effizienz).
-3. Es gibt `N` Mining-Knoten, die jeweils genau die gleiche Verarbeitungsleistung besitzen (d. h. `1/N` der Gesamtzahl).
+1. Eine Transaktion führt zu `k` Operationen und bietet jedem Miner, der sie einschließt, die Belohnung `kR`, wobei `R` vom Absender festgelegt wird und `k` und `R` (grob) für den Miner im Voraus sichtbar sind.
+2. Eine Operation hat für jeden Node Verarbeitungskosten von `C` (d. h. alle Nodes haben die gleiche Effizienz)
+3. Es gibt `N` Mining-Nodes mit jeweils exakt gleicher Rechenleistung (d. h. `1/N` der Gesamtleistung)
4. Es gibt keine Vollknoten ohne Mining.
-Ein Miner wäre bereit, eine Transaktion zu verarbeiten, wenn die erwartete Belohnung höher ist als die Kosten. Somit beträgt die erwartete Belohnung `kR/N`, da der Miner eine `1/N`-Chance hat, den nächsten Block zu verarbeiten, und die Verarbeitungskosten für den Miner einfach `kC` betragen. Folglich schließen Miner Transaktionen ein, bei denen `kR/N > kC` oder `R > NC` ist. Beachten Sie, dass `R` die Gebühr pro Operation ist, die vom Absender bereitgestellt wird, und somit eine untere Grenze für den Nutzen darstellt, den der Absender aus der Transaktion zieht, während `NC` die Gesamtkosten für das gesamte Netzwerk zur Verarbeitung einer Operation sind. Daher haben Miner den Anreiz, nur diejenigen Transaktionen einzuschließen, deren gesamter utilitaristischer Nutzen die Kosten übersteigt.
+Ein Miner wäre bereit, eine Transaktion zu verarbeiten, wenn die erwartete Belohnung höher ist als die Kosten. Daher beträgt die erwartete Belohnung `kR/N`, da der Miner eine `1/N`-Chance hat, den nächsten Block zu verarbeiten, und die Verarbeitungskosten für den Miner einfach `kC` betragen. Daher werden Miner Transaktionen einschließen, bei denen `kR/N > kC`, oder `R > NC` gilt. Beachten Sie, dass `R` die vom Absender bereitgestellte Gebühr pro Operation ist und somit eine untere Grenze für den Nutzen darstellt, den der Absender aus der Transaktion zieht, und `NC` sind die Kosten für das gesamte Netzwerk zusammen für die Verarbeitung einer Operation. Daher haben Miner den Anreiz, nur diejenigen Transaktionen einzuschließen, deren gesamter utilitaristischer Nutzen die Kosten übersteigt.
Allerdings gibt es in Wirklichkeit mehrere wichtige Abweichungen von diesen Annahmen:
@@ -383,29 +383,33 @@ Allerdings gibt es in Wirklichkeit mehrere wichtige Abweichungen von diesen Anna
3. Die Verteilung der Mining-Power könnte sich in der Praxis als radikal ungleichheitsfördernd erweisen.
4. Es gibt Spekulanten, politische Widersacher und Irre, deren Hilfsfunktion darin besteht, dem Netzwerk zu schaden, und sie können geschickt Verträge aufbauen, bei denen ihre Kosten deutlich unter denen der anderen prüfenden Knoten liegen.
-(1) führt dazu, dass Miner weniger Transaktionen einfügen, und (2) erhöht `NC`; daher heben sich diese beiden Effekte zumindest teilweise auf.[Wie?](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260) (3) und (4) sind das Hauptproblem; um sie zu lösen, setzen wir einfach eine dynamische Obergrenze fest: kein Block darf mehr Operationen enthalten als `BLK_LIMIT_FACTOR`-mal den langfristigen exponentiellen gleitenden Durchschnitt. Konkret:
+(1) bietet eine Tendenz für den Miner, weniger Transaktionen einzuschließen, und
+(2) erhöht `NC`; daher heben sich diese beiden Effekte zumindest teilweise
+gegenseitig auf.[Wie?](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260)
+(3) und (4) sind das Hauptproblem; um sie zu lösen, führen wir einfach eine variable Obergrenze ein: Kein Block kann mehr Operationen enthalten als das `BLK_LIMIT_FACTOR`-fache des langfristigen exponentiell gleitenden Durchschnitts.
+Konkret:
```js
blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)
```
-`BLK_LIMIT_FACTOR` und `EMA_FACTOR` sind Konstanten, die vorläufig auf 65536 und 1,5 gesetzt werden, aber wahrscheinlich nach weiteren Analysen geändert werden.
+`BLK_LIMIT_FACTOR` und `EMA_FACTOR` sind Konstanten, die vorerst auf 65536 und 1.5 gesetzt werden, aber nach weiterer Analyse wahrscheinlich geändert werden.
Ein weiterer Faktor, der große Blockgrößen in Bitcoin unattraktiv macht, ist, dass größere Blöcke länger zur Propagation benötigen und somit eine höhere Wahrscheinlichkeit haben, zu veralten. In Ethereum benötigen Blöcke, die viel Gas verbrauchen, auch länger zur Propagation, weil sie größer sind und weil die Verarbeitung der Statusübergänge der Transaktionen zur Validierung mehr Zeit in Anspruch nimmt. Diese Verzögerungsabschreckung ist ein bedeutender Aspekt in Bitcoin, jedoch aufgrund des GHOST-Protokolls weniger ausgeprägt in Ethereum; daher bietet das Verlassen auf regulierte Blockgrenzen eine stabilere Basis.
-### Berechnungen und Turing-Completeness {#computation-and-turing-completeness}
+### Berechnung und Turing-Vollständigkeit {#computation-and-turing-completeness}
-Ein wichtiger Hinweis ist, dass die virtuelle Maschine von Ethereum Turing-komplett ist; das bedeutet, dass der EVM-Code jede Berechnung, die möglicherweise ausgeführt werden kann, einschließlich Endlosschleifen, codieren kann. Der EVM-Code ermöglicht das Looping auf zwei Arten. Erstens gibt es eine `JUMP`-Anweisung, die das Programm an einen früheren Punkt im Code springen lässt, und eine `JUMPI`-Anweisung für bedingtes Springen, die solche Aussagen wie `while x < 27: x = x * 2` zulässt. Zweitens können Verträge andere Verträge aufrufen, was potenziell die Ausführung von Schleifen durch Rekursion ermöglicht. Dies führt zwangsläufig zu einem Problem: Können böswillige Benutzer Miner und vollständige Knoten im Grunde genommen ausschalten, indem sie sie in eine Endlosschleife zwingen? Das Problem ergibt sich aus einer Thematik in der Informatik, die als Halteproblem bekannt ist: Es gibt keine allgemeine Methode, um zu erkennen, ob ein bestimmtes Programm jemals zum Stillstand kommt oder nicht.
+Ein wichtiger Hinweis ist, dass die virtuelle Maschine von Ethereum Turing-komplett ist; das bedeutet, dass der EVM-Code jede Berechnung, die möglicherweise ausgeführt werden kann, einschließlich Endlosschleifen, codieren kann. Der EVM-Code ermöglicht das Looping auf zwei Arten. Erstens gibt es eine `JUMP`-Anweisung, die es dem Programm ermöglicht, zu einer früheren Stelle im Code zurückzuspringen, und eine `JUMPI`-Anweisung für bedingte Sprünge, die Anweisungen wie `while x < 27: x = x * 2` ermöglicht. Zweitens können Verträge andere Verträge aufrufen, was potenziell die Ausführung von Schleifen durch Rekursion ermöglicht. Dies führt zwangsläufig zu einem Problem: Können böswillige Benutzer Miner und vollständige Knoten im Grunde genommen ausschalten, indem sie sie in eine Endlosschleife zwingen? Das Problem ergibt sich aus einer Thematik in der Informatik, die als Halteproblem bekannt ist: Es gibt keine allgemeine Methode, um zu erkennen, ob ein bestimmtes Programm jemals zum Stillstand kommt oder nicht.
Wie im Abschnitt zu den Statusübergängen beschrieben funktioniert unsere Lösung, indem eine Transaktion die maximale Anzahl an Rechenschritten festlegt, die sie ausführen darf. Wenn die Ausführung länger dauert, wird die Berechnung zurückgesetzt, aber die Gebühren werden dennoch bezahlt. Nachrichten funktionieren auf die gleiche Weise. Um die Motivation hinter unserer Lösung zu verdeutlichen, betrachten Sie die folgenden Beispiele:
- Ein Angreifer erstellt einen Vertrag, der eine Endlosschleife ausführt, und sendet dann eine Transaktion, die diese Schleife beim Miner aktiviert. Der Miner verarbeitet die Transaktion, führt die Endlosschleife aus und wartet darauf, dass das Gas ausgeht. Auch wenn die Ausführung kein Gas mehr hat und mitten im Vorgang stoppt, ist die Transaktion weiterhin gültig, und der Miner erhält von dem Angreifer die Gebühr für jeden Rechenschritt.
-- Ein Angreifer erstellt eine sehr lange Endlosschleife mit der Absicht, den Miner dazu zu bringen, so lange zu rechnen, dass, wenn die Berechnung abgeschlossen ist, bereits einige weitere Blöcke erstellt wurden und es dem Miner nicht möglich ist, die Transaktion zur Einforderung der Gebühr einzuschließen. Allerdings muss der Angreifer einen Wert für `STARTGAS` angeben, der die Anzahl der Rechenschritte begrenzt, die die Ausführung benötigen kann. Dadurch weiß der Miner bereits im Voraus, dass die Berechnung eine übermäßig große Anzahl von Schritten benötigen wird.
-- Ein Angreifer entdeckt einen Vertrag mit Code in der Form `send(A,contract.storage[A]); contract.storage[A] = 0` und sendet eine Transaktion mit gerade genug Gas, um den ersten Schritt auszuführen, aber nicht den zweiten (d. h., eine Abhebung vorzunehmen, ohne den Saldo zu senken). Der Vertragsautor muss sich keine Sorgen um den Schutz vor solchen Angriffen machen, denn die Änderungen werden rückgängig gemacht, wenn die Ausführung im Änderungsprozess stoppt.
+- Ein Angreifer erstellt eine sehr lange Endlosschleife mit der Absicht, den Miner dazu zu bringen, so lange zu rechnen, dass, wenn die Berechnung abgeschlossen ist, bereits einige weitere Blöcke erstellt wurden und es dem Miner nicht möglich ist, die Transaktion zur Einforderung der Gebühr einzuschließen. Der Angreifer muss jedoch einen Wert für `STARTGAS` übermitteln, der die Anzahl der Rechenschritte begrenzt, die die Ausführung durchführen kann, sodass der Miner im Voraus weiß, dass die Berechnung eine übermäßig große Anzahl von Schritten erfordern wird.
+- Ein Angreifer sieht einen Vertrag mit Code der Form `send(A,contract.storage[A]); contract.storage[A] = 0` und sendet eine Transaktion mit gerade genug Gas, um den ersten Schritt auszuführen, aber nicht den zweiten (d. h. eine Auszahlung vorzunehmen, aber den Saldo nicht sinken zu lassen). Der Vertragsautor muss sich keine Sorgen um den Schutz vor solchen Angriffen machen, denn die Änderungen werden rückgängig gemacht, wenn die Ausführung im Änderungsprozess stoppt.
- Eine finanzielle Vereinbarung funktioniert, indem der Median von neun proprietären Datenfeeds genommen wird, um das Risiko zu minimieren. Ein Angreifer übernimmt einen der Datenfeeds, der so gestaltet ist, dass er über den variablen Adressaufruf-Mechanismus, der im Abschnitt über DAOs beschrieben ist, modifiziert werden kann, und wandelt ihn so um, dass er in einer Endlosschleife läuft, um damit zu versuchen, alle Unternehmungen, Mittel aus dem Finanzvertrag zu beanspruchen, an den Gas-Limit scheitern zu lassen. Jedoch kann der Finanzvertrag ein Gas-Limit für die Nachricht festlegen, um dieses Problem zu verhindern.
-Die Alternative zur Turing-Completeness ist Turing-Incompleteness, bei der `JUMP` und `JUMPI` nicht existieren und nur eine Kopie jedes Vertrags zu einem beliebigen Zeitpunkt im Aufrufstack existieren darf. Mit diesem System könnten das beschriebene Gebührensystem sowie die Unsicherheiten bezüglich der Wirksamkeit unserer Lösung möglicherweise entfallen, da die Kosten für die Ausführung eines Vertrags durch dessen Größe nach oben beschränkt wären. Zusätzlich ist Turing-Incompleteness nicht einmal eine allzu große Einschränkung; von allen Vertragsbeispielen, die wir intern konzipiert haben, benötigte bisher nur eines eine Schleife, und selbst diese Schleife konnte durch 26 Wiederholungen einer einzeiligen Codezeile entfernt werden. Angesichts der schwerwiegenden Folgen von Turing-Completeness und des begrenzten Nutzens – warum nicht einfach eine Turing-inkomplette Sprache verwenden? Tatsächlich ist Turing-Incompleteness jedoch alles andere als eine saubere Lösung für das Problem. Um den Grund zu verstehen, betrachten Sie die folgenden Verträge:
+Die Alternative zur Turing-Vollständigkeit ist die Turing-Unvollständigkeit, bei der `JUMP` und `JUMPI` nicht existieren und zu jedem Zeitpunkt nur eine Kopie jedes Vertrags im Aufrufstapel vorhanden sein darf. Mit diesem System könnten das beschriebene Gebührensystem sowie die Unsicherheiten bezüglich der Wirksamkeit unserer Lösung möglicherweise entfallen, da die Kosten für die Ausführung eines Vertrags durch dessen Größe nach oben beschränkt wären. Zusätzlich ist Turing-Incompleteness nicht einmal eine allzu große Einschränkung; von allen Vertragsbeispielen, die wir intern konzipiert haben, benötigte bisher nur eines eine Schleife, und selbst diese Schleife konnte durch 26 Wiederholungen einer einzeiligen Codezeile entfernt werden. Angesichts der schwerwiegenden Folgen von Turing-Completeness und des begrenzten Nutzens – warum nicht einfach eine Turing-inkomplette Sprache verwenden? Tatsächlich ist Turing-Incompleteness jedoch alles andere als eine saubere Lösung für das Problem. Um den Grund zu verstehen, betrachten Sie die folgenden Verträge:
```sh
C0: call(C1); call(C1);
@@ -418,7 +422,7 @@ C50: (einen Schritt eines Programms ausführen und die Änderung im Speicher auf
Nun soll eine Transaktion an A gedendet werden. Damit haben wir in 51 Transaktionen einen Vertrag, der 250 Rechenschritte benötigt. Miner könnten versuchen, solche „Logikbomben“ im Voraus zu erkennen, indem sie einen Wert neben jedem Vertrag beibehalten, der die maximale Anzahl an Rechenschritten angibt, die er ausführen kann. Dies müsste auch für Verträge gelten, die andere Verträge rekursiv aufrufen, was jedoch erfordert, dass Miner Verträge verbieten, die andere Verträge erstellen (da die Erstellung und Ausführung aller oben genannten 26 Verträge leicht zu einem einzigen Vertrag zusammengefasst werden könnte). Ein weiterer problematischer Aspekt besteht darin, dass das Adressfeld einer Nachricht variabel ist, weshalb es im Allgemeinen nicht einmal möglich sein könnte, im Voraus zu erkennen, welche anderen Verträge ein bestimmter Vertrag aufrufen könnte. Daher kommen wir unterm Strich zu einem überraschenden Schluss: Turing-Completeness ist überraschend einfach zu verwalten, und das Fehlen von Turing-Completeness ist ebenso überraschend schwierig zu verwalten, es sei denn, genau dieselben Kontrollmechanismen sind vorhanden – aber warum sollte man in diesem Fall das Protokoll nicht einfach Turing-komplett sein lassen?
-### Währung und Ausgabe {#currency-and-issuance}
+### Währung und Emission {#currency-and-issuance}
Das Ethereum-Netzwerk beinhaltet seine eigene integrierte Währung, Ether, die zwei Zwecke erfüllt: Zum einen dient sie als primäre Liquiditätsebene, um einen effizienten Austausch zwischen verschiedenen Arten von digitalen Assets zu ermöglichen, und zum anderen, wichtiger noch, stellt sie einen Mechanismus zur Bezahlung von Transaktionsgebühren bereit. Zur Vereinfachung und um zukünftige Streitigkeiten zu vermeiden (siehe die aktuelle Diskussion über mBTC/uBTC/Satoshi in Bitcoin), werden die Nennwerte vorab gekennzeichnet:
@@ -441,7 +445,7 @@ Das Ausgabemodell wird wie folgt aussehen:
| Währungseinheiten | 1,198-mal | 1,458-mal | 2,498-mal |
| Käufer | 83,5 % | 68,6 % | 40,0 % |
| Vor dem Verkauf ausgegebene Reserve | 8,26 % | 6,79 % | 3,96 % |
-| Nach dem Verkauf verwendete Reserve | 8.26% | 6.79% | 3.96% |
+| Nach dem Verkauf verwendete Reserve | 8,26 % | 6,79 % | 3,96 % |
| Miner | 0 % | 17,8 % | 52,0 % |
#### Langfristige Versorgungswachstumsrate (Prozent)
@@ -450,17 +454,17 @@ Das Ausgabemodell wird wie folgt aussehen:
_Trotz der linearen Währungsherausgabe tendiert, ähnlich wie bei Bitcoin, die Wachstumsrate des Angebots über die Zeit dennoch gegen null._
-Die zwei Hauptentscheidungen im obigen Modell sind (1) die Existenz und Größe eines Endowment-Pools sowie (2) die Existenz einer dauerhaft wachsenden linearen Versorgung im Gegensatz zu einer begrenzten Versorgung wie bei Bitcoin. Die Rechtfertigung des Endowment-Pools ist wie folgt. Wenn es keinen Endowment-Pool gäbe und die lineare Ausgabe auf 0,217-mal verringert würde, um die gleiche Inflationsrate zu erreichen, würde die Gesamtmenge an Ether um 16,5 % niedriger sein, was bedeutet, dass jede Einheit 19,8 % mehr wert wäre. Daher würden im Gleichgewicht 19,8 % mehr Ether im Verkauf gekauft werden, sodass jede Einheit wieder genau so viel Wert hätte wie zuvor. Die Organisation hätte dann auch 1,198-mal so viel BTC, das als in zwei Segmente unterteilt betrachtet werden kann: das ursprüngliche BTC und die zusätzlichen 0,198-mal. Folglich ist diese Situation _genau äquivalent_ zum Endowment, aber mit einem entscheidenden Unterschied: Die Organisation hält nur BTC und hat daher keinen Anreiz, den Wert der Ether-Einheit zu fördern.
+Die zwei Hauptentscheidungen im obigen Modell sind (1) die Existenz und Größe eines Endowment-Pools sowie (2) die Existenz einer dauerhaft wachsenden linearen Versorgung im Gegensatz zu einer begrenzten Versorgung wie bei Bitcoin. Die Rechtfertigung des Endowment-Pools ist wie folgt. Wenn es keinen Endowment-Pool gäbe und die lineare Ausgabe auf 0,217-mal verringert würde, um die gleiche Inflationsrate zu erreichen, würde die Gesamtmenge an Ether um 16,5 % niedriger sein, was bedeutet, dass jede Einheit 19,8 % mehr wert wäre. Daher würden im Gleichgewicht 19,8 % mehr Ether im Verkauf gekauft werden, sodass jede Einheit wieder genau so viel Wert hätte wie zuvor. Die Organisation hätte dann auch 1,198-mal so viel BTC, das als in zwei Segmente unterteilt betrachtet werden kann: das ursprüngliche BTC und die zusätzlichen 0,198-mal. Daher ist diese Situation _genau äquivalent_ zur Stiftung, aber mit einem wichtigen Unterschied: Die Organisation hält ausschließlich BTC und hat daher keinen Anreiz, den Wert der Ether-Einheit zu unterstützen.
-Das Modell des permanenten linearen Angebotswachstums verringert das Risiko dessen, was einige als übermäßige Vermögenskonzentration in Bitcoin ansehen, und bietet jetzt und in Zukunft eine faire Chance, Währungseinheiten zu erwerben, während gleichzeitig ein starker Anreiz besteht, Ether zu erwerben und zu halten, da die „Angebotswachstumsrate“ prozentual betrachtet im Laufe der Zeit dennoch gegen null tendiert. Außerdem vermuten wir, dass Münzen aufgrund von Nachlässigkeit, Tod usw. im Laufe der Zeit immer verloren gehen und dass der Münzverlust als Prozentsatz des Gesamtangebots pro Jahr modelliert werden kann. Infolgedessen wird sich das gesamte im Umlauf befindliche Währungsangebot tatsächlich irgendwann auf einen Wert stabilisieren, der der jährlichen Ausgabe geteilt durch die Verlustquote entspricht (z. B. bei einer Verlustquote von 1 % wird, sobald für das Angebot das 26-Fache erreicht ist, jährlich das 0,26-Fache gemint und das 0,26-Fache geht verloren, was ein Gleichgewicht erzeugt).
+Das Modell des permanenten linearen Angebotswachstums verringert das Risiko dessen, was einige als übermäßige Vermögenskonzentration in Bitcoin ansehen, und bietet jetzt und in Zukunft eine faire Chance, Währungseinheiten zu erwerben, während gleichzeitig ein starker Anreiz besteht, Ether zu erwerben und zu halten, da die „Angebotswachstumsrate“ prozentual betrachtet im Laufe der Zeit dennoch gegen null tendiert. Wir stellen auch die Theorie auf, dass, da Coins im Laufe der Zeit durch Unachtsamkeit, Tod usw. immer verloren gehen und der Coin-Verlust als Prozentsatz des Gesamtangebots pro Jahr modelliert werden kann, sich das gesamte im Umlauf befindliche Währungsangebot tatsächlich irgendwann auf einem Wert stabilisieren wird, der der jährlichen Emission geteilt durch die Verlustrate entspricht (z. B. bei einer Verlustrate von 1 % werden, sobald das Angebot das 26-fache erreicht, jedes Jahr 0,26X geschürft und 0,26X gehen verloren, wodurch ein Gleichgewicht entsteht).
-Beachten Sie, dass Ethereum in Zukunft wahrscheinlich zu einem Proof-of-Stake-Modell für Sicherheit wechseln wird, wodurch die Ausgaberate auf irgendwo zwischen null und 0,05-mal pro Jahr gesenkt wird. Für den Fall, dass die Ethereum-Organisation ihre Finanzierung verliert oder aus irgendeinem anderen Grund verschwindet, lassen wir einen „Gesellschaftsvertrag“ offen: Jeder hat das Recht, eine zukünftige Kandidat-Version von Ethereum zu erstellen, wobei die einzige Bedingung ist, dass die Menge an Ether höchstens gleich `60102216 * (1.198 + 0.26 * n)` sein darf, wobei `n` die Anzahl der Jahre nach dem Genesis-Block ist. Die Ersteller können frei entscheiden, einen Crowdsale durchzuführen oder auf andere Weise einen Teil oder die gesamte Differenz zwischen der von PoS angetriebenen Angebotsausweitung und der maximal erlaubten Angebotsausweitung zuzuweisen, um die Entwicklung zu bezahlen. Kandidaten-Upgrades, die nicht dem sozialen Vertrag entsprechen, dürfen berechtigterweise in konforme Versionen abgespalten werden.
+Beachten Sie, dass Ethereum in Zukunft wahrscheinlich zu einem Proof-of-Stake-Modell für Sicherheit wechseln wird, wodurch die Ausgaberate auf irgendwo zwischen null und 0,05-mal pro Jahr gesenkt wird. Für den Fall, dass die Ethereum-Organisation ihre Finanzierung verliert oder aus einem anderen Grund verschwindet, lassen wir einen „Gesellschaftsvertrag“ offen: Jeder hat das Recht, eine zukünftige Kandidatenversion von Ethereum zu erstellen, mit der einzigen Bedingung, dass die Menge an Ether höchstens gleich `60102216 * (1.198 + 0.26 * n)` sein darf, wobei `n` die Anzahl der Jahre nach dem Genesis-Block ist. Die Ersteller können frei entscheiden, einen Crowdsale durchzuführen oder auf andere Weise einen Teil oder die gesamte Differenz zwischen der von PoS angetriebenen Angebotsausweitung und der maximal erlaubten Angebotsausweitung zuzuweisen, um die Entwicklung zu bezahlen. Kandidaten-Upgrades, die nicht dem sozialen Vertrag entsprechen, dürfen berechtigterweise in konforme Versionen abgespalten werden.
### Mining-Zentralisierung {#mining-centralization}
Der Bitcoin-Mining-Algorithmus funktioniert, indem Miner SHA256 auf leicht modifizierte Versionen des Block-Headers Millionen von Malen berechnen, bis schließlich ein Knoten eine Version findet, deren Hash kleiner ist als das Ziel (derzeit etwa 2192). Allerdings ist dieser Mining-Algorithmus anfällig für zwei Formen der Zentralisierung. Erstens wird das Mining-Ökosystem von ASICs (Application-Specific Integrated Circuits) dominiert, also von Computerchips, die speziell für das Bitcoin-Mining entwickelt wurden und daher tausendmal effizienter in dieser spezifischen Aufgabe sind. Das bedeutet, dass Bitcoin-Mining nicht mehr eine stark dezentralisierte und egalitäre Aktivität ist, die Millionen von Dollar an Kapital erfordert, um effektiv teilzunehmen. Zweitens führen die meisten Bitcoin-Miner die Blockvalidierung nicht tatsächlich lokal durch; stattdessen verlassen sie sich auf einen zentralisierten Mining-Pool, um die Block-Header bereitzustellen. Dieses Problem ist wohl schlimmer: Zum Zeitpunkt der Erstellung dieses Textes kontrollieren die drei größten Mining-Pools indirekt etwa 50 % der Rechenleistung im Bitcoin-Netzwerk, obwohl dies dadurch gemildert wird, dass Miner zu anderen Mining-Pools wechseln können, wenn ein Pool oder ein Bündnis sich einen 51-%-Angriff vornimmt.
-Die aktuelle Absicht von Ethereum besteht darin, einen Mining-Algorithmus zu verwenden, bei dem Miner zufällige Daten aus dem Status abrufen, einige zufällig ausgewählte Transaktionen aus den letzten N Blöcken der Blockchain berechnen und den Hash des Ergebnisses zurückgeben müssen. Dies hat zwei wichtige Vorteile. Erstens können Ethereum-Verträge jede Art von Berechnung enthalten, sodass ein Ethereum-ASIC im Grunde genommen ein ASIC für allgemeine Berechnungen wäre – also ein besserer CPU. Zweitens erfordert das Mining Zugang zur gesamten Blockchain, was die Miner zwingt, die gesamte Blockchain zu speichern und mindestens in der Lage zu sein, jede Transaktion zu verifizieren. Dies macht zentralisierte Mining-Pools überflüssig; obwohl Mining-Pools immer noch die legitime Rolle haben können, die Zufälligkeit der Gewinnverteilung auszugleichen, kann diese Funktion ebenso gut von Peer-to-Peer-Pools ohne zentrale Kontrolle erfüllt werden.
+Die aktuelle Absicht von Ethereum besteht darin, einen Mining-Algorithmus zu verwenden, bei dem Miner zufällige Daten aus dem Status abrufen, einige zufällig ausgewählte Transaktionen aus den letzten N Blöcken der Blockchain berechnen und den Hash des Ergebnisses zurückgeben müssen. Dies hat zwei wichtige Vorteile. Erstens können Ethereum-Verträge jede Art von Berechnung enthalten, sodass ein Ethereum-ASIC im Wesentlichen ein ASIC für allgemeine Berechnungen wäre – d. h. eine bessere CPU. Zweitens erfordert das Mining Zugang zur gesamten Blockchain, was die Miner zwingt, die gesamte Blockchain zu speichern und mindestens in der Lage zu sein, jede Transaktion zu verifizieren. Dies macht zentralisierte Mining-Pools überflüssig; obwohl Mining-Pools immer noch die legitime Rolle haben können, die Zufälligkeit der Gewinnverteilung auszugleichen, kann diese Funktion ebenso gut von Peer-to-Peer-Pools ohne zentrale Kontrolle erfüllt werden.
Dieses Modell ist noch nicht getestet, und es könnte Schwierigkeiten dabei geben, bestimmte clevere Optimierungen zu vermeiden, wenn die Vertragsausführung als Mining-Algorithmus verwendet wird. Eine besonders interessante Eigenschaft dieses Algorithmus ist jedoch, dass er jedem ermöglicht, „den Brunnen zu vergiften“, indem er eine große Anzahl von Verträgen in die Blockchain einführt, die speziell dazu entwickelt wurden, bestimmte ASICs auszubremsen. Es bestehen wirtschaftliche Anreize für ASIC-Hersteller, einen solchen Trick zu verwenden, um gegeneinander vorzugehen. Daher ist die Lösung, die wir entwickeln, letztendlich eine adaptive wirtschaftlich-menschliche Lösung und nicht nur eine rein technische.
@@ -468,9 +472,9 @@ Dieses Modell ist noch nicht getestet, und es könnte Schwierigkeiten dabei gebe
Eine häufige Sorge im Zusammenhang mit Ethereum ist die Frage der Skalierbarkeit. Wie Bitcoin leidet auch Ethereum unter dem Nachteil, dass jede Transaktion von jedem Knoten im Netzwerk verarbeitet werden muss. Derzeit beläuft sich die Größe der Bitcoin-Blockchain auf etwa 15 GB und wächst um etwa 1 MB pro Stunde. Wenn das Bitcoin-Netzwerk die 2000 Transaktionen pro Sekunde von Visa verarbeiten würde, würde es alle drei Sekunden um 1 MB wachsen (1 GB pro Stunde, 8 TB pro Jahr). Ethereum wird voraussichtlich ein ähnliches Wachstumsverhalten aufweisen, verschärft durch die Tatsache, dass es viele Anwendungen auf der Ethereum-Blockchain geben wird, anstatt nur eine Währung wie bei Bitcoin. Positiv zu vermerken ist jedoch, dass Ethereum-Vollknoten nur den Status und nicht die gesamte Historie der Blockchain speichern müssen.
-Das Problem bei einer so großen Blockchain ist das Zentralisierungsrisiko. Wenn die Größe der Blockchain auf beispielsweise 100 TB ansteigt, wäre das wahrscheinlichste Szenario, dass nur eine sehr kleine Anzahl großer Unternehmen Vollknoten betreibt, während alle regulären Benutzer leichte SPV-Knoten verwenden. In einer solchen Situation entsteht die potenzielle Sorge, dass die Vollknoten sich zusammenschließen und alle einvernehmlich auf betrügerische Weise (z. B. die Blockbelohnung ändern oder sich selbst BTC geben) handeln könnten. Leichte Knoten hätten keine Möglichkeit, dies sofort zu erkennen. Natürlich würde wahrscheinlich mindestens ein ehrlicher Vollknoten existieren, und nach ein paar Stunden würden Informationen über den Betrug über Kanäle wie Reddit verbreitet werden. Aber zu diesem Zeitpunkt wäre es zu spät: Es wäre an den gewöhnlichen Benutzern, eine Initiative zu organisieren, um die betreffenden Blöcke auf die schwarze Liste zu setzen, was ein massives und vermutlich unpraktikables Koordinationsproblem darstellt – ähnlich dem einer erfolgreichen 51-%-Attacke. Im Fall von Bitcoin ist dies derzeit ein Problem, aber es gibt eine von [Peter Todd](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) vorgeschlagene Modifikation der Blockchain, die dieses Problem lindern wird.
+Das Problem bei einer so großen Blockchain ist das Zentralisierungsrisiko. Wenn die Größe der Blockchain auf beispielsweise 100 TB ansteigt, wäre das wahrscheinlichste Szenario, dass nur eine sehr kleine Anzahl großer Unternehmen Vollknoten betreibt, während alle regulären Benutzer leichte SPV-Knoten verwenden. In einer solchen Situation besteht die potenzielle Sorge, dass die Full-Nodes sich zusammenschließen und alle zustimmen könnten, auf profitable Weise zu betrügen (z. B. die Block-Belohnung ändern, sich selbst BTC geben). Leichte Knoten hätten keine Möglichkeit, dies sofort zu erkennen. Natürlich würde wahrscheinlich mindestens ein ehrlicher Vollknoten existieren, und nach ein paar Stunden würden Informationen über den Betrug über Kanäle wie Reddit verbreitet werden. Aber zu diesem Zeitpunkt wäre es zu spät: Es wäre an den gewöhnlichen Benutzern, eine Initiative zu organisieren, um die betreffenden Blöcke auf die schwarze Liste zu setzen, was ein massives und vermutlich unpraktikables Koordinationsproblem darstellt – ähnlich dem einer erfolgreichen 51-%-Attacke. Im Fall von Bitcoin ist dies derzeit ein Problem, aber es gibt eine von [Peter Todd vorgeschlagene](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) Blockchain-Modifikation, die dieses Problem lindern wird.
-Kurzfristig wird Ethereum zwei zusätzliche Strategien nutzen, um mit diesem Problem umzugehen. Erstens werden alle Miner aufgrund der Blockchain-basierten Mining-Algorithmen gezwungen, Vollknoten zu sein, wodurch eine Untergrenze für die Anzahl der Vollknoten geschaffen wird. Zweitens, und das ist noch wichtiger, werden wir nach der Verarbeitung jeder Transaktion einen Wurzelknoten eines Zwischenspeicherbaums in die Blockchain einfügen. Selbst wenn die Blockvalidierung zentralisiert ist, kann das Zentralisierungsproblem durch ein Verifizierungsprotokoll umgangen werden, solange mindestens ein ehrlicher verifizierender Knoten existiert. Wenn ein Miner einen ungültigen Block veröffentlicht, muss dieser Block schlecht formatiert sein, oder der Status `S[n]` ist falsch. Da `S[0]` bekanntlich korrekt ist, muss es einen ersten Status `S[i]` geben, der inkorrekt ist, wobei `S[i-1]` korrekt ist. Der verifizierende Knoten würde den Index `i` zusammen mit einem „Beweis der Ungültigkeit“ bereitstellen, der aus der Teilmenge der Patricia Tree-Knoten besteht, die benötigt wird, um `APPLY(S[i-1],TX[i]) -> S[i]` zu verarbeiten. Knoten würden in der Lage sein, diese Knoten zu verwenden, um diesen Teil der Berechnung auszuführen und festzustellen, dass das erzeugte `S[i]` nicht mit dem bereitgestellten `S[i]` übereinstimmt.
+Kurzfristig wird Ethereum zwei zusätzliche Strategien nutzen, um mit diesem Problem umzugehen. Erstens werden alle Miner aufgrund der Blockchain-basierten Mining-Algorithmen gezwungen, Vollknoten zu sein, wodurch eine Untergrenze für die Anzahl der Vollknoten geschaffen wird. Zweitens, und das ist noch wichtiger, werden wir nach der Verarbeitung jeder Transaktion einen Wurzelknoten eines Zwischenspeicherbaums in die Blockchain einfügen. Selbst wenn die Blockvalidierung zentralisiert ist, kann das Zentralisierungsproblem durch ein Verifizierungsprotokoll umgangen werden, solange mindestens ein ehrlicher verifizierender Knoten existiert. Wenn ein Miner einen ungültigen Block veröffentlicht, muss dieser Block entweder schlecht formatiert sein oder der Zustand `S[n]` ist falsch. Da `S[0]` bekanntermaßen korrekt ist, muss es einen ersten Zustand `S[i]` geben, der falsch ist, wobei `S[i-1]` korrekt ist. Der verifizierende Node würde den Index `i` zusammen mit einem „Ungültigkeitsbeweis“ bereitstellen, der aus der Teilmenge der Patricia-Tree-Nodes besteht, die zur Verarbeitung von `APPLY(S[i-1],TX[i]) -> S[i]` benötigt werden. Die Nodes könnten diese Nodes verwenden, um diesen Teil der Berechnung auszuführen, und sehen, dass das generierte `S[i]` nicht mit dem bereitgestellten `S[i]` übereinstimmt.
Ein weiterer, ausgeklügelterer Angriff würde darin bestehen, dass böswillige Miner unvollständige Blöcke veröffentlichen, sodass die vollständigen Informationen überhaupt nicht vorhanden sind, um zu bestimmen, ob die Blöcke gültig sind oder nicht. Die Lösung dafür ist ein Challenge-Response-Protokoll: Verifizierungsknoten geben „Herausforderungen“ in Form von Zieltransaktionsindizes aus, und beim Empfang behandelt ein leichter Knoten den Block als vertrauensunwürdig, bis ein anderer Knoten, sei es der Miner oder ein anderer Verifizierer, eine Teilmenge der Patricia-Knoten als Beweis der Gültigkeit bereitstellt.
@@ -480,38 +484,38 @@ Das Ethereum-Protokoll wurde ursprünglich als eine erweiterte Version einer Kry
Das Konzept einer beliebigen Statusübergangsfunktion, wie es im Ethereum-Protokoll umgesetzt ist, bietet eine Plattform mit einzigartigem Potenzial; Ethereum ist kein geschlossenes, einzweckiges Protokoll, das für einen spezifischen Anwendungsbereich in der Datenspeicherung, im Glücksspiel oder in Finanzen gedacht ist, sondern von Natur aus offen gestaltet. Wir glauben, dass es äußerst gut geeignet ist, als grundlegende Ebene für eine sehr große Anzahl sowohl finanzieller als auch nicht-finanzieller Protokolle in den kommenden Jahren zu dienen.
-## Anmerkungen und weiterführende Literatur {#notes-and-further-reading}
+## Hinweise und weiterführende Lektüre {#notes-and-further-reading}
-### Anmerkungen {#notes}
+### Hinweise {#notes}
1. Ein aufmerksamer Leser wird vielleicht feststellen, dass eine Bitcoin-Adresse in Wirklichkeit der Hash des öffentlichen Schlüssels der elliptischen Kurve und nicht der öffentliche Schlüssel selbst ist. In der Terminologie der Kryptografie ist es jedoch durchaus legitim, den Pubkey-Hash selbst als öffentlichen Schlüssel zu bezeichnen. Dies liegt daran, dass die Kryptografie von Bitcoin als ein spezifischer Algorithmus für digitale Signaturen betrachtet werden kann, bei dem der öffentliche Schlüssel aus dem Hash des ECC-Pubkeys besteht. Die Signatur besteht aus dem ECC-Pubkey verkettet mit der ECC-Signatur. Der Verifizierungsalgorithmus umfasst die Überprüfung des ECC-Pubkeys in der Signatur gegenüber dem ECC-Pubkey-Hash, der als öffentlicher Schlüssel bereitgestellt wird, und dann die Überprüfung der ECC-Signatur gegenüber dem ECC-Pubkey.
2. Technisch gesehen handelt es sich um den Median der 11 vorherigen Blöcke.
3. Intern sind sowohl 2 als auch „CHARLIE“ Zahlen[fn3](#notes), wobei „CHARLIE“ in Big-Endian zur Basis 256 dargestellt ist. Die Zahlen können mindestens 0 und höchstens 2256-1 sein.
-### Weiterführende Informationen {#further-reading}
+### Weiterführende Lektüre {#further-reading}
-1. [Intrinsischer Wert](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/)
+1. [Intrinsischer Wert](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it)
2. [Smart Property](https://en.bitcoin.it/wiki/Smart_Property)
3. [Smart Contracts](https://en.bitcoin.it/wiki/Contracts)
-4. [B-Money](http://www.weidai.com/bmoney.txt)
-5. [Wiederverwendbare Proofs-of-Work](https://nakamotoinstitute.org/finney/rpow/)
-6. [Sichere Eigentumstitel mit Eigentümerautorität](https://nakamotoinstitute.org/secure-property-titles/)
-7. [Bitcoin-Whitepaper](http://bitcoin.org/bitcoin.pdf)
+4. [B-money](http://www.weidai.com/bmoney.txt)
+5. [Wiederverwendbare Proofs of Work](https://nakamotoinstitute.org/finney/rpow/)
+6. [Sichere Eigentumstitel mit Eigentümerautorität](https://nakamotoinstitute.org/library/secure-property-titles/)
+7. [Bitcoin Whitepaper](http://bitcoin.org/bitcoin.pdf)
8. [Namecoin](https://namecoin.org/)
-9. [Zookos Dreieck](https://wikipedia.org/wiki/Zooko's_triangle)
-10. [Colored Coins-Whitepaper](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)
-11. [Mastercoin-Whitepaper](https://github.com/mastercoin-MSC/spec)
-12. [Dezentralisierte autonome Corporations, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)
-13. [Vereinfachte Zahlungsverifizierung](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)
-14. [Merkle Trees](https://wikipedia.org/wiki/Merkle_tree)
-15. [Patricia Trees](https://wikipedia.org/wiki/Patricia_tree)
+9. [Zooko’s Triangle](https://wikipedia.org/wiki/Zooko's_triangle)
+10. [Colored Coins Whitepaper](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)
+11. [Mastercoin Whitepaper](https://github.com/mastercoin-MSC/spec)
+12. [Dezentralisierte autonome Gesellschaften, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)
+13. [Vereinfachte Zahlungsüberprüfung](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification)
+14. [Merkle-Bäume](https://wikipedia.org/wiki/Merkle_tree)
+15. [Patricia-Bäume](https://wikipedia.org/wiki/Patricia_tree)
16. [GHOST](https://eprint.iacr.org/2013/881.pdf)
-17. [StorJ und autonome Agenten, Jeff Garzik](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html)
+17. [StorJ und Autonome Agenten, Jeff Garzik](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html)
18. [Mike Hearn über Smart Property beim Turing Festival](https://www.youtube.com/watch?v=MVyv4t0OKe4)
-19. [Ethereum RLP](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP)
-20. [Ethereum Merkle Patricia Trees](https://web.archive.org/web/20250427212320/https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree)
-21. [Peter Todd über Merkle Sum Trees](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/)
+19. [Ethereum RLP](/developers/docs/data-structures-and-encoding/rlp/)
+20. [Ethereum Merkle-Patricia-Bäume](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)
+21. [Peter Todd über Merkle-Summen-Bäume](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/)
-_Informationen zur Geschichte des Whitepapers finden Sie in [diesem Wiki](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md)._
+_Zur Geschichte des Whitepapers, siehe [dieses Wiki](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md)._
-_Ethereum hat sich, wie viele durch die Community unterstützte Open-Source-Softwareprojekte, seit seinen Ursprüngen weiterentwickelt. Um mehr über die neuesten Entwicklungen von Ethereum zu erfahren und wie Änderungen am Protokoll vorgenommen werden, empfehlen wir [diese Anleitung](/learn/)._
+_Ethereum hat sich, wie viele durch die Community unterstützte Open-Source-Softwareprojekte, seit seinen Ursprüngen weiterentwickelt. _Um mehr über die neuesten Entwicklungen von Ethereum und darüber zu erfahren, wie Änderungen am Protokoll vorgenommen werden, empfehlen wir [diesen Leitfaden](/learn/)._
diff --git a/public/content/translations/de/zero-knowledge-proofs/index.md b/public/content/translations/de/zero-knowledge-proofs/index.md
index 54e585cd272..adc2b966557 100644
--- a/public/content/translations/de/zero-knowledge-proofs/index.md
+++ b/public/content/translations/de/zero-knowledge-proofs/index.md
@@ -1,6 +1,6 @@
---
title: Null-Wissen-Beweise
-description: Eine nicht-technische Einführung in Null-Wissen-Beweise für Anfänger.
+description: "Eine nicht-technische Einführung in Null-Wissen-Beweise für Anfänger."
lang: de
---