Scaling Blockchains With Off-chain Data

Neuauflage von Plato

Verfolger: 0

Wenn ein Hash eine Million Worte wert ist

Inzwischen ist klar, dass viele Blockchain-Anwendungsfälle nichts mit Finanztransaktionen zu tun haben. Stattdessen soll die Kette die dezentrale Aggregation, Bestellung, Zeitstempelung und Archivierung von ermöglichen jedem Art der Informationen, einschließlich strukturierter Daten, Korrespondenz oder Dokumentation. Der Kernwert der Blockchain besteht darin, dass sich die Teilnehmer nachweislich und dauerhaft darauf einigen können, welche Daten wann und von wem eingegeben wurden, ohne sich auf einen vertrauenswürdigen Vermittler verlassen zu müssen. Zum Beispiel wurde SAP kürzlich gestartet Blockchain-PlattformDas Unternehmen unterstützt MultiChain und Hyperledger Fabric und zielt auf eine breite Palette von Lieferketten- und anderen nichtfinanziellen Anwendungen ab.

Die einfachste Möglichkeit, eine Blockchain zum Aufzeichnen von Daten zu verwenden, besteht darin, jedes Datenelement direkt in eine Transaktion einzubetten. Jede Blockchain-Transaktion wird von einer oder mehreren Parteien digital signiert, auf jeden Knoten repliziert, vom Konsensalgorithmus der Kette geordnet und mit einem Zeitstempel versehen und manipulationssicher dauerhaft gespeichert. Alle Daten innerhalb der Transaktion werden daher von jedem Knoten identisch, aber unabhängig gespeichert, zusammen mit einem Nachweis darüber, wer sie wann geschrieben hat. Die Benutzer der Kette können diese Informationen jederzeit abrufen.

Mit MultiChain 1.0 konnten beispielsweise ein oder mehrere benannte „Streams“ in einer Blockchain erstellt und dann zum Speichern und Abrufen von Rohdaten verwendet werden. Jeder Stream verfügt über eigene Schreibberechtigungen, und jeder Knoten kann frei auswählen, welche Streams abonniert werden sollen. Wenn ein Knoten einen Stream abonniert hat, indiziert er den Inhalt dieses Streams in Echtzeit, sodass Elemente anhand ihrer Reihenfolge, ihres Zeitstempels, ihrer Blocknummer oder ihrer Herausgeberadresse sowie über einen „Schlüssel“ (oder eine Bezeichnung) schnell abgerufen werden können. durch welche Elemente markiert werden können. MultiChain 2.0 (seit Alpha 1) erweiterte Streams, um Unicode-Text oder JSON-Daten sowie mehrere Schlüssel pro Element und mehrere Elemente pro Transaktion zu unterstützen. Außerdem wurden Zusammenfassungsfunktionen wie "JSON-Zusammenführung" hinzugefügt, mit denen Elemente auf nützliche Weise mit demselben Schlüssel oder Herausgeber kombiniert werden.

Vertraulichkeit und Skalierbarkeit

Das Speichern von Daten direkt in einer Blockchain funktioniert zwar gut, weist jedoch zwei wesentliche Mängel auf: Vertraulichkeit und Skalierbarkeit. Zunächst ist der Inhalt jedes Stream-Elements für jeden Knoten in der Kette sichtbar, und dies ist nicht unbedingt ein wünschenswertes Ergebnis. In vielen Fällen sollte ein Datenelement nur für eine bestimmte Teilmenge von Knoten sichtbar sein, selbst wenn andere Knoten für die Reihenfolge, Zeitstempelung und Beglaubigung benötigt werden.

Vertraulichkeit ist ein relativ einfach zu lösendes Problem, indem Informationen verschlüsselt werden, bevor sie in eine Transaktion eingebettet werden. Der Entschlüsselungsschlüssel für jedes Datenelement wird nur an die Teilnehmer weitergegeben, die es sehen sollen. Die Schlüsselübergabe kann in der Kette mithilfe der asymmetrischen Kryptografie (as hier beschrieben) oder über einen Off-Chain-Mechanismus, wie es bevorzugt wird. Jeder Knoten, dem der Schlüssel zum Entschlüsseln eines Elements fehlt, sieht nur binären Kauderwelsch.

