Untergeordneter Vertrag vs. Struktur

Nehmen wir an, ich muss die Sammlung komplexer Daten im Smart Contract speichern und manipulieren. Es gibt möglicherweise komplexe Regeln, die definieren, wer und wie ein Element ändern kann. Die Sammlung kann mehrere Millionen Gegenstände umfassen.

Es gibt zwei Möglichkeiten, wie diese Logik implementiert werden kann

  1. Untergeordneten Vertrag verwenden:
Vertrag DataItem {
    bytes32-Schlüssel;
    Zeichenfolgenwert;

    Funktion DataItem(bytes32 k, string v) {
        Schlüssel = k;
        Wert = v;
    }
}
Vertrag DAppInterface {
    Zuordnung (Bytes32 => Adresse) öffentliche Datenelemente;

    Funktion addDataItem (bytes32 k, string v) extern {
        dataItems[k] = neues DataItem(k, v);
    }
}
  1. Verwendung von struct:
Vertrag DAppInterface {

    struct DataItem {
        bytes32-Schlüssel;
        Zeichenfolgenwert;
    }

    Zuordnung (Bytes32 => DataItem) öffentliche DatenItems;

    Funktion addDataItem (bytes32 k, string v) extern {
        dataItems[k].key = k;
        dataItems[k].value = v;
    }
}

Was ist der Vorteil der Verwendung eines gegenüber einem anderen Ansatz? Was sind die Richtlinien für die Auswahl eines vs. anderen?

Antworten (1)

Unter den meisten Umständen sollten Datenstrukturen, sogar komplizierte, Structs sein.

Hier sind einige Gründe für die Wahl von Strukturen:

  • Verträge sind teurer. Sie müssen zunächst für die Erstellung des Vertrags bezahlen, und jedes Mal, wenn Sie darauf zugreifen, müssen Sie für einen Anruf zu einem anderen Vertrag bezahlen. Dies ist viel, viel teurer als ein sha3 für eine Suche im eigenen Speicher des Vertrags.
  • Verträge müssen Code replizieren. Jeder Vertrag muss die Logik zum Einstellen und Ändern von Werten enthalten, die Sie mit Gas bezahlen müssen. Eine Struktur benötigt nur eine Reihe von Funktionen.
  • Verträge werden aufgedeckt. Jeder kann eine Nachricht an einen Vertrag senden. Wenn Sie einen Vertrag zum Speichern von Datenstrukturen verwenden, müssen Sie den Zugriff manuell verwalten.
  • Bibliotheken könnten das sein, wonach Sie suchen. Wenn Sie nach Funktionen in einer Datenstruktur (z. B. ) suchen foo.bar(), können Sie dies mit einem Bibliotheksvertrag tun, ohne die zusätzliche Komplexität der Erstellung von Verträgen für jede Instanz.

Hier sind einige Gründe, warum Verträge besser wären:

  • Verträge können polymorph sein. Ein Vertrag könnte möglicherweise willkürlichen Code enthalten. Dadurch können mehrere Typen vermischt werden oder Benutzer können sogar ihre eigene Logik einbringen.
  • Die Logik wird aufgeteilt. In diesem Registrarvertrag hätte jede Urkunde eine Struktur sein können. Indem Deeds zu ihren eigenen Verträgen gemacht werden, gibt es weniger Angriffsfläche für die Deeds selbst, wodurch die Wahrscheinlichkeit einer weiteren Katastrophe im Ausmaß von TheDAO verringert wird.
  • Verträge werden aufgedeckt. Wenn Benutzer ihre Datenstrukturen konfigurieren müssen, kann es sich als einfacher erweisen, eine eindeutige Adresse zu haben, mit der sie direkt kommunizieren können.
  • Verträge sind Verträge. Ein untergeordneter Vertrag kann alles tun, was ein Vertrag tun kann. Wenn die Datenstrukturen aus irgendeinem Grund Dinge besitzen würden wie eine Adresse, dann wäre es weitaus besser, einen Vertrag zu haben. Ein Vertrag kann Ether direkt halten, im Gegensatz zu einer Struktur, die das Guthaben des Hauptvertrags mit anderen Strukturen teilt.

Diese sind jedoch seltener. Mein Rat: Versuchen Sie es zuerst mit Strukturen und verwenden Sie Datenstrukturverträge als letzten Ausweg.

Kann die Anzahl der Transaktionen und die Menge der im Vertrag gespeicherten Daten die Entscheidung beeinflussen, einen untergeordneten Vertrag oder eine untergeordnete Struktur zu verwenden? Nehmen wir an, ich habe eine Auktions-DApp, bei der mit jedem zum Verkauf stehenden Artikel eine Reihe von Transaktionen verbunden sind (Gebote, Zahlung, Versandinformationen hinzugefügt usw.). Diese DApp kann mit Strukturen und einem einzigen Vertrag implementiert werden. Aber in diesem Fall werden viele Transaktionen gleichzeitig gegen diesen Vertrag ausgeführt, und der Speicher für diesen Vertrag wird sehr schnell wachsen. Untergeordneter Vertrag würde isolierte Transaktionen und Speicherung für verkaufte Artikel ermöglichen.
In der aktuellen Version von Ethereum gibt es keine gleichzeitigen Transaktionen (dies wird sich voraussichtlich ändern). Unabhängig davon, ob es sich um einen oder mehrere Verträge handelt, werden Transaktionen immer einzeln ausgeführt. In ähnlicher Weise wird derselbe Betrag gespeichert, unabhängig davon, ob es sich um denselben Vertrag oder mehrere Verträge handelt (ohne Gemeinkosten). Ab einer gewissen Komplexität machen Einzelverträge Sinn. Wenn jede Auktion ein eigener Vertrag ist, können Sie beispielsweise viel einfacher mit den Kontoständen der Benutzer arbeiten.
Was ist zu wissen, wenn die Verwendung von untergeordneten Verträgen die Aufrüstbarkeit verbessert? Da das Datenstrukturlayout nicht an einen einzelnen Vertrag gebunden ist, können wir alles aktualisieren
Untergeordneter Vertrag vs. Struktur
AntwortenHierDatenschutz-Bestimmungen1y, 0v