DeFiChain - Die natürliche Impfung gegen Hacks
Die meisten der aktuellen DeFi-Projekte laufen auf Blockchains wie Ethereum, Binance Smart Chain — einer Ethereum-Fork —, Tron oder anderen. Sie alle teilen sich die gleiche Architektur, bei der dApps auf virtuellen Maschinen auf einer Blockchain laufen. Im Gegensatz zu nativen Blockchains bieten Turing-komplette-Blockchains eine größere Flexibilität für Entwickler, da der Programmiercode direkt auf der virtuellen Maschine und somit auf der Blockchain ausgeführt wird. Während dieses Design-Paradigma für eine Vielzahl unterschiedlicher Anwendungen nützlich erscheinen mag, ist es andererseits jedoch für dezentrale Finanzanwendungen äußerst riskant.
Im folgenden Artikel werden wir die Unterschiede, sowie die Vor- und Nachteile von Blockchains, die keine virtuelle Maschine verwenden und bei denen der Programmiercode direkt auf der nativen Blockchain ausgeführt wird, skizzieren. Folglich wird zunächst ein Vergleich zwischen diesen beiden Konzepten dargeboten, bevor der Fokus auf die Funktionsweise und die integralen Bausteine einer virtuellen Maschine gelegt wird. Anschließend vergleichen wir Blockchains, bei denen Transaktionen durch Zuhilfenahme einer virtuellen Maschine ausgeführt werden, mit jenen Blockchains, bei denen Transaktionen nativ ausgeführt werden, bevor wir mit einer Zusammenfassung abschließen werden.
Überblick über Native DeFi vs. DeFi unter Zuhilfenahme einer virtuellen Maschine
Da Native DeFi für die DeFi-Community noch ein recht neues Konzept ist, gibt Tabelle 1 einen Überblick über die wichtigsten Unterschiede zwischen jenen beiden konkurrierenden Konzepten.
Was ist eine virtuelle Maschine?
Es gibt derzeit unzählige von dApps, die auf der Ethereum-Blockchain laufen — einer Turing kompletten Blockchain, die einem weltweiten Peer-to-Peer-Allzweck-Computer gleichkommt und auf dem nahezu alles programmiert und ausgeführt werden kann was die eigene Vorstellungskraft hergibt. Jeder, der schon einmal versucht hat, einen Smart Contract auf der Ethereum-Blockchain zu entwickeln, der sollte bereits mit dem Begriff "EVM" vertraut sein — eine Abkürzung für Ethereum Virtual Machine.
Eine virtuelle Maschine schafft im Wesentlichen eine Abstraktionsebene zwischen der Ausführung des Codes auf der einen Seite und der ausführenden Maschine selbst auf der anderen. Die EVM ermöglicht somit die Ausführung von Programmiercode in einem vertrauenslosen Ökosystem, in dem das Ausführungsergebnis garantiert und vollständig deterministisch ist. Wann immer Anweisungen in der EVM implementiert werden, verfolgt ein System die Ausführungskosten und weist diesen Anweisungen einen zugehörigen Gaspreis zu.
Da jeder dApps auf Ethereum programmieren kann, sind diese Gas-Gebühren insofern wichtig, als dass sie als eine Art “Preisschild” für die Interaktion der dApp mit der virtuellen Maschine fungieren. Folglich muss jeder User für jede Interaktion auf Ethereum einige Ether in Form von Gas-Gebühren bezahlen. Dieser Mechanismus garantiert, dass ein “Validator” den im Voraus bezahlten Betrag erhält, selbst wenn die Ausführung fehlschlägt. Auf der anderen Seite kann eine Ausführung auch nicht länger dauern, als es der im Voraus bezahlte Betrag erlauben würde, wodurch die Möglichkeit einer Endlosschleife verhindert wird.
Doch diese Architektur garantiert keine schnellen und kostengünstigen Transaktionen. Es ist kein Geheimnis, dass Ethereum unter astronomisch hohen Transaktionsgebühren leidet, wodurch es nicht in der Lage ist, die erhebliche Last neuer Nutzer zu bewältigen. Der Großteil der DeFi-Projekte ist derzeit mit Ethereum verbunden, das in seiner aktuellen Form wohl mit verkalkten und verengten Arterien im menschlichen Körper verglichen werden kann. Auch wenn es vor einigen Jahren noch Sinn ergeben haben mag, ist das Ethereum-Netzwerk inzwischen zu einem regelrechten Flaschenhals geworden. Daher muss an neuen Lösungen gearbeitet werden, um u.a. dieses immanente Problem zu lösen — vor allem durch skalierbare, sichere und kosteneffiziente Transaktionen, die direkt auf der Konsensebene der Blockchain durchgeführt werden.
Beim Thema Sicherheit haben die verschiedenen DeFi-Stakeholder unterschiedliche Präferenzen und Herangehensweisen. Während Entwickler das Thema aus einer rein technischen Perspektive betrachten und sicherstellen, dass der Programmiercode korrekt ausgeführt wird und reibungslos funktioniert, ist es für User ausschließlich wichtig, dass DeFi-Projekte zu ihren Gunsten funktionieren, indem Hacks und bösartige Angriffe unterbunden werden.
Genau an jenem Konfliktpunkt kommt DeFiChain ins Spiel. Im Gegensatz zu EVM oder ähnlichen Blockchains, die sich einer virtuellen Maschine bedienen, legt DeFiChain den Fokus auf seine Benutzer und deren Wünsche, indem es eine sichere DeFi-Plattform bereitstellt, die tief in der nativen Blockchain verwurzelt ist.
Unterschied im Konsens-Mechanismus zwischen DeFiChain und Ethereum
Um ein besseres Verständnis über die sicherheitstechnischen Vorzüge der DeFiChain im Vergleich zu Layer-2-dApps zu erhalten, möchten wir im folgenden gerne erklären, wie der Programmiercode auf den jeweiligen Plattformen ausgeführt wird und wo dabei potenzielle Probleme und Schwachstellen auftreten könnten.
DeFi auf Ethereum
Der Workflow — von der Erstellung des Codes bis zu dessen Ausführung — ist auf Ethereum komplett anders gestaltet als auf DeFiChain. Auf Ethereum werden die meisten Smart Contracts in einer High-Level-Programmsprache namens Solidity geschrieben. Dieser Code wird dann über einen Solc-Compiler kompiliert. Sobald ein Solidity-Vertrag mit solc kompiliert ist, muss der daraus resultierende Maschinencode durch die EVM laufen, bevor er schließlich durch den Blockchain-Konsens validiert wird (siehe Abbildung 1).
Während jenes Prozesses der Kompilierung können nun jedoch Probleme auftreten. Diese reichen von menschlichen Fehlern und Programmierfehlern in jeder einzelnen Phase des Smart-Contract-Erstellungs- und Anwendungsprozesses bis hin zu ernsthaften Kompilierungs-, respektive Transpilierungsfehlern des Compilers selbst. Eines der größten Probleme hierbei ist, dass der Compiler im schlimmsten Fall sogar einen beliebigen Maschinencode erzeugen kann, der böswilligen Akteuren unvorhergesehene Angriffsvektoren eröffnet.
Ein weiteres Problem, mit dem selbst erfahrene Teams konfrontiert sind, betrifft die richtige Verwendung des Solidity-Codes, von dem vor allem neue und unerfahrene Programmierer betroffen sind. Die vielleicht erstaunlichste Erkenntnis jedoch ist, dass nicht einmal Audits gegen diese Sicherheitslücken helfen. Folglich bietet ein Multi-Millionen-Dollar-Audit keine Garantie dafür, dass ein Projekt auch sicher ist und dass es Hacks verhindern kann.
DeFi auf DeFiChain
Bei Native DeFi hingegen findet der Konsens direkt auf der nativen Blockchain-Ebene statt — es wird somit keine zusätzliche Anwendungsschicht benötigt. Um Transaktionen zu validieren reicht die Hauptblockchain-Ebene von DeFiChain aus, was sie somit viel sicherer als Blockchains mit virtuellen Maschinen macht. Die meisten der zuvor erwähnten Schwachstellen bei Turing-kompletten, respektive auf virtuellen Maschinen basierende Blockchains können bei DeFiChain komplett außer Acht gelassen werden (wie in Abbildung 2 gezeigt). Am wichtigsten bei alledem ist jedoch, dass der Konsens direkt auf der DeFiChain-Blockchain stattfindet.
Die Interaktion von DeFiChain mit dem User erfolgt dabei — anders als bei konkurrierenden DEXs wie Uniswap oder 1inch — über eine intuitive App. Dieser Ansatz garantiert größtmögliche Dezentralität bei gleichzeitiger Verringerung einer möglichen Angriffsfläche für Hacks. DNS-Angriffe, wie sie zuletzt bei CREAM Finance und Pancake Swap zu beobachten waren, gehören damit der Vergangenheit an. Der ausschlaggebende Grund hierfür ist, dass die DeFiChain DEX direkt in die App eingebettet ist und komplett Peer-to-Peer über Tausende von Computern läuft, was einen isolierten Website-Angriff unmöglich macht.
Beispiel
Um sich ein besseres Bild von der Konsensfindung und den dazu nötigen Schritten zu machen, ist es sinnvoll sich anzusehen, wie Liquidität auf Uniswap (Ethereum), und im Vergleich dazu, auf DeFiChain hinzugefügt wird. Zu diesem Zweck wollen wir einen Blick auf die folgende Transaktion werfen, die auf der Ethereum-Blockchain getätigt wurde: https://etherscan.io/vmtrace?txhash=0xb51f3aedd963065f0b3c8cf2473a6fe929ba6803a9d87b55c36159f4e7f58abd.
Abbildung 3 zeigt alle einzelnen Schritte, die von den Minern zur Validierung der Transaktionen durchgeführt werden müssen. Dabei ist ersichtlich, dass es mehr als dreitausend unterschiedlicher Schritte bedarf um Liquidität einem Liquiditätspool hinzuzufügen. Frappierend hierbei ist, dass jeder einzelne Schritt eine potenzielle Angriffsfläche für Hacks darstellt. Es ist ferner wichtig, sich vor Augen zu führen, dass die EVM einfach genau dem Programmiercode Folge leistet, oder anders ausgedrückt, die EVM folgt genau was ihr aufgetragen wird. Im obigen Beispiel besteht dieser Auftrag aus dreitausend Schritten, wobei das Endergebnis weder bekannt ist noch auf Gültigkeit überprüft wird.
Dieselbe Transaktion auf DeFiChain steht in diametralem Gegensatz dazu (wie in Abbildung 4 zu erkennen ist). Der korrespondierende Transaktions-Hash auf DeFiChain lautet: a767e065e2234615c465414bf76129335e9b4083711f56f83e256e91c943f0e3
Um Liquidität auf DeFiChain hinzuzufügen sind nur ein paar Zeilen Code vonnöten. In Abbildung 4 ist ersichtlich, dass DFI (Ergebnisparameter 0) und der entsprechende Betrag an BTC (Ergebnisparameter 2) dem DFI-BTC-Liquiditätspool hinzugefügt werden. Als unmittelbares Ergebnis wird dann der Liquiditäts-Token auf die unter "shareaddress" angezeigte Adresse übertragen. Diese paar Zeilen Code reichen aus um Liquidität zu einem Pool auf DeFiChain hinzuzufügen — es sind somit keine 3.700 einzelnen Anweisungen nötig, um eine relativ einfache Aufgabe wie obige auszuführen. Nebst dessen wird durch die Reduzierung der Durchführungsschritte die potenzielle Angriffsfläche für Hacks stark reduziert.
Zusammenfassung
Native DeFi ist ein neuartiges und lang erwartetes Konzept im DeFi-Bereich um endlich die Interessen der Programmierer und Entwickler mit jenen der Community in Einklang bringen zu können. Die Maxime lautet nicht mehr "wir kümmern uns nur um unseren Code", sondern es wird zum ersten Mal eine kundenorientierte und auf Sicherheit ausgelegt Sichtweise eingenommen.
Vor allem angesichts der anhaltenden Exploits und "Rug Pulls" — selbst bei bereits auditierten Projekten — bleiben die Sicherheitsbedenken von Layer-2-Projekten auf Blockchains wie Ethereum ein Problem, das einfach nicht vernachlässigt werden darf.
Einige Sicherheitsfirmen prognostizieren für 2021 bereits das schlimmste Jahr für DeFi-Datenschutzverletzungen und Hacks. Daher ist es nur allzu verständlich und nur eine Frage der Zeit, bis mehr User auf den Geschmack nach Native-DeFi-Projekten wie etwa DeFiChain kommen. Der Grund hierfür ist recht einfach: Einerseits wollen sich immer weniger User potenziellen Schwachstellen und Sicherheitsrisiken aussetzen aber gleichzeitig haben sie auch vermehrt Sehnsucht nach mehr Dezentralität.
Um über aktuelle Informationen und Neuigkeiten auf dem Laufenden zu bleiben, folgt uns doch auf Twitter oder tretet unserer Telegram-Gruppe bei.