Ein Blick hinter die Kulissen verteilter Validatoren

Validator-Key-Sharding und verteilte Schlüsselerzeugung (DKG)

DKG
Bei einem klassischen Ethereum-Validator wird ein einzelner privater Schlüssel verwendet, um Nachrichten zu signieren, Blöcke zu attestieren und neue Blöcke vorzuschlagen. Dieser Schlüssel befindet sich üblicherweise auf einem einzigen Gerät. Fällt dieses Gerät aus oder wird kompromittiert, besteht für den Validator das Risiko von Ausfallzeiten oder Slashing. Das Distributed Validator Technology (DVT)-Verfahren löst dieses Problem, indem es das Prinzip eines einzelnen Geräts mit vollständigem Schlüsselbesitz abschafft. Der Schlüssel wird stattdessen von Beginn an verteilt erzeugt – mit einem Verfahren namens Distributed Key Generation (DKG).

Im DKG-Prozess erzeugen mehrere Teilnehmer gemeinsam einen privaten Schlüssel, ohne dass ein Teilnehmer das gesamte Geheimnis kennt. Jeder Teilnehmer erhält einen Anteil am privaten Schlüssel des Validators. Zum Einsatz kommen fortschrittliche kryptografische Verfahren, die gewährleisten, dass der resultierende öffentliche Schlüssel dem erwarteten BLS (Boneh–Lynn–Shacham)-Schlüssel entspricht, wie er im Ethereum-Konsensprotokoll verwendet wird. Die erzeugten Schlüsselanteile sind mathematisch miteinander verknüpft, sodass sie später gemeinsam genutzt werden können, um im Namen des Validators gültige Signaturen zu erzeugen.

Key Sharding über DKG ist ein grundlegendes Sicherheitsmerkmal von DVT. Da kein einzelner Teilnehmer den gesamten Schlüssel kontrolliert, ist die Validator-Architektur von vornherein widerstandsfähig gegen Kompromittierungen. Selbst wenn ein Knoten kompromittiert wird oder offline geht, kann die Gruppe weiterarbeiten, solange der erforderliche Schwellenwert an Schlüsselanteilen zum Signieren verfügbar ist.

Threshold-BLS-Signaturen und Multipartei-Berechnung (MPC)

Nachdem die Schlüsselanteile verteilt wurden, muss der Validator-Cluster seine Signaturaufgaben – also das Vorschlagen von Blöcken und Abgeben von Attestierungen – erfüllen, ohne dass der vollständige private Schlüssel jemals rekonstruiert wird. Hier kommen Threshold-BLS-Signaturen und die Multipartei-Berechnung (MPC) zum Einsatz.

Das in der Ethereum-Konsensschicht eingesetzte BLS-Signaturschema unterstützt Schwellenwertsignaturen. In einer DVT-Architektur ist es erforderlich, dass eine vordefinierte Anzahl Teilnehmer zusammenwirkt, um eine Signatur zu erzeugen. In einem Cluster mit fünf Knoten können beispielsweise beliebige drei eine gültige Signatur generieren. Der Schwellenwert wird im Rahmen der Schlüsselerzeugung festgelegt und definiert die Fehlertoleranz des Validators.

Das Signaturverfahren wird mittels sicherer Multipartei-Berechnung durchgeführt. Jeder Teilnehmer signiert die Nachricht mit seinem eigenen Schlüsselanteil. Die entstandenen Teilsignaturen werden anschließend zu einer vollständigen BLS-Signatur aggregiert, die an die Ethereum Beacon Chain gesendet werden kann. Zu keinem Zeitpunkt während dieses Vorgangs wird der vollständige private Schlüssel rekonstruiert oder offengelegt.

MPC gewährleistet, dass der Validator auch bei Anwesenheit von unzuverlässigen oder potenziell nicht vertrauenswürdigen Teilnehmern weiterhin sicher betrieben werden kann. Durch kryptografische Garantien ist es möglich, dass eine Gruppe unabhängiger Knoten gegenüber dem Netzwerk wie ein einzelner Validator auftritt. Diese Abstraktion ist entscheidend für die Kompatibilität von DVT mit Ethereum, ohne dass Änderungen am Protokoll oder an den Konsensregeln erforderlich sind.

Gossipbasierte Koordination und Client-Kompatibilität

Ein DVT-Cluster umfasst mehrere Knoten, die als Teil eines verteilten Validator-Clients operieren. Damit diese Knoten synchron bleiben, Aufgaben koordinieren und Informationen wie Blockvorschläge, Attestierungen oder Teilsignaturen austauschen können, kommunizieren sie kontinuierlich. Die meisten DVT-Systeme setzen hierfür auf eine gossipbasierte Peer-to-Peer-Kommunikationsschicht.

