R-Chain-Blockchain-Plattform: Allgemeine Architektur und Evolution

Hallo an diejenigen, die die Entwicklung des Einsatzes dezentraler Plattformen in Unternehmens- und Inter-Corporate-Prozessen verfolgen. Unsere Veröffentlichungen zu diesem Thema wurden Anfang 2018 unterbrochen. Nein, die Raiffeisenbank hat nicht aufgehört, in diese Richtung zu arbeiten: Es ist an der Zeit, von methodischen Berechnungen und dem Kennenlernen der Fähigkeiten einzelner Technologien zur Implementierung spezifischer Geschäftsfälle in einem industriellen Umfeld oder so nah wie möglich daran überzugehen. Dieser Artikel ist sehr umfangreich und gleichzeitig informativ. Wir hoffen daher auf Ihre Beteiligung und warnen vor dem Tutorial-Format.











In den Jahren 2016-2017 haben wir eine Reihe von Forschungsprojekten zum Aufbau einer dezentralen Handelsfinanzierungsplattform abgeschlossen. Verwendete Test Ethereum (Rinkeby) als zugrunde liegende verteilte Hauptbuchplattform und Ethereum Swarm als dezentrales Filesharing-Tool. Neben allgemeinen Fragen zum Aufbau einer dezentralen Plattform haben wir die Möglichkeiten intelligenter Verträge, den Einsatz von Orakeln und intelligente Schiedsverträge getestet. Einige dieser Ergebnisse sind





Basierend auf diesen Forschungsprojekten,





Das Ergebnis dieser ziemlich langwierigen Arbeit war, wie das Militär sagt, die "Akzeptanz für die Lieferung" der IT Raiffeisenbank der regulären dezentralen R-Chain-Plattform. Es wird jetzt als Element des Kundenservice für Unternehmensgruppen unterschiedlicher Größe angeboten.



Wir teilen die Hauptmerkmale beim Aufbau dieser Plattform und sprechen auch über die Entwicklung der Verwendung verschiedener "technischer" Komponenten - Blockchain-Plattformen und verteilte Dateisysteme.

Inhalt

• Merkmale von Unternehmens- und Inter-Corporate-Systemen
• Allgemeine Plattformarchitektur
  
  
  • Architektur von Softwarekomponenten
  • Geschäftsprozess aus einer Hand
  • Vorteile der Verwendung eines Geschäftsprozesses aus einer Hand
  • Nachteile der Verwendung eines generischen Geschäftsprozesses
  • Host-Netzwerküberwachung
• Entwicklung der Verwendung verschiedener technischer Komponenten
• Erfahrung in Forschung und Betrieb von Unternehmensplattformen und deren Weiterentwicklung

Merkmale von Unternehmens- und Inter-Corporate-Systemen

Damit die Implementierung der Plattform in den industriellen Betrieb reibungslos und ohne für Entwickler unerwartete Exzesse verläuft, muss verstanden werden, dass die dem zukünftigen Teilnehmer vorgeschlagene Plattform die folgenden Anforderungen erfüllen muss:

• Die Plattform muss einen Betreiber haben - eine juristische Person, die gegenüber den Teilnehmern für ihre Funktionsweise verantwortlich ist. Die Option - jeder für sich, alles wird durch den Konsens der Teilnehmer entschieden, und so weiter, typisch für öffentliche Blockchain-Plattformen, wird hier nicht funktionieren.
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

Viele in dieser Liste werden überrascht sein, dass die Wörter "Transaktionen pro Sekunde" und andere Leistungsbewertungen fehlen. Unsere Erfahrung zeigt, dass Produktivität nicht die wichtigste Voraussetzung für eine erfolgreiche Plattformimplementierung ist. Die Leistung muss nur "ausreichend" sein, und es gibt viele Datenflussarchitekturen, die den Durchsatz der zugrunde liegenden Plattform drastisch erhöhen können - von Datenregistern bis zu seitlichen Turbo-Streams. Die Wahrscheinlichkeit, dass Ihr Projekt aufgrund der Unaufmerksamkeit gegenüber den oben genannten Punkten stirbt, ist hyperbolisch höher.

Allgemeine Plattformarchitektur

Architektur von Softwarekomponenten

Die Anwendungen, die wir in unseren Forschungsprojekten 2016-2017 verwendet haben, wurden auf der Grundlage der direkten Integration von Dialogschnittstellen mit den "technischen" Komponenten der verteilten Plattform - geth und swarm - geschrieben. Nachdem wir jedoch die Möglichkeiten und Konsequenzen dieses Ansatzes analysiert hatten, kamen wir zu dem Schluss, dass es notwendig ist, eine weitere Schicht zwischen dem Business-Backend und den "technischen" Komponenten einzuführen - einen Adapter für einheitliche Geschäftsobjekte. Diese Technik gehört zu ziemlich Standardmustern für die Erstellung von Softwarearchitekturen, die jedoch ihre Effektivität nicht beeinträchtigen. Infolgedessen sah die Softwarearchitektur des Knotens unserer Plattform ungefähr so ​​aus:







