Warum werden nicht alle Verträge erstellt?

Es gibt viele Vorschläge, aus verschiedenen Gründen vorkompilierte Verträge hinzuzufügen. Ich verstehe jedoch nicht, warum ein vorkompilierter Vertrag effizienter wäre als ein tatsächlicher Vertrag. Wenn das der Fall ist, bedeutet das nicht, dass die EVM nicht ausreichend optimiert ist? Was hält Ethereum davon ab, jeden Vertrag zu erstellen; vielleicht mit LLVM?

Antworten (2)

Ein vorkompilierter Vertrag ist, wie ich es verstehe, tatsächlich protokollsubventioniert . Das heißt, obwohl es technisch gesehen Code an einer bestimmten Adresse gibt, ist der Gaspreis weitaus geringer, als wenn er manuell ausgeführt würde. Wenn ich das gelbe Papier richtig verstehe, kostet ECDSARECOVER nur 3000 Benzin.

Dies funktioniert, weil effizienterer externer Code für verschiedene Implementierungen geschrieben werden kann (falls noch nicht vorhanden) und dann einfach eingefügt wird, wenn der Vertrag ausgeführt wird. Dies ist jedoch nicht unbedingt der Fall für einen zufälligen Vertrag außerhalb der Blockchain.

Ich glaube, Geth hat einen begrenzten JIT-Compiler für Smart Contracts, was zu einem weiteren Problem beim Kompilieren jedes Vertrags führt: Speicherplatz. Es gibt nur so viel Platz, um vernünftigerweise kompilierte Verträge zwischenzuspeichern, insbesondere unter Berücksichtigung potenzieller Angreifer. Geth scheint es derzeit standardmäßig auf 64 Kontrakte zu beschränken, und ich habe erhebliche Diskussionen über Gitter über Algorithmen (nicht unbedingt Geth-bezogen) gehört, um welche auszuwählen.

Sind Vorkompilierungsverträge resistent gegen Dekompilierung von beispielsweise Porosity github.com/comaeio/porosity ?
Ich bin mir nicht sicher, in welcher Sprache die Vorkompilierungen geschrieben sind (möglicherweise LLL?), Aber sie sind Open Source. Außerdem würde nur die naivste Implementierung den Code tatsächlich ausführen, wenn es einen Fehler geben sollte, anstatt nur den bereits vorhandenen Code außerhalb der EVM zu verwenden.

Matthäus Antwort ist richtig. Ich möchte jedoch hinzufügen, dass eines der Ziele von Ethereum 2.0 darin besteht, diese vorkompilierten Verträge loszuwerden. Da sie von allen Kunden implementiert werden müssen, ist das Risiko von Segmentierungsproblemen hoch. Dieses Risiko wird gemildert, indem die Anzahl der vorkompilierten Verträge extrem gering gehalten wird (im Moment 4; weitere 4 im kommenden Januar-Update IIRC).

Vorkompilierte Verträge können vermieden werden, wenn On-Chain-Verträge sie implementieren oder On-Chain-Bibliotheksverträge aufrufen, die sie implementieren. Ich glaube, dies ist eines der vielen Designziele beim Wechsel von altem EVM-Code zu eWASM, das über eine ausreichend schnelle VM verfügen würde, um diese Funktion zu unterstützen.