Dezentrale Anwendungsarchitektur: Back-End-, Sicherheits- und Entwurfsmuster

Dezentrale Anwendungen oder ÐApps erfordern ein spezielles Systemdesign, um eine hohe Sicherheit und Zuverlässigkeit zu erreichen. In diesem Artikel werde ich einige Hauptprinzipien für das ordnungsgemäße Entwerfen und Implementieren von Back-End- und Smart-Verträgen für dezentrale Anwendungen behandeln, wobei Ethereum das wichtigste Beispiel ist, obwohl ein Großteil davon für EOS, Tron und andere dezentrale Datenplattformen gelten würde.

Artikel Highlights:

  • So speichern Sie private Schlüssel ohne Sicherheitsbedenken im Backend
  • Wie man intelligente Verträge richtig gestaltet und was man „dezentralisiert“
  • Beispiele für dezentrale und semizentrale Anwendungsarchitekturen
  • Wie man mit einfachen Dingen wie Netzwerklast und Ausfällen umgeht

Es wird groß, lass es uns tun!

Dezentrale Programme und Blockchain

Ungeachtet der Tatsache, dass Blockchain heutzutage mit einer Vielzahl von Anpassungs- und Regelungsschwierigkeiten konfrontiert ist, ist dies eine Technologie, die auf lange Sicht Bestand hat, sei es Blockchain, Hashgraph, Tempo oder eine andere verteilte Hauptbuch-Technologie, die noch aussteht, unabhängig vom Algorithmus.

Der Hauptnutzen von Blockchain und anderen ähnlichen Technologien kann wie folgt verallgemeinert werden: Sie ermöglichen es Benutzern, Programme zu schreiben und auszuführen, die nach der Erstellung praktisch nicht mehr geändert oder während der Ausführung manipuliert werden können. Mit anderen Worten, diese Programme werden immer wie geplant ausgeführt, und keine einzelne Partei kann ihr Verhalten beeinflussen.

Diese Definition gilt für viele heute existierende Kryptowährungen, wenn wir sie als Programme betrachten, die definieren, wie Münzen hin und her transferiert werden können. Dies erklärt auch, warum Kryptowährungen und viele Arten von Token einen echten Wert haben: Sie können durch ihre definierten „zugrunde liegenden Programme“ nicht aus dem Nichts generiert werden.

Die Plattformen Ethereum / EOS / Tron /… implementieren im Gegensatz zu Bitcoin eine komplexere Programmschicht, die wiederum die Ausführungsumgebung implementiert, sodass jeder seine eigenen dezentralen Programme auf der Plattform schreiben kann. Diese benutzerdefinierten Programme werden ausnahmslos wie geplant ausgeführt, und ihre Sicherheit wird von der Plattform garantiert.

Dezentrale Anwendungen

Diese sicheren und unveränderlichen Programme, die in einem dezentralen Netzwerk in Kombination mit traditionellen Front-End- und Back-End-Technologien ausgeführt werden, werden heute als dezentrale Anwendungen (ÐApps) bezeichnet. Wenn einige von ihnen semi-zentralisiert sein können, sollte ein Großteil der Aktivitäten in der wirklich dezentralen Anwendung außerhalb der Kontrolle einer zentralen Partei erfolgen.

Wenn mich jemand gefragt hätte, wie DApps heute funktionieren, hätte ich das wahrscheinlich gezeichnet

Um sich vorzustellen, was wir heute als dezentrale Anwendungen bezeichnen, nehmen Sie eine vorhandene zentrale Webressource wie _YouTube_ oder _Instagram_ und stellen Sie sich vor, dass Sie anstelle eines kennwortgeschützten zentralen Kontos Ihre „Krypto-Identität“ an die Web- / mobile Ressource gebunden haben.

Das bietet Ihnen Wallet Software. Der private Schlüssel dieser Identität (ein Geheimnis, mit dem Sie im Namen dieser Identität handeln können) wird auf Ihrem lokalen Gerät gespeichert und geht nie online, sodass niemand außer Ihnen diese Identität kontrollieren kann. Mit dieser Identität können Sie über die Website verschiedene Aktionen sowohl in zentralen (von einer zentralen Behörde kontrollierten Webressourcen) als auch in dezentralen (einem anderen Netzwerk als dem herkömmlichen WWW, dessen Ziel es ist, die zentrale Behörde zu beseitigen) Netzwerken ausführen als Zugangspunkt und / oder als grafische Benutzeroberfläche. Der springende Punkt dieser „Krypto-Identität“ ist, dass Ihre Aktionen kryptografisch gesichert sind und niemand in der Lage ist, Ihre Unterschriften oder Unterschriften zu ändern.

