¿Cuál es el mérito de crear nuevos lenguajes de contratos inteligentes como Solidity en lugar de usar otros lenguajes?

Cada lenguaje de programación está diseñado para un entorno operativo particular y tareas de destino; y estas restricciones impulsan casi todas las decisiones de diseño sobre qué características admitir y cuáles descartar.

Hace un tiempo, dediqué bastante tiempo a crear un compilador cruzado Go -> EVM. Me las arreglé para ejecutar algunos programas triviales y definitivamente fue muy divertido, pero muy pronto comencé a encontrarme con las limitaciones de EVM que chocan con las suposiciones básicas detrás de Go:

• Cada rutina necesita al menos 64 KB de memoria. Trivialmente bajo para cualquier hardware decente hoy en día, pero exorbitantemente alto y caro para el EVM.
• Go se basa en el administrador de memoria a nivel del sistema operativo. Esto significa que para ejecutar programas de Go en el EVM, necesitaríamos desarrollar un administrador de micromemoria sobre el EVM que pueda admitir las operaciones que necesita Go. Diseñé una versión POC del algoritmo Buddy Memory Allocation , pero ese se basa en el hecho de que la memoria es limitada y fija, y asigna fragmentos arbitrarios dentro de eso. El EVM, por otro lado, es "infinito" y cobra por compensación máxima asignada. Por lo tanto, todos los algoritmos habituales de asignación de memoria se verían afectados, ya que suponen que los costos de memoria son constantes, mientras que el EVM es posicional e incluso exponencial.
• Go es un lenguaje de recolección de basura, por lo que cada asignación de memoria también debe mantener contadores de referencia, que deben funcionar bien con el asignador de memoria. Nuevamente, no es imposible de resolver, pero el código de operación asociado y los costos de memoria no lineal hacen que esto sea muy costoso.
• Incluso si se resuelven los problemas de memoria, aún necesita encontrar soluciones para las primitivas de sincronización, las interrupciones del sistema operativo y otras construcciones de almacenamiento que tendemos a dar por sentado pero que EVM no tiene.

Estos desafíos fueron los principales por los que decidí no continuar con mi port de Go to the EVM, pero realmente resaltan que los lenguajes modernos se basan en innumerables características compatibles con los sistemas operativos subyacentes, que a su vez se basan en suposiciones sobre qué es el hardware subyacente. capaz de hacerlo y los costos asociados.

El EVM es una bestia muy diferente de este aspecto, por lo que aplicar las mismas suposiciones conduce a una ejecución de código muy subóptima. Por eso se tomó la decisión de desarrollar un lenguaje diseñado específicamente para el entorno de ejecución de EVM. De hecho, es probable que sea mucho más trabajo que portar una sintaxis de idioma existente (!), Pero también da como resultado un entorno utilizable frente a tener todo tipo de "restricciones documentadas" que, aunque algo es un código Go válido, no puede usarlo. porque "xyz".

Tenga en cuenta que es muy posible que el diseño original de EVM sea malo y se amplíe, actualice o incluso reemplace por completo cuando alguien encuentre una solución mucho mejor para hacer las cosas. Pero esa es una posibilidad futura, mientras que Solidity es una necesidad actual.

En particular, en el mundo de los contratos inteligentes, el código está diseñado para interoperar con EVM y, por lo tanto, existen algunos requisitos clave para que un lenguaje se use en un contrato inteligente.

1. El compilador debe poder generar código optimizado para el tamaño del código (mientras que muchos otros lenguajes tienden a optimizar la eficiencia de cómputo).

2. Optimice la seguridad y la capacidad de auditoría.

También es posible que haya otros beneficios sociales o de organización por usar un nuevo idioma, como

3. Una flexibilidad mucho mayor de las decisiones de diseño de su compilador (nadie intentará usar el código existente en su nuevo compilador y se quejará de que no funciona)

Consulte la otra respuesta de @Péter Szilágyi para ver un ejemplo de intentar usar el lenguaje Go para compilar de forma cruzada en un código de bytes EVM

Referencia: Vitalik responde sobre por qué un nuevo idioma en AMA

Hay varios desafíos. En primer lugar, C++ existente y otros compiladores tienden a generar código que realmente no está optimizado para un tamaño de código compacto; p.ej. incluso el programa más simple genera un archivo de más de 4 kb. Esto está bien para las computadoras, donde el almacenamiento es barato, pero es terrible para las cadenas de bloques, donde el almacenamiento es costoso. Por lo tanto, se requieren compiladores especializados.

En segundo lugar, los lenguajes de contratos inteligentes de EVM deben diseñarse con un enfoque particularmente fuerte en la seguridad, que no es algo que le importe en la misma medida a la mayoría de los lenguajes existentes.

No estoy seguro de si sería fácil que mi respuesta se fusione con la respuesta de @ Péter Szilágyi , así que la hago por separado.