Wichtige Überlegungen zum Design von Ethereum ÐApps (2): So organisieren Sie Ihre Daten (Struct VS. Child Contract)

Speichern von Daten in Blockchain mithilfe eines intelligenten Vertrags
Dies ist die zweite Veröffentlichung einer Reihe, die darauf abzielt, die Verwendung von Ethereum zum Erstellen von DApps zu fördern. Sie können die erste Veröffentlichung dieser Serie "Upgradable Smart Contracts" überprüfen, bevor Sie fortfahren, da einige Ideen miteinander verbunden sind.

Welches ist das Beste? Ein intelligenter Vertrag für alle Entitäten oder ein intelligenter Vertrag für jede Entität? Tatsächlich sollten Sie aus vielen Gründen und in den meisten Fällen in Betracht ziehen, nur einen Vertrag bereitzustellen, der die Informationen aller Entitäten desselben Typs enthält. Lassen Sie uns jedoch zunächst die folgenden beiden Beispiele verwenden, um die beiden möglichen Entwürfe zu veranschaulichen, die in diesem Artikel behandelt werden.

Die beiden Entwürfe, die wir diskutieren

Erstes Entwurfsbeispiel: Speichern Sie alle Basisdaten der Mitglieder in einem Vertrag unter Verwendung einer „Struktur“:

Ein Beispielprojekt, das diesem Muster folgt, finden Sie hier. Welches ist ein Marktplatz Smart Vertrag zum Austausch von Gesundheitsinformationen.

2. Entwurfsbeispiel: Speichern Sie die Basisdaten jedes Mitglieds in einer anderen bereitgestellten Version eines Vertrags

Ein Beispielcode für ein Projekt, das diesem Muster folgt, finden Sie hier. Es ist für ein Projekt namens Medical Record Sharing.

Welches Designmuster ist das beste?

Im Zusammenhang mit dem Speichern von Daten für DApps in einer Blockchain mithilfe intelligenter Verträge ist das erste vorgeschlagene Design, das eine Struktur verwendet, überlegen. Dies liegt an den folgenden Gründen:

Wenn Sie Daten in Verträgen speichern, verwenden Sie Verträge als Tabellen

Aus Sicht des Designs Verträge, die Daten speichern, sind wie Tabellen und nicht wie Objekte. Lassen Sie uns zur Verdeutlichung zum Beispiel über „Menschen“ in einem dezentralen Fahrzeugleasing sprechen. Sie sollten sich überlegen, ob Sie eine Datenbank haben und Tabellen erstellen möchten. Und Sie sollten so denken, wie Sie eine Tabelle erstellen, in der die Daten aller Personen gespeichert werden. Und Sie werden niemals eine Tabelle für jede Person erstellen. Ebenso sollte ein Vertrag eine Tabelle darstellen. Und Sie erstellen einen Smart Contract für alle Personen, um dort Informationen in diesem Vertrag zu speichern. Sie sollten nicht für jede Person eine Vertragsinstanz bereitstellen.

Solidität ist eine vertragsorientierte Programmiersprache

Sie sollten sich einen Vertrag nicht genau als Objekt in OOP vorstellen. Im Gegensatz dazu ist Solidity, wie von Ethereum vorgeschlagen, eine vertragsorientierte Programmiersprache. Sie sollten also nicht nur alle Ihre OOP in Solidität anpassen. Einige OOP-Konzepte sind jedoch anwendbar, beispielsweise die Vererbung. Einige andere Konzepte sollten jedoch anders sein. So wie wir die Kommunikation zwischen Verträgen gestalten. Tatsächlich ist dies der Hauptunterschied zwischen objektorientierter und vertragsorientierter Programmierung.

Weniger Kosten (weniger Gas)

Eine weitere Überlegung, die der Designperspektive von Solidity als intelligente Vertragsprogrammiersprache hinzugefügt werden muss, sind die Kosten. Wenn Sie sich für den zweiten vorgeschlagenen Ansatz entscheiden, benötigen Sie erheblich mehr Gas, um Ihr System zu betreiben. Beachten Sie, dass das für die Bereitstellung eines Vertrags erforderliche „Gas“ viel mehr ist als das für die Kommunikation mit einem anderen Vertrag erforderliche Gas. Darüber hinaus ist das Gas, das für die Interaktion mit einem anderen Vertrag benötigt wird, viel mehr als das Gas, das für einige interne Vorgänge innerhalb desselben Vertrags benötigt wird.

Selbst für das private Ethereum bedeutet weniger Gas eine schnellere Verarbeitung des Methodenaufrufs. Insbesondere, weil beim Aufrufen eines anderen Smart Contracts eine weitere Transaktion ausgeführt werden muss. Der Aufruf einer Methode erfolgt in derselben Transaktion.

Weniger Operationen beim Aktualisieren von Daten

