Warum Zensurresistenz nicht nimmer eine gute Eigenschaft einer Blockchain ist

Blockchains verändern die Art und Weise, wie Besitzverhältnisse in Gemeinschaften dargestellt und verwaltet werden. Nutzer müssen sich dabei nicht mehr auf zentrale Instanzen wie Banken oder Notare verlassen, um Transaktionen zu beglaubigen. Software, die auf mehreren Computern parallel läuft, sogenannte Netzwerkknoten, übernehmen diese Aufgabe. Eine Eigenschaft, die von den Communitys immer besonders gepriesen wird, ist die sogenannte Zensurresistenz: Transaktionen bzw. Zustände der verteilten Datenbanken können nicht rückgängig gemacht werden. Dies trifft allerdings nur teilweise zum Wohl aller Nutzer zu, sehen wir uns an, warum.

Keine Blockchain ist 100 % zensurresistent

Obwohl immer davon gesprochen wird, dass Zensurresistenz eine absolute Eigenschaft ist (entweder ja oder nein), ist sie relativ. Blockchains oder DLTs sind nicht zu 100 % zensurresistent. Eine Blockchain kann theoretisch angegriffen werden oder die Community entscheidet sich dazu, Transaktionen rückgängig zu machen oder den Status des Ledgers zu ändern. Ein bekanntes Beispiel hierfür ist der Ethereum Hardfork von 2016 oder der von Bitcoin von 2010. Am Ende ist eine Blockchain so zensurresistent, wie stark die Community diesem Prinzip folgt und wie groß ein eventueller Schaden ist bzw. wer betroffen ist. Würde z. B. bei Bitcoin durch einen Fehler ein Großteil aller Coins in die Hände eines Hackers gelangen und der Betrieb des Netzwerkes somit keinen Sinn mehr ergeben, würde sogar die Bitcoin Community die Blockchain zurücksetzen, soviel ist sicher.

Auch technisch gesehen können drei Miningpools bei Bitcoin Transaktionen zensieren, da sie über 51 % der Hashrate hinter sich haben. Der Nutzer verlässt sich allerdings darauf, dass die angeschlossenen Miner dem Prinzip der Zensurresistenz folgen und den Pool wechseln, sollten so etwas passieren.

Der Nutzer will Sicherheit, nicht Zensurresistenz

Zensurresistenz ist nicht die letzte Eigenschaft, die ein Blockchainnutzer erreichen möchte. Er möchte, dass sein Kapital sicher vor fremden Zugriffen ist und dies glaubt er mit Zensurresistenz zu erreichen. Zensurresistenz ist also Mittel zum Zweck. Aber erreicht man mit dem Mittel auch den Zweck? Nicht immer. Die gesamte Sicherheit des Guthabens auf einer Blockchain hängt von einer Kette an Faktoren ab. Die Sicherheit der gesamten Kette ist immer so stark wie ihr schwächstes Glied. So muss der Nutzer dem Gerät (Smartphone / Laptop) vertrauen, mit dem er auf die Blockchain zugreift, der Software (Wallets) und vielem mehr. Bei Smart Contract Plattformen wie Ethereum, Polkadot oder EOS kommt ein schwaches Glied in der Sicherheitskette hinzu: die Fehleranfälligkeit von Code. Enthält der Code eines Smart Contracts Sicherheitslücken, wird Zensurresistenz zum Problem. Mehr dazu weiter unten.

Bei Bitcoin ist das Paradigma der Zensurresistenz möglicherweise sinnvoll

Bitcoin ist die älteste Blockchain. Den Code betrachtend hat sie nur einen Smart Contract, der relativ einfach und unkompliziert ist. Der Code von Bitcoin ist seit über 10 Jahren geprüft und Fehler dadurch unwahrscheinlich. Die integrierte Forth-ähnliche Skriptsprache ist nicht turingvollständig und daher weniger fehleranfällig auf Kosten von Flexibilität und Ausdrucksmächtigkeit. Alle diese Eigenschaften könnten dazu führen, dass bei Bitcoin keine gröbere Sicherheitslücke mehr existiert. Sollte dem aber dennoch so sein und sie eines Tages ausgenutzt werden, hängt es wie bereits geschrieben von der Höhe des Schadens ab, ob die Bitcoin Community an ihrem Zensurresistenz-Paradigma festhält. Dass sie ihre Blockchain aufgibt, wenn ein großer Schaden entsteht, ist sehr unwahrscheinlich.

Smart Contract Plattformen und Zensurresistenz

Immer wieder hört man, dass durch Ausnutzen von Sicherheitslücken in Smart Contracts auf Ethereum und anderen Plattformen große Mengen an Kapital entwendet werden. Manchmal kommt es zu Vergütungen bzw. teilweise Vergütungen. Sehr oft verliert der Nutzer allerdings sein Kapital. Allein im Jahr 2020 sollen über 500 Mio. $ durch Hacks auf Ethereum verloren gegangen sein. Das ist deutlich mehr als auf zentralen Kryptobörsen. Kryptobörsen geben das ggf. entwendete Kapital ihren Kunden oft zurück. So nach dem Bitfinex Hack von 2016 oder dem Binance Hack von 2019. Zudem bieten auch diese Unternehmen gute Zinsen auf Coin Staking an. So betrachtet ist das Staken seiner Coins auf z. B. Binance sicherer als das Nutzen von Ethereum DeFi. Man fragt sich, wo steckt also der Sinn hinter DeFi? Können diese Konzepte jemals zu Massenanwendung führen oder bleiben sie eine Wette auf die Fähigkeiten der Programmierer?

