Newsticker

Forscher schlagen Standards für reversible Token-Transaktionen vor

"U-Turn" von Christian Gloor via flickr.com. Bild zugeschnitten. Lizenz: Creative Commons

Drei Forscher der Universität Standord veröffentlichen einen Standard, der Transaktionen mit Token auf Ethereum und anderen Blockchains reversibel machen soll. Dies soll helfen, in Zukunft große Hacks zu vermeiden.

Klar. Blockchains sollen „immutabel“ sein, unveränderlich. Darum geht es ja.

Aber manchmal stört das auch. Wenn Mt. Gox ausgeraubt, eine Bridge gehackt, ein Smart Contract ausgenutzt wird. Insbesondere im weiteren Ökosystem um Ethereum, um DeFi, Smart Contracts, NFTs und EVM-Bridges, gab es im Lauf der letzten zwei Jahre eine kaum mehr übersehbare Anzahl an Hacks, die Token im Wert vieler Milliarden Dollar in die Wallets von Kriminellen geschleust haben. 2020 mindestens 7,8 Milliarden Dollar, 2021 mindestens 14 Milliarden.

Wie wäre es, fragen Kaili Wang und ihre Kollegen Dan Boneh und Qinchen Wang an der Stanfort-University, wenn man die Möglichkeiten von „programmierbarem Geld“ bzw. Smart Contracts nutzt, um reversible Transaktionen zu schaffen?

In einem Whitepaper beschreiben Wang und ihre Kollegen zwei neue Tokenstandards, ERC-20R und ERC-721R, die reversible Transaktionen für fungible und nicht-fungible Token einführen. Eine Transaktion mit diesen Token kann rückgängig gemacht werden, allerdings nur für einen „relativ kurzen Zeitabschnitt“ , nachdem sie auf der Blockchain gelandet ist. Wenn diese „Disput-Periode“ um ist, ist die Transaktion so irreversibel wie gewohnt.

Aber auch in der kurzen Phase des Disputs kann man eine Transaktion nicht einfach per Knopfdruck zurückspulen. Stattdessen muss man bei einem „dezentralen Set an Richtern“ beantragen, das Token einzufrieren, und diese dann überzeugen, dass die Transaktion umzudrehen ist. Der Ablauf ist also etwa derselbe, wie wenn man eine Transaktion bei PayPal storniert, nur dass es kein PayPal gibt, sondern eine DAO, eine Dezentrale Autonome Organisation.

Technisch ist dies „nicht einfach und enthält viele faszinierende technologische Herausforderungen“. Dazu gehört etwa, dass Angreifer Assets, die sie gestohlen haben, rasch bewegen können. „Tatsächlich kann ein Angreifer den Mempool beobachten und die Assets bewegen, sobald er eine Anforderung sieht, sie einzufrieren.“ Der Angreifer kann ein NFT dann rasch verkaufen oder fungible Token auf verschiedenen Accounts verteilen. Je nach Frist kann er die Token auch bereits auf einer Börse verkauft oder getauscht, an einen Mixer gesendet, als Kollateral verwendet oder verbrannt haben. „Der neue reversible Standard muss all diese Fälle ordentlich behandeln.“

Die Forscher sind überzeugt, gute Antworten auf diese Probleme gegeben zu. Mit der Solidity-Implementierung der beiden Smart Contracts haben sie bereits einen Prototypen ihrer Erfindung veröffentlicht, der die API-Funktionen freeze, reverse, rejectReverse und clean enthält. Die konkrete technische Implementierung der Funktionen ist zu komplex, um sie hier zu diskutieren.

Ein weiteres Problem ist eher sozial: die Entscheidung der Jury über eine Transaktion. Die Richter müssen bereit sein, Transaktionen einzufrieren, bevor es zu spät ist, und sie müssen möglichst kompetent entscheiden, ob einem Gesuch Recht zu geben ist. Wang und ihre Kollegen stellen sich „einen großen Pool an verfügbaren Richtern vor, die für ihre Arbeit kompensiert werden.“ Je nach Größe einer Transaktion müssen mehr Richter in die Entscheidung involviert sein.

Es gibt mehrere mögliche Verfahren, wie die Richter ausgewählt werden. Das Paper geht hier aber nicht ins Detail. Dagegen erklärt es, wie die Richter für ihre Mühe bezahlt werden: „Jedes Gesuch an den Governance-Contract, etwas einzufrieren, muss durch eine Art Stake begleitet werden.“ Man muss etwas bezahlen, wenn man Gebrauch von der Funktion macht, eine Transaktion umzukehren, je mehr, desto höher der Betrag und desto eiliger man es hat.

An der Stelle stößt man aber auf eine der Standardfragen, wenn es um DAOs geht: Was, wenn ein Richter, absichtlich oder unabsichlich, falsch entscheidet? Oder was, wenn er sich bestechen lässt? Wer kontrolliert die Kontrolleure?

