Kaspa Anhänger schießen gegen BTC

skyrmion · 19. November 2023 um 15:39

Die ausführlichen Beiträge einiger meiner Vorredner haben mich heute doch motiviert, auch noch meinen Senf dazu zu geben.

Zusammenfassung

Irgendwann kann sich herausstellen, dass das vermeintliche Trilemma nicht existiert. Aber zum aktuellen Zeitpunkt wird dieser Trade-Off von keiner Chain umgangen, auch nicht von Kaspa bzw. den zugrundeliegenden Protokollen. Genauso wie andere Smart-Contract-Projekte gibt Kaspa einen Teil von Dezentralität und Sicherheit zugunsten der Skalierung auf.

Dezentralität
Wie schon oft im Forum diskutiert, existieren m.E. verschiedene Aspekte von Dezentralität und diese können mehr oder weniger stark ausgeprägt sein.
Insbesondere ist ein Aspekt, ob jeder mit relativ geringem Aufwand, auch zuhause oder mobil, eine eigene Full Node betreiben kann. Also wieviel Geld und Vorwissen man benötigt, und ob man wegen Rechenleistung und/oder Internet-Geschwindigkeit auf Hosting Anbieter angewiesen ist (Teil-Zentralisierung).
Sicherheit
Man kann es außerdem als einen Aspekt von Sicherheit ansehen, ob jede Node mit geringem Aufwand die vollständige Blockchain, inkl. aller Transaktionen und Signaturen ab dem Genesis-Block verifizieren und speichern kann.
Ein weitere Sicherheitsaspekt ist die Komplexität der Software bzw. des Konsensmechanismus. Je komplexer dieser ist, desto größer ist die Wahrscheinlichkeit von unbekannten Angriffsszenarien, anderer Bugs, oder von Mechanismen, die zu Instabilitäten führen.

Natürlich gibt es viele weitere Aspekte. Aber zumindest in den genannten Punkten geht Kaspa im Vergleich zu Bitcoin einen Trade-Off ein, um die Skalierung zu verbessern.

Falls man aber sowieso der Meinung ist, dass nicht jeder eine Full Node betreiben können muss, dass man nicht die vollständige Historie speichern muss, und dass Komplexität keine übermäßige Bedrohung darstellt, könnte man Kaspa ggü. Bitcoin bevorzugen.
Dabei sollte man dann aber möglichst auch weitere, oben nicht genannte Aspekte berücksichtigen. Ich habe diese nur herausgepickt, um zu zeigen, dass Kaspa nicht einfach besser, sondern anders als Bitcoin ist, und dass auch Kaspa kein Trilemma widerlegt.

Begründung

Ich fange mal damit an, warum Bitcoin nicht einfach die Blockgröße und/oder die Blockrate signifikant erhöht.

Eine Erhöhung um den Faktor 10 oder 100 würde lange nicht reichen, damit man keine Zusatzlösungen für ein zukünftiges globales „electronic Cash“ mehr benötigt. Mit dem Anspruch, alle Transaktionen auf der Main Chain abbilden zu können, sprechen wir von einer Erhöhung um mindestens den Faktor 10.000, eher noch 100.000. Das wäre beispielsweise ein 100 MB Block pro Sekunde, oder einhundert 1 MB Blöcke pro Sekunde, entsprechend einigen 100.000 Transaktionen pro Sekunde (TPS).

Ohne Anspruch auf Vollständigkeit sprechen dagegen u.a. die folgenden Gründe:

1) Hard Fork
Für solche Änderungen wäre eine breite Übereinstimmung in der gesamten Community notwendig.

