In diesem Artikel möchte ich Euch die Zilliqa Blockchain etwas näherbringen.
Es wird hier etwas technischer, ich hoffe auch der Neueinsteiger kann erahnen, wie das System funktioniert
Ich wurde über Telegram angefragt, ob ich nicht einen Artikel über Zilliqa schreiben könnte, um das Projekt im deutschsprachigen Raum etwas bekannter zu machen.
Während meiner Recherche über Zilliqa wurde mir rasch klar, dass das gar nicht so einfach ist.
Das Zilliqa Netzwerk ist ziemlich komplex und hat recht wenig mit anderen bekannte Blockchain Projekten gemeinsam.
Natürlich habe ich ein passendes Video zur Thematik gemacht und dieser Artikel soll, soweit möglich, die Informationen aus dem Video zusammenfassen.
Beginnen wir mit dem Aufbau von Zilliqa:
Zilliqa besteht aus zwei parallel laufenden Blockchains auf denen unterschiedliche Daten abgelegt werden.
Diese zwei Blockchains werden durch zwei verschiedene, zusammen arbeitende „Abteilungen“ mit Daten gespeist.
Einerseits gibt es das Directory Service Committe (in der Grafik grün dargestellt)
Das DSC kann man sich am besten als die Organisationsabteilung vorstellen.
Auf der anderen Seite haben wir die Shards. Die Shards sind die Abteilungen, die die eigentliche Arbeit verrichten. In den Shards werden die Transaktionen validiert. Man könnte die Shards als Produktion in einer Fabrik verstehen. (in der Grafik rot dargestellt)
Wir haben also, um bei der Fabrik zu bleiben, das Directory Service Committe als Administrativabteilung, die die Arbeiten an die Produktion weiterleitet und verteilt.
Der Output der Shards, also der Produktion, wird auf der TX Blockchain in Form von TX Blöcken gespeichert (hellblau) und die administrativen Daten des DSC werden auf der Public Channel Blockchain in Form von DS Blöcken gespeichert (gelb).
Die beiden Blockchains sind miteinander verknüpft, sodass die administrativen Daten mit den Transaktionsdaten der einzelnen Blöcke verbunden sind.
Sehen wir uns jetzt einmal an wie die administrative Seite funktioniert:
Directory Service Committe / DSC
Das DSC umfasst eine fixe Anzahl Nodes. Die Nodes werden im First in, First out verfahren nach einer gewissen Zeit ausgetauscht. Das heißt der älteste Node fällt aus dem Committe raus und wird durch einen neuen ersetzt. Der neue Node kann dem Committe nur beitreten, wenn er vorher ein Proof of Work Rätsel gelöst hat. Mit dem Lösen des Rätsels erwirbt sich der Node gewissermaßen eine Zutrittsberechtigung. Diese Zutrittsberechtigung wird in der Public Channel Blockchain gespeichert.
In weiterer Folge bestimmt das DSC einen Leader welcher, für die Zeit die es benötigt einen DS Block zu generieren, im Amt bleibt. Man spricht von einer DS Epoche.
Der DS Leader erhält sein Amt in dem er am schnellsten ein POW Rätsel gelöst hat.
Die Aufgabe des DS Leaders besteht nun darin die Aufgaben- und Nodeverteilung in der Produktion, also in den Shards vorzunehmen. Er leitet gewissermaßen die Aufgaben der Verwaltung an die Produktion weiter und dient somit als Bindeglied.
Nun kommen wir zu den Shards:
Zuerst müssen wir uns ansehen, was Shards eigentlich sind.
Während in herkömmlichen Blockchainnetzwerken alle Nodes im Netzwerk an derselben Aufgabe arbeiten, werden bei Zilliqa die Nodes in Arbeitsgruppen aufgeteilt. Nehmen wir als Beispiel 1000 Nodes im Netzwerk. Diese 1000 Nodes werden jetzt in 10 Arbeitsgruppen ( Shards) aufgeteilt. Das bedeutet, dass in jedem Shard 100 Nodes arbeiten. Das bedeutet weiter, dass jetzt 10 Aufgaben parallel bearbeitet werden können und dadurch die Transaktionsgeschwindigkeit ( TX/ Sekunde) um den Faktor 10 gestiegen ist. In einem Zilliqa Shard sind aus Sicherheitsgründen mindestens 600 Nodes in einer Arbeitsgruppe.
Aufbau der Shards:
Alle Nodes in einem Shard haben vor dem Eintritt ein POW Rätsel zu lösen. Auch hier braucht jeder Node eine Zutrittsberechtigung, welche wieder auf der Public Channel Chain gespeichert wird.
Im Gegensatz zum DSC ist die Nodeanzahl in der „Produktion“ nicht beschränkt. Je mehr Nodes in der Produktion arbeiten, umso mehr Shards können gebildet werden und umso mehr Aufgaben können parallel bearbeitet werden. Das bedeutet, je mehr Nodes in der Produktion arbeiten, desto höher werden die Transaktionen pro Sekunde.
Auch in den Shards wird mithilfe eines POW Rätsels ein Leader bestimmt, der Shard Leader. Der Shard Leader / SL bleibt für die Dauer eines Microblocks im Amt. Ein Microblock bezeichnet eine validierte Aufgabe.
So, jetzt wissen wir, wie die beiden Abteilungen aufgebaut sind. Sehen wir uns jetzt an wie die Shards zusammengestellt werden:
Sobald der neu ernannte Directory Service Leader sein Amt antritt, gibt er ein POW Rätsel an alle Nodes in der Produktion. Alle Nodes die das Rätsel gelöst haben werden daraufhin den verschiedenen Shards zugeteilt. Dadurch wird erreicht, dass die Shards nach jeder DS Epoche, also Amtszeit des DSC Leaders, neu zusammengestellt werden. Sind die Shards neu zusammengestellt bestimmen die einzelnen Shards, mittels POW, ihren Leader.
Der Konsensmechanismus:
Practical Byzantine fault Tolerance / PBTF
Die Konsensfindung in den Shards durchläuft 3 Phasen.
• 1. Phase: pre Prepare Phase
In dieser Phase sendet der Shard Leader die Aufgabe an alle Nodes im Shard.
• 2. Phase: Prepare Phase
In dieser Phase validiert jeder Node die Aufgabe und schickt eine „erledigt“ Nachricht an alle anderen Nodes im Shard.
• 3. Phase: Commit Phase
In der Commit-Phase wartet jeder Node bis er von mindestens 2/3 der anderen Nodes im Shard eine „erledigt“ Meldung erhält. Wenn ein Node die entsprechende Anzahl an „erledigt“ Meldungen von den anderen Nodes erhalten hat, sendet er eine „Übergabe“
Nachricht an alle anderen Nodes im Shard. Danach wartet jeder Node auf den Empfang der „Übergabe“ Nachricht von mindestens 2/3 der Nodes im Shard.
Nach diesen drei Phasen die im Shard verarbeitet wurden, wird der so entstandene Microblock vom Shard Leader an das Directory Service Committe gesendet. Im DSC durchläuft jeder Microblock das gleiche Validierungsverfahren noch einmal. Das DSC führt also den PBTF Mechanismus bei jedem Microblock noch einmal durch.
Wenn die Validierungsphasen im DSC durchlaufen sind, werden mehrere Mikroblöcke in einen TX Block verpackt und der TX Blockchain angehängt.
Die Daten der Nodes, welche bei den Validierungsphasen anfielen werden durch das DSC in einen DS Block gespeichert und der Public Channel Blockchain angehängt und mit den nötigen Verknüpfungen zur TX Blockchain versehen.
Nachdem wir nun wissen wie die Zilliqa Blockchain im Wesentlichen aufgebaut ist, ist es an der Zeit die Sicherheit des Netzwerkes etwas genauer anzusehen.
Sicherheitsmaßnahmen:
Da jeder Node im Zilliqa Netzwerk eine Zutrittsberechtigung braucht und zum Erlangen, ebendieser Zutrittsberechtigung, ein POW Rätsel lösen muss, entstehen für jeden Nodebetreiber Energiekosten. So gesehen kauft sich jeder Nodebetreiber über die Energiekosten zum Lösen des POW Rätsels in das Netzwerk ein. Dadurch wird es für einzelne Nodebetreiber relativ teuer, wenn er mehrere Nodes ins Netzwerk einschleusen will. Es wurde so die erste Hürde für betrügerische Nodes geschaffen.
Da bei der Bestimmung der Leader, egal ob im DSC oder im Shard, wieder ein POW Rätsel gelöst werden muss steigen die Kosten weiter. Auch das Zusammensetzen der Shards beginnt mit einem POW Rätsel an die Nodes in der „Produktion“, ergo wieder Kosten.
Durch diese POW Rätsel wird das Netzwerk sehr effektiv vor Sybil Attacken geschützt. Eine Sybil Attacke zielt auf die Leistungsfähigkeit eines Netzwerks, indem der Attackierende versucht das Netzwerk mit Anfragen zu fluten und dadurch die Geschwindigkeit im Netzwerk zu reduzieren oder gleich komplett lahmlegen.
Eine weitere Hürde für betrügerische Nodes ist der Umstand, dass bei jedem Amtsantritt eines neuen DSC Leaders die Shards neu zusammengestellt werden. Somit weiß der Betreiber eines betrügerischen Nodes nicht welchem Shard er zugeteilt wird und schon gar nicht welche Transaktionen in diesem Shard validiert werden.
Zusätzlich geht das Zilliqa Netzwerk von einer Beteiligung von betrügerischen Nodes in Höhe von 1/3 der Nodes in einem Shard aus. Wenn das Netzwerk kompromittiert werden soll, muss der betrügerische Nodebetreiber demnach 2/3 der Nodes im Shard kontrollieren. Nur weiß er ja nicht in welchem Shard seine Nodes zugeteilt werden.
Von dieser Seite her scheint es schier unmöglich mit betrügerischen Nodes das Netzwerk zu manipulieren.
Rein mathematisch liegt die Wahrscheinlichkeit das 1/3 der Nodes im Shard betrügerisch sind bei 1 zu 1 Million, sofern insgesamt 600 Nodes im Shard sind. Das ist der Grund, warum immer mindestens 600 Nodes in einem Shard sein müssen.
Zusätzlich ist im Zilliqa Netzwerk noch eine weitere Sicherheitsstufe eingebaut. Diese Stufe zielt auf betrügerische Leader. Es besteht durchaus die Möglichkeit, dass ein betrügerischer Node zum Shard Leader werden kann, er muss nur das POW Rätsel am schnellsten lösen. In einem solchen Fall kann eine 2/3 Mehrheit im Shard den Leader absetzen. Zu einer Abwahl führen einige Parameter wie unter anderem die Geschwindigkeit mit der der Leader kommuniziert. Versucht der Leader die Transaktionsgeschwindigkeit zu bremsen und somit das Netzwerk zu verlangsamen wird er abgesetzt, sofern eine 2/3 Mehrheit im Shard besteht.
Bei der Validierung der Transaktionen im Shard, wird die Transaktion zweimal mit mindestens einer 2/3 Mehrheit für gültig erklärt. Im DSC wird der Microblock ebenfalls mit mindesten einer 2/3 Mehrheit in 2 Phasen validiert, also auch zweimal. Somit wurde am Ende jede Transaktion viermal mit mindestens einer 2/3 Mehrheit validiert.
Wenn ein neuer Block an die Blockchain angehängt wird, sind keine Bestätigungen oder Kontrollen des Blockes mehr nötig. Alle Bestätigungen und Validierungen finden vor dem Anhängen des Blockes statt. Ein direkter Angriff auf die eigentliche Blockchain bringt somit nichts.
Soviel zu den Sicherheitsaspekten im Zilliqa Netzwerk.
Nun zu den Vorteilen diese Architektur:
Als Erstes fällt natürlich die Skalierbarkeit ins Auge. Mit jedem zusätzlichen Node im Netzwerk steigt, linear, die Transaktionsgeschwindigkeit.
Die Entwickler prognostizieren 2500 TX/ sec. was auf dem Niveau von VISA liegt.
Dadurch, dass der POW nur sporadisch eingesetzt wird und nicht dauernd, wie z.B. beim Bitcoin, ist der Energiebedarf bei Zilliqa wesentlich geringer.
Das Netzwerk ist, wie wir gesehen haben, äußerst sicher und stabil.
Zum Schluss noch zwei zusätzliche Layer bei Zilliqa:
Ohne genaue auf die Umsetzung einzugehen noch zwei Dinge.
Im Zilliqa Netzwerk gibt es Smartcontracts. Diese werden mit der Scilla Programmiersprache geschrieben.
Staking
Staking auf ZIL ist auch möglich, wobei hier die hinterlegten ZIL nicht für die Validierung der Blöcke eingesetzt wird, sondern das „Archiv“ absichern. Nodes, die die Transaktionsdaten aufbereiten und der Öffentlichkeit zur Verfügung stellen (Blockexplorer) müssen den Qualitätsansprüchen von Zilliqa entsprechen. Diese Nodes werden regelmäßig von Zilliqa überprüft. (Online-Zeit, Bandbreite, etc.) Nodes die den Qualitätsansprüchen nicht genügen werden bestraft und Ihre hinterlegten ZIL werden teilweise oder ganz eingezogen.
So, das war es von meiner Seite zum Thema Zilliqa.
Ich hoffe, ich konnte Euch einen Überblick zur Funktionsweise verschaffen.
Falls ich irgendwo einen Fehler eingebaut habe, korrigiert mich bitte in den Kommentaren.
Dasselbe gilt natürlich für jede Art von Kritik und Anregungen.
In diesem Sinne
Tschüss Euch