Könnte Ethereum eine breite Vertragssprachenunterstützung wie NEO erhalten?

Ich werde versuchen, eine Antwort auf die technischen Teile der Frage zu geben. Ich hatte den gleichen Gedanken über die Wiederholung der Geschichte oder Schriftsteller, die nicht wussten, wovon sie sprachen, als ich die Werbung für mehrere Sprachen als ein Merkmal von NEO mit Ausnahme von Ethereum sah.

Die kurze Antwort ist nein, der Mangel an Sprachunterstützung in Ethereum ist keine intrinsische Eigenschaft von Ethereum.

Da sowohl NEO als auch Ethereum Turing-vollständig sind, können sie nachweislich zur gegenseitigen Implementierung verwendet werden (die Begriffe, die wir jetzt verwenden, wurden aus vielleicht offensichtlichen Gründen in diesem Papier nicht verwendet); Das heißt, selbst wenn sie nicht dieselben Programme direkt ausführen können, kann die virtuelle NEO-Maschine (VM) eine virtuelle Ethereum-Maschine simulieren und umgekehrt, wobei die simulierte Maschine verwendet wird, um die Eingabe auszuführen, mit einigen Einschränkungen.

Die oben genannten Vorbehalte sind indirekt relevant für NEO und Ethereum. Der erste Vorbehalt ist, dass die emulierte Ausführungsgeschwindigkeit langsamer ist als bei einer vergleichbaren virtuellen Maschine; Gemessen in Anweisungen erfordert ein Ethereum-nativer Kontrakt weniger Anweisungen zur Ausführung (und kostet somit weniger Gas) als die Ausführung eines Kontrakts, der die NEO-VM emuliert, die einen NEO-Kontrakt ausführt. Letzteres zu tun ist natürlich albern. Wir würden einfach nativen Code schreiben. Dies führt zum zweiten Vorbehalt: Nicht jede Anweisung einer VM kann effizient emuliert werdenvon einer anderen VM. Beispielsweise ist es auf Computern ohne Gleitkommaeinheiten relativ rechenintensiv, Gleitkommaberechnungen durchzuführen – aber es ist immer noch möglich. Deutschland, die Einführung von zkSNARKS in Ethereum in Metropolis wird es ermöglichen, etwas in Verträgen umzusetzen, das vorher nicht realisierbar gewesen wäre. Ein weiterer Vorbehalt ist, dass die Eingabe/Ausgabe (E/A) und Peripheriegeräte, die den virtuellen Maschinen zur Verfügung stehen, nicht gleich sind – insbesondere kann eine Ethereum-VM derzeit nicht direkt mit der NEO-VM interagieren, und ich gehe davon aus, dass auch das Gegenteil der Fall ist. Es gibt andere Vorbehalte, die ich überspringen werde (z. B. Speichereinschränkungen durch die Portierung), aber die oben genannten sind vielleicht die größten Vorbehalte.

Es ist möglich, dass NEO über eine größere Anzahl von schnellen nativen Operationen verfügt, die es einfacher machen, eine größere Anzahl von Operationen effizient zu unterstützen, aber wenn sich dies als nützlich erweist, wird jemand sicher eine EIP vorschlagen, um Unterstützung für die hinzuzufügen Anweisung. In der Zwischenzeit, wenn man wirklich in einer bestimmten Sprache schreiben wollte, könnte man auch einen Cross-Compiler schreiben (oder einen neuen EVM-Compiler und -Optimierer für das Parsing-Frontend eines bestehenden Compilers schreiben) und etwas zusätzliche Unterstützung hinzufügen, um Blockchain I zu handhaben /O wie Ermittlung der aktuellen Blocknummer und Zustandsverwaltung.

Nach einigem weiteren Lesen scheint es, als ob NEO einige E/A-Funktionen hat, die Teil seiner VM sind, die nicht Teil von Ethereums sind – insbesondere Auslöser, die dazu führen, dass Verträge ausgeführt werden, wie z. B. das Auslösen an einem bestimmten Datum oder bei einem anderen Konto ein bestimmtes Gleichgewicht erreicht). In NEO ist es ein bisschen wie bei Interrupt-gesteuerten Rückrufen; in Ethereum kann dies (ohne die EVM zu modifizieren) durch externe Abfragen wie Ethereum Alarm Clock erfolgen. Dies hat natürlich keinen Einfluss darauf, welche Sprachen unterstützt oder unterstützt werden.