Die Wissenschaftler schlagen mehrere Techniken vor. Bestechungen sollen etwa verhindert werden, indem Richter zufällig ausgewählt werden, ohne dass sie voneinander wissen, und dass der Beweis der Richter, befugt zu sein, Recht zu sprechen, erst mit dem Urteil veröffentlicht wird.  Nötig ist aber auch ein Mechanismus, durch den das Kollektiv der Richter darüber abstimmt, ob ein einzelner Richter sein Recht missbraucht hat.

In gewisser Weise reproduziert die Richter-DAO das Problem, das Blockchains gelöst haben. Es wäre sicherlich, auf die eine oder andere Weise, möglich, sofern die Struktur der DAO die richtigen Anreize setzt. Aber wäre es auch wünschenswert?

Auf der einen Seite klar. Wenn man schon programmierbares Geld – bzw. programmierbare Assets – hat, dann wäre es doch auch gut, sie vor Diebstahl zu schützen. Schon Satoshi hat das Bedürfnis erkannt, als er Multisig-Verfahren beschrieb, um gestohlene Bitcoins quasi einzufrieren, und es dürfte kein Zufall oder Irrtum sein, dass sowohl PayPal als auch die Banken Bedarf von einer solchen Funktion machen. Sogar das Lightning-Netzwerk baut auf reversiblen Transaktionen auf.

Auf der anderen Seite gibt man mit der Reversibilität Kontrolle ab. Man führt einen Mittelsmann ein, der ein Token unmittelbar nach einer Transaktion für eine gewisse Zeit treuhänderisch begleitet. Sehr vieles hängt davon ab, ob die Richter, die man ins System einführt, zuverlässig und ehrlich sind.

Über Christoph Bergmann (2408 Artikel)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder ---

