Im Gelbbuch heißt es:
Dies sind vier sogenannte „vorkompilierte“ Verträge, die als vorläufige Architektur gedacht sind, die später zu nativen Erweiterungen werden können. Die vier Verträge in den Adressen 1, 2, 3 und 4 führen die Elliptic-Curve-Public-Key-Recovery-Funktion, das SHA2-256-Bit-Hash-Schema, das RIPEMD-160-Bit-Hash-Schema bzw. die Identitätsfunktion aus.
Was ist ein vorkompilierter Vertrag und wie unterscheiden sie sich von nativen Opcodes? Was bringt es, wenn ein vorkompilierter Vertrag zu einer nativen Erweiterung wird? Warum wurde SHA2-256 angesichts der weit verbreiteten Verwendung nicht nativ implementiert?
Auch wenn ich den wahren Grund nicht kenne, versuche ich es zu erraten. Es gäbe folgende Überlegungen:
Größe des Namensraums . Es gibt nicht so viele mögliche Opcodes, daher müssen diese sehr sparsam zugewiesen werden. Der Raum der Vertragsadressen ist dagegen praktisch unbegrenzt.
Risiko der Wiederverwendung von Namen . Es ist ein gutes Software-Engineering-Prinzip, Namen (oder Opcodes) nicht wiederzuverwenden, insbesondere in einem System, in dem man die Upgrades nicht kontrolliert.
Dienstprogramm . Es gibt einige Operationen, die immer nützlich sind, wie arithmetische Operationen, Bittwiddling, Flusskontrolle und andere. Andererseits könnten sich kryptografische Primitive in der Zukunft als unzureichend erweisen, und stattdessen wird etwas anderes verwendet werden. Solche Primitive in Opcodes umzuwandeln, geht das Risiko ein, wertvollen Namensraum für etwas zu verschwenden, das veraltet sein könnte.
Sanfte Werbung für beliebten/nützlichen Code . Wenn bestimmte Dinge, zum Beispiel zkSNARKs-Operationen oder die Dogecoin-PoW-Verifizierung, beginnend mit Solidity-Code und dann teilweise optimiert, sehr nützlich und beliebt werden, könnten sie zu vorkompilierten Verträgen werden. Eine solche Beförderung ist eine viel sanftere Änderung des Netzwerks als die Einführung eines neuen Opcodes.
Keine Autorität, aber ich kenne jemanden, der...
Aus dem Artikel von Vitalik, Eine Vorgeschichte des Ethereum-Protokolls
Die zweite war die Idee von „Precompiles“, die das Problem lösen, komplexe kryptografische Berechnungen in der EVM nutzbar zu machen, ohne sich mit EVM-Overhead befassen zu müssen. Wir hatten auch viele ehrgeizigere Ideen zu „nativen Verträgen“ durchgearbeitet, bei denen Bergleute, wenn sie eine optimierte Implementierung einiger Verträge haben, den Gaspreis dieser Verträge „abstimmen“ könnten, so dass Verträge, die die meisten Bergleute viel schneller ausführen könnten, natürlich hätten ein niedrigerer Gaspreis; Alle diese Ideen wurden jedoch verworfen, weil wir keinen kryptoökonomisch sicheren Weg finden konnten, so etwas zu implementieren. Ein Angreifer könnte immer einen Vertrag erstellen, der eine kryptografische Operation mit Falltür ausführt, die Falltür an sich selbst und seine Freunde verteilen, damit sie diesen Vertrag viel schneller ausführen können, Wählen Sie dann den Gaspreis nach unten und verwenden Sie dies, um das Netzwerk zu doSen. Stattdessen haben wir uns für den viel weniger ehrgeizigen Ansatz entschieden, eine kleinere Anzahl von Vorkompilierungen zu haben, die einfach im Protokoll angegeben sind, für allgemeine Operationen wie Hashes und Signaturschemata.
Ich glaube nicht, dass es eine "richtige Antwort" darauf gibt, ob eine bestimmte Funktionalität vorkompiliert oder nativ sein muss. Es sieht so aus, als wäre es aus all den zuvor genannten Gründen auf ein Designurteil hinausgelaufen. Wenn VB oder Gavofyork nicht selbst eingreifen, werden wir es nie mit Sicherheit wissen …
T9b