In dieser Architektur die Geschäftsanwendungfunktioniert nicht direkt mit Abstraktionen von DLT-Komponenten, sondern mit einem bestimmten bedingten "universellen Geschäftsprozess" (im Folgenden als Prozess bezeichnet) - es erstellt einen Prozess, ändert den Status des Prozesses. Die Reduzierung der Datenstruktur des universellen Prozesses und seiner Operationen auf die im DLT-Client verwendeten Daten und Operationen wird durch eine Reihe von Komponenten ausgeführt, die als "Spiegel der Geschäftsprozesse" bezeichnet werden. Der "Spiegel" führt auch die umgekehrte Transformation der vom DLT-Client empfangenen Informationen durch und filtert Informationen nach Prozessen, die nicht mit dem Teilnehmer - dem Eigentümer des Knotens - zusammenhängen. Somit wird auf jedem Knoten eine Datenbank von Geschäftsprozessen, an denen dieser Knoten beteiligt ist, in einem synchronen Zustand und im bequemsten Format für eine Geschäftsanwendung gehalten . Geschäftsanwendunginteragiert mit dieser Datenbank - einer Datenbank mit Geschäftsprozessen, die Informationen über den Status von Prozessen empfängt und Vorgänge überträgt, um diese Status zu ändern.

Geschäftsprozess aus einer Hand