3 Kommentare zu Forscher schlagen Standards für reversible Token-Transaktionen vor

  1. Schon Satoshi hat das Bedürfnis erkannt, als er Multisig-Verfahren beschrieb, um gestohlene Bitcoins quasi einzufrieren, und es dürfte kein Zufall oder Irrtum sein, dass sowohl PayPal als auch die Banken Bedarf von einer solchen Funktion machen.

    Genau das ist das Problem, Bitcoin ist (eigentlich*) trustless und sollte die Fungibilität eines Bargelds abbilden, bei dem ich mir als Empfänger keine Gedanken machen muss, ob ich es später tatsächlich nutzen kann oder nicht. Wenn ich über PayPal oder per Banküberweisung die Ware verkaufe, kann der Kunde jederzeit (berechtigt oder nicht) behaupten, sein Account wäre gekapert gewesen, was mir beides bereits passiert ist, mit entsprechenden Konsequenzen, inklusive Betrugsanzeige, Hausdurchsuchung und Verlust des Bankkontos wegen nicht erhaltenen 370€. Ich hatte zwar in diesem Fall keinen direkten Schaden, weil der gefälschte Überweisungsträger erkannt wurde, die Folgekosten waren aber deutlich höher.

    Zufällige Richter in einem pseudonymen System sind extrem schwierig umzusetzen, selbst wenn man dafür einen gewissen Stake halten müsste, denn
    2. müsste man einen Delay ins Spending jeder UTXO einbauen, damit die Richter genug Zeit haben, bevor die UTXO bereits bei einem Händler ausgegeben oder an einer Börse verkauft wurde, die Finalität nach etlichen Stunden wäre imho ein K.O. Kriterium.
    1. wird anders als beim dPoS (welches ohnehin schon extrem schwierig dezentral zu halten ist) den meisten Usern der Aufwand zu hoch sein aber Whales könnten Tausende Richter gleichzeitig stellen um damit oft die Mehrheit zu stellen.

    *Ausnahmen gibt es heute schon für sanktionierte Adressen und UTXO, die man erhält, deren Score von einem der Chainanalyse Anbieter sehr schlecht ist.

  2. Artur August // 7. Oktober 2022 um 8:04 // Antworten

    Bitcoin Vault bietet hier eine viel bessere Lösung. Bei Vault wird auf Richter verzichtet. Hier hat man als Absender die direkte Kontrolle bezüglich der Rückholung des versendeten Betrages. Mit Hilfe von drei private keys. Mit dem 1. standard private key löst man eine Überweisung mit 144 Blöcken/24h Verzögerung aus. Man kann sie mit dem 2. fast private key auf sofort Überweisen beschleunigen, oder mit dem 3. cancel key die Überweisung stornieren, d.h. auf die Ausgangaadresse zurückholen, oder auf eine von dir definierte Ausweichadresse weiterleiten im Fall einer korrumpierten Wallet.

    https://btcv.com/whitepaper

  3. Danke für den ja doch interessanten Artikel.
    Wenn sich diese ERC-20R-Token durchsetzen sollten, dann kauft man sich damit Probleme ein, die eigentlich jeden „klassischen“ Kryptowährungfreund sehr abschrecken sollten. Ich seh nicht, dass die Vorteile dieser Funktion die Nachteile überwiegen.

    Ja gut. Man kann das implementieren, und ich kann mir auch vorstellen, dass das mit etwas Hirnschmalz rein technisch auch einigermaßen funktioniert.
    Aber es ist eben das, was man ursprünglich meines Erachtens nicht wollte. Das Prinzip war „Be your own bank.“ und so. Nicht abhängig von anderen Menschen sein, war das Ziel. Und: „Wenn du du nicht alleiniger Besitzer der Keys bist, sind es nicht deine coins.“

    Ob ich jetzt einer Bank mein Geld anvertraue oder anonymen Richtern, in jedem Fall kann man dann prinzipiell auch gleich eine Kryptowährung entwickeln, bei der die Richter zumindest demokratisch von den Nutzern gewählt werden und auch bestenfalls noch Voraussetzungen wie sachliche Kompetenz erfüllen. Da hätte ich dann wohl noch eher das Vertrauen, dass da jemand Richter wird, der meine Coins nicht zu Betrügern schickt. Oh warte, dann kann ich ja auch einfach in die klassische Politik gehen…

    Diese Prinzipien, die Kryptowährungen groß gemacht haben, gibt man damit auf. Man geht weg von dem code-is-law-Prinzip und orientiert sich wieder daran, wie Menschen seit Tausenden Jahren Streit lösen: Mit Richtern, die entscheiden. Das funktioniert mal mehr und mal weniger gut. Das kann doch aber schon gar nicht immer funktionieren. Beispiel: Ich bestell was im Internet, bezahle mit einem ERC-20R-basierten Token, bekomme die Ware nicht, und mache einen Disput auf, weil mir jemand also mit Social engineering meine Coins geklaut hat. Wie soll ich dem „Richter“ glaubhaft beweisen, dass ich die Ware nicht bekommen habe und meine Token wieder haben will? Das übliche Problem, dass bei Meinung-gegen-Meinung existiert wird keine „Richter-Implementierung“ jemals zuverlässig inhaltlich korrekt lösen können. Und das ist nicht nur auf das Ware-nicht-bekommen-Beispiel beschränkt. Auch Entscheidungen über (vermeintliche) Hacks werden aus gleichem Grund bei weitem nicht immer eindeutig gerecht entscheidbar sein. Auch ist die Grenze zwischen „einen Smart-Contract hacken“ und „Funktionen nutzen, wie sie vorgesehen sind“ fließend. Niemand kann klar sagen ab wann etwas hacken ist, und ab wann etwas noch legal ist, weil man nur vorhandene Funktionen ausnutzt. Fragen die Richter im Zweifelsfall dann die Entwickler, wie eine Smart-Contract-Funktion benutzt werden darf und wie nicht? Das wäre aber auch Unsinn, weil dann sind de facto nur die Entwickler die Richter, und das ist sicherlich auch nicht Sinn der Sache.

    Übrigens wird auch diese Funktion genau natürlich wieder ausgenutzt. Vorheriges Beispiel nur umgekehrt: Betrüger kaufen Sachen, bezahlen mit ERC-20C-Token, kassieren die Ware, und stellen ungerechtfertige Disput-Anträge um die coins wieder zu bekommen und manchmal werden sie damit durchkommen und ihre Token zu Unrecht wieder bekommen, weil sie das System oder die Richter in irgendeiner Weise betrügen. Und dann? Disput-Anträge für abgeschlossene Dispute? Weil wenn man dann als Verkäufer seine Coins wieder bekommen möchte, und den falschen Disput rückgängig zu machen, müsste ja eine ganz neue Transaktion seitens des Betrüger-Käufers gemacht werden, was natürlich nicht passieren wird. Analoge Beispiele für sowas lassen sich auch wieder mit „Blockchain-Hacks“ konstruieren.

    Entweder man lässt irreversible Blcokchain-Transaktionen zu wenn sie möglich sind, und lebt mit den Effekten, die sich dadurch ergeben, oder man benutzt einfach eine klassische Bank, wo man womöglich Chancen hat, mit Klagen usw. sein Geld im Betrugsfall wieder zu bekommen. Mittelwege sind praktisch kaum gerecht umsetzbar. Gerade deshalb haben doch die code-is-law-Anhänger Argumente, die man eben leider nicht so einfach wegdiskutieren kann. Reversible Transaktionen lösen die Probleme nicht.

    Man versucht ein >sozialestechnischen< Ansätzen zu lösen. Aus langjähriger Software-Entwickler-Erfahrung kann ich sagen: Das funktioniert leider nicht. Ich lass mich gern eines besseren belehren.

Kommentar verfassen

%d Bloggern gefällt das: