Aus dem Artikel: Gibt es gut gelöste und einfache Speichermuster für Solidity?
Ignoriert man die Kosten, weiß jemand, wie viele Variablen/Zeilen ein Soliditätsvertrag mit jedem der Typen verarbeiten kann? Oder ist dies vor allem durch die Transaktionsgröße begrenzt?
Genauer gesagt, wann wird mein Vertrag scheißen?
struct DocumentStruct{
bytes32 name;
uint value;
}
mapping(bytes32 => DocumentStruct) public documentStructs;
function StoreDocument(bytes32 key, bytes32 name, uint value) returns (bool success) {
documentStructs[key].name = name;
documentStructs[key].value = value;
return true;
}
Scale-Varianten-Lösungen, also Prozesse mit Rechenaufwand, der mit der Größe der Tabelle steigt, sind (allgemein gesagt) schlechter Stil für Solidity Contracts, da die Kosten der Funktionen so lange steigen werden, bis entweder a) die Kosten für die Nutzung des Contracts unwirtschaftlich werden oder b) das SperrgasLimit überschritten wird. Bedingung b) macht es unmöglich, die Funktion um jeden Preis auszuführen .
Jedes der Muster ist so ausgelegt, dass es skaleninvariant ist. Die Gaskosten werden in jeder Größenordnung gleich sein . Wie Thomas betonte, ist max rows eine wirklich große Zahl. Es würde eine wirklich große Gasinvestition darstellen.
Sie können jedes der Beispiele oder Ihre eigene Implementierung der Muster ausführen, testen (z. B. mit Remix) und darauf vertrauen, dass sich das Gas und die Leistung nicht ändern, wenn die Tabellen größer werden. Mit anderen Worten, Sie können (und sollten) Ihre Kosten kennen.
Die Kosten würden nicht unbedingt vom Vertragsinhaber getragen werden. Wenn Verträge so gestaltet sind, dass die Gasausgaben mit den Vorteilen für die Benutzer in Einklang gebracht werden, können wir uns vorstellen, dass diese Kosten gerecht auf die Benutzer verteilt werden, die den Datensatz erstellen.
Während die Solidity-Vertragsbeispiele auf effiziente und durchweg bescheidene Gebühren ausgelegt sind, beeinflussen zwei Faktoren den zukünftigen Preis von Updates. Erstens beeinflussen die Marktkräfte den Preis von ETH und damit Gas. Zweitens können zukünftige Protokolländerungen die Kosten von Operationen auf niedriger Ebene ändern, aus denen das Gesamtgas berechnet wird.
Dieser zweite Punkt verdient Erwähnung. Obwohl der Code gleich große Operationen und Kontrollflüsse in jeder Größenordnung beibehält, werden die aktuellen Gasschätzungen natürlich von Ethereums „Preisliste“ für die Operationscodes berechnet. Periodische Anpassungen der Preisliste sind denkbar (Protokolländerungen). Zukünftige Änderungen der Preisliste und der zukünftige Wert von Eth lassen sich meiner Meinung nach nicht genau vorhersagen .
Als Auftragsdesigner ist es meiner Meinung nach die beste Haltung , konsistente und niedrige Gesamtkosten anzustreben, da dies sicherstellt, dass die Funktionen in jeder Größenordnung ausführbar sind.
Ich hoffe es hilft.
Die obige Antwort ist technisch falsch. Ihr Vertrag kann nicht mehr als 2^256-1 Einträge speichern, aber diese Zahl ist so groß, dass sie nicht annähernd voll werden kann.
Der wichtigere Punkt sind die Kosten, die mit der Speicherung von Daten in der Blockchain verbunden sind. Ich habe irgendwo gelesen, dass das Speichern von nur einem Megabyte viele tausend Dollar kosten könnte, und das war, bevor der Preis für Ether in die Höhe schoss.
Sie sollten auf jeden Fall verstehen, wie viel es kosten wird, bevor Sie planen, zu viele Daten in der Kette zu speichern. Stattdessen speichern die Leute die Daten in IPFS und speichern nur den Hash dieser Daten in der Kette.
Eigentlich ist deine Frage nicht so eindeutig. Meinen Sie, gibt es eine Begrenzung der Größe der Vertragsvariablen?
Der Vertrag, den Sie oben schreiben, ist legal und Sie müssen sich keine Sorgen machen, dass die Variable documentStructsüberläuft.
MapTyp ist ein dynamischer Typ in Solidität, jedem Element in der Karte wird ein eindeutiger Speicherplatz (durch Hash-Funktion berechnete Adresse) zum Speichern zugewiesen. Die Speichergröße ist unbegrenzt. Daher wird eine Karte konzeptionell gesehen niemals überlaufen.
Hier ist ein Link , darin ist die Vertragslagerorganisation anschaulich beschrieben. Hoffe es kann dir helfen.
Ignoriert man die Kosten, weiß jemand, wie viele Variablen/Zeilen ein Soliditätsvertrag mit jedem der Typen verarbeiten kann?
Dies gilt nicht speziell für das Hinzufügen von Einträgen zu Ihrer mapping, aber im Allgemeinen ist die Größe des Stapels zu beachten.
Das Hinzufügen lokaler Variablen zu einer bestimmten Funktion würde wahrscheinlich zu einem „Stack too deep“-Fehler führen, wie in diesem vorherigen Thread beschrieben:
Fehler beim Kompilieren: Stapel zu tief
Früher waren 17 lokale Variablen (ich glaube typinvariant ) die Grenze.
das Fett