In einem Gossip-Netzwerk verbreiten die Knoten Nachrichten, indem sie sie an einen Teil ihrer Peers weiterleiten, die diese Information wiederum im Netzwerk verteilen. Dieses dezentrale Modell minimiert das Risiko von Kommunikationsengpässen und verhindert, dass ein einzelner Knoten zum zentralen Kommunikationspunkt wird. Gossip-Protokolle sind robust gegenüber Knotenausfällen und Netzwerkpartitionen und eignen sich daher besonders zur Koordination von Validatoren.

Der verteilte Validator-Client – zum Beispiel Obols Charon oder die Node-Software von SSV.Network – realisiert die Koordination beim Signieren, Fehlerbehandlung sowie die Nachverfolgung der Teilnahme. Diese Clients sind kompatibel mit allen gängigen Ethereum-Validator-Stacks wie Prysm, Lighthouse, Teku oder Nimbus. Somit kann jeder Knoten im DVT-Cluster einen Standard-Ethereum-Konsensclient verwenden und parallel die DVT-Logik betreiben.

Die Kompatibilität der Clients ist für die Verbreitung von zentraler Bedeutung. Betreiber müssen ihre Infrastruktur nicht grundlegend umbauen, um DVT einzusetzen. Sie können weiter auf bewährte Softwarelösungen zurückgreifen und profitieren dennoch von höherer Ausfallsicherheit und geteilter Verantwortung. Durch diese Plug-and-Play-Architektur lässt sich DVT nahtlos in bestehende Staking-Prozesse einbinden, ohne den betrieblichen Aufwand zu erhöhen.

Latenz, Quorumgröße und Annahmen zur ehrlichen Mehrheit

Obwohl DVT die Dezentralisierung und Ausfallsicherheit verbessert, bringt das Verfahren auch gewisse Kompromisse mit sich. Die Latenz zählt dabei zu den wichtigsten Aspekten. Beim klassischen Validator erfolgt die Signatur direkt auf einer lokalen Maschine. In einer DVT-Architektur muss die Signatur jedoch über mehrere Knoten koordiniert und von jedem ein Teilbeitrag geleistet werden, bevor das finale Ergebnis erzeugt ist. Dies bedeutet einen höheren Kommunikationsaufwand und kann bei Netzwerkauslastung oder langsamen Teilnehmern zu Verzögerungen führen.

Zur Reduzierung dieses Effekts legen DVT-Systeme ein Quorum fest – also die minimale Knotenanzahl, die notwendig ist, um eine Signatur zu erzeugen. Die Größe des Quorums bestimmt das Gleichgewicht zwischen Sicherheit und Verfügbarkeit. Ein kleineres Quorum erhöht Geschwindigkeit und die Widerstandskraft gegenüber langsamen Knoten, senkt jedoch die Fehlertoleranz. Ein größeres Quorum verbessert die Fehlertoleranz, kann aber die Signaturerstellung verlangsamen und anfälliger für Verzögerungen machen.

In einem 5-aus-7-DVT-Cluster müssen zum Beispiel mindestens fünf beliebige Knoten online und reaktionsfähig sein, um eine Signatur zu generieren. Die Architektur toleriert damit den Ausfall von bis zu zwei Knoten. Fällt mehr als diese Zahl aus, kann der Validator keine Signaturen mehr leisten und riskiert wegen Ausfallzeiten Sanktionen. Die Wahl dieser Parameter sollte sich nach der Risikobereitschaft des Clusters und der räumlichen Verteilung der Knoten richten.

Alle DVT-Verfahren beruhen auf der Annahme einer ehrlichen Mehrheit. Das Protokoll geht davon aus, dass eine vorgegebene Zahl von Knoten korrekt arbeitet und im Sinne des Netzwerks agiert. Werden zu viele Knoten kompromittiert oder verhalten sich in böswilliger Absprache, könnten ungültige Signaturen entstehen oder der Validator absichtlich an der Teilnahme gehindert werden. Auch wenn solche Szenarien bei sorgfältig konzipierten Clustern unwahrscheinlich sind, müssen sie in Bedrohungsanalysen und beim Betrieb berücksichtigt werden.

In der Praxis werden DVT-Cluster häufig von unabhängigen Betreibern oder in Staking-Kollektiven mit gemeinsamen Interessen gebildet. Das senkt das Risiko von Kollusion und erhöht die Systemsicherheit. Mit wachsender Reife der Technologie können neue Koordinationsmechanismen, Vertrauensmodelle und Reputationssysteme entstehen, um die Sicherheit und Verlässlichkeit der verteilten Validierung weiter zu stärken.