Der rätselhafte Full Node von Ethereum

Der Ausbruch des Vesuvs. Gemälde von Camillo de Vito , 1813. Fotografiert von Ωméga *, geteilt durch flickr.com. Lizenz: Creative Commons

Ethereum kann verwirrend sein. Schon die Frage, wie groß die Blockchain ist – 100 Gigabyte oder ein Terabyte – stellt viele vor eine Herausforderung. Ebenso schwierig ist es, zu definieren, was ein Full Node ist, und zu erklären, wie man die Blockchain ausliest. Wir versuchen, mithilfe von Afri Schoedon von Parity ein wenig Licht ins Dunkel zu bringen.

Ethereum ist anders als Bitcoin und überfordert oft auch Leute, die man eigentlich für Experten halten sollte. Nichts zeigt dies so deutlich wie eine kurze Episode im Dauer-Propagandakrieg der Kryptoszene.

Und zwar hat jemand mit dem Pseudonym „StopAndDecrypt“ einen Artikel über Ethereum veröffentlicht, der den Titel trägt, dass die Blockchain mittlerweile größer als ein Terabyte sei. „StopAndDecrypt“ ist, muss man wissen, Moderator von r/Bitcoin – manche sagen dazu „Zensor“ – und tritt in vielen weiteren sozialen Medien als vehementer Streiter für die Sache Bitcoin Core auf. Sein Artikel läuft, wenig überraschend, darauf hinaus, dass Ethereum wegen der großen Blockchain dem Untergang geweiht und keine andere Währung als Bitcoin Core überlebensfähig ist. Oh, Wunder.

Die meisten in der Ethereum-Szene haben den Artikel relativ höflich kommentiert: Er sei im Detail absurd falsch, treffe aber den einen oder anderen Punkt. Die Blockchain sei mitnichten ein Terabyte groß – doch die hohe Datenlast mache Ethereum durchaus zu schaffen.

Das Thema hat einen Rattenschwanz an Fragen: Wie groß ist die Blockchain wirklich? Wie kommt man dazu, zu denken, sie sei ein Terabyte groß? Warum haben Ethereum-Nodes so viele verschiedene Modi, zu synchronisieren? Und wie sehr belastet die Datenmenge das Netzwerk tatsächlich? Afri Schoedon, Release-Manager von Parity, einer Ethereum-Node-Software, hat mir diese und andere Fragen beantwortet. Heraus kam eine Odysee in fünf Etappen.

I. Die Blockchain von Ethereum ist nicht mal halb so groß wie die von Bitcoin

Die Größe einer Blockchain ist einfach zu bestimmen: Sie ist die Summe aller Blöcke. Das ist ziemlich unkompliziert.

„Die Blockchain von Ethereum enthält alle Transaktionen. Das sind derzeit etwa 70 bis 80 Gigabyte. Wenn man sie heruntergeladen hat, kann man alles berechnen, was jemals passiert ist,“ erklärt Afri. Die Ethereum-Blockchain ist damit nicht – wie von StopAndDecrypt behauptet – größer als ein Terabyte, sondern in Wahrheit nicht mal halb so groß wie die von Bitcoin, die derzeit gut 170 Gigabyte auf die Waage bringt.

Laut den Statistiken von Etherstats.io gibt es etwa alle 15 Sekunden einen neuen Block, der maximal 25 Kilobyte groß ist. Damit wächst die Blockchain alle zehn Minuten um etwa ein Megabyte – also mit derselben Rate wie Bitcoin.

Soweit ist alles überschaubar.

II. Einen Node synchronisieren

Afri Schoedon.

Auch die erste Synchronisierung eines Nodes ist relativ einfach erklärt: Sowohl bei Bitcoin wie bei Ethereum lädt der Node die Blockchain herunter, Block für Block, und errechnet daraus einen Zustand. Bei Bitcoin heißt dieser UTXO-Set, bei Ethereum State.

Das UTXO-Set ist lediglich eine Art Liste mit Münzen, die noch nicht ausgegeben sind. Um es aufzubauen, muss der Node es Block für Block ausrechnen: Jede Transaktion vernichtet eine Münze und schafft eine neue. Auf diese Weise aktualisiert ein Node das UTXO-Set vom Genesis-Block bis in die Gegenwart.

Der State von Ethereum ist anders. Komplizierter. „Er enthält die Balance oder den Zustand von unter anderem jedem Smart Contract,“ erklärt Afri. Smart Contracts sind wie Algorithmen in einem Computerprogramm, und ihr State das jeweilige Ergebnis. Bei einem Token-Contract kann es eine Liste mit Guthaben der Accounts sein, bei der DAO die Ergebnisse von Abstimmungen. Und so weiter.

Aufgebaut wird der State aber auf diesselbe Weise wie ein UTXO-Set: Block für Block, bis man in der Gegenwart angekommen ist. Wenn ein Ethereum-Node synchronisiert, kalkuliert er den State mit jedem Block neu. Die Zwischenergebnisse – die historischen States – „sind nur wichtig, um den neuen State zu berechnen. Gewöhnlich wirft man die weg. Es gibt kaum Anwendungsfälle, bei denen man einen alten State braucht.“

