¿Por qué desea utilizar diferentes implementaciones de EVM?

Actualmente existen muchas implementaciones de EVM (Java, C++, Python, Go, etc).

Por ejemplo: usaré Solidity para escribir DApp sobre EVM-Java y EVM-Python, ¿por qué querría usar EVM-Java en lugar de EVM-Python?

¿Por qué y cuándo quieres usar uno sobre el otro?

Respuestas (4)

¿Por qué y cuándo quieres usar uno sobre el otro?

La respuesta de alto nivel es que no lo harías, no te importaría. Es similar a elegir un sistema operativo según el idioma en el que está escrito.

Si todo lo que desea hacer es desarrollar y ejecutar sus propios contratos inteligentes, los clientes en los que se ejecutan esos contratos se abstraen.


Si realmente desea ejecutar su propio cliente, en lugar de solo desarrollar Dapps, puede haber razones por las que algunas personas prefieran una sobre la otra:

  • Desea ejecutar lo que la comunidad consideraría el cliente más seguro y probado en batalla. Así que elige los más populares .
  • Desea ayudar a la comunidad asegurándose de que haya varios clientes diferentes ejecutándose en la red, por lo que deliberadamente no ejecuta el cliente más popular. (Durante el ataque DDoS en DevCon2, Geth se vio afectado pero Parity no. Si Parity no hubiera existido, habría habido problemas).
  • Desea editar el código fuente para realizar sus propias modificaciones (por ejemplo, si es un minero, para cambiar los algoritmos de minería), así que elija un cliente escrito en un idioma con el que esté más familiarizado.

Tenga en cuenta, sin embargo, que solo en el último de estos está haciendo una elección basada en el idioma subyacente del cliente.


Usaré Solidity para escribir DApp sobre EVM-Java y EVM-Python,

Como mencioné anteriormente, a) crear un Dapp yb) ejecutar un cliente, son ortogonales. No necesita ejecutar su propio cliente/EVM para implementar su Dapp. Los contratos inteligentes asociados se ejecutarán en todos los nodos de la red, por lo que no puede elegir qué tipos de clientes ejecutarán sus contratos.

Aquí hay algunos argumentos:

  • Todos sabemos que Solidity parece un lenguaje fácil, pero lo que mucha gente no sabe es: qué está sucediendo realmente y cómo se procesa este código (en el EVM) . No podemos controlar sus punteros de memoria como podríamos hacerlo en C++, por ejemplo, por lo que suceden muchas cosas en el EVM y no nos damos cuenta.
  • Además, Solidity no es un lenguaje sólido y completamente probado, como lo serán Java, C++ u otros . Y también, estos otros lenguajes permitirán mejores opciones de depuración y prueba , lo que no proporciona Solidez.
  • Esto nos hace pensar que un contrato inteligente (que tiene que contener dinero, y una vez implementado, no podemos cambiar nada) necesitará programarse más como controlador, por ejemplo: más probado, con más control de memoria como lo tiene C++, etc. ..

Estas son las principales razones por las que nacen otras implementaciones.

Espero eso ayude.

Aquí estás hablando de un "lenguaje sustituto de Solidity", pero esa no era mi pregunta. Mi pregunta es, ¿por qué hay diferentes implementaciones de EVM? Entonces, por ejemplo, escribiré sobre Solidity en la parte superior de Java-EVM y Python-EVM, ¿correcto? Por lo tanto, no estoy seguro de por qué querría usar Java-EVM frente a Python-EVM.
Sí, pero es mucho más difícil (o incluso imposible) rastrear y controlar la memoria con Java EVM. Es por eso que existen otras implementaciones.

Elegiría uno en función de dos factores (similar a las opciones con cualquier biblioteca)

1) Mantenimiento de la biblioteca.

2) Su comodidad en el uso del idioma.

Pero ¿por qué te importaría? Porque todos ellos hacen exactamente el mismo trabajo, ¿verdad? (es decir, ejecutar código de solidez, etc.) Es como decir que quiero usar MySQL basado en Java o basado en C ++ (suponiendo que ambas implementaciones sean idénticas en características y rendimiento).

Tal vez esté creando un proyecto que ejecuta transacciones dentro de su propio código y no desea implementar todo el EVM, por lo que usaría uno de ellos. Por ejemplo, si su aplicación está escrita en Java, tiene sentido usar ethereumJ.