Heutzutage sind die Rechen- und Speicherkapazitäten fehlertoleranter dezentraler Netzwerke wie Ethereum, EOS oder Tron begrenzt. Wenn sie skalierbar wären, könnten wir dezentrale Netzwerke verwenden, um die gesamte dezentrale Anwendung einschließlich ihrer grafischen Benutzeroberfläche, Daten und Geschäftslogik zu speichern. In diesem Fall würden wir diese Anwendungen als wirklich dezentral / verteilt bezeichnen.

Da diese Netzwerke heutzutage nicht skalierbar sind, kombinieren wir verschiedene Ansätze, um den maximalen Dezentralisierungsgrad für unsere Anwendungen zu erreichen. Das "traditionelle" Back-End, wie wir es kennen, geht nirgendwo hin. Zum Beispiel:

  • Wir verwenden das Back-End, um das Front-End für eine dezentrale Anwendung zu hosten.
  • Wir verwenden das Back-End für die Integration mit anderen vorhandenen Technologien und Diensten. Echte Weltklasse-Anwendungen können nicht in einer isolierten Umgebung ausgeführt werden.
  • Wir verwenden das Back-End, um alles zu speichern und zu verarbeiten, was für ein dezentrales Netzwerk (insbesondere Blockchain) groß genug ist. Praktischerweise werden die gesamte Anwendung und ihre Geschäftslogik irgendwo auf der Welt gespeichert, ausgenommen nur den Blockchain-Teil. Ganz zu schweigen davon, dass IPFS und ähnliche Speicherebenen den Zugriff auf Dateien nicht garantieren können. Daher können wir uns auch nicht auf sie verlassen, ohne die Dateien selbst zu hosten. Mit anderen Worten, es ist immer ein dedizierter Server erforderlich.

Es gibt keine Möglichkeit, eine sichere und teilweise dezentrale Anwendung zu erstellen, ohne ein solides Back-End zu verwenden, und der Sinn dieses Artikels besteht darin, zu erläutern, wie dies richtig gemacht wird.

(De) Zentralisierung und Tokens

Es ist so, dass fast alle dezentralen Anwendungen heutzutage auf sogenannten Token basieren - maßgeschneiderten (oder einfach geklonten) Kryptowährungen, die eine bestimmte dezentrale Anwendung steuern. Tokens sind einfach eine programmierbare Währung oder ein programmierbares Guthaben.

Während intelligente Token-Verträge festlegen, wie Benutzer Token übertragen können, können intelligente Anwendungsverträge alle in intelligenten Token-Verträgen fehlenden Elemente erweitern. Beide Smart Contracts laufen auf dezentralen Netzwerken

Normalerweise ist ein Token ein „intelligenter Vertrag“ (ein benutzerdefiniertes Programm), der auf einer dezentralen Plattform wie Ethereum geschrieben ist. Wenn Sie einige Token besitzen, können Sie im Grunde genommen verschiedene Dienste für eine Webressource oder eine mobile App nutzen und dieses Token gegen etwas anderes eintauschen. Der entscheidende Punkt hierbei ist, dass der Token für sich selbst lebt und nicht von einer zentralen Behörde kontrolliert wird.

Es gibt viele Beispiele für Anwendungen, die auf Token basieren: von zahlreichen Sammelspielen wie CryptoKitties (ERC721-Token) bis zu serviceorientierteren Apps wie LOOM Network oder sogar Browsern wie Brave und Spieleplattformen wie DreamTeam (ERC20-kompatible Token).

Entwickler selbst bestimmen und entscheiden, wie viel Kontrolle sie über ihre Anwendungen haben (oder nicht haben). Sie können die Geschäftslogik der gesamten Anwendung auf intelligenten Verträgen aufbauen (wie es CryptoKitties getan hat) oder sie können überhaupt keine intelligenten Verträge verwenden und alles auf ihren Servern zentralisieren. Der beste Ansatz liegt jedoch irgendwo in der Mitte.

Backend für dezentrale Netzwerke

Aus technischer Sicht muss es eine Brücke geben, die Token und andere intelligente Verträge mit der Web- / Mobilanwendung verbindet.

