Klingsorstr. 6, 12167 Berlin
+49 151 22668185
luehrs.alexander@gmail.com

Die Bedeutung der Dezentralisierung (Vitalik Buterin)

Die Bedeutung der Dezentralisierung (Vitalik Buterin)

“Dezentralisierung” ist eines der Wörter, die in der Kryptowirtschaft am häufigsten verwendet werden, und wird oft sogar als die gesamte Daseinsberechtigung einer Blockchain angesehen, aber es ist auch eines der Wörter, die vielleicht am schlechtesten definiert sind. Tausende von Forschungsstunden und Milliarden von Dollar an Hashpower wurden einzig und allein für den Versuch aufgewendet, Dezentralisierung zu erreichen, sie zu schützen und zu verbessern, und wenn Diskussionen rivalisierend werden, ist es äußerst üblich, dass die Befürworter eines Protokolls (oder einer Protokollerweiterung) als ultimatives Totschlagargument behaupten, die gegnerischen Vorschläge seien “zentralisiert”.

Aber es herrscht oft große Verwirrung darüber, was dieses Wort eigentlich bedeutet. Betrachten Sie z. B. das folgende, völlig wenig hilfreiche, aber leider allzu häufige Diagramm:

Betrachten Sie die beiden Antworten auf Quora auf die Frage “Was ist der Unterschied zwischen dezentral und dezentral”. Die erste gibt im Wesentlichen das obige Diagramm wieder, während die zweite die völlig andere Behauptung aufstellt, dass “dezentral bedeutet, dass nicht die gesamte Verarbeitung der Transaktionen am selben Ort stattfindet”, während “dezentral bedeutet, dass nicht eine einzige Einheit die Kontrolle über die gesamte Verarbeitung hat”. Die oberste Antwort auf der Ethereum-Stack-Börse zeigt ein sehr ähnliches Diagramm, bei dem jedoch die Wörter “dezentralisiert” und “verteilt” vertauscht sind! Hier ist eindeutig eine Klarstellung angebracht.

Drei Arten der Dezentralisierung
Wenn man von Software-Dezentralisierung spricht, gibt es eigentlich drei verschiedene Achsen der Zentralisierung/Dezentralisierung, über die man sprechen kann. Während es in einigen Fällen schwierig ist zu sehen, wie man das eine ohne das andere haben kann, sind sie im Allgemeinen ziemlich unabhängig voneinander. Die Achsen sind wie folgt:

  • Architektonische (De-)Zentralisierung – aus wie vielen physischen Computern besteht ein System? Wie viele dieser Computer können zu einem bestimmten Zeitpunkt ausfallen?
  • Politische (De-)Zentralisierung – wie viele Personen oder Organisationen kontrollieren letztendlich die Computer, aus denen das System besteht?
  • Logische (De-)Zentralisierung – ähneln die Schnittstelle und die Datenstrukturen, die das System präsentiert und verwaltet, eher einem einzelnen monolithischen Objekt oder einem amorphen Schwarm? Eine einfache Heuristik lautet: Wenn man das System in zwei Hälften teilt, die sowohl Anbieter als auch Nutzer umfassen, funktionieren dann beide Hälften weiterhin vollständig als unabhängige Einheiten?
    Wir können versuchen, diese drei Dimensionen in einem Diagramm darzustellen:

Beachten Sie, dass viele dieser Einteilungen sehr grob und höchst fragwürdig sind. Aber lassen Sie uns versuchen, sie alle durchzugehen:

Traditionelle Unternehmen sind politisch zentralisiert (ein CEO), architektonisch zentralisiert (ein Hauptsitz) und logisch zentralisiert (man kann sie nicht wirklich in zwei Hälften teilen)
Das Zivilrecht stützt sich auf eine zentralisierte gesetzgebende Instanz, während das Gewohnheitsrecht auf Präzedenzfällen beruht, die von vielen einzelnen Richtern geschaffen werden. Das Zivilrecht hat immer noch eine gewisse architektonische Dezentralisierung, da es viele Gerichte gibt, die dennoch einen großen Ermessensspielraum haben, aber das Common Law hat mehr davon. Beide sind logischerweise zentralisiert (“das Gesetz ist das Gesetz”).

