Ich weiß, ich weiß. Es gibt viele Krypto-Projekte, es gibt viele Konsens: basierend auf Arbeit und Eigentum, Gold, Öl, gebackenen Kuchen (es gibt eines, ja, ja). Was brauchen wir mehr von einem? Dies möchte ich diskutieren, nachdem ich die Übersetzung der „leichten“ technischen Dokumentation des *Constellation-Projekts gelesen habe (). Natürlich ist dies keine vollständige Beschreibung des Algorithmus, aber mich interessiert die Meinung der Habr-Community. Gibt es einen Platz für einen solchen Konsens oder ist er unnötig?
Es gibt nicht mehr viele Buchstaben. Wenn Sie also einfach nur „Wow, so viel wie möglich über Krypto“ schreiben möchten, dann unterlassen Sie es bitte. Wenn Sie sich für neue Entwicklungen im Bereich verteilter Systeme interessieren und etwas in den Kommentaren mitzuteilen haben, dann verweisen Sie bitte auf Kat.
PS: Ich bin nicht der Autor der Technologie, ich kann nicht für die vollständige Übertragung des Wesens garantieren, daher freue ich mich über Kommentare mit Änderungsanträgen, falls vorhanden.
Entwicklung von synchronen zu asynchronen Konsensen
Knoten werden mithilfe eines deterministischen Prozesses ausgewählt (derselbe, der auch in DHTs wie Bittorrent verwendet wird), der die Verantwortlichkeiten der Knoten dynamisch anpasst, um die Validierung zu „erleichtern“ oder, verständlicher, einen Konsens zu erzielen. Wir wählen Gruppen von 3 Knoten aus und führen parallel Konsensrunden durch, sodass ein Knoten als Moderator in mehreren Blöcken fungieren kann. Dadurch können wir Transaktionen asynchron verarbeiten, was im Wesentlichen bedeutet, dass mehrere Blockchains gleichzeitig gebildet werden. Der Prozess ähnelt einem Spinnennetz, das aus vielen Fäden besteht, im Gegensatz zu Knoten, die im Laufe der Zeit eine einzige Kette bilden. Asynchrone oder parallele Verarbeitung ist die Grundlage der skalierbaren Programmierung, da sie die Nutzung aller Computerressourcen ermöglicht und so die Gesamtberechnung beschleunigt. Dieses Netzwerk wird in der Informatik als gerichteter azyklischer Graph oder DAG bezeichnet.
Kanalbreite einer linearen Blockchain im Vergleich zum multiplikativen Effekt einer DAG, bei der wir mehrere parallele Blockchains haben.
Geometrische Implementierung der linearen Blockchain gegen DAG. Schwarze Punkte sind Blöcke, weiße Punkte sind Knoten
Wir verwenden in jeder Konsensrunde drei Knoten, da wir dadurch einige interessante mathematische Prozesse für die Schlussfolgerung über den Zustand erhalten und eine „Oberflächenebene“ über die Daten in Form verbundener Dreiecke bilden. Das Protokoll verwendet dann die Dreiecke, um eine optimale Oberfläche zusammenzufügen, die keine redundanten oder inkonsistenten Daten enthält und die kleinstmöglichen Dreiecke aufweist. Algorithmisch ist dies analog zu einem „minimalen Schnitt“ eines Graphen und mathematisch analog zu einer Ableitungs- oder Optimierungsfunktion (aus der die Funktion den kürzesten Weg findet, den sie entlang der Oberfläche zurücklegen kann). Dieser kürzeste Weg entspricht der optimalen Speicherung von Daten (Transaktionen) in einem DAG. Widersprüchliche dreieckige „Kacheln“, damit die Oberfläche der Veranstaltung glatt und konfliktfrei ist.
Geometrische Implementierung der Konflikterkennung/-bearbeitung. Ein widersprüchlicher Block erzeugt eine zusätzliche Oberflächenkachel. Wir entfernen zusätzliche Oberflächenkacheln, um eine ebene (= konfliktfreie) Veranstaltungsoberfläche zu erhalten.
Konsens basierend auf Reputation
In einem optimalen dezentralen P2P-Reputationssystem sollte jeder Knoten in der Lage sein, sein Vertrauen in andere Knoten unabhängig zu bestimmen. Unser System verwendet ein spezielles Modell, das transitive Beziehungen oder Beziehungen, die ein Knoten zu anderen Knoten hat, bei der Zuweisung einer globalen Bewertung berücksichtigt. „Sie sind nur so gut wie Ihr Unternehmen.“ Das Endergebnis ist eine „Schiefe“ oder ein Gradient, der auf transitivem Vertrauen oder Reputation über alle Knoten im $DAG oder regulären Kanal basiert. Dies kann man sich wie einen Pinsel oder eine Käsereibe vorstellen, die über eine „Oberfläche“ radiert und auswählt, welche „dreieckigen Kacheln“ gelöscht und welche zurückgelassen werden sollen. Auf diese Weise entfernt die Konfliktlogik tatsächlich „dreieckige Kacheln“.
Ein DAG mit einer widersprüchlichen Kachel geht durch einen „gekrümmten“ Raum, der einen Farbverlauf aufweist, ähnlich einer Käsereibe, und wird die widersprüchliche Kachel entfernen oder „löschen“.
Teilweise/vollständige Knotenskalierung
In der Netzwerktheorie wird die optimale Zuweisung typischerweise als „skalenfrei“ bezeichnet, was als eine hierarchische Anordnung beschrieben werden kann, bei der große zentrale Knoten viele kleinere periphere Knoten verwalten. Diese Verbreitung ist in der Natur und vor allem im Internet sichtbar. Constellation nutzt diese Architektur, um den Durchsatz oder die Breite unseres Diagramms zu „skalieren“ oder zu erhöhen.
Der Effekt der hierarchischen Partitionierung. Wir können weitere Knoten hinzufügen, indem wir die Bandbreite erhöhen
Hylochain – Kanalbasierte Anwendungsunterstützung
Unser Ansatz zur Anwendungsunterstützung kann als „dezentrale Smart-Contract-Plattform“ betrachtet werden. Anstelle eines zentralen Netzwerks, das die gesamte Logik ausführt und alle Daten der Anwendung verarbeitet, koordiniert Constellation die Anwendungsdaten mit „Hauskanälen“, die man sich wie einen Fernsehsender vorstellen kann, der alle Daten des Haussystems sendet. Jeder Mitarbeiterkanal kann seine eigene Verifizierungslogik implementieren, um das Oracle-Problem durch End-to-End-Authentifizierung von Datenproduzenten und transitive Verifizierung zusammengesetzter Mitarbeitersysteme zu lösen. State-Channel-Netzwerke bieten parallele Unterstützung für Anwendungen und beschleunigen so die Einführungszeiten, die durch den herkömmlichen synchronen Konsens in einem Smart-Contract-Netzwerk begrenzt sind.
Zwei Standardkanäle, die über das $DAG-Netzwerk „kompatibel“ sind. Sie können interagieren oder interpretiert werden, da sie beide durch den Einsatz hybrider $DAG + Channel-Knoten in $DAG „integriert“ sind.
Der Grund für den Namen Hylochain liegt darin, dass unser Ansatz zur Anwendungsunterstützung das funktionale Programmiermodell Recursion Schemes zur Erstellung der MapReduce-Schnittstelle verwendet hat. Insbesondere können die Rekursionsschemata Hylomorphismus und Metamorphismus integriert werden, um überprüfbare Abfragen zu erstellen und Verbindungen über native Kanäle zu streamen, indem algebraische Datentypen auf die gleiche Weise validiert werden, wie Op-Codes für Smart Contracts überprüft werden. Das Endergebnis ist eine funktionale MapReduce-Schnittstelle, die Dateningenieuren vertraut und mit der vorhandenen Big-Data-Technologie kompatibel ist.
Hylomorphic und Metamorphic sind Standardkanäle für den Kontrast. Im metamorphen Zustand werden Daten von zwei regulären Kanälen an einen Block im Metakanal gesendet. In Gilo verwenden wir den vorherigen Status eines Kanals, um zwei andere Kanäle abzufragen (eine bestimmte Frage zu stellen) und speichern dann das Abfrageergebnis in einem Block.
Tokenomics und seine Verbindung mit Hylochain
Sobald ein nativer Kanal erstellt wurde, kann er in den $DAG-Kanal integriert werden, allerdings unter Verwendung der ACI oder Application Chain Interface. Diese Schnittstelle ist einfach ein JSON-Objekt mit Konfigurationsinformationen und einem öffentlichen Schlüssel, der dem Kanal selbst zugeordnet ist. Der Grund, warum wir einen öffentlichen Schlüssel einem regulären Kanal zuordnen, besteht darin, einen Vermittlungsmechanismus für die Daten des regulären Kanals zu schaffen. Wenn der reguläre Kanal bereitgestellt wird, konfigurieren Entwickler selbst, wie Zahlungen aus dem $DAG-Netzwerk zwischen Knoten und Betreibern verteilt werden.
Ablauf zum Erwerb des Zugangs zu Informationen oder zur Änderung von Informationen. Die Anfrage wird an $DAG gesendet, das Geld wird an das Kanalkonto gesendet, das Ergebnis wird an den Käufer gesendet und die Transaktionsprüfsumme wird an das $DAG-Netzwerk gesendet, das dann das Geld an den regulären Kanal freigibt.
Source: habr.com