Project Jump Cannon: Elegir WASM

En episodios anteriores expusimos los motivos para trabajar en contratos inteligentes nativos de Stellar ahora. El ecosistema de Stellar está en una posición ventajosa para implementar contratos inteligentes: aprendiendo de la investigación que ya se ha realizado; avanzando equipados con una caja de herramientas diversa; e implementando contratos inteligentes de Stellar de una manera que es fiel a las cosas que hacen que Stellar sea lo que es: seguro, escalable y promueve un acceso equitativo.

Una de las primeras decisiones importantes al construir una plataforma de contratos inteligentes en 2022 es elegir una plataforma de contrato inteligente. Esta publicación te guiará a través del proceso de toma de decisiones, las opciones que consideramos y los pros y contras de cada una. Pero si solo estás aquí para el gran final…

TL;DR: Project Jump Cannon se está desarrollando en un entorno de ejecución WebAssembly (WASM).

Para aquellos de ustedes que se quedan para aprender cómo y por qué elegimos WASM, sigamos adelante.

Durante los últimos meses, un equipo de SDF se ha centrado en evaluar el panorama actual de los contratos inteligentes. Queremos usar la tecnología más apropiada y aprender del ecosistema de criptomonedas más amplio. Nuestro equipo ha creado un documento de selección de pila doc con nuestros criterios de selección y una comparación exhaustiva de las tecnologías existentes. Si te interesan todos los detalles minuciosos, ¡revisa ese documento! Esta publicación de blog es una versión simplificada de la misma.

Primero, ¿qué queremos decir cuando decimos “pila de contratos inteligentes”? Bueno, mucho. Pero aquí hay una versión condensada con cuatro componentes

1. La Máquina Virtual (VM): Esta ejecuta instrucciones de bytecode en un entorno aislado. Realmente no sabe nada sobre la blockchain.
2. Los servicios de tiempo de ejecución de Blockchain: Estos conectan la máquina virtual con la blockchain: almacenamiento de ledger, medición de gas, etc.
3. La cadena de herramientas de lenguaje: Esto permite a los desarrolladores escribir contratos en un lenguaje “legible por humanos” como Rust o Solidity.
4. SDKs de Desarrollo de Contratos: Estos facilitan el proceso de desarrollo al proporcionar bibliotecas, documentación, un sandbox de pruebas y más.

En un mundo perfecto elegiríamos una tecnología lista para usar que cubra toda la pila de contratos inteligentes. Eso podría no ser realista, dadas las diferencias entre los protocolos de blockchain y las implementaciones. Dicho esto, como mínimo, nos gustaría elegir una Máquina Virtual existente y un lenguaje de programación: estos son campos bien investigados, y aunque nuestro equipo incluye creadores de lenguajes, no necesitamos reinventar la rueda.

Consideramos los siguientes criterios para evaluar las opciones tecnológicas:

1. Primero y principal nos preguntamos: ¿es lo suficientemente “capaz”? Si la tecnología no puede facilitar el tipo de contratos inteligentes que estamos buscando, es un punto de partida no válido.
2. Luego miramos varios aspectos del diseño: ¿el modelo de almacenamiento promueve una responsabilidad a largo plazo por el estado y un tamaño de ledger manejable? ¿Las transacciones se prestan bien a la concurrencia al particionar? ¿Cómo son la ergonomía del desarrollador? Eso es un poco subjetivo, pero queremos asegurarnos de que la experiencia de desarrollo no sea demasiado “extraña”.
3. Analizamos la(s) implementación(es) existente(s) en términos de rendimiento, madurez y cuán atadas están a una blockchain y entorno de ejecución específicos.
4. Por último, miramos la madurez del ecosistema: ¿cuántos contratos existentes, desarrolladores y recursos para desarrolladores existen?

Estas son las lentes a través de las cuales examinamos las opciones. Hay mucha tecnología de contratos inteligentes allí afuera. Aquí hay algunas de las opciones notables que investigamos y nuestra opinión general sobre cada una.

La Máquina Virtual de Ethereum (EVM) es el elefante en la habitación. Se desarrolló junto con Ethereum y está impulsando la mayoría de la actividad en el espacio DeFi. Se utiliza más comúnmente junto con el lenguaje de programación Solidity, pero existen otros, como Vyper. La EVM también se utiliza en una variedad de otras redes como Avalanche, Celo, Fantom y otras.

Es, con mucho, la pila de contratos inteligentes más popular. Es madura y tiene una abundancia de recursos para desarrolladores, herramientas y mejores prácticas disponibles. Sin embargo, sus modelos de almacenamiento y ejecución son costosos y difíciles de paralelizar. Esto hace que el software de validación sea menos accesible y se interponga en el camino de la escalabilidad. Además, haber sido construido específicamente para Ethereum hace que la adopción de EVM en redes existentes sea extremadamente desafiante.