Genau das macht ein “ganz normaler” Ethereum-Node: Er lädt die Blockchain herunter, kalkuliert im Arbeitsspeicher für jeden Block einen State, aber speichert nur den aktuellen. Je nach System dauert es 12 Stunden bis eine Woche, bis er damit fertig ist. Das Performance-Geheimnis für das Synchronisieren ist, so Afri, „ein möglichst großer Cache und möglichst viel Arbeitspeicher.“

III. Woher kennt der Node die Geschichte einer Adresse?

Da ein Node sowohl bei Bitcoin als auch bei Ethereum nur die Blockchain und den Endzustand speichert, ist es nicht ganz trivial, die Historie zu erfahren: Woher weiß der Node, welche Transaktionen mit oder zu einer Adresse ausgeführt wurden, wenn sie nicht mehr Teil des aktuellen Zustandes sind?

Die einfachste Variante ist, wenn der Node es „miterlebt“: wenn er die Adresse schon kennt und eine Zustandsänderung durch einen neuen Block erfährt. Dann weiß er, wonach er schauen muss, und speichert die relevanten Informationen in der Wallet-Datei. Aber was, wenn man die Adressen noch nicht hat, sondern später importiert? Bei dieser Frage zeigen sich die Unterschiede zwischen einem Node bei Bitcoin und Ethereum.

Bei Bitcoin gibt es zwei Möglichkeiten: Erstens, der Node reindiziert die Datenbank. Dies passiert, wenn man etwa einen privaten Schlüssel einspielt. Das Programm sucht dann in der Blockchain nach den entsprechenden Transaktionen. Einige Minuten später hat es die Historie der Adresse. Zweitens kann man den Node mit der Flagge „–txindex=1“ starten. Dann schreibt er während der Synchronisierung eine Liste mit Transaktionen. Das braucht einige Gigabyte zusätzlichen Speicher.

Bei Ethereum ist beides möglich – theoretisch. Praktisch wird es dadurch erschwert, dass es kein UTXO-Set gibt, sondern nur „Accounts“. Sie können sich das so vorstellen, dass ein Guthaben bei Bitcoin ein Eimer voller Münzen ist, die jeweils ihre Herkunft eingeprägt haben, während es bei Ethereum ein Eimer Wasser ist, von dem man lediglich den Pegel erkennt. Dieser Pegel kann durch normale Transaktionen verändert werden, aber auch durch die Ausführung von Smart Contracts. Dies macht es schwieriger, die vergangenen Ereignisse in der Blockchain zu finden.

Theoretisch ist es möglich, die Historie von Accounts auf Abruf zu rekonstruieren. Aber da kein Ethereum-Client diese Option hat, muss man es von Hand durch die APIs machen. Es geht aber auch einfacher: „Man kann auch alte Transaktions-Pfade sehen, indem man beim Synchronisieren die Option ‚–tracing on‘ aktiviert,“ sagt Afri, „dann speichert der Node die Ausführungsergebnisse der Transaktionen, was etwa 30-50% mehr Speicher braucht.“

IV. Warum es so schwierig ist, die Historie eines Smart Contracts nachzuzeichnen

Mit Tracing kann ein Ethereum-Node die Ergebnisse historischer Transaktionen nachschlagen. Würden wir von Bitcoin reden, wäre damit fast alles gesagt. Aber wir reden von Ethereum.

Afri erklärt, dass man mit Tracing nicht jeden Zustand von Smart Contracts rekonstruieren kann. Welchen State hatte ein ICO-Contract, nachdem 1.200 Leute teilgenommen haben? Welchen Zustand hatten Contracts wie von CryptoKitties bei einem bestimmten Block? Dies individuell nachzuprüfen ist sehr schwierig, vor allem, wenn mehrere Smart Contracts miteinander interagieren. „Um hier den State herauszufinden, reicht es nicht, einfach auf die Transaktionen zu schauen.“

Natürlich könnte man selektiv die States bilden, die man braucht. Aber das hat, so Afri, noch kein Client implementiert, und es ist sehr schwierig. Stattdessen kann man einen Node als „Full Archival Node“ (FAN) synchronisieren: der Node wirft die alten States nicht weg, sondern speichert sie auf der Festplatte. Das dauert ziemlich lang und braucht enorm viel Speicher. Man kann es sich so vorstellen, als würde ein Unternehmen nach jeder Transaktion – jeder verkauften Ware, jeder ausgeführten Gehaltszahlung – die komplette Bilanz neu ausrechnen und ausdrucken.

Für normale User, meint Afri, ist das unnötig. „Man braucht es nur, um rückwirkend den Zustand von Smart Contracts nachzuvollziehen. Ich sage immer, das brauchen nur Wissenschaftler, Strafermittler und Blockexplorer.“ Wer einen solchen FAN hat, kann in Echtzeit jede historische Zustandsänderung aller Smart Contracts abfragen.

V. Ein Terabyte fressender Monsternode

Ein FAN braucht mittlerweile mehr als ein Terabyte an Speicher. Afri schätzt, dass der Bedarf bis Ende des Jahres auf knapp zwei Terabyte anschwellen wird, und wenn Ethereum weiterhin so wächst wie derzeit, wird ein FAN in absehbarer Zukunft acht oder 16 Terabyte brauchen.