Sprachen sind logisch dezentralisiert; das Englisch, das zwischen Alice und Bob gesprochen wird, und das Englisch, das zwischen Charlie und David gesprochen wird, müssen überhaupt nicht übereinstimmen. Es gibt keine zentralisierte Infrastruktur, die für die Existenz einer Sprache erforderlich ist, und die Regeln der englischen Grammatik werden nicht von einer einzigen Person geschaffen oder kontrolliert (wohingegen Esperanto ursprünglich von Ludwig Zamenhof erfunden wurde, obwohl es jetzt eher wie eine lebende Sprache funktioniert, die sich schrittweise und ohne Autorität entwickelt).

BitTorrent ist logischerweise dezentralisiert, ähnlich wie die englische Sprache. Content-Delivery-Netzwerke sind ähnlich, werden aber von einem einzigen Unternehmen kontrolliert.
Blockchains sind politisch dezentralisiert (niemand kontrolliert sie) und architektonisch dezentralisiert (kein zentraler Infrastrukturausfallpunkt), aber sie sind logisch zentralisiert (es gibt einen gemeinsam vereinbarten Zustand und das System verhält sich wie ein einzelner Computer).

Wenn Leute über die Vorzüge einer Blockchain sprechen, beschreiben sie oft die Vorteile einer “zentralen Datenbank”; diese Zentralisierung ist eine logische Zentralisierung, und es ist eine Art der Zentralisierung, die in vielen Fällen wohl gut ist (obwohl Juan Benet vom IPFS auch auf logische Dezentralisierung drängen würde, wo immer dies möglich ist, weil logisch dezentralisierte Systeme dazu neigen, Netzwerkpartitionen gut zu überstehen, in Regionen der Welt mit schlechter Konnektivität gut zu funktionieren usw.; siehe auch diesen Artikel von Scuttlebot, der ausdrücklich für logische Dezentralisierung eintritt).

Eine architektonische Zentralisierung führt oft zu einer politischen Zentralisierung, wenn auch nicht unbedingt – in einer formalen Demokratie treffen sich Politiker in einer physischen Regierungskammer und halten dort Abstimmungen ab, aber die Verwalter dieser Kammer erlangen dadurch keine wesentliche Macht über die Entscheidungsfindung. In computergestützten Systemen kann es zu einer architektonischen, aber nicht politischen Dezentralisierung kommen, wenn es eine Online-Gemeinschaft gibt, die aus Bequemlichkeit ein zentralisiertes Forum nutzt, in dem aber ein weithin vereinbarter sozialer Vertrag besteht, dass jeder in ein anderes Forum wechselt, wenn die Eigentümer des Forums böswillig handeln (Gemeinschaften, die sich aus Rebellion gegen das, was sie als Zensur in einem anderen Forum ansehen, bilden, haben diese Eigenschaft in der Praxis wahrscheinlich).

Logische Zentralisierung macht architektonische Dezentralisierung schwieriger, aber nicht unmöglich – siehe wie dezentralisierte Konsensnetzwerke bereits bewiesen haben, dass sie funktionieren, aber schwieriger sind als die Aufrechterhaltung von BitTorrent. Und logische Zentralisierung macht politische Dezentralisierung schwieriger – in logisch zentralisierten Systemen ist es schwieriger, Streitigkeiten zu lösen, indem man sich einfach darauf einigt, “zu leben und leben zu lassen”.

Drei Gründe für Dezentralisierung
Die nächste Frage lautet: Warum ist Dezentralisierung überhaupt sinnvoll? Es werden im Allgemeinen mehrere Argumente angeführt:

