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:
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.
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.
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.
Turm
bool
Typ 255 Bit verschwendet, macht mich verrückt.Ismael
Turm
Turm
Ismael
Turm