Gaskostendatenbank in Smartcontract

Wie kann ich eine "Datenbank" in einem Smart Contract speichern und wie würden die Kosten berechnet, was kostet mich Benzin?

Ein praktisches Beispiel wäre, ich habe eine Android-App, die einen Smart Contract mit der Ethereum-Android-Lib aufruft und Daten hinzufügt, ich gehe davon aus, dass diese Daten dann von einem anderen Android-Client abgerufen werden können. Wie hoch sind die Kosten für die Eingabe dieser Daten in den Smart Contract? Ist es die Menge der neuen Daten, die ich einzugeben versuche, oder die Gesamtkosten aller Daten, die im Smart Contract enthalten sind?

Der Pseudovertrag, an den ich gedacht habe, würde so aussehen:

contract patientRecord {
  address public owner;
  uint public numFiles;
  struct File {
    uint name;
    bytes32 illness;
  }
  mapping(uint => File) public files;

  // add a new file
  function files(bytes32 _message) {
    if (msg.value == 0 || complete || refunded) throw;
    files[numFiles] = Pledge(msg.value.name, msg.value.illness);
    numFiles++;
  }

  function retreive(uint id){
      //get back file of a pateint with ID
  }

  function retreive(uint id){
      //modify some value in a file
  }

}
Das sagt mir nicht wirklich, wie viel es kostet, eine Datei in der Blockchain zu speichern, aber ich möchte wissen, was mich kosten wird. Wenn ich einem Vertrag Daten hinzufüge
Sie sollten Ihren Code testen. Schreiben Sie einige Tests und finden Sie heraus, wie viel Benzin es kostet. Andernfalls müssen Sie sich den Maschinencode ansehen und ihn anhand der Gasbetriebskosten manuell berechnen (z. B. im Yellowpaper oder Google danach, da er seitdem geändert wurde). Ich stimme offen zu lassen, es sei denn, es gibt bereits in einem Frage- / Antwortsatz eine gute Anleitung zur Schätzung der Gaskosten.

Antworten (1)

Diese Frage gibt es schon eine Weile. Ich denke, möglicherweise verdient es eine zusammengefasste Richtungsantwort.

Zunächst einige große Schlagzeilen, die zunächst vielleicht nicht besonders wichtig erscheinen oder möglicherweise schwer auf einen Schlag zu verdauen sind.

  1. Migrieren Sie vorhandene oder imaginäre Datenbankdesigns nicht direkt in den Blockchain-Speicher. Wählen Sie einen minimalistischen Ansatz für die On-Chain-Speicherung. Der Smart Contract sollte meiner Meinung nach die Integrität der Anwendung sicherstellen . Im weiteren Sinne soll der Smart Contract die Integrität der Daten sicherstellen. Überflüssige Felder und Deskriptoren werden im Allgemeinen an einen anderen Ort verschoben, wo Speicherplatz und Leistung reichlich und billig sind.
  2. Gasgebühren gelten für gespeicherte Bytes und ausgeführte OpCodes. Wieder Minimalismus, weil jedes Byte zählt .

In Anbetracht dessen tendieren viele Designs dazu, wichtige Schlüssel und wenig mehr aufzubewahren.

In Bezug auf eine relationale Datenbank könnten Primärschlüssel und Fremdschlüssel die minimale On-Chain-Speicherung sein, die erforderlich ist, um die referenzielle Integrität zu erzwingen. " Address Line 2" ist die Art von Deskriptor, die in dieser Hinsicht nicht hilft, also ein guter Kandidat zum Speichern an anderer Stelle.

Sie könnten beispielsweise alle Deskriptoren serialisieren und das Ergebnis an einem Offchain-Standort speichern - einer traditionellen Datenbank, IPFS, Swarm ... und dann den Standort und den Hash der aktuellen Daten im Smart Contract speichern. Auf diese Weise bietet der Smart Contract einen Hinweis auf „weitere Informationen“ und eine Möglichkeit, die Genauigkeit der von diesem Ort geladenen Daten zu bestätigen.

Der einzige Weg, die genauen Kosten für Byte-für-Byte-On-Chain-Speicherung zu kennen, besteht darin, etwas auszuprobieren und zu messen. Dazu gehört, eine Richtung zu finden und zu codieren. Dazu werden hier einige Grundmuster und deren Stärken und Schwächen aufgezeigt:

Gibt es gut gelöste und einfache Speichermuster für Solidity?

Diese Muster sind so konzipiert, dass die Gaskosten in jeder Größenordnung konsistent sind. weil es von entscheidender Bedeutung ist, zu vermeiden, etwas mit steigenden Kosten zu entwerfen, wenn der Datensatz wächst. Ein verlinkter Artikel am Ende zeigt gemessene Gaskosten für das Beispiel.

Auffallend fehlt in dieser Liste jede Form des Sortierens/Ordnens . Ein Smart Contract, der sich auf Integrität konzentriert, kann diese Überlegung oft außer Acht lassen. Das heißt, wenn Kunden bestellte Daten benötigen, können häufig Optimierungen auf Kundenseite erarbeitet werden. Die Smart Contracts werden erheblich vereinfacht, indem sie sich auf das Zulassen / Verbieten von Einfügungen, Löschungen, Aktualisierungen usw. konzentrieren. Benötigt selten eine sortierte Liste.

Allerdings ist eine verknüpfte Liste eine kostengünstige Möglichkeit, bei Bedarf durchsuchbare geordnete Ergebnisse zu erzielen. Hier finden Sie ein experimentelles LinkedList- Beispiel:

https://bitbucket.org/rhitchens2/soliditystoragepatterns

Auch hier liegt der Schwerpunkt auf Einfachheit und konsistenten Gaskosten in jeder Größenordnung. Es funktioniert einfach nicht, wenn die Kosten für Operationen wie Einfügen und Finden mit der Größe des Datensatzes steigen.

Außerdem eine verallgemeinerte Sammlung und ein experimentelles Beispiel zum Erzwingen der referenziellen Integrität in einer Eins-zu-Viele-Beziehung. Code im oben verlinkten Repo. Erklärung hier: https://medium.com/@robhitchens/enforcing-referential-integrity-in-ethereum-smart-contracts-a9ab1427ff42

Ich hoffe es hilft.

Gaskostendatenbank in Smartcontract
AntwortenHierDatenschutz-Bestimmungen1y, 0v