In den heutigen vollständig dezentralen Anwendungen, in denen Clients direkt mit intelligenten Verträgen interagieren, wird diese Brücke auf die JSON-RPC-API-Funktionen öffentlicher APIs oder Knotenpools wie Infura beschränkt, die aufgrund der Tatsache, dass nicht jedes Gerät vorhanden sein muss, eingeschränkt Führen Sie den einzelnen Netzwerkknoten aus und unterstützen Sie ihn. Diese API bietet jedoch nur grundlegende und sehr enge Funktionen, die es kaum erlauben, einfache Abfragen durchzuführen oder Daten effizient zu aggregieren. Aus diesem Grund wird schließlich das benutzerdefinierte Back-End aktiviert, wodurch die Anwendung semi-zentralisiert wird.

Die gesamte Interaktion mit dem dezentralen Netzwerk kann je nach den Anforderungen der Anwendung auf ein oder zwei Punkte eingegrenzt werden:

  1. Abhören der Netzwerkereignisse (wie Token-Übertragungen) / Lesen des Netzwerkstatus.
  2. Veröffentlichen von Transaktionen (Aufrufen von Funktionen zum Ändern des Status von Smart Contracts wie Token-Transfer).

Die Implementierung dieser beiden Punkte ist recht schwierig, insbesondere wenn wir eine sichere und zuverlässige Back-End-Lösung erstellen möchten. Hier sind die wichtigsten Punkte, die wir unten aufschlüsseln werden:

  • Erstens ist die Ereignisabfrage in Ethereum nicht sofort einsatzbereit. Aus mehreren Gründen: Netzwerkknoten können beim Abrufen einer großen Anzahl von Ereignissen ausfallen, Ereignisse können aufgrund von Netzwerkgabeln usw. verschwinden oder sich ändern. Wir müssen eine Abstraktionsschicht aufbauen, um Ereignisse aus dem Netzwerk zu synchronisieren und ihre zuverlässige Zustellung zu gewährleisten.
  • Das Gleiche gilt für das Veröffentlichen von Transaktionen. Wir müssen die einfachen Dinge von Ethereum wie Nonce Counter und Gasschätzungen sowie das erneute Veröffentlichen von Transaktionen zusammenfassen, um eine zuverlässige und stabile Schnittstelle zu bieten. Darüber hinaus erfordert das Veröffentlichen von Transaktionen die Verwendung privater Schlüssel, was eine erweiterte Back-End-Sicherheit erfordert.
  • Sicherheit. Wir werden es ernst nehmen und feststellen, dass es unmöglich ist, zu garantieren, dass private Schlüssel niemals in einem Back-End kompromittiert werden. Glücklicherweise gibt es einen Ansatz zum Entwerfen einer dezentralen Anwendung, ohne dass Back-End-Konten in hohem Maße gesichert werden müssen.

In unserer Praxis haben wir dadurch eine robuste Back-End-Lösung für Ethereum geschaffen, die wir Ethereum Gateway nennen. Es abstrahiert andere Microservices von Ethereums Spaß und bietet eine zuverlässige API, um damit zu arbeiten.

Als schnell wachsendes Startup können wir aus offensichtlichen Gründen (noch) nicht die vollständige Lösung veröffentlichen, aber ich werde Ihnen alles mitteilen, was Sie wissen müssen, damit Ihre dezentrale Anwendung einwandfrei funktioniert. Wenn Sie jedoch spezielle Fragen oder Anfragen haben, können Sie sich gerne an mich wenden. Kommentare zu diesem Artikel sind ebenfalls sehr willkommen!

Backend-Überwachung für Ethereum. Der Monitor zeigt Aktivitäten hauptsächlich in Bezug auf unsere Funktion für wiederkehrende Abrechnungen an (obwohl Sie sehen können, dass jede Stunde Spitzenwerte auftreten).

Dezentrale Anwendungsarchitektur