Es stellte sich natürlich die Frage, welche Eigenschaften mit einem universellen Geschäftsprozess ausgestattet werden sollten, um einerseits die Vorteile der Blockchain-Plattformen maximal zu nutzen und andererseits maximale Flexibilität und Funktionalität für die Verwendung in einer Geschäftsanwendung. Eine zusätzliche Bedingung war die Fähigkeit, die ausgewählten Eigenschaften auf den meisten gängigen DLT-Plattformen zu implementieren, deren Funktionalität sich in einigen Aspekten erheblich unterscheidet (Ethereum / Quorum / Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Basierend auf den Erfahrungen unserer eigenen und der Projekte anderer kamen wir zu den folgenden Schlussfolgerungen.



Ein universeller Geschäftsprozess sollte die folgenden Attribute aufweisen:

• Prozessparameter (Prozesstyp, Status, Kontextattribute des Prozesses)
• Rollenliste der Prozessteilnehmer
• Liste der prozessbezogenen elektronischen Dokumente
• Prozessübergangskarte

Gleichzeitig muss die Plattform auf der Ebene der Blockchain-Komponenten die folgenden Bedingungen für die Weitergabe des Prozesses im Netzwerk bereitstellen:

• Vollständigkeit und Integrität der Informationen
• Vertraulichkeit elektronischer Dokumente außerhalb des Teilnehmerkreises
• Kontrolle der Verfolgung der Prozessübergangskarte
• Speichern des Verlaufs von Änderungen in Prozesszuständen

Um diese Funktionen zu implementieren, wurden intelligente Rahmenverträge mit den entsprechenden Eigenschaften und Methoden entwickelt.



Lassen Sie uns auf einige der aufgelisteten Attribute und Bedingungen eingehen - was, wie und warum.



Prozessparameter- sind bedingt offen, da sie direkt über einen intelligenten Vertrag übertragen werden. Für einige Blockchain-Plattformen sind sie grundsätzlich öffentlich (Ethereum / Masterchain), für andere können sie durch Standardverfahren zur Gewährleistung des Datenschutzes geschlossen werden (Quorum - Private Smart Contracts, Hyperledger Fabric - Kanäle und private Daten). Der wahrscheinlich wichtigste Parameter des „Kerns“ des Prozesses in unserer Implementierung ist der „Prozesstyp“, da er nicht nur eine semantische, sondern auch eine funktionale Last trägt. Abhängig vom „Prozesstyp“ wählt der DLT-Adapter eine intelligente Vertragsvorlage für diesen Prozess Stelle dich vor. Warum wird das benötigt? Offensichtlich gibt es unzählige Arten von Transaktionen und dieselben unterschiedlichen Geschäftsprozesse, die deren Implementierung sicherstellen.In einer relativ großen Anzahl von Fällen unterscheiden sich Geschäftsprozesse im Wesentlichen nur in der Übergangskarte (aus Sicht der Plattform) und können mit einem einzigen intelligenten Vertrag implementiert werden, der eine beliebige Übergangskarte unterstützt (mehr dazu weiter unten). Mit einem bestimmten Geschäftsprozess können jedoch ganz besondere Momente verbunden sein:

• (, )
• (, )
• (, )

Der Versuch, all diese potenzielle Vielfalt zu formalisieren, zu "formatieren" und in einer einzigen Vorlage für intelligente Verträge zusammenzufassen, ist absolut utopisch. Die Entwicklung einer eindeutigen Vorlage für eine bestimmte Art von Geschäftsprozess ist viel effizienter und bietet sowohl eine hohe Flexibilität als auch die Möglichkeit, die erforderlichen Prozesselemente und kritischen Überprüfungen direkt in den „Kern“ der Blockchain-Komponente zu „flashen“. Dies schließt jegliche Manipulationsmöglichkeit durch einzelne Teilnehmer aus. Darüber hinaus wird die gesamte Plattform die Vereinheitlichung von Schnittstellen für die Interaktion von Geschäftsanwendungen mit Prozessen und eine hohe Modularität bei der Implementierung ihrer spezifischen Funktionen kombinieren.



Zu den "Kernel-Attributen" unseres Prozesses gehören auch "Status" und "Hinweis": Die erste ist eine kurze Beschreibung des Prozessstatus ("Neu", "Abgebrochen", "Geschlossen", "OnApproval"), die zweite ist eine "lange" Zeichenfolge mit eine detailliertere Beschreibung zum "Status". Wir beschränken die Länge einer Notiz auf etwa 1000 Zeichen (z. B. "Unzureichendes Guthaben auf dem Konto"), da dem Prozess beigefügte elektronische Dokumente erhebliche Mengen an Informationen übertragen sollen (insbesondere vertraulich).



Prozessübergangskarte- beschreibt, ob ein Teilnehmer mit einer bestimmten Rolle den Status des Prozesses ändern kann und zu welchem. Die Kontrolle über die Zulässigkeit von Übergängen erfolgt durch den "Kern" der Blockchain-Komponente und kann von einem "machtlosen" Teilnehmer nicht gefälscht werden. Darüber hinaus kann die Navigationskarte beispielsweise von einer Geschäftsanwendung verwendet werden, um die möglichen Aktionen des Knotenbesitzers im aktuellen Status des Prozesses für die entsprechende Verwaltung von Dialogkomponenten zu ermitteln.



Übertragung vertraulicher Daten.Zur Übertragung vertraulicher Informationen werden elektronische Dokumente verwendet, die dem Prozess beigefügt sind. Die Geschäftsanwendung lädt die erforderlichen Dokumente in den lokalen Dateispeicher "Mirrors" hoch und zeigt sie im Vorgang an, um den Status des Prozesses zu ändern. Vor der Übertragung vom lokalen Speicher zum DFS wird das Dokument mit den öffentlichen Schlüsseln der Empfängerknoten - Teilnehmer am Prozess - verschlüsselt. Nachdem der generierte Kryptocontainer an DFS übertragen wurde, werden die Verknüpfung mit ihm und der Hash des Originaldokuments in den Smart Contract des Prozesses übertragen. Nach Erhalt von Informationen über eine Änderung des Prozessstatus werden die Dateidetails in die Geschäftsprozessdatenbank abgerufen, und dann wird der Kryptocontainer über die Verknüpfung aus der DFS extrahiert und mit dem Schlüssel des empfangenden Knotens entschlüsselt. Es wird überprüft, ob die Hash-Summe des im Smart-Vertrag des Prozesses angegebenen Dokuments übereinstimmt.Das Dokument wird im lokalen Dateispeicher abgelegt und steht für die Geschäftsanwendung zur Verfügung. Daher funktioniert die Geschäftsanwendung nur mit der "offenen" Version des Dokuments - alle Sorgen um die sichere Übertragung werden vom "Spiegel" übernommen.



Der Verlauf der Prozesszustandsänderung ist eine Folge von "Rahmen", von denen jeder einer Operation der Prozesszustandsänderung entspricht. In unserer Implementierung speichern wir die folgenden Daten für jeden "Rahmen" der Geschichte:

• Status
• Hinweis
• die Kennung des Initiators der Statusänderungstransaktion

Der Änderungsverlauf wird auf der Ebene eines intelligenten Vertrags aufgezeichnet und ermöglicht nicht nur die Verfolgung der Abfolge von Übergängen zu Prüfungszwecken, sondern ermöglicht es der Geschäftsanwendung auch, die Ereigniskette auch bei gleichzeitigem Eintreffen (z. B. Einfrieren, Funktionsunterbrechung usw.) korrekt zu verarbeiten.



Rechtliche Bedeutung sicherstellen- ein sehr wichtiges Thema, das wir im Abschnitt "Merkmale von Unternehmens- und Inter-Corporate-Systemen" erwähnt haben. Wir gingen zunächst von dem Konzept aus, dass rechtliche Bedeutung nicht durch eine Blockchain-Plattform bereitgestellt werden sollte, sondern durch die Verwendung einer externen PKI, die regulatorische Unterstützung oder ein angemessenes Maß an Vertrauen unter den Plattformteilnehmern bietet. Grob gesagt muss ein elektronisches Dokument, das eine Rechtsgrundlage für Ihre Handlungen darstellt (Zahlungsdokument, Vertrag, Nachfrage usw.) und dem Prozess beigefügt ist, auf der Grundlage einer "koscheren" PKI (in Russland - GOST, beispielsweise irgendwo im Ausland) unterzeichnet werden SSL oder PGP / GPG). Die Branchenanwendung überprüft die "externe" Signatur und ergreift die entsprechenden Maßnahmen. Oder auch nicht, je nach Ergebnis. Jemand wird sagendass dies nicht "evangelisch" ist und "wir Anwälte von der rechtlichen Bedeutung von Blockchain-Transaktionen überzeugen müssen". Wir haben viele Schritte dieser Reise durchlaufen und das Ergebnis war immer das gleiche. Im Fall von Russland jedochDie Masterchain-Zertifizierung eröffnet in dieser Hinsicht bestimmte Möglichkeiten - wie sie sagen: "Viel Spaß beim Jagen!"

