Machen Sie sich mit unseren Vorschlägen für DeFi-Anwendungen vertraut und testen sie, wenn Sie neu bei Ethereum sind.
DeFi-Apps entdecken
@@ -77,37 +78,37 @@ Das klingt merkwürdig... „Warum würde ich mein Geld programmieren wollen?“
Für fast alle Finanzdienstleistungen gibt es dezentrale Alternativen. Ethereum aber schafft zudem Möglichkeiten, komplett neue Finanzprodukte zu gestalten. Im Folgenden eine Liste mit Beispielen, die ständig länger wird:
-- [Geld rund um die Welt senden](#send-money)
-- [Geld rund um die Welt „streamen“](#stream-money)
-- [Zugang zu stabilen Währungen](#stablecoins)
-- [Kredite mit hinterlegten Sicherheiten aufnehmen](#lending)
-- [Kredite ohne hinterlegte Sicherheiten aufnehmen](#flash-loans)
-- [Krypto-Sparkonten eröffnen](#saving)
-- [Mit Token handeln](#swaps)
-- [Das eigene Portfolio vergrößern](#investing)
+- [Geld um die ganze Welt senden](#send-money)
+- [Geld um den Globus streamen](#stream-money)
+- [Auf stabile Währungen zugreifen](#stablecoins)
+- [Kredite mit Sicherheiten aufnehmen](#lending)
+- [Kredite ohne Sicherheiten aufnehmen](#flash-loans)
+- [Mit Krypto-Sparen beginnen](#saving)
+- [Token handeln](#swaps)
+- [Ihr Portfolio vergrößern](#investing)
- [Ihre Ideen finanzieren](#crowdfunding)
-- [Versicherungen abschließen](#insurance)
-- [Das eigene Portfolio verwalten](#aggregators)
+- [Versicherung abschließen](#insurance)
+- [Ihr Portfolio verwalten](#aggregators)
### Geld schnell um die ganze Welt senden {#send-money}
-Als Blockchain ist Ethereum für sichere und globale Transaktionen konzipiert. Wie auch Bitcoin macht Ethereum das weltweite Senden von Geld so einfach wie das Versenden einer E-Mail. Geben Sie einfach den [ENS-Namen](/glossary/#ens) des Empfängers (z. B. bob.eth) oder die Kontoadresse der Wallet ein und schon geht die Zahlung (typischerweise) innerhalb von Minuten direkt beim Empfänger ein. Zum Senden oder Empfangen von Zahlungen ist eine [Wallet](/wallets/) erforderlich.
+Als Blockchain ist Ethereum für sichere und globale Transaktionen konzipiert. Wie auch Bitcoin macht Ethereum das weltweite Senden von Geld so einfach wie das Versenden einer E-Mail. Geben Sie einfach den [ENS-Namen](/glossary/#ens) des Empfängers (z. B. bob.eth) oder seine Kontoadresse aus Ihrer Wallet ein, und Ihre Zahlung geht (normalerweise) innerhalb weniger Minuten direkt an ihn. Um Zahlungen zu senden oder zu empfangen, benötigen Sie eine [Wallet](/wallets/).
- Siehe Zahlungs-dApps
+ Zahlungs-Dapps ansehen
#### Geld um die Welt „streamen“... {#stream-money}
Über Ethereum lässt sich auch Geld streamen. So können Sie das Gehalt für Personen sekündlich überweisen und geben ihnen damit Zugang zu ihrem verdienten Geld, wann immer sie es gerade benötigen. Ein weiterer Anwendungsfall wäre beispielsweise das Mieten von Objekten, wie z. B. Schließfächer oder E-Scooter, auf sekündlicher Basis.
-Und wenn Sie keine [ETH](/glossary/#ether) senden oder streamen wollen, weil sich der Wert so stark verändern kann, gibt es alternative Währungen auf Ethereum: [Stablecoins](/glossary/#stablecoin).
+Und wenn Sie [ETH](/glossary/#ether) nicht senden oder streamen möchten, weil sich sein Wert so stark ändern kann, gibt es alternative Währungen auf Ethereum: [Stablecoins](/glossary/#stablecoin).
-### Zugriff auf Stablecoins {#stablecoins}
+### Zugriff auf stabile Währungen {#stablecoins}
Die Volatilität von Kryptowährungen ist ein Problem für viele Finanzprodukte und allgemein für den Einsatz als Zahlungsmittel. Dieses Problem hat die DeFi-Community mit Stablecoins gelöst. Ihr Wert ist an ein anderes Asset gebunden, typischerweise beliebte Währungen wie der Dollar.
@@ -127,28 +128,28 @@ Es gibt zwei etablierte Möglichkeiten, um Geld von dezentralen Anbietern zu lei
- Pool-basiert, das heißt Kreditgeber stellen Geldmittel (Liquidität) für einen Pool bereit, aus dem Kreditnehmer die Mittel leihen können.
- Siehe Lending-dApps
+ Kredit-Dapps ansehen
Auf dezentrale Kreditanbieter zurückzugreifen, bietet viele Vorteile...
-#### Geld leihen mit Privatsphäre {#borrowing-privacy}
+#### Kreditaufnahme mit Datenschutz {#borrowing-privacy}
Bei der Vergabe und Inanspruchnahme von Krediten dreht sich heutzutage alles um die beteiligten Einzelpersonen. Banken müssen vor einer Kreditvergabe wissen, ob man wahrscheinlich in der Lage ist, den Kredit zurückzuzahlen.
-Eine dezentrale Kreditvergabe funktioniert vollständig ohne Identifikation der involvierten Parteien. Stattdessen muss der Kreditnehmer eine Sicherheit stellen, die der Kreditgeber automatisch erhält, wenn der Kredit nicht zurückgezahlt wird. Manche Kreditanbieter nehmen sogar [NFTs](/glossary/#nft) als Sicherheiten an. NFTs kann man sich wie eine Besitzurkunde für einen bestimmten Vermögenswert vorstellen. [Mehr zu NFTs](/nft/)
+Eine dezentrale Kreditvergabe funktioniert vollständig ohne Identifikation der involvierten Parteien. Stattdessen muss der Kreditnehmer eine Sicherheit stellen, die der Kreditgeber automatisch erhält, wenn der Kredit nicht zurückgezahlt wird. Manche Kreditgeber akzeptieren sogar [NFTs](/glossary/#nft) als Sicherheit. NFTs kann man sich wie eine Besitzurkunde für einen bestimmten Vermögenswert vorstellen. [Mehr zu NFTs](/nft/)
Das ermöglicht es, ohne Kreditchecks und Preisgabe von privaten Informationen Geld zu borgen.
-#### Zugang zu globalen Geldmitteln {#access-global-funds}
+#### Zugriff auf globale Geldmittel {#access-global-funds}
-Wenn Sie auf einen dezentralen Kreditgeber setzen, erhalten Sie Zugang zu allen hinterlegten Assets überall auf der Welt und nicht nur zu denen, die im Depot Ihrer Bank oder Institution verwaltet werden. Damit werden Kredite leichter zugänglich und die Zinssätze verbessern sich.
+Wenn Sie auf einen dezentralen Kreditgeber setzen, erhalten Sie Zugang zu allen hinterlegten Assets überall auf der Welt und nicht nur zu denen, die im Depot Ihrer Bank oder Institution verwaltet werden. Dadurch werden Kredite leichter zugänglich und die Zinssätze verbessern sich.
#### Steuervorteile {#tax-efficiencies}
Wenn Sie Geld leihen, erhalten Sie Zugang zu Assets und müssen nicht Ihr ETH verkaufen (ein steuerpflichtiger Vorgang). Stattdessen können Sie ETH als Sicherheit für einen Stablecoin-Kredit verwenden. Damit erhalten Sie den benötigten Cashflow, ohne Ihre ETH verkaufen zu müssen. Stablecoins sind Token, die als Zahlungsmittel wesentlich besser geeignet sind, da sie anders als ETH keinen Wertschwankungen unterliegen. [Mehr zu Stablecoins](#stablecoins)
-#### Flash Loans {#flash-loans}
+#### Flash-Loans {#flash-loans}
Flash Loans, also Blitzkredite, sind eine experimentelle Form der dezentralen Kreditaufnahme. Dabei können Sie Geld leihen, ohne Sicherheiten oder persönliche Informationen hinterlegen zu müssen.
@@ -172,27 +173,27 @@ Gäbe es an Handelsplatz B kurzfristig zu wenig Angebot von Assets, wodurch Sie
Um das obige Beispiel in der etablierten Finanzwelt umzusetzen, benötigten Sie sehr viel Geld. Diese Strategien des Geldverdienens sind jenen mit großem bestehenden Vermögen vorbehalten. Flash Loans sind ein Beispiel einer Zukunft, in der der Besitz von Geld nicht die Voraussetzung dafür ist, Geld zu verdienen.
- Mehr zu Flash Loans
+ Mehr zu Flash-Loans
-### Jetzt mit dem Kryptosparen beginnen {#saving}
+### Mit Krypto sparen {#saving}
-#### Darlehen {#lending}
+#### Kreditvergabe {#lending}
Sie können Ihrer Krypto in Echtzeit beim Wachsen zusehen, indem Sie sie verleihen und Zinsen verdienen. Aktuell sind diese Zinssätze um einiges höher als bei lokalen Banken (wenn Sie das Glück haben, Zugang dazu zu haben). Hier ein Beispiel:
-- Sie verleihen 100 Dai, ein [Stablecoin](/stablecoins/), an ein Produkt wie z. B. Aave.
+- Sie verleihen Ihre 100 Dai, einen [Stablecoin](/stablecoins/), an ein Produkt wie Aave.
- Sie erhalten einen Token, der für Ihr verliehenes Dai steht, also 100 Aave Dai (aDai).
-- Ihr aDai steigt auf Grundlage der Zinssätze an und Sie können Ihr Guthaben in Ihrer Wallet wachsen sehen. Abhängig von der [APR](/glossary/#apr) kann Ihr Wallet-Guthaben beispielsweise nach ein paar Tagen und sogar nur ein paar Stunden 100,1234 anzeigen!
+- Ihr aDai steigt auf Grundlage der Zinssätze an und Sie können Ihr Guthaben in Ihrer Wallet wachsen sehen. Abhängig vom [APR](/glossary/#apr) zeigt Ihr Wallet-Guthaben nach ein paar Tagen oder sogar Stunden einen Wert wie 100,1234 an!
- Sie können dann jederzeit normales Dai in Höhe Ihres aDai-Guthabens abheben.
- Zu Lending-dApps
+ Lending-Dapps ansehen
-#### No-Loss-Lotterien {#no-loss-lotteries}
+#### Verlustfreie Lotterien {#no-loss-lotteries}
No-Loss-Lotterien wie zum Beispiel PoolTogether sind ein lustiger und innovativer Weg, Geld zu sparen.
@@ -205,7 +206,7 @@ No-Loss-Lotterien wie zum Beispiel PoolTogether sind ein lustiger und innovative
Der Gewinnpool wird aus allen Zinsen gewonnen, die durch das Verleihen der Ticketanzahlungen wie im Beispiel zum Verleihen oben generiert wurden.
- PoolTogether testen
+ PoolTogether ausprobieren
@@ -217,36 +218,36 @@ Auf Ethereum gibt es Tausende Token. Der Handel mit verschiedenen Token erfolgt
Wenn Sie zum Beispiel die No-Loss-Lotterie PoolTogether (wie oben beschrieben) nutzen möchten, benötigen Sie einen Token wie Dai oder USDC. An diesen DEXs können Sie Ihr ETH gegen solche Token eintauschen. Sobald Sie fertig sind, ist es wieder möglich, diese Token zurückzutauschen.
- Zu Token-Handesplätzen
+ Token-Börsen ansehen
-### Erweitertes Trading {#trading}
+### Fortgeschrittener Handel {#trading}
Für Trader, die sich mehr Kontrolle wünschen, gibt es fortgeschrittenere Optionen. Limit Orders, Perpetuals, Margin Trading und vieles mehr ist möglich. Mit dezentralem Trading erhalten Sie Zugang zu globaler Liquidität. Der Markt schließt nie und Sie haben immer volle Kontrolle über Ihre Assets.
Wenn Sie sich für einen zentralen Handelsplatz entscheiden, müssen Sie Ihre Assets vor dem Handeln zuerst hinterlegen und darauf vertrauen, dass der Anbieter diese sicher verwahrt. Während Ihre Assets bei dem Anbieter hinterlegt sind, sind sie dem Risiko von Hackerangriffen ausgesetzt.
- Zu Trading-dApps
+ Trading-Dapps ansehen
-### Das eigene Portfolio vergrößern {#investing}
+### Ihr Portfolio vergrößern {#investing}
Auf Ethereum gibt es auch Produkte für das Portfoliomanagement, deren Ziel es ist, Ihr Portfolio mit einer Strategie Ihrer Wahl zu vergrößern. Das erfolgt automatisch, ist offen für jeden und Sie benötigen keinen realen Manager, der einen Anteil an Ihren Gewinnen beansprucht.
-Ein gutes Beispiel ist der [DeFi Pulse Index Fund (DPI)](https://defipulse.com/blog/defi-pulse-index/). Es handelt sich um einen Fonds, der automatisch ein Rebalancing durchführt, um sicherzustellen, dass Ihr Portfolio immer die besten DeFi-Token nach Marktkapitalisierung enthält. Sie werden niemals irgendwelche Details verwalten müssen und können jederzeit Abhebungen aus dem Fonds tätigen.
+Ein gutes Beispiel ist der [DeFi Pulse Index-Fonds (DPI)](https://defipulse.com/blog/defi-pulse-index/). Es handelt sich um einen Fonds, der automatisch ein Rebalancing durchführt, um sicherzustellen, dass Ihr Portfolio immer die besten DeFi-Token nach Marktkapitalisierung enthält. Sie werden niemals irgendwelche Details verwalten müssen und können jederzeit Abhebungen aus dem Fonds tätigen.
- Zu Investment-dApps
+ Investment-Dapps ansehen
-### Eigene Ideen finanzieren {#crowdfunding}
+### Ihre Ideen finanzieren {#crowdfunding}
Ethereum ist die ideale Platform für Crowdfunding:
@@ -255,12 +256,12 @@ Ethereum ist die ideale Platform für Crowdfunding:
- Spendensammler können automatische Erstattungen einrichten, wenn es beispielsweise eine bestimmte Frist und einen Mindestbetrag gibt, die bzw. der nicht eingehalten oder erreicht wird.
- Zu Crowdfunding-dApps
+ Crowdfunding-Dapps ansehen
#### Quadratische Finanzierung {#quadratic-funding}
-Ethereum ist Open-Source-Software und ein Großteil der bisherigen Arbeit wurde von der Community finanziert. Das hat zur Entwicklung eines interessanten neuen Fundraising-Modells geführt: die quadratische Finanzierung. Damit lässt sich die Art und Weise, wie wir in Zukunft alle Arten von öffentlichen Gütern finanzieren, verbessern.
+Ethereum ist Open-Source-Software und ein Großteil der bisherigen Arbeit wurde von der Community finanziert. Das hat zur Entwicklung eines interessanten neuen Fundraising-Modells geführt: die quadratische Finanzierung. Dieses Modell hat das Potenzial die Art und Weise zu verbessern, wie wir in Zukunft alle Arten von öffentlichen Gütern finanzieren.
Über die quadratische Finanzierung wird sichergestellt, dass die Projekte mit dem größten individuellen Bedarf auch die meisten Mittel erhalten. Mit anderen Worten: Projekte, die das Leben der meisten Menschen verbessern können. So funktioniert es:
@@ -272,7 +273,7 @@ Ethereum ist Open-Source-Software und ein Großteil der bisherigen Arbeit wurde
Projekt A mit 100 Spenden zu je 1 Euro könnte also mehr Mittel erhalten als Projekt B mit einer einzelnen Spende von 10.000 Euro (abhängig von der Größe des übereinstimmenden Pools).
- Zu quadratischer Finanzierung
+ Mehr über quadratische Finanzierung
@@ -281,10 +282,10 @@ Projekt A mit 100 Spenden zu je 1 Euro könnte also mehr Mittel erhalten als Pro
Eine dezentralisierte Versicherung zielt darauf ab, Versicherungen billiger und transparenter zu machen sowie Versicherungsfälle schneller auszuzahlen. Mit einem höherem Grad an Automatisierung wird der Versicherungsschutz erschwinglicher und die Auszahlungen erfolgen wesentlich schneller. Die Daten, die zur Entscheidung über Ihren Versicherungsfall genutzt werden, sind vollkommen transparent.
-Bei Ethereum-Produkten gibt es wie auch bei jeder anderen Software Fehler und Exploits. Derzeit liegt beispielsweise bei vielen Versicherungsprodukten in diesem Bereich der Schwerpunkt auf dem Schutz der Benutzer vor finanziellen Verlusten. Es gibt jedoch Projekte, die damit beginnen, einen Versicherungsschutz für alles Unwägbarkeiten aufzubauen, die das Leben uns bescheren kann. Ein gutes Beispiel ist die Ernteversicherung von Etherisc. Es wird versucht, [Kleinbauern in Kenia gegen Dürren und Überschwemmungen abzusichern](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc). Dezentrale Versicherungen können Landwirten, denen herkömmliche Versicherungen oft zu teuer sind, einen erschwinglichen Versicherungsschutz bieten.
+Ethereum Produkte können wie jede andere Software an Fehlern und Exploits leiden. Derzeit liegt beispielsweise bei vielen Versicherungsprodukten in diesem Bereich der Schwerpunkt auf dem Schutz der Benutzer vor finanziellen Verlusten. Es gibt jedoch Projekte, die damit beginnen, einen Versicherungsschutz für alles Unwägbarkeiten aufzubauen, die das Leben uns bescheren kann. Ein gutes Beispiel hierfür ist Etheriscs „Crop Cover“, das [Kleinbauern in Kenia vor Dürren und Überschwemmungen schützen](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc) soll. Dezentrale Versicherungen können Landwirten, denen herkömmliche Versicherungen oft zu teuer sind, einen erschwinglichen Versicherungsschutz bieten.
- Zu Versicherungs-dApps
+ Versicherungs-Dapps ansehen
@@ -294,7 +295,7 @@ Bei Ethereum-Produkten gibt es wie auch bei jeder anderen Software Fehler und Ex
Bei all diesen Entwicklungen brauchen Sie einen Weg, um alle Ihre Investitionen, Darlehen und Trades im Auge zu behalten. Es gibt eine Reihe von Produkten, mit denen Sie alle Ihre DeFi-Aktivitäten zentral koordinieren können. Das ist der Vorteil der offenen Architektur von DeFi. Teams können Schnittstellen entwickeln, über die Sie nicht nur Ihr Guthaben für alle Produkte sehen, sondern zusätzlich auch deren Funktionen nutzen können. Das finden Sie vielleicht nützlich, wenn Sie sich umfassender mit DeFi vertraut machen.
- Zu Portfolio-dApps
+ Portfolio-Dapps ansehen
@@ -323,21 +324,21 @@ Ethereum ist aus mehreren Gründen die perfekte Grundlage für DeFi:
DeFi ist praktisch ein Ebenenmodell:
1. Die Blockchain: Ethereum enthält den Transaktionsverlauf und den Status der Konten.
-2. Die Assets: [ETH](/what-is-ether/) und die anderen Token (Währungen).
-3. Die Protokolle – [Smart Contracts](/glossary/#smart-contract), die die Funktionalität bereitstellen, z.B. einen Dienst, der die dezentrale Ausleihe von Vermögenswerten ermöglicht.
-4. [Die Anwendungen](/apps/): Produkte die wir benutzen, um Protokolle zu verwalten und auf diese zuzugreifen.
+2. Die Vermögenswerte – [ETH](/what-is-ether/) und die anderen Token (Währungen).
+3. Die Protokolle – [Smart Contracts](/glossary/#smart-contract), die die Funktionalität bereitstellen, zum Beispiel ein Dienst, der die dezentrale Kreditvergabe von Vermögenswerten ermöglicht.
+4. [Die Anwendungen](/apps/) – die Produkte, die wir verwenden, um die Protokolle zu verwalten und auf sie zuzugreifen.
-Merke: Vieles von DeFi nutzt den [ERC-20-Standard](/glossary/#erc-20). Anwendungen in DeFi nutzen einen Wrapper namens „Wrapped Ether“ (WETH) für ETH. [Erfahren Sie mehr über Wrapped Ether](/wrapped-eth).
+Hinweis: Ein Großteil von DeFi verwendet den [ERC-20-Standard](/glossary/#erc-20). Anwendungen in DeFi verwenden einen Wrapper für ETH namens Wrapped Ether (WETH). [Erfahren Sie mehr über Wrapped Ether](/wrapped-eth).
-## DeFi aufbauen {#build-defi}
+## DeFi entwickeln {#build-defi}
DeFi ist eine Open-Source-Bewegung. DeFi-Protokolle und -Anwendungen sind für jeden offen, um sie zu überprüfen, aufzuspalten und zu verbessern. Durch diese kombinierten Ebenen oder Layer (sie teilen alle die gleiche Basis-Blockchain und Assets) können Protokolle vermischt und aufeinander abgestimmt werden, um neue einzigartige Möglichkeiten zu schaffen.
- Mehr zum Erstellen von dApps
+ Mehr zum Erstellen von Dapps
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
### DeFi-Daten {#defi-data}
@@ -346,18 +347,19 @@ DeFi ist eine Open-Source-Bewegung. DeFi-Protokolle und -Anwendungen sind für j
### DeFi-Artikel {#defi-articles}
-- [Ein Leitfaden für Einsteiger in DeFi](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6. Januar 2020_
+- [Ein Leitfaden für Anfänger zu DeFi](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6. Januar 2020_
+- [EEA DeFi Risk Assessment Guidelines](https://entethalliance.org/specs/defi-risks/) – Ein von der Branche unterstützter Überblick, wie man die wichtigsten Risiken in DeFi-Protokollen identifiziert und bewertet.
### Videos {#videos}
-- [Finanzmathematik – mehr erfahren über dezentralisierte Finanzmärkte](https://finematics.com/) – _Videos zu DeFi_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _DeFi-Grundlagen: Alles, was Sie wissen müssen, um in diesem gelegentlich verblüffenden Bereich durchzustarten._
-- [Whiteboard-Krypto](https://youtu.be/17QRFlml4pA) _Was ist DeFi?_
+- [Finematics – Bildung im Bereich dezentrales Finanzwesen](https://finematics.com/) – _Videos zu DeFi_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) – _DeFi-Grundlagen: Alles, was Sie für den Einstieg in diesen manchmal verwirrenden Bereich wissen müssen._
+- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) – _Was ist DeFi?_
-### Communities {#communities}
+### Communitys {#communities}
-- [DeFi Llama Discord Server](https://discord.defillama.com/)
-- [DeFi Pulse Discord Server](https://discord.gg/Gx4TCTk)
+- [DeFi Llama Discord-Server](https://discord.defillama.com/)
+- [DeFi Pulse Discord-Server](https://discord.gg/Gx4TCTk)
diff --git a/public/content/translations/de/desci/index.md b/public/content/translations/de/desci/index.md
index 7c5049acdcd..f53aab41e7d 100644
--- a/public/content/translations/de/desci/index.md
+++ b/public/content/translations/de/desci/index.md
@@ -1,6 +1,6 @@
---
title: Dezentrale Wissenschaft (DeSci)
-description: Eine Übersicht über dezentralisierte Wissenschaft auf Ethereum
+description: "Eine Übersicht über dezentralisierte Wissenschaft auf Ethereum"
lang: de
template: use-cases
emoji: ":microscope:"
@@ -8,17 +8,17 @@ sidebarDepth: 2
image: /images/future_transparent.png
alt: ""
summaryPoint1: Eine globale, offene Alternative zum derzeitigen wissenschaftlichen System.
-summaryPoint2: Technologie, die es Wissenschaftlern ermöglicht, Finanzierung zu erhalten, Experimente durchzuführen, Daten zu teilen, Erkenntnisse zu verbreiten und vieles mehr.
+summaryPoint2: "Technologie, die es Wissenschaftlern ermöglicht, Finanzierung zu erhalten, Experimente durchzuführen, Daten zu teilen, Erkenntnisse zu verbreiten und vieles mehr."
summaryPoint3: Baut auf der Open-Science-Bewegung auf.
---
## Was ist dezentralisierte Wissenschaft (DeSci)? {#what-is-desci}
-Die dezentralisierte Wissenschaft (DeSci) ist eine Bewegung mit dem Ziel, eine öffentliche Infrastruktur für die faire und gerechte Finanzierug, Schaffung, Überprüfung, Zueignung, Speicherung und Verbreitung von wissenschaftlichem Wissen mithilfe des [Web3](/glossary/#web3)-Stack zu errichten.
+Dezentralisierte Wissenschaft (DeSci) ist eine Bewegung, die darauf abzielt, eine öffentliche Infrastruktur für die Finanzierung, Erstellung, Überprüfung, Anerkennung, Speicherung und Verbreitung von wissenschaftlichem Wissen fair und gerecht unter Verwendung des [Web3](/glossary/#web3)-Stacks aufzubauen.
DeSci zielt darauf ab, ein Ökosystem zu schaffen, in dem Wissenschaftler ermutigt werden, ihre Forschungsergebnisse offen zu teilen und Anerkennung für ihre Arbeit zu erhalten. Gleichzeitig wird Fachleuten, die ihre eigenen Leistungen einbringen möchten, der Zugang zur Forschung ermöglicht. DeSci arbeitet mit der Idee, dass wissenschaftliche Erkenntnisse für alle zugänglich und der Prozess der wissenschaftlichen Forschung transparent sein sollte. DeSci schafft ein dezentraleres und verteiltes wissenschaftliches Forschungsmodell, das widerstandsfähiger gegen Zensur und Kontrolle durch zentrale Behörden ist. DeSci hofft, eine Umgebung zu schaffen, in der neue und unkonventionelle Ideen gedeihen können, indem der Zugang zu Finanzierung, wissenschaftlichen Werkzeugen und Kommunikationskanälen dezentralisiert wird.
-Die dezentralisierte Wissenschaft ermöglicht eine vielfältigere Finanzierung aus verschiedenen Quellen (von [DAOs](/glossary/#dao) über [quadratische Spenden](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) bis hin zu Crowdfunding und mehr), einen leichteren Zugang zu Daten und Methoden sowie Anreize für die Reproduzierbarkeit.
+Dezentrale Wissenschaft ermöglicht vielfältigere Finanzierungsquellen (von [DAOs](/glossary/#dao) über [quadratische Spenden](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) bis hin zu Crowdfunding und mehr), einen leichteren Zugang zu Daten und Methoden und bietet Anreize für Reproduzierbarkeit.
### Juan Benet - Die DeSci-Bewegung
@@ -28,16 +28,16 @@ Die dezentralisierte Wissenschaft ermöglicht eine vielfältigere Finanzierung a
Eine unvollständige Liste von zentralen Problemen in der Wissenschaft und wie dezentralisierte Wissenschaft dazu beitragen kann, diese Probleme anzugehen
-| **Dezentralisierte Wissenschaft** | **Traditionelle Wissenschaft** |
-| -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Die Verteilung von Geldmitteln wird **von der Öffentlichkeit bestimmt**, indem Mechanismen wie quadratische Spenden oder DAOs genutzt werden. | Kleine, geschlossene, **zentralisierte Gruppen** kontrollieren die Verteilung von Geldmitteln. |
-| Sie arbeiten mit Kollegen aus **der ganzen Welt** zusammen. | Finanzierungsorganisationen und Heimatinstitutionen **limitieren** Ihre Kollaborationen. |
-| Finanzierungsentscheidungen finden online und **transparent** statt. Es werden neue Finanzierungsmechanismen erforscht. | Finanzierungsentscheidungen werden mit langer Bearbeitungszeit und **limitierter Transparenz** durchgeführt. Es gibt nur wenige Finanzierungsmechanismen. |
-| Die gemeinsame Nutzung von Labor-Dienstleistungen wird leichter und transparenter durch [Web3](/glossary/#web3)-Technologie. | Die gemeinsame Nutzung von Labor-Dienstleistungen ist meist **langsam und undurchsichtig**. |
-| **Neue Veröffentlichungsmodelle**, die Web3-Primitiven für Vertrauen, Transparenz und universellen Zugriff nutzen, können entwickelt werden. | Sie veröffentlichen über etablierte Wege, die oft als **ineffizient, voreingenommen and ausbeuterisch** eingestuft werden. |
-| Sie können **Tokens und Reputation durch Peer-Review-Arbeit verdienen**. | Ihre **Peer-Review-Arbeit ist unbezahlt**, was für gewinnorientierte Herausgeber von Vorteil ist. |
-| **Sie besitzen das geistige Eigentum (IP)**, das Sie generieren und verteilen es den transparenten Bedingungen entsprechend. | **Ihre Heimatinstitution besitzt das IP**, das Sie generieren. Der Zugang zum IP ist nicht sichtbar. |
-| **Das Teilen von allen durchgeführten Forschungsarbeiten**, einschließlich der Daten von erfolglosen Versuchen, indem alle Schritte On-Chain sind. | **Publikations-Bias** heißt, dass Forscher eher Experimente mit erfolgreichen Ergebnissen veröffentlichen. |
+| **Dezentralisierte Wissenschaft** | **Traditionelle Wissenschaft** |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Die Verteilung der Mittel wird **von der Öffentlichkeit** mittels Mechanismen wie quadratischen Spenden oder DAOs **bestimmt**. | Kleine, geschlossene, **zentralisierte Gruppen** kontrollieren die Verteilung der Mittel. |
+| Sie arbeiten mit Kollegen aus **der ganzen Welt** in dynamischen Teams zusammen. | Finanzierungsorganisationen und Heimateinrichtungen **beschränken** Ihre Zusammenarbeit. |
+| Finanzierungsentscheidungen werden online und **transparent** getroffen. Es werden neue Finanzierungsmechanismen erforscht. | Finanzierungsentscheidungen werden mit einer langen Bearbeitungszeit und **begrenzter Transparenz** getroffen. Es gibt nur wenige Finanzierungsmechanismen. |
+| Der Austausch von Labordienstleistungen wird durch den Einsatz der [Web3](/glossary/#web3)-Technologie einfacher und transparenter. | Der Austausch von Laborressourcen ist oft **langsam und undurchsichtig**. |
+| Es können **neue Veröffentlichungsmodelle** entwickelt werden, die Web3-Primitive für Vertrauen, Transparenz und universellen Zugang nutzen. | Sie veröffentlichen über etablierte Wege, die häufig als **ineffizient, voreingenommen und ausbeuterisch** eingestuft werden. |
+| Sie können **Token und Reputation für das Peer-Reviewing** von Arbeiten **verdienen**. | Ihre **Peer-Review-Arbeit ist unbezahlt** und kommt gewinnorientierten Verlagen zugute. |
+| **Sie besitzen das geistige Eigentum (IP)**, das Sie generieren, und verteilen es gemäß transparenter Bedingungen. | **Ihre Heimateinrichtung besitzt das geistige Eigentum**, das Sie generieren. Der Zugang zum IP ist nicht sichtbar. |
+| **Die gesamte Forschung teilen**, einschließlich der Daten aus erfolglosen Bemühungen, indem alle Schritte on-chain festgehalten werden. | **Publikations-Bias** bedeutet, dass Forscher eher Experimente mit erfolgreichen Ergebnissen teilen. |
## Ethereum und DeSci {#ethereum-and-desci}
@@ -47,11 +47,11 @@ Ein dezentralisiertes Wissenschaftssystem erfordert robuste Sicherheit, minimale
DeSci baut das spezifische Instrumentarium, um die traditionelle akademische Welt in die digitale Welt zu integrieren. Im Folgenden finden Sie eine Auswahl von Anwendungsfällen, die Web3 der wissenschaftlichen Gemeinschaft bieten kann.
-### Veröffentlichung (Publishing) {#publishing}
+### Veröffentlichung {#publishing}
-Das wissenschaftliche Publizieren ist bekanntermaßen problematisch, weil es von Verlagen verwaltet wird, die auf die kostenlose Arbeit von Wissenschaftlern, Gutachtern und Redakteuren angewiesen sind, um die Veröffentlichungen zu erstellen, dann aber exorbitante Veröffentlichungsgebühren verlangen. Die Öffentlichkeit, die in der Regel indirekt durch Steuern für das Werk und die Veröffentlichungskosten gezahlt hat, kann oft nicht auf dasselbe Werk zugreifen, ohne den Verleger erneut zu bezahlen. Die Gesamtkosten für die Publikation einzelner wissenschaftlicher Arbeiten belaufen sich oft auf fünfstellige Beträge (USD), wodurch das gesamte Konzept wissenschaftlicher Erkenntnisse als [öffentliches Gut](/glossary/#public-goods) untergraben wird, während gleichzeitig enorme Gewinne für eine kleine Gruppe von Verlegern erzielt werden.
+Das wissenschaftliche Publizieren ist bekanntermaßen problematisch, weil es von Verlagen verwaltet wird, die auf die kostenlose Arbeit von Wissenschaftlern, Gutachtern und Redakteuren angewiesen sind, um die Veröffentlichungen zu erstellen, dann aber exorbitante Veröffentlichungsgebühren verlangen. Die Öffentlichkeit, die in der Regel indirekt durch Steuern für das Werk und die Veröffentlichungskosten gezahlt hat, kann oft nicht auf dasselbe Werk zugreifen, ohne den Verleger erneut zu bezahlen. Die Gesamtkosten für die Veröffentlichung einzelner wissenschaftlicher Arbeiten belaufen sich oft auf fünfstellige Beträge ($ USD), was das gesamte Konzept wissenschaftlicher Erkenntnisse als [öffentliches Gut](/glossary/#public-goods) untergräbt, während gleichzeitig enorme Gewinne für eine kleine Gruppe von Verlegern erzielt werden.
-Kostenlose und frei zugängliche Plattformen gibt es in Form von Preprint-Servern, wie [ArXiv](https://arxiv.org/). Diesen Plattformen mangelt es jedoch an Qualitätskontrollen, [Anti-Sybil-Mechanismen](/glossary/#anti-sybil). Sie verfolgen in der Regel keine Qualitätskriterien auf Artikelniveau, was bedeutet, dass sie in der Regel nur dazu dienen, die Arbeiten zu veröffentlichen, ehe sie bei einem traditionellen Verlag eingereicht werden. SciHub macht auch publizierte Arbeiten frei zugänglich. Dies geschieht jedoch nicht auf legalem Weg, sondern erst, nachdem die Verlage ihre Bezahlung erhalten haben und die Arbeit in ein strenges Urheberrecht verpackt wurde. Dies hinterlässt eine kritische Lücke für zugängliche wissenschaftliche Publikationen und empirischen Daten mit einem eingebetteten Legitimationsmechanismus und Motivationsmodell. Die Werkzeuge für den Aufbau eines solchen Systems gibt es in Web3.
+Kostenlose und frei zugängliche Plattformen gibt es in Form von Preprint-Servern, [wie ArXiv](https://arxiv.org/). Diesen Plattformen mangelt es jedoch an Qualitätskontrollen und [Anti-Sybil-Mechanismen](/glossary/#anti-sybil). Sie verfolgen in der Regel keine Metriken auf Artikelebene, was bedeutet, dass sie normalerweise nur dazu dienen, Arbeiten vor der Einreichung bei einem traditionellen Verlag bekannt zu machen. SciHub macht auch publizierte Arbeiten frei zugänglich. Dies geschieht jedoch nicht auf legalem Weg, sondern erst, nachdem die Verlage ihre Bezahlung erhalten haben und die Arbeit in ein strenges Urheberrecht verpackt wurde. Dies hinterlässt eine kritische Lücke für zugängliche wissenschaftliche Publikationen und empirischen Daten mit einem eingebetteten Legitimationsmechanismus und Motivationsmodell. Die Werkzeuge für den Aufbau eines solchen Systems gibt es in Web3.
### Reproduzierbarkeit und Replizierbarkeit {#reproducibility-and-replicability}
@@ -60,29 +60,30 @@ Reproduzierbarkeit und Replizierbarkeit sind die Grundvoraussetzungen für quali
- Reproduzierbare Ergebnisse können mehrfach nacheinander vom selben Team mit derselben Methodik erzielt werden.
- Reproduzierbare Ergebnisse können von einer anderen Gruppe mit demselben Versuchsaufbau erzielt werden.
-Neue Web3-native Tools können sicherstellen, dass Reproduzierbarkeit und Replizierbarkeit die Basis für Forschungsergebnisse sind. Damit können wir Qualitätsforschung in das technologische Umfeld der akademischen Welt einbinden. Web3 bietet die Möglichkeit, [Attestierungen](/glossary/#attestation) für jeden Analysekomponenten zu schaffen: die rohen Daten, den Rechner und das Anwendungsergebnis. Der Vorteil von Konsens-Systemen besteht darin, dass durch die Schaffung eines vertrauenswürdigen Netzwerks zur Pflege dieser Komponenten jeder Netzwerkteilnehmer für die Nachvollziehbarkeit der Berechnung und die Validierung jedes Ergebnisses verantwortlich sein kann.
+Neue Web3-native Tools können sicherstellen, dass Reproduzierbarkeit und Replizierbarkeit die Basis für Forschungsergebnisse sind. Damit können wir Qualitätsforschung in das technologische Umfeld der akademischen Welt einbinden. Web3 bietet die Möglichkeit, [Attestierungen](/glossary/#attestation) für jede Analysekomponente zu erstellen: die Rohdaten, die Berechnungs-Engine und das Anwendungsergebnis. Der Vorteil von Konsens-Systemen besteht darin, dass durch die Schaffung eines vertrauenswürdigen Netzwerks zur Pflege dieser Komponenten jeder Netzwerkteilnehmer für die Nachvollziehbarkeit der Berechnung und die Validierung jedes Ergebnisses verantwortlich sein kann.
### Finanzierung {#funding}
-Das derzeitige Standardmodell der Wissenschaftsförderung besteht darin, dass Einzelpersonen oder Forschergruppen schriftliche Anträge bei einer Förderorganisation einreichen. Die Bewertung der Anträge und die anschließende Durchführung von Interviews mit den Antragstellern erfolgt durch ein kleines Gremium, das sich aus vertrauenswürdigen Personen zusammensetzt, bevor die Mittel an einen kleinen Kreis von Antragstellern vergeben werden. Abgesehen von der Entstehung von Engpässen, die manchmal zu **jahrelangen Wartezeiten** zwischen der Beantragung eines Zuschusses und dem Erhalten eines Zuschusses führen, ist dieses Modell dafür bekannt, höchst **anfällig für die Neigungen, Eigeninteressen und Politik** des Überprüfungsgremiums zu sein.
+Das derzeitige Standardmodell der Wissenschaftsförderung besteht darin, dass Einzelpersonen oder Forschergruppen schriftliche Anträge bei einer Förderorganisation einreichen. Die Bewertung der Anträge und die anschließende Durchführung von Interviews mit den Antragstellern erfolgt durch ein kleines Gremium, das sich aus vertrauenswürdigen Personen zusammensetzt, bevor die Mittel an einen kleinen Kreis von Antragstellern vergeben werden. Abgesehen davon, dass Engpässe entstehen, die zu mitunter **jahrelangen Wartezeiten** zwischen der Beantragung und dem Erhalt eines Zuschusses führen, ist dieses Modell bekanntermaßen sehr **anfällig für die Voreingenommenheit, die Eigeninteressen und die Politik** des Prüfungsausschusses.
Studien haben gezeigt, dass die Bewilligungsgremien bei der Auswahl von qualitativ hochwertigen Anträgen schlecht abschneiden: Gleiche Anträge, die verschiedenen Gremien vorgelegt werden, führen zu sehr unterschiedlichen Ergebnissen. Aufgrund der Mittelknappheit konzentrierten sie sich auf einen kleineren Pool älterer Forscher mit intellektuell konservativeren Projekten. Dies hat zu einer extrem wettbewerbsorientierten Förderlandschaft geführt, die falsche Anreize setzt und die Innovation im Keim erstickt.
-Web3 hat das Potenzial, dieses kaputte Finanzierungsmodell zu durchbrechen, indem es mit verschiedenen Anreizmodellen experimentiert, die von DAOs und Web3 im Allgemeinen entwickelt werden. [Retroaktive Fördermittel für öffentliche Güter](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [quadratische Förderung](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), [DAO Governance](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) und [tokenisierte Anreizstrukturen](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) sind einige der Web3-Tools, die die Wissenschaftsförderung revolutionieren könnten.
+Web3 hat das Potenzial, dieses kaputte Finanzierungsmodell zu durchbrechen, indem es mit verschiedenen Anreizmodellen experimentiert, die von DAOs und Web3 im Allgemeinen entwickelt werden. [Retroaktive Finanzierung öffentlicher Güter](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [quadratische Finanzierung](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), [DAO-Governance](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) und [tokenisierte Anreizstrukturen](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) sind einige der Web3-Tools, die die Wissenschaftsfinanzierung revolutionieren könnten.
### IP-Eigentum und -Entwicklung {#ip-ownership}
-Geistiges Eigentum (IP) ist ein Hauptproblem der traditionellen Wissenschaft: Es bleibt in Universitäten stecken oder wird in Biotechs nicht genutzt und ist schwierig zu bewerten. Allerdings ist das Eigentum an digitalen Gütern (wie z. B. wissenschaftlichen Daten oder Aufsätzen) ein Bereich, in dem Web3 mit seinen [Non-Fungible Token (NFTs)](/glossary/#nft) eine sehr gute Lösung bietet.
+Geistiges Eigentum (IP) ist ein Hauptproblem der traditionellen Wissenschaft: Es bleibt in Universitäten stecken oder wird in Biotechs nicht genutzt und ist schwierig zu bewerten. Der Besitz von digitalen Vermögenswerten (wie z. B. wissenschaftlichen Daten oder Artikeln) ist jedoch etwas, das Web3 mit [nicht fungiblen Token (NFTs)](/glossary/#nft) außergewöhnlich gut umsetzt.
Auf die gleiche Weise, wie NFTs Einnahmen für zukünftige Transaktionen an den ursprünglichen Ersteller zurückgeben können, können Sie transparente Wertzuweisungsketten einrichten, um Forscher, Verwaltungsorgane (wie DAOs) oder sogar die Personen, deren Daten gesammelt werden, zu belohnen.
-[IP-NFTs](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) können auch als Schlüssel zu einem dezentralisierten Datenspeicher für die durchgeführten Forschungsexperimente fungieren und zur NFT- und [DeFi](/glossary/#defi)-Finanzierung beitragen (von der Fraktionalisierung bis zu Lending Pools und Value Appraisal). Es ermöglicht auch nativen On-Chain-Einheiten als DAOs wie etwa [VitaDAO](https://www.vitadao.com/), direkt in der Kette zu recherchieren. Die Einführung von nicht übertragbaren ["soulbound"-Token](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) könnte ebenfalls eine wichtige Rolle in DeSci spielen, da sie es Einzelpersonen ermöglichen, ihre Erfahrung und ihre Referenzen in Verbindung mit ihrer Ethereum-Adresse nachzuweisen.
+[IP-NFTs](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) können auch als Schlüssel zu einem dezentralen Daten-Repository der durchgeführten Forschungsexperimente dienen und an die Finanzialisierung von NFT und [DeFi](/glossary/#defi) (von der Fraktionierung über Lending-Pools bis hin zur Wertermittlung) anknüpfen. Es ermöglicht auch nativen On-Chain-Entitäten wie DAOs wie [VitaDAO](https://www.vitadao.com/), Forschung direkt on-chain durchzuführen.
+Die Einführung von nicht übertragbaren [„Soulbound“-Token](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) könnte ebenfalls eine wichtige Rolle in DeSci spielen, da sie es Einzelpersonen ermöglichen, ihre Erfahrung und ihre Referenzen in Verbindung mit ihrer Ethereum-Adresse nachzuweisen.
-### Datenspeicherung, Zugriff und Architektur {#data-storage}
+### Datenspeicherung, -zugriff und -architektur {#data-storage}
Wissenschaftliche Daten können durch Web3-Modelle viel leichter zugänglich gemacht werden, und die verteilte Speicherung erlaubt es der Forschung, katastrophale Ereignisse zu überleben.
-Ausgangspunkt muss ein System sein, auf das jede dezentrale Identität mit verifizierbaren Berechtigungsnachweisen zugreift. Dies ermöglicht die sichere Replikation sensibler Daten durch vertrauenswürdige Parteien, Redundanz und Widerstandsfähigkeit gegen Zensur, die Reproduktion von Ergebnissen und sogar die Möglichkeit der Zusammenarbeit mehrerer Parteien und das Hinzufügen neuer Daten zu einem Datensatz. Vertrauliche Datenverarbeitungsmethoden wie [Compute-to-Data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol) bieten alternative Zugriffsmechanismen zur Replikation von Rohdaten und zur Schaffung vertrauenswürdiger Forschungsumgebungen für besonders sensible Daten. Trusted Research Environments (vertrauenswürdige Forschungsumgebungen) wurden [vom NHS](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) als bahnbrechende Lösung für Datenschutz und Zusammenarbeit genannt, da sie ein Ökosystem schaffen, in dem Forscher vor Ort sicher mit Daten arbeiten können, indem sie standardisierte Umgebungen für die gemeinsame Nutzung von Code und Verfahren verwenden.
+Ausgangspunkt muss ein System sein, auf das jede dezentrale Identität mit verifizierbaren Berechtigungsnachweisen zugreift. Dies ermöglicht die sichere Replikation sensibler Daten durch vertrauenswürdige Parteien, Redundanz und Widerstandsfähigkeit gegen Zensur, die Reproduktion von Ergebnissen und sogar die Möglichkeit der Zusammenarbeit mehrerer Parteien und das Hinzufügen neuer Daten zu einem Datensatz. Vertrauliche Berechnungsmethoden wie [Compute-to-Data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol) bieten alternative Zugriffsmechanismen zur Replikation von Rohdaten und schaffen so vertrauenswürdige Forschungsumgebungen für die sensibelsten Daten. Trusted Research Environments wurden [vom NHS zitiert](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) als eine zukunftsorientierte Lösung für Datenschutz und Zusammenarbeit, da sie ein Ökosystem schaffen, in dem Forscher mithilfe standardisierter Umgebungen für den Austausch von Code und Verfahren sicher vor Ort mit Daten arbeiten können.
Flexible Web3-Datenlösungen unterstützen die oben genannten Szenarien. Sie bilden die Grundlage für eine wirklich offene Wissenschaft, in der Forscher ohne Zugangsbeschränkungen oder Gebühren öffentliche Güter schaffen können. Öffentliche Web3-Datenlösungen wie IPFS, Arweave und Filecoin werden für die Dezentralisierung optimiert. dClimate bietet beispielsweise universellen Zugang zu Klima- und Wetterdaten, auch von Wetterstationen und Vorhersagemodellen.
@@ -90,46 +91,49 @@ Flexible Web3-Datenlösungen unterstützen die oben genannten Szenarien. Sie bil
Erkunden Sie Projekte und werden Sie Teil der DeSci-Gemeinschaft.
-- [DeSci.Global: globale Ereignisse und Termine](https://desci.global)
-- [Blockchain für Science Telegram](https://t.me/BlockchainForScience)
-- [Molecule: fördern und eigene Forschungsprojekte finanzieren lassen](https://www.molecule.xyz/)
-- [VitaDAO: langfristige Forschung finanziert durch gesponserte Forschungsverträge](https://www.vitadao.com/)
-- [ResearchHub: wissenschaftliche Ergebnisse veröffentlichen und in Diskurs mit Partnern gehen](https://www.researchhub.com/)
-- [dClimate API: Klimadaten abfragen, die von einer dezentralen Gemeinschaft erfasst werden](https://www.dclimate.net/)
-- [DeSci Foundation: DeSci Publishing Tool Builder](https://descifoundation.org/)
-- [DeSci.World: One-Stop-Shop für Benutzer, mit dezentralisierter Wissenschaft](https://desci.world)
-- [OceanDAO: DAO regelte die Finanzierung der datenbezogenen Wissenschaft](https://oceanprotocol.com/)
-- [OpScientia: offene dezentrale wissenschaftliche Workflows](https://opsci.io/research/)
-- [Bio.xyz: Erhalten Sie Mittel für Ihr Biotech-DAO oder desci-Projekt](https://www.bio.xyz/)
-- [Flamming-Protokoll: Open-Source-Datenwirtschaft, die die kollaborative biomedizinische Entdeckung fördert](http://flemingprotocol.io/)
+- [DeSci.Global: Kalender für globale Events und Meetups](https://desci.global)
+- [Blockchain for Science Telegram](https://t.me/BlockchainForScience)
+- [Molecule: Fördern Sie Ihre Forschungsprojekte und lassen Sie sie finanzieren](https://www.molecule.xyz/)
+- [VitaDAO: Finanzierung durch gesponserte Forschungsverträge für die Langlebigkeitsforschung erhalten](https://www.vitadao.com/)
+- [ResearchHub: Veröffentlichen Sie ein wissenschaftliches Ergebnis und treten Sie mit Fachkollegen in den Dialog](https://www.researchhub.com/)
+- [dClimate API: Klimadaten abfragen, die von einer dezentralen Community erfasst werden](https://www.dclimate.net/)
+- [DeSci Foundation: Entwickler von DeSci-Publishing-Tools](https://descifoundation.org/)
+- [DeSci.World: One-Stop-Shop für Benutzer zum Ansehen und Mitwirken an dezentraler Wissenschaft](https://desci.world)
+- [OceanDAO: DAO-gesteuerte Finanzierung für datenbezogene Wissenschaft](https://oceanprotocol.com/)
+- [Opscientia: offene dezentrale Wissenschafts-Workflows](https://opsci.io/research/)
+- [Bio.xyz: Lassen Sie sich für Ihr Biotech-DAO oder DeSci-Projekt finanzieren](https://www.bio.xyz/)
+- [Fleming-Protokoll: Open-Source-Datenwirtschaft, die die kollaborative biomedizinische Entdeckung fördert](http://flemingprotocol.io/)
- [Active Inference Institute](https://www.activeinference.org/)
-- [IdeaMarkets: Ermöglicht dezentralisierte wissenschaftliche Glaubwürdigkeit](https://ideamarket.io/)
+- [IdeaMarkets: Dezentralisierte wissenschaftliche Glaubwürdigkeit ermöglichen](https://ideamarket.io/)
- [DeSci Labs](https://www.desci.com/)
-- [ValleyDAO: eine offene, globale Gemeinschaft, die Geldmittel und translationale Unterstützung für die Forschung von synthetischer Biologie bietet](https://www.valleydao.bio)
-- [Cerebrum DAO: Sourcing- und Nurturing-Lösungen, um Gehirn-Fitness voranzubringen und Neurodegeneration vorzubeugen](https://www.cerebrumdao.com/)
-- [CryoDAO: Förderung von Mondflug-Forschung im Feld von Kältekonservierung](https://www.cryodao.org)
+- [ValleyDAO: eine offene, globale Gemeinschaft, die Finanzierung und translationale Unterstützung für die Forschung im Bereich der synthetischen Biologie bietet](https://www.valleydao.bio)
+- [Cerebrum DAO: Lösungen zur Förderung der Gehirngesundheit und zur Vorbeugung von Neurodegeneration beschaffen und fördern](https://www.cerebrumdao.com/)
+- [CryoDAO: Finanzierung von Moonshot-Forschung im Bereich der Kryokonservierung](https://www.cryodao.org)
+- [Elata: Mitspracherecht bei der Zukunft der psychiatrischen Medizin](https://www.elata.bio/)
-Wir freuen uns über Vorschläge für neue Projekte, die in die Liste aufgenommen werden sollen – bitte lesen Sie dazu unsere [Listing Policy](/contributing/adding-desci-projects/)!
+Wir freuen uns über Vorschläge für neue Projekte, die wir auflisten können – sehen Sie sich unsere [Auflistungsrichtlinie](/contributing/adding-desci-projects/) an, um loszulegen!
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
- [DeSci Wiki von Jocelynn Pearl und Ultrarare](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#)
-- [Ein Leitfaden für die dezentrale Biotechnologie von Jocelynn Perl für die Zukunft von a16z](https://future.a16z.com/a-guide-to-decentralized-biotech/)
-- [Die Argumente für DeSci](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
-- [Anleitung zu DeSci](https://future.com/what-is-decentralized-science-aka-desci/)
-- [Dezentralisierte Wissenschaftsressourcen](https://www.vincentweisser.com/desci)
-- [Die Biopharma-IP-NFTs von Molecule – Eine technische Beschreibung](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
-- [Aufbau zuverlässiger Wissenschaftssysteme von Jon Starr](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
-- [Paul Kohlhaas – DeSci: die Zukunft der dezentralisierten Wissenschaft (Podcast)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
-- [Eine aktive Inferenz-Ontologie für die dezentralisierte Wissenschaft: von aufgestellten Sensemaking bis zu den epistemischen Commons](https://zenodo.org/record/6320575)
-- [DeSci: die Zukunft der Forschung von Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
-- [Science Funding (Epilog: DeSci und neue Kryptoprimitive) von Nadia](https://nadia.xyz/science-funding)
-- [Dezentralisierung ist eine Dezentralisierung der Arzneimittelentwicklung](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
+- [Ein Leitfaden für dezentrale Biotechnologie von Jocelynn Pearl für a16z future](https://future.a16z.com/a-guide-to-decentralized-biotech/)
+- [Argumente für DeSci](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/)
+- [Leitfaden zu DeSci](https://future.com/what-is-decentralized-science-aka-desci/)
+- [Ressourcen zur dezentralen Wissenschaft](https://www.vincentweisser.com/desci)
+- [Molecule’s Biopharma IP-NFTs – Eine technische Beschreibung](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description)
+- [Aufbau von vertrauenslosen Wissenschaftssystemen von Jon Starr](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673)
+- [Paul Kohlhaas – DeSci: Die Zukunft der dezentralen Wissenschaft (Podcast)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a)
+- [Eine aktive Inferenz-Ontologie für die dezentralisierte Wissenschaft: vom situierten Sensemaking zu den epistemischen Commons](https://zenodo.org/record/6320575)
+- [DeSci: Die Zukunft der Forschung von Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
+- [Wissenschaftsfinanzierung (Epilog: DeSci und neue Krypto-Primitive) von Nadia](https://nadia.xyz/science-funding)
+- [Dezentralisierung revolutioniert die Medikamentenentwicklung](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
+- [Was ist DeSci – Dezentrale Wissenschaft?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
### Videos {#videos}
-- [Was ist die dezentralisierte Wissenschaft?](https://www.youtube.com/watch?v=-DeMklVWNdA)
-- [Gespräch zwischen Vitalik Buterin und dem Wissenschaftler Aubrey de Grey über den Schnittpunkt der Langlebigkeitsforschung und Kryptographie](https://www.youtube.com/watch?v=x9TSJK1widA)
-- [Wissenschaftliche Veröffentlichung ist kaputt. Kann Web3 das reparieren?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
-- [Juan Benet - DeSci, unabhängige Labore und datenintensive Wissenschaft im großen Maßstab](https://www.youtube.com/watch?v=zkXM9H90g_E)
-- [Sebastian Brunemeier – Wie DeSci die biomedizinische Forschung verändern kann & Risikokapital](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
+- [Was ist dezentrale Wissenschaft?](https://www.youtube.com/watch?v=-DeMklVWNdA)
+- [Gespräch zwischen Vitalik Buterin und dem Wissenschaftler Aubrey de Grey über die Schnittstelle von Langlebigkeitsforschung und Krypto](https://www.youtube.com/watch?v=x9TSJK1widA)
+- [Wissenschaftliche Veröffentlichung ist kaputt. Kann Web3 es reparieren?](https://www.youtube.com/watch?v=WkvzYgCvWj8)
+- [Juan Benet – DeSci, Unabhängige Labore & Datenwissenschaft im großen Maßstab](https://www.youtube.com/watch?v=zkXM9H90g_E)
+- [Sebastian Brunemeier – Wie DeSci die biomedizinische Forschung und Risikokapital transformieren kann](https://www.youtube.com/watch?v=qB4Tc3FcVbM)
+- [Paige Donner – Werkzeuge für die offene Wissenschaft mit Web3 und der Blockchain](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s)
diff --git a/public/content/translations/de/developers/docs/accounts/index.md b/public/content/translations/de/developers/docs/accounts/index.md
index 80ce328c50d..642fa1efa76 100644
--- a/public/content/translations/de/developers/docs/accounts/index.md
+++ b/public/content/translations/de/developers/docs/accounts/index.md
@@ -1,21 +1,21 @@
---
title: Ethereum-Konten
-description: Eine Erklärung der Ethereum-Konten – ihre Datenstrukturen und ihre Beziehung zur Schlüsselpaar-Kryptografie.
+description: "Eine Erklärung der Ethereum-Konten – ihre Datenstrukturen und ihre Beziehung zur Schlüsselpaar-Kryptografie."
lang: de
---
-Ein Ethereum-Konto ist eine Entität mit einem Ether(ETH)-Guthaben, welche Transaktionen bei Ethereum durchführen kann. Konten können benutzerkontrolliert oder als intelligenter Vertrag bereitgestellt werden.
+Ein Ethereum-Account besitzt ein Ether (ETH)-Guthaben und kann Nachrichten auf Ethereum senden. Konten können benutzerkontrolliert oder als intelligenter Vertrag bereitgestellt werden.
## Voraussetzungen {#prerequisites}
-Als Vorbereitung auf die Inhalte dieser Seite empfehlen wir Ihnen, zunächst unsere [Einführung in Ethereum](/developers/docs/intro-to-ethereum/) zu lesen.
+Um diese Seite besser zu verstehen, empfehlen wir dir, zuerst unsere [Einführung in Ethereum](/developers/docs/intro-to-ethereum/) zu lesen.
-## Kontotypen {#types-of-account}
+## Kontoarten {#types-of-account}
Ethereum hat zwei Kontotypen:
- Konten im externen Besitz (EOA) – kontrolliert von jeder beliebigen Person mit den privaten Schlüsseln
-- Vertragskonto – ein auf dem Netwerk eröffneter Smart Contract, gesteuert durch Code. Erfahre mehr über [intelligente Verträge](/developers/docs/smart-contracts/).
+- Vertragskonto – ein auf dem Netwerk eröffneter Smart Contract, gesteuert durch Code. Erfahre mehr über [Smart Contracts](/developers/docs/smart-contracts/)
Beide Kontotypen haben die Möglichkeit
@@ -34,20 +34,21 @@ Beide Kontotypen haben die Möglichkeit
**Vertrag**
- Die Erstellung eines Vertrags ist mit Kosten verbunden, da diese Netzwerkspeicher verwenden.
-- Transaktionen können nur als Antwort auf den Erhalt einer Transaktion gesendet werden.
+- Kann nur dann Nachrichten senden, wenn eine Transaktion empfangen wird.
- Transaktionen von einem externen Konto auf ein Vertragskonto können einen Code auslösen, der viele verschiedene Aktionen ausführt, z. B. die Übertragung von Token oder sogar die Erstellung eines neuen Vertrags.
- Vertragskonten haben keine privaten Schlüssel. Stattdessen werden sie durch die Logik vom Smart Contract Code gesteuert.
-## Analyse eines Kontos {#an-account-examined}
+## Ein Konto im Detail {#an-account-examined}
Ethereum-Konten haben vier Bereiche:
-- `Nonce` – ein Zähler, der die Anzahl der von einem externen Konto gesendeten Transaktionen oder die Anzahl der von einem Vertragskonto erstellten Verträge angibt. Für jedes Konto kann nur eine Transaktion mit einem bestimmten Nonce-Wert ausgeführt werden. Das schützt vor Wiederholungsangriffen, bei denen signierte Transaktionen wiederholt gesendet und erneut ausgeführt werden.
-- `Balance` – die Anzahl von wei, die diese Adresse besitzt. Wei ist eine Stückelung der ETH und es gibt 1e+18 wei pro ETH.
-- `codeHash` – Dieser Hash bezieht sich auf den _code_ eines Kontos auf der Ethereum Virtual Machine (EVM). In Vertragskonten sind Codefragmente einprogrammiert, die verschiedene Operationen ausführen können. Dieser EVM-Code wird ausgeführt, wenn das Konto einen Nachrichtenaufruf erhält. Er kann im Gegensatz zu den anderen Kontofeldern nicht geändert werden. Alle diese Codefragmente werden in der Zustandsdatenbank unter den entsprechenden Hashes gespeichert und können später abgerufen werden. Dieser Hash-Wert wird als codeHash bezeichnet. Bei externen Konten ist das Feld codeHash der Hash einer leeren Zeichenfolge.
-- `StorageRoot` – manchmal auch bekannt als Speicher-Hash. Ein 256-Bit-Hash des Wurzelknotens eines Merkle-Patricia-Tries, der den Speicherinhalt des Kontos codiert (eine Zuordnung zwischen 256-Bit-Integer-Werten), codiert in den Trie als eine Zuordnung vom Keccak-256-Bit-Hash der 256-Bit-Integer-Schlüssel zu den RLP-codierten 256-Bit-Integer-Werten. Dieser Trie kodiert den Hash des Speicherinhalts dieses Kontos und ist standardmäßig leer.
+- `nonce` – Ein Zähler, der die Anzahl der von einem externen Konto gesendeten Transaktionen oder die Anzahl der von einem Vertragskonto erstellten Verträge angibt. Für jedes Konto kann nur eine Transaktion mit einem bestimmten Nonce-Wert ausgeführt werden. Das schützt vor Wiederholungsangriffen, bei denen signierte Transaktionen wiederholt gesendet und erneut ausgeführt werden.
+- `balance` – Die Anzahl der Wei, die diese Adresse besitzt. Wei ist eine Stückelung der ETH und es gibt 1e+18 wei pro ETH.
+- `codeHash` – Dieser Hash bezieht sich auf den _Code_ eines Kontos auf der Ethereum Virtual Machine (EVM). In Vertragskonten sind Codefragmente einprogrammiert, die verschiedene Operationen ausführen können. Dieser EVM-Code wird ausgeführt, wenn das Konto einen Nachrichtenaufruf erhält. Er kann im Gegensatz zu den anderen Kontofeldern nicht geändert werden. Alle diese Codefragmente werden in der Zustandsdatenbank unter den entsprechenden Hashes gespeichert und können später abgerufen werden. Dieser Hash-Wert wird als codeHash bezeichnet. Bei externen Konten ist das Feld codeHash der Hash einer leeren Zeichenfolge.
+- `storageRoot` – Manchmal auch als Storage-Hash bekannt. Ein 256-Bit-Hash des Wurzelknotens eines [Merkle-Patricia-Tries](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), der die Speicherinhalte des Kontos kodiert (eine Zuordnung zwischen 256-Bit-Integer-Werten), die im Trie als eine Zuordnung vom Keccak-256-Bit-Hash der 256-Bit-Integer-Schlüssel zu den RLP-kodierten 256-Bit-Integer-Werten kodiert ist. Dieser Trie kodiert den Hash des Speicherinhalts dieses Kontos und ist standardmäßig leer.
- _Diagramm angepasst von [Ethereum EVM illustriert](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramm adaptiert von [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## Externe Konten und Schlüsselpaare {#externally-owned-accounts-and-key-pairs}
@@ -67,32 +68,32 @@ Beispiel:
`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f`
-Der öffentliche Schlüssel wird mithilfe des [Elliptic Curve Digital Signature Algorithm](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) aus dem privaten Schlüssel generiert. Du erhältst eine öffentliche Adresse für dein Konto, indem du die letzten 20 Bytes des Keccak-256-Hashes des öffentlichen Schlüssels nimmst und `0x` an den Anfang setzt.
+Der öffentliche Schlüssel wird aus dem privaten Schlüssel unter Verwendung des [Elliptic Curve Digital Signature Algorithm](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) generiert. Du erhältst eine öffentliche Adresse für dein Konto, indem du die letzten 20 Bytes des Keccak-256-Hashes des öffentlichen Schlüssels nimmst und `0x` an den Anfang setzt.
-Das bedeutet, dass ein Konto in externem Besitz (EOA) eine 42-stellige Adresse hat (ein 20-Byte-Segment, das aus 40 hexadezimalen Zeichen und dem Präfix `0x` besteht).
+Das bedeutet, dass ein externes Konto (Externally Owned Account, EOA) eine 42-stellige Adresse hat (ein 20-Byte-Segment, das aus 40 hexadezimalen Zeichen plus dem `0x`-Präfix besteht).
Beispiel:
`0x5e97870f263700f46aa00d967821199b9bc5a120`
-Das folgende Beispiel zeigt, wie Sie mit dem Signatur-Tool [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) ein neues Konto erstellen. Clef ist ein Kontenverwaltungs- und Signierungs-Tool, das zusammen mit dem Ethereum-Client [Geth](https://geth.ethereum.org) erhältlich ist. Der Befehl `clef newaccount` erstellt ein neues Schlüsselpaar und speichert es in einem verschlüsselten Schlüsselspeicher.
+Das folgende Beispiel zeigt, wie du mit einem Signier-Tool namens [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) ein neues Konto erstellst. Clef ist ein Tool zur Kontoverwaltung und zum Signieren, das mit dem Ethereum-Client [Geth](https://geth.ethereum.org) gebündelt ist. Der Befehl `clef newaccount` erstellt ein neues Schlüsselpaar und speichert es in einem verschlüsselten Keystore.
```
-> clef newaccount --keystore
+> clef newaccount --keystore
-Please enter a password for the new account to be created:
->
+Bitte gib ein Passwort für das neu zu erstellende Konto ein:
+>
------------
-INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
-WARN [10-28|16:19:09.306] Please remember your password!
-Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
+INFO [10-28|16:19:09.156] Dein neuer Schlüssel wurde generiert address=0x5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] Bitte sichere deine Schlüsseldatei path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
+WARN [10-28|16:19:09.306] Bitte merke dir dein Passwort!
+Erstelltes Konto 0x5e97870f263700f46aa00d967821199b9bc5a120
```
-[Dokumentation für Geth](https://geth.ethereum.org/docs)
+[Geth-Dokumentation](https://geth.ethereum.org/docs)
-Es ist möglich, neue öffentliche Schlüssel von deinem privaten Schlüssel abzuleiten, aber nicht, einen privaten Schlüssel von öffentlichen Schlüsseln abzuleiten. Es ist unabdingbar, Ihren privaten Schlüssel sicher aufzubewahren und – wie der Name schon sagt – **PRIVAT** zu halten.
+Es ist möglich, neue öffentliche Schlüssel von deinem privaten Schlüssel abzuleiten, aber du kannst keinen privaten Schlüssel von öffentlichen Schlüsseln ableiten. Es ist unerlässlich, deine privaten Schlüssel sicher aufzubewahren und – wie der Name schon sagt – **PRIVAT** zu halten.
Du benötigst einen privaten Schlüssel, um Nachrichten und Transaktionen zu signieren, die eine Signatur nach außen anzeigen. Andere können dann die Unterschrift verwenden, um deinen öffentlichen Schlüssel abzuleiten und den Autor der Nachricht zu verifizieren. In Ihrer Anwendung können Sie eine JavaScript-Bibliothek nutzen, um Transaktionen zum Netzwerk zu senden.
@@ -106,11 +107,11 @@ Beispiel:
Die Vertragsadresse wird in der Regel angegeben, wenn ein Vertrag an die Ethereum Blockchain versendet wird. Diese Adresse stammt von der Erstelleradresse und der Anzahl der Transaktionen, die von dieser Adresse versendet werden (die „nonce“).
-## Schlüssel für Validatoren {#validators-keys}
+## Validator-Schlüssel {#validators-keys}
Es gibt einen weiteren Schlüsseltyp in Ethereum, der mit dem Wechsel von Proof-of-Work zu Proof-of-Stake für den Konsensmechanismus eingeführt wurde. Dieser nennt sich BLS-Schlüssel und wird verwendet, um Validatoren zu identifizieren. Diese Schlüssel lassen sich sehr effizient aggregieren, um die Bandbreite zu reduzieren, die das Netzwerk benötigt, um einen Konsens zu erzielen. Ohne diese Schlüsselaggregation wäre der minimale Stake für Validatoren viel höher.
-[Mehr über Schlüssel für Validatoren](/developers/docs/consensus-mechanisms/pos/keys/).
+[Mehr über Validator-Schlüssel](/developers/docs/consensus-mechanisms/pos/keys/).
## Ein Hinweis zu Wallets {#a-note-on-wallets}
@@ -124,11 +125,11 @@ Austin führt Sie durch Hash-Funktionen und Schlüsselpaare.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Ethereum Accounts verstehen](https://info.etherscan.com/understanding-ethereum-accounts/) – Etherscan
+- [Ethereum-Konten verstehen](https://info.etherscan.com/understanding-ethereum-accounts/) – Etherscan
-_Gibt es Community-Resourcen, die Sie hilfreich fanden? Bearbeiten Sie diese Seite und fügen Sie sie hinzu._
+_Sie kennen Community-Resourcen die Ihnen geholfen haben? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!_
## Verwandte Themen {#related-topics}
diff --git a/public/content/translations/de/developers/docs/apis/backend/index.md b/public/content/translations/de/developers/docs/apis/backend/index.md
index 9b76ebe5038..385abdc0f15 100644
--- a/public/content/translations/de/developers/docs/apis/backend/index.md
+++ b/public/content/translations/de/developers/docs/apis/backend/index.md
@@ -1,12 +1,12 @@
---
title: Backend-API-Bibliotheken
-description: Eine Einführung in die Ethereum-Client-APIs, über die Sie mit der Blockchain Ihrer Anwendung interagieren können.
+description: "Eine Einführung in die Ethereum-Client-APIs, über die Sie mit der Blockchain Ihrer Anwendung interagieren können."
lang: de
---
-Damit eine Softwareanwendung mit der Ethereum-Blockchain interagieren kann (z. B. Lesen von Blockchain-Daten und/oder Senden von Transaktionen an das Netzwerk), muss es sich mit einem Ethereum-Knoten verbinden.
+Damit eine Softwareanwendung mit der Ethereum-Blockchain interagieren kann (d. h. Blockchain-Daten lesen und/oder Transaktionen an das Netzwerk senden), muss sie sich mit einem Ethereum-Node verbinden.
-Zu diesem Zweck implementiert jeder Ethereum-Client die [JSON-RPC](/developers/docs/apis/json-rpc/)-Spezifikation, sodass eine einheitliche Sammlung von [Methoden](/developers/docs/apis/json-rpc/#json-rpc-methods) zur Verfügung steht, auf die Anwendungen sich verlassen können.
+Zu diesem Zweck implementiert jeder Ethereum-Client die [JSON-RPC](/developers/docs/apis/json-rpc/)-Spezifikation, sodass ein einheitlicher Satz von [Methoden](/developers/docs/apis/json-rpc/#json-rpc-methods) zur Verfügung steht, auf die sich Anwendungen verlassen können.
Wenn Sie eine bestimmte Programmiersprache verwenden möchten, um sich mit einem Ethereum-Knoten zu verbinden, können Sie auf eine der komfortablen Bibliotheken in diesem Ökosystem zurückgreifen, die Ihnen das Leben erleichtern. Mit diesen Programmbibliotheken können Entwickler intuitive, einzeilige Methoden schreiben, um JSON-RPC-Anfragen („unter der Haube“) zu initialisieren, die mit Ethereum interagieren.
@@ -16,16 +16,16 @@ Es könnte hilfreich sein, den [Ethereum-Stack](/developers/docs/ethereum-stack/
## Warum eine Bibliothek verwenden? {#why-use-a-library}
-Durch Abstraktion vereinfachen diese Programmbibliotheken die komplexe direkte Interaktion mit einem Ethereum-Knoten. Zudem bieten sie auch Dienstprogrammfunktionen (z. B. ETH in GWei umwandeln), so dass Sie als Entwickler weniger Zeit mit den Problemstellungen der Ethereum-Clients verbringen müssen und sich stärker auf die einzigartige Funktion Ihrer Anwendung konzentrieren können.
+Durch Abstraktion vereinfachen diese Programmbibliotheken die komplexe direkte Interaktion mit einem Ethereum-Knoten. Sie bieten auch Hilfsfunktionen (z. B. die Umrechnung von ETH in Gwei), sodass Sie als Entwickler weniger Zeit mit den Feinheiten von Ethereum-Clients verbringen und sich mehr auf die einzigartige Funktionalität Ihrer Anwendung konzentrieren können.
## Verfügbare Bibliotheken {#available-libraries}
-### Infrastruktur- und Knoten-Dienste {#infrastructure-and-node-services}
+### Infrastruktur- und Node-Dienste {#infrastructure-and-node-services}
-**Alchemy-****_Ehereum-Entwicklungsplattform_**
+**Alchemy –** **_Ethereum-Entwicklungsplattform._**
- [alchemy.com](https://www.alchemy.com/)
-- [Dokumentation](https://docs.alchemy.com/)
+- [Dokumentation](https://www.alchemy.com/docs/)
- [GitHub](https://github.com/alchemyplatform)
- [Discord](https://discord.com/invite/alchemyplatform)
@@ -35,13 +35,13 @@ Durch Abstraktion vereinfachen diese Programmbibliotheken die komplexe direkte I
- [Dokumentation](https://docs.allthatnode.com)
- [Discord](https://discord.gg/GmcdVEUbJM)
-**Blast by Bware Labs -** **_Dezentrale APIs für Ethereum Mainnet und Testnetzwerke._**
+**Blast by Bware Labs –** **_Dezentrale APIs für Ethereum-Mainnet und Testnets._**
- [blastapi.io](https://blastapi.io/)
- [Dokumentation](https://docs.blastapi.io)
-- [Discord](https://discord.gg/bwarelabs)
+- [Discord](https://discord.gg/SaRqmRUjjQ)
-**BlockPi -** **_Bereitstellung von effizienteren und schnellen RPC-Diensten_**
+**BlockPi –** **_Bereitstellung effizienterer und schnellerer RPC-Dienste_**
- [blockpi.io](https://blockpi.io/)
- [Dokumentation](https://docs.blockpi.io/)
@@ -53,111 +53,116 @@ Durch Abstraktion vereinfachen diese Programmbibliotheken die komplexe direkte I
- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/)
**Etherscan – Blockexplorer und Transaktions-API**
+
- [Dokumentation](https://docs.etherscan.io/)
-**GetBlock-** **_Blockchain als Dienstleistung für Web3-Entwicklung_**
+**Blockscout - ein Open-Source-Block-Explorer**
+
+- [Dokumentation](https://docs.blockscout.com/)
+
+**GetBlock –** **_Blockchain-as-a-Service für die Web3-Entwicklung_**
- [GetBlock.io](https://getblock.io/)
-- [Dokumentation](https://getblock.io/docs/)
+- [Dokumentation](https://docs.getblock.io/)
-**Infura –** **_Die Ethereum-API als Dienst_**
+**Infura –** **_Die Ethereum-API als Service._**
- [infura.io](https://infura.io)
- [Dokumentation](https://docs.infura.io/api)
- [GitHub](https://github.com/INFURA)
-**Node RPC – _kostengünstiger EVM-JSON-RPC-Anbieter_**
+**Node RPC – _Kostengünstiger EVM-JSON-RPC-Anbieter_**
- [noderpc.xyz](https://www.noderpc.xyz/)
- [Dokumentation](https://docs.noderpc.xyz/node-rpc)
-**NOWNodes - _Full Nodes und Block Explorers._**
+**NOWNodes – _Full Nodes und Block-Explorer._**
- [NOWNodes.io](https://nownodes.io/)
-- [Dokumentation](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro)
+- [Dokumentation](https://nownodes.gitbook.io/documentation)
-**QuickNode –** **_Blockchain-Infrastruktur als Dienstleistung_**
+**QuickNode –** **_Blockchain-Infrastruktur as a Service._**
- [quicknode.com](https://quicknode.com)
- [Dokumentation](https://www.quicknode.com/docs/welcome)
- [Discord](https://discord.gg/quicknode)
-**Rivet –** **_Ethereum- und Ethereum Classic-APIs als Service unterstützt durch Open-Source-Software_**
+**Rivet –** **_Ethereum- und Ethereum-Classic-APIs as a Service, betrieben mit Open-Source-Software._**
- [rivet.cloud](https://rivet.cloud)
- [Dokumentation](https://rivet.cloud/docs/)
- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment)
-**Zmok –** **_geschwindigkeitsorientierte Ethereum-Nodes als JSON-RPC-/WebSockets-API_**
+**Zmok –** **_Geschwindigkeitsorientierte Ethereum-Nodes als JSON-RPC/WebSockets-API._**
- [zmok.io](https://zmok.io/)
- [GitHub](https://github.com/zmok-io)
- [Dokumentation](https://docs.zmok.io/)
- [Discord](https://discord.gg/fAHeh3ka6s)
-### Entwicklungswerkzeuge {#development-tools}
+### Entwicklerwerkzeuge {#development-tools}
-**ethers-kt – ** **_asynchrone, hochleistungsfähige Kotlin-/Java-/Android-Bibliothek für EVM-basierte Blockchains._**
+**ethers-kt –** **_Asynchrone, hochleistungsfähige Kotlin-/Java-/Android-Bibliothek für EVM-basierte Blockchains._**
- [GitHub](https://github.com/Kr1ptal/ethers-kt)
- [Beispiele](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
- [Discord](https://discord.gg/rx35NzQGSb)
-**Nethereum -** **_Eine Open Source .NET Integration-Library für Blockchain_**
+**Nethereum –** **_Eine Open-Source-.NET-Integrationsbibliothek für die Blockchain._**
- [GitHub](https://github.com/Nethereum/Nethereum)
- [Dokumentation](http://docs.nethereum.com/en/latest/)
- [Discord](https://discord.com/invite/jQPrR58FxX)
-**Python Tooling –** **_eine Auswahl von Programmbibliotheken für Ethereum-Interaktion über Python_**
+**Python-Tooling –** **_Eine Vielzahl von Bibliotheken für die Interaktion mit Ethereum über Python._**
-- [py.ethereum.org](https://python.ethereum.org/)
+- [py.ethereum.org](https://snakecharmers.ethereum.org/)
- [web3.py GitHub](https://github.com/ethereum/web3.py)
-- [web3.py Chat](https://gitter.im/ethereum/web3.py)
+- [web3.py-Chat](https://gitter.im/ethereum/web3.py)
-**Tatum –** **_die ultimative Blockchain-Entwicklungsplattform_**
+**Tatum –** **_Die ultimative Blockchain-Entwicklungsplattform._**
- [Tatum](https://tatum.io/)
- [GitHub](https://github.com/tatumio/)
- [Dokumentation](https://docs.tatum.io/)
- [Discord](https://discord.gg/EDmW3kjTC9)
-**web3j –** **_eine Java-/Android-/Kotlin-/Scala -Integrationsbibliothek für Ethereum_**
+**web3j –** **_Eine Java/Android/Kotlin/Scala-Integrationsbibliothek für Ethereum._**
- [GitHub](https://github.com/web3j/web3j)
-- [Dokumente](https://docs.web3j.io/)
+- [Docs](https://docs.web3j.io/)
- [Gitter](https://gitter.im/web3j/web3j)
### Blockchain-Dienste {#blockchain-services}
-**BlockCypher –** **_Ethereum-Web-APIs_**
+**BlockCypher –** **_Ethereum-Web-APIs._**
- [blockcypher.com](https://www.blockcypher.com/)
- [Dokumentation](https://www.blockcypher.com/dev/ethereum/)
-**Chainbase -** **_All-in-One web3-Dateninfrastruktur für Ethereum._**
+**Chainbase –** **_All-in-one-Web3-Dateninfrastruktur für Ethereum._**
- [chainbase.com](https://chainbase.com/)
- [Dokumentation](https://docs.chainbase.com/)
- [Discord](https://discord.gg/Wx6qpqz4AF)
-**Chainstack -** **_Elastische und dedizierte Ethereum-Nodes als Dienst._**
+**Chainstack –** **_Elastische und dedizierte Ethereum-Nodes as a Service._**
- [chainstack.com](https://chainstack.com)
-- [Dokumentation](https://docs.chainbase.com/docs)
-- [Ethereum API-Referenz](https://docs.chainstack.com/reference/ethereum-getting-started)
+- [Dokumentation](https://docs.chainstack.com/)
+- [Ethereum-API-Referenz](https://docs.chainstack.com/reference/ethereum-getting-started)
-**Coinbase Cloud Node -** **_Blockchain Infrastruktur-API._**
+**Coinbase Cloud Node –** **_Blockchain-Infrastruktur-API._**
-- [Coinbase Cloud Node](https://www.coinbase.com/cloud)
-- [Dokumentation](https://docs.cloud.coinbase.com/)
+- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform)
+- [Dokumentation](https://docs.cdp.coinbase.com/)
-**DataHub von Figment -** **_Web3-API-Dienste mit Ethereum-Mainnet und -Testnets_**
+**DataHub by Figment –** **_Web3-API-Dienste mit Ethereum-Mainnet und Testnets._**
- [DataHub](https://www.figment.io/)
- [Dokumentation](https://docs.figment.io/)
-**Moralis -** **_EVM API-Anbieter auf Unternehmensebene._**
+**Moralis –** **_EVM-API-Anbieter auf Unternehmensebene._**
- [moralis.io](https://moralis.io)
- [Dokumentation](https://docs.moralis.io/)
@@ -165,43 +170,42 @@ Durch Abstraktion vereinfachen diese Programmbibliotheken die komplexe direkte I
- [Discord](https://moralis.io/joindiscord/)
- [Forum](https://forum.moralis.io/)
-**NFTPort -** **_Ethereum Daten- und Mint-APIs._**
+**NFTPort –** **_Ethereum-Daten- und Mint-APIs._**
- [nftport.xyz](https://www.nftport.xyz/)
- [Dokumentation](https://docs.nftport.xyz/)
- [GitHub](https://github.com/nftport/)
- [Discord](https://discord.com/invite/K8nNrEgqhE)
-**Tokenview -** **_Die allgemeine API-Plattform für die Multi-Crypto-Blockchain._**
+**Tokenview –** **_Die allgemeine Plattform für Multi-Krypto-Blockchain-APIs._**
- [services.tokenview.io](https://services.tokenview.io/)
- [Dokumentation](https://services.tokenview.io/docs?type=api)
- [GitHub](https://github.com/Tokenview)
-**Watchdata –** **_bietet einen einfachen und zuverlässigen API-Zugriff auf die Ethereum-Blockchain_**
+**Watchdata –** **_Bietet einfachen und zuverlässigen API-Zugriff auf die Ethereum-Blockchain._**
- [Watchdata](https://watchdata.io/)
- [Dokumentation](https://docs.watchdata.io/)
- [Discord](https://discord.com/invite/TZRJbZ6bdn)
-**Covalent –** **_erweiterte Blockchain-APIs für über 200 Ketten._**
+**Covalent –** **_Angereicherte Blockchain-APIs für über 200 Chains._**
- [covalenthq.com](https://www.covalenthq.com/)
- [Dokumentation](https://www.covalenthq.com/docs/api/)
- [GitHub](https://github.com/covalenthq)
- [Discord](https://www.covalenthq.com/discord/)
-
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
_Sie kennen Community-Resourcen die Ihnen geholfen haben? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!_
## Verwandte Themen {#related-topics}
-- [Knotenpunkte und Clients](/developers/docs/nodes-and-clients/)
+- [Nodes und Clients](/developers/docs/nodes-and-clients/)
- [Entwicklungs-Frameworks](/developers/docs/frameworks/)
-## Ähnliche Tutorials {#related-tutorials}
+## Verwandte Tutorials {#related-tutorials}
-- [Web3js einrichten, um die Ethereum-Blockchain in JavaScript zu nutzen](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Leitfaden für die Einrichtung von web3.js in Ihrem Projekt._
-- [Aufruf eines intelligenten Vertrags mit JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Mit dem DAI-Token können Sie die Funktion „Verträge aufrufen“ mit JavaScript verwenden._
+- [Web3.js einrichten, um die Ethereum-Blockchain in JavaScript zu verwenden](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Anleitung, um web3.js in Ihrem Projekt einzurichten._
+- [Einen Smart Contract aus JavaScript aufrufen](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Sehen Sie am Beispiel des DAI-Tokens, wie man Vertragsfunktionen mit JavaScript aufruft._
diff --git a/public/content/translations/de/developers/docs/apis/javascript/index.md b/public/content/translations/de/developers/docs/apis/javascript/index.md
index 24cde103297..03b2681dacf 100644
--- a/public/content/translations/de/developers/docs/apis/javascript/index.md
+++ b/public/content/translations/de/developers/docs/apis/javascript/index.md
@@ -1,41 +1,43 @@
---
title: JavaScript-API-Bibliotheken
-description: Eine Einführung in die JavaScript-Client-Bibliotheken, über die Sie von Ihrer Anwendung aus mit der Blockchain interagieren können.
+description: "Eine Einführung in die JavaScript-Client-Bibliotheken, über die Sie von Ihrer Anwendung aus mit der Blockchain interagieren können."
lang: de
---
-Damit eine Web-Anwendung mit der Ethereum-Blockchain interagieren kann (z. B. Auslesen von Blockchain-Daten und/oder Senden von Transaktionen an das Netzwerk), muss sie sich mit einem Ethereum-Node verbinden.
+Damit eine Web-Anwendung mit der Ethereum-Blockchain interagieren kann (d. h. Blockchain-Daten lesen und/oder Transaktionen an das Netzwerk senden), muss sie sich mit einem Ethereum-Node verbinden.
-Zu diesem Zweck implementiert jeder Ethereum-Client die [JSON-RPC](/developers/docs/apis/json-rpc/)-Spezifikation, damit es einen einheitlichen Satz von [Methoden](/developers/docs/apis/json-rpc/#json-rpc-methods) gibt, auf die sich Anwendungen verlassen können.
+Zu diesem Zweck implementiert jeder Ethereum-Client die [JSON-RPC](/developers/docs/apis/json-rpc/)-Spezifikation, sodass es einen einheitlichen Satz von [Methoden](/developers/docs/apis/json-rpc/#json-rpc-methods) gibt, auf die sich Anwendungen verlassen können.
Wenn Sie sich über JavaScript mit einem Ethereum-Node verbinden möchten, ist das auch über VanillaJavaScript möglich. Doch es existieren noch weitere Lösungen in Programmbibliotheken in diesem Ökosystem, die das alles viel einfacher machen. Mit diesen Programmbibliotheken können Entwickler intuitive, einzeilige Methoden schreiben, um JSON-RPC-Anfragen („unter der Haube“) zu initialisieren, die mit Ethereum interagieren.
-Bitte beachten Sie, dass seit [der Zusammenführung](/roadmap/merge/) zwei verbundene Teile von Ethereum-Software benötigt werden, um einen Knoten zu betreiben. Ein Ausführungsclient und ein Konsensclient. Bitte stellen Sie sicher, dass Ihr Knoten sowohl über einen Ausführungs- als auch einen Konsensclient verfügt. Wenn sich Ihr Knoten nicht auf einem lokalen Rechner (Ihr Knoten läuft z. B. auf einer AWS-Instanz) befindet, müssen Sie die IP-Adressen im Tutorial entsprechend anpassen. Für weitere Informationen schauen Sie sich unsere Seite zum [Betreiben eines Knotens](/developers/docs/nodes-and-clients/run-a-node/) an.
+Bitte beachten Sie, dass seit [dem Merge](/roadmap/merge/) zwei verbundene Teile der Ethereum-Software – ein Ausführungs-Client und ein Konsens-Client – erforderlich sind, um einen Node zu betreiben. Bitte stellen Sie sicher, dass Ihr Knoten sowohl über einen Ausführungs- als auch einen Konsensclient verfügt. Wenn sich Ihr Node nicht auf Ihrem lokalen Rechner befindet (z. B. wenn er auf einer AWS-Instanz ausgeführt wird), aktualisieren Sie die IP-Adressen im Tutorial entsprechend. Weitere Informationen finden Sie auf unserer Seite über das [Betreiben eines Nodes](/developers/docs/nodes-and-clients/run-a-node/).
## Voraussetzungen {#prerequisites}
-Sie müssen JavaScript verstehen. Zusätzlich ist es hilfreich, wenn Sie den [Ethereum-Stack](/developers/docs/ethereum-stack/) und [Ethereum-Clients](/developers/docs/nodes-and-clients/) ebenfalls verstehen.
+Neben dem Verständnis von JavaScript könnte es hilfreich sein, den [Ethereum-Stack](/developers/docs/ethereum-stack/) und die [Ethereum-Clients](/developers/docs/nodes-and-clients/) zu verstehen.
-## Warum eine Programmbibliothek verwenden? {#why-use-a-library}
+## Warum eine Bibliothek verwenden? {#why-use-a-library}
-Mit diesen Programmbibliotheken lässt sich die direkte Interaktion mit einem Ethereum-Node erheblich vereinfachen. Zudem bieten sie Dienstprogrammfunktionen (z. B. Umwandlung von ETH zu GWei), so dass Sie als Entwickler weniger Zeit damit verbringen, Probleme mit Ethereum-Clients zu lösen, und sich auf die einzigartigen Funktionen Ihrer Applikation konzentrieren können.
+Durch Abstraktion vereinfachen diese Programmbibliotheken die komplexe direkte Interaktion mit einem Ethereum-Knoten. Sie bieten auch Hilfsfunktionen (z. B. die Umrechnung von ETH in Gwei), sodass Sie als Entwickler weniger Zeit mit den Feinheiten von Ethereum-Clients verbringen und sich mehr auf die einzigartige Funktionalität Ihrer Anwendung konzentrieren können.
-## Eigenschaften von Programmbibliotheken {#library-features}
+## Bibliotheksfunktionen {#library-features}
-### Verbindung mit Ethereum-Nodes {#connect-to-ethereum-nodes}
+### Mit Ethereum-Nodes verbinden {#connect-to-ethereum-nodes}
Sie können sich über einen Provider und diese Bibliotheken mit Ethereum verbinden und die Daten auslesen – über JSON-RPC, INFURA, Etherscan, Alchemy oder MetaMask.
+> **Warnung:** Web3.js wurde am 4. März 2025 archiviert. [Lesen Sie die Ankündigung](https://blog.chainsafe.io/web3-js-sunset/). Ziehen Sie für neue Projekte die Verwendung alternativer Bibliotheken wie [ethers.js](https://ethers.org) oder [viem](https://viem.sh) in Betracht.
+
**Ether-Beispiel**
```js
-// Ein BrowserProvider umschließt einen standardmäßigen Web3-Provider, der
-// von MetaMask als window.ethereum in jede Seite injiziert wird
+// Ein BrowserProvider umschließt einen Standard-Web3-Provider,
+// den MetaMask als window.ethereum in jede Seite injiziert
const provider = new ethers.BrowserProvider(window.ethereum)
-// Das MetaMask-Plugin ermöglicht auch das Signieren von Transaktionen, um
-// Ether zu senden und bezahlte Statusänderungen innerhalb der Blockchain vorzunehmen.
-// Dazu benötigen wir den Unterzeichner vom Konto...
+// Das MetaMask-Plugin ermöglicht auch das Signieren von Transaktionen,
+// um Ether zu senden und für Zustandsänderungen in der Blockchain zu bezahlen.
+// Dafür benötigen wir den Signierer des Kontos...
const signer = provider.getSigner()
```
@@ -68,7 +70,7 @@ Sobald die Einrichtung abgeschlossen ist, können Sie folgende Abfragen für die
- Ressourcen-Schätzung
- Smart-Contract-Ereignisse
- Netzwerk-ID
-- und weitere...
+- und mehr...
### Wallet-Funktionalität {#wallet-functionality}
@@ -77,7 +79,7 @@ Diese Programmbibliotheken bieten Ihnen die Funktionalität, um Wallets zu erste
Hier ist ein Beispiel von Ethers
```js
-// Erstelle eine Wallet-Instanz aus einem Mnemonik...
+// Erstellen einer Wallet-Instanz aus einer Mnemonic...
mnemonic =
"announce room limb pattern dry unit scale effort smooth jazz weasel alcohol"
walletMnemonic = Wallet.fromPhrase(mnemonic)
@@ -88,15 +90,15 @@ walletPrivateKey = new Wallet(walletMnemonic.privateKey)
walletMnemonic.address === walletPrivateKey.address
// true
-// Die Adresse als Promise gemäß der Signer API
+// Die Adresse als Promise gemäß der Signer-API
walletMnemonic.getAddress()
// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' }
-// Die Wallet-Adresse ist auch synchron verfügbar
+// Eine Wallet-Adresse ist auch synchron verfügbar
walletMnemonic.address
// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1'
-// Die internen kryptographischen Komponenten
+// Die internen kryptografischen Komponenten
walletMnemonic.privateKey
// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db'
walletMnemonic.publicKey
@@ -110,7 +112,7 @@ walletMnemonic.mnemonic
// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol'
// }
-// Hinweis: Ein Wallet, das mit einem privaten Schlüssel erstellt wurde, hat keine
+// Hinweis: Eine Wallet, die mit einem privaten Schlüssel erstellt wurde, hat keine
// Mnemonic (die Ableitung verhindert dies)
walletPrivateKey.mnemonic
// null
@@ -128,8 +130,8 @@ tx = {
walletMnemonic.signTransaction(tx)
// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' }
-// Die Connect-Methode gibt eine neue Instanz des
-// Wallets zurück, die mit einem Provider verbunden ist
+// Die connect-Methode gibt eine neue Instanz des
+// mit einem Provider verbundenen Wallets zurück
wallet = walletMnemonic.connect(provider)
// Abfragen des Netzwerks
@@ -138,33 +140,33 @@ wallet.getBalance()
wallet.getTransactionCount()
// { Promise: 0 }
-// Ether senden
+// Senden von Ether
wallet.sendTransaction(tx)
```
-[Lesen Sie die ganzen Dokumente](https://docs.ethers.io/v5/api/signer/#Wallet)
+[Lesen Sie die vollständige Dokumentation](https://docs.ethers.io/v5/api/signer/#Wallet)
Einmal eingerichtet, können Sie:
- Konten erstellen
- Transaktionen senden
- Transaktionen signieren
-- und weitere...
+- und mehr...
-### Mit den Funktionen von Smart Contracts interagieren {#interact-with-smart-contract-functions}
+### Mit Smart-Contract-Funktionen interagieren {#interact-with-smart-contract-functions}
JavaScript-Client-Bibliotheken ermöglichen Ihrer Anwendung, Smart Contract-Funktionen aufzurufen. Dafür lesen sie die Application Binary Interface (ABI) eines kompilierten Vertrags.
Die ABI erklärt im Wesentlichen die Funktionen des Vertrags im JSON-Format und erlaubt die Verwendung wie ein normales JavaScript-Objekt.
-Also folgender Solidity-Vertrag:
+Folgender Solidity-Vertrag würde...
```solidity
contract Test {
uint a;
address d = 0x12345678901234567890123456789012;
- function Test(uint testInt) { a = testInt;}
+ constructor(uint testInt) { a = testInt;}
event Event(uint indexed b, bytes32 c);
@@ -177,7 +179,7 @@ contract Test {
}
```
-Würde in nachfolgendem JSON resultieren:
+... zu nachfolgendem JSON werden:
```json
[{
@@ -213,11 +215,11 @@ Dies bedeutet Sie können:
- Sie können einen Vertrag bereitstellen.
- Und mehr...
-### Dienstprogrammfunktionen {#utility-functions}
+### Hilfsfunktionen {#utility-functions}
Die Dienstprogrammfunktionen stellen Ihnen praktische Verknüpfungen bereit, die das Entwickeln mit Ethereum erleichtern.
-ETH-Werte sind standardmäßig in Wei. 1 ETH = 1.000.000.000.000.000.000.000.000 WEI – sprich, Sie haben es mit vielen Zahlen zu tun. `web3.utils.toWei` konvertiert für Sie Ether in Wei.
+ETH-Werte sind standardmäßig in Wei. 1 ETH = 1.000.000.000.000.000.000.000.000 WEI – sprich, Sie haben es mit vielen Zahlen zu tun. `web3.utils.toWei` konvertiert Ether für Sie in Wei.
Das sieht in Ether wie folgt aus:
@@ -232,60 +234,56 @@ ethers.utils.formatEther(balance)
// '2.337132817842795605'
```
-- [Web3js-Dienstprogrammfunktionen](https://docs.web3js.org/api/web3-utils)
-- [Ethers-Dienstprogrammfunktionen](https://docs.ethers.io/v5/api/utils/)
+- [Web3.js-Hilfsfunktionen](https://docs.web3js.org/api/web3-utils)
+- [Ethers-Hilfsfunktionen](https://docs.ethers.org/v6/api/utils/)
-## Verfügbare Programmbibliotheken {#available-libraries}
+## Verfügbare Bibliotheken {#available-libraries}
-**Web3.js –** **_Ethereum-JavaScript-API_**
+**Web3.js –** **_Ethereum-JavaScript-API._**
-- [Dokumentation](https://docs.web3js.org/)
-- [GitHub](https://github.com/ethereum/web3.js/)
+- [Dokumentation](https://docs.web3js.org)
+- [GitHub](https://github.com/ethereum/web3.js)
-**Ethers.js –** **_Eine vollständige Ethereum-Wallet-Implementierung und Dienstprogramme in JavaScript und TypeScript_**
+**Ethers.js –** **_Eine vollständige Ethereum-Wallet-Implementierung und Dienstprogramme in JavaScript und TypeScript._**
-- [Dokumentation](https://docs.ethers.io/)
-- [GitHub](https://github.com/ethers-io/ethers.js/)
+- [Ethers.js-Startseite](https://ethers.org/)
+- [Dokumentation](https://docs.ethers.io)
+- [GitHub](https://github.com/ethers-io/ethers.js)
-**The Graph –** **_Ein Protokoll für die Indizierung von Ethereum- und IPFS-Daten und Abfragen mit GraphQL_**
+**The Graph –** **_Ein Protokoll zur Indizierung von Ethereum- und IPFS-Daten und deren Abfrage mit GraphQL._**
-- [The Graph](https://thegraph.com/)
-- [Graph Explorer](https://thegraph.com/explorer/)
-- [Dokumentation](https://thegraph.com/docs/)
-- [GitHub](https://github.com/graphprotocol/)
+- [The Graph](https://thegraph.com)
+- [Graph Explorer](https://thegraph.com/explorer)
+- [Dokumentation](https://thegraph.com/docs)
+- [GitHub](https://github.com/graphprotocol)
- [Discord](https://thegraph.com/discord)
-**light.js –** **_Eine reaktive High-Level-JS-Bibliothek, die für leichte Clients optimiert wurde._**
-
-- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js)
-
-
-**Alchemyweb3 –** **_Wrapper um Web3.js mit automatischen Wiederholungen und erweiterten APIs_**
+**Alchemy SDK –** **_Ein Wrapper um Ethers.js mit erweiterten APIs._**
-- [Dokumentation](https://docs.alchemy.com/reference/api-overview)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
+- [Dokumentation](https://www.alchemy.com/docs)
+- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js)
-**Alchemy NFT API –** **_API für den Abruf von NFT-Daten, einschließlich Eigentumsrechten, Metadatenattributen und mehr._**
-
-- [Dokumentation](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
-- [GitHub](https://github.com/alchemyplatform/alchemy-web3)
-
-**Viem -** **_Schnittstelle in TypeScript für Ethereum._**
+**viem –** **_TypeScript-Schnittstelle für Ethereum._**
- [Dokumentation](https://viem.sh)
- [GitHub](https://github.com/wagmi-dev/viem)
-## Weiterführende Informationen {#further-reading}
+**Drift –** **_TypeScript-Meta-Bibliothek mit integriertem Caching, Hooks und Test-Mocks._**
+
+- [Dokumentation](https://ryangoree.github.io/drift/)
+- [GitHub](https://github.com/ryangoree/drift/)
+
+## Weiterführende Lektüre {#further-reading}
_Sie kennen Community-Resourcen die Ihnen geholfen haben? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!_
## Verwandte Themen {#related-topics}
-- [Knotenpunkte und Clients](/developers/docs/nodes-and-clients/)
+- [Nodes und Clients](/developers/docs/nodes-and-clients/)
- [Entwicklungs-Frameworks](/developers/docs/frameworks/)
-## Ähnliche Tutorials {#related-tutorials}
+## Verwandte Tutorials {#related-tutorials}
-- [Web3js einrichten, um die Ethereum-Blockchain in JavaScript zu nutzen](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Leitfaden für die Einrichtung von web3.js in Ihrem Projekt._
-- [Aufruf eines intelligenten Vertrags mit JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Mit dem DAI-Token können Sie die Funktion „Verträge aufrufen“ mit JavaScript verwenden._
-- [Transaktionen über web3 und Alchemy senden](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– Schritt-für-Schritt-Komplettlösung zum Senden von Transaktionen aus dem Backend._
+- [Web3.js einrichten, um die Ethereum-Blockchain in JavaScript zu verwenden](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Anleitung, um web3.js in Ihrem Projekt einzurichten._
+- [Einen Smart Contract aus JavaScript aufrufen](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Sehen Sie am Beispiel des DAI-Tokens, wie man Vertragsfunktionen mit JavaScript aufruft._
+- [Transaktionen mit Web3 und Alchemy senden](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– Schritt-für-Schritt-Anleitung zum Senden von Transaktionen vom Backend aus._
diff --git a/public/content/translations/de/developers/docs/apis/json-rpc/index.md b/public/content/translations/de/developers/docs/apis/json-rpc/index.md
index ad51b54df9a..19a3559f1b1 100644
--- a/public/content/translations/de/developers/docs/apis/json-rpc/index.md
+++ b/public/content/translations/de/developers/docs/apis/json-rpc/index.md
@@ -1,36 +1,36 @@
---
title: JSON-RPC-API
-description: Ein zustandsloses, leichtgewichtiges Remote Procedure Call (RPC)-Protokoll für Ethereum-Clients
+description: "Ein zustandsloses, leichtgewichtiges Remote Procedure Call (RPC)-Protokoll für Ethereum-Clients"
lang: de
---
Damit eine Software-Anwendung mit der Ethereum-Blockchain interagieren kann – entweder um Blockchain-Daten zu lesen oder Transaktionen an das Netzwerk zu senden – muss sie mit einem Ethereum-Knoten verbunden werden.
-Zu diesem Zweck implementiert jeder [Ethereum-Client](/developers/docs/nodes-and-clients/#execution-clients) eine [JSON-RPC-Spezifikation](https://github.com/ethereum/execution-apis), sodass eine einheitliche Methode vorliegt, auf die sich Anwendungen verlassen können, unabhängig von der spezifischen Nodes oder Client Implementierung.
+Zu diesem Zweck implementiert jeder [Ethereum-Client](/developers/docs/nodes-and-clients/#execution-clients) eine [JSON-RPC-Spezifikation](https://github.com/ethereum/execution-apis), sodass ein einheitlicher Satz von Methoden vorhanden ist, auf den sich Anwendungen unabhängig von der spezifischen Node- oder Client-Implementierung verlassen können.
-[JSON-RPC](https://www.jsonrpc.org/specification) ist ein zustandsloses, leichtgewichtiges Remote-Prozeduraufruf-(RPC)-Protokoll. Es definiert mehrere Datenstrukturen und die Regeln für deren Verarbeitung. Sie ist transportunabhängig, da die Konzepte innerhalb eines Prozesses, über Sockets, über HTTP oder in vielen verschiedenen Nachrichtenübermittlungsumgebungen verwendet werden können. Verwendet wird dabei das Datenformat JSON (RFC 4627).
+[JSON-RPC](https://www.jsonrpc.org/specification) ist ein zustandsloses, schlankes Remote-Prozeduraufruf- (RPC) Protokoll. Es definiert mehrere Datenstrukturen und die Regeln für deren Verarbeitung. Sie ist transportunabhängig, da die Konzepte innerhalb eines Prozesses, über Sockets, über HTTP oder in vielen verschiedenen Nachrichtenübermittlungsumgebungen verwendet werden können. Verwendet wird dabei das Datenformat JSON (RFC 4627).
## Client-Implementierungen {#client-implementations}
-Ethereum-Clients können bei der Implementierung der JSON-RPC-Spezifikation jeweils unterschiedliche Programmiersprachen verwenden. Weitere Details zu den einzelnen Programmiersprachen finden Sie in der [Client-Dokumentation](/developers/docs/nodes-and-clients/#execution-clients). Es wird empfohlen, dass Sie sich mit den neuesten Informationen zur API-Unterstützung in der Dokumentation des jeweiligen Clients vertraut machen.
+Ethereum-Clients können bei der Implementierung der JSON-RPC-Spezifikation jeweils unterschiedliche Programmiersprachen verwenden. Weitere Details zu bestimmten Programmiersprachen finden Sie in der jeweiligen [Client-Dokumentation](/developers/docs/nodes-and-clients/#execution-clients). Es wird empfohlen, dass Sie sich mit den neuesten Informationen zur API-Unterstützung in der Dokumentation des jeweiligen Clients vertraut machen.
-## Komfortable Bibliotheken {#convenience-libraries}
+## Convenience-Bibliotheken {#convenience-libraries}
-Es ist möglich, über die JSAON-RPC-API direkt mit Ethereum-Clients zu interagieren, doch für dApp-Entwickler gibt es häufig einfachere Optionen. Es gibt viele [JavaScript-](/developers/docs/apis/javascript/#available-libraries) und [Backend-API-](/developers/docs/apis/backend/#available-libraries) Bibliotheken, die Wrapper für die JSON-RPC-API bereitstellen. Mithilfe dieser Bibliotheken können Entwickler intuitive, einzeilige Methoden in der Programmiersprache ihrer Wahl schreiben, um JSON-RPC-Anforderungen (unter der Haube) zu initialisieren, die mit Ethereum interagieren.
+Es ist möglich, über die JSAON-RPC-API direkt mit Ethereum-Clients zu interagieren, doch für dApp-Entwickler gibt es häufig einfachere Optionen. Es existieren viele [JavaScript-](/developers/docs/apis/javascript/#available-libraries) und [Backend-API-](/developers/docs/apis/backend/#available-libraries)Bibliotheken, die Wrapper für die JSON-RPC-API bereitstellen. Mithilfe dieser Bibliotheken können Entwickler intuitive, einzeilige Methoden in der Programmiersprache ihrer Wahl schreiben, um JSON-RPC-Anforderungen (unter der Haube) zu initialisieren, die mit Ethereum interagieren.
-## Konsensclient-APIs {#consensus-clients}
+## Konsens-Client-APIs {#consensus-clients}
-Diese Seite befasst sich hauptsächlich mit der JSON-RPC-API, die von Ethereum-Ausführungsclients verwendet wird. Konsensclients haben jedoch auch eine RPC-API, mit der Benutzer Informationen über den Knoten abfragen sowie Beacon-Blöcke, Beacon-Zustand und andere konsensbezogene Informationen direkt von einem Knoten anfordern können. Diese API ist auf der Webseite [Beacon API](https://ethereum.github.io/beacon-APIs/#/) dokumentiert.
+Diese Seite befasst sich hauptsächlich mit der JSON-RPC-API, die von Ethereum-Ausführungsclients verwendet wird. Konsensclients haben jedoch auch eine RPC-API, mit der Benutzer Informationen über den Knoten abfragen sowie Beacon-Blöcke, Beacon-Zustand und andere konsensbezogene Informationen direkt von einem Knoten anfordern können. Diese API ist auf der [Beacon-API-Webseite](https://ethereum.github.io/beacon-APIs/#/) dokumentiert.
Es wird auch eine interne API für die Kommunikation zwischen Clients innerhalb eines Knotens verwendet, d. h. sie ermöglicht es dem Konsensclient und dem Ausführungsclient, Daten auszutauschen. Dies wird als „Engine API“ bezeichnet und die Spezifikationen sind auf [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) verfügbar.
-## Spezifikationen des Ausführungsclients {#spec}
+## Ausführungs-Client-Spezifikation {#spec}
-[ Lesen Sie die vollständige JSON-RPC-API-Spezifikation auf GitHub](https://github.com/ethereum/execution-apis). Diese API ist auf der [Execution API-Webseite](https://ethereum.github.io/execution-apis/api-documentation/) dokumentiert und enthält einen Inspector, mit dem Sie alle verfügbaren Methoden ausprobieren können.
+[Lesen Sie die vollständige JSON-RPC-API-Spezifikation auf GitHub](https://github.com/ethereum/execution-apis). Diese API ist auf der [Execution API Webseite](https://ethereum.github.io/execution-apis/) dokumentiert und enthält einen Inspector, um alle verfügbaren Methoden auszuprobieren.
## Konventionen {#conventions}
-### Hexadezimalwert-Kodierung {#hex-encoding}
+### Hex-Wert-Kodierung {#hex-encoding}
In JSON werden zwei Schlüssel-Datentypen übertragen: Roh-Byte-Arrays und Mengen. Beide werden mit einer Hex-Kodierung übertragen, haben jedoch unterschiedliche Anforderungen an das Format.
@@ -58,9 +58,9 @@ Hier sind einige Beispiele:
- FALSCH: 0xf0f0f (muss eine gerade Anzahl von Ziffern haben)
- FALSCH: 004200 (muss 0x als Präfix hinzufügen)
-### Der Standardblockparameter {#default-block}
+### Der Block-Parameter {#block-parameter}
-Die folgenden Methoden haben einen zusätzlichen Standardblockparameter:
+Die folgenden Methoden haben einen Blockparameter:
- [eth_getBalance](#eth_getbalance)
- [eth_getCode](#eth_getcode)
@@ -68,36 +68,36 @@ Die folgenden Methoden haben einen zusätzlichen Standardblockparameter:
- [eth_getStorageAt](#eth_getstorageat)
- [eth_call](#eth_call)
-Wenn Anfragen gestellt werden, die den Zustand von Ethereum beeinflussen, bestimmt der letzte Standardblockparameter die Höhe des Blocks.
+Wenn Anfragen gestellt werden, die den Status von Ethereum abfragen, bestimmt der angegebene Blockparameter die Höhe des Blocks.
-Folgende Optionen sind für den Standardblockparameter möglich:
+Für den Blockparameter sind folgende Optionen möglich:
-- `HEX String` - eine ganzzahlige Blocknummer
-- `String „frühestes“` für den frühesten/Genesis-Block
-- `String "latest"` – für den neuesten vorgeschlagenen Block
-- `String „sicher“` - für den neuesten sicheren Block
-- `String „finalisiert“` - für den neuesten finalisierten Block
-- `String „ausstehend“` - für den ausstehenden Zustand/Transaktionen
+- `HEX-String` – eine ganzzahlige Blocknummer
+- `String „earliest“` für den frühesten/Genesis-Block
+- `String „latest“` – für den letzten vorgeschlagenen Block
+- `String „safe“` – für den letzten sicheren Head-Block
+- `String „finalized“` – für den letzten finalisierten Block
+- `String „pending“` – für den ausstehenden Zustand/die ausstehenden Transaktionen
## Beispiele
-Auf dieser Seite stellen wir Beispiele dafür bereit, wie man einzelne JSON_RPC API-Endpunkte mit dem Befehlszeilenwerkzeug [curl](https://curl.se) verwendet. Diese Beispiele für einzelne Endpunkte finden sich im Abschnitt [Curl-Beispiele](#curl-examples) unten. Weiter unten auf der Seite stellen wir auch ein [End-to-End-Beispiel](#usage-example) bereit, wie man mithilfe eines Geth-Nodes, der JSON_RPC API und curl einen Smart Contract kompiliert und bereitstellt.
+Auf dieser Seite stellen wir Beispiele für die Verwendung einzelner JSON-RPC-API-Endpunkte mit dem Kommandozeilen-Tool [curl](https://curl.se) zur Verfügung. Diese Beispiele für einzelne Endpunkte finden Sie weiter unten im Abschnitt [Curl-Beispiele](#curl-examples). Weiter unten auf der Seite stellen wir außerdem ein [End-to-End-Beispiel](#usage-example) für das Kompilieren und Bereitstellen eines Smart Contracts unter Verwendung eines Geth-Nodes, der JSON-RPC-API und curl bereit.
## Curl-Beispiele {#curl-examples}
-Beispiele zur Verwendung der JSON_RPC-API durch Ausführen von [curl](https://curl.se)-Anfragen an einem Ethereum-Knoten werden unten bereitgestellt. Jedes Beispiel enthält eine Beschreibung des spezifischen Endpunkts, seiner Parameter, seines Rückgabetyps und ein Beispiel dafür, wie es verwendet werden sollte.
+Nachfolgend finden Sie Beispiele für die Verwendung der JSON-RPC-API durch Senden von [curl](https://curl.se)-Anfragen an einen Ethereum-Node. Jedes Beispiel enthält eine Beschreibung des spezifischen Endpunkts, seiner Parameter, seines Rückgabetyps und ein Beispiel dafür, wie es verwendet werden sollte.
-Es kann sein, dass die curl-Anfragen eine Fehlermeldung im Zusammenhang mit dem Inhaltstyp zurückgeben. Das liegt daran, dass die Option `--data` den Inhaltstyp auf `application/x-www-form-urlencoded` festlegt. Wenn Ihr Knoten sich darüber beschwert, setzen Sie den Header manuell, indem Sie am Anfang des Aufrufs `-H "Content-Type: application/json"` platzieren. In den Beispielen ist auch die URL/IP & Port-Kombination nicht enthalten, die als letztes Argument an curl übergeben werden muss (z. B. `127.0.0.1:8545`). Ein vollständiger curl-Aufruf, der diese zusätzlichen Daten enthält, hat folgende Form:
+Es kann sein, dass die curl-Anfragen eine Fehlermeldung im Zusammenhang mit dem Inhaltstyp zurückgeben. Das liegt daran, dass die Option `--data` den Inhaltstyp auf `application/x-www-form-urlencoded` setzt. Wenn Ihr Node sich darüber beschwert, setzen Sie den Header manuell, indem Sie `-H "Content-Type: application/json"` an den Anfang des Aufrufs stellen. Die Beispiele enthalten auch nicht die URL/IP- und Port-Kombination, die das letzte an curl übergebene Argument sein muss (z. B. `127.0.0.1:8545`). Ein vollständiger curl-Aufruf, der diese zusätzlichen Daten enthält, hat folgende Form:
```shell
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
```
-## Kommunikation, Zustand, Verlauf {#gossip-state-history}
+## Gossip, Zustand, Verlauf {#gossip-state-history}
-Eine Handvoll Kernmethoden von JSON-RPC erfordern Daten aus dem Ethereum-Netzwerk und gehören in drei Hauptkategorien: _Kommunikation, Zustand, Verlauf_. Verwenden Sie die Links in diesen Abschnitten, um zu jeder Methode zu springen, oder verwenden Sie das Inhaltsverzeichnis, um die gesamte Liste der Methoden zu durchsuchen.
+Eine Handvoll zentraler JSON-RPC-Methoden erfordern Daten aus dem Ethereum-Netzwerk und lassen sich in drei Hauptkategorien einteilen: _Gossip, Zustand und Verlauf_. Verwenden Sie die Links in diesen Abschnitten, um zu jeder Methode zu springen, oder verwenden Sie das Inhaltsverzeichnis, um die gesamte Liste der Methoden zu durchsuchen.
-### Kommunikationsmethoden {#gossip-methods}
+### Gossip-Methoden {#gossip-methods}
> Diese Methoden verfolgen die Spitze der Blockchain. Das ist der Weg, wie Transaktionen sich im Netzwerk verbreiten, in Blöcke aufgenommen werden und wie Clients von neuen Blöcken erfahren.
@@ -136,26 +136,26 @@ Eine Handvoll Kernmethoden von JSON-RPC erfordern Daten aus dem Ethereum-Netzwer
Sie können das [Playground-Tool](https://ethereum-json-rpc.com) verwenden, um die API-Methoden zu entdecken und auszuprobieren. Es zeigt Ihnen auch, welche Methoden und Netzwerke von verschiedenen Knotenanbietern unterstützt werden.
-## JSON-RPC API-Methoden {#json-rpc-methods}
+## JSON-RPC-API-Methoden {#json-rpc-methods}
-### web3_ClientVersion {#web3_clientversion}
+### web3_clientVersion {#web3_clientversion}
Gibt die aktuelle Client-Version zurück.
**Parameter**
-Keine
+Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`String` - Die aktuelle Client-Version
+`String` – Die aktuelle Client-Version
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
-// Result
+// Ergebnis
{
"id":67,
"jsonrpc":"2.0",
@@ -165,26 +165,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],
### web3_sha3 {#web3_sha3}
-Gibt Keccak-256 (_nicht_ der standardisierte SHA3-256) von den gegebenen Daten zurück.
+Gibt den Keccak-256 (_nicht_ den standardisierten SHA3-256) der angegebenen Daten zurück.
**Parameter**
-1. `DATA` – die Daten, die in einen SHA3-Hash konvertiert werden sollen
+1. `DATA` – Die Daten, die in einen SHA3-Hash umgewandelt werden sollen
```js
params: ["0x68656c6c6f20776f726c64"]
```
-**Rückgabewert**
+**Rückgabewerte**
-`DATA` - Das SHA3-Ergebnis des gegebenen Strings.
+`DATA` – Das SHA3-Ergebnis des angegebenen Strings.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
-// Result
+// Ergebnis
{
"id":64,
"jsonrpc": "2.0",
@@ -198,24 +198,24 @@ Gibt die aktuelle Netzwerk-ID zurück.
**Parameter**
-Keine
+Keine (None)
-**Rückgabewert**
+**Rückgabewerte**
-`String` - Die aktuelle Netzwerk-ID.
+`String` – Die aktuelle Netzwerk-ID.
-Die vollständige Liste der aktuellen Netzwerk-IDs ist verfügbar unter [chainlist.org](https://chainlist.org). Einige häufige sind:
+Die vollständige Liste der aktuellen Netzwerk-IDs ist unter [chainlist.org](https://chainlist.org) verfügbar. Einige häufige sind:
- `1`: Ethereum Mainnet
-- `11155111`: Sepolia Testnetz
-- `560048` : Hoodi Testnetz
+- `11155111`: Sepolia Testnet
+- `560048` : Hoodi-Testnet
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
-// Result
+// Ergebnis
{
"id":67,
"jsonrpc": "2.0",
@@ -225,22 +225,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67
### net_listening {#net_listening}
-Gibt `true` zurück, wenn der Client aktiv auf Netzwerkverbindungen hört.
+Gibt `true` zurück, wenn der Client aktiv auf Netzwerkverbindungen lauscht.
**Parameter**
-Keine
+Keine (None)
-**Rückgabewert**
+**Rückgabewerte**
-`Boolean` - `true`, wenn zuhörend, ansonsten `false`.
+`Boolean` – `true`, wenn gelauscht wird, andernfalls `false`.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
-// Result
+// Ergebnis
{
"id":67,
"jsonrpc":"2.0",
@@ -254,18 +254,18 @@ Gibt die Anzahl der aktuell mit dem Client verbundenen Peers zurück.
**Parameter**
-Keine
+Keine (None)
-**Rückgabewert**
+**Rückgabewerte**
-`QUANTITY` - Ganzzahlwert, der die Anzahl der verbundenen Peers repräsentiert.
+`QUANTITY` – Ganzzahl der Anzahl der verbundenen Peers.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
-// Result
+// Ergebnis
{
"id":74,
"jsonrpc": "2.0",
@@ -275,22 +275,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":
### eth_protocolVersion {#eth_protocolversion}
-Gibt die aktuelle Ethereum-Protokollversion zurück. Beachten Sie, dass diese Methode [nicht in Geth verfügbar](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924) ist.
+Gibt die aktuelle Ethereum-Protokollversion zurück. Beachten Sie, dass diese Methode in [Geth nicht verfügbar ist](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924).
**Parameter**
-Keine
+Keine (None)
-**Rückgabewert**
+**Rückgabewerte**
-`String` - Die aktuelle Ethereum-Protokollversion
+`String` – Die aktuelle Ethereum-Protokollversion
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
-// Result
+// Ergebnis
{
"id":67,
"jsonrpc": "2.0",
@@ -300,21 +300,25 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[]
### eth_syncing {#eth_syncing}
-Gibt ein Objekt mit Daten zum Synchronisierungsstatus oder `false` zurück.
+Gibt ein Objekt mit Daten über den Synchronisierungsstatus oder `false` zurück.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
-Keine
+Keine (None)
-**Rückgabewert**
+**Rückgabewerte**
-Die genauen Rückgabedaten variieren je nach Client-Implementierung. Alle Clients geben `False` zurück, wenn der Knoten nicht synchronisiert wird, und alle Clients geben die nachfolgenden Felder zurück.
+Die genauen Rückgabedaten variieren je nach Client-Implementierung. Alle Clients geben `False` zurück, wenn der Node nicht synchronisiert wird, und alle Clients geben die folgenden Felder zurück.
-`Object|Boolean` – ein Objekt mit Synchronisierungsstatus-Daten oder `FALSE`, wenn nicht synchronisiert wird:
+`Object|Boolean`, Ein Objekt mit Synchronisierungsstatusdaten oder `FALSE`, wenn nicht synchronisiert wird:
-- `startingBlock`: `QUANTITY` - Der Block, bei dem der Import begonnen hat (wird nur zurückgesetzt, nachdem die Synchronisierung ihren Kopf erreicht hat)
-- `currentBlock`: `QUANTITY` - Der aktuelle Block, identisch zu eth_blockNumber
-- `highestBlock`: `QUANTITY` - Der geschätzte höchste Block
+- `startingBlock`: `QUANTITY` – Der Block, bei dem der Import gestartet wurde (wird erst zurückgesetzt, nachdem die Synchronisierung ihren Head erreicht hat)
+- `currentBlock`: `QUANTITY` – Der aktuelle Block, wie bei eth_blockNumber
+- `highestBlock`: `QUANTITY` – Der geschätzte höchste Block
Die einzelnen Clients können jedoch auch zusätzliche Daten liefern. Beispielsweise gibt Geth Folgendes zurück:
@@ -362,9 +366,9 @@ Weitere Einzelheiten finden Sie in der Dokumentation zu Ihrem jeweiligen Client.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -374,7 +378,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
highestBlock: '0x454'
}
}
-// Or when not syncing
+// Oder wenn nicht synchronisiert wird
{
"id":1,
"jsonrpc": "2.0",
@@ -386,20 +390,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
Gibt die Coinbase-Adresse des Clients zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
+> **Hinweis:** Diese Methode ist seit **v1.14.0** veraltet und wird nicht mehr unterstützt. Der Versuch, diese Methode zu verwenden, führt zu dem Fehler „Method not supported“.
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`DATA`, 20 Byte – die aktuelle Coinbase-Adresse.
+`DATA`, 20 Bytes – die aktuelle Coinbase-Adresse.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}'
-// Result
+// Ergebnis
{
"id":64,
"jsonrpc": "2.0",
@@ -411,20 +421,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6
Gibt die Ketten-ID zurück, die für das Unterzeichnen der Replay-geschützten Transaktionen verwendet wird.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`chainId` – Hexadezimalwert als String, der die Ganzzahl der aktuellen Ketten-ID repräsentiert.
+`chainId`, Hexadezimalwert als String, der die Ganzzahl der aktuellen Ketten-ID darstellt.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}'
-// Result
+// Ergebnis
{
"id":67,
"jsonrpc": "2.0",
@@ -434,20 +448,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
### eth_mining {#eth_mining}
-Gibt `true` zurück, wenn der Client aktiv neue Blöcke mint. Dies kann für Proof-of-Work-Netzwerke nur `true` zurückgeben und ist möglicherweise seit [der Zusammenführung](/roadmap/merge/) in einigen Clients nicht mehr verfügbar.
+Gibt `true` zurück, wenn der Client aktiv neue Blöcke schürft. Dies kann nur bei Proof-of-Work-Netzwerken `true` zurückgeben und ist bei einigen Clients seit [The Merge](/roadmap/merge/) möglicherweise nicht mehr verfügbar.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`Boolean` – gibt `true` zurück, wenn der Client aktiv mint, andernfalls `false`.
+`Boolean` – gibt `true` zurück, wenn der Client schürft, andernfalls `false`.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
//
{
@@ -459,22 +477,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
### eth_hashrate {#eth_hashrate}
-Gibt die Anzahl der Hashes pro Sekunde zurück, mit der der Knoten mint. Dies kann für Proof-of-Work-Netzwerke nur `true` zurückgeben und ist möglicherweise seit [der Zusammenführung](/roadmap/merge/) in einigen Clients nicht mehr verfügbar.
+Gibt die Anzahl der Hashes pro Sekunde zurück, mit der der Knoten mint. Dies kann nur bei Proof-of-Work-Netzwerken `true` zurückgeben und ist bei einigen Clients seit [The Merge](/roadmap/merge/) möglicherweise nicht mehr verfügbar.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
`QUANTITY` – Anzahl der Hashes pro Sekunde.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}'
-// Result
+// Ergebnis
{
"id":71,
"jsonrpc": "2.0",
@@ -486,20 +508,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7
Gibt eine Schätzung des aktuellen Preises pro Gas in Wei zurück. Der Besu-Client prüft beispielsweise die letzten 100 Blöcke und gibt standardmäßig den mittleren Preis pro Gas-Einheit zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`QUANTITY` – Ganzzahl des aktuellen Gas-Preises in Wei.
+`QUANTITY` – Ganzzahl des aktuellen Gaspreises in Wei.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
-// Result
+// Ergebnis
{
"id":73,
"jsonrpc": "2.0",
@@ -511,20 +537,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7
Gibt eine Liste von Adressen zurück, die dem Client gehören.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`Array of DATA`, 20 Byte – Adressen, die dem Client gehören.
+`Array von DATA`, 20 Bytes – Adressen, die dem Client gehören.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -534,22 +564,26 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
### eth_blockNumber {#eth_blocknumber}
-Gibt die Zahl des aktuellsten Blocks zurück.
+Gibt die Nummer des neuesten Blocks zurück.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
Keine (None)
-**Rückgaben**
+**Rückgabewerte**
-`QUANTITY` – Ganzzahl der Blocknummer, auf der sich der Client derzeit befindet.
+`QUANTITY` – Ganzzahl der aktuellen Blocknummer, auf der sich der Client befindet.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}'
-// Result
+// Ergebnis
{
"id":83,
"jsonrpc": "2.0",
@@ -559,27 +593,31 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id
### eth_getBalance {#eth_getbalance}
-Gibt das Guthaben des Kontos einer bestimmten Adresse zurück.
+Gibt das Guthaben des Kontos an einer bestimmten Adresse zurück.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
-1. `DATA`, 20 Bytes - Adresse, deren Guthaben überprüft werden soll.
-2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`, 20 Bytes – Adresse, deren Guthaben geprüft werden soll.
+2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe den [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
```
-**Rückgaben**
+**Rückgabewerte**
-`QUANTITY` – Ganzzahl für den aktuellen Saldo in Wei.
+`QUANTITY` – Ganzzahl des aktuellen Guthabens in Wei.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -591,30 +629,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407
Gibt den Wert aus einer Speicherposition an einer angegebenen Adresse zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 20 Bytes - Adresse des Speichers.
-2. `QUANTITY` - Ganzzahlwert der Position im Speicher.
-3. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, siehe [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`, 20 Bytes – Adresse des Speichers.
+2. `QUANTITY` – Ganzzahl der Position im Speicher.
+3. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe den [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter)
-**Rückgaben**
+**Rückgabewerte**
`DATA` – der Wert an dieser Speicherposition.
-**Beispiel:** Die Berechnung der richtigen Position hängt vom abzurufenden Speicher ab. Betrachten Sie den folgenden Contract, der unter `0x295a70b2de5e3953354a6a8344e616ed314d7251` von der Adresse `0x391694e7e0b0cce554cb130d723a9d27458f9298` bereitgestellt wurde.
+**Beispiel**
+Die Berechnung der korrekten Position hängt vom abzurufenden Speicher ab. Betrachten Sie den folgenden Contract, der unter `0x295a70b2de5e3953354a6a8344e616ed314d7251` von der Adresse `0x391694e7e0b0cce554cb130d723a9d27458f9298` bereitgestellt wurde.
```
contract Storage {
uint pos0;
mapping(address => uint) pos1;
- function Storage() {
+ constructor() {
pos0 = 1234;
pos1[msg.sender] = 5678;
}
}
```
-Das Abrufen des Wertes von pos0 ist simpel:
+Das Abrufen des Wertes von pos0 ist einfach:
```js
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
@@ -658,28 +701,32 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [
Gibt die Anzahl der von einer Adresse _gesendeten_ Transaktionen zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 20 Bytes - Adresse.
-2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`, 20 Bytes – Adresse.
+2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe den [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
"0x407d73d8a49eeb85d32cf465507dd71d507100c1",
- "latest", // state at the latest block
+ "latest", // Zustand des neuesten Blocks
]
```
-**Rückgaben**
+**Rückgabewerte**
`QUANTITY` – Ganzzahl der Anzahl der von dieser Adresse gesendeten Transaktionen.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -691,15 +738,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params
Gibt die Anzahl der Transaktionen in einem Block zurück, von einem Block, der dem angegebenen Block-Hash entspricht.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 32 Bytes - Hash eines Blocks
+1. `DATA`, 32 Bytes – Hash eines Blocks
```js
params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
```
-**Rückgaben**
+**Rückgabewerte**
`QUANTITY` – Ganzzahl der Anzahl der Transaktionen in diesem Block.
@@ -720,9 +771,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa
Gibt die Anzahl der Transaktionen in einem Block zurück, der der angegebenen Blocknummer entsprechen.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `QUANTITY|TAG` – Ganzzahl einer Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block).
+1. `QUANTITY|TAG` – eine Ganzzahl einer Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter).
```js
params: [
@@ -730,7 +785,7 @@ params: [
]
```
-**Rückgaben**
+**Rückgabewerte**
`QUANTITY` – Ganzzahl der Anzahl der Transaktionen in diesem Block.
@@ -751,17 +806,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu
Gibt die Anzahl der Onkel in einem Block zurück, der dem angegebenen Block-Hash entspricht.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 32 Bytes - Hash eines Blocks
+1. `DATA`, 32 Bytes – Hash eines Blocks
```js
params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
```
-**Rückgaben**
+**Rückgabewerte**
-`QUANTITY` – Ganzzahl für die Anzahl der Onkel in diesem Block.
+`QUANTITY` – Ganzzahl der Anzahl der Uncles in diesem Block.
**Beispiel**
@@ -780,9 +839,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p
Gibt die Anzahl der Onkel in einem Block zurück, der der angegebenen Blocknummer entspricht.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `QUANTITY|TAG` – Ganzzahl einer Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block)
+1. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe den [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -790,9 +853,9 @@ params: [
]
```
-**Rückgaben**
+**Rückgabewerte**
-`QUANTITY` – Ganzzahl für die Anzahl der Onkel in diesem Block.
+`QUANTITY` – Ganzzahl der Anzahl der Uncles in diesem Block.
**Beispiel**
@@ -811,10 +874,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber",
Gibt den Code an einer angegebenen Adresse zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 20 Bytes - Adresse
-2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block)
+1. `DATA`, 20 Bytes – Adresse
+2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe den [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -823,7 +890,7 @@ params: [
]
```
-**Rückgaben**
+**Rückgabewerte**
`DATA` – der Code von der angegebenen Adresse.
@@ -842,27 +909,27 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA
### eth_sign {#eth_sign}
-Die Unterzeichnungsmethode berechnet eine Ethereum-spezifische Signatur mit: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
+Die sign-Methode berechnet eine Ethereum-spezifische Signatur mit: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
-Durch das Hinzufügen eines Präfixes zur Nachricht wird die berechnete Signatur als Ethereum-spezifische Signatur erkennbar. Das verhindert Missbrauch, bei dem eine bösartige dApp beliebige Daten (z. B. Transaktionen) signieren und die Signatur nutzen kann, um sich als das Opfer auszugeben.
+Durch das Hinzufügen eines Präfixes zur Nachricht wird die berechnete Signatur als Ethereum-spezifische Signatur erkennbar. Dies verhindert einen Missbrauch, bei dem eine böswillige Dapp beliebige Daten (z. B. eine Transaktion) signieren und die Signatur verwenden kann, um sich als das Opfer auszugeben.
Hinweis: Die zum Signieren verwendete Adresse muss entsperrt sein.
**Parameter**
-1. `DATA`, 20 Bytes - Adresse
-2. `DATA`, N Bytes - Nachricht zum Signieren
+1. `DATA`, 20 Bytes – Adresse
+2. `DATA`, N Bytes – zu signierende Nachricht
-**Rückgaben**
+**Rückgabewerte**
`DATA`: Signatur
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -872,31 +939,31 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37
### eth_signTransaction {#eth_signtransaction}
-Signiert eine Transaktion, die zu einem späteren Zeitpunkt an das Netzwerk gesendet werden kann, indem sie mit [eth_sendRawTransaction](#eth_sendrawtransaction) verwendet wird.
+Signiert eine Transaktion, die zu einem späteren Zeitpunkt mit [eth_sendRawTransaction](#eth_sendrawtransaction) an das Netzwerk übermittelt werden kann.
**Parameter**
-1. `Objekt` - Das Transaktionsobjekt
+1. `Object` – Das Transaktionsobjekt
- `type`:
-- `from`: `DATA`, 20 Bytes - Die Adresse, von der die Transaktion gesendet wird.
-- `to`: `DATA`, 20 Bytes - (Optional beim Erstellen eines neuen Vertrags) Die Adresse, an die die Transaktion gerichtet ist.
-- `gas`: `MENGE` - (Optional, Standard: 90000) Ganzzahlwert des Gases, das für die Transaktionsausführung bereitgestellt wurde. Es wird ungenutztes Gas zurückgegeben.
-- `gasPrice`: `QUANTITY` – (optional, Standard: noch zu bestimmen) Ganzzahl von gasPrice, die für jedes bezahlte Gas verwendet wird, in Wei.
-- `value`: `QUANTITY` – (optional) Ganzzahl des Werts, der mit dieser Transaktion gesendet wird, in Wei.
-- `data`: `DATA` - Der kompilierte Code eines Vertrags ODER der Hash der aufgerufenen Methode Signatur und kodierter Parameter.
-- `nonce`: `QUANTITY` - (Optional) Ganzzahlwert einer Nonce. Dies ermöglicht es, eigene ausstehende Transaktionen mit der gleichen Nonce zu überschreiben.
+- `from`: `DATA`, 20 Bytes – Die Adresse, von der die Transaktion gesendet wird.
+- `to`: `DATA`, 20 Bytes – (optional bei der Erstellung eines neuen Vertrags) Die Adresse, an die die Transaktion gerichtet ist.
+- `gas`: `QUANTITY` – (optional, Standard: 90000) Ganzzahl des für die Transaktionsausführung bereitgestellten Gases. Es wird ungenutztes Gas zurückgegeben.
+- `gasPrice`: `QUANTITY` – (optional, Standard: wird noch festgelegt) Ganzzahl des Gaspreises, der für jedes bezahlte Gas in Wei verwendet wird.
+- `value`: `QUANTITY` – (optional) Ganzzahl des mit dieser Transaktion gesendeten Werts in Wei.
+- `data`: `DATA` – Der kompilierte Code eines Vertrags ODER der Hash der aufgerufenen Methodensignatur und der kodierten Parameter.
+- `nonce`: `QUANTITY` – (optional) Ganzzahl einer Nonce. Dies ermöglicht es, eigene ausstehende Transaktionen mit der gleichen Nonce zu überschreiben.
-**Rückgaben**
+**Rückgabewerte**
-`DATA` – das RLP-codierte Transaktionsobjekt, das vom angegebenen Konto signiert wurde.
+`DATA`, Das RLP-kodierte Transaktionsobjekt, das vom angegebenen Konto signiert wurde.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}'
-// Result
+// Ergebnis
{
"id": 1,
"jsonrpc": "2.0",
@@ -906,19 +973,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","
### eth_sendTransaction {#eth_sendtransaction}
-Erstellt eine neue Nachrichtenanruftransaktion oder eine Contract-Erstellung, wenn das Datenfeld Code enthält, und signiert sie mit dem im `from`-Feld angegebenen Konto.
+Erstellt eine neue Nachrichtenaufruf-Transaktion oder eine Vertragserstellung, wenn das Datenfeld Code enthält, und signiert sie mit dem in `from` angegebenen Konto.
**Parameter**
-1. `Objekt` - Das Transaktionsobjekt
+1. `Object` – Das Transaktionsobjekt
-- `from`: `DATA`, 20 Bytes - Die Adresse, von der die Transaktion gesendet wird.
-- `to`: `DATA`, 20 Bytes - (Optional beim Erstellen eines neuen Vertrags) Die Adresse, an die die Transaktion gerichtet ist.
-- `gas`: `MENGE` - (Optional, Standard: 90000) Ganzzahlwert des Gases, das für die Transaktionsausführung bereitgestellt wurde. Es wird ungenutztes Gas zurückgegeben.
-- `gasprice`: `QUANTITY` – (Optional, Standard: Noch zu bestimmen) Ganzzahlwert des Gaspreises, der für jedes bezahlte Gas verwendet wird.
-- `Value`: `QUANTITY` - (Optional) Ganzzahlwert des mit dieser Transaktion gesendeten Werts.
-- `input`: `DATA` – der kompilierte Code eines Contracts ODER der Hash der aufgerufenen Methodensignatur und der codierten Parameter.
-- `nonce`: `QUANTITY` - (Optional) Ganzzahlwert einer Nonce. Dies ermöglicht es, eigene ausstehende Transaktionen mit der gleichen Nonce zu überschreiben.
+- `from`: `DATA`, 20 Bytes – Die Adresse, von der die Transaktion gesendet wird.
+- `to`: `DATA`, 20 Bytes – (optional bei der Erstellung eines neuen Vertrags) Die Adresse, an die die Transaktion gerichtet ist.
+- `gas`: `QUANTITY` – (optional, Standard: 90000) Ganzzahl des für die Transaktionsausführung bereitgestellten Gases. Es wird ungenutztes Gas zurückgegeben.
+- `gasPrice`: `QUANTITY` – (optional, Standard: wird noch festgelegt) Ganzzahl des Gaspreises, der für jedes bezahlte Gas verwendet wird.
+- `value`: `QUANTITY` – (optional) Ganzzahl des mit dieser Transaktion gesendeten Werts.
+- `input`: `DATA` – Der kompilierte Code eines Vertrags ODER der Hash der aufgerufenen Methodensignatur und der kodierten Parameter.
+- `nonce`: `QUANTITY` – (optional) Ganzzahl einer Nonce. Dies ermöglicht es, eigene ausstehende Transaktionen mit der gleichen Nonce zu überschreiben.
```js
params: [
@@ -934,18 +1001,18 @@ params: [
]
```
-**Rückgaben**
+**Rückgabewerte**
-`DATA`, 32 Byte – der Transaktions-Hash oder der Null-Hash, wenn die Transaktion noch nicht verfügbar ist.
+`DATA`, 32 Bytes – der Transaktionshash oder der Null-Hash, wenn die Transaktion noch nicht verfügbar ist.
-Verwenden Sie [eth_getTransactionReceipt](#eth_gettransactionreceipt), um die Contract-Adresse zu erhalten, nachdem die Transaktion in einem Block vorgeschlagen wurde, wenn Sie einen Contract erstellt haben.
+Verwenden Sie [eth_getTransactionReceipt](#eth_gettransactionreceipt), um die Vertragsadresse zu erhalten, nachdem die Transaktion in einem Block vorgeschlagen wurde, als Sie einen Vertrag erstellt haben.
**Beispiel**
```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}'
-// Result
+// Anfrage
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{siehe oben}],"id":1}'
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -967,18 +1034,18 @@ params: [
]
```
-**Rückgaben**
+**Rückgabewerte**
-`DATA`, 32 Byte – der Transaktions-Hash oder der Null-Hash, wenn die Transaktion noch nicht verfügbar ist.
+`DATA`, 32 Bytes – der Transaktionshash oder der Null-Hash, wenn die Transaktion noch nicht verfügbar ist.
-Verwenden Sie [eth_getTransactionReceipt](#eth_gettransactionreceipt), um die Contract-Adresse zu erhalten, nachdem die Transaktion in einem Block vorgeschlagen wurde, wenn Sie einen Contract erstellt haben.
+Verwenden Sie [eth_getTransactionReceipt](#eth_gettransactionreceipt), um die Vertragsadresse zu erhalten, nachdem die Transaktion in einem Block vorgeschlagen wurde, als Sie einen Vertrag erstellt haben.
**Beispiel**
```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}'
-// Result
+// Anfrage
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{siehe oben}],"id":1}'
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -988,31 +1055,35 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params"
### eth_call {#eth_call}
-Führt sofort einen neuen Nachrichtenaufruf aus, ohne eine Transaktion auf der Blockchain zu erstellen. Wird häufig für die Ausführung von Smart-Contract-Funktionen mit Leseberechtigung verwendet, zum Beispiel `balanceOf` für einen ERC-20-Contract.
+Führt einen neuen Message Call sofort aus, ohne eine Transaktion auf der Blockchain zu erstellen. Wird oft für die Ausführung schreibgeschützter Smart-Contract-Funktionen verwendet, zum Beispiel `balanceOf` für einen ERC-20-Vertrag.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
-1. `Object` - Das Transaktionsaufrufobjekt
+1. `Object` – Das Transaktionsaufruf-Objekt
-- `from`: `DATA`, 20 Bytes - (Optional) Die Adresse, von der die Transaktion gesendet wird.
+- `from`: `DATA`, 20 Bytes – (optional) Die Adresse, von der die Transaktion gesendet wird.
- `to`: `DATA`, 20 Bytes – Die Adresse, an die die Transaktion gerichtet ist.
-- `gas`: `QUANTITY` - (Optional) Ganzzahlwert des für die Transaktionsausführung bereitgestellten Gases. eth_call verbraucht kein Gas, aber dieser Parameter kann von einigen Ausführungen benötigt werden.
-- `gasprice`: `QUANTITY` - (Optional) Ganzzahlwert des Gaspreises, der für jedes bezahlte Gas verwendet wird
-- `value`: `QUANTITY` - (Optional) Ganzzahlwert des mit dieser Transaktion gesendeten Werts
-- `input`: `DATA` – (optional) Hash der Methodensignatur und der codierten Parameter. Einzelheiten finden Sie unter [Ethereum-Contract-ABI in der Solidity-Dokumentation](https://docs.soliditylang.org/en/latest/abi-spec.html).
+- `gas`: `QUANTITY` – (optional) Ganzzahl des für die Transaktionsausführung bereitgestellten Gases. eth_call verbraucht kein Gas, aber dieser Parameter kann von einigen Ausführungen benötigt werden.
+- `gasPrice`: `QUANTITY` – (optional) Ganzzahl des für jedes bezahlte Gas verwendeten Gaspreises.
+- `value`: `QUANTITY` – (optional) Ganzzahl des mit dieser Transaktion gesendeten Werts.
+- `input`: `DATA` – (optional) Hash der Methodensignatur und der kodierten Parameter. Details hierzu finden Sie unter [Ethereum Contract ABI in der Solidity-Dokumentation](https://docs.soliditylang.org/en/latest/abi-spec.html).
-2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITY|TAG` – ganzzahlige Blocknummer oder der String `"latest"`, `"earliest"`, `"pending"`, `"safe"` oder `"finalized"`, siehe den [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter)
-**Rückgaben**
+**Rückgabewerte**
-`DATA` – der Rückgabewert des ausgeführten Vertrages.
+`DATA` – der Rückgabewert des ausgeführten Vertrags.
**Beispiel**
```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}'
-// Result
+// Anfrage
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{siehe oben}],"id":1}'
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -1024,20 +1095,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}]
Generiert und gibt eine Schätzung zurück, wie viel Gas erforderlich ist, damit die Transaktion abgeschlossen werden kann. Die Transaktion wird nicht zur Blockchain hinzugefügt. Beachten Sie, dass die Schätzung aus verschiedenen Gründen, einschließlich der EVM-Mechanik und der Leistung des Knotens, erheblich höher sein kann als die tatsächlich von der Transaktion verbrauchte Gas-Menge.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-Siehe [eth_call](#eth_call)-Parameter – mit der Ausnahme, dass alle Eigenschaften optional sind. Wenn kein Gas-Limit angegeben ist, verwendet Geth das Block-Gas-Limit aus dem anstehenden Block als Obergrenze. Infolgedessen reicht die zurückgegebene Schätzung möglicherweise nicht aus, um die Abfrage/Transaktion auszuführen, wenn die Gas-Menge höher als das ausstehende Block-Gas-Limit ist.
+Siehe [eth_call](#eth_call) Parameter, außer dass alle Eigenschaften optional sind. Wenn kein Gas-Limit angegeben ist, verwendet Geth das Block-Gas-Limit aus dem anstehenden Block als Obergrenze. Daher reicht die zurückgegebene Schätzung möglicherweise nicht aus, um den Aufruf/die Transaktion auszuführen, wenn die Gasmenge höher ist als das Gaslimit des ausstehenden Blocks.
-**Rückgaben**
+**Rückgabewerte**
-`QUANTITY` – die verbrauchte Gas-Menge.
+`QUANTITY` – die Menge des verbrauchten Gases.
**Beispiel**
```js
-// Request
-curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
-// Result
+// Anfrage
+curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{siehe oben}],"id":1}'
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -1049,10 +1124,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see
Gibt Informationen zu einem Block per Hash zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 32 Bytes - Hash eines Blocks.
-2. `Boolean` - Bei `true` werden die vollständigen Transaktionsobjekte zurückgegeben, bei `false` nur die Hashes der Transaktionen.
+1. `DATA`, 32 Bytes – Hash eines Blocks.
+2. `Boolean` – Wenn `true`, werden die vollständigen Transaktionsobjekte zurückgegeben, wenn `false`, nur die Hashes der Transaktionen.
```js
params: [
@@ -1061,41 +1140,40 @@ params: [
]
```
-**Rückgaben**
+**Rückgabewerte**
-`Object` – ein Blockobjekt oder `null`, wenn kein Block gefunden wurde:
+`Object` – Ein Block-Objekt oder `null`, wenn kein Block gefunden wurde:
-- `number`: `QUANTITY` - Die Blocknummer. `null`, wenn es ein ausstehender Block ist.
-- `hash`: `DATA`, 32 Bytes - Hash des Blocks. `null`, wenn es ein ausstehender Block ist.
-- `parentHash`: `DATA`, 32 Bytes - Hash des übergeordneten Blocks.
-- `nonce`: `DATA`, 8 Bytes - Hash des generierten Proof-of-Work. `null`, wenn es ein ausstehender Block ist.
-- `sha3Uncles`: `DATA`, 32 Bytes - SHA3 der Onkeldaten im Block.
-- `logsBloom`: `DATA`, 256 Bytes - Der Bloom-Filter für die Protokolle des Blocks. `null`, wenn es ein ausstehender Block ist.
-- `TransaktionsRoot`: `DATA`, 32 Bytes - Das Stammverzeichnis der Transaktions-Trie des Blocks.
+- `number`: `QUANTITY` – die Blocknummer. `null`, wenn es ein ausstehender Block ist.
+- `hash`: `DATA`, 32 Bytes – Hash des Blocks. `null`, wenn es ein ausstehender Block ist.
+- `parentHash`: `DATA`, 32 Bytes – Hash des übergeordneten Blocks.
+- `nonce`: `DATA`, 8 Bytes – Hash des generierten Proof-of-Work. `null`, wenn es ein ausstehender Block ist, `0x0` für Proof-of-Stake-Blöcke (seit The Merge)
+- `sha3Uncles`: `DATA`, 32 Bytes – SHA3 der Uncle-Daten im Block.
+- `logsBloom`: `DATA`, 256 Bytes – der Bloom-Filter für die Protokolle des Blocks. `null`, wenn es ein ausstehender Block ist.
+- `transactionsRoot`: `DATA`, 32 Bytes – die Wurzel des Transaktions-Trie des Blocks.
- `stateRoot`: `DATA`, 32 Bytes – Die Wurzel des endgültigen Zustands-Trie des Blocks.
-- `receiptsRoot`: `DATA`, 32 Bytes - Die Wurzel des Quittungstries des Blocks.
-- `miner`: `DATA`, 20 Byte – die Adresse des Begünstigten, dem die Mining-Belohnungen gegeben wurden.
-- `difficulty`: `QUANTITY` - Ganzzahlwert der Schwierigkeit für diesen Block.
-- `totalDifficulty`: `QUANTITY` - Ganzzahlwert der Gesamtschwierigkeit der Blockchain bis zu diesem Block.
-- `extraData`: `DATA` - Das Feld „zusätzliche Daten“ dieses Blocks.
-- `size`: `QUANTITY` - Ganzzahlwert der Größe dieses Blocks in Bytes.
-- `gasLimit`: `QUANTITY` - Das maximal zulässige Gas in diesem Block.
-- `gasUsed`: `QUANTITY` - Das insgesamt von allen Transaktionen in diesem Block verbrauchte Gas.
-- `timestamp`: `QUANTITY` - Der Unix-Zeitstempel für den Zeitpunkt, zu dem der Block sortiert wurde.
+- `receiptsRoot`: `DATA`, 32 Bytes – die Wurzel des Beleg-Trie des Blocks.
+- `miner`: `DATA`, 20 Bytes – die Adresse des Begünstigten, der die Block-Belohnungen erhalten hat.
+- `difficulty`: `QUANTITY` – Ganzzahl der für diesen Block erforderlichen Rechenleistung.
+- `totalDifficulty`: `QUANTITY` – Ganzzahl der gesamten Rechenleistung der Kette bis zu diesem Block.
+- `extraData`: `DATA` – das „extra data“-Feld dieses Blocks.
+- `size`: `QUANTITY` – Ganzzahl der Größe dieses Blocks in Bytes.
+- `gasLimit`: `QUANTITY` – das maximal zulässige Gas in diesem Block.
+- `gasUsed`: `QUANTITY` – das insgesamt von allen Transaktionen in diesem Block verbrauchte Gas.
+- `timestamp`: `QUANTITY` – der Unix-Zeitstempel, zu dem der Block zusammengestellt wurde.
- `transactions`: `Array` – Array von Transaktionsobjekten oder 32-Byte-Transaktions-Hashes, abhängig vom zuletzt angegebenen Parameter.
-- `uncles`: `Array` - Array von Onkel-Hashes.
+- `uncles`: `Array` – Array von Uncle-Hashes.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
-// Result
-{
+// Ergebnis
{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
"difficulty": "0x4ea3f27bc",
"extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
"gasLimit": "0x1388",
@@ -1118,7 +1196,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
"transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
"uncles": [
]
-}
+ }
}
```
@@ -1126,10 +1204,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
Gibt Informationen über eine Block-für-Block-Nummer zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `QUANTITY|TAG` – Ganzzahl einer Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block).
-2. `Boolean` - Bei `true` werden die vollständigen Transaktionsobjekte zurückgegeben, bei `false` nur die Hashes der Transaktionen.
+1. `QUANTITY|TAG` – eine Ganzzahl einer Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter).
+2. `Boolean` – Wenn `true`, werden die vollständigen Transaktionsobjekte zurückgegeben, wenn `false`, nur die Hashes der Transaktionen.
```js
params: [
@@ -1138,12 +1220,13 @@ params: [
]
```
-**Rückgaben** Siehe [eth_getBlockByHash](#eth_getblockbyhash)
+**Rückgabewerte**
+Siehe [eth_getBlockByHash](#eth_getblockbyhash)
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}'
```
@@ -1153,39 +1236,43 @@ Ergebnis siehe [eth_getBlockByHash](#eth_getblockbyhash)
Gibt die Informationen über eine Transaktion zurück, die anhand des Transaktions-Hashs angefordert wurde.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 32 Bytes - Hash einer Transaktion
+1. `DATA`, 32 Bytes – Hash einer Transaktion
```js
params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
```
-**Rückgaben**
+**Rückgabewerte**
-`Object` – ein Transaktionsobjekt oder `null`, wenn keine Transaktion gefunden wurde:
+`Object` – Ein Transaktionsobjekt oder `null`, wenn keine Transaktion gefunden wurde:
-- `blockHash`: `DATA`, 32 Bytes - Hash des Blocks, in dem sich diese Transaktion befand. `null`, wenn es aussteht.
-- `blockNumber`: `QUANTITY` - Blocknummer, in der sich diese Transaktion befand. `null`, wenn es aussteht.
-- `from`: `DATA`, 20 Bytes - Adresse des Senders.
-- `gas`: `QUANTITY` - Vom Sender bereitgestelltes Gas.
-- `gasPrice`: `QUANTITY` - Vom Sender bereitgestellter Gaspreis in Wei.
-- `hash`: `DATA`, 32 Bytes - Hash der Transaktion.
-- `input`: `DATA` - Die mit der Transaktion gesendeten Daten.
-- `nonce`: `QUANTITY` - Die Anzahl der von dem Sender vor dieser Transaktion durchgeführten Transaktionen.
-- `to`: `DATA`, 20 Bytes - Adresse des Empfängers. `null` wenn es sich um eine Vertragserstellungstransaktion handelt.
-- `transactionIndex`: `QUANTITY` - Ganzzahlwert der Transaktionsindexposition im Block. `null`, wenn es aussteht.
-- `value`: `QUANTITY` - Der übertragene Wert in Wei.
-- `v`: `QUANTITY` - ECDSA Wiederherstellungs-ID
-- `r`: `QUANTITY` - ECDSA Signatur r
-- `s`: `QUANTITY` - ECDSA Signatur s
+- `blockHash`: `DATA`, 32 Bytes – Hash des Blocks, in dem sich diese Transaktion befand. `null`, wenn sie aussteht.
+- `blockNumber`: `QUANTITY` – Blocknummer, in der sich diese Transaktion befand. `null`, wenn sie aussteht.
+- `from`: `DATA`, 20 Bytes – Adresse des Absenders.
+- `gas`: `QUANTITY` – vom Absender bereitgestelltes Gas.
+- `gasPrice`: `QUANTITY` – vom Absender bereitgestellter Gaspreis in Wei.
+- `hash`: `DATA`, 32 Bytes – Hash der Transaktion.
+- `input`: `DATA` – die mit der Transaktion gesendeten Daten.
+- `nonce`: `QUANTITY` – die Anzahl der Transaktionen, die vom Absender vor dieser getätigt wurden.
+- `to`: `DATA`, 20 Bytes – Adresse des Empfängers. `null`, wenn es sich um eine Vertragserstellungstransaktion handelt.
+- `transactionIndex`: `QUANTITY` – Ganzzahl der Indexposition der Transaktion im Block. `null`, wenn sie aussteht.
+- `value`: `QUANTITY` – in Wei übertragener Wert.
+- `v`: `QUANTITY` – ECDSA-Wiederherstellungs-ID
+- `r`: `QUANTITY` – ECDSA-Signatur r
+- `s`: `QUANTITY` – ECDSA-Signatur s
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'
-// Result
+// Ergebnis
{
"jsonrpc":"2.0",
"id":1,
@@ -1212,10 +1299,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param
Gibt Informationen über eine Transaktion nach dem Block-Hash und der Transaktionsindexposition zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `DATA`, 32 Bytes - Hash eines Blocks.
-2. `QUANTITY` - Ganzzahlwert der Transaktionsindexposition.
+1. `DATA`, 32 Bytes – Hash eines Blocks.
+2. `QUANTITY` – Ganzzahl der Indexposition der Transaktion.
```js
params: [
@@ -1224,7 +1315,8 @@ params: [
]
```
-**Rückgaben** Siehe [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**Rückgabewerte**
+Siehe [eth_getTransactionByHash](#eth_gettransactionbyhash)
**Beispiel**
@@ -1239,10 +1331,14 @@ Ergebnis siehe [eth_getTransactionByHash](#eth_gettransactionbyhash)
Gibt Informationen über eine Transaktion nach der Blocknummer und der Transaktionsindexposition zurück.
+
+ Endpunkt im Playground ausprobieren
+
+
**Parameter**
-1. `QUANTITY|TAG` – eine Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - Die Transaktionsindexposition.
+1. `QUANTITY|TAG` – eine Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITY` – die Indexposition der Transaktion.
```js
params: [
@@ -1251,12 +1347,13 @@ params: [
]
```
-**Rückgaben** Siehe [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**Rückgabewerte**
+Siehe [eth_getTransactionByHash](#eth_gettransactionbyhash)
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
```
@@ -1270,39 +1367,40 @@ Gibt den Beleg einer Transaktion nach dem Transaktions-Hash zurück.
**Parameter**
-1. `DATA`, 32 Bytes - Hash einer Transaktion
+1. `DATA`, 32 Bytes – Hash einer Transaktion
```js
params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
```
-**Rückgaben** `Object` – ein Transaktionsbeleg-Objekt oder `null`, wenn kein Beleg gefunden wurde:
+**Rückgabewerte**
+`Object` – Ein Transaktionsbeleg-Objekt oder `null`, wenn kein Beleg gefunden wurde:
-- `transactionHash`: `DATA`, 32 Bytes - Hash der Transaktion.
-- `transactionIndex`: `QUANTITY` - Ganzzahlwert der Transaktionsindexposition im Block.
-- `blockHash`: `DATA`, 32 Bytes - Hash des Blocks, in dem sich diese Transaktion befand.
-- `blockNumber`: `QUANTITY` - Blocknummer, in der sich diese Transaktion befand.
-- `from`: `DATA`, 20 Bytes - Adresse des Senders.
-- `to`: `DATA`, 20 Bytes - Adresse des Empfängers. null, wenn es sich um eine Vertragserstellungstransaktion handelt.
-- `cumulativeGasUsed` : `QUANTITY` - Die Gesamtmenge an Gas, die bei Ausführung dieser Transaktion im Block verwendet wurde.
-- `effectiveGasPrice` : `QUANTITY` - Die Summe der Grundgebühr und der Tipp, die pro Einheit Gas bezahlt wurde.
-- `gasUsed`: `QUANTITY` - Die Menge an Gas, die von dieser bestimmten Transaktion allein verwendet wurde.
-- `contractAddress`: `DATA`, 20 Bytes - Die Vertragsadresse, die erstellt wurde, falls die Transaktion eine Vertragserstellung war, andernfalls `null`.
-- `logs`: `Array` - Array von Log-Objekten, die diese Transaktion generiert hat.
-- `logsBloom`: `DATA`, 256 Bytes - Bloom-Filter für leichte Clients, um schnell verwandte Logs abzurufen.
-- `type`: `QUANTITY` - Ganzzahlwert des Transaktionstyps, `0x0` für veraltete Transaktionen, `0x1` für Zugriffslistentypen, `0x2` für dynamische Gebühren.
+- `transactionHash `: `DATA`, 32 Bytes – Hash der Transaktion.
+- `transactionIndex`: `QUANTITY` – Ganzzahl der Indexposition der Transaktion im Block.
+- `blockHash`: `DATA`, 32 Bytes – Hash des Blocks, in dem sich diese Transaktion befand.
+- `blockNumber`: `QUANTITY` – Blocknummer, in der sich diese Transaktion befand.
+- `from`: `DATA`, 20 Bytes – Adresse des Absenders.
+- `to`: `DATA`, 20 Bytes – Adresse des Empfängers. null, wenn es sich um eine Vertragserstellungstransaktion handelt.
+- `cumulativeGasUsed` : `QUANTITY ` – die Gesamtmenge an Gas, die bei der Ausführung dieser Transaktion im Block verbraucht wurde.
+- `effectiveGasPrice` : `QUANTITY` – die Summe aus der Grundgebühr und dem pro Gaseinheit gezahlten Trinkgeld.
+- `gasUsed `: `QUANTITY ` – die Menge an Gas, die allein durch diese spezifische Transaktion verbraucht wurde.
+- `contractAddress `: `DATA`, 20 Bytes – die erstellte Vertragsadresse, wenn es sich bei der Transaktion um eine Vertragserstellung handelte, andernfalls `null`.
+- `logs`: `Array` – Array von Log-Objekten, die diese Transaktion generiert hat.
+- `logsBloom`: `DATA`, 256 Bytes – Bloom-Filter für Light Clients, um zugehörige Protokolle schnell abzurufen.
+- `type`: `QUANTITY` – Ganzzahl des Transaktionstyps, `0x0` für Legacy-Transaktionen, `0x1` für Zugriffstlistentypen, `0x2` für dynamische Gebühren.
-Es gibt auch _eines davon_ zurück:
+Es gibt auch eines davon zurück:
-- `root` : `DATA` 32 Bytes des vorherigen Transaktions-Stateroots (vor Byzantium)
-- `status`: `QUANTITY` entweder `1` (Erfolg) or `0` (Fehler)
+- `root` : `DATA` 32 Bytes des Post-Transaktions-Zustands-Roots (vor Byzanz)
+- `status`: `QUANTITY` entweder `1` (erfolgreich) oder `0` (fehlgeschlagen)
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}'
-// Result
+// Ergebnis
{
"jsonrpc": "2.0",
"id": 1,
@@ -1310,15 +1408,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
"blockHash":
"0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
"blockNumber": "0xeff35f",
- "contractAddress": null, // string of the address if it was created
+ "contractAddress": null, // string der Adresse, wenn sie erstellt wurde
"cumulativeGasUsed": "0xa12515",
"effectiveGasPrice": "0x5a9c688d4",
"from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
"gasUsed": "0xb4c8",
"logs": [{
- // logs as returned by getFilterLogs, etc.
+ // logs wie sie von getFilterLogs usw. zurückgegeben werden.
}],
- "logsBloom": "0x00...0", // 256 byte bloom filter
+ "logsBloom": "0x00...0", // 256-Byte-Bloom-Filter
"status": "0x1",
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"transactionHash":
@@ -1331,12 +1429,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-Gibt Informationen über einen Onkel eines Blocks nach Hash und Onkel-Indexposition zurück.
+Gibt Informationen über einen Uncle eines Blocks nach Hash und Uncle-Indexposition zurück.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
-1. `DATA`, 32 Bytes - Der Hash eines Blocks.
-2. `QUANTITY` - Die Indexposition des Onkels.
+1. `DATA`, 32 Bytes – Der Hash eines Blocks.
+2. `QUANTITY` – die Indexposition des Uncle.
```js
params: [
@@ -1345,7 +1447,8 @@ params: [
]
```
-**Rückgaben** Siehe [eth_getBlockByHash](#eth_getblockbyhash)
+**Rückgabewerte**
+Siehe [eth_getBlockByHash](#eth_getblockbyhash)
**Beispiel**
@@ -1356,16 +1459,20 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex"
Ergebnis siehe [eth_getBlockByHash](#eth_getblockbyhash)
-**Hinweis**: Ein Onkel enthält keine einzelnen Transaktionen.
+**Hinweis**: Ein Uncle enthält keine einzelnen Transaktionen.
### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-Gibt Informationen über einen Onkel eines Blocks nach Nummer und Onkel-Indexposition zurück.
+Gibt Informationen über einen Uncle eines Blocks nach Nummer und Uncle-Indexposition zurück.
+
+
+ Endpunkt im Playground ausprobieren
+
**Parameter**
-1. `QUANTITY|TAG` – eine Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, wie im [Standardblockparameter](/developers/docs/apis/json-rpc/#default-block).
-2. `QUANTITY` - Die Indexposition des Onkels.
+1. `QUANTITY|TAG` – eine Blocknummer oder der String `"earliest"`, `"latest"`, `"pending"`, `"safe"` oder `"finalized"`, wie im [Block-Parameter](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITY` – die Indexposition des Uncle.
```js
params: [
@@ -1374,14 +1481,15 @@ params: [
]
```
-**Rückgaben** Siehe [eth_getBlockByHash](#eth_getblockbyhash)
+**Rückgabewerte**
+Siehe [eth_getBlockByHash](#eth_getblockbyhash)
-**Hinweis**: Ein Onkel enthält keine einzelnen Transaktionen.
+**Hinweis**: Ein Uncle enthält keine einzelnen Transaktionen.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}'
```
@@ -1389,23 +1497,25 @@ Ergebnis siehe [eth_getBlockByHash](#eth_getblockbyhash)
### eth_newFilter {#eth_newfilter}
-Erstellt auf Basis von Filteroptionen ein Filterobjekt, um eine Benachrichtigung auszugeben, wenn sich der Status ändert (Protokolle). Um zu überprüfen, ob sich der Status geändert hat, rufen Sie [eth_getFilterChanges](#eth_getfilterchanges) auf.
+Erstellt auf Basis von Filteroptionen ein Filterobjekt, um eine Benachrichtigung auszugeben, wenn sich der Status ändert (Protokolle).
+Um zu prüfen, ob sich der Zustand geändert hat, rufen Sie [eth_getFilterChanges](#eth_getfilterchanges) auf.
-**Hinweis zum Festlegen von Themenfiltern:** Themen sind auftragsabhängig. Eine Transaktion mit einem Protokoll mit den Themen [A, B] wird mit den folgenden Themenfiltern abgeglichen:
+**Ein Hinweis zur Angabe von Themenfiltern:**
+Themen sind reihenfolgeabhängig. Eine Transaktion mit einem Protokoll mit den Themen [A, B] wird mit den folgenden Themenfiltern abgeglichen:
- `[]` „alles“
-- `[A]` „A an erster Stelle (und alles danach)“
-- `[null, B]` „Alles an erster Stelle UND B an zweiter Stelle (und alles danach)“
-- `[A, B]` „A an erster Stelle UND B an zweiter Stelle (und alles danach)“
-- `[[A, B], [A, B]]` „(A ODER B) an erster Stelle UND (A ODER B) an zweiter Stelle (und alles danach)“
+- `[A]` „A an erster Position (und alles danach)“
+- `[null, B]` „alles an erster Position UND B an zweiter Position (und alles danach)“
+- `[A, B]` „A an erster Position UND B an zweiter Position (und alles danach)“
+- `[[A, B], [A, B]]` „(A ODER B) an erster Position UND (A ODER B) an zweiter Position (und alles danach)“
- **Parameter**
-1. `Object` – die Filteroptionen:
+1. `Object` – Die Filteroptionen:
-- `fromBlock`: `QUANTITY|TAG` – (optional, standardmäßig: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten abgeschlossenen Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
-- `toBlock`: `QUANTITY|TAG` – (optional, standardmäßig: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten abgeschlossenen Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
-- `Adresse`: `DATA|Array`, 20 Bytes - (Optional) Vertragsadresse oder eine Liste von Adressen, von denen Protokolle stammen sollen.
-- `topics`: `Array of DATA`, - (Optional) Array von 32 Bytes `DATA`-Themen. Themen sind auftragsabhängig. Jedes Thema kann auch ein Array von DATEN mit „oder“-Optionen sein.
+- `fromBlock`: `QUANTITY|TAG` – (optional, Standard: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten finalisierten Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
+- `toBlock`: `QUANTITY|TAG` – (optional, Standard: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten finalisierten Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
+- `address`: `DATA|Array`, 20 Bytes – (optional) Vertragsadresse oder eine Liste von Adressen, von denen Protokolle stammen sollen.
+- `topics`: `Array von DATA`, – (optional) Array von 32 Bytes `DATA` Themen. Themen sind auftragsabhängig. Jedes Thema kann auch ein Array von DATEN mit „oder“-Optionen sein.
```js
params: [
@@ -1425,14 +1535,15 @@ params: [
]
```
-**Rückgaben** `QUANTITY` – eine Filter-ID.
+**Rückgabewerte**
+`QUANTITY` – eine Filter-ID.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -1442,18 +1553,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic
### eth_newBlockFilter {#eth_newblockfilter}
-Erstellt einen Filter im Knoten, um eine Benachrichtigung auszugeben, wenn ein neuer Block eintrifft. Um zu überprüfen, ob sich der Status geändert hat, rufen Sie [eth_getFilterChanges](#eth_getfilterchanges) auf.
+Erstellt einen Filter im Knoten, um eine Benachrichtigung auszugeben, wenn ein neuer Block eintrifft.
+Um zu prüfen, ob sich der Zustand geändert hat, rufen Sie [eth_getFilterChanges](#eth_getfilterchanges) auf.
-**Parameter** Keine
+**Parameter**
+Keine
-**Rückgaben** `QUANTITY` – eine Filter-ID.
+**Rückgabewerte**
+`QUANTITY` – eine Filter-ID.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -1463,18 +1577,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],
### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-Erstellt einen Filter im Knoten, um eine Benachrichtigung auszugeben, wenn eine neue ausstehende Transaktionen eintrifft. Um zu überprüfen, ob sich der Status geändert hat, rufen Sie [eth_getFilterChanges](#eth_getfilterchanges) auf.
+Erstellt einen Filter im Knoten, um eine Benachrichtigung auszugeben, wenn eine neue ausstehende Transaktionen eintrifft.
+Um zu prüfen, ob sich der Zustand geändert hat, rufen Sie [eth_getFilterChanges](#eth_getfilterchanges) auf.
-**Parameter** Keine
+**Parameter**
+Keine
-**Rückgaben** `QUANTITY` – eine Filter-ID.
+**Rückgabewerte**
+`QUANTITY` – eine Filter-ID.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -1484,11 +1601,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter"
### eth_uninstallFilter {#eth_uninstallfilter}
-Deinstalliert einen Filter mit angegebener ID. Sollte immer aufgerufen werden, wenn die Uhr nicht mehr benötigt wird. Zusätzlich Timeout für Filter, wenn sie für einen bestimmten Zeitraum nicht mit [eth_getFilterChanges](#eth_getfilterchanges) angefordert werden.
+Deinstalliert einen Filter mit angegebener ID. Sollte immer aufgerufen werden, wenn die Uhr nicht mehr benötigt wird.
+Zusätzlich kommt es bei Filtern zu einem Timeout, wenn sie für einen bestimmten Zeitraum nicht mit [eth_getFilterChanges](#eth_getfilterchanges) angefordert werden.
**Parameter**
-1. `QUANTITY` – die Filter-ID.
+1. `QUANTITY` – Die Filter-ID.
```js
params: [
@@ -1496,14 +1614,15 @@ params: [
]
```
-**Rückgabewerte** `Boolean` – `true`, wenn der Filter erfolgreich deinstalliert wurde, andernfalls `false`.
+**Rückgabewerte**
+`Boolean` – `true`, wenn der Filter erfolgreich deinstalliert wurde, andernfalls `false`.
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc": "2.0",
@@ -1525,26 +1644,30 @@ params: [
]
```
-**Rückgabewerte** `Array` – Array von Protokollobjekten oder ein leeres Array, wenn sich seit der letzten Umfrage nichts geändert hat.
+**Rückgabewerte**
+`Array` – Array von Protokollobjekten oder ein leeres Array, wenn sich seit der letzten Abfrage nichts geändert hat.
+
+- Für mit `eth_newBlockFilter` erstellte Filter sind die Rückgabewerte Block-Hashes (`DATA`, 32 Bytes), z. B. `["0x3454645634534..."]`.
+
+- Für mit `eth_newPendingTransactionFilter` erstellte Filter sind die Rückgabewerte Transaktions-Hashes (`DATA`, 32 Bytes), z. B. `["0x6345343454645..."]`.
-- Für mit `eth_newBlockFilter` erstellte Filter sind die Rückgabewerte Block-Hashes (`DATA`, 32 Bytes), z. `["0x3454645634534..."]`.
-- Für Filter, die mit `eth_newPendingTransactionFilter` erstellt wurden, sind die Rückgabewerte Transaktions-Hashes (`DATA`, 32 Bytes), z. `["0x6345343454645..."]`.
- Für mit `eth_newFilter` erstellte Filter sind Protokolle Objekte mit folgenden Parametern:
- - `removed`: `TAG` - `true`, als das Protokoll aufgrund einer Neustrukturierung der Blockchain entfernt wurde. `false`, wenn es sich um ein gültiges Protokoll handelt.
- - `logIndex`: `QUANTITY` – Ganzzahlwert der Protokollindexposition im Block. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
- - `transactionIndex`: `QUANTITY` - Ganzzahlwert der Transaktionsindexposition, aus der das Protokoll erstellt wurde. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
- - `transactionHash`: `DATA`, 32 Bytes - Hash der Transaktionen, aus denen dieses Protokoll erstellt wurde. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
- - `blockHash`: `DATA`, 32 Bytes - Hash des Blocks, in dem sich dieses Protokoll befand. `null`, wenn es aussteht. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
- - `blockNumber`: `QUANTITY` - Die Blocknummer, in der sich dieses Protokoll befand. `null`, wenn es aussteht. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
- - `Adresse`: `DATA`, 20 Bytes - Adresse, von der dieses Protokoll stammt.
- - `data`: `DATA` – enthält null oder mehr 32 Byte nicht indizierte Argumente des Protokolls.
- - `topics`: `Array of DATA` - Array von 0 bis 4 32 Bytes `DATA` von indizierten Protokollargumenten. (In _Solidity_: Das erste Thema ist der _Hash_ der Signatur des Ereignisses (z. B. `Deposit (address,bytes32,uint256)`), es sei denn, Sie haben das Ereignis mit dem `anonymous`-Spezifizierer deklariert.)
+ - `removed`: `TAG` – `true`, wenn das Protokoll aufgrund einer Reorganisation der Kette entfernt wurde. `false`, wenn es sich um ein gültiges Protokoll handelt.
+ - `logIndex`: `QUANTITY` – Ganzzahl der Protokollindexposition im Block. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
+ - `transactionIndex`: `QUANTITY` – Ganzzahl der Indexposition der Transaktion, aus der das Protokoll erstellt wurde. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
+ - `transactionHash`: `DATA`, 32 Bytes – Hash der Transaktionen, aus denen dieses Protokoll erstellt wurde. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
+ - `blockHash`: `DATA`, 32 Bytes – Hash des Blocks, in dem sich dieses Protokoll befand. `null`, wenn sie aussteht. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
+ - `blockNumber`: `QUANTITY` – die Blocknummer, in der sich dieses Protokoll befand. `null`, wenn sie aussteht. `null`, wenn es sich um ein ausstehendes Protokoll handelt.
+ - `address`: `DATA`, 20 Bytes – Adresse, von der dieses Protokoll stammt.
+ - `data`: `DATA` – nicht indizierte Protokolldaten mit variabler Länge. (In _Solidity_: null oder mehr nicht indizierte 32-Byte-Protokollargumente.)
+ - `topics`: `Array von DATA` – Array von 0 bis 4 32 Bytes `DATA` von indizierten Protokollargumenten. (In _Solidity_: Das erste Thema ist der _Hash_ der Signatur des Ereignisses (z. B. `Deposit(address,bytes32,uint256)`), es sei denn, Sie haben das Ereignis mit dem `anonymous`-Spezifizierer deklariert.)
+
- **Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}'
-// Result
+// Ergebnis
{
"id":1,
"jsonrpc":"2.0",
@@ -1569,7 +1692,7 @@ Gibt ein Array aller Protokolle zurück, die dem Filter mit der angegebenen ID e
**Parameter**
-1. `QUANTITY` – die Filter-ID.
+1. `QUANTITY` – Die Filter-ID.
```js
params: [
@@ -1577,12 +1700,13 @@ params: [
]
```
-**Rückgabewerte** Siehe [eth_getFilterChanges](#eth_getfilterchanges)
+**Rückgabewerte**
+Siehe [eth_getFilterChanges](#eth_getfilterchanges)
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
```
@@ -1594,13 +1718,13 @@ Gibt ein Array aller Protokolle zurück, die einem angegebenen Filterobjekt ents
**Parameter**
-1. `Object` – die Filteroptionen:
+1. `Object` – Die Filteroptionen:
-- `fromBlock`: `QUANTITY|TAG` – (optional, standardmäßig: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten abgeschlossenen Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
-- `toBlock`: `QUANTITY|TAG` – (optional, standardmäßig: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten abgeschlossenen Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
-- `Adresse`: `DATA|Array`, 20 Bytes - (Optional) Vertragsadresse oder eine Liste von Adressen, von denen Protokolle stammen sollen.
-- `topics`: `Array of DATA`, - (Optional) Array von 32 Bytes `DATA`-Themen. Themen sind auftragsabhängig. Jedes Thema kann auch ein Array von DATEN mit „oder“-Optionen sein.
-- `blockhash`: `DATA`, 32 Bytes - (optional, **future**) Mit dem Hinzufügen von EIP-234 wird `blockHash` eine neue Filteroption sein, die die zurückgegebenen Protokolle auf den einzelnen Block mit dem 32-Byte-Hash `blockHash` beschränkt. Die Verwendung von `blockHash` entspricht `fromBlock` = `toBlock` = die Blocknummer mit Hash `blockHash`. Wenn `blockHash` in den Filterkriterien vorhanden ist, sind weder `fromBlock` noch `toBlock` zulässig.
+- `fromBlock`: `QUANTITY|TAG` – (optional, Standard: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten finalisierten Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
+- `toBlock`: `QUANTITY|TAG` – (optional, Standard: `"latest"`) ganzzahlige Blocknummer oder `"latest"` für den letzten vorgeschlagenen Block, `"safe"` für den letzten sicheren Block, `"finalized"` für den letzten finalisierten Block oder `"pending"`, `"earliest"` für Transaktionen, die noch nicht in einem Block sind.
+- `address`: `DATA|Array`, 20 Bytes – (optional) Vertragsadresse oder eine Liste von Adressen, von denen Protokolle stammen sollen.
+- `topics`: `Array von DATA`, – (optional) Array von 32 Bytes `DATA` Themen. Themen sind auftragsabhängig. Jedes Thema kann auch ein Array von DATEN mit „oder“-Optionen sein.
+- `blockHash`: `DATA`, 32 Bytes – (optional, **zukünftig**) Mit der Hinzufügung von EIP-234 wird `blockHash` eine neue Filteroption sein, die die zurückgegebenen Protokolle auf den einzelnen Block mit dem 32-Byte-Hash `blockHash` beschränkt. Die Verwendung von `blockHash` ist äquivalent zu `fromBlock` = `toBlock` = der Blocknummer mit dem Hash `blockHash`. Wenn `blockHash` in den Filterkriterien vorhanden ist, sind weder `fromBlock` noch `toBlock` erlaubt.
```js
params: [
@@ -1612,12 +1736,13 @@ params: [
]
```
-**Rückgabewerte** Siehe [eth_getFilterChanges](#eth_getfilterchanges)
+**Rückgabewerte**
+Siehe [eth_getFilterChanges](#eth_getfilterchanges)
**Beispiel**
```js
-// Request
+// Anfrage
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
```
@@ -1625,11 +1750,11 @@ Ergebnis siehe [eth_getFilterChanges](#eth_getfilterchanges)
## Anwendungsbeispiel {#usage-example}
-### Einen Contract mit JSON_RPC bereitstellen {#deploying-contract}
+### Bereitstellen eines Vertrags mittels JSON-RPC {#deploying-contract}
-Dieser Abschnitt enthält eine Demonstration, wie ein Contract nur mithilfe der RPC-Schnittstelle bereitgestellt wird. Es gibt alternative Wege zur Bereitstellung von Contracts, bei denen diese Komplexität abstrahiert wird – zum Beispiel die Verwendung von Bibliotheken, die auf der RPC-Schnittstelle wie [web3.js](https://web3js.readthedocs.io/) und [web3.py](https://github.com/ethereum/web3.py) aufbauen. Diese Abstraktionen sind im Allgemeinen leichter zu verstehen und weniger fehleranfällig, es ist dennoch hilfreich, zu verstehen, was im Hintergrund passiert.
+Dieser Abschnitt enthält eine Demonstration, wie ein Contract nur mithilfe der RPC-Schnittstelle bereitgestellt wird. Es gibt alternative Wege zur Bereitstellung von Verträgen, bei denen diese Komplexität abstrahiert wird – zum Beispiel die Verwendung von Bibliotheken, die auf der RPC-Schnittstelle aufbauen, wie [web3.js](https://web3js.readthedocs.io/) und [web3.py](https://github.com/ethereum/web3.py). Diese Abstraktionen sind im Allgemeinen leichter zu verstehen und weniger fehleranfällig, es ist dennoch hilfreich, zu verstehen, was im Hintergrund passiert.
-Das Folgende ist ein unkomplizierter Smart Contract namens `Multiply7`, der über die JSON-RPC-Schnittstelle auf einem Ethereum-Knoten bereitgestellt wird. Dieses Tutorial geht davon aus, dass der Reader bereits einen Geth-Knoten ausführt. Weitere Informationen zu Nodes und Clients finden Sie [hier](/developers/docs/nodes-and-clients/run-a-node). Bitte sehen Sie in der jeweiligen [Client](/developers/docs/nodes-and-clients/)-Dokumentation nach, wie Sie den HTTP-JSON-RPC für Nicht-Geth-Clients starten. Die meisten Clients werden standardmäßig auf `localhost:8545` ausgeführt.
+Das Folgende ist ein unkomplizierter Smart Contract namens `Multiply7`, der über die JSON-RPC-Schnittstelle auf einem Ethereum-Knoten bereitgestellt wird. Dieses Tutorial geht davon aus, dass der Reader bereits einen Geth-Knoten ausführt. Weitere Informationen zu Nodes und Clients finden Sie [hier](/developers/docs/nodes-and-clients/run-a-node). Bitte sehen Sie in der jeweiligen [Client](/developers/docs/nodes-and-clients/)-Dokumentation nach, wie Sie den HTTP-JSON-RPC für Nicht-Geth-Clients starten. Die meisten Clients werden standardmäßig auf `localhost:8545` bereitgestellt.
```javascript
contract Multiply7 {
@@ -1649,10 +1774,10 @@ geth --http --dev console 2>>geth.log
Dadurch wird die HTTP-RPC-Schnittstelle auf `http://localhost:8545` gestartet.
-Wir können überprüfen, ob die Schnittstelle läuft, indem wir die Coinbase-Adresse und den Saldo mit [curl](https://curl.se) abrufen. Bitte beachten Sie, dass sich die Daten in diesen Beispielen auf Ihrem lokalen Knoten unterscheiden. Wenn Sie diese Befehle ausprobieren möchten, ersetzen Sie die Anfrageparameter in der zweiten Curl-Anfrage durch das Ergebnis, das von der ersten zurückgegeben wird.
+Wir können überprüfen, ob die Schnittstelle läuft, indem wir die Coinbase-Adresse (die erste Adresse aus dem Array der Konten) und das Guthaben mithilfe von [curl](https://curl.se) abrufen. Bitte beachten Sie, dass sich die Daten in diesen Beispielen auf Ihrem lokalen Knoten unterscheiden. Wenn Sie diese Befehle ausprobieren möchten, ersetzen Sie die Anfrageparameter in der zweiten Curl-Anfrage durch das Ergebnis, das von der ersten zurückgegeben wird.
```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_coinbase", "id":1}' -H "Content-Type: application/json" localhost:8545
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
@@ -1666,15 +1791,15 @@ web3.fromWei("0x1639e49bba16280000", "ether")
// "410"
```
-Jetzt, da es etwas Ether in unserer privaten Entwicklungs-Kette gibt, können wir den Contract bereitstellen. Der erste Schritt besteht darin, den Multiply7-Contract in Bytecode zu kompilieren, der an die EVM gesendet werden kann. Um Solc, den Solidity-Compiler, zu installieren, folgen Sie der [Solidity-Dokumentation](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Möglicherweise möchten Sie eine ältere `solc`-Version verwenden, um der [Version des verwendeten Compilers für unser Beispiel zu entsprechen](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
+Jetzt, da es etwas Ether in unserer privaten Entwicklungs-Kette gibt, können wir den Contract bereitstellen. Der erste Schritt besteht darin, den Multiply7-Contract in Bytecode zu kompilieren, der an die EVM gesendet werden kann. Um solc, den Solidity-Compiler, zu installieren, folgen Sie der [Solidity-Dokumentation](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Möglicherweise möchten Sie eine ältere `solc`-Version verwenden, um der [Version des für unser Beispiel verwendeten Compilers](https://github.com/ethereum/solidity/releases/tag/v0.4.20) zu entsprechen.)
-Der nächste Schritt besteht darin, den Multiply7-Contract in Bytecode zu kompilieren, der an die EVM gesendet werden kann.
+Der nächste Schritt besteht darin, den Multiply7-Vertrag in Bytecode zu kompilieren, der an die EVM gesendet werden kann.
```bash
echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
======= :Multiply7 =======
-Binary:
+Binär:
6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
```
@@ -1699,13 +1824,13 @@ curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": [
{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
```
-Unser Contract wurde am `0x4d03d617d700cf81935d7f797f4e2ae719648262` erstellt. Ein Nullergebnis anstelle eines Belegs bedeutet, dass die Transaktion noch nicht in einen Block aufgenommen wurde. Warten Sie einen Moment, prüfen Sie, ob Ihr Konsens-Client ausgeführt wird, und versuchen Sie es erneut.
+Unser Vertrag wurde auf `0x4d03d617d700cf81935d7f797f4e2ae719648262` erstellt. Ein Nullergebnis anstelle eines Belegs bedeutet, dass die Transaktion noch nicht in einen Block aufgenommen wurde. Warten Sie einen Moment, prüfen Sie, ob Ihr Konsens-Client ausgeführt wird, und versuchen Sie es erneut.
#### Interaktion mit Smart Contracts {#interacting-with-smart-contract}
-In diesem Beispiel senden wir eine Transaktion mit `eth_sendTransaction` an die Methode `multiply` des Contracts.
+In diesem Beispiel werden wir eine Transaktion mit `eth_sendTransaction` an die `multiply`-Methode des Vertrags senden.
-`eth_sendTransaction` erfordert mehrere Argumente, speziell `from`, `to` und `data`. `From` ist die öffentliche Adresse unseres Kontos und `to` ist die Contract-Adresse. Das Argument `data` enthält eine Nutzlast, die definiert, welche Methode mit welchen Argumenten aufgerufen werden muss. An dieser Stelle kommt die [ABI (Application Binary Interface – binäre Anwendungsschnittstelle)](https://docs.soliditylang.org/en/latest/abi-spec.html) ins Spiel. Die ABI ist eine JSON-Datei, die festlegt, wie Daten für die EVM definiert und kodiert werden.
+`eth_sendTransaction` erfordert mehrere Argumente, insbesondere `from`, `to` und `data`. `From` ist die öffentliche Adresse unseres Kontos und `to` ist die Vertragsadresse. Das Argument `data` enthält eine Nutzlast, die definiert, welche Methode mit welchen Argumenten aufgerufen werden muss. Hier kommt das [ABI (Application Binary Interface)](https://docs.soliditylang.org/en/latest/abi-spec.html) ins Spiel. Die ABI ist eine JSON-Datei, die festlegt, wie Daten für die EVM definiert und kodiert werden.
Die Byte der Nutzlast definieren, welche Methode im Contract aufgerufen wird. Das sind die ersten 4 Byte aus dem Keccak-Hash über den Funktionsnamen und seine Argumenttypen, Hex-codiert. Die Multiplizieren-Funktion akzeptiert ein uint, welches ein Alias für uint256 ist. Damit bleibt uns:
@@ -1714,13 +1839,13 @@ web3.sha3("multiply(uint256)").substring(0, 10)
// "0xc6888fa1"
```
-Der nächste Schritt besteht darin, die Argumente zu codieren. Es gibt nur einen uint256, beispielsweise den Wert 6. Die ABI hat einen Abschnitt, der angibt, wie uint256-Typen codiert werden.
+Der nächste Schritt besteht darin, die Argumente zu kodieren. Es gibt nur einen uint256, beispielsweise den Wert 6. Die ABI hat einen Abschnitt, der angibt, wie uint256-Typen codiert werden.
-`int: enc(X)` ist die Big-Endian-Zweierkomplementcodierung von X, aufgefüllt auf der Seite höherer Ordnung (links) mit 0xff für negatives X und mit null > Byte für positives X, sodass die Länge ein Vielfaches von 32 Byte ist.
+`int: enc(X)` ist die Big-Endian-Zweierkomplement-Kodierung von X, die auf der höherwertigen (linken) Seite mit 0xff für negatives X und mit Null-Bytes für positives X aufgefüllt wird, so dass die Länge ein Vielfaches von 32 Bytes ist.
-Dies wird zu `0000000000000000000000000000000000000000000000000000000000006` codiert.
+Dies kodiert zu `0000000000000000000000000000000000000000000000000000000000000006`.
-Durch die Kombination des Funktionsselektors und des codierten Arguments werden unsere Daten zu `0xc6888fa10000000000000000000000000000000000000000000000000000000000006`.
+Durch die Kombination des Funktionsselektors und des kodierten Arguments lauten unsere Daten `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
Dies kann nun an den Knoten gesendet werden:
@@ -1753,7 +1878,7 @@ Da eine Transaktion gesendet wurde, wurde ein Transaktions-Hash zurückgegeben.
}
```
-Der Beleg enthält ein Protokoll. Dieses Protokoll wurde von der EVM bei der Transaktionsausführung generiert und in den Beleg aufgenommen. Die Funktion `multiply` zeigt, dass das Ereignis `Print` mit der Eingabe mal 7 ausgelöst wurde. Da das Argument für das Ereignis `Print` ein uint256 war, können wir es gemäß den ABI-Regeln dekodieren, was zu der erwarteten Dezimalzahl 42 führt. Abgesehen von den Daten ist es erwähnenswert, dass Themen verwendet werden können, um festzustellen, welches Ereignis das Protokoll erstellt hat:
+Der Beleg enthält ein Protokoll. Dieses Protokoll wurde von der EVM bei der Transaktionsausführung generiert und in den Beleg aufgenommen. Die `multiply`-Funktion zeigt, dass das `Print`-Ereignis mit der Eingabe mal 7 ausgelöst wurde. Da das Argument für das `Print`-Ereignis ein uint256 war, können wir es gemäß den ABI-Regeln dekodieren, was zu der erwarteten Dezimalzahl 42 führt. Abgesehen von den Daten ist es erwähnenswert, dass Themen verwendet werden können, um festzustellen, welches Ereignis das Protokoll erstellt hat:
```javascript
web3.sha3("Print(uint256)")
@@ -1765,7 +1890,7 @@ Das war nur eine kurze Einführung in einige der häufigsten Aufgaben, die die d
## Verwandte Themen {#related-topics}
- [JSON-RPC-Spezifikation](http://www.jsonrpc.org/specification)
-- [Knotenpunkte und Clients](/developers/docs/nodes-and-clients/)
+- [Nodes und Clients](/developers/docs/nodes-and-clients/)
- [JavaScript-APIs](/developers/docs/apis/javascript/)
- [Backend-APIs](/developers/docs/apis/backend/)
-- [Ausführende Clients](/developers/docs/nodes-and-clients/#execution-clients)
+- [Ausführungs-Clients](/developers/docs/nodes-and-clients/#execution-clients)
diff --git a/public/content/translations/de/developers/docs/blocks/index.md b/public/content/translations/de/developers/docs/blocks/index.md
index 8729bdf88cc..f9f679d6fd0 100644
--- a/public/content/translations/de/developers/docs/blocks/index.md
+++ b/public/content/translations/de/developers/docs/blocks/index.md
@@ -1,6 +1,6 @@
---
-title: Blöcke
-description: Eine Übersicht über Blöcke in der Ethereum Blockchain – ihre Datenstruktur, warum sie benötigt werden und wie sie erstellt werden.
+title: "Blöcke"
+description: "Eine Übersicht über Blöcke in der Ethereum Blockchain – ihre Datenstruktur, warum sie benötigt werden und wie sie erstellt werden."
lang: de
---
@@ -8,13 +8,14 @@ Blöcke sind Stapel von Transaktionen mit einem Hash des vorherigen Blocks in de
## Voraussetzungen {#prerequisites}
-Blöcke sind ein sehr anfängerfreundliches Thema. Um dir jedoch zu helfen, diese Seite besser zu verstehen, empfehlen wir, zuerst [ Konten](/developers/docs/accounts/), [Transaktionen](/developers/docs/transactions/) und unsere [Einführung in Ethereum](/developers/docs/intro-to-ethereum/) zu lesen.
+Blöcke sind ein sehr anfängerfreundliches Thema. Um diese Seite besser zu verstehen, empfehlen wir Ihnen jedoch, zuerst [Konten](/developers/docs/accounts/), [Transaktionen](/developers/docs/transactions/) und unsere [Einführung in Ethereum](/developers/docs/intro-to-ethereum/) zu lesen.
## Warum Blöcke? {#why-blocks}
Um sicherzustellen, dass alle Teilnehmer des Ethereum-Netzwerks einen synchronisierten Zustand beibehalten und sich über den genauen Verlauf der Transaktionen einig sind, fassen wir die Transaktionen in Blöcken zusammen. Das bedeutet, dass Dutzende (oder Hunderte) von Transaktionen in einem Durchgang übergeben, bestätigt und synchronisiert werden.
- _Diagramm angepasst von [Ethereum EVM illustriert](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramm adaptiert von [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
Durch die zeitliche Verteilung der Commits geben wir allen Netzwerkteilnehmern genügend Zeit, einen Konsens zu erzielen: Obwohl Transaktionsanfragen dutzende Male pro Sekunde erfolgen, werden Blöcke auf Ethereum nur alle zwölf Sekunden erstellt und festgeschrieben.
@@ -24,7 +25,7 @@ Um die Transaktionsgeschichte zu erhalten, sind Blöcke streng sortiert (jeder n
Sobald ein Block von einem zufällig ausgewählten Validator im Netzwerk erstellt wird, wird er im gesamten Netzwerk verbreitet. Alle Knoten fügen diesen Block dann am Ende ihrer Blockchain hinzu und ein neuer Validator wird ausgewählt, um den nächsten Block zu erstellen. Der genaue Prozess der Blockzusammenstellung und Festlegung/Konsensbildung ist zurzeit in Ethereums Proof-of-Stake-Protokoll festgelegt.
-## Proof-of-Stake-Protokoll {#proof-of-work-protocol}
+## Proof-of-Stake-Protokoll {#proof-of-stake-protocol}
Proof-of-Stake bedeutet Folgendes:
@@ -33,30 +34,30 @@ Proof-of-Stake bedeutet Folgendes:
- Andere Validatoren, die von dem neuen Block erfahren, führen die Transaktionen erneut aus, um sicherzustellen, dass sie der vorgeschlagenen Änderung des globalen Zustands zustimmen. In der Annahme, dass der Block gültig ist, fügen sie ihn zu ihrer eigenen Datenbank hinzu.
- Wenn ein Validator von zwei konkurrierenden Blöcken für denselben Slot erfährt, wählt er mit seinem Fork-Wahlalgorithmus den Block aus, der von den meisten eingesetzten ETH unterstützt wird.
-[Mehr über Proof-of-Stake](/developers/docs/consensus-mechanisms/pos)
+[Mehr zu Proof-of-Stake](/developers/docs/consensus-mechanisms/pos)
## Was enthält ein Block? {#block-anatomy}
Ein Block enthält viele verschiedene Informationen. Auf oberster Ebene enthält ein Block folgende Felder:
-| Feld | Beschreibung |
-|:------------------- |:----------------------------------------------------------- |
-| `Zeitspanne (Slot)` | Der Slot, zu dem der Block gehört |
-| `proposer_index` | Die ID des Validators, der den Block vorschlägt |
-| `parent_root` | Der Hash des vorausgehenden Blocks |
-| `state_root` | Der Stamm-Hash des Zustandsobjekts |
-| `hauptteil` | Ein Objekt, das mehrere Felder enthält, wie unten definiert |
+| Feld | Beschreibung |
+| :--------------- | :---------------------------------------------------------- |
+| `slot` | Der Slot, zu dem der Block gehört |
+| `proposer_index` | Die ID des Validators, der den Block vorschlägt |
+| `parent_root` | Der Hash des vorausgehenden Blocks |
+| `state_root` | Der Stamm-Hash des Zustandsobjekts |
+| `hauptteil` | Ein Objekt, das mehrere Felder enthält, wie unten definiert |
-Der `Body` eines Blocks enthält selbst mehrere Felder:
+Der `body` eines Blocks enthält selbst mehrere Felder:
| Feld | Beschreibung |
-|:-------------------- |:-------------------------------------------------------------------------------- |
+| :------------------- | :------------------------------------------------------------------------------- |
| `randao_reveal` | Ein Wert, der zur Auswahl des nächsten Block-Vorschlagenden verwendet wird |
| `eth1_data` | Informationen zum Einzahlungsvertrag |
| `graffiti` | Beliebige Daten, die zum Markieren von Blöcken verwendet werden |
| `proposer_slashings` | Liste der zu streichenden Validatoren |
| `attester_slashings` | Liste der Attestierer für Slashing |
-| `beglaubigungen` | Liste der Bescheinigungen zugunsten des aktuellen Blocks |
+| `beglaubigungen` | Liste der Attestierungen, die für frühere Slots gemacht wurden |
| `einzahlungen` | Liste der neuen Einlagen zum Einzahlungsvertrag |
| `voluntary_exits` | Liste der Validatoren, die das Netzwerk verlassen |
| `sync_aggregate` | Teilmenge der Validatoren, die zur Bedienung von leichten Clients verwendet wird |
@@ -65,88 +66,88 @@ Der `Body` eines Blocks enthält selbst mehrere Felder:
Das Feld `attestations` enthält eine Liste aller Attestierungen im Block. Attestierungen haben ihren eigenen Datentyp der mehrere Datenteile enthält. Jede Attestierung enthält:
| Feld | Beschreibung |
-|:------------------ |:------------------------------------------------------------------------- |
+| :----------------- | :------------------------------------------------------------------------ |
| `aggregation_bits` | Eine Liste der Validatoren, die an dieser Attestierung teilgenommen haben |
| `daten` | Ein Container mit mehreren Unterfeldern |
-| `signature` | Kollektivsignatur aller bescheinigenden Validatoren |
+| `unterschrift` | Aggregierte Signatur einer Gruppe von Validatoren für den `data`-Teil |
-Das Feld `data` in `attestation` enthält folgende Elemente:
+Das `data`-Feld in der `attestation` enthält Folgendes:
-| Feld | Beschreibung |
-|:------------------- |:----------------------------------------------------------- |
-| `Zeitspanne (Slot)` | Der Slot, auf den sich die Attestierung bezieht |
-| `Index` | Indizes für die bescheinigenden Validatoren |
-| `beacon_block_root` | Der Stamm-Hash des Beacon-Blocks, der dieses Objekt enthält |
-| `quelle` | Der letzte berechtigte Kontrollpunkt |
-| `target` | Der Grenzblock der neuesten Epoche |
+| Feld | Beschreibung |
+| :------------------ | :--------------------------------------------------------------------- |
+| `slot` | Der Slot, auf den sich die Attestierung bezieht |
+| `index` | Indizes für die bescheinigenden Validatoren |
+| `beacon_block_root` | Der Root-Hash des Beacon-Blocks, der als Kopf der Kette angesehen wird |
+| `quelle` | Der letzte berechtigte Kontrollpunkt |
+| `target` | Der Grenzblock der neuesten Epoche |
-Die Ausführung der Transaktionen in der `execution_payload` aktualisiert den globalen Zustand. Alle Clients führen die Transaktionen in der `execution_payload` erneut aus, um sicherzustellen, dass der neue Zustand dem Zustand im neuen Block im Feld `state_root` entspricht. Auf diese Weise stellen Clients sicher, dass ein neuer Block gültig und sicher ist, um ihn der Blockchain hinzuzufügen. Der `execution payload` selbst ist ein Objekt mit mehreren Feldern. Es gibt auch einen `execution_payload_header`, der wichtige zusammengefasste Informationen über die auszuführenden Daten enthält. Diese Datenstrukturen sind wie folgt organisiert:
+Die Ausführung der Transaktionen in der `execution_payload` aktualisiert den globalen Zustand. Alle Clients führen die Transaktionen in der `execution_payload` erneut aus, um sicherzustellen, dass der neue Zustand dem im `state_root`-Feld des neuen Blocks entspricht. Auf diese Weise stellen Clients sicher, dass ein neuer Block gültig und sicher ist, um ihn der Blockchain hinzuzufügen. Die `execution_payload` selbst ist ein Objekt mit mehreren Feldern. Es gibt auch einen `execution_payload_header`, der wichtige zusammenfassende Informationen über die Ausführungsdaten enthält. Diese Datenstrukturen sind wie folgt organisiert:
Der `execution_payload_header` enthält die folgenden Felder:
-| Feld | Beschreibung |
-|:--------------------- |:------------------------------------------------------------------------------------- |
-| `übergeordneter_hash` | Hash des übergeordneten Blocks |
-| `fee_recipient` | Kontoadresse, an die die Transaktionsgebühren gezahlt werden |
-| `state_root` | Stamm-Hash für den globalen Zustand nach der Anwendung der Änderungen in diesem Block |
-| `receipts_root` | Hash des Transaktionsempfänger-Baums |
-| `logs_bloom` | Datenstruktur, die Ereignisprotokolle enthält |
-| `prev_randao` | Verwendeter Wert in einer zufälligen Validatorauswahl |
-| `block_number` | Die Nummer des aktuellen Blocks |
-| `gas_limit` | Maximales für diesen Block erlaubtes Gas |
-| `gas_used` | Die eingesetzte Menge an Gas in diesem Block |
-| `Zeitstempel` | Die Blockzeit |
-| `extra_data` | Beliebige zusätzliche Daten als rohe Bytes |
-| `base_fee_per_gas` | Der Basisgebührenwert |
-| `block_hash` | Hash des ausführenden Blocks |
-| `transactions_root` | Stamm-Hash der Transaktionen in der Nutzlast |
-| `withdrawal_root` | Stamm-Hash der Abhebungen in der Nutzlast |
-
-Die `execution_payload` selbst enthält Folgendes (das ist identisch zum Header, außer dass es anstatt des Stamm-Hash der Transaktionen die Liste der Transaktions- und Abhebungsinformationen enthält) :
-
-| Feld | Beschreibung |
-|:--------------------- |:------------------------------------------------------------------------------------- |
-| `übergeordneter_hash` | Hash des übergeordneten Blocks |
-| `fee_recipient` | Kontoadresse, an die die Transaktionsgebühren gezahlt werden |
-| `state_root` | Stamm-Hash für den globalen Zustand nach der Anwendung der Änderungen in diesem Block |
-| `receipts_root` | Hash des Transaktionsempfänger-Baums |
-| `logs_bloom` | Datenstruktur, die Ereignisprotokolle enthält |
-| `prev_randao` | Verwendeter Wert in einer zufälligen Validatorauswahl |
-| `block_number` | Die Nummer des aktuellen Blocks |
-| `gas_limit` | Maximales für diesen Block erlaubtes Gas |
-| `gas_used` | Die eingesetzte Menge an Gas in diesem Block |
-| `Zeitstempel` | Die Blockzeit |
-| `extra_data` | Beliebige zusätzliche Daten als rohe Bytes |
-| `base_fee_per_gas` | Der Basisgebührenwert |
-| `block_hash` | Hash des ausführenden Blocks |
-| `Transaktionen` | Liste der Transaktionen, die ausgeführt werden sollen |
-| `abhebungen` | Liste der Abhebungsobjekte |
-
-Die Liste `withdrawals` enthält `withdrawal`-Objekte, die wie folgt strukturiert sind:
+| Feld | Beschreibung |
+| :------------------- | :------------------------------------------------------------------------------------ |
+| `parent_hash` | Hash des übergeordneten Blocks |
+| `fee_recipient` | Kontoadresse, an die die Transaktionsgebühren gezahlt werden |
+| `state_root` | Stamm-Hash für den globalen Zustand nach der Anwendung der Änderungen in diesem Block |
+| `receipts_root` | Hash des Transaktionsempfänger-Baums |
+| `logs_bloom` | Datenstruktur, die Ereignisprotokolle enthält |
+| `prev_randao` | Verwendeter Wert in einer zufälligen Validatorauswahl |
+| `block_number` | Die Nummer des aktuellen Blocks |
+| `gas_limit` | Maximales für diesen Block erlaubtes Gas |
+| `gas_used` | Die eingesetzte Menge an Gas in diesem Block |
+| `timestamp` | Die Blockzeit |
+| `extra_data` | Beliebige zusätzliche Daten als rohe Bytes |
+| `base_fee_per_gas` | Der Basisgebührenwert |
+| `block_hash` | Hash des ausführenden Blocks |
+| `transactions_root` | Stamm-Hash der Transaktionen in der Nutzlast |
+| `withdrawal_root`},{ | Stamm-Hash der Abhebungen in der Nutzlast |
+
+Die `execution_payload` selbst enthält Folgendes (beachten Sie, dass diese mit dem Header identisch ist, außer dass sie anstelle des Root-Hashs der Transaktionen die tatsächliche Liste der Transaktionen und Auszahlungsinformationen enthält):
+
+| Feld | Beschreibung |
+| :----------------- | :------------------------------------------------------------------------------------ |
+| `parent_hash` | Hash des übergeordneten Blocks |
+| `fee_recipient` | Kontoadresse, an die die Transaktionsgebühren gezahlt werden |
+| `state_root` | Stamm-Hash für den globalen Zustand nach der Anwendung der Änderungen in diesem Block |
+| `receipts_root` | Hash des Transaktionsempfänger-Baums |
+| `logs_bloom` | Datenstruktur, die Ereignisprotokolle enthält |
+| `prev_randao` | Verwendeter Wert in einer zufälligen Validatorauswahl |
+| `block_number` | Die Nummer des aktuellen Blocks |
+| `gas_limit` | Maximales für diesen Block erlaubtes Gas |
+| `gas_used` | Die eingesetzte Menge an Gas in diesem Block |
+| `timestamp` | Die Blockzeit |
+| `extra_data` | Beliebige zusätzliche Daten als rohe Bytes |
+| `base_fee_per_gas` | Der Basisgebührenwert |
+| `block_hash` | Hash des ausführenden Blocks |
+| `transaktionen` | Liste der Transaktionen, die ausgeführt werden sollen |
+| `auszahlungen` | Liste der Abhebungsobjekte |
+
+Die `withdrawals`-Liste enthält `withdrawal`-Objekte, die wie folgt strukturiert sind:
| Feld | Beschreibung |
-|:---------------- |:---------------------------------------------- |
-| `address` | Kontoadresse, für die die Abhebung erfolgt ist |
-| `Betrag` | Abgehobener Betrag |
-| `Index` | Abhebungsindexwert |
+| :--------------- | :--------------------------------------------- |
+| `adresse` | Kontoadresse, für die die Abhebung erfolgt ist |
+| `amount` | Abgehobener Betrag |
+| `index` | Abhebungsindexwert |
| `validatorIndex` | Validatorindexwert |
-## Blockzeit {#block-time}
+## Block-Zeit {#block-time}
Die Blockzeit bezieht sich auf die Zeit zwischen Blöcken. In Ethereum wird Zeit in Einheiten zu je zwölf Sekunden aufgeteilt. Diese heißen "Slots". In jedem Slot wird ein Validator ausgewählt, der einen Block vorschlägt. Geht man davon aus, dass alle Validatoren online und voll funktionsfähig sind, wird es in jedem Slot einen Block gegen. Die zugehörige Blockzeit beträgt dann 12 Sekunden. Es kann jedoch vorkommen, dass Validatoren offline sind, wenn sie dazu aufgerufen werden einen Block vorzuschlagen. Der zugehörige Slot bleibt dann leer.
-Diese Implementierung unterscheidet sich von PoW-basierten Blockchain-Systemen, in denen die Erzeugung eines Blocks zu den probabilistischen Verfahren gehört, wodurch die Mining-Schwierigkeit des Protokolls ausgeglichen wird. Die [durchschnittliche Blockverbreitungszeit](https://etherscan.io/chart/blocktime) von Ethereum ist ein perfektes Beispiel für die Implementierung von Proof of Stake und damit für den Wechsel von Proof of Work (PoW) zu Proof of Stake (PoS), der durch eine weitere Anpassung der Blockverbreitungszeit auf 12 Sekunden ermöglicht wurde.
+Diese Implementierung unterscheidet sich von PoW-basierten Blockchain-Systemen, in denen die Erzeugung eines Blocks zu den probabilistischen Verfahren gehört, wodurch die Mining-Schwierigkeit des Protokolls ausgeglichen wird. Die [durchschnittliche Block-Zeit](https://etherscan.io/chart/blocktime) von Ethereum ist ein perfektes Beispiel dafür, wobei der Übergang von Proof-of-Work zu Proof-of-Stake anhand der Konsistenz der neuen 12-Sekunden-Block-Zeit deutlich abgeleitet werden kann.
## Blockgröße {#block-size}
-Ein finaler, wichtiger Hinweis ist, dass Blöcke selbst in ihrer Größe begrenzt sind. Jeder Block hat eine Zielgröße von 30 Millionen Gas, aber die Größe der Blöcke wird entsprechend der Netznachfrage erhöht oder verringert, bis zur Blockgrenze von 60 Millionen Gas (doppelte Zielblockgröße). Das Gas-Limit eines Blocks kann um den Faktor 1/1024 vom Gas-Limit des vorangegangenen Blocks nach oben oder unten justiert werden. Dadurch können Validatoren das Gas-Limit eines Blocks durch Konsens verändern. Die Gesamtmenge des von allen Transaktionen im Block verbrauchten Gases muss unter dem Blockgaslimit liegen. Das ist wichtig, weil dadurch sichergestellt wird, dass Blöcke nicht willkürlich groß sein können. Wenn Blöcke beliebig groß sein könnten, würden weniger leistungsstarke Knoten aufgrund von Platz- und Geschwindigkeitsanforderungen allmählich nicht mehr mit dem Netzwerk Schritt halten können. Je größer der Block, desto höher ist die erforderliche Verarbeitungsleistung, um den Block rechtzeitig für das nächste Zeitintervall zu berechnen. Das ist ein ganz zentraler Aspekt, der durch die Begrenzung der Blockgröße umgangen wird.
+Ein finaler, wichtiger Hinweis ist, dass Blöcke selbst in ihrer Größe begrenzt sind. Jeder Block hat eine Zielgröße von 30 Millionen Gas, aber die Größe der Blöcke wird entsprechend der Netznachfrage erhöht oder verringert, bis zur Blockgrenze von 60 Millionen Gas (doppelte Ziel-Blockgröße). Das Gas-Limit eines Blocks kann um den Faktor 1/1024 vom Gas-Limit des vorangegangenen Blocks nach oben oder unten justiert werden. Dadurch können Validatoren das Gas-Limit eines Blocks durch Konsens verändern. Die Gesamtmenge des von allen Transaktionen im Block verbrauchten Gases muss unter dem Blockgaslimit liegen. Das ist wichtig, weil dadurch sichergestellt wird, dass Blöcke nicht willkürlich groß sein können. Wenn Blöcke beliebig groß sein könnten, würden weniger leistungsstarke Knoten aufgrund von Platz- und Geschwindigkeitsanforderungen allmählich nicht mehr mit dem Netzwerk Schritt halten können. Je größer der Block, desto höher ist die erforderliche Verarbeitungsleistung, um den Block rechtzeitig für das nächste Zeitintervall zu berechnen. Das ist ein ganz zentraler Aspekt, der durch die Begrenzung der Blockgröße umgangen wird.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
_Sie kennen Community-Resourcen die Ihnen geholfen haben? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!_
## Verwandte Themen {#related-topics}
- [Transaktionen](/developers/docs/transactions/)
-- [Ressourcen](/developers/docs/gas/)
+- [Gas](/developers/docs/gas/)
- [Proof-of-Stake](/developers/docs/consensus-mechanisms/pos)
diff --git a/public/content/translations/de/developers/docs/bridges/index.md b/public/content/translations/de/developers/docs/bridges/index.md
new file mode 100644
index 00000000000..d7bfe7514ac
--- /dev/null
+++ b/public/content/translations/de/developers/docs/bridges/index.md
@@ -0,0 +1,138 @@
+---
+title: "Brücken"
+description: "Eine Übersicht über Bridging für Entwickler"
+lang: de
+---
+
+Mit der Verbreitung von L1-Blockchains und L2-[Skalierungslösungen](/developers/docs/scaling/) sowie einer ständig wachsenden Zahl dezentralisierter Anwendungen, die kettenübergreifend arbeiten, ist die Notwendigkeit der Kommunikation und des Transfers von Vermögenswerten über Ketten hinweg zu einem wesentlichen Bestandteil der Netzwerkinfrastruktur geworden. Um dies zu ermöglichen, gibt es verschiedene Arten von Brücken (Bridges).
+
+## Notwendigkeit für kettenübergreifende Brücken {#need-for-bridges}
+
+Es gibt Bridges, um Blockchain-Netzwerke miteinander zu verbinden. Sie ermöglichen Konnektivität und Interoperabilität zwischen Blockchains.
+
+Blockchains existieren in isolierten Umgebungen. Das bedeutet, dass es für Blockchains keine Möglichkeit gibt, auf natürliche Weise mit anderen Blockchains zu transferieren und zu kommunizieren. Dies hat zur Folge, dass es innerhalb eines Ökosystems zwar erhebliche Aktivität und Innovation geben kann, diese aber durch die fehlende Konnektivität und Interoperabilität mit anderen Ökosystemen eingeschränkt ist.
+
+Bridges bieten eine Möglichkeit für isolierte Blockchain-Umgebungen, sich zu connecten. Sie stellen eine Transportroute zwischen Blockchains her, über die Token, Nachrichten, beliebige Daten und sogar [Smart-Contract-Aufrufe](/developers/docs/smart-contracts/) von einer Kette zur anderen übertragen werden können.
+
+## Vorteile von kettenübergreifenden Brücken {#benefits-of-bridges}
+
+Einfach ausgedrückt, ermöglichen Brücken zahlreiche Anwendungsfälle, indem sie es Blockchain-Netzwerken erlauben, Daten auszutauschen und Vermögenswerte zwischen ihnen zu transferieren.
+
+Blockchains haben einzigartige Stärken, Schwächen und Ansätze zum Aufbau von Anwendungen (wie Geschwindigkeit, Durchsatz, Kosten usw.). Bridges tragen zur Entwicklung des gesamten Krypto-Ökosystems bei, indem sie es Blockchains ermöglichen, die Innovationen der anderen zu nutzen.
+
+Für Entwickler ermöglichen Bridges Folgendes:
+
+- Die Übertragung von Daten, Informationen und Vermögenswerten über Ketten hinweg.
+- Die Erschließung neuer Funktionen und Anwendungsfälle für Protokolle, da Bridges den Gestaltungsspielraum für Protokolle erweitern. Zum Beispiel kann ein Protokoll für Yield Farming, das ursprünglich im Ethereum Mainnet eingesetzt wurde, Liquiditätspools über alle EVM-kompatiblen Chains hinweg anbieten.
+- Die Möglichkeit, die Stärken der verschiedenen Blockchains zu nutzen. So können Entwickler beispielsweise von den niedrigeren Gebühren der verschiedenen L2-Lösungen profitieren, indem sie ihre Dapps auf Rollups bzw. Sidechains deployen und Nutzer diese überbrücken können.
+- Zusammenarbeit zwischen Entwicklern aus verschiedenen Blockchain-Ökosystemen, um neue Produkte zu entwickeln.
+- Nutzer und Communities aus verschiedenen Ökosystemen für ihre Dapps gewinnen.
+
+## Wie funktionieren Bridges? {#how-do-bridges-work}
+
+Obwohl es viele [Arten von Designs für kettenübergreifende Brücken](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) gibt, stechen drei Möglichkeiten zur Vereinfachung des kettenübergreifenden Transfers von Vermögenswerten hervor:
+
+- **Sperren und Prägen –** Vermögenswerte auf der Quellkette sperren und auf der Zielkette prägen.
+- **Verbrennen und Prägen –** Vermögenswerte auf der Quellkette verbrennen und auf der Zielkette prägen.
+- **Atomare Swaps –** Tausch von Vermögenswerten auf der Quellkette gegen Vermögenswerte auf der Zielkette mit einer anderen Partei.
+
+## Arten von kettenübergreifenden Brücken {#bridge-types}
+
+Bridges lassen sich in der Regel in eine der folgenden Kategorien einordnen:
+
+- **Native kettenübergreifende Brücken –** Diese kettenübergreifenden Brücken werden in der Regel gebaut, um die Liquidität auf einer bestimmten Blockchain zu fördern, was es den Nutzern erleichtert, Gelder in das Ökosystem zu transferieren. Die [Arbitrum Bridge](https://bridge.arbitrum.io/) wurde beispielsweise gebaut, um es Nutzern zu erleichtern, von Ethereum Mainnet zu Arbitrum zu überbrücken. Andere solche kettenübergreifenden Brücken sind die Polygon PoS Bridge, das [Optimism Gateway](https://app.optimism.io/bridge) usw.
+- **Validator- oder Orakel-basierte kettenübergreifende Brücken –** Diese kettenübergreifenden Brücken stützen sich auf eine externe Gruppe von Validatoren oder Orakel, um kettenübergreifende Übertragungen zu validieren. Beispiele: Multichain und Across.
+- **Generalisierten kettenübergreifenden Brücken zur Nachrichtenübermittlung –** Diese kettenübergreifenden Brücken können Vermögenswerte zusammen mit Nachrichten und beliebigen Daten über Ketten hinweg übertragen. Beispiele: Axelar, LayerZero und Nomad.
+- **Liquiditätsnetzwerke –** Diese kettenübergreifenden Brücken konzentrieren sich in erster Linie auf die Übertragung von Vermögenswerten von einer Kette zur anderen über atomare Swaps. Im Allgemeinen unterstützen sie keine cross-chain Nachrichtenübermittlung. Beispiele: Connext und Hop.
+
+## Zu berücksichtigende Trade-offs {#trade-offs}
+
+Bei Bridges gibt es keine perfekten Lösungen. Vielmehr gibt es Kompromisse, die gemacht werden, um einen bestimmten Zweck zu erfüllen. Entwickler und Benutzer können Bridges anhand der folgenden Faktoren bewerten:
+
+- **Sicherheit –** Wer verifiziert das System? Durch externe Validatoren gesicherte Bridges sind in der Regel weniger sicher als Bridges, die lokal oder nativ durch die Validatoren der Blockchain gesichert sind.
+- **Bequemlichkeit –** Wie lange dauert der Abschluss einer Transaktion und wie viele Transaktionen musste ein Nutzer unterzeichnen? Wie lange braucht ein Entwickler, um eine Bridge zu integrieren, und wie komplex ist der Prozess?
+- **Konnektivität –** Welche verschiedenen Zielketten kann eine kettenübergreifende Brücke verbinden (d. h. Rollups, Sidechains, andere Layer-1-Blockchains usw.) und wie schwierig ist es, eine neue Blockchain zu integrieren?
+- **Fähigkeit, komplexere Daten zu übermitteln –** Kann eine kettenübergreifende Brücke die Übertragung von Nachrichten und komplexeren beliebigen Daten über Ketten hinweg ermöglichen oder unterstützt sie nur kettenübergreifende Vermögensübertragungen?
+- **Kosteneffizienz –** Wie viel kostet die Übertragung von Vermögenswerten über Ketten hinweg über eine kettenübergreifende Brücke? In der Regel erheben Bridges eine feste oder variable Gebühr, die sich nach den Gaskosten und der Liquidität bestimmter Routen richtet. Es ist auch wichtig, die Kosteneffizienz einer Bridge auf der Grundlage des zur Gewährleistung ihrer Sicherheit erforderlichen Kapitals zu bewerten.
+
+Grundlegend können Bridges in "trusted" und "trustless" Bridges unterteilt werden.
+
+- **Vertrauenswürdig –** Vertrauenswürdige kettenübergreifende Brücken werden extern verifiziert. Sie verwenden eine externe Gruppe von Verifizierern (Gruppen mit Mehrsignatur, Mehrparteien-Rechensysteme, Orakelnetzwerke), um Daten über Ketten hinweg zu senden. Infolgedessen können sie eine hohe Konnektivität bieten und eine vollständig generalisierte Nachrichtenübermittlung über Chains hinweg ermöglichen. Sie zeichnen sich auch durch hohe Geschwindigkeit und Kosteneffizienz aus. Dies geht jedoch auf Kosten der Sicherheit, da die Benutzer sich auf die Sicherheit der Bridge verlassen müssen.
+- **Vertrauenslos –** Diese kettenübergreifenden Brücken stützen sich auf die Blockchains, die sie verbinden, und deren Validatoren, um Nachrichten und Token zu übertragen. Sie sind "vertrauenslos", weil sie keine neuen Vertrauensannahmen (zusätzlich zu den Blockchains) hinzufügen. Folglich gelten trustless Bridges als sicherer als trusted Bridges.
+
+Um trustless Bridges auf der Grundlage anderer Faktoren zu bewerten, müssen wir sie in "Generalized message passing bridges" und "Liquidity networks" unterteilen.
+
+- **Generalisierte kettenübergreifende Brücken zur Nachrichtenübermittlung –** Diese kettenübergreifenden Brücken zeichnen sich durch Sicherheit und die Fähigkeit aus, komplexere Daten über Ketten hinweg zu übertragen. In der Regel sind sie auch sehr kosteneffizient. Diese Stärken gehen jedoch in der Regel auf Kosten der Konnektivität bei einfachen Client-Brücken (z. B. IBC) und der Geschwindigkeit bei optimistischen Brücken (z. B. Nomad), die Betrugsnachweise verwenden.
+- **Liquiditätsnetzwerke –** Diese kettenübergreifenden Brücken verwenden atomare Swaps für die Übertragung von Vermögenswerten und sind lokal verifizierte Systeme (d. h. sie verwenden die Validatoren der zugrunde liegenden Blockchains, um Transaktionen zu verifizieren). Daher zeichnen sie sich durch Sicherheit und Geschwindigkeit aus. Außerdem gelten sie als vergleichsweise kostengünstig und bieten eine gute Konnektivität. Der größte Nachteil ist jedoch ihre Unfähigkeit, komplexere Daten zu übertragen, da sie keine cross-chain Nachrichtenübermittlung unterstützen.
+
+## Risiken bei kettenübergreifenden Brücken {#risk-with-bridges}
+
+Kettenübergreifende Brücken sind für die drei [größten Hacks in DeFi](https://rekt.news/leaderboard/) verantwortlich und befinden sich noch in einem frühen Entwicklungsstadium. Die Verwendung von Bridges birgt die folgenden Risiken:
+
+- **Smart-Contract-Risiko –** Obwohl viele kettenübergreifende Brücken Audits erfolgreich bestanden haben, reicht ein einziger Fehler in einem Smart Contract aus, damit Vermögenswerte Hacks ausgesetzt sind (z. B. [Solanas Wormhole Bridge](https://rekt.news/wormhole-rekt/)).
+- **Systemische finanzielle Risiken** – Viele kettenübergreifende Brücken verwenden Wrapped Assets, um kanonische Versionen des ursprünglichen Vermögenswerts auf einer neuen Kette zu prägen. Dies setzt das Ökosystem einem systemischen Risiko aus, da wir gesehen haben, wie gewrappte Versionen von Token ausgenutzt wurden.
+- **Gegenparteirisiko –** Einige kettenübergreifende Brücken verwenden ein vertrauenswürdiges Design, bei dem sich Nutzer darauf verlassen müssen, dass die Validatoren nicht kollaborieren, um Nutzergelder zu stehlen. Da die Nutzer diesen Drittparteien vertrauen müssen, sind sie Risiken wie Absprachen, Zensur und anderen betrügerischen Aktivitäten ausgesetzt.
+- **Offene Fragen –** Da sich kettenübergreifende Brücken in einem frühen Entwicklungsstadium befinden, gibt es viele unbeantwortete Fragen dazu, wie sich kettenübergreifende Brücken unter verschiedenen Marktbedingungen verhalten werden, wie z. B. bei Netzwerküberlastung und bei unvorhergesehenen Ereignissen wie Angriffen auf Netzwerkebene oder State Rollbacks. Diese Ungewissheit birgt gewisse Risiken, deren Ausmaß noch unbekannt ist.
+
+## Wie können Dapps Brücken nutzen? {#how-can-dapps-use-bridges}
+
+Hier sind einige praktische Anwendungen, die Entwickler bei der Integration von Brücken für ihre Cross-Chain-Dapps berücksichtigen können:
+
+### Integration von kettenübergreifenden Brücken {#integrating-bridges}
+
+Entwickler haben verschiedene Möglichkeiten, Bridges zu implementieren:
+
+1. **Eine eigene kettenübergreifende Brücke bauen –** Der Bau einer sicheren und zuverlässigen kettenübergreifenden Brücke ist nicht einfach, besonders wenn man einen vertrauensminimierten Weg wählt. Dies erfordert umfangreiche Erfahrung und technisches Fachwissen in Bezug auf Skalierbarkeit und Interoperabilität. Zudem ist ein Team notwendig, das sich um die Wartung der Brücke kümmert und ausreichend Liquidität anzieht, um sie funktionsfähig zu machen.
+
+2. **Nutzern mehrere Optionen für kettenübergreifende Brücken anzeigen –** Viele [Dapps](/developers/docs/dapps/) erfordern, dass Nutzer ihre nativen Token besitzen, um mit ihnen zu interagieren. Um den Nutzern den Zugriff auf ihre Token zu ermöglichen, können sie verschiedene Bridge-Optionen auf ihrer Plattform anbieten. Diese Methode ist jedoch eine schnelle Lösung und lenkt den Nutzer von der Dapp-Oberfläche weg, da er weiterhin mit anderen Dapps und Bridges interagieren muss. Dies kann zu einem umständlichen Onboarding-Erlebnis mit erhöhtem Fehlerpotenzial führen.
+
+3. **Eine kettenübergreifende Brücke integrieren –** Diese Lösung erfordert nicht, dass die Dapp Nutzer an die externen Schnittstellen der kettenübergreifenden Brücke und DEX sendet. Sie ermöglicht es Dapps, das Onboarding-Erlebnis der Benutzer zu verbessern. Dieser Ansatz hat jedoch seine Grenzen:
+
+ - Die Bewertung und Pflege von Bridges ist schwierig und zeitaufwändig.
+ - Die Auswahl einer Bridge führt zu einem Single Point of Failure und zu Abhängigkeiten.
+ - Die Dapp ist durch die Fähigkeiten der Bridge begrenzt.
+ - Bridges allein reichen möglicherweise nicht aus. Dapps benötigen möglicherweise DEXs, um weitere Funktionen wie Cross-Chain-Swaps anzubieten.
+
+4. **Mehrere kettenübergreifende Brücken integrieren –** Diese Lösung löst viele Probleme, die mit der Integration einer einzigen kettenübergreifenden Brücke verbunden sind. Sie hat jedoch auch ihre Grenzen, da die Integration mehrerer Bridges ressourcenintensiv ist und einen technischen und kommunikativen Mehraufwand für Entwickler bedeutet - die knappste Ressource in der Kryptowirtschaft.
+
+5. **Einen Aggregator für kettenübergreifende Brücken integrieren –** Eine weitere Option für Dapps ist die Integration einer Aggregationslösung für kettenübergreifende Brücken, die ihnen Zugang zu mehreren kettenübergreifenden Brücken gibt. Bridge-Aggregatoren erben die Stärken aller Bridges und sind daher nicht durch die Fähigkeiten einer einzelnen Bridge eingeschränkt. Die Bridge-Aggregatoren übernehmen in der Regel die Wartung der Bridge-Integrationen und ersparen der App damit den Aufwand, sich um die technischen und betrieblichen Aspekte einer Bridge-Integration zu kümmern.
+
+Abgesehen davon haben Bridge-Aggregatoren auch ihre Grenzen. So können sie zwar mehr Bridge-Optionen anbieten, aber auf dem Markt sind in der Regel viel mehr Bridges verfügbar als die, die auf der Plattform des Aggregators angeboten werden. Darüber hinaus sind Bridge-Aggregatoren, genau wie Bridges, auch Smart-Contract- und Technologierisiken ausgesetzt (mehr Smart Contracts = mehr Risiken).
+
+Wenn eine Dapp den Weg der Integration einer Bridge oder eines Aggregators einschlägt, gibt es verschiedene Optionen, je nachdem, wie umfassend die Integration sein soll. Wenn es sich zum Beispiel nur um eine Front-End-Integration handelt, um das Onboarding-Erlebnis des Nutzers zu verbessern, würde eine Dapp das Widget integrieren. Wenn die Integration jedoch tiefergehende cross-chain Strategien wie Staking, Yield Farming usw. umfassen soll, integriert die Dapp das SDK oder die API.
+
+### Eine Dapp auf mehreren Chains bereitstellen {#deploying-a-dapp-on-multiple-chains}
+
+Um eine Dapp auf mehreren Chains bereitzustellen, können Entwickler Entwicklungsplattformen wie [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) usw. verwenden. Diese Plattformen verfügen in der Regel über modulare Plugins, mit denen Dapps cross-chain eingesetzt werden können. Zum Beispiel können Entwickler einen deterministischen Bereitstellungs-Proxy verwenden, der vom [hardhat-deploy-Plugin](https://github.com/wighawag/hardhat-deploy) angeboten wird.
+
+#### Beispiele:
+
+- [Wie man kettenübergreifende Dapps baut](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [Aufbau eines kettenübergreifenden NFT-Marktplatzes](https://youtu.be/WZWCzsB1xUE)
+- [Moralis: Kettenübergreifende NFT-Dapps bauen](https://www.youtube.com/watch?v=ehv70kE1QYo)
+
+### Überwachung der Vertragsaktivität über Ketten hinweg {#monitoring-contract-activity-across-chains}
+
+Zur Überwachung der chain-übergreifenden Contract-Aktivitäten können Entwickler Subgraphen und Entwicklerplattformen wie Tenderly verwenden, um Smart Contracts in Echtzeit zu beobachten. Solche Plattformen verfügen auch über Tools, die eine erweiterte Datenüberwachungsfunktionalität für kettenübergreifende Aktivitäten bieten, wie z. B. die Überprüfung von [Ereignissen, die von Verträgen ausgegeben werden](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events), usw.
+
+#### Tools
+
+- [The Graph](https://thegraph.com/en/)
+- [Tenderly](https://tenderly.co/)
+
+## Weiterführende Lektüre {#further-reading}
+
+- [Blockchain-Brücken](/bridges/) – ethereum.org
+- [L2Beat Bridge Risk Framework](https://l2beat.com/bridges/summary)
+- [Blockchain-Brücken: Aufbau von Netzwerken aus Kryptonetzwerken](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 8. Sep. 2021 – Dmitriy Berenzon
+- [Das Interoperabilitäts-Trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 1. Okt. 2021 – Arjun Bhuptani
+- [Cluster: Wie vertrauenswürdige und vertrauensminimierte kettenübergreifende Brücken die Multi-Chain-Landschaft gestalten](https://blog.celestia.org/clusters/) - 4. Okt. 2021 – Mustafa Al-Bassam
+- [LI.FI: Bei kettenübergreifenden Brücken ist Vertrauen ein Spektrum](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 28. Apr. 2022 – Arjun Chand
+- [Der Stand der Rollup-Interoperabilitätslösungen](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 20. Juni 2024 – Alex Hook
+- [Nutzung gemeinsamer Sicherheit für sichere kettenübergreifende Interoperabilität: Lagrange State Committees und darüber hinaus](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 12. Juni 2024 – Emmanuel Awosika
+
+Zusätzlich finden Sie hier einige aufschlussreiche Präsentationen von [James Prestwich](https://twitter.com/_prestwich), die helfen können, ein tieferes Verständnis für kettenübergreifende Brücken zu entwickeln:
+
+- [Brücken bauen, keine ummauerten Gärten](https://youtu.be/ZQJWMiX4hT0)
+- [Brücken analysieren](https://youtu.be/b0mC-ZqN8Oo)
+- [Warum brennen die Brücken](https://youtu.be/c7cm2kd20j8)
diff --git a/public/content/translations/de/developers/docs/consensus-mechanisms/index.md b/public/content/translations/de/developers/docs/consensus-mechanisms/index.md
index ffbf5c088ab..48bb1e6854c 100644
--- a/public/content/translations/de/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/de/developers/docs/consensus-mechanisms/index.md
@@ -1,6 +1,6 @@
---
title: Konsensmechanismus
-description: Eine Erklärung von Konsensprotokollen in verteilten Systemen und die Rolle, die sie in Ethereum spielen.
+description: "Eine Erklärung von Konsensprotokollen in verteilten Systemen und die Rolle, die sie in Ethereum spielen."
lang: de
---
@@ -8,7 +8,7 @@ Der Begriff „Konsensmechanismus“ wird oft umgangssprachlich verwendet, um
## Voraussetzungen {#prerequisites}
-Um diese Seite besser zu verstehen, empfehlen wir dir, zuerst unsere [Einleitung zu Ethereum](/developers/docs/intro-to-ethereum/) zu lesen.
+Um diese Seite besser zu verstehen, empfehlen wir dir, zuerst unsere [Einführung in Ethereum](/developers/docs/intro-to-ethereum/) zu lesen.
## Was ist ein Konsens? {#what-is-consensus}
@@ -30,25 +30,25 @@ Diese Komponenten bilden zusammen den Konsensmechanismus.
## Arten von Konsensmechanismen {#types-of-consensus-mechanisms}
-### Proof-of-Work-basiert {#proof-of-work}
+### Auf Proof-of-Work basierend {#proof-of-work}
-Wie Bitcoin nutzte auch Ethereum früher ein auf **Proof-of-Work (PoW)** basierendes Konsensprotokoll.
+Wie Bitcoin hat auch Ethereum früher ein auf **Proof-of-Work (PoW)** basierendes Konsensprotokoll verwendet.
-#### Blockerstellung {#pow-block-creation}
+#### Block-Erstellung {#pow-block-creation}
-Miner konkurrieren darum, neue Blöcke voll mit verarbeiteten Transaktionen zu erstellen. Der Gewinner teilt den neuen Block mit dem Rest des Netzwerks und verdient einige frisch geprägte ETH. Das Rennen wird von dem Computer gewonnen, der ein mathematisches Rätsel am schnellsten lösen kann. Dies erzeugt die kryptografische Verbindung zwischen dem aktuellen Block und dem vorherigen Block. Die Lösung dieses Rätsels ist die Arbeit („Work“) in „Proof-of-Work“. Die kanonische Chain wird dann durch eine Abspaltungs-Wahl-Regel bestimmt, bei der die Reihe von Blöcken ausgewählt wird, für deren Mining die meiste Arbeit geleistet wurde.
+Miner konkurrieren darum, neue Blöcke voll mit verarbeiteten Transaktionen zu erstellen. Der Gewinner teilt den neuen Block mit dem Rest des Netzwerks und verdient einige frisch geminte ETH. Das Rennen wird von dem Computer gewonnen, der ein mathematisches Rätsel am schnellsten lösen kann. Dies erzeugt die kryptografische Verbindung zwischen dem aktuellen Block und dem vorherigen Block. Die Lösung dieses Rätsels ist die Arbeit („Work“) in „Proof-of-Work“. Die kanonische Chain wird dann durch eine Abspaltungs-Wahl-Regel bestimmt, bei der die Reihe von Blöcken ausgewählt wird, für deren Mining die meiste Arbeit geleistet wurde.
#### Sicherheit {#pow-security}
Die Sicherheit des Netzwerks wird dadurch gewährleistet, dass Sie 51 % der Rechenleistung des Netzwerks brauchen, um die Chain zu betrügen. Das würde so große Investitionen in Ausrüstung und Energie erfordern, dass Sie wahrscheinlich mehr ausgeben würden, als Sie einnehmen.
-Mehr über [Proof-of-Work](/developers/docs/consensus-mechanisms/pow/)
+Mehr zu [Proof-of-Work](/developers/docs/consensus-mechanisms/pow/)
-### Proof-of-Stake-basiert {#proof-of-stake}
+### Auf Proof-of-Stake basierend {#proof-of-stake}
Ethereum verwendet jetzt ein auf **Proof-of-Stake (PoS)** basierendes Konsensprotokoll.
-#### Blockerstellung {#pos-block-creation}
+#### Block-Erstellung {#pos-block-creation}
Validatoren erstellen Blöcke. In jedem Slot wird zufällig ein Validator als Block-Proposer ausgewählt. Ihr Konsens-Client fordert ein Bündel von Transaktionen als „Ausführungsnutzlast“ von ihrem gekoppelten Ausführungs-Client an. Sie verpacken dies in Konsensdaten, um einen Block zu bilden, den sie an andere Nodes im Ethereum-Netzwerk senden. Diese Blockproduktion wird mit ETH belohnt. In seltenen Fällen, wenn für einen einzigen Slot mehrere mögliche Blöcke existieren oder Nodes zu unterschiedlichen Zeiten von Blöcken erfahren, wählt der Abspaltungs-Wahl-Algorithmus den Block aus, der die Chain mit dem größten Gewicht an Attestierungen bildet (wobei das Gewicht die Anzahl der attestierenden Validatoren ist, skaliert nach ihrem ETH-Guthaben).
@@ -58,35 +58,35 @@ Ein Proof-of-Stake-System ist kryptoökonomisch sicher, weil ein Angreifer, der
Mehr zu [Proof-of-Stake](/developers/docs/consensus-mechanisms/pos/)
-### Ein visueller Leitfaden {#types-of-consensus-video}
+### Eine visuelle Anleitung {#types-of-consensus-video}
Erfahren Sie mehr über die verschiedenen Arten von Konsensmechanismen, die auf Ethereum verwendet werden:
-### Sybil: Widerstand & Kettenauswahl {#sybil-chain}
+### Sybil-Resistenz & Kettenauswahl {#sybil-chain}
Proof-of-Work und Proof-of-Stake sind für sich genommen keine Konsensprotokolle, aber sie werden oft der Einfachheit halber als solche bezeichnet. Sie sind eigentlich Sybil-Widerstandsmechanismen und Blockautor-Selektoren; sie bieten eine Möglichkeit, zu entscheiden, wer der Autor des letzten Blocks ist. Eine weitere wichtige Komponente ist der Chain-Auswahl-(auch Abspaltungs-Wahl-)Algorithmus. Er ermöglicht es Nodes, in Szenarien, bei denen mehrere Blöcke in der gleichen Position existieren, einen einzigen korrekten Block an der Spitze der Chain auszuwählen.
-Mit dem **Sybil-Widerstand** wird gemessen, wie ein Protokoll gegen einen Sybil-Angriff abschneidet. Der Widerstand gegen diese Art von Angriffen ist für eine dezentrale Blockchain unerlässlich und ermöglicht es Minern und Validatoren, gleichermaßen entsprechend der eingesetzten Ressourcen belohnt zu werden. Proof-of-Work und Proof-of-Stake schützen davor, indem sie die Benutzer dazu bringen, viel Energie aufzuwenden oder viele Sicherheiten bereitzustellen. Diese Schutzmaßnahmen sind eine wirtschaftliche Abschreckung gegen Sybil-Angriffe.
+**Sybil-Resistenz** misst, wie gut ein Protokoll gegen einen Sybil-Angriff abschneidet. Der Widerstand gegen diese Art von Angriffen ist für eine dezentrale Blockchain unerlässlich und ermöglicht es Minern und Validatoren, gleichermaßen entsprechend der eingesetzten Ressourcen belohnt zu werden. Proof-of-Work und Proof-of-Stake schützen davor, indem sie die Benutzer dazu bringen, viel Energie aufzuwenden oder viele Sicherheiten bereitzustellen. Diese Schutzmaßnahmen sind eine wirtschaftliche Abschreckung gegen Sybil-Angriffe.
-Eine **Chain-Auswahlregel** wird verwendet, um zu entscheiden, welche Chain die „richtige“ ist. Bitcoin verwendet die „längste Chain“-Regel. Das bedeutet, dass die Blockchain, die am längsten ist, von den restlichen Nodes als gültig akzeptiert wird, sodass sie mit ihr arbeiten. Bei Proof-of-Work-Chains wird die längste Chain auf Basis der gesamten kumulativen Proof-of-Work-Schwierigkeit der Chain bestimmt. Bei Ethereum kam früher auch die „längste Chain“-Regel zur Anwendung; jetzt, da Ethereum auf Proof-of-Stake läuft, hat es jedoch einen aktualisierten Abspaltungs-Wahl-Algorithmus übernommen, der das „Gewicht“ der Kette bestimmt. Das Gewicht entspricht der kumulierten Summe der Validatorenstimmen, gewichtet nach den in Ether eingesetzten Beträgen der Validatoren.
+Eine **Kettenauswahlregel** wird verwendet, um zu entscheiden, welche Kette die "richtige" ist. Bitcoin verwendet die „längste Chain“-Regel. Das bedeutet, dass die Blockchain, die am längsten ist, von den restlichen Nodes als gültig akzeptiert wird, sodass sie mit ihr arbeiten. Bei Proof-of-Work-Chains wird die längste Chain auf Basis der gesamten kumulativen Proof-of-Work-Schwierigkeit der Chain bestimmt. Bei Ethereum kam früher auch die „längste Chain“-Regel zur Anwendung; jetzt, da Ethereum auf Proof-of-Stake läuft, hat es jedoch einen aktualisierten Abspaltungs-Wahl-Algorithmus übernommen, der das „Gewicht“ der Kette bestimmt. Das Gewicht entspricht der kumulierten Summe der Validatorenstimmen, gewichtet nach den in Ether eingesetzten Beträgen der Validatoren.
-Ethereum verwendet einen Konsensmechanismus, bekannt als [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/), der [Casper FFG-Proof-of-Stake](https://arxiv.org/abs/1710.09437) mit der [GHOST-Abspaltungs-Wahl-Regel](https://arxiv.org/abs/2003.03052) kombiniert.
+Ethereum verwendet einen Konsensmechanismus, der als [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) bekannt ist und der [Casper FFG Proof-of-Stake](https://arxiv.org/abs/1710.09437) mit der [GHOST Fork-Choice-Regel](https://arxiv.org/abs/2003.03052) kombiniert.
-## Weiterführende Informationen {#further-reading}
+## Weiterführende Lektüre {#further-reading}
-- [Was ist ein Blockchain-Konsens-Algorithmus?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
+- [Was ist ein Blockchain-Konsensalgorithmus?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
- [Was ist der Nakamoto-Konsens? Vollständiger Leitfaden für Anfänger](https://blockonomi.com/nakamoto-consensus/)
- [Wie funktioniert Casper?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
-- [Über die Sicherheit und Leistungsfähigkeit von Proof-of-Work-Blockchains](https://eprint.iacr.org/2016/555.pdf)
+- [Über die Sicherheit und Leistung von Proof-of-Work-Blockchains](https://eprint.iacr.org/2016/555.pdf)
- [Byzantinischer Fehler](https://en.wikipedia.org/wiki/Byzantine_fault)
-_Gibt es Community-Resourcen, die Sie hilfreich fanden? Bearbeiten Sie diese Seite und fügen Sie sie hinzu._
+_Sie kennen Community-Resourcen die Ihnen geholfen haben? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!_
## Verwandte Themen {#related-topics}
- [Proof-of-Work](/developers/docs/consensus-mechanisms/pow/)
- [Mining](/developers/docs/consensus-mechanisms/pow/mining/)
- [Proof-of-Stake](/developers/docs/consensus-mechanisms/pos/)
-- [Proof-of-authority](/developers/docs/consensus-mechanisms/poa/)
+- [Proof-of-Authority](/developers/docs/consensus-mechanisms/poa/)