Dieser Teil des Artikels hängt stark von den Anforderungen einer bestimmten dezentralen Anwendung ab. Wir werden jedoch versuchen, einige grundlegende Interaktionsmuster herauszufinden, auf denen diese Anwendungen aufbauen ((Plattform = Dezentrale Plattform = Ethereum / EOS / Tron / Whatever):

Client ⬌ ⬌Plattform: vollständig dezentrale Anwendungen.

Der Client (Browser oder mobile Anwendung) kommuniziert direkt mit der dezentralen Plattform mithilfe von Ethereum-Wallet-Software wie Metamask, Trust oder Hardware-Wallets wie Trezor oder Ledger. Beispiele für DApps, die auf diese Weise erstellt wurden, sind CryptoKitties, Loom's Delegated Call, Crypto Wallets selbst (Metamask, Trust, Tron Wallet usw.), dezentrale Crypto-Börsen wie Etherdelta usw.

ÐPlattform ⬌ Client ⬌ Back-End ⬌ Plattform: zentralisierte oder semi-zentralisierte Anwendungen.

Die Client-Interaktion mit der dezentralen Plattform und dem Server hat wenig gemeinsam. Ein gutes Beispiel hierfür ist ein (zentralisierter) Krypto-Austausch wie BitFinex oder Poloniex: Die Währungen, mit denen Sie an Börsen handeln, werden einfach in der traditionellen Datenbank erfasst. Sie können Ihr Datenbankguthaben aufladen, indem Sie Assets an eine bestimmte Adresse senden ((Plattform ⬌ Client) und nach einigen Aktionen in der App (Back-End ⬌Plattform) Assets zurückziehen. Alles, was Sie jedoch in Bezug auf eine aApp tun. Selbst (Client ⬌ Back-End) impliziert nicht Ihre direkte Interaktion mit der ÐPlattform.

Ein weiteres Beispiel ist Etherscan.io, das einen semizentralen Ansatz verwendet: Sie können dort alle nützlichen dezentralen Aktionen ausführen, aber die Anwendung selbst macht ohne ihr umfassendes Back-End keinen Sinn (Etherscan synchronisiert Transaktionen fortlaufend, parst Daten und speichert sie). letztendlich Bereitstellung einer umfassenden API / UI).

Etwas dazwischen: noch, zentralisierte oder semi-zentralisierte Anwendungen.

Die oben genannten Ansätze kombiniert. Beispielsweise können wir eine Anwendung haben, die verschiedene Dienste im Austausch für Krypto bereitstellt, sodass Sie sich mit Ihrer Krypto-Identität anmelden und Informationen signieren können.

Hoffentlich wirft das Interaktionsmuster vollständig dezentraler Anwendungen (Client Client ⬌ Plattform) keine Fragen auf. Wenn Sie sich auf so erstaunliche Dienste wie Infura oder Trongrid verlassen, können Sie ganz einfach eine Anwendung erstellen, für die überhaupt kein Server erforderlich ist. Nahezu alle clientseitigen Bibliotheken wie Ethers.js for Ethereum oder Tron-Web for Tron können eine Verbindung zu diesen öffentlichen Diensten herstellen und mit dem Netzwerk kommunizieren. Bei komplexeren Abfragen und Aufgaben müssen Sie möglicherweise trotzdem einen eigenen Server zuweisen.

Der Rest der Interaktionsmuster, an denen das Back-End beteiligt ist, macht die Dinge interessanter und komplexer. Stellen Sie sich einen Fall vor, in dem unser Back-End auf ein Ereignis im Netzwerk reagiert, um all dies in einem Bild darzustellen. Zum Beispiel veröffentlicht der Benutzer eine Berechtigungstransaktion, die uns die Erlaubnis gibt, sie zu belasten. Um eine Gebühr zu erheben, müssen wir die Gebührentransaktion als Reaktion auf das ausgegebene Zertifikatsereignis veröffentlichen:

Ein Beispiel für die Reaktion des Servers auf die Benutzeraktion im dezentralen Netzwerk

Aus der Sicht des Backends geschieht Folgendes:

  1. Wir hören uns ein bestimmtes Netzwerkereignis an, indem wir das Netzwerk kontinuierlich abfragen.
  2. Sobald wir ein Ereignis erhalten, führen wir eine Geschäftslogik durch und beschließen dann, eine Transaktion als Antwort zu veröffentlichen.
  3. Vor der Veröffentlichung der Transaktion möchten wir sicherstellen, dass sie wahrscheinlich abgebaut wird (in Ethereum bedeutet die erfolgreiche Transaktionsgasschätzung, dass keine Fehler im Hinblick auf den aktuellen Netzwerkstatus vorliegen). Wir können jedoch nicht garantieren, dass die Transaktion erfolgreich abgebaut wird.
  4. Mit einem privaten Schlüssel signieren und veröffentlichen wir die Transaktion. In Ethereum müssen wir auch den Gaspreis und das Gaslimit der Transaktion bestimmen.
  5. Nach der Veröffentlichung der Transaktion wird der Status des Netzwerks fortlaufend abgefragt.
  6. Wenn es zu lange dauert und wir den Status der Transaktion nicht abrufen können, müssen wir sie erneut veröffentlichen oder ein "Fail-Szenario" auslösen. Transaktionen können aus verschiedenen Gründen verloren gehen: Überlastung des Netzwerks, Ausfall von Peers, Erhöhung der Netzwerklast usw. In Ethereum können Sie auch in Betracht ziehen, eine Transaktion mit einem anderen (tatsächlichen) Gaspreis neu zu signieren.
  7. Nachdem wir unsere Transaktion endgültig abgebaut haben, können wir bei Bedarf weitere Geschäftslogik ausführen. Beispielsweise können wir andere Back-End-Services über den Abschluss der Transaktion benachrichtigen. Erwägen Sie außerdem, einige Bestätigungen abzuwarten, bevor Sie endgültige Entscheidungen in Bezug auf die Transaktion treffen: Das Netzwerk ist verteilt, und daher kann sich das Ergebnis innerhalb von Sekunden ändern.

Wie Sie sehen, ist viel los! In Ihrer Anwendung sind jedoch möglicherweise einige dieser Schritte nicht erforderlich, je nachdem, was Sie erreichen möchten. Der Aufbau eines robusten und stabilen Backends erfordert jedoch eine Lösung für alle oben genannten Probleme. Lassen Sie uns das zusammenfassen.

Backend für dezentrale Anwendungen

Hier möchte ich einige der Punkte hervorheben, die die meisten Fragen aufwerfen, nämlich:

  • Abhören von Netzwerkereignissen und Lesen von Daten aus dem Netzwerk
  • Veröffentlichen von Transaktionen und sichere Vorgehensweise

Abhören von Netzwerkereignissen

In Ethereum sowie in anderen dezentralen Netzwerken ermöglicht ein Konzept intelligenter Vertragsereignisse (oder Ereignisprotokolle oder nur Protokolle), dass Anwendungen außerhalb der Kette wissen, was in der Blockchain geschieht. Diese Ereignisse können von Entwicklern intelligenter Verträge an jedem Punkt des Codes für intelligente Verträge erstellt werden.

Beispielsweise muss innerhalb des bekannten ERC20-Token-Standards jede Token-Übertragung das Transfer-Ereignis protokollieren, wodurch Anwendungen außerhalb der Kette wissen, dass eine Token-Übertragung stattgefunden hat. Indem wir auf diese Ereignisse „hören“, können wir alle (Re-) Aktionen ausführen. Einige mobile Crypto-Wallets senden Ihnen beispielsweise eine Push- / E-Mail-Benachrichtigung, wenn Token an Ihre Adresse übertragen werden.

Tatsächlich gibt es keine zuverlässige Lösung für die sofortige Überwachung von Netzwerkereignissen. Mithilfe verschiedener Bibliotheken können Sie Ereignisse nachverfolgen / abhören. In vielen Fällen kann jedoch ein Fehler auftreten, der zu verlorenen oder nicht verarbeiteten Ereignissen führt. Um zu vermeiden, dass Ereignisse verloren gehen, müssen wir ein benutzerdefiniertes Back-End erstellen, das den Synchronisierungsprozess für Ereignisse aufrechterhält.

Je nach Ihren Anforderungen kann die Implementierung variieren. Hier ein Bild von Ihnen zu machen, ist eine der Möglichkeiten, wie Sie eine zuverlässige Bereitstellung von Ethereum-Ereignissen in Bezug auf die Microservice-Architektur erstellen können:

Zuverlässige Zustellung von Ethereum-Events an alle Back-End-Services

Diese Komponenten funktionieren folgendermaßen:

  1. Der Back-End-Dienst für die Ereignissynchronisierung fragt das Netzwerk ständig ab und versucht, neue Ereignisse abzurufen. Sobald einige neue Ereignisse verfügbar sind, werden diese Ereignisse an den Nachrichtenbus gesendet. Nach erfolgreicher Übermittlung des Ereignisses an den Nachrichtenbus, wie bei der Blockchain, können wir den Block des letzten Ereignisses speichern, um beim nächsten Mal neue Ereignisse von diesem Block anzufordern. Denken Sie daran, dass das gleichzeitige Abrufen von zu vielen Ereignissen zu immer fehlgeschlagenen Anforderungen führen kann. Sie müssen daher die Anzahl der vom Netzwerk angeforderten Ereignisse / Blöcke begrenzen.
  2. Der Nachrichtenbus (z. B. Rabbit MQ) leitet das Ereignis an jede Warteschlange weiter, die für jeden Back-End-Service einzeln eingerichtet wurde. Vor dem Veröffentlichen von Ereignissen gibt der Back-End-Service für die Ereignissynchronisierung den Routing-Schlüssel an (z. B. eine intelligente Vertragsadresse + ein Ereignisthema), während Verbraucher (andere Back-End-Services) Warteschlangen erstellen, die nur für bestimmte Ereignisse abonniert sind.

Infolgedessen erhält jeder Back-End-Service nur die Ereignisse, die er benötigt. Darüber hinaus garantiert der Nachrichtenbus die Zustellung aller Ereignisse, sobald sie für ihn veröffentlicht wurden.

Natürlich können Sie anstelle des Nachrichtenbusses auch etwas anderes verwenden: HTTP-Rückrufe, Sockets usw. In diesem Fall müssen Sie herausfinden, wie Sie die Rückrufzustellung selbst gewährleisten können: Verwalten von exponentiellen / benutzerdefinierten Rückrufwiederholungen, Implementieren einer benutzerdefinierten Überwachung und bald.

Veröffentlichen von Transaktionen

Es sind einige Schritte erforderlich, um eine Transaktion im dezentralen Netzwerk zu veröffentlichen:

  1. Vorbereiten der Transaktion. Zusammen mit den Transaktionsdaten bedeutet dieser Schritt, den Netzwerkstatus anzufordern, um herauszufinden, ob diese Transaktion gültig ist und abgebaut werden soll (Gasschätzung in Ethereum) und die fortlaufende Nummer der Transaktion (Nonce in Ethereum). Einige Bibliotheken versuchen dies unter der Haube zu tun, diese Schritte sind jedoch wichtig.
  2. Unterzeichnung der Transaktion. Dieser Schritt impliziert die Verwendung des privaten Schlüssels. Hier möchten Sie höchstwahrscheinlich (zum Beispiel) die benutzerdefinierte Private-Key-Assembly-Lösung einbetten.
  3. Veröffentlichen und erneutes Veröffentlichen der Transaktion. Einer der wichtigsten Punkte hierbei ist, dass Ihre veröffentlichte Transaktion immer die Möglichkeit hat, verloren zu gehen oder aus dem dezentralen Netzwerk auszufallen. In Ethereum kann die veröffentlichte Transaktion beispielsweise gelöscht werden, wenn der Gaspreis des Netzes plötzlich steigt. In diesem Fall müssen Sie die Transaktion erneut veröffentlichen. Darüber hinaus möchten Sie die Transaktion möglicherweise mit anderen Parametern erneut veröffentlichen (zumindest mit einem höheren Gaspreis), damit sie so schnell wie möglich abgebaut wird. Das erneute Veröffentlichen der Transaktion kann daher ein erneutes Signieren der Transaktion bedeuten, wenn die Ersatztransaktion zuvor nicht vorsigniert wurde (mit anderen Parametern).
Die obigen Punkte in Bezug auf das Veröffentlichen von Ethereum-Transaktionen wurden visualisiert

Wenn Sie die oben genannten Ansätze verwenden, können Sie etwas erstellen, das dem im folgenden Sequenzdiagramm dargestellten ähnelt. In diesem speziellen Ablaufdiagramm zeige ich (allgemein!), Wie die wiederkehrende Abrechnung in der Blockchain funktioniert (in einem verknüpften Artikel finden Sie weitere Informationen):

  1. Der Benutzer führt eine Funktion in einem Smart-Vertrag aus, die es dem Back-End letztendlich ermöglicht, eine erfolgreiche Gebührentransaktion durchzuführen.
  2. Ein Back-End-Service, der für eine bestimmte Aufgabe zuständig ist, überwacht das Ereignis der Gebührenermäßigung und veröffentlicht eine Gebührentransaktion.
  3. Sobald die Gebührentransaktion abgebaut ist, empfängt dieser Back-End-Service, der für eine bestimmte Aufgabe zuständig ist, ein Ereignis vom Ethereum-Netzwerk und führt eine Logik aus (einschließlich des Festlegens des nächsten Gebührendatums).
Das allgemeine Sequenzdiagramm für die Funktionsweise wiederkehrender Abrechnungen in der Blockchain zeigt die Interaktion zwischen Back-End-Diensten und dem Ethereum-Netzwerk

Back-End-Sicherheit und intelligente Verträge

Beim Veröffentlichen von Transaktionen wird immer ein privater Schlüssel verwendet. Sie fragen sich möglicherweise, ob es möglich ist, private Schlüssel sicher zu verwahren. Ja und nein Es gibt zahlreiche komplexe Strategien und verschiedene Arten von Software, mit denen private Schlüssel im Back-End recht sicher gespeichert werden können. Einige Speicherlösungen für private Schlüssel verwenden geoverteilte Datenbanken, während andere sogar die Verwendung spezieller Hardware vorschlagen. In jedem Fall ist der anfälligste Punkt einer halbzentralisierten Anwendung jedoch der, an dem der private Schlüssel zusammengestellt und zum Signieren einer Transaktion verwendet wird (oder, bei spezieller Hardware, der Punkt, an dem eine Transaktionssignierprozedur ausgelöst wird). Theoretisch gibt es daher keine 100% zuverlässige Lösung, die einen kugelsicheren Schutz vor der Beeinträchtigung gespeicherter privater Schlüssel ermöglicht.

Denken Sie jetzt so. In vielen Fällen müssen Sie nicht so oft private Schlüssel auf dem Back-End sichern. Stattdessen können Sie intelligente Verträge und die gesamte Anwendung so gestalten, dass ein privates Schlüsselleck das normale Verhalten nicht beeinträchtigt. Bei diesem Ansatz spielt es keine Rolle, wie autorisierte Konten mit dem Smart-Vertrag interagieren. Sie lösen lediglich einen intelligenten Vertrag aus, um seine übliche Arbeit zu erledigen, und der intelligente Vertrag selbst führt alle erforderlichen Überprüfungen durch. Ich nenne es das "Muster der Betriebskonten".

Betriebskontenmuster für dezentrale Anwendungen, bei denen Sie für Ihre Back-End-Konten keine militärische Sicherheit benötigen

So im Notfall:

  • Das einzige, was der Angreifer stehlen kann, ist eine winzige Menge Ether (ab Ethereum), die für das Veröffentlichen von Transaktionen auf den Betriebskonten abgelegt wird
  • Der Angreifer kann weder der intelligenten Vertragslogik noch den am Prozess beteiligten Personen Schaden zufügen
  • Kompromittierte Betriebskonten können schnell durch andere ersetzt werden. Dies erfordert jedoch entweder das manuelle Ersetzen (Generieren neuer Konten und erneutes Autorisieren von Konten in allen intelligenten Verträgen) oder die Entwicklung einer zusätzlichen Lösung, die mit einer einzigen Transaktion aus einem Super heraus die Magie vollbringt -sichere (Hardware oder Multi-Sig) Master-Konto.

In unserer Lösung für die wiederkehrende Abrechnung von Ethereum ist der Smart-Vertrag für wiederkehrende Abrechnungen beispielsweise so konzipiert, dass wir einen ganzen Monat Zeit haben, um die gefährdeten Konten zu ersetzen, wenn eines davon gefährdet ist .

Wenn Sie jedoch Ihren privaten Back-End-Schlüssel so sicher wie möglich speichern möchten, können Sie versuchen, Vault mit einem großartigen Plugin für Ethereum zu verwenden, das Ethereum-Konten speichert und verwaltet (behalten Sie auch unsere Open-Source-Module im Auge - wir werden demnächst etwas ähnliches veröffentlichen). Ich werde hier nicht tief in die Details eintauchen, obwohl Sie die verknüpften Projekte besuchen und von dort selbst lernen können.

Das ist noch nicht alles, was ich zu sagen habe. Dieser Artikel war jedoch viel länger als erwartet, so dass ich aufhören muss. Abonnieren Sie mein Medium / andere Netzwerke, wenn Sie an Software, Krypto oder Reisetipps interessiert sind oder einfach nur etwas Interessantes verfolgen möchten. Ich hoffe, ich habe eine große wertvolle Information geliefert und Sie werden sie nützlich finden. Fühlen Sie sich frei, diesen Artikel zu kommentieren und zu verbreiten!