Skalierbarkeit ist dagegen eine größere Herausforderung. Angenommen, jede anständige Blockchain-Plattform sollte einen Netzwerkdurchsatz von 500 Transaktionen pro Sekunde unterstützen. Wenn der Zweck der Kette die Informationsspeicherung ist, hängt die Größe jeder Transaktion in erster Linie davon ab, wie viele Daten sie enthält. Jede Transaktion benötigt außerdem (mindestens) 100 Byte Overhead, um die Adresse des Absenders, die digitale Signatur und einige andere Kleinigkeiten zu speichern.

Wenn wir einen einfachen Fall nehmen, in dem jedes Element eine kleine JSON-Struktur von 100 Bytes ist, würde der Gesamtdatendurchsatz 100 Kilobyte pro Sekunde betragen, berechnet aus 500 × (100 + 100). Dies entspricht einer Bandbreite von weniger als 1 Megabit / Sekunde, was der Kapazität jeder modernen Internetverbindung entspricht. Daten würden sich mit einer Rate von etwa 3 Terabyte pro Jahr ansammeln, was keine geringe Menge ist. Aber jetzt mit 12 Terabyte Festplatten weit verbreitet und RAID Controller, die mehrere physische Laufwerke zu einem einzigen logischen Laufwerk kombinieren, können problemlos 10 bis 20 Jahre Daten auf jedem Knoten speichern, ohne zu viel Aufwand oder Kosten.

Ganz anders sieht es jedoch aus, wenn wir größere Informationen speichern, z. B. gescannte Dokumentationen. Ein JPEG-Scan von A4-Blatt Papier mit angemessener Qualität kann eine Größe von 500 Kilobyte haben. Multiplizieren Sie dies mit 500 Transaktionen pro Sekunde, und wir sehen einen Durchsatz von 250 Megabyte pro Sekunde. Dies entspricht einer Bandbreite von 2 Gigabit / Sekunde, was schneller ist als bei den meisten lokalen Netzwerken, geschweige denn bei Verbindungen zum Internet. Bei Amazon Web Services am billigsten veröffentlichter Preis von 0.05 USD pro Gigabyte bedeutet dies eine jährliche Bandbreitenrechnung von 400,000 USD pro Knoten. Und wo speichert jeder Knoten die 8000 Terabyte neuer Daten, die jährlich generiert werden?

Es ist klar, dass für Blockchain-Anwendungen, in denen viele große Datenmengen gespeichert sind, eine einfache Speicherung in der Kette keine praktische Wahl ist. Um die Verletzung zusätzlich zu beleidigen, werden Knoten aufgefordert, eine große Menge an Informationen zu speichern, die sie nicht einmal lesen können, wenn Daten verschlüsselt werden, um das Problem der Vertraulichkeit zu lösen. Dies ist kein attraktiver Vorschlag für die Teilnehmer des Netzwerks.

Die Hashing-Lösung

Wie lösen wir das Problem der Skalierbarkeit von Daten? Wie können wir die dezentrale Beglaubigung von Daten durch die Blockchain nutzen, ohne diese Daten auf jeden Knoten in der Kette zu replizieren?

Die Antwort ist mit einer cleveren Technologie, die als „Hash“ bezeichnet wird. Ein Hash ist eine lange Zahl (denken Sie an 256 Bit oder etwa 80 Dezimalstellen), die ein Datenelement eindeutig identifiziert. Der Hash wird aus den Daten mit a berechnet Einwegfunktion Das hat eine wichtige kryptografische Eigenschaft: Bei jedem Datenelement ist es einfach und schnell, seinen Hash zu berechnen. Bei einem bestimmten Hash ist es jedoch rechnerisch nicht möglich, Daten zu finden, die diesen Hash generieren würden. Und wenn wir „rechnerisch nicht realisierbar“ sagen, meinen wir mehr Berechnungen als Atome im bekannten Universum.

Hashes spielen in allen Blockchains eine entscheidende Rolle, indem sie Transaktionen und Blöcke eindeutig identifizieren. Sie liegen auch der rechnerischen Herausforderung in Proof-of-Work-Systemen wie Bitcoin zugrunde. Es wurden viele verschiedene Hash-Funktionen mit Gobbledy-Gook-Namen wie BLAKE2, MD5 und RIPEMD160 entwickelt. Damit jedoch einer Hash-Funktion vertraut werden kann, muss sie einer umfassenden akademischen Überprüfung und Prüfung unterzogen werden. Diese Tests werden in Form von versuchten Angriffen durchgeführt, z. B. "Vorbild" (Finden einer Eingabe mit dem angegebenen Hash), "Zweites Vorbild" (Finden einer zweiten Eingabe mit demselben Hash wie die angegebene Eingabe) und "Kollision" (Finden eines beliebigen) zwei verschiedene Eingänge mit demselben Hash). Das Überleben dieses Handschuhs ist alles andere als einfach. Eine lange und tragische Geschichte gebrochener Hash-Funktionen beweist die berühmte Maxime: "Rollen Sie nicht Ihre eigene Krypto."

