Am Freitag veröffentlichte Dan Robinson, der sich auf Twitter als Anwalt und Programmierer bezeichnet, einen brisanten Blogpost über das Ethereum Netzwerk. Laut seiner Analyse gibt es zahlreiche Bots, welche den Ethereum-Mempool (alle noch nicht bestätigten Transaktionen) nach Möglichkeiten durchsuchen, um auf Kosten anderer Profit zu schlagen.
Nutzer versendet versehentlich falsche Token an Smart Contract
Das Problem vor Augen geführt bekommen, hat Robinson als er von einem Ethereum-Nutzer kontaktiert wurde. Dieser wollte Liquidität für ein Uniswap Handelspaar zur Verfügung stellen. Dabei hat er aber nicht die dafür erforderlichen Token gesendet, sondern die dazugehörigen Pool-Token. Pool-Token sind normalerweise Token, die man beim Hinterlegen des Originals in den Pool bekommt, um später wieder das Original mit Zinsen abholen zu können. Der Wert der Token belief sich auf rund 12.000 $.
Anfänglich ging Robinson davon aus, dass die Token für immer verloren seien, doch dann kam er drauf, dass der Kontrakt die Funktion “burn” implementiert. Diese Funktion vernichtet alle Pool-Token die der Kontrakt enthält und sendet die dazugehörigen originalen Token an eine gewünschte Adresse, die man beim Funktionsaufruf mit übergibt. Mit anderen Worten, jeder kann diese Token beheben, wenn er davon weiß.
Pläne für die Rückholung
Robinson dachte zuerst, dass er einfach nur diese “burn” Funktion mit der Adresse des Nutzers aufrufen müsse, um die Token herauszukriegen und gut. Er schritt aber nicht sofort zur Tat, sondern machte sich Gedanken. Es ist naheliegend, dass wo Profite winken es Anstrengungen gibt, sich diese zu holen. Es ist kein Geheimnis, dass Bots den Mempool von Ethereum rund um die Uhr im Auge behalten, um solche Transaktionen abzufangen und zu überschreiben in dem sie ihnen beim Rennen zuerst in einen Block zu kommen zuvorkommen (höherer Gaspreis z. B.).
Die Uniswap Kontrakte sind standardisiert. Jeder kann jederzeit einen Pool mit einem neuen ETH/ERC-20 oder ERC-20/ERC-20 Handelspaar eröffnen. Deshalb ist es für den Angreifer einfacher den Mempool auf bestimmte Funktionsaufrufe zu überprüfen, als jeden Smart Contract einzeln zu überwachen. Wenn nun eine Transaktion welche “burn” aufruft im Mempool landet, sind die Angreifer alarmiert.
Robinson war klar, dass sehr wahrscheinlich jemand auf das Geschenk wartet, welches er mit dem Senden der Transaktion übergeben würde. Er beschloss sich Mithilfe von Experten die Transaktion zu verschleiern. Dazu installierte er zwei Smart Contracts auf dem Hauptnetz. Einer davon ruft die “burn” Funktion auf, nachdem er vom anderen davor aktiviert wurde.
Die Bots waren schneller
Wegen ein paar Missgeschicken kam dem Team dann ein Bot zuvor und holte sich die Coins im Wert von 12.000 $ ab: Als die Kontrakte auf Ethereum abgelegt waren, sendeten sie die Transaktion, welche den Kontrakt aktivierte, der dann die “burn” Funktion aufrufen sollte. Als sie dann diesem Kontrakt den Befehl zum Aufrufen von “burn” senden wollten, gab die Wallet einen Fehler, weil der Gas-Schätzer nicht manuell überschrieben werden konnte. Es verstrich wichtige Zeit und die zweite Transaktion kam deshalb in einen späteren Block.
Dieser kleine Fehler reichte aus, um den Angreifern zum Erfolg zu verhelfen. Robinson gab zu Fehler gemacht zu haben, und dass man durch mehr Sorgfalt die Token wahrscheinlich hätte zurückholen können. Er verweist aber gleichzeitig auf ein größeres Problem.
Miner könnten diese Aktionen viel effizienter durchführen
Robinson schreibt, dass das “frontrunning” Beispiel nur eines der vielen täglich stattfindenden dieser Art sei. Die finanziellen Anreize motivieren Miner dasselbe zu tun, wie die Bots nur mit einem großen Vorteil. Die Miner müssen die Transaktionen nicht in den Mempool schieben, sondern können sie sofort in den Block einbinden, wenn sie dran sind bzw. die Transaktionen ausschließen, welche sie überschreiben wollen. Zudem müssen sie nur einen hohen Gaspreis simulieren, da sie das Gas selbst einstecken. Mehr noch, die Miner könnten vorherige Blöcke ignorieren, wenn es dafür einen finanziellen Anreiz gibt. Dies erhöht die Wahrscheinlichkeit auf Erfolg.
Gibt es Lösungen für dieses Problem?
Robinson ruft dazu auf ihn zu kontaktieren, wenn man sich über dieses Problem Gedanken macht, bzw. an möglichen Lösungen arbeitet. Daniel Larimer, der Entwickler der EOS Software hat den Blogpost via Twitter aufgegriffen:
This is why #ethereum is unsuitable for #defi The problems described don’t exist on #EOS as it is both too fast to front run and producers are known and can be held accountable. Scary what happens on #eth. https://t.co/o6MdVW8u6U
Aus diesem Grund ist Ethereum für DeFi ungeeignet. Die beschriebenen Probleme gibt es bei EOS nicht, da es sowohl zu schnell für “frontrunning” ist als auch die Blockproduzenten bekannt sind und zur Rechenschaft gezogen werden können. Beängstigend, was auf Ethereum passiert.
In Sachen DeFi ist EOS zwar auch im Aufbau begriffen, hinkt jedoch wie alle Plattformen in diesem Bereich Ethereum weit hinterher. Ob dieses Problem gravierend genug ist, um die DeFi Projekte zur Migration auf EOS zu bewegen, kann nur die Zukunft zeigen. Interessant ist es auf jeden Fall.