Vorteile der Verwendung eines Geschäftsprozesses aus einer Hand

Was hat uns dieser Ansatz am Ende gebracht?

• Erweiterung des Kreises potenzieller Entwickler dezentraler Geschäftsanwendungen. «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

Hier, wahrscheinlich, wie es in einem berühmten Lied gesungen wird - "Hinter ihnen hört man ein Murmeln ..." -, zum Beispiel, dass der Hyperledger Fabric- oder Corda-Kettencode im Gegensatz zu der etwas zu eleganten Solidity es Ihnen ermöglicht, eine nahezu unendlich komplexe Logik von Geschäftsprozessen zu implementieren, und Dieser Ansatz entweiht ihre Funktionalität. Nun ja, sie werden absolut richtig sein. Zu den murmelnden möchte ich Sie an einige bekannte Botschaften aus dem Bereich der Softwareentwicklung erinnern:

• Wo soll Geschäftslogik abgelegt werden - in den gespeicherten Prozeduren der Datenbank oder im Code von Geschäftsanwendungen?
• Was ist besser - ein Mainframe oder ein spezieller Computer?
• Sind Sie sicher, dass die von Ihnen gewählte Basislinie die Kompatibilität mit zukünftigen Lebensaktualisierungen gewährleistet? Und im Allgemeinen, wird es die nächsten 2 Jahre überleben?

Die Antwort ist einfach genug, wenn:

• Sie haben viel Geld, Zeit und kostenlose Blockchain-Spezialisten
• Sie sind sicher, dass die von Ihnen gewählte Blockchain-Basis nicht vom Wort "nie" geändert werden muss.
• Sie müssen die Funktionen der Plattform wirklich um 101% "einschränken".

Na dann - ein spezieller Taschenrechner ... im Sinne von Hyperledger Fabric oder Corda mit Nähten auf dem Cheyncode und anderem "Meißelschneiden in Stein". Wenn nicht, denken Sie selbst ...

Host-Netzwerküberwachung

Für einige ist es vielleicht eine Offenbarung, aber eine gut organisierte Überwachung ist die Grundlage für den erfolgreichen Betrieb von Softwaresystemen in einem Unternehmen. Und dieses Konzept umfasst nicht nur (und sogar nicht so sehr) die Standardüberwachung der Infrastruktur von Servern, sondern auch die Funktionsüberwachung von Softwarekomponenten. Ihre verteilte Plattform sollte nicht nur korrekt funktionieren, sondern auch Fehler machen und dem Support-Service eine ausreichende Menge an vernünftigen Informationen zur Verfügung stellen, mit denen Sie einen Fehler schnell identifizieren, identifizieren und beheben können. Es ist sogar noch besser, wenn das Überwachungssystem über proaktive Funktionen verfügt - es ermöglicht Ihnen, potenzielle "schlechte Dinge" zu identifizieren und ihre möglichen Konsequenzen zu blockieren, bevor "passiert" ist.



Wenn Sie zu jedem Zeitpunkt nicht verstehen, in welchem ​​Zustand sich die Knoten Ihres Netzwerks befinden und was auf ihnen geschieht, aber "gemäß den Signalen der Benutzer" arbeiten, ist es besser, sofort Speicherplatz in der Warteschlange freizugeben und sich nicht die Zeit lieber Kunden zu nehmen.



Auf dieser Grundlage wurde von Beginn der Entwicklung unserer Plattform an ein proaktives Überwachungssystem eingebaut. Beschreiben wir das Funktionsprinzip:

• In der Blockchain-Basis der Plattform wird ein spezieller Smart-Vertrag eingerichtet, der für die Erfassung und Verteilung von Überwachungsdaten verantwortlich ist (der Kürze halber werden wir diesen Smart-Vertrag als SCM bezeichnen).
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  > Prüfpfad von Geschäftsanwendungen

Bei einem bestimmten Wert oder einer Kombination von Werten für die Überwachung von Indikatoren unterbricht Mirror automatisch die Verarbeitung seiner Operationswarteschlangen und blockiert das Auftreten potenzieller unerwünschter Konsequenzen, z. B.:

• Im Falle einer kritischen Verzögerung in der Steuerbezeichnung des Blockchain-Kanals, die als Knotenausfall aus dem Blockchain-Netzwerk oder als vollständige Funktionsstörung interpretiert wird
• Im Falle einer kritischen Verzögerung im Steueretikett des DFS-Kanals, die als Verlust eines Knotens aus dem DFS-Netzwerk oder als vollständige Funktionsstörung interpretiert wird
• Bei Fehlern in der Operationswarteschlange werden alle nachfolgenden Operationen, die diesem Geschäftsobjekt zugeordnet sind (universeller Geschäftsprozess), blockiert