Um zu unserem ursprünglichen Problem zurückzukehren, können wir die Skalierbarkeit von Daten in Blockchains lösen, indem wir anstelle der Daten selbst die Hashes großer Datenmengen in Transaktionen einbetten. Jeder Hash fungiert als "Verpflichtung" zu seinen Eingabedaten, wobei die Daten selbst außerhalb der Blockchain oder "außerhalb der Kette" gespeichert werden. Mit der beliebten SHA256-Hash-Funktion kann beispielsweise ein 500-Kilobyte-JPEG-Bild durch eine 32-Byte-Zahl dargestellt werden, was einer Reduzierung von über 15,000 × entspricht. Selbst mit einer Rate von 500 Bildern pro Sekunde befinden wir uns in Bezug auf die in der Kette selbst gespeicherten Daten bequem wieder auf dem Gebiet der realisierbaren Bandbreiten- und Speicheranforderungen.

Natürlich kann jeder Blockchain-Teilnehmer, der ein Off-Chain-Image benötigt, es nicht aus seinem Hash reproduzieren. Wenn das Bild jedoch auf andere Weise abgerufen werden kann, dient der On-Chain-Hash dazu, zu bestätigen, wer es wann erstellt hat. Genau wie bei regulären On-Chain-Daten ist der Hash in eine digital signierte Transaktion eingebettet, die einvernehmlich in die Kette aufgenommen wurde. Wenn eine Bilddatei vom Himmel fällt und der Hash für dieses Bild mit einem Hash in der Blockchain übereinstimmt, werden der Ursprung und der Zeitstempel dieses Bildes bestätigt. Die Blockchain bietet also genau den gleichen Wert für die Beglaubigung, als ob das Bild direkt in die Kette eingebettet wäre.

Eine Frage der Lieferung

So weit, ist es gut. Durch das Einbetten von Hashes in eine Blockchain anstelle der Originaldaten haben wir eine einfache Lösung für das Problem der Skalierbarkeit. Dennoch bleibt eine entscheidende Frage offen:

Wie liefern wir den ursprünglichen Inhalt außerhalb der Kette an die Knoten, die ihn benötigen, wenn nicht über die Kette selbst?

Diese Frage hat mehrere mögliche Antworten, und wir wissen, dass MultiChain-Benutzer sie alle anwenden. Ein grundlegender Ansatz besteht darin, ein zentrales Repository bei einer vertrauenswürdigen Partei einzurichten, in das alle Daten außerhalb der Kette hochgeladen und anschließend abgerufen werden. Dieses System könnte natürlich die "Inhaltsadressierung" verwenden, was bedeutet, dass der Hash jedes Datenelements direkt als Kennung für den Abruf dient. Während dieses Setup möglicherweise für einen Proof-of-Concept funktioniert, ist es für die Produktion nicht sinnvoll, da der Sinn einer Blockchain darin besteht, vertrauenswürdige Vermittler zu entfernen. Selbst wenn On-Chain-Hashes verhindern, dass der Vermittler Daten fälscht, können Daten aufgrund eines technischen Fehlers oder der Handlungen eines betrügerischen Mitarbeiters gelöscht oder an einige Teilnehmer nicht übermittelt werden.

Eine vielversprechendere Möglichkeit ist die Punkt-zu-Punkt-Kommunikation, bei der der Knoten, der einige Daten außerhalb der Kette benötigt, diese direkt von dem Knoten anfordert, der sie veröffentlicht hat. Dies vermeidet es, sich auf einen vertrauenswürdigen Vermittler zu verlassen, weist jedoch drei alternative Mängel auf:

Es erfordert eine Zuordnung von Blockchain-Adressen zu IP-Adressen, damit der Verbraucher einiger Daten direkt mit seinem Herausgeber kommunizieren kann. Blockchains können diese Art der statischen Netzwerkkonfiguration im Allgemeinen vermeiden, was ein Problem in Bezug auf Failover und Datenschutz darstellen kann.
Wenn der ursprüngliche Herausgeberknoten das Netzwerk verlassen hat oder vorübergehend außer Betrieb ist, können die Daten von niemand anderem abgerufen werden.
Wenn eine große Anzahl von Knoten an Daten interessiert ist, wird der Herausgeber von Anforderungen überfordert. Dies kann zu einer starken Überlastung des Netzwerks führen, das System des Herausgebers verlangsamen und zu langen Verzögerungen für diejenigen führen, die versuchen, diese Daten abzurufen.

Um diese Probleme zu vermeiden, verwenden wir idealerweise einen dezentralen Bereitstellungsmechanismus. Knoten sollten in der Lage sein, die benötigten Daten abzurufen, ohne sich auf ein einzelnes System verlassen zu müssen - sei es ein zentrales Repository oder der ursprüngliche Herausgeber der Daten. Wenn mehrere Parteien über Daten verfügen, sollten sie die Last der Übermittlung an alle anderen Personen teilen, die diese Daten wünschen. Niemand muss einer einzelnen Datenquelle vertrauen, da On-Chain-Hashes nachweisen können, dass Daten nicht manipuliert wurden. Wenn mir ein böswilliger Knoten die falschen Daten für einen Hash liefert, kann ich diese Daten einfach verwerfen und versuchen, jemanden zu fragen.

Für diejenigen, die Erfahrung mit haben Peer-to-Peer-Dateifreigabe Protokolle wie Napster, Gnutella oder BitTorrent werden alle sehr vertraut klingen. In der Tat sind viele der Grundprinzipien gleich, aber es gibt zwei wesentliche Unterschiede. Angenommen, wir verwenden unsere Blockchain in einem Unternehmenskontext, wird das System in einer geschlossenen Gruppe von Teilnehmern und nicht im gesamten Internet ausgeführt. Zweitens fügt die Blockchain ein dezentrales Backbone für Bestellung, Zeitstempelung und Notarisierung hinzu, das es allen Benutzern ermöglicht, eine nachweislich konsistente und manipulationssichere Ansicht darüber zu behalten, was genau wann und von wem passiert ist.

Wie kann ein Entwickler von Blockchain-Anwendungen diese dezentrale Bereitstellung von Inhalten außerhalb der Kette erreichen? Eine häufige Wahl ist die Verwendung einer vorhandenen Peer-to-Peer-Plattform für die gemeinsame Nutzung von Dateien, z. B. der amüsant benannten InterPlanetary File System (IPFS) und verwenden Sie es zusammen mit der Blockchain. Jeder Teilnehmer führt sowohl einen Blockchain-Knoten als auch einen IPFS-Knoten aus, wobei eine Middleware zwischen beiden koordiniert. Beim Veröffentlichen von Daten außerhalb der Kette speichert diese Middleware die Originaldaten in IPFS und erstellt dann eine Blockchain-Transaktion, die den Hash dieser Daten enthält. Um einige Daten außerhalb der Kette abzurufen, extrahiert die Middleware den Hash aus der Blockchain und verwendet diesen Hash, um den Inhalt aus IPFS abzurufen. Der lokale IPFS-Knoten überprüft den abgerufenen Inhalt automatisch anhand des Hashs, um sicherzustellen, dass er nicht geändert wurde.

Diese Lösung ist zwar möglich, aber alles ziemlich ungeschickt und unpraktisch. Zunächst muss jeder Teilnehmer drei separate Softwareteile (Blockchain-Knoten, IPFS-Knoten und Middleware) installieren, warten und aktualisieren, von denen jeder seine Daten an einem separaten Ort speichert. Zweitens wird es zwei separate Peer-to-Peer-Netzwerke mit jeweils eigener Konfiguration, Netzwerkports, Identitätssystem und Berechtigung geben (obwohl zu beachten ist, dass IPFS geschlossene Netzwerke noch nicht unterstützt). Schließlich würde eine enge Kopplung von IPFS und Blockchain die Middleware zunehmend komplexer machen. Wenn beispielsweise die Off-Chain-Daten, auf die von einigen Blockchain-Transaktionen verwiesen wird, sofort abgerufen werden sollen (mit automatischen Wiederholungsversuchen), muss die Middleware ständig betriebsbereit sein und ihren eigenen komplexen Status beibehalten. Wäre es nicht schön, wenn der Blockchain-Knoten dies alles für uns tun würde?