Weitere Überlegungen, die in den Sinn kommen sollten, sind der für die Verwaltung der Verträge erforderliche Betriebsaufwand. Wenn Sie sich für den zweiten Ansatz entscheiden, sollten Sie überlegen, wie viel Kopfschmerzen Sie haben werden, wenn Sie beispielsweise den sekundären Eigentümer des Vertrags ändern müssen. Zum Beispiel für den Fall, dass Sie einen sekundären Eigentümer festlegen (kann auch ein Multi-Sig-Vertrag sein), der von Ihrer Organisation und nicht vom Endbenutzer verwaltet wird. Welche wird benötigt, falls der Endbenutzer (das Mitglied) zum Beispiel seinen privaten Schlüssel verloren hat! Und Sie benötigen diese Funktionalität, um Personendaten zu speichern.

Geringerer Aufwand bei der Implementierung neuer Codelogik

Anhand des ersten Artikels dieser Serie, Upgradable Smart Contracts, können Sie erkennen, wie kompliziert es ist, die Aktualisierbarkeit aufrechtzuerhalten und bei Bedarf bereitzustellen. Stellen Sie sich vor, Sie haben zehn Millionen Kunden, um zu sehen, wie schmerzhaft es sein kann, die falsche Wahl zu treffen. Und lassen Sie uns sagen, Sie werden mit dem zweiten vorgeschlagenen Design gehen. Jetzt hat jeder Kunde seine eigene Version des Vertrags, die speziell für ihn bereitgestellt wurde. Was kostet es, all diese zehn Millionen zu aktualisieren, selbst in einem privaten Ethereum-Netzwerk?

Sie können mehrere Bibliotheken und / oder Basisverträge verwenden

Anstatt andere Verträge zu verwenden und mit ihnen zu kommunizieren, gestalten Sie Verträge, die Daten enthalten, neu, um einen Basisvertrag (oder eine Bibliothek) zu bilden, der von abgeleiteten Klassen verwendet wird. Auf diese Weise könnte die Struktur, die die Daten und die zugehörigen Lese-, Hinzufüge-, Aktualisierungs- und Löschmethoden enthält, in einer anderen Datei isoliert werden.

Wenn Sie also die Mühe haben, eine lange Soliditätsdatei zu haben, die viele Strukturen und die zugehörigen Methoden zusammen enthält, teilen Sie jede Struktur mit dem zugehörigen Code in eine separate Basisklasse oder Bibliothek auf, und lassen Sie den Hauptvertrag von diesen Basisverträgen erben. Ich denke, dies ist einer der Hauptgründe, warum Solidität Mehrfachvererbung ermöglicht.

Beispiel für eine komplexe Struktur, einen Marktplatz:

Denken wir über einen Marktplatz nach. Sie müssen beispielsweise die Verkäufer / Käufer, alle Produkte / Dienstleistungen, die sie verkaufen / kaufen, und alle Transaktionen speichern, die zwischen ihnen stattfinden.

Nachdem Sie die genannten Punkte berücksichtigt haben, können Sie Ihre Logik in separaten Klassen und Bibliotheken organisieren, um die Wartbarkeit zu gewährleisten und das Upgrade zu vereinfachen. In einem solchen Fall können Sie sich dafür entscheiden, Verträge für jedes der folgenden Unternehmen abzuschließen:

  • Personen: Zum Speichern von Personeninformationen (da jeder Käufer möglicherweise etwas verkauft und somit ein Verkäufer ist, werden durch diesen Vertrag sowohl Käufer als auch Verkäufer gerettet)
  • Produkte: Zum Speichern von Produktinformationen.
  • Transaktionen: Um Kauf- und Verkaufstransaktionen zu protokollieren.
  • Markt: Um Ihre Logik aufrechtzuerhalten (Dieser intelligente Vertrag kann Einkäufe abwickeln und verarbeiten)

Beachten Sie, dass Sie die Daten von Personen, Produkten und Transaktionen im selben Marktvertrag speichern können. Ein einziger intelligenter Vertrag für alle Daten und die gesamte Logik, wie in Aktualisierbare intelligente Verträge beschrieben, erschwert jedoch die zukünftigen Aktualisierungen Ihres Systems. Um das Design modular zu halten, schlage ich daher vor, einen Vertrag für People, einen weiteren für Produkte und einen weiteren für Transactions abzuschließen. Damit werden sie als Basisklassen für den Market Smart-Vertrag verwendet. Auf diese Weise enthalten Personen, Produkte und Transaktionen Daten, während Market Ihre Geschäftslogik enthält.

Fazit

Die obigen Punkte sind speziell für DApps erforderlich. Dies ist der Fall, wenn Sie Daten in Blockchain im Solidity-Stil speichern möchten. Obwohl dies weniger wahrscheinlich ist, kann es vorkommen, dass Sie auf eine Situation stoßen, die keine gültigen Gründe für die Verwendung von Strukturen für untergeordnete Verträge darstellt. Und sie sind möglicherweise in einem anderen Kontext und in anderen Situationen nicht gültig. Dennoch sind die oben genannten am besten für DApps geeignet.