2) Gefährdung von Konsens und Sicherheit
Wenn während der Verbreitung neuer Blöcke im Netzwerk bereits weitere Blöcke gefunden werden, ist ein stabiler Konsens gefährdet, oder irgendwann nicht mehr möglich. Miner bauen dann jeweils auf unterschiedlichen Blöcken auf. Es gäbe ständig Forks mit wertlosen (orphaned) Blöcken. Dadurch sinkt auch die Hashrate-Schwelle für erfolgreiche Angriffe weit unter 50%.
Es muss also sichergestellt sein, dass die Blöcke einen entsprechend ihrer Größe ausreichenden zeitlichen Abstand haben. Eine neuer Block wandert im P2P-Netzwerk von Node zu Node. Bevor eine Node den neuen Block allerdings weiterleitet, verifiziert sie diesen komplett, was heute schätzungsweise in der Größenordnung von Sekunden dauert. Bis ein neuer Block also über mehrere Nodes beim Großteil des Netzwerks ankommt, vergehen heute schon mehrere 10 s (s.u. interessantes Paper von C. Decker, evtl. veraltet).
Die Verifizierungsdauer ist grob proportional zur Blockgröße. Bei sehr viel größeren Blöcken müsste man also auch die Blockzeit eigentlich erhöhen, anstatt sie zu senken.
Für eine schnellere Verteilung könnte man die Blöcke schon vor einer vollständigen Verifizierung weiterleiten (s.a. Paper von C. Decker). Aber durch eine gewisse Mindestverarbeitungs- und übertragungszeit gibt es Grenzen.
Bei zu viel Blockdaten pro Zeit bräuchte man für die reine Verifizierung irgendwann Hochleistungsrechner.

3) Speicherbedarf / Pruning
Mehr TPS bedeuten mehr Speicherbedarf auf den Full Nodes. Insbesondere bei den genannten Erhöhungs-Faktoren könnte praktisch fast niemand mehr eine Node betreiben, die nicht mit Pruning arbeitet, also alte Blöcke wieder löscht.

4) Verifizierung der kompletten Blockchain
Bei Bitcoin laden aktuell auch Full Nodes mit aktivem Pruning alle Blöcke (von anderen Full Nodes) herunter, um diese zu verifizieren, ein eigenes UTXO Set aufzubauen, und die Blöcke später wieder zu löschen.
Heute schon werden von einer neuen Node standardmäßig zwar alte Skripte/Signaturen bis zu einem Checkpoint nicht mehr verifiziert (assumeValid). Und es gibt ähnliche Checkpoint Ideen für die Übernahme eines fertigen UTXO Sets (assumeUTXO). Aber es ist immer noch zu jeder Zeit einfach möglich, alles zu laden und selbst zu verifizieren.
Bei den oben genannten hohen TPS könnte praktisch niemand mehr die komplette Blockchain ab Genesis verifizieren. Bei den großen Datenmengen würden auch kaum noch Archive Nodes existieren, von den man alle Blöcke erhielte, wenn überhaupt.

5) Internetanbindung
Die Internet-Geschwindigkeit eines üblichen privaten Anschlusses würde lange nicht mehr reichen, um alle Blöcke zu erhalten (Download), geschweige denn, sie weiterzuleiten (Upload).
Solana hat 2019 im Testnet mit 200 Nodes angeblich 50.000 TPS erreicht. Dabei allerdings mit minimalster Transaktionsgröse um die 200 Byte, was letztlich ca. 80 MBit/s entspricht. Die Nodes hatten angeblich eine Anbindung von ungefähr 100 MBit/s.
Für ein electronic Cash System unter realen Bedingungen würde man also Hochleistungsnodes mit einer Anbindung von mindestens 1 GBit/s benötigen; eher wesentlich mehr.

6) Miner-Anbindung und -Erfolg
Die Anbindung der Miner an das restliche Netzwerk sollte einen möglichst geringen Einfluss auf die erhaltenen Rewards haben. Bei sehr hohen Blockraten und Datenmengen pro Zeit, könnten z.B. Miner stark benachteiligt werden, die irgendwo abgeschieden mit überschüssiger Energie arbeiten, oder sich generell einfach in schlecht angebundenen Länder befinden.