Off-Chain-Daten in MultiChain 2.0

Heute freuen wir uns, die dritte Vorschau-Version (Alpha 3) von MultiChain 2.0 mit einer vollständig integrierten und nahtlosen Lösung für Daten außerhalb der Kette. Jede in einem Stream veröffentlichte Information kann je nach Wunsch in der Kette oder außerhalb der Kette sein, und MultiChain kümmert sich um alles andere.

Nein wirklich, wir meinen alles. Als Entwickler, der auf MultiChain aufbaut, müssen Sie sich keine Gedanken über Hashes, lokalen Speicher, Inhaltserkennung, dezentrale Bereitstellung oder Datenüberprüfung machen. Folgendes passiert hinter den Kulissen:

Der veröffentlichende MultiChain-Knoten schreibt die neuen Daten in seinen lokalen Speicher und schneidet große Elemente in Stücke, um sie leicht zu verdauen und zu liefern.
Die Transaktion zum Veröffentlichen von Off-Chain-Stream-Elementen wird automatisch erstellt und enthält die Chunk-Hashs und die Größe (n) in Byte.
Diese Transaktion wird signiert und an das Netzwerk gesendet, wobei sie sich zwischen den Knoten ausbreitet und auf die übliche Weise in die Blockchain eingeht.
Wenn ein Knoten, der einen Stream abonniert hat, einen Verweis auf einige Daten außerhalb der Kette sieht, fügt er die Chunk-Hashes für diese Daten zu seiner Abrufwarteschlange hinzu. (Beim Abonnieren eines alten Streams stellt ein Knoten auch alle zuvor veröffentlichten Off-Chain-Elemente zum Abrufen in die Warteschlange.)
Wenn sich in der Abrufwarteschlange eines Knotens Chunks befinden, werden als Hintergrundprozess Abfragen an das Netzwerk gesendet, um diese Chunks zu lokalisieren, die durch ihre Hashes gekennzeichnet sind.
Diese Chunk-Abfragen werden auf Peer-to-Peer-Weise an andere Knoten im Netzwerk weitergegeben (derzeit auf zwei Hops beschränkt - siehe technische Details unten).
Jeder Knoten, der die Daten für einen Block enthält, kann antworten, und diese Antwort wird auf demselben Pfad wie die Abfrage an den Teilnehmer zurückgeleitet.
Wenn kein Knoten die Blockabfrage beantwortet, wird der Block zur späteren Wiederholung an die Warteschlange zurückgegeben.
Andernfalls wählt der Abonnent die vielversprechendste Quelle für einen Block (basierend auf Hops und Antwortzeit) und sendet ihm eine Anforderung für die Daten dieses Blocks, wiederum auf demselben Peer-to-Peer-Pfad wie die vorherige Antwort.
Der Quellknoten liefert die angeforderten Daten erneut über denselben Pfad.
Der Abonnent überprüft die Größe und den Hash der Daten anhand der ursprünglichen Anforderung.
Wenn alles ausgecheckt ist, schreibt der Abonnent die Daten in seinen lokalen Speicher und stellt sie sofort zum Abrufen über die Stream-APIs zur Verfügung.
Wenn der angeforderte Inhalt nicht eingetroffen ist oder nicht mit dem gewünschten Hash oder der gewünschten Größe übereinstimmt, wird der Block zum späteren Abrufen aus einer anderen Quelle in die Warteschlange zurückgeführt.

Am wichtigsten ist, dass dies alles sehr schnell geschieht. In Netzwerken mit geringer Latenz erreichen kleine Datenstücke außerhalb der Kette die Teilnehmer innerhalb von Sekundenbruchteilen nach der Transaktion, auf die sie verweisen. Und für Anwendungen mit hoher Last zeigen unsere Tests, dass MultiChain 2.0 alpha 3 eine Rate von über 1000 Off-Chain-Elementen oder 25 MB Off-Chain-Daten pro Sekunde auf einem Midrange-Server (Core i7) mit einem anständigen Wert aufrechterhalten kann Internetverbindung. Bei Off-Chain-Artikeln mit einer Größe von bis zu 1 GB funktioniert alles einwandfrei, weit über der 64-MB-Grenze für On-Chain-Daten. Wir hoffen natürlich, diese Zahlen weiter zu verbessern, da wir während der Beta-Phase Zeit damit verbringen, MultiChain 2.0 zu optimieren.

