Zum besseren Verständnis sollte zuerst das Kapital "Bitcoin Blockchain" gelesen werden. Speicherkapazität und Datendurchlauf sind bei der Bitcoin Blockchain schrecklich, wird mit herkömmlichen Datenbanken wie denjenigen von Facebook, Google, Amazon, VISA oder Netflix verglichen. Jede Full Node (Knoten) speichert sämtliche Daten der Blockchain, die bereits 85 GB gross ist. Neue Knoten brauchen über einen Tag, um eine Kopie anzulegen. Bitcoin stösst an seine Kapazitätsgrenze. Da die Blockgrösse bei 1 MB limitiert ist, steigen die Gebühren solange an, bis die Nachfrage sinkt. Im Moment kann Bitcoin betreffend Gebühren zwar noch locker mit VISA oder Mastercard mithalten. Jedoch geht der Trend in die falsche Richtung und die Bitcoin Blockchain ist nur für hochwertige Daten, wie Bitcoins, geeignet. SkalierbarkeitEs gibt zwei Lager mit unterschiedlichen Auffassungen. Die einen Bitcoin Entwickler meinen, dass die Blockgrösse angepasst werden sollte, um die Kapazität zu erhöhen und die Gebühren zu senken. Damit würde die Bitcoin Blockchain aber umso schneller aufgebläht, womit immer weniger Knoten sich als Miner an der Sicherung beteiligen könnten. Der Konzentrationsprozess würde sich beschleunigen. Das andere Lager ist daher der Meinung, dass die Blockgrösse prinzipiell unangetastet bleiben soll. Über technologischen Fortschritt soll das Bitcoin Ökosystem effizienter gemacht werden. Light Clients laden nur einen Teil der Blockchain herunter. Über einen Software Upgrade (SegWit) soll ausserdem die Verifizierung der Transaktionen ausserhalb der Blockchain erfolgen, womit die Blöcke entlastet würden. Dies gleicht aber eher einem Flickwerk. Skalierbarkeit wird weiterhin ein Hauptproblem von Bitcoin, aber auch von Ethereum bleiben. Einen schönen Überblick über diese Debatte gibt es hier. BigchainDB wählt daher einen anderen Weg: Ausgangspunkt sind herkömmliche dezentrale Datenbanken, die um die Vorteile der Blockchain (keine mächtige Mittlerinstitution, nicht manipulierbar und Token System) erweitert werden. Die bestehenden Datenbanken können ca. 1 Mio. Transaktionen pro Sekunde (TPS) ausführen und die Speicherkapazität beträgt etwa 1’000’000 GB, was dem 10’000-fachen der Bitcoin Blockchain entspricht. Damit können ganze Dokumente anstelle des Fingerabdrucks (Hash) gespeichert werden. 1 Mio. TPS entspricht dem theoretischen Wert der Experimente mit der BitShares oder HEAT Blockchain. Ein weiteres Indiz, dass dies in ein paar Jahren möglich ist. Das Settlement bzw. die Abwicklung von Transaktionen könnte dann wenige Sekunden in Anspruch nehmen – verglichen mit Tagen beim heutigen Bankensystem und 10-60 Minuten bei Bitcoin. Herkömmliche Datenbanken speichern pro Knoten nur einen Bruchteil der Daten. Im Endeffekt braucht es nur wenige Kopien. Moderne Datenbanken wie Cassandra von Netflix speichern 3 davon. Falls ein Server aussteigt, kann sofort eine neue Kopie angelegt werden. Dass drei Kopien gleichzeitig verloren gehen, ist praktisch unmöglich. Steigt die Anzahl Knoten können mehr Daten gespeichert werden, womit das System skalierbar ist. Bei Bitcoin beteiligen sich ca. 10’000 Knoten als Full Node. Es gibt damit auch 10’000 vollständige Kopien der Blockchain. Damit fallen im Durchschnitt alle 5’000 Mrd. Jahren sämtliche Kopien aus. Dies ist doch etwas zu grosszügig und macht das System langsam. Bei BigchainDB beteiligen sich nur eine begrenzte vorbestimmte Anzahl Knoten an der Sicherung. Zu Beginn werden es 5 Institutionen sein, die hauptsächlich nicht gewinnorientiert arbeiten und am Aufbau eines dezentralen, demokratischen Internets interessiert sind. Diese föderierten Knoten stimmen über Transaktionen ab. Sofern eine Mehrheit der Föderationsmitglieder eine Transaktion als gültig ansieht, wird sie in der Blockchain verewigt. Entscheidend ist, dass die Föderation aus unabhängigen Mitgliedern besteht. Dabei soll über Gerichtsbarkeit, Regionen, Webhoster (Amazon, Rackspace etc.), Programmiersprachen (Python, Go etc.) und Betriebssysteme (Microsoft, Linux etc.) hinweg diversifiziert werden. Bei der BigchainDB gibt es zwei Datenbanken (siehe Grafik unten). Im Backlog werden einkommende Transaktionen ungeordnet gespeichert. Dann werden sie verifiziert und – falls fehlerfrei - der Blockchain zugefügt. Im Unterschied zu Bitcoin arbeiten alle Knoten an derselben Blockchain. Eine Gabelung (Fork) wie bei herkömmlichen Blockchains ist nicht möglich und die Wahrscheinlichkeit der doppelten Ausgabe von Tokens ist sehr gering. Trotzdem werden Blöcke weiterhin verwendet. Hauptgrund ist, dass in der Datenbank für jedes Föderationsmitglied nur ein Haken (positiv/negativ) und eine digitale Unterschrift pro 1’000 Transaktionen bzw. Block gespeichert werden muss. Jedes Föderationsmitglied kontrolliert nun die Blöcke. Sofern eine Transaktion fehlerhaft ist oder Output von einem Block ist, der noch nicht abgeschlossen wurde, wird sie wieder in den Backlog zurückgeschoben. Der fehlerhafte Block bleibt jedoch bestehen, da sowieso genügend Speicher zu Verfügung steht und die Löschung der Daten nur Zeit kosten würde. Blöcke werden selbst dann verifiziert, falls eine Mehrheit bereits entschieden hat. Es ist nämlich zeitlich effizienter, zu kontrollieren, statt nachzuforschen, ob eine Verifizierung überhaupt noch nötig ist. Bei der BigchainDB können mehrere Token parallel in derselben Blockchain nachgeführt werden. Colored Coins sind überflüssig. Sämtliche Token werden auf doppelte Ausgabe überprüft und die Transaktions-Gebühren können in derselben Kryptowährung bezahlt werden. BigchainDB baut auf herkömmlichen Datenbanken auf. In der engeren Auswahl standen Cassandra, HBase, Redis, Riak, MongoDB, RethinkDB und ElasticSearch. Alle diese Datenbanken brauchen den Paxos Algorithmus bzw. dessen Abwandlung Raft. Kriterien waren Zuverlässigkeit der Blockanordnung und automatische, schnelle Benachrichtigung von Änderungen der Blockchain. RethinkDB erfüllt die Kriterien am besten. SpeicherkapazitätFalls alle Föderationsmitglieder auf Amazon Web Services laufen würden, könnten 48’000 GB Speicher pro Knoten zur Verfügung stehen. Bei 25 Mitgliedern käme man schon auf über 1 Petabyte (1’000’000 Mrd. GB). Falls 3 Kopien der Blockchain in der dezentralen Datenbank gespeichert werden, entspricht dies 1/3 Petabyte Speicherplatz. Transaktionen pro SekundeDie Zeit, die eine Transaktion braucht, um von einem Föderationsmitglied zum anderen zu wandern, hängt vom Abstand der Knoten ab. Bei einem globalen System beläuft sie sich auf durchschnittlich 150 Millisekunden.
Löst ein Wallet eine Transaktion aus, wird diese an ein Föderationsmitglied gesendet. Dieses prüft, ob keine Coins doppelt ausgegeben werden, indem eine Anfrage an die dezentrale BigchainDB gestartet wird. Je mehr Föderationsmitglieder, desto dezentraler sind die Kopien gespeichert, desto länger dauert eine Anfrage. Falls ok, wird die Transaktion an ein zweites Föderationsmitglied gesendet, das zufällig ausgewählt wird. Dieses schreibt die Transaktion in den Backlog und das Netzwerk wird benachrichtigt. Fehlerfreie Transaktionen werden nun dem lokal gespeicherten Block zugefügt. Dort muss gewartet werden, bis der Block gefüllt ist. Dies ist der Fall nach 1’000 zugefügten Transaktionen oder spätestens nach 5 Sekunden. Erst wenn das Mitglied alle vorgängigen Blöcke kontrolliert hat, wird der Block in die Blockchain geschrieben und wiederum das Netzwerk informiert. Nun können die anderen Föderationsmitglieder den Prüfprozess starten. Jeder Knoten muss für die Verifizierung Anfragen an die Datenbank starten, die digitale Unterschrift berechnen und das Resultat (positiv/negativ) in die Blockchain schreiben. Transaktionen können parallel geprüft werden, weshalb dieser Schritt von der Prozessorleistung abhängt. Sobald eine Verifizierung zu einem Mehrheitsentscheid führt, wird dies dem Netzwerk inklusive Wallet weitergeleitet. Insgesamt dauert es ca. 1.5 Sekunden bis das Wallet eine definitive Bestätigung der Ausführung bekommt. Mit RethinkDB wurden Transaktionen pro Sekunde (TPS) in Abhängigkeit der Anzahl Revisionsknoten getestet (siehe Grafik unten). Bei 32 Knoten wird bereits die Zielgrösse von 1 Mio. TPS erreicht.
1 Kommentar
23/4/2018 13:47:24
Yodse ecosystem overview
Antwort
Hinterlasse eine Antwort. |