7) Mining-Incentive
Der Konsensmechanismus und die entsprechenden Parameter müssen dazu führen, dass Miner aus eigenem, rationalen Antrieb für das Netzwerk arbeiten. Insbesondere bei sehr hoher Blockgröße oder -rate, müssen langfristig die geringeren Fees immer noch reichen.

Kaspa löst von diesen Problemen nach meinem Verständnis ungefähr die Hälfte, aber ich kann mich natürlich täuschen…

zu 1)
Projekte, die hautpsächlich von einem kleinen Personenkreis vorangetrieben werden, können leichter angepasst werden. Kaspa ist denke ich noch nicht so weit, dass zu Protokoll-Anpassungen ein breiter globaler Konsens, unter Berücksichtigung von Nutzern, Minern, Entwicklern und Node-Betreibern gefunden werden muss.
Die Umsetzung immer größerer Blockraten wird also wahrscheinlich auf wenig Ablehnung stoßen. Ob man das gut oder schlecht findet, bleibt jedem selbst überlassen.

zu 2)
… alles nach meinem aktuellen Verständnis …
Kaspa löst dieses Problem mit den erwähnten BlockDAG Protokollen. Miner können parallel auf unterschiedlichen Blöcken aufsetzen. Alle Transaktionen dieser parallelen Blöcke werden dann letztlich im Ledger berücksichtigt, solange sie sich nicht widersprechen. Es werden also keine Blöcke komplett verworfen, nur weil ein anderer Block mit teilweise gleichen Transaktionen zuerst da ist.
Die Konsensregeln entscheiden dann, identisch auf jeder Node, in welcher Reihenfolge die Blöcke bzw. Transaktionen in den Ledger aufgenommen werden. Das ist entscheidend bei Widersprüchen, aber ebenso bei der Frage, welcher Miner die Fees erhält, sollten dieselben Transaktionen in mehreren Blöcken enthalten sein.
Es ist also nicht notwendig, dass ein neuer Block sich erst überall verteilen muss, damit Miner auf diesem aufsetzen. Man kann direkt mit den bekannten Blöcken weiterarbeiten, auch während parallel zig weitere neue Blöcke eintrudeln.
Dadurch, dass möglichst viele ehrliche Blöcke berücksichtigt werden, wird auch keine Hashrate durch orphaned Blocks verworfen. Eine hohe Blockrate macht es also Angreifern nicht so viel leichter einen Double Spend durchzuführen.
Das entsprechende Protokoll (GhostDAG, später DAGKNIGHT) ist in meinen Augen sehr komplex; insbesondere im Vergleich zu Bitcoin. Dieses Problem haben viele Projekte, die skalieren wollen. Es werden sicher im Laufe der Zeit relativ viele neue Angriffsszenarien auftauchen.

zu 3)
Ohne Pruning geht es bei den hohen Datenmengen wie gesagt nicht. Allgemein würde mich interessieren, welche konkreten (!) Nachteile man durch Pruning hat. Ich habe selbst noch keine abschließende Meinung. Interessant ist dieser ältere Thread: Blocktrainer Pro und Blocksize.
Eine Verifizierung des Proof of Works der Gesamtchain wäre auch bei Pruning aller Nodes mit NIPoPoW möglich. Allerdings nicht mehr die Verifikation aller Transaktionen.

zu 4)
Bei den angedachten TPS eines weltweiten „electronic Cash“ wird keine Node mehr zu Beginn alle Transaktionen ab Genesis verifizieren.
Ich denke auch nicht, dass man langfristig überhaupt noch Nodes finden würde, die einem auf Anfrage hin kostenlos beliebige alte Blöcke zur Verfügung stellen. Anscheinend ist der Zug aber bei Kaspa eh schon abgefahren, wenn die Archive Nodes zu Beginn wirklich vergessen wurden.
Bei Bitcoin hat man zumindest immer die Möglichkeit alle Blöcke von Genesis an zu verifizieren.

