Bitcoin-Nodes müssen eigentlich niemandem vertrauen. Doch gilt das auch uneingeschränkt für neue Teilnehmer im Bitcoin-Netzwerk?
8 „Gefällt mir“
Danke @sutterseba. Du schreibst:
Die Kette mit dem größten Arbeitsnachweis ist die gültige – nicht die längste, wie häufig irrtümlicherweise angenommen wird.
Woran erkennt die Node den größten Arbeitsnachweis?
Edit: An den führenden Nullen des Block Hashes?
1 „Gefällt mir“
Hey @sutterseba,
danke für den Artikel. Der gibt einen guten Start in die Thematik. Doch jetzt kommt noch ein ABER von mir. Ich glaube, du hast die Möglichkeiten für einen Angriff ein wenig zu kurz beschrieben.
Die einzige Möglichkeit von dir einen Eclipse erfolgreich durchzuführen, wäre es, wenn man die hard-Coded Nodes kompromittieren würde. Doch in der Tat reicht es, wenn die Verbindungen zu diesen gekappt wird. Ein Internet Service Provider (ISP) z.B. wäre in der Lage, genau diese Nodes (auch die in der erweiterten Liste) entweder ganz zu unterdrücken, oder ggf. auf sich selbst zu routen (Man-in-the-Middle (MITM)). In diesem Fall wäre bei einer „Geburt“ einer Node die Gefahr weiterhin sehr groß.
Sollte ein Angriff zu einem späteren Zeitpunkt nach dem ersten Start erfolgen, ist weiterhin eine Gefahr da, denn ich könnte ja gezielt versuchen, a la MITM zunächst unentdeckt alle gefundenen Blöcke weiter durchzustechen, und nur wenn ich einen Angriff fahren möchte, weitere Blöcke unterdrücken. Ist die Node isoliert, bekommt sie das auch zunächst nicht mit.
Ein Schutz vor einem potenziellen Angriff des ISP, oder Betreiber eines Netzwerksystems (DNS, RPKI, …) durch Tor hilft leider auch nur bedingt. Die Gründe habe ich noch nicht ganz durchschaut, kann aber z.B. im BIP 324 gefunden werden (auch weitere Quellen dazu).
- Proxy networks like Tor or I2P introduce a separate address space, independent of network topology, with a very low cost per address making eclipse attacks cheaper. In comparison, clearnet IPv4 and IPv6 networks make obtaining multiple network identities in distinct, well-known network partitions carry a non-trivial cost. Thus, it is not desirable to have a substantial portion of nodes be exclusively connected this way, as this would significantly reduce Eclipse attack costs.[2] Additionally, Tor connections come with significant bandwidth and latency costs that may not be desirable for all network users.
BIP 324
Wissenschaftlicher Paper mit Hintergründen sind:
Bitcoin over Tor isn’t a good idea
Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
SABRE: Protecting Bitcoin against Routing Attacks
Es scheint jedoch nach dieser Connected Paper Übersicht, dass die wissenschaftlichen Bemühungen bereits ruhen. Also vielleicht doch weniger Grund sich zu sorgen.
3 „Gefällt mir“
Vereinfacht gesagt an den führenden Nullen von allen Blöcken der jeweiligen Chain. Das kannst du halt einfach ausrechnen. Das ist eigentlich der Existenzgrund einer Bitcoin Node: Die Chain mit der meisten Arbeit finden.
Wenn du auf deiner Node mal getblockchaininfo machst, siehst du einen Parameter chainwork mit einer Zahl. Dieser Wert gibt die erwartete Arbeit der Chain an, genauer gesagt die erwarteten Hashes, die notwendig waren, um diese Chain zu produzieren. Das wird so berechnet.
Ich bin mit den DNS-Seeds schon ziemlich ins Detail gegangen. Das ist ja keine wissenschaftliche Arbeit, sondern ein Blocktrainer-Artikel. Dieser ganze Eclipse-Absatz ist ohnehin nur wegen unserer Diskussion damals entstanden und soll nur veranschaulichen wie sehr man in unwahrscheinliche Szenarien abtauchen muss, um nur einen einzigen (belanglosen) Angriff durchzuführen. 
Natürlich gibt es noch weitere Angriffsmöglichkeiten. Aber, dass der eigene ISP einem einen Streich spielt, ist doch out-of-scope. Sollte das der Fall sein, kann mir sowieso gefälschte Bitcoin Core Software vorgesetzt werden.
In der Praxis ist meine Node nicht auf sich allein gestellt. Ich selbst kann überprüfen, ob Werte wie der oben erwähnte chainwork sinnvoll sind. Ein ISP kann mit einem solchen Angriff maximal DOS verursachen, mehr aber auch nicht.
3 „Gefällt mir“
Ich bin irgendwie immer noch nicht ganz glücklich mit dem Vergleich zum PoS, den wir ja neulich schon kurz angerissen hatten. Aber vielleicht verstehe ich es auch noch nicht ganz, da ich aktuell nicht mehr so tief drinstecke.
Was möchte jemand erreichen, der solch einen Angriff mittels einer eigenen Chain durchführt?
Einfach nur das Vertrauen und damit die Kryptowährung zerstören?
In diesem Fall wäre das mittels einer komplett neuen Chain nur theoretisch ein bedrohliches Szenario. Schließlich sollten solche (nur temporär störenden Angriffe) nicht unerwartet für das Netzwerk sein.
Oder sich selbst bereichern?
In diesem Fall hätte ich keinen Unterschied zwischen PoS und PoW gesehen, da einen Bereicherung nur über Double Spends funktionieren könnte, falls man schnell genug ist.
Es ist sehr schwierig, aber theoretisch möglich, dass jemand einen Double-Spend-Versuch durchführt (z.B. durch Kontrolle mehrerer, scheinbar unabhängiger Pools). Dagegen kann man eigentlich nur spieltheoretisch argumentieren.
Beim PoS ist das genauso. Jemand könnte sehr viele, scheinbar unabhängige Stake Pools kontrollieren, um einen Double Spend durchzuführen. Das wäre „leichter“ als bei PoW, aber spieltheoretisch betrachtet mindestens genauso unvernünftig wie bei PoW.
Wenn man allerdings, wie in deinem Beispiel, ausgehend vom Genesis-Block eine komplett neue Chain erzeugt, was dann? Damit kann man sich nicht bereichern. Schließlich existieren ja nicht einmal andere brauchbare Adressen, über die man seine Coins verkaufen könnte.
Das Zerstörungs-Szenario sollte es also eigentlich nicht geben; es können jederzeit solche selbstgebastelten Chains herumgeistern. Und im Bereicherungs-Szenario sehe ich keinen Unterschied zwischen PoS und PoW.
In Bitcoin Core verankert sind dafür sogenannte DNS Seeds, […]
Weißt du zufällig, wie das Bei Ethereum, Cardano etc. ist? Könnte mir vorstellen, dass da auch eine handvoll Standard-Nodes enthalten sind.
Fazit
[…] Zwar kann Sicherheit nie perfekt sein, und Vertrauen nie zu 100% vermieden werden, doch das Bitcoin-Netzwerk kommt diesem Ideal sicherlich deutlich näher als so manche Alternative.
Ich sehe zwar aktuell keinen, zumindest keinen für mich nachvollziehbaren Angriff, der PoS im Gegensatz zu PoW bedroht. Allerdings stimme ich dir insgesamt zu!
Gefühlsmäßig sieht man immer diesen entscheidenden PoW Vorteil, dass kontinuierlich unvorstellbar große, reale Arbeit geleistet werden müsste, um die Chain temporär zu manipulieren. Das beinhaltet den Zugang zu Energie und Hardware.
Allerdings sollte man Vergleiche von PoS und PoW auch immer unter folgenden Aspekten betrachten:
-
Angriffe, die auf einem Bruch oder einer Manipulation der Kryptographie basieren, würden beide Netzwerke zerstören. Macht es also wirklich Sinn, es als PoS Nachteil herauszustellen, dass die Blockproduktion bei PoS nur auf kryptographischen Methoden basiert und nicht auf realer Arbeit?
Ich bin mir da selbst unsicher. Genauso wie eine kryptographische PoS „Blockerstellungs-Methode“ kann man sich vorstellen, dass man SHA-256 mathematisch oder algorithmisch beschleunigt bzw. bricht.
Sollte sich PoW allerdings irgendwann an physikalischen Limits zur Hash-Erzeugung bewegen, wäre das natürlich unschlagbar. -
Sollten sich Fehler im Code befinden, wäre das ebenfalls für PoS und PoW bedrohlich. Allerdings kann man hier zumindest sagen, dass PoS an der Basis wesentlich komplexer funktioniert als PoW und damit wahrscheinlich anfälliger ist.
Aber irgendwie ist das auch ein bisschen off-topic zu deinem Artikel. 
3 „Gefällt mir“
Ja, zum Beispiel. Es ging mir jetzt auch gar nicht um konkrete Szenarien, dass diese eher theoretisch und aus heutiger Sicht erstmal unwahrscheinlich sind ist sowieso klar, sondern um den grundlegenden Kompromiss, den man mit PoS halt einfach eingehen muss.
Stell dir vor, ich gebe dir einen gefälschten Client für ein PoS-Netzwerk. Dieser sucht sich dann irgendeine gefälschte Chain zusammen, die täuschend echt aussieht. Stell dir vor, von solchen gefälschten „Dummy“ Chains gibt es Tausende. Wer sagt dir jetzt als neue Node, dass du den „echten“ Client installiert hast und welche der Tausenden Chains die „echte“ ist? Du kannst natürlich den Client nehmen, der von der Ethereum Foundation signiert ist, oder das auf Kraken gelistete Netzwerk als das Original anerkennen. Aber wirklich trustless anhand der rohen Daten kannst du das nicht selbst verifizieren.
Mit Proof-of-Work halt schon. Selbst wenn ich dir einen falschen Bitcoin Core Client mit manipuliertem Genesis Block und komplett neuer Chain gebe, kannst du an der Arbeit der Chain feststellen, dass irgendetwas faul ist.
Ne, keine Ahnung. Wird sicherlich ähnlich sein.
Mir gefällt aber die aktuelle Lösung in Bitcoin Core auch nicht wirklich besonders. Klar, ein praktischer Angriff ist natürlich unrealistisch, aber besonders elegant ist es jetzt auch nicht. Vielleicht gibt es da zukünftig auch noch einen besseren Weg.
Auf jeden Fall, im Beitrag ging es ja ohnehin nur um diesen einen Aspekt. Eine ausführliche Gegenüberstellung sollte das gar nicht werden und das wäre mir auch viel zu heiß… 
3 „Gefällt mir“
Meinst du, dass die Node das aufgrund der heutigen „Standard-Konsensregeln“ kann? Oder dass ich das selbst mittels Vorwissen oder Recherche kann?
Bei Bitcoin kann ich bei Erhalt einer Chain ausrechnen, wie viele Hashes insgesamt ungefähr dort rein geflossen sind. Da ich auswendig weiß, welche globale Hashrate wir ungefähr haben bzw. hatten, merke ich ob das zusammenpasst. Ansonsten sehe ich halt einfach irgendwo nach.
Die Node alleine kann aber nicht wissen, ob der enthaltenen PoW für den Stand heute plausibel ist, oder ob gleich noch eine Chain mit größerem PoW ankommt, oder ob überhaupt die „echte“ Chain noch ankommt. Außer man würde einen erwarteten Mindest-PoW bei Block xy in die Konsensregeln aufnehmen, was ja durchaus möglich wäre. Aktuell ist so ein Mindestwert aber meines Wissens nicht in Bitcoin Core enthalten.
Bei PoS muss ich bei Erhalt einer Chain eigentlich nur überprüfen, ob eine einzelne mir bekannte Adresse, von der schon einmal gesendet oder gestaked wurde, in der Chain vorkommt. Jemand, der eine Chain komplett neu mit eigenen Keys aufbaut, kann die bekannten Adressen ja nicht verwenden, da er den Private Key bräuchte. Eine einzelne Adresse kann ich aber doch auch einfach selbst aus meinen Daten kennen, oder recherchieren.
Ich sehe den Unterschied irgendwie immer noch nicht…
(Die PoS Überlegung mit der einzelnen Adresse ist nicht ganz ausgereift. Aber so oder so ähnlich müsste es eigentlich sein, da die Stake-Verteilung bestimmt, wer mit Wahrscheinlichkeit P einen Block erzeugen darf.)
1 „Gefällt mir“
Ich würde sagen der Unterschied liegt zumindest aktuell in den Größenordnungen der Hashrate. Natürlich kannst du komplett ohne Vorwissen nicht wissen ob die „echten“ Blöcke jetzt 10 oder 30 führende Nullen haben müssen, da gebe ich dir Recht. Was du aber (auch nicht ohne anderes Wissen) ableiten kannst ist, wie viel Energie ungefähr in dem Erstellvorgang eines Blockes steckt und damit abschätzen wie Vertrauenswürdig die Kette sein soll weil soundso viel Energie dafür geopfert wurde. Wenn die vergleichbare Energie gerade mal Berlin versorgen könnte ist die Kette wertloser als wenn die Energie komplett Europa versorgen könne (nur mal so als Random Vergleich).
Der eigentliche Punkt ist aber, im Gegensatz zum PoS, dass du beim Erhalt (wenigstens) zweier Ketten somit sofort unterscheiden kannst welche wertvoller durch mehr abgesicherte Energie ist. Das geht bei PoS nicht weil theoretisch jeder einfach ausgedachte Werte dafür eintragen kann (wie z.B. meine Kette benutzen 1000000000 Menschen oder es wird durch 200000 Coins gesichert oder whatever) All diese „Beweise“ unterliegen dem Orakel-Problem und du kannst dir nie sicher sein ob die Werte einer Kette lügen. Wenn du zwei Ketten mit unterschiedlichen Angeben unter PoS bekommst weißt du zwar dass eine Kette lügt, aber du weißt trotzdem nicht welcher du vertrauen solltest, also welche von beiden falsch ist.
Bei PoW kannst du die weniger sinnvolle Kette durch den Hash sofort erkennen und die andere Kette verwerfen oder als lügner enttarnen. (Das klappt natürlich nur solange wie der PoW bzw. der Hashalgorithmus nicht gebrochen ist denn genau hier liegt das Vertrauen in das Orakel bei Bitcoin)
Du kannst also mit PoW mit einer neuen Node solange auf einer falschen Kette mitlaufen bis du irgendwie von einer energiereicheren Kette etwas mitbekommst. Dann weißt du sofort dass du einer falschen Kette nachgegangen bist und auf die bessere Kette wechseln. Oder du bist auf der energetisch besseren Kette und dir wird eine geringere kette angeboten die do sofort ablehnen oder als Fake enttarnen kannst.
Bei PoS wären in jedem Fall die Senarien so: Dir wird eine Fake-Kette angeboten die z.B. durch irgendeine KI erstellt wurde. Wie willst du jetzt herrausfinden welche Echt ist und welche nicht? Das geht nur wenn du z.B. externe Zertifikate ausließt. Aber was ist wenn diese gestohlen oder kompromitiert wurden? Und das gillt immer für beide Senarien: Ob du erst auf der echten Kette läufst und dir eine andere Angeboten wurde oder ob du auf einer Fakekette läufst und mit der echten Kette in Berührung kommst. Du weist dann nur dass irgendwas nciht stimmt und musst dich extern schlau machen um auf deine eigen gewählte Wahrheit zu kommen.
Darin sind wir uns einig. Das trifft auf PoW und im übertragenen Sinne auf PoS zu.
Auch das ist klar und auch ein einfaches Prinzip.
Das Schöne beim PoW ist außerdem, dass Mining Energie nach einem Fork entweder in die eine oder andere Kette fließt. Das ist ein Verteil für PoW, da nach einerm PoS Fork der gesamte Stake in beiden Ketten existiert und dort als Basis zur Blockerzeugung dienen kann. Man hat seine Macht praktisch vervielfacht (Stichwort „Nothing at Stake“).
Aber im Artikel und mir selbst geht es um etwas anderes:
Diese Behauptung stört mich und ich frage mich, wie man darauf kommt?
Ich persönlich bin übrigens weder Altcoiner noch irgendeine Bitcoin Cyber Hornet, sondern ausschließlich an der Wahrheit interessiert. Ich habe jetzt mal wieder ein bisschen nachgelesen und bin auf folgendem Wissensstand, der natürlich auch fehlerhaft sein kann.
Für PoW und PoS gilt gleichermaßen:
Es gibt eine Regel, nach der eine Node trustless entscheiden kann, welcher der erhaltenen Ketten vertraut wird. Niemals kann man sicher sein, die nach diesem Maß vertrauenswürdigste Kette schon erhalten zu haben.
Über den zweiten Satz sind wir uns ja schon einig.
Bzgl. des ersten Satzes sind wir uns beim PoW einig. Eine Node präferiert nach aktuellem Nakamoto-Konsensus die Kette mit dem größten PoW.
Bei PoS, hier beispielhaft Ouroboros ab Version „Genesis“, präferiert eine Node u.a. diejenige Kette, die in einer gewissen Anzahl von Slots nach dem letzten gemeinsamen Block mit der aktuell verwendeten Kette, die meisten Blöcke produziert.
D.h. es wird geschaut, wie viele Blöcke in beiden Ketten direkt nach einem Fork produziert wurden. Die unehrliche Kette, d.h. nach Definition diejenige mit < 50% des Stakes, wird nach dem Fork immer erst einmal weniger Blöcke produzieren, da die Rechte für potentielle Blockerzeuger bereits für eine gewisse Zeit im Vorraus feststehen (kryptographisch gesichert).
Sollte jemand vom Genesis-Block ab eine komplett neue Kette erzeugen, hätte er das Problem, dass sich im echten Genesis-Block schon Transaktionen befinden. Diese Coins gehen dem Angreifer mit seinen Fake-Stakepools aber verloren, d.h. diese sind nicht an ihn delegiert und er kann nicht so viele Blöcke erzeugen, wie die echte Chain.
Ouroboros ist das Protokoll, welches z.B. bei Cardano und Polkadot eingesetzt wird. Bei anderen PoS Protokollen mag die Chain Selection Rule gerne anders aussehen; damit habe ich mich wenig beschäftigt.
A propos Orakel-Problem: Der Genesis-Block ist natürlich bei allen PoXY Blockchains im konsens-relevanten Code verankert.
Notwendige Bedingung für die Funktion des Distributed Ledgers sind bei Bitcoin und bei Ouroboros übrigens eine ehrliche Mining- bzw. Stake-Mehrheit von 50%.
Bei Interesse:
→ https://iohk.io/en/blog/posts/2023/02/09/ouroboros-genesis-enhanced-security-in-a-dynamic-environment/
→ https://eprint.iacr.org/2018/378.pdf
→ IOHK | Ouroboros Genesis: A Provably Secure Proof-of-Stake Blockchain Protocol - YouTube
→ IOHK | Cardano Community Meetup in London: Ouroboros PoS Research - Prof. Aggelos Kiayias - YouTube
Hier noch ein Zitat aus dem Paper:
Thus the new rule substitutes a “global” longest chain rule with a “local” longest chain rule that prefers chains that demonstrate more participation after forking from the currently held chain Cmax.
As proven in Section 4, this additional condition allows an honest party that joins the network at an arbitrary point in time to bootstrap based only on the genesis block (obtained from FINIT) and the chains it observes by listening to the network for a sufficiently long period of time.
In prior work, a newly spawned party had to be assumed to be bootstrapped by obtaining an honest chain from an external, and fully trusted, mechanism (or, alternatively, be given a list of trustworthy nodes from which to request an honest chain); our solution does not rely on any such assumption.
1 „Gefällt mir“
Das ist ein guter Punkt und ich muss erstmal darüber Nachdenken.
So wie ich dich spontan verstanden habe baut die Sicherheit von PoS darauf, dass Coins die Staken auch früher erst einmal erworben sein müssen und das in der Blockchain bewiesen sein muss.
Das mag zwar sein, aber so wie ich PoS verstehe geht das „Minen“ durch Stakes ja nicht schneller oder langsamer nur weil mal mehr und mal weniger Coins staken. So wie ich es im Kopf habe (Noch hab ich diene Quellen nicht durchgelesen!) wird bei PoS eine eine Zeit festgelegt (z.B. alle 90 Sekunden) und zu dieser Zeit dann aus allen Stakenden Coins quasi einer Ausgewürfelt dessen Besitzer dann den nächsten Block bauen darf. Wer mehr Coins hat wird natürlich auch häufiger ausgewählt. Das Prinzip kann man dann unterschiedlich ausprogrammieren und z.B. Stakende Coins die bei Blockgenerierung dann offline sind bestrafen usw.
Ausgehend von diesem Stake-Modell könntest du aber einen Angriff durch eine gefälschte Blockkette nicht erkennen, denn der Angreifer kann ja in seiner neuen Kette alleine mit vielen eigenen Nodes Staken. Das einzige was mir einfällt ist, dass es vielleicht auffällt, dass viele andere Coins, die vorher gestaked haben nicht mehr staken…
Aber je nachdem wie früh der Angreifer die Kette vom Orginal absplittet kann er die komplette Kette von beginn an nachrechnen. Denn warum sollte sich der Angreifer beim Nachrechnen der Kette an die Zeitbeschränkung halten? Er kann alle am Angriff beteiligten Nodes auf das Startdatum der Absplittung von der Mainkette setzen (und je nachdem wie früh das ist fallen fehlende stakende Coins eben nicht auf) und dann den Stakingprozess für viele (eigene) Teilnehmer emulieren indem er die Uhrzeiten der Nodes auch schneller voranschreiten lässt und so z.B. jede Sekunde 10 Blöcke findet bis die Kette genauso lang ist wie die originale. Wenn dann noch viele Transaktionen mit eingeflossen sind, so viele wie in der Originalen auch, dann kann man die Angreifer-Kette eben nicht mehr von der orignalen Kette unterscheiden. Ja das Nachrechnen der Orginal-Kette kostet auch Rechenzeit, aber eben wegen dem Staking nicht ansatzweise so viel wie bei PoW. Oder habe ich irgendwo einen Denkfehler?
Ich hab irgendwann mal von einem Projekt gelesen wo es ein PoT gab, also ein Beweis dass eine gewisse Zeit gewartet wurde. ich weiß spontan nicht ob das wirklich geht und wie das funktioniert, aber damit könnte man so einen Angriff (wegen der Zeitmanipulation) eventuell auch verhindern.
Aber ich denke nocheinmal darüber nach was es bedeutet dass die Stakingrechte für eine Zeit geblockt sind. Das birgt nämlich einige Komplikationen: Was ist wenn mal eine Node ausfällt? Auch die echte Kette würde den Block ja dann nicht bekommen und „langsamer“ laufen und somit auch Angriffe ermöglichen.
1 „Gefällt mir“
Ich habe mich oben auf das delegated Proof of Stake Protokoll Ouroboros beschränkt. Von Casper (Ethereum) mit Slashing etc. habe ich noch weniger Ahnung.
Kann gut sein, dass die Betrachtung dort ganz anders aussieht. @sutterseba hatte ja einen Post von Vitalik Buterin verlinkt.
Jeder Coin Besitzer kann mittels eines geheimen Staking Keys seinen Stake, auf der Blockchain dokumentiert, für einen gewissen Zeitraum an jeden verfügbaren Pool delegieren. Hierzu ist auch kein Transfer von Coins nötig, dieses bleiben in der Wallet des Besitzers.
Wenn also vom Genesis Block an erst einmal nichts delegiert wäre, hast du vielleicht recht. Wenn im Genesis Block aber schon delegiert wird, dann an Pools, die nicht unter der Kontrolle des Angreifers stehen. Möchte dieser also eine komplett neue Kette aufbauen, geht ihm ein Teil des delegierten Stakes verloren, da diese nicht an die eigenen Pools delegiert ist. In den entsprechenden Slots fehlen dann Blöcke.
Die oben beschriebene Chain Selection Rule würde in diesem Fall die Kette mit der höheren Blockdichte nach dem Fork, also die ehrliche bevorzugen.
Ich stecke aber überhaupt nicht mehr im Thema drin und habe keine Ahnung wie das im Cardano Genesis Block ist. Das Ouroboros Protokoll wird ja auch ständig weiterentwickelt.
Allerdings könnten z.B. auch Checkpoints im Code verankert werden, also Stände zu gewissen Zeitpunkten, Damit hätte ein Angreifer dann immer das beschriebene Problem, dass keine komplett neue Kette erzeugt werden könnte, und ein Fork irgendwann später erst einmal langsamer laufen würde. Aber es ist natürlich unschön Checkpoints einzutragen, da man sich darauf in der Realwelt einigen müsste. Wobei theoretisch jede Node einen Block eintragen könnte, wie er/sie möchte.
Klar, das ist auch genau so. Aber auch nicht wirklich anders als beim Mining. Entsprechende Angriffsszenarien wären bei PoW und bei PoS denkbar.
Ich kann diese Diskussion aktuell leider auch nicht bis ins Detail zu Ende führen, da ich wie gesagt nicht mehr so tief im Thema drin bin.
Stichwörter sind „Long Range Attack“ und „Costless Simulation“. Ich habe mir allerdings angewöhnt, nur noch Ouroboros-spezifische oder komplett Coin-unabhängige wissenschaftliche Inhalte zu lesen.
Es gibt einfach zu viel PoS Bullshit auf irgendwelchen Bitcoin Seiten oder von absoluten Shitcoins.
Ein generelles Problem von PoS wird aber hier schon deutlich:
Es ist einfach wesentlich komplexer, sich über alle möglichen Angriffsszenarien Gedanken machen zu müssen, die nur dadurch entstehen, dass es nichts kostet eine Chain zu erstellen. Komplexität ist aber immer der Feind der Sicherheit.
1 „Gefällt mir“
Ich bin grad dabei das Paper durchzuarbeiten, kann aber nicht versprechen es 100% sofort zu verstehen.
Das mit den geblockten Stakingcoins ist einleuchtend und so hab ich es mir auch in der Zwischenzeit überlegt: Wenn für eine Epoche von Blöcken im Vorraus schon feststeht wer in der Periode genau staken wird und das Staken nur mit privatem Schlüssel möglich ist, dann kann ein Angreifer wie du richtig sagst nicht so einfach die Kette Offline übernehmen. Weil in den Blöcken des Angreifers würden die festgelegten Blöcke der anderen Teilnehmer fehlen und es wäre sofort ab diesem (auch in der Vergangenheit liegenden Periode) erkennbar durch die längere echte Kette wer Recht hat. Das leuchtet ein.
Aber was mir spontan dazu einfallt (aber auch sehr unrealistisch ist): Ein Teilnehmer darf in einer Periode nie zufällig alle Blöcke erstellen. Denn dann hat er die Hoheit über den Inhalt der Periode und kann sich (auch jederzeit nachträglich!) ab dieser Periode eine valide Offlinechain erstellen weil er ja selber in seiner fake-Chain dann bestimmen kann wer Staked und somit seine Stakes bei seinen eigenen Nodes bleiben. Damit kann er auch in den Folgeperioden immer selber staken und somit eine exakt genauso lange Kette erstellen. Bei Bitcoin wäre es theoretisch nicht schlimm wenn mal zufällig 100 Blöcke von einem einzelnen Akteur kommen. Aber jeh nach Anzahl der Blöcke in einer Periode kann man diese Chance ja relativ gering halten.
Was die obige Chance aber wieder vergrößert ist auch, dass aktive Staker ausfallen können und somit die echte Blockchain künstlich kürzer wird und Angriffe in dieser Periode wahrscheinlicher werden. Und wie geschrieben, es muss im Gegensatz zu Bitcoin nur einmal zu einem singulären Ereignis kommen (von dem nicht einmal bekannt sein muss dass es passiert ist) und der Akteur kann für immer auch beliebig im Nachhinein die Kette nachrechnen.
Außerdem im Beispiel des Genisis Blockes: Ja auch der Ersteller hat mit diesem Block und seinen privaten Schlüsseln die Macht so einen Angriff durchzuführen und seine Blockchain nocheinmal komplett neu durchzurechnen (oder jeder der die privaten Stakingschlüssel des Genisisblockes bekommt was vielleicht eine größere Angriffsstrategie sein kann 
).
Edit2: Zitat aus dem Paper (Übersetzt):
In Ouroboros Genesis enthält dieser Block die Schlüssel, Unterschriften und die ursprüngliche Anteilsverteilung der Parteien, die zu Beginn des Protokolls anwesend waren.
Soll heißen sobald diese Schlüssel irgendwie geknackt werden können kann derjenige vom Genisisblock an beliebig seine eigene Chain entwickeln.
Edit: also Ja, auch in Bitcoin gibt es Probleme wenn bestimmte Schranken überschritten werden wie z.B. die 50% Attacke. Worauf ich hier eigentlich hinaus will ist, dass bei PoS die Blockchains nach erreichen dieser Schranken sofort komplett kompromitiert sind während Bitcoin eine einmalige Kettenänderung durchführt (die meistens nur wenige Blöck entspricht) und dann weitermachen kann.
1 „Gefällt mir“
Ok, ich gebe dir recht: Unter normalen Umständen ist es relativ einfach möglich die echte Kette zu erkennen wenn man die Blockdichte der Ketten zum Fork-Zeitpunkt betrachtet weil ein Angreifender Staker ja erstmal weniger Blöcke erzeugen kann als die echte Kette (vorausgesetzt er hat nicht 50% des Stakes) und das Erzeugen der Blöcke ist kryptografisch vom Stake mit Private Key gesichert.
Sobald er aber einmal 50% des Stakes hat bzw. genauer gesagt mehr als 50% aller Blöcke eine Epoche gefunden hat, kann er für immer (auch nachträglich) ab diesem Zeitpunkt eine validen Abspaltung erstellen die er wegen seiner Coin-Hoheit auch beliebig lang machen kann und somit immer die bessere Kette werden kann.
Wenn man das mit Bitcoin vergleicht klingt es wie eine 50% Attacke und ist relativ unwahrscheinlich aber leider auch deutlich gefährlicher als der PoW Algorithmus. Wenn bei Bitcoin ein Pool mal zufällig mehr als 50% Rechenleistung hat kann ein Angriff nur in der Zeitspanne passieren wo der Pool diese Hashrate auch aufbringen kann. Bei PoS kann der Angriff auch noch Jahre später von diesem Ereignis aus die Kette spalten und sogar das „richtige“ Netzwerk überschreiben.
Was man dann weiter diskutieren kann ist: was ist wenn ein Angreifer die privaten Schlüssel der Staker unbemerkt klaut und somit die Stakinghoheit bekommt? Er kann damit unbemerkt einmalig über die 50% kommen und das Netzwerk dann Jahre später angreifen. Dabei spielt natürlich auch eine Rolle ob die anderen Netzwerkteilnehmer (oder der Angreifer selber) Blöcke auslässt um über die 50% zu kommen.
Wenn der Angreifer Blöcke auslässt kann er diesen ausgelassenen Block in seiner Offlinekette trotzdem im Nachhinein mit aufnehmen während die Öffentlichkeit nicht mitbekommt dass in dieser Periode mal 50% der Blöcke vom Angreifer erstellt wurden. Und wenn andere Teilnehmer Blöcke auslassen hat der Angreifer es einfacher auf die 50% zu kommen.
Vor allem finde ich es aber beunruhigend dass die Kettenersteller jederzeit so einen Angriff durchführen könnten weil sie schon im aller ersten Block die volle Coinverteilung und Stakingregeln kennen und somit auch immer vom aller ersten Block auf einen validen Fork erstellen können. Und für jede Periode von Blöcken gibt es die zufällige Chance dass ein Akteur mal 50% der Blöcke erstellt. Die Chance dass so ein Angriff also passieren kann steigt mit der Zeit an und wird umso gefährlicher je weiter sich ein Akteur der 50% Marke nährt (Wobei die Ersteller ja definitiv 100% zu beginn und wahrscheinlich auch viele Perioden danach besitzen)
Jetzt kann man ja weiter Argumentieren dass die Ersteller und ein 50% Staker kein Interesse an einem Angriff haben weil der Wert ihrer Kette und Coins dann sinkt. Das mag zwar aktuell stimmen, aber ist das auch in Zukunft so? Was ist wenn ein Ersteller seine Meinung ändert und sein Projekt zerstören will? Z.B. wenn er seine Werte komplett abgezogen hat und mit so einem Angriff eben nocheinmal versucht die Kette zu überschreiben? Außerdem gibt es ja immer die Gefahr dass die Schlüssel gestohlen werden und es reicht veraltete Schlüssen der Vergangenheit zu bekommen. Sobald man 50% der privaten Schlüssel einer Epoche gesammelt hat kann man die Kette ab diesem Zeitpunkt valide Forken.
Abschließend: Ja du hast recht: Generell kann man die Valide Kette auch bei PoS sofort erkennen und einfache Angriffe oder falsche Ketten fallen relativ einfach auf denn ansonsten würde ja jede Blockerstellung schon zum Fork führen. Einer neuen Node kann somit nicht jeder beliebig eine falsche Kette unterjubeln. Erst wenn einmalig 50% der erstellen Blöcke einer Epoche in den Händen eines Angreifers sind, was auch beliebig rückwirkend der Fall sein darf, dann kann der Angreifer die Kette valide Forken und somit übernehmen und jeder neuen Node seine Kette unterjubeln.
Was ich noch lustig finde ist, dass Youtube mir bei der Recherche nach „Ouroboros Genesis“ Videos wie „Der Beweis das die Erde eine Scheibe ist“ vorgeschlagen hat 
Gibt es für das Thema keine Videos auf Deutsch? 60 Seiten Englisch finde ich immer so ermüdend.
1 „Gefällt mir“
Ohje.
Während beim Proof-of-Work-Mechanismus geleistete Arbeit darüber entscheidet, wer Autor eines neuen Blockes sein darf, spielt bei Proof of Stake investiertes Kapital eine Rolle. Dieses verliert bei unserem theoretischen Angriff aber seine Authentizität, da schließlich die gesamte Historie, also auch vermeintlicher Reichtum, vorgetäuscht werden könnte.
Also zuerst einmal: Jede aktuelle Blockchain, selbst Bitcoin hat Checkpoints. Alles was ich jetzt schreibe trifft also auf den Checkpoint oder wenn wir das in der Ur-Form betrachten auf den Genesis-Block oder die Situation, als wir von PoW zu PoS gewechselt sind (z.B. bei Ethereum) zu. Es wäre möglich, dass ein Protokoll schlechtere Designentscheidungen trifft, aber generell ist es so implementierbar und oft auch so oder ähnlich implementiert:
- Zum PoS-Start sind die „initialen“ Staker klar.
- Ein weiterer Staker, der seine Funds einlockt und einen Validator betreiben möchte muss von einem bestehenden Staker gemined werden.
- Alle Aktionen, wie z.B. das Finalisieren der Kette oder die Validator-Selection werden idr. maßgeblich durch die Mehrheit der Staker/Validatoren beeinflusst, bzw. bestimmt.
- Oft verhalten sich Netzwerke so, dass sie ohne eine Mehrheit von >50% oder >=67% der Validator-Selection keinen finalisierten Zustand erreichen können.
Davon lässt sich ableiten:
- Du brauchst zu irgend einem Zeitpunkt mehr als 50% oder 67% der eingelockten Funds oder bei Systemen wie z.B. ETH mehr als 67% der private keys der Validatoren zum Start-Zeitpunkt (=dem Zeitpunkt ab dem Du die Kette fortberechnen möchtest).
- Es ist also notwendig diese PKs zu knacken, zu kaufen oder zu stehlen.
Im konkreten Beispiel mit ETH sind das 420000 Validator private-keys beim Wechsel von PoW auf PoS und 660000 Validator private-keys heute. Durch Slashing und die finalisation-Regel bräuchte man beim Start also 840000 private-keys (so viele haben nie existiert) oder wenn man die Keys von bestehenden Börsen einsackt immer noch 280000. So viele standen nie zentralisiert zur Verfügung.
Es gibt also zumindest für Ethereum keinen Weg die Chain „zu simulieren“ auch nicht für eine „gewiefte AI“.
Eine erstmals gestartete Node in solch einem Netzwerk hat also keine Möglichkeit zu erkennen, ob es sich bei der einen oder der anderen Blockchain um den „echten“ Zustand handelt und muss sich eine geeignete externe Quelle für diese Entscheidung suchen.
Das ist korrekt. Aber: Hier steht PoW vs PoS in sofern da, dass PoW trotzdem synchronisieren kann und die PoS-Node halt den Dienst mit einer Fehlermeldung quittiert, bis man ihr externe Information zufügt. (Den Root-Hash der letzten Epoche z.B…) Leider sollte man nie darauf vertrauen, dass das Gossip-Protokoll funktioniert während dem Bootstrap-Fall der Node, es müssen also BTC PoW und auch die PoS-Node gegen einen Block-Explorer (oder meinetwegen auch die Difficulty aus dem Gedächtnis, trotzdem externe Information) getestet werden.
Streng genommen könnte man also argumentieren, dass ein Proof-of-Stake-Netzwerk per se nicht ohne Vertrauen funktionieren kann, alleine weil zwei konkurrierenden Chains zunächst nicht eindeutig auf deren „Echtheit“ beurteilt werden können.
Das ist falsch. Der schlechte Zustand (z.B. zwei konkurrierende Chains) kann bei funktionierendem Gossip-Protokoll (das ist auch die Annahme für den restlichen Absatz) erkannt werden und erst dann kann die Situation nicht trustless aufgelöst werden. Das heißt aber auch, dass die überwiegende Mehrheit (wo es keine konkurrierenden Chains gibt) ein vertrauensfreier Start möglich ist. Das Gossip-Protokoll leitet übrigens keine Chainforks weiter, die dem weak subjectivity root der Node, welche weiterleiten müsste widerspricht. Es ist also ziemlich schwer einen Konfliktzustand dort zu publizieren, ähnlich wie Bitcoin-Nodes keine Transaktionen weiter leiten, die nur den mempool flooden sollen, etc.
Befürworter von Proof of Stake sprechen daher auch von „schwacher Subjektivität“, da ein Teil des Konsensmechanismus sozusagen auf eine soziale Ebene ausgelagert werden muss.
Das ist unglücklich formuliert und wird evtl. von einigen Lesern falsch aufgefasst: Die Begriffe Objektivität, Subjektivität und schwache Subjektivität kommen daher, wie die Node die Realität feststellen kann:
- PoW bei BTC ist objektiv, weil man sozusagen mit einer Regel immer die beste Kette wählen kann: Welche Kette hat das meiste absolvierte notwendige PoW.
- Subjektivität bedeutet, dass jede Node die Realität aus ihrer Sicht wahr nimmt.
- Schwache Subjektivität bedeutet, dass jede Node die Realität aus ihrer Sicht wahr nimmt, sich die Nodes aber nach Regeln auf eine gemeinsame Realität einigen.
Es muss kein Teil des Konsens auf eine soziale Ebene ausgelagert werden, sondern es kann im worst-case (oben das beschriebene Bootstrap-Problem) notwendig werden. Eine synchronisierte PoS-Node benötigt keinen sozialen Eingriff mehr, außer sie ist zu lange offline - aber dann ist es ja auch keine synchronisierte Node mehr.
Natürlich bedeutet dies nicht, dass Proof-of-Stake-Netzwerke alleine deshalb zum Scheitern verurteilt sind, aber es ist ein interessanter Diskussionspunkt, der zwar recht theoretisch, aber dennoch grundlegende Kompromisse gegenüber Bitcoins Konsensmechanismus aufzeigt.
Würde mich interessieren, wie hier die redaktionellen Vorgaben gewesen sind. Denn es gibt eine ganze Reihe an Vorteilen von PoS, die hier einfach unterschlagen werden, z.B.:
Bei PoW kann ich die Kette mit hoher total difficulty „übernehmen“, wenn eine Eclipse-Attack gelingt und neue Blöcke vorenthalten oder sogar versuchen mit wahrscheinlich weniger Hash-Rate eine alternative Realität zu erschaffen. Das ist bei PoS nicht möglich. Bei PoS stellt die eigene Nodes den Betrieb ein und kein Angreifer kann einfach so die Kette weiter berechnen, weil ihm die private keys fehlen, usw.
Dadurch und z.B. auch durch das vorgegebene Timing-Verhalten hat ein PoS-System bei den beschriebenen Angriffsvektoren mit Ausnahme der Bootstrap-Situation eigentlich nur Vorteile.
Ich finde den Artikel schwierig, denn funktionierendes Gossip-Protokoll vorausgesetzt ist die einzige Bredouille in die ich mit PoS in diesen Szenarien kommen kann, dass die Node den Dienst verweigert und ich manuell eingreifen muss. Ansonsten habe ich eigentlich nur Vorteile.
Aber natürlich gibt es andere Nachteile bei PoS, wie erhöhte Komplexität usw.
2 „Gefällt mir“
Huhu @GhostTyper,
Bei PoW werden ja so schnell wie möglich Blöcke gewürfelt und wenn die eine gewisse Schwierigkeit erfüllen gelten sie als gemined. Für einfache PoS Systeme wird so schnell wie möglich, also der arbeitsintensive Teil verhindert indem nur z.B. alle 90 Sekunden gewürfelt werden darf. Das hat aber den Nachteil, dass Miner die Zeit ausstellen können und trotzdem eine Art PoW daraus machen.
Bei Ouroboros wird das PoW so verhindert, dass die Nuance (also die Möglichkeiten wie man einen gültigen Block erstellen kann) auf 1 pro Sekunde gesetzt was bedeutet also egal wie viel man rechnen kann es geht nur 1 pro Sekunde. Mithilfe Kryptografie (ist für den Kontext erstmal nicht relevant aber definitiv spannend zu untersuchen) kann man dann die Gewichtungen der Votes pro Sekunde mit dem eingesetzten Stake verbinden und anhand der Stakes kann man die Difficulty festlegen. Ein gefundener Block muss aber mit den privaten Stakerschüssel signiert werden um seine Anwesenheit zu beweisen.
Für diesen Standart Fall geb ich dir recht dass man einfach anhand der längeren Kette die echte Kette erkennen kann weil ein Angreifer zwar die Kette aus der Vergangenheit verzweigen kann und die Sekunden im Schnelldurchlauf durchrechnen kann aber weil er nicht die Privaten Schlüssel hat wird er lokal zu dem Forkzeitpunkt nur seine Stakerblöcke finden und damit definitiv weniger Blöcke pro Zeit generieren können als die echte Kette. Mithilfe der Blockdichte zum Kettenabsplittungszeitpunkt kann man also vertrauenslos die echte Kette erkennen.
Was ist aber, wenn es einmal jemanden gibt, der zufällig mehr als 50% aller Blöcke einer Periode gefunden hat? Das Problem ist dass er jetzt jederzeit auch aus der Zukunft von dieser Stelle aus einen validen gültigen Fork erstellen kann. Ja das mag unwahrscheinlich sein aber theoretisch ist die Kette ab diesen Zeitpunkt für immer angreifbar. Noch schlimmer: wenigstens der Genesisblock eines PoS wurde vom Ersteller der Kette erstellt und dieser hat zu diesem Zeitpunkt die Hoheit des Minings. Jeder PoS-Ersteller könnte also von diesem Zeitpunkt seine Kette jederzeit nachrechnen und eine Valide längere Blockchain erstellen als die echte Kette. Jetzt kann man sagen das wäre unökonomisch für den Ersteller oder jemanden der einmalig 50% aller Blöcke in einer Periode gefunden hat, aber was ist wenn der Ersteller sein Projekt zerstören will oder der Angreifer seine Werte aus der Chain schon wieder rausgezogen hat und dann durch den Angriff versucht sich wieder einzuhacken?
Wegen dem Konsenzmechanismus und weil der Angreifer dann die Stakehoheit hat kann er beliebig längere Ketten aus der Vergangenheit aufbauen und die Dichtevorraussetzung erfüllen. Eine neue Node könnte die echte Kette dann nicht mehr von einer Angreifer-Kette unterscheiden.
Hab ich irgendwo ein Denkfehler?
Edit. Für einen 50% Angreifer könnte es sein, dass er deutlich mehr als 50% der Blöcke einer Periode braucht weil er ja zu dem Zeitpunkt in der Vergangenheit ja redlich Blöcke erstellt hat. Ein valider Fork müsste mehr Blöcke als diese und die Blöcke der anderen Netzwerkteilnehmer haben was doch sehr unrealistisch ist (z.B. dass der damals redliche schon ein zwei Blöcke nicht veröffentlicht hat oder andere Netzwerkteilnehmer ausgefallen sind). Aber die Gefahr der Kettenersteller bleibt. Es müssten theoretisch nur die privaten Schlüssen der Kettenersteller geklaut werden und die komplette Kette kann von Beginn an nachgerechnet werden und die echte Kette überschreiben.
Hey,
Das verstehe ich nicht. Die meisten PoS-Chains akzeptieren nur einen Block auf gleicher Blockhöhe von einem Validator und es gibt keine PoW-Komponente. Zwei Blöcke oder zwei Attestate vom gleichen private-key auf gleicher Blockhöhe könnte (wenn es Slashing in dem Netzwerk gibt) ein slashable offence sein.
Das wollte ich nicht als Argument anbringen. Viel eher so: Bei ETH z.B. benötigst Du für Epochen >= 67% der private keys. Du kannst die Kette also nicht mit weniger im Schnitt fortschreiben.
In diesem Fall werden alle Nodes, die bei dem Versuch online waren diesen neuen Fork ignorieren und auch nicht über das Gossip-Protokoll verteilen. Eine Node in der Bootstrap-Situation sieht dann zwei konkurrierende Chains und verweigert den weiteren Start und erwartet dann sozusagen externe Information.
Korrekt. Siehe Antwort eines darüber und noch folgendes: Aktuelle Node-Software ist gegen den Angriff wahrscheinlich immun, weil sie einen „neu genugen“ Checkpoint hat.
Zu beachten ist auch noch, das Netzwerke On- und Offboarding Queues implementieren können. Diese verlängern die Zeit meistens über die letzten Snapshots und Root-Epochen hinaus in der man immer noch geslashed werden kann, wenn man eine parallele Kette aufbaut.
2 „Gefällt mir“
@GhostTyper, danke für deine ausführlichen Beiträge!
Letztlich ging es ja um die Frage ob eine Node bei Erhalt von mehreren Chains, unter denen sich die bisherige „ehrliche“ Chain befindet, diese ohne Hilfe von außen erkennen kann. Und darum, ob sich PoW und PoS hierbei unterscheiden.
Das Problem beim Versuch zu antworten fängt für mich schon damit an, „ehrlich“ zu definieren. Ist die Chain die „ehrliche“, die bisher allgemein akzeptiert wurde? Oder ist es die Chain, welche zum aktuellen Zeitpunkt die Hash- bzw. Stake-Mehrheit besitzt? Oder einfach diejenige, die nach aktuellen Konsensregeln als gültige Chain gewählt wird?
Die letzten beiden Definitionen wären für diese Diskussion witzlos, da hiernach alle Konsensmechanismen die ehrliche Chain verwenden, selbst während und nach einem Double-Spend-Angriff.
Als „ehrlich“ betrachte ich also die Chain, die bisher allgemein akzeptiert wurde.
Unter diesem Aspekt verstehe ich deine Erklärungen noch nicht ganz. Evtl. kommt das aber auch vom Unterschied zwischen Casper und Ouroboros. Das Bootstrapping-Problem habe ich auch noch nicht durchblickt.
Falls bei PoS tatsächlich schon eine „Blockerzeugungs-relevante“ Stake-Verteilung im ersten PoS Block oder auch in späteren Checkpoints verankert ist, würde es doch genügen, von da an immer die Chain bevorzugen, die in den ersten N Blöcken nach einem Fork die meisten Blöcke produziert (siehe Ouroboros).
Damit würde eine Node immer komplett trustless die bisherige ehrliche Chain erkennen. Zumindest beim delegated PoS kann ich mir das so vorstellen, da ein Angreifer mit < 50% Stake eine Zeit lang weniger Blöcke als die Mehrheits-Chain erstellen kann. Bei non-delegated PoS weiß ich das nicht.
Angriffe mit > 50 % kann man ausklammern, da man diese sowieso niemals ohne weitere Realwelt-Absprachen in den Griff kriegen könnte.
Das ist tatsächlich sehr interessant, kannte ich noch nicht!
Allerdings sieht es für mich nach erstem Überfliegen des Codes so aus, als wäre ein enthaltener defaultAssumeValid-Block keine notwendige Bedingung für eine valide Kette.
Viel mehr sieht es so aus, als würde die Node bei Erfüllen mehrerer Kriterien, wie z.B. das Enthalten des defaultAssumeValid-Blocks und ein bestimmter Minimal-PoW, die Validierung der vorherigen Blöcke überspringen, um Zeit zu sparen.
Falls der Block allerdings nicht enthalten wäre, würde die Node einfach alle Blöcke validieren und am Ende trotzdem die Kette mit dem meisten PoW bevorzugen. Die Erfüllung aller Abkürzungs-Kriterien zusammen wären also hinreichend, aber nicht notwendig.
Ich mag mich aber täuschen, da ich es nicht im Detail nachvollzogen habe. Hier stehen einige Hinweise, aber inzwischen wurde der referenzierte Code leicht angepasst: https://github.com/CryptAxe/info/blob/master/AssumeValid.md
Gibt es bei Ethereum wirklich harte Checkpoints, die in einer validen Kette vorhanden sein müssen?
1 „Gefällt mir“
Hey @skyrmion.
Dann musst Du ja auch erst mal definieren was „allgemein akzeptiert“ bedeutet.
Technisch kannst Du nicht auflösen, was sozial oder moralisch ehrlich für die Chain ist, von daher kann diese Diskussion nur darum gehen, was nach den aktuellen Konsens-Regeln die gültige Chain ist.
Bei Bitcoin oder PoW ist das objektiv die „schwerste“ PoW-Kette, also die mit der höchsten kumulativen PoW-Anforderung. Und zwar egal, ob ein Double-Spend passiert ist oder nicht und auch egal ob Leute diese Chain gut finden oder nicht.
Bei Ethereum (also einer PoS-Implementation) gibt es keine objektive Betrachtungsweise. Das beste was wir haben können ist eine subjektive Wahrnehmung einer jeden einzelnen Node. Das Netzwerk als ganzes kann einen objektiveren (aber keinen objektiven) Zustand dadurch erreichen, dass jede Node durch attestieren der Kette die sie aus ihrer Sicht für die richtige hält mitteilt und wir dann statistisch sehen, was die Mehrheit (bei Ethereum müssen das 67% der Nodes über Epochen hinweg sein) für die korrekte Kette hält. (Keine Ahnung, ob dieser Satz korrektes Deutsch ist.)
Wenn wir eben geschriebenes durchdenken gibt es meiner Meinung nach die folgenden 4 Fallunterscheidungen mit unterschiedlichem Ausgang (wir nehmen an, dass das Gossip-Protokoll ordnungsgemäß funktioniert):
- PoW im Bootstrap-Fall: PoW findet die Richtige Kette automatisch auch wenn es zwei Ketten mit gleicher Blockhöhe gibt.
- PoS im Bootstrap-Fall: Die PoS-Node muss den Start verweigern, weil sie keine Möglichkeit hat die richtige Kette zu finden, kann den Angriffsvektor aber erkennen.
- PoW im Betrieb: PoW findet nicht mehr garantiert die beste Kette und rechnerisch wäre es leichter einen gültigen Block an eine PoW-Kette anzuhängen als den PK eines Validators „zu Knacken“.
- PoS im Betrieb: Es ist unmöglich die Kette zu übernehmen, außer Du hast 50% oder 67% der private-keys der Validatoren.
Ich kenne mich mit Ouroboros nicht gut genug aus. Da es aber auch generell um PoS geht kann ich sagen, dass sich PoS ohne irgendwelche Shananigans, die den Aufwand PoW „nachempfinden“ (wenn das alles so ist) nicht auf eine Anzahl Blöcke oder ähnliches verlassen kann.
Es könnte auch eine Situation einer klassischen long-range-attack sein: Die Leute, die Früher Validatoren betrieben haben machen das heute nicht mehr und haben ihre private-keys von damals verkauft. Dann könnte eine konkurrierende Kette, korrekt signiert aufgebaut werden, die eine Node täuschen könnte, bzw. dann zu dem Konfliktfall (Punkt 2 oben) führt.
Ich glaube ohne dass ich mich groß damit Beschäftigt habe, dass defaultAssumeValid nur relevant ist, wenn man keine komplette Validation der Kette (Startparameter) anfordert, aber dass nMinimumChainWork schon immer als Check genutzt wird - also auch als Checkpoint gesehen werden sollte.
Das ist Sache der Client-Entwickler. Ethereum ist in diesem Punkt ja dezentral im Vergleich zu Bitcoin (Client-Diversity). Je nach dem, welche Sync-Methoden Clients implementieren (Snap-Sync und so weiter) gibt es schon Checkpoints auf die man sich in manchen Clients geeinigt hat. Es muss also überhaupt kein Checkpoint vorhanden sein, ich glaube aber (ohne dass ich das überprüft habe) jeder Client implementiert Checkpoints.
2 „Gefällt mir“
Sehr gut, dann kommen keine unqualifizierten Querschüsse mehr von dir und ich kann meinen Gedanken zu einem interessanten Punkt des Threadersteller darlegen.
Die von Roman in einem Video vorgebrachte Idee, dass eine KI eine gefälschte Blockchain erstellen könnte, die dann von Nodes heruntergeladen wird, ist ein überaus interessanter Gedanke. Bei Bitcoin hat man die Möglichkeit die Hashes nachzurechnen und kann ziemlich sicher sein (wenn auch nicht mathematisch 100%ig), dass man die originale BC hat. Bei den POS chains ist das nicht der Fall.
Ist das nun ein Risiko und ein Argument dafür, dass nur Bitcoin wirklich trustless ist? Hier kann man sicher geteilter Meinung sein, je nachdem wie man Risiko für sich selbst einordnet. Für mich ist es kein Grund, einer POS chain die Sicherheit abzusprechen. Warum?
-
Ich betreibe ja selbst eine Lightning node. Warum bin ich überzeugt, dass sie richtig funktioniert und kein fake ist? Weil sie funktioniert! Nicht weil ich händisch irgendwelche Hashes nachgerechnet habe. Die Prüfung der Hashes erfolgt durch die heruntergeladene Software selbst. Nicht durch mich. Wenn ich eine fake BC bekommen hätte, dann auch eine manipulierte node-Software, die mir vorgaukelt, alle Hashes sind okay. Ich kenne auch wirklich niemanden, der nach dem ersten Sync mittels Zweitsoftware den BTC Ledger auf seiner node kontrolliert hat. Ja, es wäre möglich, aber es macht einfach niemand. Trotzdem sind wir node Betreiber alle sicher, dass wir auf der richtigen chain unterwegs sind. Die Transaktionen sind identisch, die eigenen Balances stimmen, der offizielle mempool explorer ist gleich zu unserem. All das sind für uns die Gründe, warum wir von der Authentizität überzeugt sind. Wir rechnen keine Hashes von neuen Blöcken nach. Wir verlassen uns darauf, dass unsere node nicht über Nacht gehackt wurde. Neue Lightning Transaktionen, neue Bitcoin Transaktionen, etc. Alles läuft problemlos. Beweis durch Funktionalität.
-
Mit dem Beispiel meiner BTC node vom vorigen Punkt ist auch gleich gesagt, warum ich mir sicher sein kann, dass auch die heruntergeladene POS chain die Richtige sein würde.
Wäre sie fake, dann würden meine Balances nicht stimmen, keine Transaktionen akzeptiert werden, ich würde gar nicht am Netzwerk teilnehmen. Nichts wäre in Synchronisation. Gar nichts. Ich brauche wie oben beschrieben keine Hashes nachrechenen (lassen), der Betrug wäre vollkommen offensichtlich. Nichts würde funktionieren. Als würde ich den chrome browser runterladen und es öffnet sich dann MS Word. Keine Kontrolle des Codes notwendig, es ist offensichtlich die falsche Software.
Die Gefahr einer manipulierten Blockchain aufzusetzen ist zwar größer 0%, aber so verschwindend klein, wie bei meiner Bitcoin node.
Insofern sehe ich hier keinen Sicherheitsnachteil bei nicht POW chains, bezüglich des von Roman geschilderten Szenarios.
1 „Gefällt mir“
Beweis durch Funktionalität.
Den hast du auch bei der Bank, bei Paypal usw.
Da funktioniert auch alles.
der Betrug wäre vollkommen offensichtlich.
Und bei wem würdest du dich dann beschweren? Bei der Ethereum Foundation?
Es ist egal ob der Betrug offensichtlich ist, wenn dein Geld weg ist.
Wenn einer deine private keys klaut ist der Betrug auch offensichtlich, die coins sind weg.
Nutzt einem aber nix. Man muss den Betrug verhindern, ihn zu sehen nachdem er passiert ist bringt nix.