Wäre ein 64-Bit-basiertes EVM im Ethereum-Ökosystem nicht effizienter?

Wie das Ethereum Rationale -Design sagt:

32-Byte-Wortgröße – die Alternative sind 4- oder 8-Byte-Wörter, wie bei den meisten anderen Architekturen, oder unbegrenzt, wie bei Bitcoin. 4- oder 8-Byte-Wörter sind zu restriktiv, um Adressen und große Werte für Kryptoberechnungen zu speichern, und unbegrenzte Werte sind zu schwierig, um ein sicheres Gasmodell zu erstellen. 32 Bytes sind ideal, da sie gerade groß genug sind, um 32-Byte-Werte zu speichern, die in vielen Krypto-Implementierungen üblich sind, sowie Adressen (und die Möglichkeit bieten, Adresse und Wert als Optimierung in einen einzigen Speicherindex zu packen), aber nicht so groß als äußerst ineffizient.

Aber die Sache ist:

  • Eine 256-Bit-EVM-Implementierung hilft, um mit Adressen zu arbeiten, und das stimmt. Aber da Ethereum nicht als Kryptowährungssystem definiert ist, wäre der wichtigste Teil der Daten keine Adressen, sondern Daten, die für Smart Contracts verwendet werden .
  • Wenn die Mehrheit der CPUs auf dem Markt tatsächlich mit einer 64-Bit-Architektur hergestellt wird und ein hoher Prozentsatz der Daten, mit denen wir im Ethereum-Ökosystem arbeiten, ungefähr gleich sind (64 Bit, 32 Bit, 16 Bit, 8 Bit. .). Glauben Sie, dass ein EVM auf Basis einer 64-Bit-Architektur oder etwas Ähnlichem die Leistung des gesamten Systems nicht verbessern würde?

Denken Sie darüber nach, wenn Sie ein Array von 32- oder 64-Bit-Daten iterieren müssen und die EVM-Speicherblöcke 256-Bit sind, bedeutet dies zusätzliche Arbeit für die CPU, um die Berechnungen durchzuführen, und es geht viel Zeit verloren.

Wenn Sie denken, dass dies eine mögliche Verbesserung wäre, gibt es eine Initiative oder EIP, die offen ist? Ich habe nichts gesehen.

Vielen Dank.

Antworten (2)

Sie werden mehrere Probleme haben

  • Wenn Sie Ihren Speicher auf 256 Bit belassen, wird der Zugriff komplexer. Sie benötigen 4 x 64-Bit-Wörter, um einen Speicherplatz zu adressieren. Alle Operationen müssen 256 Bit in 64 Bit konvertieren. Ihre EVM wird ziemlich komplex zu implementieren und zu auditieren sein.

  • Wenn Sie den Speicher auf 64 Bit umstellen, ist Ihre EVM einfacher, aber der Speicher ist viel kleiner und Kollisionen viel wahrscheinlicher.

  • Sie können Adressen nicht nativ darstellen. Adressen sind 20 Bytes groß und Sie benötigen 3 x 64-Bit-Register.

  • Sie benötigen Abwärtskompatibilität mit alten Verträgen, und Sie müssen eine Art Übersetzer implementieren.

Die CPU ist nicht der Flaschenhals. Sicher, es gibt bessere VMs (und es gibt Untersuchungen darüber, sie durch WASM zu ersetzen), aber die aktuelle Implementierung erfüllt ihre Aufgabe korrekt.

Das wichtigere Thema ist IO, jede Transaktion hat ein paar Modifikationen des Ethereum World Zustands. Und ein Block hat ungefähr hundert Transaktionen, und alle 15 Sekunden wird ein Block generiert.

Der Wechsel zu 64-Bit ist ein äußerst wichtiges Upgrade für Ethereum, und die Verwendung einer 256-Bit-Maschine war ein Fehler. Ismael, wie viel Maschinencode hast du geschrieben? Die Art und Weise, wie Sie von Registern sprechen, lässt mich glauben, dass Sie Maschinencode nicht verstehen. Die Verwendung eines 32-Bit-Rechners würde die Sicherheit nicht beeinträchtigen und die Gasgebühren aufgrund von Platzverschwendung senken – sogar noch mehr als ein 64-Bit-Rechner, da wir weniger Nullen speichern würden. Die Tatsache, dass der boolTyp 255 Bit verschwendet, macht mich verrückt.
@rook Greife nicht die Person an, sondern das Argument. Mit den heute verfügbaren Informationen und den Projektanforderungen würde ich mich für eine 64-Bit-VM entscheiden, aber vor 7 Jahren war die Erfahrung nicht dieselbe. Wenn Sie sich in der Lage fühlen, schreiben Sie die 64-Bit-EVM und schlagen Sie die Änderung an der EF vor. Wenn es gut ist, wird es angenommen, Sie bekommen jeden Job, den Sie wollen, und werden entsprechend bezahlt. Es ist einfach zu reden, etwas zu schreiben, das funktioniert, ist viel schwieriger.
-Entschuldigen Sie. Es spielt keine Rolle, wie viele Register eine Variable belegt, da diese Maschinen einen Opcode haben sollten, der mehrere Registervergleiche durchführen kann. Indem Sie alle Variablen auf 256 Bit setzen, speichern Sie am Ende mehr Nullen als tatsächliche Daten, und genau das sehen wir. Ich würde gerne diese VM schreiben, das ist nicht schwierig, weil es nichts Neues ist. Das erste EVM war völlig neu, und das war schwer zu bewerkstelligen – und dafür habe ich Mitgefühl. Aber jetzt, wo wir sehen können, dass die EVM mehr leeren Speicherplatz als echte Daten speichert, haben wir ein echtes Problem.
Eigentlich, wenn sie Ingenieure für dieses Projekt brauchen, habe ich einen großartigen Lebenslauf. Für diesen Fall hat x86 also 8 Allzweckregister, was bedeutet, dass auf einem 64-Bit-System zwei vollständige 256-Bit-Schlüssel geladen werden können, und dann ist ein Vergleich eine einzelne Operation. Die EVM sollte diesem Muster folgen, mit wem muss ich sprechen?
@rook Die Ethereum Foundation und andere Organisationen haben Förderprogramme, die jeder beantragen kann, ethereum.org/en/community/grants . Bevor Sie sich bewerben, würde ich vorschlagen, an einigen der Foren teilzunehmen und nach anderen Forschungsinteressen wie ethresear.ch zu suchen .
@ishmael Danke, du bist eine große Bereicherung für diese Community und eine freundliche Person.

Natürlich ist es schwierig, das mit Sicherheit zu sagen, aber meiner Intuition nach ist der Engpass nicht die Größe der Wörter. Der Flaschenhals ist das gezielte Auferlegen der 14-Sekunden-Blockzeit. Die Blockzeit ist ein Parameter, den die ursprünglichen Designer gewählt haben, um die Bergleute zu zwingen, Energie in Form von Strom zu verbrauchen. Selbst wenn Sie an anderer Stelle im System optimiert haben, würden diese 14 Sekunden nicht verschwinden, sodass sich die Optimierung nicht manifestieren würde.

Ja, aber mit dem Übergang zu PoS und anderen Konsensmethoden ist es nicht so wichtig, dass feste Blockzeiten und wichtigere Dinge wie diese EVM-Implementierung. Deshalb habe ich darum gebeten.
Wenn wir also zu PoS migrieren, gibt es viel mehr Platz, um die Architektur von EVM zu verbessern?