Fehlertoleranz – bei dezentralen Systemen ist es weniger wahrscheinlich, dass sie versehentlich ausfallen, da sie sich auf viele einzelne Komponenten stützen, bei denen dies unwahrscheinlich ist.
Widerstandsfähigkeit gegen Angriffe – dezentrale Systeme sind teurer anzugreifen und zu zerstören oder zu manipulieren, weil es keine empfindlichen zentralen Punkte gibt, die zu viel geringeren Kosten angegriffen werden können als die wirtschaftliche Größe des umgebenden Systems.
Widerstandsfähigkeit gegen geheime Absprachen – es ist für Teilnehmer an dezentralen Systemen viel schwieriger, sich abzusprechen, um auf Kosten anderer Teilnehmer zu handeln, während die Führungen von Unternehmen und Regierungen ständig Absprachen treffen, die ihnen selbst zugute kommen, aber weniger gut koordinierte Bürger, Kunden, Angestellte und die Allgemeinheit schädigen.
Alle drei Argumente sind wichtig und stichhaltig, aber alle drei Argumente führen zu einigen interessanten und unterschiedlichen Schlussfolgerungen, wenn man anfängt, über Protokollentscheidungen unter Berücksichtigung der drei einzelnen Perspektiven nachzudenken. Lassen Sie uns versuchen, jedes dieser Argumente einzeln zu erläutern.

Was die Fehlertoleranz betrifft, so ist das Kernargument einfach. Was ist unwahrscheinlicher: der Ausfall eines einzelnen Computers oder der Ausfall von fünf von zehn Computern zur gleichen Zeit? Das Prinzip ist unumstritten und wird im wirklichen Leben in vielen Situationen angewandt, z. B. bei Düsentriebwerken, Notstromaggregaten, insbesondere in Krankenhäusern, militärischen Infrastrukturen, der Diversifizierung von Finanzportfolios und eben auch bei Computernetzen.

Diese Art der Dezentralisierung ist zwar immer noch wirksam und äußerst wichtig, erweist sich jedoch oft als weit weniger Allheilmittel, als ein naives mathematisches Modell manchmal vorhersagen würde. Der Grund dafür ist der Gleichtaktfehler. Sicherlich ist die Wahrscheinlichkeit, dass vier Düsentriebwerke ausfallen, geringer als bei einem Düsentriebwerk, aber was wäre, wenn alle vier Triebwerke in derselben Fabrik hergestellt wurden und ein Fehler in allen vier Triebwerken von demselben untreuen Mitarbeiter verursacht wurde?

Sind Blockchains in ihrer heutigen Form in der Lage, vor Gleichtaktausfällen zu schützen? Nicht unbedingt. Betrachten Sie die folgenden Szenarien:

Alle Knoten in einer Blockchain führen dieselbe Client-Software aus, und es stellt sich heraus, dass diese Client-Software einen Fehler hat.

Alle Knoten in einer Blockchain führen dieselbe Client-Software aus, und es stellt sich heraus, dass das Entwicklerteam dieser Software sozial korrumpiert ist.

Das Forschungsteam, das Protokoll-Upgrades vorschlägt, erweist sich als sozial korrupt.
In einer Proof-of-Work-Blockchain befinden sich 70 % der Miner im selben Land, und die Regierung dieses Landes beschließt, alle Mining-Farmen aus Gründen der nationalen Sicherheit zu beschlagnahmen.

Der Großteil der Mining-Hardware wird von ein und demselben Unternehmen gebaut, und dieses Unternehmen wird bestochen oder gezwungen, eine Hintertür zu implementieren, durch die diese Hardware nach Belieben abgeschaltet werden kann.

Bei einer Proof-of-Stake-Blockchain werden 70 % der im Umlauf befindlichen Münzen an einer Börse gehalten.

Eine ganzheitliche Betrachtung der Dezentralisierung der Fehlertoleranz würde alle diese Aspekte berücksichtigen und prüfen, wie sie minimiert werden können. Einige Schlussfolgerungen, die sich daraus ergeben, sind ziemlich offensichtlich:

Es ist von entscheidender Bedeutung, mehrere konkurrierende Implementierungen zu haben.
Das Wissen über die technischen Überlegungen, die hinter Protokollverbesserungen stehen, muss demokratisiert werden, damit sich mehr Menschen an den Forschungsdiskussionen beteiligen und eindeutig schlechte Protokolländerungen kritisieren können.

Die Hauptentwickler und Forscher sollten bei mehreren Unternehmen oder Organisationen angestellt sein (alternativ können viele von ihnen ehrenamtlich tätig sein).

Die Mining-Algorithmen sollten so konzipiert sein, dass das Risiko einer Zentralisierung minimiert wird.
Idealerweise verwenden wir Proof of Stake, um das Risiko der Zentralisierung von Hardware vollständig zu vermeiden (obwohl wir auch vorsichtig sein sollten gegenüber neuen Risiken, die durch Proof of Stake auftauchen).

Beachten Sie, dass sich die Anforderung an die Fehlertoleranz in ihrer naiven Form auf die architektonische Dezentralisierung konzentriert, aber wenn Sie anfangen, über die Fehlertoleranz der Gemeinschaft nachzudenken, die die laufende Entwicklung des Protokolls steuert, dann ist auch die politische Dezentralisierung wichtig.

Betrachten wir nun die Angriffsresistenz. Bei einigen rein wirtschaftlichen Modellen kommt man manchmal zu dem Ergebnis, dass Dezentralisierung gar keine Rolle spielt. Wenn Sie ein Protokoll erstellen, bei dem die Validierer garantiert 50 Millionen Dollar verlieren, wenn ein 51%iger Angriff (d.h. eine endgültige Umkehrung) stattfindet, dann spielt es keine Rolle, ob die Validierer von einem Unternehmen oder von 100 Unternehmen kontrolliert werden – 50 Millionen Dollar wirtschaftliche Sicherheitsspanne sind 50 Millionen Dollar wirtschaftliche Sicherheitsspanne. Tatsächlich gibt es tiefgreifende spieltheoretische Gründe, warum Zentralisierung diese Vorstellung von wirtschaftlicher Sicherheit sogar maximieren kann (das Transaktionsauswahlmodell bestehender Blockchains spiegelt diese Erkenntnis wider, da die Aufnahme von Transaktionen in Blöcke durch Miner/Blockproposer eigentlich eine sehr schnell rotierende Diktatur ist).

Sobald man jedoch ein umfassenderes Wirtschaftsmodell annimmt, und insbesondere eines, das die Möglichkeit von Zwang zulässt (oder viel mildere Dinge wie gezielte DoS-Angriffe gegen Knoten), wird die Dezentralisierung wichtiger. Wenn man eine Person mit dem Tod bedroht, sind 50 Millionen Dollar plötzlich nicht mehr so wichtig für sie. Aber wenn die 50 Millionen Dollar auf zehn Personen verteilt sind, müssen Sie zehnmal so viele Personen bedrohen, und zwar alle gleichzeitig. Generell ist die moderne Welt in vielen Fällen durch eine Angriffs-/Verteidigungsasymmetrie zugunsten des Angreifers gekennzeichnet – ein Gebäude, dessen Bau 10 Millionen Dollar kostet, kann weniger kosten als die Zerstörung von 100.000 Dollar, aber die Hebelwirkung des Angreifers ist oft sublinear: Wenn die Zerstörung eines Gebäudes, dessen Bau 10 Millionen Dollar kostet, 100.000 Dollar kostet, kann die Zerstörung eines Gebäudes, dessen Bau 1 Million Dollar kostet, realistischerweise vielleicht 30.000 Dollar kosten. Kleiner ergibt bessere Verhältnisse.