Besonderes Augenmerk wurde auf die Behandlung von Datenbankfehlern gelegt, die vom "Spiegel" verwendet werden. Diese Datenbank wird nicht nur als Schnittstelle zu Geschäftsanwendungen verwendet, sondern auch als Statusstapel für die Zustandsmaschine der Operationswarteschlangen "Spiegeln". Die Erfahrung hat gezeigt, dass bei Vorhandensein bestimmter Fehler beim Ändern von Daten in den Datenbanktabellen Schleifenoperationen mit massivem erneuten Senden von Transaktionen und anderen Freuden auftreten können. Aufgrund eines ähnlichen Fehlers haben wir einmal in zwei Tagen ein halbjährliches Volumen der Kette auf Quorum „erstellt“. Wenn daher ein Fehler dieser Art festgestellt wird, wird der "Spiegel" vollständig ausgeschaltet und wartet auf eine manuelle Antwort des Supportdienstes.



Die zentralen Überwachungsknoten extrahieren Informationen von allen Netzwerkknoten (übrigens auch von sich selbst) aus dem SCM und analysieren sie, sodass gefährliche oder potenziell gefährliche Zustände wie beispielsweise rechtzeitig erkannt werden können:

• - DFS-
• - DFS-
• -
• «»
• «»

Das folgende Bild zeigt ein Beispiel eines einfachen Monitors für eines unserer Testnetzwerke: Es wurden







mehr proaktive Überwachungsschemata der "oberen Ebene" entwickelt und implementiert, einschließlich Geschäftsanwendungen, aber hier kommen wir an die wackelige Grenze des geistigen Eigentums bestimmter Kunden.



Verbergen wir nicht die Tatsache, dass in einigen unserer Blockchain-Netzwerke die Überwachung des Datenverkehrs die überwiegende Mehrheit des gesamten Datenverkehrs ausmacht. In diesem Zusammenhang gab es sogar Überlegungen, einen variablen Zeitplan für die Häufigkeit von "Sondierungspaketen" zu verwenden - häufiger während der Arbeitszeit, seltener außerhalb der Arbeitszeit. Aber das ist es wert. Ja wirklich.



Überwachen Sie im Allgemeinen alles, was Sie sich vorstellen können, solange Ihre dezentrale Netzwerkbandbreite dies zulässt. Sie werden mehr als ein- oder zweimal die Götter der Programmierung und natürlich die Autoren dieses Artikels loben :)



Denn wie eine der Interpretationen von Murphys Gesetz sagt: "Der Fehler liegt normalerweise in einer Position, an der niemand zweifelt."

Entwicklung der Verwendung verschiedener technischer Komponenten

Nachdem wir die allgemeinen Bedingungen für die Bereitstellung und den Betrieb von dezentralen Unternehmensnetzwerken sowie die Architekturprinzipien, die wir beim Aufbau der R-Chain-Plattform verwendet haben, berücksichtigt haben, wenden wir uns nun der Geschichte zu, wie und warum sich die einzelnen technischen Komponenten bei der Implementierung spezifischer Projekte entwickelt haben.



Das erste war das Projekt der Ausstellung einer internationalen Garantie , bei der unsere Partner von März bis Dezember 2018 Kollegen aus Weißrussland waren.



Wir haben mit der Konfiguration Ethereum - Ethereum Swarm - Crypto-Pro (DLT-DFS-Kryptographie) begonnen, die sich in Forschungsprojekten bewährt hat. Anstelle des verwendeten öffentlichen PoA-Testnetzwerks von Ethereum Rinkeby wurden das private Netzwerk von Ethereum PoA und das private Netzwerk von Ethereum Swarm erhöht. Anfangs traten keine technischen Probleme auf, aber wir hatten ein "kryptografisches" Problem - einer der belarussischen Teilnehmer lehnte es rundweg ab, die von uns angebotenen Kryptografietools zu verwenden, und verwies dabei auf das lokale Gesetz zur Verwaltung elektronischer Dokumente. Zu dieser Zeit war es "im Moment" nicht möglich, eine qualitativ hochwertige Lösung zu finden, aber es gab ein stetiges Verständnis für die schwierige und wichtige Rolle der Kryptographie für den Erfolg internationaler Projekte.



