Was ist der Vorteil, neue intelligente Vertragssprachen wie Solidity zu erstellen, anstatt andere Sprachen zu verwenden?

Jede Programmiersprache ist für eine bestimmte Einsatzumgebung und Zielaufgaben konzipiert; und diese Einschränkungen bestimmen fast alle Designentscheidungen darüber, welche Funktionen unterstützt und welche weggelassen werden sollen.

Vor einiger Zeit habe ich ziemlich viel Zeit damit verbracht, einen Go -> EVM-Cross-Compiler zu erstellen. Ich habe es geschafft, ein paar triviale Programme auszuführen, und es hat definitiv viel Spaß gemacht, aber ziemlich bald habe ich begonnen, die Grenzen der EVM zu stoßen, die mit den Kernannahmen hinter Go kollidieren:

• Jede Goroutine benötigt mindestens 64 KB Speicher. Heutzutage trivial niedrig für jede anständige Hardware, aber exorbitant hoch und teuer für das EVM.
• Go stützt sich auf den Speichermanager auf Betriebssystemebene. Das bedeutet, dass wir zum Ausführen von Go-Programmen auf der EVM einen Mikrospeichermanager auf der EVM entwickeln müssten, der die von Go benötigten Operationen unterstützen kann. Ich habe eine POC-Version des Buddy Memory Allocation -Algorithmus entworfen , aber diese basiert auf der Tatsache, dass der Speicher begrenzt und fest ist, und weist darin beliebige Teile zu. Die EVM hingegen ist "unendlich" und berechnet pro maximal zugewiesenem Offset. Alle üblichen Speicherzuweisungsalgorithmen würden also leiden, da sie davon ausgehen, dass die Speicherkosten konstant sind, während die EVM positionsabhängig und sogar exponentiell ist.
• Go ist eine Garbage Collection-Sprache, daher muss jede Speicherzuweisung auch Referenzzähler verwalten, die gut mit dem Speicherzuordner zusammenarbeiten müssen. Wieder nicht unmöglich zu lösen, aber die damit verbundenen Opcode- und nichtlinearen Speicherkosten machen dies sehr teuer.
• Selbst wenn die Speicherprobleme gelöst sind, müssen Sie immer noch Lösungen für Synchronisierungsprimitive, Betriebssystemunterbrechungen und andere Speicherkonstrukte finden, die wir für selbstverständlich halten, die EVM jedoch nicht hat.

Diese Herausforderungen waren die Hauptgründe, warum ich mich gegen die Fortsetzung meiner Portierung von Go auf die EVM entschieden habe, aber sie zeigen wirklich, dass moderne Sprachen auf unzähligen Funktionen basieren, die die zugrunde liegenden Betriebssysteme unterstützen, die wiederum auf Annahmen über die zugrunde liegende Hardware beruhen Leistungsfähigkeit und die damit verbundenen Kosten.

Die EVM ist in dieser Hinsicht ein ganz anderes Biest, sodass die Anwendung derselben Annahmen zu einer höchst suboptimalen Codeausführung führt. Daher wurde die Entscheidung getroffen, eine speziell auf die EVM-Ausführungsumgebung zugeschnittene Sprache zu entwickeln. Es ist in der Tat wahrscheinlich viel mehr Arbeit, als eine vorhandene Sprachsyntax (!) zu portieren , aber es führt auch zu einer brauchbaren Umgebung im Vergleich zu allen möglichen "dokumentierten Einschränkungen", dass etwas zwar gültiger Go-Code ist, aber nicht verwendet werden kann weil "xyz".

Beachten Sie, dass es sehr gut sein kann, dass das ursprüngliche EVM-Design schlecht ist und erweitert, aktualisiert oder sogar vollständig ersetzt wird, wenn jemand eine viel bessere Lösung findet, um Dinge zu tun. Aber das ist eine zukünftige Möglichkeit, während Solidität ein aktuelles Bedürfnis ist.

Insbesondere in der Welt der Smart Contracts ist der Code so konzipiert, dass er mit EVM zusammenarbeitet, und daher gibt es einige wichtige Anforderungen an eine Sprache, die in Smart Contracts verwendet werden soll.

1. Der Compiler muss in der Lage sein, Code auszugeben, der für die Codegröße optimiert ist (während viele andere Sprachen dazu neigen, die Berechnungseffizienz zu optimieren).

2. Optimieren Sie für Sicherheit und Revisionsfähigkeit.

Es ist auch möglich, dass es andere organisatorische/soziale Vorteile für die Verwendung einer neuen Sprache gibt, wie z

3. Eine viel größere Flexibilität Ihrer Compiler-Entwurfsentscheidungen (niemand wird versuchen, bestehenden Code auf Ihrem neuen Compiler zu verwenden und sich darüber beschweren, dass er nicht funktioniert)

Siehe die andere Antwort von @Péter Szilágyi für ein Beispiel für den Versuch, die Go-Sprache zu verwenden, um in einen EVM-Bytecode zu kompilieren

Referenz: Vitalik antwortet, warum eine neue Sprache in AMA

Es gibt mehrere Herausforderungen. Zunächst einmal neigen vorhandene C++- und andere Compiler dazu, Code auszugeben, der wirklich nicht für kompakte Codegröße optimiert ist; z.B. Selbst das einfachste Programm gibt eine Datei aus, die länger als 4 KB ist. Das ist in Ordnung für Computer, wo Speicher billig ist, aber schrecklich für Blockchains, wo Speicher teuer ist. Daher sind spezialisierte Compiler erforderlich

Zweitens müssen intelligente EVM-Vertragssprachen mit einem besonders starken Fokus auf Sicherheit entwickelt werden, was den meisten bestehenden Sprachen nicht im gleichen Maße am Herzen liegt.

Ich bin mir nicht sicher, ob es einfach wäre, meine Antwort in die Antwort von @ Péter Szilágyi einzufügen, also mache ich sie zu einer separaten.