zu 5)
Es kommen langfristig ausschließlich Hochleistungsnodes bei Hosting-Dienstleistern in Frage. So wie bei den anderen „skalierenden“ SmartContract-Projekten halt auch. Der Privatnutzer kann dann ohne exorbitante Kosten keine Node mehr zuhause betreiben.

zu 6)
Trotz der Möglichkeit parallel geminter Blöcke hat man bei Kaspa einen Vorteil wenn man früher dran ist, da man dann die Fees einer mehrfach vorkommenden Transaktion kassiert. Inwieweit abgeschiedenere Miner dadurch benachteiligt werden, kann ich aber nicht genau beurteilen.

zu 7)
Wie bei Bitcoin setzen sich die Rewards bei Kaspa auch aus Rewards und Fees zusammen. Insbesondere der langfristige Zustand bei vernachlässigbarer Subsidy ist aber interessant.
Erstens sollte sich der verfügbare Speicherplatz in Blöcken einigermaßen an der Nachfrage orientieren. Ansonsten brechen die Fees und damit die Hashrate langfristig ein. Das gleiche Problem wird Bitcoin auch lösen müssen.
Bei Kaspa kommt aber noch folgendes hinzu:
Falls die Miner wie bei Bitcoin alle immer die teuersten Transaktionen in die Blöcke aufnehmen, würde es viele identische parallele Blöcke geben. Das heißt trotz höherer Datenmenge hätte man nicht mehr TPS, als ohne parallele Blöcke.
Die Protokoll-Entwickler nehmen also an, dass die Miner freiwillig zufällige Transaktionen aus dem Mempool picken, da das die Duplikate minimiert und im Mittel über alle Miner der rentabelste Zustand ist.
Es gibt allerdings auch schon Analysen, die zeigen, dass wenige Miner sich in diesem Zustand immer überdurchschnittlich bereichern könnern, wenn sie die teuersten Transaktionen auswählen (eine Art selfish Mining).
Weiterhin würde genau dadurch auch die Bildung von Mining Pools incentiviert, da eine Absprache bei der Transaktionsverteilung im Vergleich zum Solo-Mining rentabler ist. Man wollte aber genau durch das neue Protokoll eigentlich das Solo-Mining ohne Pools incentivieren.
Es ist noch offen wie das in der Praxis laufen wird. Aber es gibt auch schon Ideen, wie man durch gewisse Zwänge im Protokoll die Miner in die richtige Richtung bringen könnte.
Nach meinem Eindruck ist dieser Punkt noch unklar. Man könnte im aktuell angedachten Optimal-Zustand auf jeden Fall keine Transaktion beschleunigen, indem man eine hohe Fee ansetzt. Diese Tatsache wiederum könnte einen funktionierenden Marktmechanismus stark ausbremsen.

Nachtrag

Für den Use Case als „electronic Cash“ sollte man bei solchen Vergleichen eigentlich immer die Gesamtlösung vergleichen, nicht nur einzelne Blockchains oder Payment Layer. Gesamtlösungen können z.B. sein:

Eine einzelne Blockchain/DAG (z.B. Kaspa, BSV)
Main Layer mit integriertem Sharding (z.B. in Zukunft Ethereum, Cardano, Iota etc.)
Main Layer & separate Second Layer (z.B. Bitcoin + Lightning/Sidechains/etc.)

Die beste Gesamtlösung würde idealerweise alle drei Trilemma-Aspekte und weitere Aspekte sicherstellen/optimieren: Dezentralität, Sicherheit, Skalierbarkeit, Begrenztheit, Anonymität, …

Alle Beispiele, die mir zu den drei Varianten einfallen, schaffen das nicht perfekt, inkl. Bitcoin+Lightning oder Kaspa. Man muss also einen Trade Off eingehen, bis irgendjemand eine bessere Idee hat.

Solange man es nicht schafft alle Aspekte auf einmal zu erschlagen, halte ich einen auf Sicherheit und Dezentralität optimierten Main Layer für die beste Lösung.

Quellen: