Bei dem Stichwort Tangle muss man sofort an IOTA denken. Was hat euer Tangle mit dem von IOTA gemeinsam, worin unterscheidet es sich?

Das Tangle ist in erster Linie eine revolutionäre und beeindruckende Erfindung von IOTA, die uns stark inspiriert hat. Dazu handelt es sich um einen sehr treffenden Namen für eine scheinbar chaotische Speicheranordnung. In diesem Sinne unterscheidet sich das Helix-Tangle nicht von dem IOTA-Tangle. Transaktionen werden in einem Directed Acyclic Graph (DAG) zur weiteren Verarbeitung abgebildet, was vor allem Vorteile bei der Skalierbarkeit bringt – ein entscheidender Vorteil gegenüber einer Blockchain.

Im Tangle werden neue Transaktionen durch einen „Tip Selection“-Algorithmus an den Graphen angeknüpft, welcher Gewichte von Transaktionen nutzt, um einen „Random Walk“ zu simulieren, der seinerseits zwei Transaktionen, die es zu referenzieren gilt, als Ergebnis liefert. Bisherige Implementierungen des Tangle weisen jedoch eine Instabilität bei der „Tip Selection“ auf – in der Praxis enden manche Transaktionen als sogenannte „Waisen“, die von neu verknüpften Transaktionen niemals referenziert werden. Unser Data-Science-Team hat existierende Verfahren der „Tip Selection“ praktisch analysiert, diverse Optimierungsmöglichkeiten gefunden und realistische Simulationen der Lösungsansätze implementiert.

Weiterhin setzt Helix auf eine binäre statt eine trinäre Auslegung des Tangle. Wir verstehen zwar die Vorteile einer trinären Auslegung, insbesondere unter Ausführung in dedizierter Hardware, jedoch verfolgt Helix das Ziel einer höchstmöglichen Endnutzerkompatibilität. Entsprechend wurde auch die Kryptographie binär implementiert, wobei wir uns an den NIST-Standard halten und auf hochgradig experimentelle Verfahren verzichten. Zudem halten wir es gegenwärtig für sehr gewagt, Mutmaßungen über die Resistenz gegen Quantencomputern zu treffen, allerdings beschäftigen wir uns ebenfalls sehr intensiv mit dieser Herausforderung.

Ein weiteres Problem des Tangle liegt in der Unvergleichbarkeit von Elementen. Timestamps etwa können semantisch nicht validiert werden. Anders als in der Blockchain ist es nur schwer möglich, eine intuitive lineare Ordnung aus dem Tangle abzuleiten. Somit existieren Elemente, die als nicht vergleichbar gelten. Daher arbeiten wir in enger Kooperation mit Forschungsinstituten an einer Methode, Teilmengen des Tangle effizient zu ordnen, ohne dabei an semantischer Validität zu verlieren. Diese ist die Grundvoraussetzung für die geplante Unterstützung von Smart Contracts, für die entscheidend wichtig ist, in welcher Reihenfolge Transaktionen ausgeführt werden. Beispielsweise müssen Smart Contracts, die in Exchanges genutzt werden, eine Möglichkeit aufweisen, die Reihenfolge der „Bids“ einzusehen, um das digitale Asset an den Erstbietenden übertragen zu können.

Wie plant ihr die Dezentralität herzustellen und was ist eure Incentivierung für die Netzwerkteilnehmer?

Das Helix-Network führt sogenannte „Validator Nodes“ ein, deren primäre Aufgabe darin besteht, Meilensteine an das Tangle zu knüpfen und das jeweilige „Cutset“, also ein Intervall von Meilenstein bis einschließlich Meilenstein+1, linear zu ordnen. Meilensteine sind Transaktionen, die eine besondere digitale Signatur tragen und letztendlich für die Bestätigung von Transaktionen verantwortlich sind. Die Validatoren würden mittels des „Schnorr Digital Signing Algorithm“ den zu setzenden Meilenstein kollektiv signieren, sodass jeder Netzwerkteilnehmer die Authentizität bzw. den Ursprung des Meilensteins nachweisen kann.

Die Validatoren führen einen modifizierten „practical Byzantine Fault Tolerance Algorithmus“ (pBFT) aus, um Einigung über Meilenstein und Ordnung zu finden. Die Wahrscheinlichkeit, als „Primary“ oder „Leader“ gewählt zu werden, steht in Proportion zur jeweiligen „Reputation“ des Validators. Zur Wahl des Primary wird „Randherd“ (Scalable Bias Resistant Distributed Randomness) eingesetzt. Das Netzwerk ist vollkommen permissionless, also erfordert auch der Beitritt in die Teilnehmergruppe der Validatoren keinerlei Genehmigung – es entscheidet einzig und allein die Reputation über das Bestehen oder Nichtbestehen des Validators. Der Reputationswert des Validators leitet sich aus der Gesamtheit von Proof of Work ab, die ihm von Fullnodes oder Lightnodes zugeordnet wurde. Im Helix-Netzwerk entscheidet sich zwangsläufig jeder Teilnehmer für einen bestimmten Validator, dem er sich mit der jeweiligen Transaktion verpflichtet. Übrigens ermöglicht dieses grundlegende Konzept überhaupt erst eine reibungslose Integration von Smart Contracts und Proof of Useful Work.