Für Hobby-User ist ein FAN schon jetzt zuviel. Erstens, weil es ewig und zwei Tage braucht, um ihn zu laden, und zweitens, weil eine SSD-Festplatte in der notwendigen Größe ziemlich teuer ist. Da ein FAN extrem viele Lese- und Schreiboperationen ausführt, ist der Verschleiß groß. Die Festplatte sollte mindestens einmal im Jahr gewechselt werden.

Sorgen, dass die FANs aussterben, macht sich Afri aber nicht. „Das Worst-Case-Szenario ist, dass es für Blockexplorer eben teurer wird. Es wird aber immer jemanden geben, der genügend Ressourcen hat, um so ein Ding laufen zu lassen.“ Was sind schon zwei 16-Terabyte-Festplatten im Jahr für ein lukratives Unternehmen? Die ersten 30-Terabyte-Platten sind bereits marktreif, 100-Terabyte-SSD-Festplatten stehen kurz vor dem Markteintritt. Die Anforderungen sind hoch, aber machbar.

Sorgen macht sich Afri daher auch eher um die normalen Full Nodes ohne das Archiv der historischen States.

VI. Dezentralität

Ein Full Node braucht bei Ethereum derzeit etwa 100 Gigabyte an Speicher. Das ist deutlicher weniger als ein Bitcoin Full Node. Allerdings frisst ein Full Node bei Ethereum viel mehr CPU-Leistung und Arbeitsspeicher als ein Bitcoin-Node und braucht länger, um zu synchronisieren. Der State ist eben komplexer als das UTXO-Set.

Aber derzeit ist noch alles in Ordnung. Ein Schwund an Nodes ist nicht feststellbar. Mit rund 17.000 Nodes mit offenen Ports hat Ethereum fast doppelt so viele Knoten wie Bitcoin. Einen Anlass, sich Sorgen zu machen, gibt es also noch nicht.

Wenn Ethereum jedoch weiterhin so wachsen wird wie bisher, wird die Größe eines Full Nodes in absehbarer Zukunft auf mehr als 500 Gigabyte anwachsen. Dies könnte, so Afri, eine Schmerzgrenze sein, ab der viele Hobbyisten ihren Full Node aufgeben. Die Schmerzen entstehen nicht nur durch den Speicherbedarf, sondern auch durch die anderen Faktoren, wie das Synchronisieren, die CPU-Belastung oder die Festplattenoperationen. Ein Full Node bremst schon heute viele Computer spürbar aus.

Die Alternative können für User „Warp-Nodes“ sein. Diese synchronisiert man bei Parity mit der Option „–warp“. Ein Warp-Node lädt sich von den anderen Nodes lediglich den State sowie eine bestimmte Anzahl der nachfolgenden Blöcke, standardmäßig 30.000, herunter. „Dank State-Trie-Root Hash im Block Header kann man nicht einfach einen falschen State bekommen. Es ist nahezu unmöglich, den zu faken.“ Für die Beträge, die Normalsterbliche empfangen und versenden, ist ein solcher Node mehr als ausreichend sicher. Zudem kann man durch einen Wechsel der Peers und die Anfrage bei verschiedenen Blockexplorern die Sicherheit weiter erhöhen.

Wie bei Bitcoin erfüllen Full Nodes in privater Hand bei Ethereum die Funktion eines Kontrollorgans. Wenn sie wegfallen, droht die Dezentralität von Ethereum zu zerbrechen, und die Kryptowährung könnte zum Spielball von Kartell-Interessen werden. Ab wann dies passiert, und wie schlimm es wirklich ist, ist jedoch eine Frage, über die man lange streiten kann. Besser wäre es jedoch, wenn es nicht nötig wäre, weil private Full Nodes weiterhin bestehen.

VII. Zukunft

Das Ziel der Ethereum-Entwickler ist es daher, die Full Nodes klein genug zu halten, dass sie von Hobby-Usern betrieben werden können, aber genügend Kapazität zu schaffen, um kein Wachstum abzublocken. Das ist sozusagen die Quadratur des Kreises, oder, wie Afri sagt, „der heilige Gral der Blockchain.“

Es ist „ein technisches Problem, auf das es viele theoretische und einige praktische Lösungsansätze gibt“: Erstens Sidechains, also dass man über Bridges andere Chains anbindet. Das gibt es schon, mit Loom und dem POA Network, steckt aber noch in den Kinderschuhen. Zweitens State Channels wie bei Raiden, was bedeutet, dass Transaktionen off-chain ausgeführt werden. Das gibt es schon als Prototyp, aber ist noch nicht so weit wie das Lightning-Netzwerk bei Bitcoin. Drittens wird an Sharding gearbeitet, was bedeutet, dass man die Chain aufsplittet.

All diese Lösungen sind noch einige Jahre entfernt, meint Afri. Er ist optimistisch, dass Ethereum so lange fortbesteht, findet aber auch, dass es knapp werden könnte. „Wir wollen ja nicht, dass nur große Firmen einen Knoten betreiben können. Es gibt derzeit noch keine Engpässe, aber es könnte in den nächsten Jahren kritisch werden.“