Lösungsansätze

Wie wir gesehen haben, macht DeFi nicht viel Sinn, wenn zentrale Unternehmen sicherer sind als dezentrale Blockchains. Der größte Schwachpunkt für die Sicherheit ist, wie bereits geschrieben, die Fehleranfälligkeit von Code. Es gibt einige Lösungsansätze, welche diesem Problem entgegenwirken sollen.

Umstieg auf weniger Fehleranfällige Programmiersprachen

Einige Smart Contract Plattformen nutzen z. B. funktionale Programmiersprachen, um die Fehleranfälligkeit des Codes zu reduzieren. Dazu gehören Cardano mit Haskell, Tezos mit OCaml oder Aeternity mit Erlang. Es gibt hier jedoch einige Nachteile. Erstens wird die Fehleranfälligkeit nur eingeschränkt und Fehler nicht vollständig vermieden. Es kann daher immer noch zu Fehlern kommen, die eventuell Millionenschäden anrichten in einem dezentralen Finanznetzwerk. Zweitens sind funktionale Programmiersprachen im Gegensatz zu den imperativen Programmiersprachen nicht besonders verbreitet und der Umstieg ist aufwändig, was die Entwicklergemeinde vorerst deutlich einschränken dürfte. Des Weiteren kann man mit imperativen Programmiersprachen wesentlich effizienter Laufzeitoptimierungen am Code vornehmen.

Bedingte Eingriffe durch die Community

Bei Ethereum kam es 2016 zu einer Aufspaltung der Blockchain, weil ein Hacker eine Sicherheitslücke ausgenutzt und empfindliche Summen an Kapital entwendet hat. Die Community verstieß darauf gegen ihre eigenen “Code is Law” Prinzipien um den Schaden rückgängig zu machen. Nicht alle waren einverstanden und es entstanden zwei Ketten: Ethereum mit der Wiederherstellung des alten Zustands vor dem Hack und Ethereum Classic ohne Eingriff.

Bei EOS geht man einen anderen Weg. Die Community verfolgt einen “Intent of Code is Law” (Absicht des Codes ist Gesetz) Ansatz. Macht der Code nicht was er sollte, können die Blockproducer eingreifen und den gewünschten Zustand wiederherstellen. Zensurresistenz ist hier also an die Bedingung geknüpft, dass der Code das macht, was er soll. Hierfür wird die Absicht des Codes in nativer Sprache beschrieben, damit die Community prüfen kann, ob ein Fehler passiert ist und so dem Eingreifen der Konsensknoten ggf. zustimmen oder es verneinen. Auch sind für die Smart Contracts gewisse Auflagen zu erfüllen, damit ein Eingreifen möglich ist. So muss der Code z. B. von kompetenten Unternehmen geprüft worden sein. Im Mai 2021 kam es auf der EOS Blockchain zu einem Hack eines geprüften Smart Contracts. Der Hacker konnte 1,2 Mio. EOS stehlen. Die Blockproducer haben eingegriffen und des Hackers Konten eingefroren, später wurde das Geld den rechtmäßigen Besitzern zurückgegeben.

Die EOS Blockchain ist auf technisch auf die Communityprinzipien der bedingten Zensurresistenz zugeschnitten. Es ist einfacher zwischen 21 Blockproduzenten einen Konsens zu finden und etwaige Hacker vor den Augen der Community aufzuhalten als mit hunderten Konsensknoten. Trotzdem werden die Blockproduzenten überwacht, damit sie sich ehrlich verhalten. Die Community wählt die Blockproducer mit ihren Token.

Das ganze Prinzip ist noch nicht vollständig entwickelt und die Community berät gerade über die Bedingungen, wann eingegriffen werden kann, wer die kurzfristigen Entscheidungen trifft und wie man den ganzen Prozess vereinfacht. Am ganzen Prinzip sieht man, dass es sicherer ist als ein zentraler Anbieter. Die Vorgänge werden hier von der gesamten Community überwacht, während bei einem zentralen Anbieter dieser tun und lassen kann, was er will.

Fazit

Blockchains sind in erster Linie dazu da, um das Kapital der Nutzer sicherer zu machen. Durch die Fehleranfälligkeit von Code ist diese Sicherheit stark gefährdet. Zentrale Dienste sind sicherer als neue, noch wenig getestete Smart Contracts. Smart Contracts kann man erst dann wirklich testen, wenn sie genutzt werden und damit ein Anreiz für Hacker da ist, Sicherheitslücken auszunutzen. Auch sicherere Programmiersprachen werden wahrscheinlich nicht genügend Sicherheit bringen, um viel Kapital sicher genug zu handhaben.

Unter diesen Bedingungen ist absolute Zensurresistenz eher ein Nachteil als ein Vorteil. Die Sicherheit hängt wie bei allem dezentralen Netzwerken davon ab, wie stark die Community ihren Prinzipien folgt. Ein Nutzer, der Smart Contracts nutzt, sollte sich also die Frage stellen, welchen Prinzipien die Community folgt, welcher er sein Kapital anvertraut. Eine “Code ist Gesetz” (Zensurresistenz) vertretende Community bedeutet nicht unbedingt die größte Sicherheit für ihn. Das Gute am Ganzen ist, dass es viele Communitys mit unterschiedlichen Prinzipien und der Nutzer so mehr Auswahlmöglichkeiten hat.