Wenn MultiChain-Anwendungsentwickler Daten außerhalb der Kette anstelle von Daten in der Kette in Streams verwenden, müssen sie genau zwei Dinge tun:

Übergeben Sie beim Veröffentlichen von Daten ein "Offchain" -Flag an die entsprechenden APIs.
Berücksichtigen Sie bei der Verwendung der Stream-Abfrage-APIs die Möglichkeit, dass einige Daten außerhalb der Kette möglicherweise noch nicht verfügbar sind, wie durch das Flag "Verfügbar" angezeigt. Während diese Situation unter normalen Umständen selten ist, ist es für Anwendungsentwickler wichtig, angemessen damit umzugehen.

Um zu verhindern, dass jeder Knoten jedes Element außerhalb der Kette abruft, sollten die Elemente in geeigneter Weise zu Streams zusammengefasst werden, wobei jeder Knoten diese Streams von Interesse abonniert.

On-Chain- und Off-Chain-Elemente können innerhalb desselben Streams verwendet werden, und die verschiedenen Stream-Abfrage- und Zusammenfassungsfunktionen beziehen sich identisch auf beide Datentypen. Auf diese Weise können Publisher für jedes Element in einem Stream die richtige Auswahl treffen, ohne den Rest einer Anwendung zu beeinträchtigen. Beispielsweise kann ein Stream von JSON-Elementen über die Aktivitäten von Personen Off-Chain-Daten zur persönlichen Identifizierung von Informationen und On-Chain-Daten für den Rest verwenden. Abonnenten können die JSON-Zusammenführung von MultiChain verwenden, um beide Arten von Informationen zum Lesen in einem einzigen JSON zu kombinieren.

Wenn Sie Stream-Elemente außerhalb der Kette ausprobieren möchten, folgen Sie einfach den Vorgaben von MultiChain Erste Schritte Tutorial, und überspringen Sie nicht Abschnitt 5.

Was kommt als nächstes?

Mit der nahtlosen Unterstützung von Daten außerhalb der Kette bietet MultiChain 2.0 einen großen Fortschritt für Blockchain-Anwendungen, die sich auf die Zeitstempelung und Beglaubigung von Daten in großem Maßstab konzentrieren. Langfristig denken wir bereits über eine Menge möglicher zukünftiger Verbesserungen dieser Funktion für die Community- und / oder Enterprise-Editionen von MultiChain nach:

Stream implementieren lesen Berechtigungen mit einer Kombination aus Off-Chain-Elementen, gesalzenen Hashes, signierten Chunk-Abfragen und verschlüsselter Zustellung.
Zulassen, dass Daten außerhalb der Kette explizit "vergessen" werden, sowohl freiwillig von einzelnen Knoten als auch von allen Knoten als Antwort auf eine Nachricht in der Kette.
Selektive Stream-Abonnements, bei denen Knoten nur die Daten für Off-Chain-Elemente mit bestimmten Herausgebern oder Schlüsseln abrufen.
Die richtigen merkle Bäume Damit kann ein einzelner On-Chain-Hash eine unbegrenzte Anzahl von Off-Chain-Elementen darstellen, was einen weiteren großen Sprung in Bezug auf die Skalierbarkeit bedeutet.
Steckbare Speicher-Engines, mit denen Daten außerhalb der Kette in Datenbanken oder externen Dateisystemen anstatt auf der lokalen Festplatte gespeichert werden können.
Knoten, die im Laufe der Zeit lernen, wo normalerweise jede Art von Daten außerhalb der Kette in einem Netzwerk verfügbar ist, und deren Blockabfragen entsprechend fokussieren.

Wir würden es lieben zu Hören Sie Ihr Feedback auf der obigen Liste sowie Artikel außerhalb der Kette im Allgemeinen. Da MultiChain 2.0 offiziell noch in Alpha ist, bleibt genügend Zeit, um diese Funktion vor der endgültigen Veröffentlichung zu verbessern.

In der Zwischenzeit haben wir bereits mit der Arbeit an „Smart Filters“ begonnen, der letzten wichtigen Funktion, die für die MultiChain 2.0 Community geplant ist. Ein intelligenter Filter ist ein in die Blockchain eingebetteter Code, der benutzerdefinierte Regeln zum Überprüfen von Daten oder Transaktionen implementiert. Intelligente Filter haben einige Ähnlichkeiten mit „intelligenten Verträgen“ und können viele der gleichen Aufgaben ausführen, weisen jedoch wesentliche Unterschiede in Bezug auf Sicherheit und Leistung auf. Wir freuen uns darauf, Ihnen zu gegebener Zeit mehr zu erzählen.