Wozu führt diese Argumentation? Erstens spricht sie stark für den Proof of Stake gegenüber dem Proof of Work, da Computerhardware leicht zu erkennen, zu regulieren oder anzugreifen ist, während Münzen viel leichter versteckt werden können (der Proof of Stake ist auch aus anderen Gründen sehr angriffsresistent). Zweitens spricht dies für weit verteilte Entwicklungsteams, auch geografisch. Drittens bedeutet dies, dass sowohl das Wirtschaftsmodell als auch das Fehlertoleranzmodell bei der Entwicklung von Konsensprotokollen berücksichtigt werden müssen.

Schließlich kommen wir zu dem vielleicht kompliziertesten der drei Argumente, der Kollusionsresistenz. Kollusion ist schwer zu definieren; vielleicht ist die einzige wirklich gültige Art, es zu formulieren, einfach zu sagen, dass Kollusion “Koordination ist, die wir nicht mögen”. Im wirklichen Leben gibt es viele Situationen, in denen eine perfekte Koordination zwischen allen Beteiligten zwar ideal wäre, aber eine Untergruppe, die in der Lage ist, sich zu koordinieren, während die anderen dies nicht können, gefährlich ist.

Ein einfaches Beispiel ist das Kartellrecht – absichtliche regulatorische Schranken, die errichtet werden, um es den Teilnehmern auf einer Seite des Marktes zu erschweren, sich zusammenzuschließen und wie ein Monopolist zu handeln und auf Kosten der anderen Seite des Marktes und des allgemeinen gesellschaftlichen Wohlergehens einseitige Gewinne zu erzielen. Ein weiteres Beispiel sind die Vorschriften gegen die aktive Koordinierung zwischen Kandidaten und Super-PACs in den Vereinigten Staaten, die sich in der Praxis allerdings als schwer durchsetzbar erwiesen haben. Ein viel kleineres Beispiel ist eine Regel in einigen Schachturnieren, die zwei Spieler daran hindert, viele Partien gegeneinander zu spielen, um die Punktzahl des einen Spielers zu erhöhen. Wo man auch hinschaut, überall wird versucht, unerwünschte Koordination in hochentwickelten Institutionen zu verhindern.

Bei Blockchain-Protokollen stützt sich die mathematische und wirtschaftliche Begründung für die Sicherheit des Konsenses häufig auf das Modell der unkoordinierten Wahl oder die Annahme, dass das Spiel aus vielen kleinen Akteuren besteht, die unabhängig voneinander Entscheidungen treffen. Wenn ein Akteur mehr als ein Drittel der Mining-Leistung in einem Proof-of-Work-System erhält, kann er durch egoistisches Mining übergroße Gewinne erzielen. Können wir jedoch wirklich sagen, dass das Modell der unkoordinierten Entscheidungen realistisch ist, wenn 90 % der Mining-Leistung des Bitcoin-Netzwerks so gut koordiniert sind, dass sie gemeinsam auf der gleichen Konferenz erscheinen?

Die Befürworter der Blockchain argumentieren auch, dass Blockchains sicherer sind, weil sie ihre Regeln nicht einfach willkürlich ändern können, wann immer sie wollen, aber dieses Argument wäre schwer zu verteidigen, wenn die Entwickler der Software und des Protokolls alle für ein Unternehmen arbeiten, Teil einer Familie sind und in einem Raum sitzen. Der springende Punkt ist, dass diese Systeme nicht wie eigennützige Einheitsmonopole handeln sollten. Man kann also durchaus die These aufstellen, dass Blockchains sicherer wären, wenn sie besser koordiniert wären.

