¿Ethereum podría obtener un amplio soporte de lenguaje contractual como NEO?

Intentaré una respuesta en las partes técnicas de la pregunta. Tuve el mismo pensamiento sobre la repetición de la historia o los escritores que no sabían de lo que estaban hablando cuando vi la promoción de múltiples idiomas como una característica intrínseca de NEO con la exclusión de Ethereum.

La respuesta corta es no, la falta de soporte de idiomas en Ethereum no es una propiedad intrínseca de Ethereum.

Dado que tanto NEO como Ethereum son Turing-completo, pueden, como se ha demostrado, usarse para implementarse mutuamente (los términos que usamos ahora, quizás por razones obvias, no se usaron en este documento); es decir, incluso si no pueden ejecutar los mismos programas directamente, la máquina virtual NEO (VM) puede simular una máquina virtual Ethereum y viceversa, utilizando la máquina simulada para ejecutar la entrada, con algunas advertencias.

Las advertencias de lo anterior son indirectamente relevantes para NEO y Ethereum. La primera advertencia es que la velocidad de ejecución emulada será más lenta que la de una máquina virtual comparable; medido en instrucciones, un contrato nativo de Ethereum requerirá menos instrucciones para ejecutarse (y, por lo tanto, costará menos gas) que ejecutar un contrato que emula la máquina virtual NEO que ejecuta un contrato NEO. Por supuesto, hacer esto último es una tontería. Simplemente escribiríamos código nativo. Esto lleva a la segunda advertencia: no todas las instrucciones de una VM pueden emularse de manera eficientepor otra máquina virtual. Por ejemplo, en computadoras sin unidades de punto flotante, es relativamente costoso computacionalmente hacer matemáticas de punto flotante, pero aún se puede hacer. Afortunadamente, la introducción de zkSNARKS en Ethereum en Metropolis permitirá implementar algo en los contratos que antes no habría sido factible. Otra advertencia es que la entrada/salida (E/S) y los periféricos disponibles para las máquinas virtuales no son lo mismo; específicamente, una VM Ethereum no puede interactuar actualmente directamente con la VM NEO y espero que lo contrario también sea cierto. Hay otras advertencias que pasaré por alto (p. ej., las limitaciones de memoria de la portabilidad), pero las anteriores son quizás las mayores.

Es posible que NEO tenga un conjunto más grande de operaciones nativas rápidas que facilitan el soporte eficiente de una mayor cantidad de operaciones, pero si esto resulta útil, estoy seguro de que alguien propondrá un EIP para agregar soporte para el instrucción. Mientras tanto, si uno realmente quisiera escribir en un idioma en particular, también podría escribir un compilador cruzado (o escribir un nuevo compilador y optimizador EVM para la interfaz de análisis de un compilador existente) y agregar algún soporte adicional para manejar blockchain I /O como determinar el número de bloque actual y la gestión del estado.

Después de leer más, parece que NEO tiene algunas características de E/S que son parte de su VM que no son parte de Ethereum, específicamente, disparadores que hacen que se ejecuten contratos, como disparar en una fecha determinada o cuando otra cuenta alcanza un equilibrio particular). En NEO, es un poco como las devoluciones de llamada impulsadas por interrupciones; en Ethereum, esto se puede hacer (sin modificar el EVM) usando un sondeo externo como Ethereum Alarm Clock. Por supuesto, esto no tiene ningún efecto sobre qué idiomas se admiten o son compatibles.