Move es una pila de contratos inteligentes diseñada por y para la blockchain Diem. La pila incluye una máquina virtual, cadena de herramientas de programación, un prover dedicado y otras herramientas de desarrollo.

Move está diseñado cuidadosamente desde cero como una pila tecnológica blockchain integral. Hace muchas cosas bien, incluyendo un lenguaje de verificación único y un prover que se construyeron junto con el lenguaje. Por otro lado, es bastante inmaduro (todavía en progreso, sin ecosistema significativo) y el ejecutor actual es muy lento. Además, el modelo de almacenamiento de Move presenta un modelo de programación que los desarrolladores luchan por comprender.

WASM es una especificación de bytecode creada para ejecutar aplicaciones en un entorno aislado en un navegador.

Es utilizado por varias cadenas en diferentes configuraciones: Polkadot, Terra, Near, Elrond, Dfinity, etc. Se utiliza más comúnmente con el lenguaje de programación Rust, pero hay otros.

WASM se presta bien para contratos inteligentes ya que fue diseñado para operar en un entorno que, al igual que una blockchain, es extremadamente adverso: la web. Como VM, WASM presenta el conjunto más amplio de posibles lenguajes fuente, cadenas de herramientas, intérpretes y JITs, y presenta el mejor rendimiento y el menor grado de acoplamiento a la semántica de una blockchain específica. Sin embargo, deja abierto el problema de diseñar “el resto de la pila” – servicios de tiempo de ejecución agnósticos y específicos de blockchain, así como APIs/SDKs de lenguaje fuente y/o enlaces/lenguajes de dominio específico. Hay varias cadenas para estudiar y aprender, pero ninguna se ajusta lo suficientemente bien a Stellar como para adoptarla sin cambios.

Curiosamente, la comunidad de Ethereum ha estado abogando por usar WASM en Ethereum desde tan temprano como 2015. La Fundación Ethereum también ha desarrollado eWASM: un subconjunto restringido de WASM para ser utilizado en Ethereum 2.0. Con las definiciones cambiantes de Ethereum 2.0 a lo largo de los años, no está claro si eWASM se implementará alguna vez en Ethereum. Sin embargo, esto sugiere un posible reencuentro entre la pila WASM y el ecosistema de Ethereum en el camino.

eBPF es una especificación de bytecode con múltiples implementaciones de VM. Originalmente creada para ejecutar programas aislados en un kernel de OS. En el espacio de la blockchain, solo es utilizado por Solana que usa una versión modificada de la implementación rBPF. El lenguaje principal de contrato para Solana es Rust, aunque teóricamente se pueden usar muchos. Las transacciones de Solana declaran dependencias lo que permite al tiempo de ejecución particionar bloques y ejecutar concurrentemente en múltiples núcleos.

eBPF para contratos inteligentes es una elección bastante única, y Solana hace muchas afirmaciones audaces al respecto. Sin embargo, los beneficios reales no están claros. eBPF como VM es sustancialmente similar a WASM como objetivo para múltiples lenguajes a través de cadenas de herramientas nativas, pero el soporte es peor y la carga de mantenimiento es mayor. Una gran diferencia es que los intérpretes de eBPF típicamente optimizan para un inicio de baja latencia, pero cada vez más, este es el caso con los intérpretes rápidos de WASM de todos modos. Los modelos de concurrencia y almacenamiento de Solana son más prometedores como entradas de diseño para nuestros propios esfuerzos, pero presentan riesgos de seguridad y rendimiento lo suficientemente significativos como para no adoptarlos sin cambios.

¡Hay muchas más opciones de contratos inteligentes! Algunas de ellas dependen de la blockchain, algunas se basan en un modelo UTXO y algunas son simplemente... marginales. Estamos manteniendo un ojo en estas pero esta publicación de blog se está alargando un poco.

Así que volviendo al resultado final: nos estamos enfocando en WASM para Project Jump Cannon. Creemos que proporciona un entorno de ejecución robusto para contratos inteligentes, tiene un ecosistema próspero y puede usarse para construir un sistema que sea seguro, escalable y promueva un acceso equitativo.

Dicho esto, muchas preguntas permanecen:

• ¿Qué implementación de WASM usar?
• ¿Qué lenguaje(s) fuente admitir?
• ¿Cuál es el modelo de almacenamiento de contratos?
• ¿Cuál es el modelo de paralelismo de contratos?
• ¿Cuál es la historia de interoperabilidad con el protocolo Stellar existente?
• … ¡y muchas más!

Mantente atento, ya que responderemos todo lo anterior.