Gibt es eine (theoretische) Grenze für die Datenmenge, die ein Vertrag speichern kann?

Gibt es eine theoretische Grenze für die Datenmenge, die ein Vertrag speichern kann, während er in einem privaten Netz läuft, in dem Gas keine Rolle spielt?

Kontext: In einer Finanz-DApp, die globale Zahlungssysteme ersetzen soll, ist der tx/s-Durchsatz sicherlich ein limitierender Faktor, der viel diskutiert wird. Aber darum geht es mir hier nicht. Kann ein Vertrag 1 GB, 1 TB, ... Daten in einem Vertrag speichern? Die Daten würden nicht auf einmal geschrieben, sondern würden sich im Laufe der Zeit ansammeln.

Beispiel: Nehmen wir ein Best-Case-Szenario an, in dem wir es schaffen, eine einzelne Transaktion von Token, die auf einem Smart Contract leben, in 100 Bytes zu quetschen. Bei einem Durchsatz von 1000 tps würde dies 100*1000*3600*24*31*12 = 3,2 TB/Jahr ergeben. Sie können gerne raten, ob / wann dies möglich sein wird.

Sind Sie sich zu 100 % sicher, dass Sie all diese Aufzeichnungen für die Ewigkeit aufbewahren müssen? Wenn es darum geht, Dinge zwischen Parteien zu kommunizieren, ist die Verwendung von Flüsternachrichten möglicherweise besser. Eine andere Möglichkeit wäre, einen 32-Byte-Hash zu speichern, der auf die echten Daten in Swarm oder IPFS usw. verweist.
Guter Punkt, ich bin mir ziemlich sicher, dass ich sie nicht für alle Ewigkeit brauche, sondern nur versuche, die Grundlagen zu verstehen. Ich bin mir sicher, dass ich all diese Aufzeichnungen anfangs haben möchte, aber es wäre großartig, wenn ich sie nach N Blöcken zu IPFS verschieben könnte – zB nach einem typischen Auditierungszeitraum von einem Jahr. Es scheint derzeit schwierig, dies in einem Vertrag ohne Zentralisierung umzusetzen (verlassen Sie die Blockchain auf IPFS und stellen Sie sicher, dass sich jetzt die richtigen Dinge in IPFS befinden).

Antworten (2)

Vertragsspeicher ist ein Schlüssel von 32 Bytes und ein Wert von 32 Bytes, sodass ein einzelner Vertrag maximal etwa 1,46 GB (32^32) speichern kann.

FALSCH. Es gibt 2^256 verschiedene Schlüssel, und jeder Schlüssel kann 32 Bytes speichern, also könnten insgesamt 2^261 Bytes gespeichert werden. Das heißt, bis dahin wird die Ethereum-Blockchain wahrscheinlich aufgrund einer Hash-Kollision brechen....

Danke, ich habe meinen Kommentar hier aktualisiert und werde ihn korrigieren ethereum.stackexchange.com/questions/986/…
Was meinst du damit break, wird die ganze Blockchain scheitern? Gibt es keine Prüfungen auf doppelte Hashes? Muss die Transaktion zurückgespult/wiederholt werden, bis keine Kollision mehr auftritt?
@BlockChange Wenn doppelte Hashes entdeckt werden, gibt es viel größere Probleme, da dies bedeuten würde, dass der Hash-Algorithmus beschädigt wurde. Als Referenz für @ 2 ^ 261, vorausgesetzt, Sie können 1 Hash pro Pikosekunde berechnen, benötigen Sie immer noch mehr Zeit als wir bis zum Hitzetod des Universums haben, um einen solchen Konflikt zu finden, es sei denn, der Hash-Algorithmus ist kaputt
2^261 = #Bytes, die mit 2^256 Adressen gespeichert werden können, die jeweils 2^5 (=32) Bytes speichern. Es hat nichts mit dem Hashing-Algorithmus zu tun. Der verwendete Hash-Algorithmus ist Keccak 256-Bit-Hash, der 2 ^ 256 mögliche Hash-Werte ergibt, aber Sie müssten nicht bis zum letzten warten, damit eine Kollision auftritt. Erinnern Sie sich an das Geburtstagsproblem (auch bekannt als Geburtstagsparadox). Kollisionswahrscheinlichkeit > 99 % nach 2^130 Werten. Mit 2 ^ 160 dieser Werte als Adressen von 2 ^ 160 Verträgen, P (Kollision) > 99,999999 .... % (nicht sicher, wie viele 9 nach dem Dezimalkomma)
@Earlz - Der Punkt ist, dass es in einem Jahrtausend (1000 Jahre) ungefähr 2 ^ 35 Sekunden gibt. Bei der Erstellungsrate von 1 Vertrag pro Sekunde würde es also 2^125 Jahrtausende dauern, um 2^160 Verträge zu erstellen. Das Erhalten von Kollisionen lange vorher bedeutet NICHT, dass der Hash-Algorithmus "kaputt" ist.
in der realen Implementierung kann es nicht buchstäblich 2 ^ 261 sein, oder? Es kann sich nicht vorstellen, dass es physikalisch möglich ist. Müssen wir den Hash nicht um die tatsächliche Speichergröße modulieren? Was ist in diesem Fall diese tatsächliche Speichergröße?

Vertragsspeicher ist ein Schlüssel von 32 Bytes und ein Wert von 32 Bytes, sodass ein einzelner Vertrag maximal etwa 2^261 Bytes (2^256 * 32b) speichern kann.

In einer privaten Kette, in der Gas keine Rolle spielt, können 2 ^ 160 Verträge erstellt werden, da der Adressraum 160 Bit beträgt, vorausgesetzt, er kann vollständig verwendet werden. Theoretisch sind also etwa 2^421 Bytes das Maximum, das Verträge speichern können.

Sie würden auf Hash-Kollisionen stoßen, lange bevor Sie 2^160 Verträge erstellt haben; 2^80 ist wahrscheinlich eine vernünftigere Schätzung.
Warum sollte es zu einer Hash-Kollision kommen, nachdem Sie 2^80 Verträge erstellt haben? @ NickJohnson
Kann der Wert eines Schlüssels ein sein struct, der größer als 32 Bytes sein kann? @eth♦
@Alper Die Schlüssel des Vertragsspeichers können nur 32 Byte lang sein.
Gibt es eine (theoretische) Grenze für die Datenmenge, die ein Vertrag speichern kann?
AntwortenHierDatenschutz-Bestimmungen1y, 0v