About Christoph Bergmann (1372 Articles)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder, es es seit Mitte 2013 führt. Christoph hat vor kurzem ein Buch geschrieben: Bitcoin: Die verrückte Geschichte vom Aufstieg eines neuen Geldes. Das Buch stellt Bitcoin in seiner ganzen Pracht dar. Ihr könnt es direkt auf der Webseite Bitcoin-Buch.org bestellen - natürlich auch mit Bitcoin - oder auch per Amazon. Natürlich freuen wir uns auch über Spenden in Bitcoin oder Bitcoin Cash an die folgende Adresse: 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Wer will, kann uns auch Hier mit Lightning spenden. Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Wer dies privat machen möchte, sollte meinen PGP-Schlüssel verwenden.

38 Comments on Der rätselhafte Full Node von Ethereum

  1. Danke für diesen ausführlichen Artikel zum Thema Blockchains von Bitcoin und Ethereum. Über Ethereum kann ich leider nicht all zu viele deutsche Artikel finden.

  2. Ja also, klasse Artikel/Interview! Hoher Informationsgehalt. Top Content. Danke 🙂

  3. Danke!

  4. Anonymous // 29. June 2018 at 15:17 // Reply

    Ja, StopAndDecrypt ist bekannt für seine Propaganda und Zensur von Informationen. Zensieren kann er natürlich nicht auf Medium, sondern nur auf Reddit.
    Ein sehr ausführlicher Artikel, top!

  5. Kartoffelkopf // 29. June 2018 at 18:02 // Reply

    Letztendlich ist bei Ethereum NUR ein FAN ein Fullnode und ein Fullnode ein FAN. Alles andere ist Augenwischerei bzw. eine versuchte Umdeutung von Begrifflichkeiten. Denn die Blockchain, als Notarbuch (= ledger), MUSS ALLES nachvollziehbar enthalten, was am Ende als Resultat bei den Usern ankommt (das gilt analog auch für die Geschichte mit dem Hash des UTXO-Set bei Bitcoin-Cash)!

    Denn war es nicht so, dass das, was Ethereum von Bitcoin unterscheidet, die Turing-vollständigen Smart Contracts sind, welche auf der Blockchain gespeichert und ausgeführt werden können? Und wenn man schon so argumentiert, dann muss man auch anerkennen, dass die Ethereum Blockchain inzwischen über 1 Terabyte gross ist und in nicht allzu ferner Zukunft auf über 16 Terabyte anschwellen wird (laut Artikel). Alles andere sind schlicht Light Nodes.

    • Anonymous // 29. June 2018 at 20:44 // Reply

      Bitcoin ist schon turing-complete, kann aber natürlich nicht alles, was Ethereum kann.
      Die Frage ist: Brauche ich wirklich Ethereum für meine Aufgabe, oder kann ich mit Bitcoin das gleiche Ergebnis erzielen?

      • Kartoffelkopf // 30. June 2018 at 10:09 //

        Das stimmt so nicht oder ich habe etwas Wichtiges verpasst. Die Skriptsprache von Bitcoin ist meines Wissens nicht Turing-vollständig! Das braucht man auch nicht für ein Zahlungs- bzw. Werterhaltungsmittel wie Bitcoin. Zusätzlich ist die Turing-Vollständigkeit bekanntlich auch ein Angriffsvektor. Natürlich ließe sich Bitcoins Skriptsprache entsprechend erweitern, wenn die Bitcoin-Community dies für notwendig erachten sollte.

      • Anonymous // 30. June 2018 at 17:40 //

        @Kartoffelkopf
        Die Bitcoin Skriptsprache selbst ist nicht turing-complete, du kannst aber mit Bitcoin eine Turing Maschine bauen. Das hat den Vorteil, dass es keine Endlosschleifen geben kann, denn du bezahlst für jeden Schritt Fees (bzw. für jede Iteration).
        Craig Wright war der erste, der das sagte (2015, vor dem CSW = Satoshi Kram).
        Clemens Lay hatte dann 2018 darüber einen Vortrag gehalten: https://youtu.be/M6j-11H2O7c

      • Das ist richtig. Wofür braucht man eigentlich “Smart” Contracts?

        Ethereum (geschweige denn die neuen konkurrierenden Plattformen) wird in meinen Augen sehr stark überbewertet, da für die meisten Anwendungen, die darauf laufen, auch auf Bitcoin direkt oder einer 2nd Layer Lösung wie z.B. Counterparty dafür ausreichend wären. Der einzige sinnvolle [sic] Anwendungsfall für Ethereum aktuell sind ICOs, die zu 99%+ Scams sind. Als Payment Ersatz zu Buchgeld oder gar Bargeld ist es Dank für alle transparenter Blockchain trotz geringerer TX-Size genauso wenig geeignet wie Bitcoin. Optionale zk-Snarks wie bei Zcash werden daran auch nichts ändern.

        Über die fast offensichtlichen Scams wie EOS, die versprechen, Ethereum zu ersetzen (wofür und womit eigentlich?), will ich eigentlich schweigen… Vitalik zumindest ist erwachsen geworden und im Gegensatz zu einem Dan Larimer versucht er seine Plattform weiterzuentwickeln, anstatt ständig neue nutzlose Scams in die Welt zu setzen und Mitmenschen um ihr Geld zu bringen.

      • “Als Payment Ersatz zu Buchgeld oder gar Bargeld ist es Dank für alle transparenter Blockchain trotz geringerer TX-Size genauso wenig geeignet wie Bitcoin.”

        Oh, mit den Smart Contracts kann man eine Menge Dinge machen, die man gerne mit Geld machen würde. Ein Konto mit Kindersicherung, maßgeschneiderte Multisigs, Dividendenzahlungen, Dauerüberweisungen, alles was du willst. Leider wird das weniger stark entwickelt als ICOs und Gaminig-Token. Als ich zum ersten Mal eine Multisig-Adresse auf ETH gebildet habe, wurde mir klar, dass ETH auch die Chance hat, ein besseres Geld als Bitcoin zu sein, und das ganz nebenbei …

      • Kartoffelkopf // 1. July 2018 at 11:51 //

        @Anonymous: Man kann schon mit einem Sandstrand und einem Stock eine Turingmaschine nachbilden. Also mal wieder viel heisse Luft von Möchtegern-Satoshi CW. Bei Ethereum gibt es übrigens auch keine Endlosschleifen, weil irgendwann das Gas alle ist (soweit ich weiss).

      • Anonymous // 1. July 2018 at 14:47 //

        @Kartoffelkopf Schau dir doch mal die Präsentation an, bevor du voreilig urteilst. Hätte ich die Wörter “Craig Wright” gar nicht hingeschrieben, dann wäre deine Antwort sicherlich anders ausgefallen…

      • Ein Konto mit Kindersicherung, maßgeschneiderte Multisigs, Dividendenzahlungen, Dauerüberweisungen, alles was du willst.

        Das ist mir bewusst. Allerdings ist das auch alles direkt auf der Bitcoin Blockchain oder mit Second Layer Lösungen (wie z.B. dem erwähnten Couterparty) möglich. Dividendenzahlungen, die von externen Faktoren abhängen, werden aber schwierig, egal ob auf der Bitcoin oder Ethereum Blockchain.

      • Mir ist bisher kein Multisig außerhalb von ETH bekannt, bei dem die Wallet erkennen kann, ob eine Teilsignierung vorliegt. Es gibt schon einen Grund, weshalb die Token über Colored Coins und Counterparty ein Nischendasein geführt haben, aber die ERC-Token so eingeschlagen haben.

      • Wofür ist die Information über eine Teilsignierung denn notwendig? In der Tat läuft die Signierung meist Off-Chain, aber wenn es einen plausiblen Grund für eine Onchain Lösung gibt, würde ich diesen auch bei Monero einreichen (welches seit einigen Monaten endlich auch Multisig unterstützt)…

        Es gibt schon einen Grund, weshalb die Token über Colored Coins und Counterparty ein Nischendasein geführt haben, aber die ERC-Token so eingeschlagen haben.

        Der Grund hierfür ist wahrscheinlich die scheinbare Simplizität in der Erstellung, die jeder Depp “schafft”. Allerdings führt diese auch zu etlichen ungewollten(?) Scams wie DAO, die sogar einen Chainsplit herbeigeführt hat, waren ja nur der Anfang… Es gibt in der Tat einige wenige Anwendungen auf Ethereum, die sinnvoll sind. Allerdings würde ich deren Volumen aktuell auf weniger als 1% schätzen.

      • Multisig mit Bitcoin nach 6 Jahren P2SH:
        1. Finde deinen PubKey raus (WTF?)
        2. Bitte den anderen, seinen PubKey rauszusuchen und dir zu schicken (WTF?)
        3. Erstelle eine P2SH-Adresse (WTF?)
        4. Überweist Geld dort hin
        Nun zum Auflösen
        5. Bilde eine Teilsignierung (WTF?)
        6. Schicke die Teilsignatur an deinen Partner
        7. Dieser bildet daraus eine volle Signatur (WTF?)
        8. Wenn beide nicht dieselbe Wallet benutzen, wird es scheitern

        8 Schritte, darunter zwei Mal E-Mails hin und her und 5 Schritte, die selbst für mich nach 5 Jahren Bitcoin eine Herausforderung sind (WTF?).

        Multisig bei ETH, nach 3 Jahren Smart Contracts:
        1. Suche eine Adresse raus
        2. Bitte den Partner, dir seine Adresse zu geben (copy & paste)
        3. Bilde den Smart Contract durch ein Formular in Parity / Ethereum Wallet (in GUI)
        4. Überweise Geld dorthin (einfach senden)
        Auflösen
        5. Initiiere die Transaktion in der Wallet (einfach senden)
        6. Der andere wird in der Wallet aufgefordert, zu bestätigen (Passwort, Enter)

        6 Schritte, darunter nur ein E-Mail-Austausch, kein Datenversand, kein WTF.

        Wenn z. B. meine Freundin und ich ein BTC-Multisig-Konto bilden würden, wäre das eine große Herausforderung. Meine Mutter wird es niemals verwenden. Was meinst du, warum Multisig bei BTC extrem zentralisiert ist? Wird quasi nur von BitGo eingesetzt. OpenBazaar mussten eine Wallet in die Software implementieren, um die für sie notwendigen Multisig-Befehle zu verwenden, weil das mit allen anderen Wallets nicht geht / den User maßlos überfordert. Börsen, die versucht haben, Multisig selbst zu bauen, haben mit einer kaum zu benutzbaren Software geendet. Ich glaube, einige Darknetmarket haben damit experimentiert, aber soweit ich weiß wurde es nie genügend genutzt, um Exit Scams zu verhindern … Man könnte fast sagen, Multisig bei BTC ist gescheitert. Ethereum hat immerhin die Chance, es besser zu machen.

      • Das ist richtig. Mit der Usability steht / fällt jedes noch so innovative Feature. Nicht zuletzt muss man das auch bei Monero ankreiden, denn bis vor einem Jahr gab es schlichtweg gar keine GUI, heutzutage ist sie immer noch nicht perfekt und weit von einer Funktionalitätsparität zur CLI entfernt. Multisig gehört leider auch dazu…
        Nichtsdestotrotz bin ich stolz, dass wir letzteres mittlerweile zumindest in der CLI verfügbar haben, eine Protokolländerung bzw. Hard Fork war dafür übrigens nicht notwendig. Wie bei Bitcoin und den meisten Open Source Projekten wird Usability leider auch in Monero (noch) nicht groß geschrieben, denn man konzentriert sich auf ein stabiles Fundament. Bulletproofs, die aktuell durch drei unparteiische externe Stellen geprüft werden und wahrscheinlich im Oktober live gehen, könnten ein Game-Changer werden, da sie die Transaktionsgröße um durchschnittlich 90% verringern und Monero endlich etwas handlicher machen. Letztendlich entscheidet die Usability über den Erfolg eines Projekts könnte man meinen. Marketing ist aktuell wahrscheinlich noch ein stärkerer Faktor, siehe Onecoin, Bitconnect, Verge oder EOS. Die Liste ist beliebig erweiterbar und wir brauchen “bald” einen echten Shakeout, in dem diese Scams in Vergessenheit untergehen. In den Top100 vom Market Cap sehe ich nicht mehr als 10% Überlebensschancen. Im gesamten Crypto Space sind es wohl weniger als 1%.

    • Denn die Blockchain, als Notarbuch (= ledger), MUSS ALLES nachvollziehbar enthalten, was am Ende als Resultat bei den Usern ankommt

      Die ETH-Blockchain mit ~80gb enthält das: Sie ist ein unmanipulerbarer Speicher der Informationen, aus denen man alles ableiten kann, was jemals auf ETH passiert ist.

      • Kartoffelkopf // 30. June 2018 at 18:18 //

        Ich beziehe mich hier auf IV: Die Nachvollziehbarkeit der Smart Contracts. Und mit den 80GB ist das laut Ihres Artikel nicht möglich da man daür einen FAN bräuchte:

        ‘Afri erklärt, dass man mit Tracing nicht jeden Zustand von Smart Contracts rekonstruieren kann. Welchen State hatte ein ICO-Contract, nachdem 1.200 Leute teilgenommen haben? Welchen Zustand hatten Contracts wie von CryptoKitties bei einem bestimmten Block? Dies individuell nachzuprüfen ist sehr schwierig, vor allem, wenn mehrere Smart Contracts miteinander interagieren. „Um hier den State herauszufinden, reicht es nicht, einfach auf die Transaktionen zu schauen.”

        Natürlich könnte man selektiv die States bilden, die man braucht. Aber das hat, so Afri, noch kein Client implementiert, und es ist sehr schwierig. Stattdessen kann man einen Node als „Full Archival Node“ (FAN) synchronisieren: der Node wirft die alten States nicht weg, sondern speichert sie auf der Festplatte. Das dauert ziemlich lang und braucht enorm viel Speicher. Man kann es sich so vorstellen, als würde ein Unternehmen nach jeder Transaktion – jeder verkauften Ware, jeder ausgeführten Gehaltszahlung – die komplette Bilanz neu ausrechnen und ausdrucken.’

      • Die Blockchain ist dennoch nur 80gb groß. Sie enthält alle Informationen, die man braucht.

        Man könnte darüber diskutieren, ob nur ein FAN ein echter Full Node ist, ja. Aber zu sagen, die Blockchain sei 1tb groß, ist so ähnlich, als würde man sagen, die Bitcoin Blockchain sei so groß wie eine MySQL-Datenbank mit allen Guthaben jeder Adresse zu jeder Zeit inklusive sämtlicher Skripte, deren Zwischenzustände, die bei der Verifizierung jeder einzelnen Transaktion angefallen sind, sowie jeder Rechenoperation und jeden Zwischenständen, die man braucht, um etwa die Gebühren und die Guthaben auszurechnen.

        Du willst sämtliche Zwischenstände der Verifizierung einer großen Multisig-Transaktion auslesen? Steht nicht direkt in deinen Block-Dateien? Dann hast du keine Blockchain. So gesehen hätte niemand eine Bitcoin-Blockchain. Das ist ziemlich genau deine Anforderung an eine Ethereum-Blockchain.

        Oder: Das wäre so, als würdest du sagen, ein Buch sei so lang, wie seine Seiten plus die Interpretation / Erklärung von Begriffen / plus Zwischenzusammenfassungen jedes handlungsabschnitts …

        Es ist nicht die Definition einer Blockchain, dass sie eine Datenbank mit jeder mögliche Information ist, die man aus ihr herausholen kann. Man könnte, wie gesagt, darüber diskutieren, ob ein Full Node das können muss. Aber nicht über die Größe der Blockchain von ETH. Die ist sehr eindeutig nicht 1tb groß.

        Ohne jeden Zweifel ist es bei Ethereum sehr viel komplexer, alle Informationen aus der Blockchain rauszuholen, als bei Bitcoin, ja.

      • Kartoffelkopf // 1. July 2018 at 11:27 //

        Ich sehe das nicht so bzw. ich sehe das anders:

        Nochmals, das, was Ethereum angeblich ausmacht, sind die Smart Contracts. Sowas gibt es bei Bitcoin (noch) nicht. Eine Multisig-Transaktion ist KEIN Smart Contract. Zumindest nicht nach meinem Verständnis. Und Zwischenzutände gibt es da auch nicht. Denn nur dadurch, dass mehrere Parteien eine solche Transaktion signieren, wird diese Transaktion noch lange nicht smart.

        Aber vielleicht reden wir aneinander vorbei und müssen erstmal festlegen, was ein Smart Contract eigentlich ist (vllt ist meine Vorstellung vollkommen verkehrt). Sicherlich kann man auch eine legacy-Transaktion im Bitcoinsystem schon als Smart Contract interpretieren. Das wäre dann aber ein sehr dummer smarter Vertrag.

        Imho sind Smart Contracts eben das, was über einfache Werttransaktionen hinausgeht. Z.B. ein Vertrag, welcher automatisch, anhand bestimmter äusserer Bedinungen, entscheidet, wieviel Wert transferiert wird. Abhänging von den Bedingungen wird ein anderer Wert transferiert und die Bedingungen bestehen nicht nur aus den korrekten Signaturen. Bei solchen Verträgen gäbe es dann innere Zustände, welche die (erfüllten) Bedingungen abbilden. Wenn sowas bis zur eigentlichen Transaktione über mehrere Schritte geht, dann muss sowas nachvollziehbar sein. Entweder direkt in der Blockchain ablesbar, oder im Nachhinein aus der Blockchain berechenbar. Ersteres wäre dann der FAN, zweiteres der Weg zum FAN. In beiden Fällen bräuchte man aber 1TB ans Speicher.

        Ergo ist die Ethereum-Blockchain 1TB gross. Beim Bitcoin kann man nicht mehr aus der vollständig runtergeladenen Blockchain rausholen (natürlich kann man seine Wallet synchronisieren, aber der entsprechende Graph ist in der Blockchain 1:1 abgebildet). Und die “inneren” Zustände einer Multisig-Transaktionen, also die Reihenfolge, wer wan was signiert hat, waren nie für die Bitcoinblockchain bestimmt, da dies Offchain abläuft und Bitcoin nur der Endzustand interessiert: alles korrekt signiert oder eben nicht.

      • Nur kurz, weil ich denke, dass wir tatsächlich aneinander vorbeireden: Um bei Bitcoin zu erfahren, welches Guthaben Adresse X an Datum Y hatte, musst du auch Zwischenzustände aus der Blockchain “rekonstruieren”. Es steht genauso wenig drin, wie die Zwischenzustände von Smart Contracts bei Ethereum.

        Ich will gar nicht kleinreden, dass es einfacher ist, diese Zwischenzustände bei Bitcoin zu rekonstrieren, als bei Ethereum, wie auch dass du einen Punkt damit hast, dass es für die Erfüllung von Smart Contracts wichtig sein könnte, Zwischenzustände zu kennen.

        Aber wenn es entsprechende Skripts gäbe, um aus der 80gb Blockchain von Ethereum auf Wunsch jeden Zwischenzustand jedes Smart Contracts herauszuholen – es ist prinzipiell möglich – würdest du dann einräumen, dass die ETH Blockchain mitnichten 1tb groß ist? Dies würde bedeuten, dass du die Größe der Blockchain von den Instrumenten abhängig machst, sie auszulesen …

      • Kartoffelkopf // 1. July 2018 at 11:36 //

        Oder physikalischer / informationstheoretischer ausgedrückt:

        Die Grösse der Blockchain ist die Menge der in ihr explizit und implizit kodierten Information. D.h. die Information, welche man ohne Nutzung zusätzliche Daten aus der Blockchain extrahieren kann.

        Daraus folgt aktuell für die Grössen der Blockchains: size(Bitcoinblockchain) >= 170GB und size(Ethereum-Blockchain) >= 1TB.

      • 170gb Bitcoin Blockchain enthalten nicht die explizite Information, welches Guthaben Adresse X zu Block Y hatte.

        80gb ETH Blockchain enthalten die implizite Information, welchen Zustand X jeder Smart Contract Y zu jedem Block Z hatte.

      • @Kartoffelkopf
        Deine Ausführung ist ziemlich treffend, allerdings muss ich Dir in mindestens einem Punkt widersprechen:

        Z.B. ein Vertrag, welcher automatisch, anhand bestimmter äusserer Bedinungen

        Es gibt für eine Blockchain (derzeit) keine Möglichkeit, äußere Bedingungen einfließen zu lassen, da sämtliche (zentralisierte) Quellen manipulierbar sind. Man kann also nur “smart” Contracts bauen, die nicht so smart sind und nur den Zustand der eigenen Blockchain kennen können.

      • Kartoffelkopf // 1. July 2018 at 14:46 //

        @Christoph: Wenn man in vernachlässigbarer Zeit und Speicherplatz aus den 80GB die entsprechenden Zustände rekonstruieren könnte, dann wäre ich damit einverstanden.

        Das gilt aber noch nichtmal mehr für Bitcoin. Obwohl beim Bitcoin die Aufwand linear ist, d.h. für die Rekonstruierung einer Wallet braucht man nur die 170GB zu scannen, ist der zeitliche Aufwand dafür schon lange nicht mehr vernachlässigbar. Deswegen sehe ich aktuell auch einen qualitativen Unterschied zwischen den 170 GB von Bitcoin und den 80GB von Ethereum:

        Ein Smart Contract, welcher über viele Zustände iteriert bevor er eine Transaktion generiert, wird mehr Speicher benötigen, als eben eine Bitcoin-Transaktion. D.h. ein blockchain.info für Ethereum, welches auch die einzelnen Zustände der Verträge abbildet und sich nicht nur darauf beschränkt, die Beträge auf den Adressen aufzulisten, wird um einiges mehr an Speicher verbrauchen.

        Ob da aber nun wirklich ein qualitativer Unterschied exisitiert, das mag nich nicht voller Gänze beurteilen. Dafür ist mein Wissen zu begrenzt. Mein Bauchgefühl sagt mir aber, dass einer exisitiert.

      • Stimme dir hier mit allem zu. Es ist erheblich schwieriger, alle Zustände aus der ETH-Blockchain herauszulesen, und aus ihr den State zu generieren, braucht auch viel mehr Speicher und CPU.

      • Kartoffelkopf // 1. July 2018 at 14:54 //

        @Paul: Das ist vollkommen richtig. Der Vertrag kann nur von anderen Vertägen auf der selben Blockchain abhängig sein. Die Komplexität, welche nur daraus erwächst, ist aber schon vollkommen ausreichend …

  6. herzmeister // 29. June 2018 at 19:19 // Reply

    “TL;DR: It has nothing to do with storage space limits” — Steht schon StopAndDecrypt’s Überschrift. Die Einleitung setzt daher schon mal den falschen Ton. Warum wohl… :-]

    Und die Aussage der Artikel sei “im Detail absurd falsch” ist ebenso “im Detail absurd falsch”, denn es gibt auch einen Response dazu, und so weiter.

    “Rich Statefulness” ist nun eben mal kein Free Lunch, von der Security her.

    • Das macht die Aussage, die Blockchain sei größer als 1tb, nicht weniger falsch.

      • herzmeister // 30. June 2018 at 14:52 //

        ich hab jetz nich genau nachgemessen, aber warum falsch grundsätzlich? die eth-blockchain mag durchaus um die 1 tb sein inzwischen, das argument bei denen ist doch eher, dass das vollkommen unwichtig ist, und die alten transaktionen lediglich als archiv betrachtet werden können, da nicht benötigt zur funktionsweise, da alles im state abgebildet wird.

      • Hast du den Artikel denn gelesen?

      • herzmeister // 2. July 2018 at 8:30 //

        ja hab ich. die kleineren blockchain-versionen (ohne archiv) sind ohne das account model (statt utxo-model) nicht möglich, welches wiederum ohne die state machine nicht möglich ist. sagt der interviewte ja auch.

      • Ich denke, das hat nicht so viel mit UTXO und Account zu tun. Accounts machen es nur ein Stück schwieriger, die Vergangenheit zu rekonstruieren.

        Die kleine und große Blockchain-Version gibt es auch für Bitcoin. Da darfst du dann das UTXO-Set für jeden Block addieren. Ich schätze, das würde die Bitcoin-Blockchain auf 300 Terabyte aufblasen oder so.

  7. Zu Anonymous 30.06.2018 17:40
    Angesprochen ist offenbar diese Bitcoin Konferenz 2015 in USA wo Dr. CSW, u.a. über touring-complete sprach.

    Ab Min 05:00 “everything that we are talking about in derivated contracts can actually be done directly in Bitcoin and the Bitcoin protocoll. It is just …… that people do understand it”

    Hörenswerter Vortrag von Clemens Ley. Der Gleich zu Beginn “…what i am showing is that many things that people think are today impossible to do in Bitcoin, can actually be done”. Danke für den Link.

  8. Gutes Interview – empfehlenswert:
    http://kryptohelden.de/episode19/

  9. Danke Richard für den Podcast. Das beste was ich seit langem gehört habe. Guter Mann der Friedrich!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s