Neben altruistischen Incentives wie beispielsweise dem sehr niedrigen Energieverbrauch besteht somit ebenfalls ein ökonomisches Interesse. Validatoren werden die Möglichkeit haben, sogenannte „Fabrics“ zu verwalten. Fabrics sind ein Zusammenschluss von „Compute-Nodes”, welche einer bestimmten Aufgabe zugewiesen sind, beispielsweise der Proteinfaltung. Ein Client kann seinen Datensatz zur Verarbeitung an einen „Fabric-Primary“ (z. B. Validator) senden, welcher diesen seinerseits an die für die Aufgabe bestimmte Fabric weiterleitet. Die Belohnung wird fair zwischen allen Compute-Nodes innerhalb der Fabric verteilt, während der Fabric-Primary eine Provision erhält.
Insofern hat ein Validator einen starken Anreiz, seine Reputation zu verbessern.

Was sind die Use Cases, die ihr anvisiert?

Helix und einige Partner arbeiten momentan an einer Vielzahl von Use Cases, welche vor allem als zeitnahe Proofs of Concept auf dem TestNet dienen sollen. Genaueres wird zu gegebener Zeit angekündigt.

Unser Hauptfokus liegt momentan auf „Beams“, einen Bio-Marketplace, der die sichere Übertragung von sensitiven Bio-Daten ermöglichen und somit einen Meilenstein im personalisierten Gesundheitswesen setzen soll. Ferner wird das Streamen oder Abonnieren eines Streams von biologisch wertvollen Daten gegen Kompensation ermöglicht. Dabei ist zu beachten, dass die Integrität der Daten quantifiziert werden muss, um ein attraktives Angebot für Forschung und Industrie zu schaffen.

Unser zweiter Use Case, den wir an dieser Stelle bereits nennen können, ist „Decentralized Cloud Computing as a Service“, in dessen Zentrum die oben genannten Fabrics stehen. Diese stellen, wie bereits erwähnt, einen Zusammenschluss von Compute-Nodes dar, die gegen Kompensation ressourcenintensive Rechenaufgaben ausführen. Auf diese Weise wird „sinnfreies“ Proof of Work eliminiert und gleichzeitig ein attraktives Belohnungssystem für unsere Netzwerkteilnehmer geschaffen. Unser Decentralized Computing in Verbindung mit Storage und Datenbanken as a Service bildet eine „Decentralized Cloud“ (DPaaS).

Ein weiterer Use Case, den wir bereits kommunizieren können, sind „Smartnodes“, welche „Cognitive Security Operations“ as a Service anbieten. Smartnodes gehören zu der Gruppe der Lightnodes und besitzen die Fähigkeit, Nachbarschaften innerhalb des Netzwerks mittels kognitiver Verfahren zu diagnostizieren. Das Diagnoseprogramm fügt sich aus mehreren Analyseschichten zusammen. Auf einer der Schichten operiert ein „Differentiable Neural Computer“ (DNC), welcher im Vergleich zu seinen Vorgängern („Deep Neural Networks“) auch bereits vergangenes Wissen nutzen kann, indem eine zusätzliche Speichermatrize zur Verfügung gestellt wird. In klassischen neuronalen Netzen werden die Kantengewichte in dem Prozess der „Back propagation“ überschrieben, sodass Zwischenergebnisse, welche möglicherweise aus vorherigen, kontextfremden Datensätzen extrahiert wurden, trotz ihres Wertes verloren gehen. Dieses Phänomen ist auch als „catastrophic interference“ bekannt. Der Vorteil von DNCs zeigt sich an der Methode, in die Speichermatrix zu schreiben und von ihr lesen zu können, ohne dabei die Kantengewichte selbst zu beeinflussen. Ein DNC weist somit die Möglichkeit auf, sich anhand der zugrunde liegenden Aufgabe selbstständig und zielgerichtet zu re-programmieren. Die DNC-Schicht soll Echtzeitinferenzen über die topologischen Strukturen des Tangle liefern, welche in Kombination mit bestimmten Parametern – etwa absoluter, maximaler Differenz der Transaktionsrate oder der gemittelten Verzögerung der Nachrichtenübermittlung zwischen Nodes – wertvolle Informationen über mögliche Angriffe enthalten können.

Wie weit seid ihr mit Helix? Was sind die nächsten Schritte?

Aus technischer bzw. Entwicklersicht konzentrieren wir uns gegenwärtig (August 2018) voll auf das Helix-Protokoll. Dieses befindet sich nach wie vor in der Prototyping-Phase, in der Stabilitäts- und Sicherheitsnachweise für vorgestellte Methoden erbracht werden. Modell und Kryptographie stehen für Reviews aus. Intern laufen das Protokoll sowie erste Use Case-Prototypen bereits seit einigen Monaten stabil. Einem breiteren geschlossenen Benutzerkreis soll im Januar 2019 Zugriff gewährt werden. Kurz darauf folgt dann die Bereitstellung einer ersten Open Alpha.

Das Wallet ist bereits vollständig implementiert und geht bald in die zweite Prototyping-Phase, in welcher Peer-Reviews und Security-Audits abgehalten werden.

Der MainNet-Launch (Open Beta) findet dann spätestens in Q2/2019 statt. Es ist geplant, das Netz mit uneingeschränkter Kernfunktionalität zu launchen. Allerdings werden sich zumindest einige Funktionsbereiche der Open Beta zu dem Zeitpunkt noch in einem experimentellen Stadium befinden.

Da das Netzwerk zukünftig von einer gemeinnützigen Stiftung betrieben, gewartet und gefördert werden wird, haben wir die Helix Foundation mit Sitz in Berlin gegründet, die kürzlich offiziell eingetragen wurde und sich über unseren ICO finanzieren wird, dessen Startschuss für den 30. September 2018 geplant ist.

BTC-ECHO