Bereits beim Ausführen von Steuertransaktionen in der realen Netzwerkinfrastruktur (jeder Teilnehmer hat einen Knoten in seinen Ressourcen bereitgestellt) wurden Fehler in der Arbeit von Ethereum Swarm festgestellt - die Dateiverluste lagen bei 20%. Es wurde vermutet, dass der Verlust auf Probleme im Swarm-Client zurückzuführen ist, wenn mehrere Dateien gleichzeitig gesendet werden. Im Allgemeinen wurde diese Annahme bestätigt: Experimentell gelang es uns, eine Pause zwischen dem Senden einzelner Dateien an Swarm in 5 Sekunden zu finden. Während des Übergangs zu einer vollständig bekämpften Netzwerkkonfiguration, die aufgrund der Besonderheiten der in der Raiffeisenbank-Infrastruktur angewendeten Netzwerksegmentierung die Erstellung eines Transit-Swarm-Knotens erforderte, trat ein kritisches Problem auf: Mit Ethereum Swarm konnten bis zu 30% der Dateien beim Durcharbeiten eines Transit-Knotens verloren gehen.Die "geschichtete" Architektur und das gute Überwachungssystem ermöglichten es, die eigentliche Garantie im "manuellen Gaspumpen" -Modus erfolgreich durchzuführen, aber das Schicksal von Ethereum Swarm war besiegelt. Ich muss sagen, dass die erklärte Fähigkeit von Ethereum Swarm, in Topologien ohne direkte Sender-Empfänger-Verbindung zu arbeiten, einer der Hauptgründe für die Wahl als technologische Basis für DFS war und die Unfähigkeit, in diesem Modus zuverlässig zu arbeiten, viele Probleme verursachte.und seine Unfähigkeit, in diesem Modus zuverlässig zu arbeiten, verursachte viele Probleme.und seine Unfähigkeit, in diesem Modus zuverlässig zu arbeiten, verursachte viele Probleme.



Es sei darauf hingewiesen, dass das auf Ethereum basierende private Netzwerk in diesem Projekt mit seiner Wiederherstellbarkeit zufrieden ist. Der Projektplan ging davon aus, dass der Abschluss der ausgestellten Garantie 3 Monate nach ihrer Ausstellung erfolgen würde, und während dieser Pause stoppten einige der Teilnehmer ihre Knoten. Nach dem Neustart des Netzwerks ohne Tänze mit Tamburinen innerhalb eines Tages stellte es jedoch seine Integrität wieder her, und der Vorgang des Schließens der Garantie verlief ohne Beschwerden.



Das nächste Projekt war die Schaffung eines gruppeninternen Netzwerks für die Ascona-Unternehmensgruppe - September 2018 - aktuelle Zeit.



Basierend auf den Erfahrungen des internationalen Garantieprojekts wurde IPFS (InterPlanetary File System) als technologische Grundlage für DFS ausgewählt. Es funktionierte gut für das parallele Senden von Dateien und erforderte keine speziellen Modusanpassungen. Möglicherweise ist die einzige Schwachstelle von IPFS die Unmöglichkeit (angegeben!), In "Transit" -Topologien zu arbeiten. Beim Aufbau von Netzwerken mit einer großen Anzahl von Teilnehmern ist die Implementierung eines "vollständigen Sterns" des Zugriffs von jedem auf jeden von ihnen, gelinde gesagt, ein organisatorisches Problem. Andererseits implementieren alle Teilnehmer den Zugriff zwischen sich und den "Unterstützungs" -Knoten des Bedieners. Um die reibungslose Verteilung von Dateien zu organisieren, wurde der folgende Mechanismus implementiert:

• Wenn eine Datei an einen Smart-Vertrag eines bestimmten Geschäftsprozesses angehängt wird, wird das DeliveryFile-Ereignis generiert, das einen Link zur Datei enthält
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

Daher wurde das Ascona-Projekt in der Konfiguration Ethereum - IPFS - Crypto-Pro gestartet.



Die Verwendung von Crypto-Pro zum Verschlüsseln von Dateien und "externen" Signaturen von rechtsrelevanten Dokumenten stellte die Einfachheit der rechtlichen Bindung sowie das Fehlen von Ansprüchen der Abteilungen für Informationssicherheit sicher, was sich wiederum äußerst positiv auf den Zeitpunkt auswirkte, an dem die erforderlichen Genehmigungen sowohl von der Bank als auch von der Bank eingeholt wurden Parteien der Unternehmen der Ascona-Unternehmensgruppe. Im Allgemeinen entwickelte sich das Projekt in einem funktionierenden Zustand und nachdem es die Pilotphase bestanden hatte, war es am Ziel, zur Produktion zu gehen und hier ...



... und hier in zwei Projekten gleichzeitig - bedingt "fremd", aber an denen wir als Experten teilgenommen haben, haben wir bei ähnlichen Konfigurationen Mega-Gabeln von Tausenden von Blöcken gefangen, mit dem Verlust von Transaktionen eines Teils des Netzwerks. Die Analyse der Protokolle und Interpretationen der Blockchain-Community führte zu einer enttäuschenden Schlussfolgerung: Die Verwendung von Ethereum PoA (und in einigen Fällen sogar PoW) in kompakten Netzwerken mit einer kleinen Anzahl von Knoten (und Unternehmensnetzwerke gehören genau hierher) birgt ein hohes Risiko für solche Monster. Darüber hinaus trat in unserem Testnetzwerk regelmäßig ein mysteriöser Fehler auf, als ein Knoten aus dem Netzwerk ausfiel und nicht mehr mit ihm synchronisieren wollte. Auch nach der Neuinstallation von Ethereum und dem vollständigen Entfernen. Kurz gesagt, es wurde klar, dass das Produktnetzwerk eine Alternative zur Blockchain-Basis benötigt. Und schnell. Sehr schnell.



Die Lösung stellte sich als Quorum heraus - praktisch der Bruder von Ethereum. Die Anzahl der Verbesserungen im "Spiegel" war minimal, die Geschäftsanwendung erforderte natürlich überhaupt keine Verbesserungen.



Im Moment hat der Übergang zum Kollegium nur Vorteile gebracht:

• Der verwendete Floßkonsens eliminiert Gabeln
• Das Fehlen leerer Blöcke verringert die Größe der Kette

Das Fehlen von Gabeln ermöglicht es uns, auf eine Pause zu verzichten, während wir auf den bedingten Abschluss von Transaktionen warten, der zuvor erforderlich war, um einen möglichen Rollback von Transaktionen nicht zu bewältigen, und wir hatten bis zu 6 Blockgenerierungszyklen. Dies erhöht zum einen natürlich die Leistung der Plattform und zum anderen beseitigt es sehr schwierige Probleme, die auftreten, wenn die Gabel die berechnete Pause überschritten hat und der Status der "gespiegelten" Geschäftsobjekte, die sie berührt, nicht mehr ihrem Blockchain-Status entspricht.



Das einzige, vielleicht unangenehme Merkmal von Quorum ist die Möglichkeit, beim Neustart nach einer langen Pause einen Mega-Block mit einer Größe von mehreren Megabyte zu generieren, der den DLT-Adapter beim Versuch, seinen Inhalt zu entladen, einfach blockiert. Aber genau genommen sollte der Service Desk nicht so lange schlafen.



Als Ergebnis all dieser dramatischen Entwicklung kamen wir zur Quorum - IPFS - Crypto-PRO- Konfiguration , die wir jetzt auf dem russischen Inlandsmarkt verwenden.



Vielleicht stellt jemand eine logische Frage: "Nun, Sie haben noch nie von Quorum gehört, oder was?"... Wir haben von Quorum, Hyperledger Fabric und EOS gehört. Der Autor dieses Artikels nahm im Herbst 2017 sogar am ersten Corda-Workshop auf Russisch teil. Wahrscheinlich hat Hegel speziell für eine kluge Antwort auf solche Fragen seine Dialektik erfunden. Das kleine Team, das 2016 mit der Forschung begann, hatte gute Erfahrungen mit der Entwicklung interaktiver Anwendungen für Windows, und das öffentliche Ethereum (Test 1 ist verständlich) hatte die niedrigste Eintrittsschwelle für Blockchain-Plattformen. Und da wir daran interessiert waren, speziell zum Thema Blockchain zu forschen und nicht an verschiedenen Dockern zu basteln, ohne die es einfach unrealistisch ist, "Adult" Quorum oder Hyperledger Fabric (und nicht auf allen virtuellen Windows-Plattformen) zu starten, ist die Wahl möglich war offensichtlich. Als die Forschungsergebnisse die Aufmerksamkeit der Geschäftsbereiche der Bank und ihrer Partner auf sich zogen,Es gab die Möglichkeit, das Team zu erweitern, Schuhmachern Stiefel anzuvertrauen und Kuchen zu backen, Linux-Server zu beschaffen und so weiter. Und natürlich hat niemand die entwickelten Lösungen weggeworfen, solange sie ihr Entwicklungspotential behalten haben. Dialektik und Evolution.

Erfahrung in Forschung und Betrieb von Unternehmensplattformen und deren Weiterentwicklung

Der Autor dieses Artikels nahm an einer relativ großen Anzahl von Blockchain-Projekten teil, die bei der Raiffeisenbank, in der FinTech Association und an einigen anderen Orten durchgeführt wurden - sowohl als Entwickler als auch als Experte für dezentrale Plattformen. Einige von ihnen waren reine Forschungsprojekte, andere endeten als Piloten, andere entwickelten sich zu ziemlich großen industriellen Netzwerken mit mehreren Dutzend Knoten.



Was sind die wichtigsten Schlussfolgerungen, die aus all diesen Erfahrungen gezogen werden können?



1. Es gibt eine bestimmte Vielfalt von Blockchain-Plattformen, die sich in ihren "Verbraucher" -Eigenschaften sehr unterscheiden:

• "Eintrittsschwelle" und einfache Netzwerkbereitstellung
• Bandbreite
• Funktionalität von intelligenten Verträgen
• Optionen zum Schließen von Informationen
• Entwicklungszeit und -kosten

Daher denke ich, dass es unmöglich ist zu sagen, dass sich eine der Plattformen als absolut dominant herausstellen wird. Jedes hat seinen eigenen Kreis potenzieller Benutzer und Aufgaben, in denen seine Verwendung am rationalsten und kostengünstigsten ist. Dies gilt für Ethereum, Quorum, Hyperledger Fabric und Corda. Hier, wie bei Programmiersprachen, werden nur Vasya und Petya, die jeweils eine Sprache kennen, bis zu dem Punkt der Dummheit streiten, über den es besser ist - "Pluspunkte" oder "Kröte". Und Semyon Petrovich und Albert Ivanovich, die ein Dutzend von ihnen kennen, werden friedlich sprechen - wenn "Pluspunkte" besser sind und wann - "Kröte".



2. Trotz der Tatsache, dass einige der DLT-Plattformen (z. B. Hyperledger Fabric und Corda) die Möglichkeit bieten, große Datenelemente zu übertragen, bleiben Dateien, wahrscheinlich die Blockchain-Basis mit intelligenten Vertragsmechanismen und die Dateiübertragungsfunktionalität, getrennt. Dies ist auf folgende Punkte zurückzuführen:

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

3. Derzeit besteht ein chronischer Mangel an Spezialisten für technische Supportleistungen für dezentrale Plattformen. Genauer gesagt existieren sie einfach nicht. Absolut. In den meisten mir bekannten Projekten wird der Löwenanteil der technischen Supportarbeit von den Entwicklern oder Forschungsingenieuren geleistet, die diese Plattformen erstellt haben, was natürlich nicht gut ist. Ich denke, dies liegt an der Jugend der Leitung, und nach und nach werden technische Anweisungen, Reaktionsvorlagen, Überwachungsschemata und andere methodische Materialien entwickelt, die für die Organisation der effizienten Arbeit des Unterstützungsdienstes erforderlich sind. Eines der Probleme hierbei ist das Fehlen guter Übersichtskurse in Russisch auf bestimmten Blockchain-Plattformen. Alles muss von Hand zu Hand weitergegeben werden. Ein Support-Spezialist in einem Unternehmen ist jedoch kein Entwickler, und er konzentriert sich auf andere Themen: Überwachung,Fehlerdiagnose, Gewährleistung der Zuverlässigkeit und Wiederherstellung von Systemen nach Unfällen (glauben Sie, dass Sie keine Unfälle haben werden? Ja, natürlich). Und ehrlich gesagt ist die Wahrscheinlichkeit, dass ein Unternehmensprojekt aufgrund schlechter Unterstützung stirbt, erheblich höher als aufgrund schlechter Entwicklungsqualität. Daher ist die Gewinnung hochwertiger Spezialisten mit Erfahrung in der Unterstützung und dem Betrieb von Unternehmenssystemen ein wichtiger, wenn nicht der wichtigste Faktor dafür, dass das Projekt lange leben und sich entwickeln wird und nicht vergeht, sobald einige Gründerväter es verlassen.Daher ist die Gewinnung hochwertiger Spezialisten mit Erfahrung in der Unterstützung und dem Betrieb von Unternehmenssystemen ein wichtiger, wenn nicht der wichtigste Faktor dafür, dass das Projekt lange leben und sich entwickeln wird und nicht vergeht, sobald einige Gründerväter es verlassen.Daher ist die Gewinnung hochwertiger Spezialisten mit Erfahrung in der Unterstützung und dem Betrieb von Unternehmenssystemen ein wichtiger, wenn nicht der wichtigste Faktor für die Tatsache, dass das Projekt lange leben und sich entwickeln wird und nicht verdorren wird, sobald einige Gründerväter es verlassen.



4. Einer der trübe Rechtsbereiche ist die Formalisierung der Beziehungen zwischen dem Betreiber und den Netzteilnehmern, was durch die Tatsache verschärft wird, dass der Betreiber einerseits nicht Eigentümer des Netzes und seiner Ressourcen ist und andererseits verpflichtet ist, dessen Funktion sicherzustellen, auch wenn die Diese Maßnahme steht im Widerspruch zu den Interessen der einzelnen Teilnehmer. Das Gleichgewicht zwischen den Rechten und Pflichten des Betreibers, seine "Einflussmöglichkeiten" auf die Netzteilnehmer, die finanzielle Verantwortung des Betreibers - all dies ist nun Gegenstand sehr schwieriger Streitigkeiten. Die einfachste Frage:Wie kann der synchrone Austausch kritischer Software durch alle Netzwerkteilnehmer trotz ihrer scheinbaren Einfachheit zu sehr hitzigen Diskussionen führen? Das Auftauchen von Beispielen für die rechtliche Formalisierung der Position des Betreibers und der Netzteilnehmer auf der Grundlage der Erfahrungen mit Plattformen, die bereits in prod veröffentlicht wurden, wird die Einführung dezentraler Netze als wesentliches Element der Unternehmens- und Unternehmensbeziehungen erheblich beschleunigen.



Wenn Sie das Ende erreicht haben, gibt es auch einen Bonus: Einige der Fragen zum aktuellen Status und zu den Entwicklungspfaden dezentraler Unternehmensplattformen spiegeln sich in dem Material wider, das der Autor dieses Artikels für eine der Blockchain-Ressourcen erstellt hat (das Material ist für eine breite Palette von Lesern konzipiert ).