Bitte posten Sie Kommentare auf LinkedIn.

Technische Details

Off-Chain-Stream-Elemente in MultiChain 2.0 sind zwar einfach zu verwenden, enthalten jedoch viele Entwurfsentscheidungen und zusätzliche Funktionen, die von Interesse sein können. Die folgende Liste ist hauptsächlich für Entwickler relevant, die Blockchain-Anwendungen erstellen, und kann von weniger technischen Typen übersprungen werden:

Per-Stream-Richtlinien. Wenn ein MultiChain-Stream erstellt wird, kann er optional so eingeschränkt werden, dass nur Daten in der Kette oder außerhalb der Kette zugelassen werden. Es gibt mehrere mögliche Gründe dafür, anstatt dass jeder Verlag selbst entscheiden kann. On-Chain-Artikel bieten beispielsweise eine ironclad-Verfügbarkeitsgarantie, während alte Off-Chain-Artikel unwiederbringlich werden können, wenn ihr Herausgeber und andere Abonnenten das Netzwerk verlassen. Auf der anderen Seite können On-Chain-Artikel nicht „vergessen“ werden, ohne die Blockchain zu ändern, während Off-Chain-Artikel flexibler sind. Dies kann im Hinblick auf Datenschutzbestimmungen wie die neuen europäischen DSGVO-Bestimmungen wichtig sein.
On-Chain-Metadaten. Bei Artikeln außerhalb der Kette enthält die Transaktion in der Kette weiterhin den Herausgeber, den Schlüssel, das Format (JSON, Text oder Binär) und die Gesamtgröße des Artikels. All dies nimmt sehr wenig Platz ein und hilft Anwendungsentwicklern festzustellen, ob die Nichtverfügbarkeit eines Off-Chain-Elements für eine bestimmte Stream-Abfrage von Belang ist.
Zwei-Sprung-Limit. Bei der Weiterleitung von Blockabfragen über das Peer-to-Peer-Netzwerk besteht ein Kompromiss zwischen Erreichbarkeit und Leistung. Es wäre zwar schön, wenn jede Abfrage auf jedem einzelnen Pfad weitergegeben würde, dies kann jedoch das Netzwerk mit unnötigem „Geschwätz“ verstopfen. Daher sind Chunk-Abfragen derzeit auf zwei Hops beschränkt, was bedeutet, dass ein Knoten Daten außerhalb der Kette von jedem Peer seiner Peers abrufen kann. In den kleineren Netzwerken mit weniger als 1000 Knoten, die dazu neigen, Unternehmensblockchains zu charakterisieren, glauben wir, dass dies gut funktioniert, aber es ist für uns einfach, diese Einschränkung anzupassen (oder als Parameter anzubieten), wenn sich herausstellt, dass sie falsch ist.
Lokaler Speicher. Jeder MultiChain-Knoten speichert Daten außerhalb der Kette im Verzeichnis „Chunks“ seines regulären Blockchain-Verzeichnisses unter Verwendung eines effizienten Binärformats und eines LevelDB-Index. Ein separates Unterverzeichnis wird für die Elemente in jedem der abonnierten Streams sowie für die vom Knoten selbst veröffentlichten Elemente verwendet. In jedem dieser Unterverzeichnisse werden doppelte Chunks (mit demselben Hash) nur einmal gespeichert. Wenn sich ein Knoten von einem Stream abmeldet, kann er auswählen, ob die für diesen Stream abgerufenen Daten außerhalb der Kette gelöscht werden sollen oder nicht.
Binärer Cache. Beim Veröffentlichen großer binärer Daten, ob in der Kette oder außerhalb der Kette, ist es für Anwendungsentwickler möglicherweise nicht praktikabel, diese Daten in einer einzigen JSON-RPC-Anforderung an die MultiChain-API zu senden. Daher implementiert MultiChain 2.0 einen binären Cache, mit dem große Datenmengen über mehrere API-Aufrufe hinweg aufgebaut und in einem kurzen letzten Schritt veröffentlicht werden können. Jedes Element im Binärcache wird als einfache Datei im Unterverzeichnis „Cache“ des Blockchain-Verzeichnisses gespeichert, sodass Gigabyte an Daten auch direkt über das Dateisystem übertragen werden können.
APIs überwachen. MultiChain 2.0 alpha 3 fügt zwei neue APIs zur Überwachung des asynchronen Abrufs von Daten außerhalb der Kette hinzu. Die erste API beschreibt den aktuellen Status der Warteschlange und zeigt an, wie viele Blöcke (und wie viele Daten) warten oder abgefragt oder abgerufen werden. Die zweite API bietet aggregierte Statistiken für alle Chunk-Abfragen und -Anforderungen, die seit dem Start des Knotens gesendet wurden, einschließlich der Anzahl der verschiedenen Fehlertypen.
Bei Veröffentlichung spülen. Beim Veröffentlichen eines Off-Chain-Elements stellt MultiChain sicher, dass seine lokale Kopie der Daten vollständig auf das physische Laufwerk geschrieben (oder "gelöscht") wird, bevor die Transaktion, die auf diese Daten verweist, an das Netzwerk gesendet wird. Andernfalls könnten die Daten außerhalb der Kette dauerhaft verloren gehen, wenn der Knoten das Pech hatte, unmittelbar nach dem Senden der Transaktion die Stromversorgung zu verlieren. Dies ist für MultiChain selbst kein Problem, da die Verzögerungen zwischen den Abrufversuchen eines Chunks mit der Zeit automatisch zunehmen. Dies kann jedoch zu Problemen auf Anwendungsebene führen, bei denen jeder von der Existenz einiger Daten weiß, diese jedoch von niemandem gefunden werden können.
Veröffentlichungsleistung. Durch das Löschen von Daten außerhalb der Kette auf diese Weise auf die Festplatte kann MultiChain zu Leistungseinbußen führen, da physische Festplatten langsam sind. Beispielsweise kann eine Festplatte mit 7200 U / min im mittleren Bereich nur etwa 100 zufällige Datenschreibvorgänge pro Sekunde ausführen, wodurch wiederum die Rate begrenzt wird, mit der ein einzelner Knoten Elemente außerhalb der Kette veröffentlichen kann. Es gibt drei mögliche Problemumgehungen für dieses Problem. Erstens und am einfachsten können Knoten ein SSD-Laufwerk (Solid State Device) anstelle einer normalen Festplatte verwenden, die 10,000 zufällige Schreibvorgänge pro Sekunde unterstützt. Zweitens können mehrere Off-Chain-Elemente in einer einzigen Transaktion mithilfe der API "createrawsendfrom" veröffentlicht werden. In diesem Fall schreibt MultiChain alle Off-Chain-Daten, auf die von einer Transaktion verwiesen wird, in einer einzelnen Plattenoperation. Schließlich kann MultiChain so konfiguriert werden, dass Daten außerhalb der Kette nicht auf die Festplatte übertragen werden, bevor die Transaktion gesendet wird, die darauf verweist. Verwenden Sie diese Option mit Vorsicht.
Integration der einheimischen Währung. Für Anwendungsfälle, die dies erfordern, hat MultiChain immer die Option angeboten, eine native Währung in einer Blockchain zu verwenden, um Transaktions-Spam zu verhindern und / oder Blockvalidatoren („Miner“) zu motivieren. In diesen Fällen müssen Transaktionen Bergleuten eine Mindestgebühr anbieten, die proportional zu ihrer Größe in Bytes ist, um in der Kette weitergeleitet und bestätigt zu werden. Dieser Mechanismus wurde erweitert, um Spam außerhalb der Kette zu verhindern, indem eine zusätzliche Mindestgebühr pro Kilobyte Daten außerhalb der Kette verlangt wird, auf die in einer Transaktion verwiesen wird.
Archivknoten. Wenn ein Knoten jeden Stream abonnieren und daher jedes veröffentlichte Off-Chain-Element abrufen und speichern möchte, kann er mithilfe des Laufzeitparameters "autosubscribe" konfiguriert werden. Ein solcher Knoten fungiert als Backup für das gesamte Netzwerk und garantiert, dass nicht außerhalb der Kette liegende Elemente verloren gehen oder nicht verfügbar sind, unabhängig davon, welche anderen Knoten verschwinden. Man kann sich Drittunternehmen vorstellen, die dies als kommerziellen Service anbieten.