Dies stellt jedoch ein grundlegendes Paradoxon dar. Viele Gemeinschaften, darunter auch die von Ethereum, werden oft für ihren starken Gemeinschaftsgeist gelobt und dafür, dass sie in der Lage sind, eine Hard Fork zur Behebung von Denial-of-Service-Problemen im Protokoll innerhalb von sechs Tagen zu implementieren, freizugeben und zu aktivieren. Aber wie können wir diese gute Art der Koordination fördern und verbessern, aber gleichzeitig die “schlechte Koordination” verhindern, die darin besteht, dass Miner versuchen, alle anderen zu bescheißen, indem sie wiederholt 51%ige Angriffe koordinieren?

Es gibt drei Möglichkeiten, diese Frage zu beantworten:
Bemühen Sie sich nicht darum, unerwünschte Koordination abzuschwächen, sondern versuchen Sie stattdessen, Protokolle zu entwickeln, die ihr widerstehen können.
Versuchen Sie, einen goldenen Mittelweg zu finden, der genügend Koordination zulässt, damit sich ein Protokoll weiterentwickeln kann, aber nicht genug, um Angriffe zu ermöglichen.
Versuchen Sie, zwischen nützlicher und schädlicher Koordinierung zu unterscheiden, und machen Sie erstere einfacher und letztere schwieriger.
Der erste Ansatz macht einen großen Teil der Casper-Designphilosophie aus. Er allein ist jedoch unzureichend, da die beiden anderen Kategorien von Bedenken gegen die Dezentralisierung nicht berücksichtigt werden können, wenn man sich nur auf die wirtschaftlichen Aspekte stützt. Der zweite Ansatz ist schwer explizit zu entwickeln, vor allem auf lange Sicht, aber er geschieht oft zufällig. Die Tatsache, dass die Bitcoin-Kernentwickler im Allgemeinen Englisch, die Miner aber Chinesisch sprechen, kann beispielsweise als glücklicher Zufall betrachtet werden, da dadurch eine Art “Zweikammer”-Governance entsteht, die die Koordination erschwert, mit dem Nebeneffekt, dass das Risiko eines Scheiterns im Gleichtakt verringert wird, da die englische und die chinesische Gemeinschaft aufgrund von Entfernungen und Kommunikationsschwierigkeiten zumindest teilweise getrennt voneinander denken und es daher weniger wahrscheinlich ist, dass beide denselben Fehler machen.

Der dritte Punkt ist vor allem eine soziale Herausforderung; diesbezügliche Lösungen können sein:

Soziale Interventionen, die versuchen, die Loyalität der Teilnehmer gegenüber der Gemeinschaft rund um die Blockchain als Ganzes zu erhöhen und die Möglichkeit einer direkten Loyalität der Akteure auf einer Seite eines Marktes zueinander zu ersetzen oder zu unterbinden.

Förderung der Kommunikation zwischen verschiedenen “Marktseiten” im gleichen Kontext, um die Möglichkeit zu verringern, dass entweder Validierer oder Entwickler oder Miner beginnen, sich als eine “Klasse” zu sehen, die sich koordinieren muss, um ihre Interessen gegen andere Klassen zu verteidigen.

Gestaltung des Protokolls in einer Art und Weise, die den Anreiz für Validierer/Miner verringert, sich auf eins-zu-eins “besondere Beziehungen”, zentralisierte Relais-Netzwerke und andere ähnliche Super-Protokoll-Mechanismen einzulassen.

Klare Normen über die grundlegenden Eigenschaften, die das Protokoll haben soll, und welche Dinge nicht oder zumindest nur unter sehr extremen Umständen getan werden sollten.

Diese dritte Art der Dezentralisierung, Dezentralisierung als unerwünschte Koordinationsvermeidung, ist daher vielleicht am schwierigsten zu erreichen, und Kompromisse sind unvermeidlich. Die beste Lösung könnte darin bestehen, sich stark auf die eine Gruppe zu stützen, die garantiert ziemlich dezentralisiert ist: die Benutzer des Protokolls.

Quelle und übersetzt von: Medium.com

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.