Liebe und Leid der Archive Nodes
Matthias, genannt „Ghostie“, kennt sich mit Full Nodes aus. Auch mit denen, die Festplatte, CPU und Arbeitsspeicher quälen. In einem Gastbeitrag erzählt er von seinen Erfahrungen.
Von Ghostie
Der Betrieb eines Archive Nodes für Blockchains wie Ethereum oder Polyon ist aufwändig und teuer. Es ist mehr oder weniger die Königsklasse beim Aufsetzen von Nodes. Der Node braucht gute Hardware, Wartung (gutes Monitoring) und auch Zeit – zumindest immer dann, wenn das Monitoring anspringt oder ein neues Release ansteht. Das nimmt man in der Regel nur in Kauf, wenn man einen Grund dafür hat.
Ein Archive Node ist mehr als ein Full Node. Ein Full Node speichert „nur“ die gesamte Blockchain, während ein Archive Node zusätzlich jeden Zustand speichert, den jeder Smart Contract und jede Transaktion jemals (d.h. auf jeder Blockhöhe) hatte. Aus den Daten eines Full Nodes können jedoch die zusätzlichen Daten eines Archive Nodes rekonstruiert werden.
Da dies auf Twitter, bzw. X und auch in Online-Foren immer wieder zu Diskussionen führt, bringe ich gerne eine Analogie zu Bitcoin: Ein Archive-Node für Ethereum wäre für Bitcoin ein Node, der zu jeder Blockhöhe das auf dieser Blockhöhe gültige UTXO-Set speichert. Das ist natürlich kein besonders interessanter Anwendungsfall für Bitcoin, weil diese Daten (a) bei Bitcoin viel schneller rekonstruiert werden können und (b) auch keinen besonderen Informationsgehalt haben. Bei Ethereum ist das anders, weil es dort Smart Contracts gibt und die Speicherung der Zwischenzustände hier bedeutet, dass man z.B. direkt abfragen kann, wie viel USDT welcher Account zu welchem Zeitpunkt (also auf welcher Blockhöhe) hatte.
Meinen ersten Archive Node für das Ethereum Ökosystem habe ich 2019 synchronisiert. Damals aus reiner Neugier: Ich hatte für ein Projekt viel Server-Hardware (96 Cores, 768 GiB RAM, über 40 TiB SSD-Speicher) gekauft und wollte diese ausreizen. Also habe ich einen Archive Node für Ethereum mit geth synchronisiert, was ziemlich genau 7 Tage und 22 Stunden gedauert hat. Ich weiß das heute noch so genau, weil ich das Thema auf coinforum.de diskutiert und meinen Fortschritt dokumentiert habe.
Langfristig braucht es aber bessere Gründe. Das ist ein großer Unterschied zwischen Ethereum und Bitcoin. Bitcoiner synchronisieren die gesamte Blockchain aus Idealismus. Bei Ethereum nutzen die meisten Nutzer Knotenanbieter wie Infura oder Alchemy. Diese erlauben ca. 100.000 kostenlose API-Aufrufe, was für kleinere Projekte und Wallets mehr als ausreichend ist.
Wann und für wen ist ein Archive Node sinnvoll?
Kritisch wird es aber, wenn man Blockchain-Analysen durchführen will oder muss. Will man beispielsweise wissen, welche Accounts wann welche Guthaben eines Tokens auf Ethereum hatten, muss man durch blockweises Scannen der Blockchain alle Adressen herausfinden und dann für jede ERC20-Transaktion die historischen Guthaben abfragen. Das übersteigt selbst in einfachen Fällen die kostenlosen API-Aufrufe von Alchemy und Infura und wird schnell teuer. In solchen Fällen lohnt sich ein Archive Node, da allein das Scannen durch alle Blöcke zu so vielen API-Aufrufen führt, wie es aktuell Blöcke in der Blockchain gibt. Und Ethereum hat derzeit über 20 Millionen Blöcke.
Ich betreibe solche Knoten mittlerweile für Kunden. Die Gründe sind manchmal absurd. Eine Firma bietet zum Beispiel Hilfe bei der Erfüllung von EU-Vorschriften an. Diese verlangen, dass man für jedes Crypto-Asset den CO2-Verbrauch nachweisen muss. Wenn man nun einen Token auf Ethereum hat, muss man sämtliche vergangenen Transaktionen und Swaps zurückverfolgen, um zu berechnen, wie viel Gas der Token verbraucht hat. Das Gas entspricht der benötigten Rechenleistung und ist somit ein Indikator für den CO2-Verbrauch.
Das ist natürlich haarsträubend. Als Proof-of-Stake-Blockchain verbraucht Ethereum ohnehin sehr wenig Energie, und die Synchronisation eines Archive Nodes verursacht wahrscheinlich viel mehr CO2, als man durch die Regulierung jemals einsparen könnte (wenn überhaupt). Aber es ist nicht meine Aufgabe, solche Fragen zu stellen, sondern Nodes aufzusetzen.
Welche Ressourcen werden für den Betrieb eines Ethereum-Archive-Nodes benötigt?
Die Unterschiede zwischen den Nodes und Clienten sind teilweise enorm. Ich habe Erfahrung mit Ethereum, Polygon und Solana.
Ethereum benötigt mit dem Client Nethermind etwa 15 Terabyte Festplattenspeicher für die Daten des Execution-Layers, 8 CPU-Kerne (besser 16 für die Synchronisation) und 128 Gigabyte RAM. Ein alternativer Client ist Erigon, der mit nur drei Terabyte Daten auskommt. Erigon speichert die Daten im Vergleich zu Nethermind mit einem anderen Datenbankmodell, das neben einer sehr flachen Architektur nur Deltas zwischen einigen Blöcken speichert. Dies hat allerdings zur Folge, dass historische Abfragen in manchen Fällen etwas länger dauern können, aber auch viel Platz gespart wird.
Für einen Server ist der Bedarf überschaubar. Wenn man einmal synchronisiert hat, braucht man weniger. Die größte Herausforderung sind die Festplatten, oder besser gesagt die SSDs. Um das zu verstehen, muss man wissen, wie Smart Contracts mit der Ethereum Virtual Machine (EVM) funktionieren. Ich will euch damit nicht langweilen, also nur so viel: Jeder Smart Contract hat seinen eigenen virtuellen Speicherbereich, der je nach Account einen anderen Teil davon nachladen muss. Das führt ständig (mit jedem neuen Block) zu vielen Lese- und während der Synchronisation auch Schreiboperationen (I/O).
Deshalb sind klassische Festplatten (HDDs) nicht mehr zeitgemäß, man braucht SSDs. Wer Nethermind nutzt, muss mehrere zusammenschalten, um die mindestens 15 Terabyte zu speichern. Wenn man das mit AWS macht, kostet das schnell einen vierstelligen Betrag. Mit Erigon kann man im Prinzip auch einen Archive Node auf einem leistungsfähigen PC synchronisieren.
Polygon und Solana
Dabei ist Ethereum noch relativ ressourcenschonend! Andere EVM-kompatible Blockchains wie Polygon oder auch nicht-EVM-kompatible wie Solana haben die gleichen oder sehr ähnliche Probleme: Um sich zu synchronisieren, muss Zustand für Zustand berechnet und gespeichert werden, und jede Abfrage eines Smart Contracts erfordert extrem viele I/O-Operationen.
Man kann sich vorstellen, was passiert, wenn man wie bei Polygon die Blockzeiten verkürzt: Man braucht noch bessere Festplatten, um die Anfragen zu verarbeiten. Bei Ethereum reichen 6.000 IOPS, bei Polygon sind es schon 20.000 IOPS, die für die Synchronisation mit Erigon empfohlen werden. Das treibt die Kosten bei AWS weiter in die Höhe, ich schätze, wir sind jetzt schon bei 8.000 Euro im Monat, wenn wir uns an die Systemanforderungen für einen Archive Node halten.
Als Client für den Polygon Archive Node wird in der Regel Erigon verwendet. Während Erigon bei Ethereum nur 3 Terabyte Speicher benötigt, sind es bei Polygon bereits 10 Terabyte. Dabei ist Polygon wesentlich jünger als Ethereum. Man kann sich also schon ausrechnen, wie der Ressourcenverbrauch in Zukunft aussehen wird und wie viel Speicher ein Polygon Archive Node hypothetisch mit einem anderen Client benötigen würde.
Solana ist noch extremer. Dafür habe ich einmal zwei Nodes betrieben, für Mainnet und Testnet, um am Solana Grant teilzunehmen. Das waren aber keine Archivknoten, sondern nur Validatoren. Schon für die braucht man eine CPU mit mindestens 12 Kernen und für das Testnet mindestens 128 GiB RAM, für das Mainnet sogar mindestens 256 GiB RAM (zum besseren Vergleich: Mindestens einer der Solana-Ausfälle wurde dadurch verursacht, dass zu viele der Validatoren „nur“ 128 GiB RAM hatten). Auch die Netzwerkanbindung sollte gut sein, laut Systemanforderungen mindestens 1 Gbit/s synchron (zwei Validatoren verursachen eine konstante Auslastung von 300 Mbit/s), mit einem Trafficvolumen von knappen 100 TiB pro Monat pro Validator. Das hat man in Deutschland an den wenigsten Orten.
Ein normaler Solana Node benötigt bereits 2 Terabyte, ein Archive Node laut Internet ca. 100 Terabyte. Die Kosten sind bereits enorm.
Kann das langfristig gut gehen?
Es gibt Zweifel, ob das auf Dauer gut gehen kann. Ich persönlich glaube schon, ich glaube an den technischen Fortschritt. Ein Beispiel verdeutlicht das: Als ich 2019 meinen Geth-Node synchronisiert habe, hat das gut eine Woche gedauert. Heute dauert es mit leistungsfähigerer Hardware kaum länger, obwohl die Blockchain viel größer geworden ist. Das liegt nicht nur an besserer Hardware, sondern auch an besseren Algorithmen, die zum Beispiel bei Nethermind mit der Version 1.26 zu einer 30 bis 50 Prozent schnelleren Blockverarbeitung geführt haben.
Hard- und Software werden immer leistungsfähiger, was sich besonders bei Servern zeigt. Aber schon heute genügt es, hypothetisch 250.000 Euro zu investieren, um einen Archive Node für Solana für die nächsten zehn Jahre betreiben zu können. Solange es einen Grund und ein Geschäftsmodell gibt, wird es auch jemand machen. Deshalb mache ich mir keine Sorgen, dass es irgendwann keine Archive Nodes mehr geben wird.
Es reicht jedoch nicht aus, einfach mehr Geld in Hardware zu investieren, um zu skalieren. Sobald eine Blockchain weit verbreitet ist, stößt sie von selbst an Grenzen der Skalierbarkeit. Ohne viele Accounts erreichen viele Projekte in synthetischen Benchmarks leicht eine fünf- oder sogar sechsstellige Anzahl von Transaktionen pro Sekunde. Dies liegt daran, dass Accounts und aktuelle Zustände leicht in den CPU-Cache passen und Benchmarks aus Marketinggründen oft optimal parallelisierbar aufgebaut sind.
Aber sobald man mehr Nutzer hat, wie bei Bitcoin, wird es eng. Selbst hier wird es bei nur 7 Transaktionen pro Sekunde schon bei 4 Gigabyte Arbeitsspeicher kritisch, weil das UTXO-Set so groß ist. Und dieses – bzw. der Zustand (State) – ist bei anderen Blockchains noch viel größer und komplexer. Deshalb sollte man den Versprechungen der Blockchain-Entwickler aus dem Labor nicht glauben. In der Praxis wird es immer schwieriger.
Darüber hinaus gibt es eine natürliche Barriere, die Latenzzeit. Der Datenverkehr benötigt eine bestimmte Zeit, um von einem Knoten zum anderen zu gelangen. Es gibt eine physikalische Barriere, die durch die Lichtgeschwindigkeit definiert ist. Ein Forschungspapier (Information Propagation in the Bitcoin Network) kam zu dem Schluss, dass ein Blockintervall von mindestens 12,6 Sekunden erforderlich ist, damit sich ein Block zu den meisten Knoten auf der Welt ausbreiten kann. Daraus leitet sich bis heute das Blockintervall von Ethereum ab. Modernere Blockchains wie Solana haben deutlich kürzere Intervalle, weshalb sich die Nodes bereits in Europa und den USA sowie in Rechenzentren konzentrieren.
Damit sind wir wieder bei der alten Frage der Dezentralität und Skalierbarkeit. Wenn ich nur wenige Nodes habe, die alle nahe beieinander liegen, kann ich gut skalieren. Aber man muss kein Bitcoin-Maximalist sein, um sich zu wünschen, dass Full und Archive Nodes über die ganze Welt verteilt sein können.
Und keiner weiß davon…
Kürzlich habe ich wieder einen Ethereum (Nethermind) und einen Polygon (Erigon) Archive Node synchronisiert. Beide Clients hatten einen Bug, der die Synchronisation als Archive Node verhinderte. Während sich bei Nethermind durch die oben erwähnte Optimierung ein Bug eingeschlichen hatte, der nach einer kurzen Entschuldigung („ja, wir optimieren nicht für den Betrieb als Archive Node“) auch behoben wurde, bleibt der Bug bei Erigon offen, obwohl seit 3 Wochen ein Entwickler zugeordnet ist. Scheint wohl nicht so wichtig zu sein.
Die Bugs wurden durch Upgrades verursacht, die die Blockverarbeitung verändert haben. Man bemerkt sie nicht, wenn ein Archive Node läuft, und man bemerkt sie nicht, wenn man einen normalen Node synchronisiert. Erst wenn man sich die Mühe macht, einen Archive Node neu zu synchronisieren, merkt man es, je nach Server auch erst nach Wochen.
Die Tatsache, dass die Bugs in beiden Fällen bereits seit Wochen bestanden, zeigt, wie selten es vorkommt, dass jemand einen Archive Node neu synchronisiert. Dies hat zur Folge, dass solche Fehler lange Zeit unbemerkt bleiben und es in Zukunft zu einer Situation kommen kann, in der die Software die Synchronisation neuer Archive Nodes unmöglich macht und niemand davon weiß – weil es so selten vorkommt, dass ein neuer Archive Node erstellt wird.
In meinem Fall hat es gut funktioniert. Ich habe den Fehler an Nethermind gemeldet und den Entwicklern geholfen, ihn zu beheben. Bei Erigon war der Fehler schon bekannt, wurde aber für eine spätere Version gemeldet, als er bei mir auftrat. Hier benutze ich jetzt einfach eine ältere Version – bei Polygon ist das nicht so schlimm. Aber wenn sich so ein Bug tiefer eingräbt, weil die Archive Nodes noch seltener synchronisiert werden und das CI/CD der Node-Entwickler nicht verbessert wird, kann es sein, dass er nicht mehr so einfach zu beheben ist.
Es bleibt also möglich – aber eine Herausforderung, die im Lauf der Zeit nicht kleiner werden wird.
Entdecke mehr von BitcoinBlog.de - das Blog für Bitcoin und andere virtuelle Währungen
Melde dich für ein Abonnement an, um die neuesten Beiträge per E-Mail zu erhalten.
Vielen Dank für die interessanten Einblicke!
Stimme voll und ganz zu, andererseits sollte man den Bitcoin Entwicklern nicht glauben, 1MB sei der heilige Gral. Für eine private Node muss man auch nicht alle UTXO im Ram vorhalten, allenfalls wenn man 0-conf Tx als Merchant annehmen will.
Auch wenn ich vom technischen Fortschritt überzeugt bin (mein erster Rechner nach dem C-64 hatte eine 1,6GB HDD und 8MB Ram), halte ich heute 100TB-Nodes wie bei Polygon für utopisch und extrem zentralisierend.
Nach den Black Marble Angriffen hat man sich bei Monero auch entschlossen, neben dem Main-, Stage- und Testnet auch ein Stressnet zu starten, wo man testen kann, wie Nodes mit großen Tx-Pools und großen Blöcken umgehen:
https://monitor.stressnet.net/
Dort kann man schön erkennen, wie sich die dynamische Blocksize und die dynamischen Fees auf die Blöcke und das Mining auswirken.
Es ging ja hier auch um Archive Nodes, sowas muss man nicht unbedingt als Privatperson aufsetzen.
Sicher, dass Deine erste HDD 1.6 GB war? Das würde mich erstaunen. Ich fand die 20MB, und die 40MB, für die ich mich entschied, damals schon sehr teuer. 😉 Obwohl, wenn Du von dem RAM sprichst, war das wohl doch erst später :-).
100 TB sehe ich nicht als utopisch an, für Firmen. Der Grad der Zentralisierung und dessen Beurteilung ist eine Frage der jeweiligen Philosophie. Für Monero wäre es möglicherweise der falsche Weg. Für viele technische Lösungen reicht eine gewisse Verteilung aus.
Lieber Wolfgang, kann sein, dass eine HDD davor noch unter 1GB hatte, aber 8MB Ram waren es auf jeden Fall beim „Umstieg“ vom C-64.
Disclaimer: Ich bin DataHoarder.
Mich machen 100TB auch nicht schwach, ich halte deutlich mehr als das als Privatperson. Aber ich kenne in meinem Bekanntenkreis niemanden, der das auch tut. Bei solchen Datenmengen stellt sich irgendwann die Frage, wie man sie optimieren kann und was weg kann… Mache ich mehr oder weniger regelmäßig, da unendliche Erweiterungen zwar möglich sind, aber ins Geld gehen.
Wenn ich aber von einer Blockchain wie Polygon höre, deren Node heute >100TB benötigt und sie nicht irgendwie als wahnsinnig populär erachte, dann ist es etwas anderes, denn wenn sie populär wäre, wären wir im PB Bereich und das ist selbst für mittelständische Unternehmen kaum handelbar. Wenn wir uns jetzt damit abfinden, dass die Blockchain von einer Hand voll (oder auch nur einem) vollständig gehalten wird, wozu dann Blockchain? Es gibt etliche skalierbare Datenbankmodelle mit Master/Slave konfigurationen, die man auf Milliarden Tx skalieren kann.
Danke für die Antwort. Ich habe das vielleicht missverstanden und auch nicht genauer nachgeschaut. Ich las im Text 10TB, und dachte, dass dann ein 10X nicht so dramatisch wären. Das Argument mit der Popularität hat viel Gewicht. Mein Respekt vor großen Datenmengen hat sich etwas reduziert, seit dem ich mir bewusst geworden bin über die Mengen großer Anbieter wie YouTube, AWS etc.
Skalierbare Datenbanken sind immer unter Kontrolle einer Entität/Firma. Das ist (für mich) einer der wichtigen Punkte. Und es gibt viele Anwendungsfälle, wo eine solche Datenbank ausreicht.
Vielen Dank! Schöner Beitrag, interessant, gerne mehr davon! Danke auch für die Zahlen.
Das nutze ich als Anregung für einige Bemerkungen, die aber nicht direkt mit diesem Projekt zu tun haben:
1.
Bei Ethereum ist das anders, weil es dort Smart Contracts gibt und die Speicherung der Zwischenzustände hier bedeutet, dass man z.B. direkt abfragen kann, wie viel USDT welcher Account zu welchem Zeitpunkt (also auf welcher Blockhöhe) hatte.
Auch bei Bitcoinumsetzungen hat man „Smart“ Contracts. Bei BTC sind sie idR klein, Beschränkung durch Blockgröße. Bei BCH ist das schon anders, bei BSV ohnehin, mit max ScriptSize derzeit 500kB, den meisten originalen OP Codes restauriert. Der Unterschied liegt aber doch vielleicht eher darin, dass man bei EVM basierten Ansätzen ein accountbasiertes Modell verwendet, bei dem bei Veränderungen am Zustand dieser durch Berechnung abgesichert werden muss, während man bei tokenbasierten Ansätzen das Token hinzufügt, oder wegnimmt, und dies keinen Einfluss auf den Zustand hat, der durch den Rest der Token des „Account“ gebildet wird. Eigene Speicherbereiche braucht der SmartContract nicht. Abhängigkeiten entstehen nur durch verkettete Transaktionen.
Mich erinnert der Unterschied an den, den es zwischen imperativer und funktionaler Programmierung gibt (ja, hinkt).
Synchron halten heißt, gleiche Transaktionen in gleicher Reihenfolge in Blöcken bei allen Blockerzeugern zu erreichen. Das kann man bei Bitcoin im Prinzip gut. Die UTXO Menge neu aufzubauen, könnte (bei großen Blöcken) auch schon mal aufwendiger werden, wenn die dann alle noch validiert werden sollten.
2.
Sobald eine Blockchain weit verbreitet ist, stößt sie von selbst an Grenzen der Skalierbarkeit.
„Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling.“ (Satoshi an Mike Hearn [1]). Keiner sagt, dass das einfach ist. Viele 1000 TPS lassen sich prinzipiell auch jetzt schon erreichen (bis zu bestimmten Zahl bei BCH, viel weiter aber in der BSV Variante). Die Verwaltung der UTXO Menge ist ein Problem, aber auch da ist man z.B. (im Labor) bei BSV in Zusammenarbeit mit Aerospike (Datenbank für genau die UTXO) schon recht weit (1M TPS). Ob man es tatsächlich bis in die Praxis schafft, wird man sehen (Ja, in der Praxis ist es immer schwieriger 🙂 ).
Kurze Blockintervalle sind (für Bitcoin) nicht notwendig. Selbst, wenn die Verbreitung eine Minute dauert, oder zwei. Mit IPv6 gibt es außerdem Broadcast, da kann man allen Minern den jeweils neuen Blockheader sofort zuspielen.
[1] https://bitcointalk.org/index.php?topic=149668.msg1596879#msg1596879
Ich bin ziemlich bei Dir, aber nicht bis ins letzte Detail 😛
Je größer die Blöcke werden, desto wahrscheinlicher ist es, dass die eigene Node nicht alle Tx im eigenen Mempool hat und man kann dann nicht mehr z.B. auf hashed Trees zurückgreifen, sondern muss dem Broadcaster vertrauen und blind auf dessen (neuen) Block aufbauen, was nur über Whitelists möglich wäre und die Dezentralisierung weiter degradiert. Eigentlich kann man bis zur vollständigen Synchronisierung und Verifizierung auch nur einen leeren Block auf diesem minen, denn sonst läuft man Gefahr, eine Transaktion, die bereits bestätigt ist noch einmal aufzunehmen, was einen ungültigen Block verursachen würde. „Zum Glück“ ist das Bitcoin Mining auf wenige Pools zentralisiert und man braucht der durchschnittlichen Node seine Blöcke nicht propagieren [sic!].
Ich bin ein Verfechter der höchst möglichen Dezentralisierung und nehme dafür ggf. auch lieber „Uncle Blocks“ in Kauf, wenn diese zwischenzeitlich aufkommen und den PoW geleistet haben anstatt einen Anreiz für leere Blöcke zu geben. Der Königsstandard in der Dezentralisierung des Minings ist weiterhin p2pool, auch wenn er bei Monero weiterhin etwas unter 10% bleibt… Ich bin mir ziemlich sicher, dass wir langfristig eine Mehrheit bekommen werden, genauso wie beim Flippening des Anteils von Monero als Payment 😉
Man muss meiner Meinung nach im Bigblockansatz nicht sofort mit dem Mining beginnen. Das Ziel wäre ja, soviel wie möglich Transaktionen aufzusammeln, weil darüber der Profit gemacht würde. Zu frühes Finden eines Blockes wäre kontraproduktiv, wegen entfallener Transaktionsgebühren und weil ggf ein Beitrag geleistet würde, dass die Difficulty steigt. Es gibt mMn den Anreiz, so spät wie möglich, aber dennoch rechtzeitig mit dem PoW Hashen zu beginnen.
Wir werden sehen. Ich habe kein Problem damit, wenn sich meine Sichtweise in Zukunft als falsch erweist :-).
Ein rationaler Miner wird in der Tat erst anfangen zu minen, wenn es sich statistisch für ihn lohnt, das habe ich schon oft beschrieben und Bitcoin wilde Volatilität der Hashrate vorausgesagt, dazu stehe ich nach wie vor. Auch die Min-Fee dürfte sich dann derart einpendeln, denn wenn mich die Propagierung ins Netzwerk X Millisekunden mehr kostet, wenn ich eine zusätzliche Transaktion hinzufüge, kann ich ermitteln, wie hoch mein statistischer Verlust über etliche Blöcke ist, wenn ich solche Transaktionen hinzufüge und es wird sich ein Floor Preis bilden.
Aktuell machen die Coinbase Rewards einen Löwenanteil aus, aber in 2-3 Halvings dürfte es gerade in die Richtung gehen…
Hey Wolfgang,
ich habe zu Deinen Bemerkungen ebenfalls Bemerkungen. 😀
1. UTXO und account based model.
Das UTXO-Modell ist nur abbildbar, wenn das zugrundeliegende System entweder „native coins“ unterstützt oder mit dem System-Token selbst (der ja praktisch auch sowas wie ein native coin ist). Ethereum kann das also mit seinem Konzept leider nicht abbilden.
Bitcoin-Script ist so rudimentär, dass es damit nicht möglich ist einen eigenen Token, welcher eigenen Speicher braucht abzubilden. Das geht nur mit externer Software, welche die Blockchain dann wie eine Archive-Node scannen muss und unabhängig vom Modell (UTXO/account based) „ungefähr“ den gleichen Aufwand hat. (Siehe z.B. ord für Ordinals/Inscriptions auf Bitcoin.)
Übrigens: Um schnell an historische Balances zu kommen müssen bei beiden Modellen Indizes aufgebaut werden.
Und: Blockgrößenbegrenzung oder Blockspeicher ist übrigens idr. kein Problem. Bei Bitcoin siehst Du das ja daran, dass eine einzelne Inscription bis zu 4 MB groß sein kann dank native segwit und taproot und Ordinals mittlerweile ja auch multipart sein können, also auf mehrere Blöcke verteilt werden können.
2. IPv4 Broadcast und IPv6 Multicast
Wie man an der Überschrift sieht gibt es Broadcast ja auch schon bei IPv4. Beides hat aber Nachteile, denn beides ist „im Internet“ (also WAN-Netzen) idr. deaktiviert, weil es eben auch missbraucht werden kann (z.B. für DDOS-Attacken) um viel Traffic für viele Hosts zu erzeugen.
Danke.
Ich finde es auch einen sehr interessanten und wertvollen Beitrag.
Mehr muss man eigentlich nicht wissen, um zu verstehen, dass das Tuning der L1-Blockchain keine Zukunft hat und dass verschiedene Schichten notwendig sind, um zu skalieren.
Solana-Validatoren werden immer mehr zusammenrücken, um die Latenzzeit zu verringern und am Ende eine Einheit oder sogar ein gemeinsames Unternehmen sein, – damit fällt der Aspekt „Dezentralisierung“ für die Blockchain weg.
Es war schon die gleiche Diskussion bei der Blockgröße von Bitcoin und die Geschichte hat gezeigt, dass Dezentralisierung bei den Benutzern einen hohen Stellenwert hat.
(Offtopic)
Das ist eben eine Ansichtssache :-).
Als (untypischer?) Nutzer interessiert mich der Grad der Dezentralisierung kaum. Es reicht, wenn es sich einander kontrollierende Knoten gibt, kein Single Point of Failure, und ich dafür einen guten Service bekomme – was in meinem Fall schnelle und günstige Transaktionen sind, andere legen Wert auf andere Eigenschaften.
Ich finde es spannend zu sehen, wie weit man kommt.
„The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms.“ https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
😉
> Es war schon die gleiche Diskussion bei der Blockgröße von Bitcoin und die Geschichte hat gezeigt, dass Dezentralisierung bei den Benutzern einen hohen Stellenwert hat.
Die Geschichte hat gezeigt, dass sich die eine Seite lieber der Zensur bedient, anstatt sich einer Diskussion zu stellen bzw. diese zu zu lassen.
Recherchier mal ein bisschen ueber „Theymos“.
Die Ironie an der Sache ist, dass sich das BTC Lager fuer zensurresistenz stark macht.
Und bei Nutzern hat auch teilweise das einen hohen Stellenwert, was durch Medien, Propaganda und social engineering gepusht wird.