Una de las características más interesantes de los blockchains son los smart contracts que permiten la ejecución automática de acuerdos basados en criterios que han sido definidos previamente.

Pero, ¿qué significa esto realmente? ¿qué tipo de acuerdos? ¿qué blockchains? ¿qué significa "automáticamente"?

Tabla de contenidos

¿Qué es un contrato?

Demos un paso atrás y veamos qué es un contrato en el "mundo real". En un contrato las diferentes partes manifiestan de forma libre y voluntaria (consentimiento) su voluntad de aceptar los acuerdos a los que se llega y se reconocen como capaces para reclamar los derechos y cumplir con la diferentes obligaciones pactados (capacidad). El acuerdo tiene un objeto, el bien o servicio intercambiado, y una causa que motiva la celebración del acuerdo. Finalmente el contrato puede tener diversas formas: por escrito, ante notario, ante testigos, oral, etc.

Los contratos tradicionales como este tienen muchos problemas:

  • Interpretativos. Independientemente de la forma (aunque esté escrito y ante notario), puede darse la circunstancia que alguna obligación o derecho se entienda de manera diferente por alguna de las partes y ello genere en una disputa, que en el peor de los casos tenga que resolverse delante de un juez.
  • Ejecutivos. Aún cuando las partes interpretan el contrato de la misma manera, alguna de ellas puede incumplir parte del acuerdo o su totalidad deliberadamente de mala fe, por negligencia o por accidente. Esto es así porque se requiere de la voluntad de la parte para ejecutar una obligación. Una vez más nos podemos ver obligados a visitar a un señor juez.
  • Ineficientes en coste y tiempo
    • Para añadir garantías al acuerdo se pueden hacer por escrito ante notario lo que requiere cerrar una cita entre las partes y el notario y satisfacer sus honorarios.
    • La ejecución de las obligaciones suele requerir la voluntad y la proactividad de las partes implicadas. Es decir suelen requerir de una gestión "manual" lo que implica que la ejecución de algunos derechos puede retrasarse innecesariamente.

Un smart contract viene a solucionar todos estos problemas, de manera que las obligaciones se ejecuten automáticamente sin necesidad de voluntad o intervención de las partes (o la necesidad de incorporar intermediarios que den garantías o confianza) en cuanto se dan las condiciones (derechos) de ejecución y sin que haya posibilidad de diferentes interpretaciones.

Un smart contract es un programa informático ejecutado por un blockchain

Un smart contract es un contrato que se ha formalizado (escrito) como un programa informático que define todas las cláusulas (por tanto no hay posible interpretación, el acuerdo es lo que "hace" el programa), que tiene el control del objeto del acuerdo (por ejemplo una suma monetaria) y que se ejecuta automáticamente tan pronto como se dan las circunstancias pactadas. El smart contract es desplegado (instalado) en un blockchain específico (por ejemplo en Ethereum) y por tanto es visible por todo el mundo (transparente) y se ejecuta por el protocolo del blockchain de manera que ninguna de las partes puede alterar su contenido o detener su ejecución. Una ventaja adicional es que los smart contracts son acuerdos transfronterizos por la propia naturaleza del blockchain.

¿Cómo puede un blockchain ejecutar un smart contract? Un blockchain se ejecuta de manera descentralizada por un conjunto de nodos (ordenadores) que mantienen en marcha el protocolo. Los blockchains que tienen capacidad para gestionar smart contracts incluyen en su protocolo una capa de ejecución que se encarga precisamente de ejecutar estos smart contracts que como hemos dicho no son más que programas informáticos.

La arquitectura habitual de los blockchains es que una dirección (o cuenta) puede contener dos tipos de datos: o bien "dinero" (una cierta cantidad de la criptomoneda correspondiente a ese blockchain) o bien un programa (un smart contract). La garantía de ejecución correcta y sin alteraciones de lo pactado (programado), se da por dos motivos:

  1. El smart contract queda almacenado de forma inmutable en un bloque del blockchain.
  2. El protocolo de consenso del smart contract garantiza que múltiples nodos validadores han aceptado el resultado de la ejecución del smart contract lo que previene una ejecución errónea debida a un bug en el ejecutor o a una manipulación maliciosa del mismo.

¿Cuál es el ciclo de vida habitual de un smart contract? Sería algo así:

  1. Las partes definen un acuerdo.
  2. Se escribe el smart contract en un lenguaje de alto nivel para este propósito (por ejemplo Solidity).
  3. Se despliega el smart contract en una dirección del blockchain. A partir de este momento residirá allí de manera inmutable.
  4. Las partes pueden interactuar con el smart contract haciendo llamadas a las diferentes funciones publicadas que se ejecutarán tal y como han sido programadas y de ninguna otra manera.

Ejemplo: un marketplace entre particulares

Se quiere construir una aplicación marketplace de venta entre particulares de artículos hechos a mano o de segunda mano. La aplicación facilita la relación entre compradores y vendedores así como la logística para enviar artículos en intercambios no presenciales. El marketplace recibe una pequeña comisión de la venta por cada transacción.

¿Cuál es el principal freno del uso de estas aplicaciones? La desconfianza entre partes, tanto la del comprador que tiene miedo a pagar antes de recibir la mercancía (y que esta nunca llegue o sea diferente a lo esperado) como la del comprador que teme que una vez hecho el envío jamás reciba el pago.

En un mundo pre smart contracts lo habitual es contratar una cuenta de escrow que actúa como un agente externo a los actores implicados en la transacción dando garantías y confianza. En nuestro ejemplo funcionaría así:

  1. El comprador transferiría el dinero de la compra a la cuenta escrow.
  2. El vendedor haría el envío de la mercancía al comprador a través de un transportista.
  3. El transportista llevaría la mercancía hasta el comprador.
  4. El comprador verificaría la mercancía y confirmaría al agente escrow la recepción.
  5. El agente escrow liquidaría entonces a las diferentes partes: la comisión del marketplace, (quizás) la tarifa al transportista y el resto al vendedor.
Diagrama de flujo de una compra con escrow
Diagrama de flujo de una compra con escrow

La solución es buena y existen múltiples proveedores de escrow que ofrecen este servicio. El principal inconvenientes es una, vez más, la eficiencia:

  • el agente escrow hace un trabajo y por tanto va a cobrar por él,
  • hay múltiples envíos de dinero sobre raíles de pago tradicionales (tarjetas de crédito, transferencias bancarias, etc.) que pueden introducir grandes retasos en cada movimiento de dinero.

¿Cómo lo haríamos con blockchain y smart contracts? Definiríamos un smart contract que implementa directamente las cuentas escrow en el blockchain y almacena el valor de la mercancía en criptomoneda (haremos aquí abstracción de los problemas que estas pueden tener, pero recordad que ya tenemos stablecoins como el USDC o EUROC y el euro digital acabará llegando) y que hace las liquidaciones de manera inmediata.

El flujo es muy similar:

  1. El comprador transfiere desde su wallet el valor de la mercancía a un escrow construido dentro del smart contract.
  2. El vendedor entrega la mercancía al transportista y envía desde su wallet el valor del envío a otro escrow dentro del smart contract.
  3. El transportista entrega la mercancía al comprador.
  4. El comprador, tras verificar la mercancía, notifica al smart contract la recepción de la misma (posiblemente en un dispositivo del transportista como condición para la entrega)
  5. El smart contract transfiere de forma inmediata desde los escrows correspondientes el dinero al vendedor, al marketplace y al transportista.
Diagrama de flujo de una compra con escrow gestionado por un smart contract
Diagrama de flujo de una compra con escrow gestionado por un smart contract

Adicionalmente se pueden programar una serie de temporizadores. Por ejemplo, pongamos que pasados 15 días sin que se haya producido la confirmación se hace la devolución del dinero en los escrows a los depositantes iniciales.

Aunque el flujo es muy similar, la ventajas son muchas:

  1. Transparencia y confianza. Todos los actores pueden leer el smart contract, entender cómo funciona y saber que el blockchain garantiza que el contrato no puede cambiar y que se ejecutará en tiempo y forma.
  2. Eficiencia económica. Hemos eliminado el agente de escrow y lo hemos cambiado por un smart contract que no cobra 😊 (en realidad hay que pagar un poco en concepto de incentivo para los nodos del blockchain mantengan el protocolo, pero es despreciable en comparación a la alternativa).
  3. Eficiencia temporal. El dinero se mueve a la velocidad de Internet con transferencias (casi) inmediatas.

Retos de los smart contracts

Como suele decirse, no es oro todo lo que reluce y los smart contracts tienen sus propios retos. Muchos de estos se irán solucionando a medida que la tecnología vaya madurando, pero es bueno tenerlos en cuenta.

La inmutabilidad y la transparencia las carga el diablo

A lo largo del artículo no he parado de hablar de las ventajas de la inmutabilidad y la transparencia ya que son los mecanismos principales para garantizar la confianza y que los acuerdos se cumplan tal y como se han pactado.

Sin embargo, que cualquiera pueda ver el código y que este no pueda cambiarse, tiene un precio. Como hemos dicho un smart contract no es más que un programa informático desplegado y ejecutado por el blockchain y, como todo programa, puede contener bugs (errores de programación). Un error de programación puede expresarse como un efecto colateral inesperado (no ha habido mala fe de las partes) o como un agujero de seguridad. La inmutabilidad impide al programador o a las partes corregir el error en el código (al menos fácilmente) con lo que puede tener graves consecuencias.

Estos errores de programación y sus consecuencias no son teóricos. A lo largo de la corta historia del blockchain ha habido múltiples ataques apoyados en smart contracts que se habían programado con fallos de seguridad y que una vez detectados no se ha podido hacer nada para corregirlos. Algunos de los casos más famosos son estos:

  • "The DAO Hack", en el que el atacante consiguió sustraer una tercera parte de todos los fondos almacenados en The DAO, aproximadamente 3,6 millones de Ether. "The DAO" fue una de las primeras organizaciones autónomas descentralizadas cuya misión era actuar como un fondo de capital de riesgo dirigido por sus inversores (que eran los que aportaban los fondos). Este incidente estuvo a punto de destruir el por entonces incipiente blockchain de Ethereum.
  • "The Parity Wallet Hack". Parity proporcionaba bibliotecas de código para que terceros implementaran sus propios smart contracts sin partir de cero. Una de esas bibliotecas proporcionaba código para implementar wallets multi-sig que tenía una vulnerabilidad que habilitó varios ataques a proyectos que habían usado ese código para construir sus propias soluciones concluyendo con aproximadamente 666.773 Ethers robados o inaccesibles.

¿Qué puede hacerse para evitar la introducción de bugs o vunerabilidades en el código?

  1. Ser muy exigente con el ciclo de desarrollo, aplicando escrupulosamente todas las técnicas y metodologías de desarrollo de software de calidad (testing, revisión, refactorización, integración continua, análisis estático, etc.).
  2. Aprender patrones y utilizar bibliotecas de código de smart contracts de actores reconocidos. Aquí podemos destacar a OpenZeppelin y sus bibliotecas de código que proveen plantillas auditadas para los patrones clásicos en desarrollo de smart conracts.
  3. Realizar auditorías de seguridad por terceros de reconocido prestigio. Una vez más OpenZeppelin tiene buena reputación en este sentido pero también otros como Consensys o Hacken. Estas auditorías aportan además un sello de calidad a tu aplicación basada en smart contracts que da garantías extra a tus usuarios.
  4. Implementar un programa de recompensa (más conocido en el mundillo como bug bounty program) en el que se premia con recompensas interesantes (efectivo, criptomoneda, reconocimiento, etc.) a aquellos individuos que te reportan los bugs sin explotarlos. Es como tener a un ejército de "hackers de sombrero blanco" trabajando para ti. Por ejemplo, en el momento de escribir este artículo el programa de recompensa de AAVE, un protocolo de concesión de préstamos descentralizado, proporciona recompensas económicas de hasta 250.000 dólares.

Ok, ok, he sido un chico bueno y he implementado todos los mecanismos a mi alcance para tener un código de matrícula, pero aún así se ha escapado un bug que acabo de encontrar o, ¡qué diablos! quiero hacer una actualización en mi smart contract para ofrecer nuevas funcionaliadades. ¿Cómo lo hago? Pues básicamente hay dos opciones.

Reemplazar un smart contract por otro

La primera opción consiste en:

  1. desplegar una versión mejorada de tu smart contract en otra dirección del blockchain,
  2. hacer una migración de los recursos de un smart contract al otro (si lo tuviste en cuenta en el desarrollo inicial y puedes hacerlo) y
  3. convencer a todos tus usuarios que dejen de usar el contrato viejo y pasen a usar el contrato nuevo, es decir, que se olviden de la dirección del anterior y usen la dirección del que acabas de desplegar.

Lo sé, no parece una solución muy sencilla de implementar, pero de hecho es uno de los mecanismos que se usan.

Implementar upgradable smart contracts

La segunda opción consiste en hacer que la inmutabilidad sea mutable 😳. ¿Pero esto se puede? Sí y no. Efectivamente el código de un smart contract no se puede modificar una vez que ha sido desplegado y pasa a formar parte de un bloque del blockchain, pero el smart contract puede diseñarse siguiendo un patrón que permite simular de facto esa mutabilidad.

Para entender el patrón debemos conocer otras características de los smart contracts:

  • Además de código, tienen lo que se denomina "estado" que no es más que un conjunto de variables persistentes cuyo valor puede cambiar y ser modificado por el smart contract. Podemos imaginar las variables como una base de datos asociada al smart contract que guarda información de forma persistente pero mutable en el propio blockchain.
  • Un smart contract puede llamar por delegación a otro smart contract si conoce su dirección en el blockchain sin que el llamador del primer smart contract sea consciente (esta es la base del concepto de composability que permite la reutilización del código entre diferentes proyectos).
  • Una variable de estado de un smart contract puede contener la dirección de otro smart contract.

En este punto ya puedes imaginar la estructura del patrón para tener smart contracts "mutables" (más conocidos como upgradable smart contracts). El truco, como casi todo en informática, consiste en añadir un nivel de indirección más entre la API que define el smart contract principal y la ejecución de una función concreta que se delega a otro smart contract y cuya dirección se almacena en una variable. En un momento dado un usuario autorizado puede modificar esta variable para que apunte a otro smart contract, cambiando de facto el código que se ejecuta, sin haber modificado la API pública del smart contract principal.

Workflow para un smart contract "actualizable"
Workflow para un smart contract "actualizable"

OpenZeppelin, de nuevo, hace un trabajo excelente explicando este patrón en su documentación e implementado una biblioteca que nos provee de una plantilla base para montar nuestros propios smart contracts mutables.

Objetos no tokenizables

Los smart contracts brillan cuando el objeto del contrato, el bien a intercambiar o gestionar, es nativo en el blockchain, objetos tales como criptomonedas o todo tipo de tokens (incluyendo los famosos NFTs). En este caso, el smart contract puede transferir la propiedad entre los participantes de forma inmediata, aplicar las reglas que sean necesarias o, por ejemplo, mantener escrows según ciertas políticas.

¿Pero qué pasa cuando el objeto no es nativo en el blockchain? Podemos considerar dos casos: el dinero fiat y otros objetos.

Tokenizar dinero

Los diferentes blockchains tienen sus propia moneda (como bitcoins o ethers) pero muchos individuos y negocios a la hora de hacer transacciones en el "mundo real" prefieren o necesitan seguir haciéndolo con dinero fiat (por ejemplo dólares o euros). En este caso existe la opción de utilizar stablecoins que intentan mediante diferentes mecanismos mantener el mismo valor que la moneda fiat a la que se refieren.

En particular a mí me gustan el USDC (muy consolidado) y el EUROC (aún en fases iniciales) emitidos por Circle que son una representación tokenizada de la moneda fiat correspondiente y respaldados por reservas 1 a 1, es decir, cada USDC está respaldado por un dólar que Circle tiene en reserva y disponible. Para obtener una cierta cantidad de estos stablecoins tienes que depositar en Circle la cantidad equivalente de fiat. En cualquier momento puedes ir a Circle y cambiar una cantidad de la stablecoin por la misma cantidad en fiat. Las stablecoins son tokens que pueden ser usados en un blockchain de la misma manera que su moneda nativa (como por ejemplo ethers en Ethereum).

Por otro lado, tenemos la promesa de la moneda digital de banco central o CDBC por sus siglas en inglés (Central Bank Digital Currency) que son representaciones tokenizadas del dinero "oficial" emitido por los bancos centrales de cada área económica. Digo promesa porque tanto el Banco Central Europeo como la Reserva Federal Americana tienen procesos de análisis para lanzar euros y dólares digitales, pero todavía no está claro qué serán y cuándo. Por otro lado, en el 2022 China puso en circulación el renminbi digital (también abreviado como "RMB digital" o e-CNY) y ese mismo año otros tres bancos centrales de economías más modestas lanzaron sus respectivas CDBC: el Banco Central de las Bahamas (Sand Dollar), el Banco Central del Caribe Oriental (DCash) y el Banco Central de Nigeria (e-Naira).

Mi intuición, y esto ya es opinión, es que cuando lleguen el euro y el dólar digital convivirán y no desplazarán a las stablecoins ya que estas estarán muy integradas en la economía y los raíles financieros. De hecho, posiblemente sean lss CDBCs las que tengan problemas para coger tracción frente a las stablecoins ya, valga la redundancia, establecidas en la economía.

Tokenizar otras cosas

Una vez resuelto el problema de usar dinero dentro de los smart contracts (con criptomoneda nativa, con stable coins o con CDBCs), tenemos el problema de cómo estos pueden gestionar otro tipo de bienes o servicios que no forman parte nativa de los blockchains.

Aquí podemos pensar todo tipo de bienes: participaciones o acciones en empresas, propiedades inmobiliarias, vehículos, bonos financieros, derechos varios, etc.

Un activo del mundo físico se denomina smart property cuando su propiedad está gestionada por smart contracts en un blockchain. Para que eso sea posible, la propiedad física debe poder representarse digitalmente. Esta representación se denomina token.

Para que todo funcione correctamente, las partes deben aceptar que la posesión del token implica la propiedad del bien representado por el mismo.

¿Cómo garantizamos que la posesión del token tenga valor legal en el "mundo real"? ¿un mundo real que tiene estructuras legacy como notarios, registros, etc? Este es un campo efervesciente, innovador y en pleno desarrollo. Ahora mismo existen proyectos de tokenización de todo tipo de activos que conectan todo el poder de los smart contracts para el intercambio o gestión de los activos con su posesión legal en el "mundo real". Mi opinión es que este va a ser uno de los campos que va a permitir construir proyectos sobre blockchain de utilidad real y alejados de los negocios especulativos que ha vivido esta tecnología en sus primeros años.

Dando una vuelta más a esta conectividad entre el blockchain y el mundo físico, existen proyectos y pruebas de concepto muy interesantes en el que la posesión de un token es necesario para poder utilizar el propio bien. Imagínate, por ejemplo, coches o teléfonos móviles que para ponerse en marcha requiran conectarse a tu wallet para verificar que tienes el token que acredita su propiedad.

Sin aleatoriedad ni visión exterior. Oráculos al rescate

Como hemos mencionado, una de las fuentes de confianza de los smart contracts es que al estar ejecutados dentro del blockchain podemos tener la garantía que se ejecutan de la forma esperada y sin tener que confiar en un único ordenador (este ordenador podría tener fallos o actuar maliciosamente debido a algún interés, por ejemplo).

Los blockchains consiguen este grado de confianza gracias a sus algoritmos de consenso que básicamente consisten en que un número suficiente de nodos (ordenadores) que construyen el blockchain están de acuerdo con los resultados que produce el blockchain. Los algoritmos de consenso son variados, sofisticados y cada blockchain toma sus propias decisiones sobre qué algoritmo, variante o implementación adoptar, pero la base fundamental de todos ellos es que existen nodos validadores que pueden revisar e impugnar, si es el caso, el resultado del smart contract propuesto por algún ejecutor. En último término, un validador podría ejecutar por sí mismo el smart contract y verificar que el resultado propuesto es idéntico al que él mismo ha llegado.

Para que esto sea posible necesitamos garantizar que la ejecución del smart contract sea determinista, es decir, que no contenga fuentes de aleatoriedad y por tanto que dado un smart contract y su estado (recordemos: el valor de sus variables), la ejecución de una función ha de producir siempre el mismo valor.

Para conseguir este determinismo los blockchain impiden que los smart contracts contengan funciones que puedan generar aleatoriedad y también que puedan acceder a información externa al blockchain; dicho de otro modo: un smart contract sólo puede hacer llamadas a otro smart contract y no puede, hacer una llamada a un servicio de Internet o una API externa de cualquier tipo.

Evidentemente dependiendo del servicio que queramos construir esta es una limitación muy fuerte. ¿No podemos construir una lotería sobre smart contracts? ¿no podemos liberar el dinero retenido en un escrow externo al blockchain de una aplicación de eCommerce cuando el comprador confirma un pedido?

Evidentemente sí podemos hacerlo. En este escenario es cuando tenemos que utilizar (o constuir) un oráculo. Un oráculo es un servicio que conecta los smart contracts con el mundo exterior. Los oráculos tienen dos capas, por un lado ofrecen una interfaz como smart contracts para que el resto de smart contracts puedan conectarse y por otro lado tienen una capa en el mundo exterior al blockchain (generalmente en Internet) desde el que realizan sus tareas de obtención de información, de publicación de datos o de cambios de estado fuera del blockchain.

Si el oráculo se ha construido adecuadamente (esto es todo un artículo en sí mismo) encapsulan la aleatoridad y permiten que el smart contract que llama a sus servicios siga siendo determinista (varias llamadas al oráculo para una misma representación del momento producen el mismo resultado) y que por tanto el algoritmo de consenso del blockchain siga funcionando correctamente.

Los oráculos suelen ser vectores de ataque habituales en las aplicaciones sobre blockchain por lo que en caso de utilizarlos hay que ser especialmente diligente a la hora de integrarlos en nuestra aplicación blockchain y auditarlos adecuadamente.

Blockchains que soportan smart contracts y lenguajes de programación

Hasta el momento hemos estado hablando de smart contracts y blockchains en general, pero ni todos los blockchains soportan smart contracts, ni todos los smart contracts utilizan el mismo lenguaje de programación ni todos los smart contracts proporcionan las mismas características.

Obviamente no vamos entrar en el detalle de cada blockchain y lenguaje porque necesitaríamos varios libros, pero veamos un resumen.

Bitcoin y Script

Bitcoin fue el primer blockchain y también el primero en introducir smart contracts. Su lenguaje de programación se denomina Bitcoin Script y es un lenguaje pensado para establecer reglas en el procesamiento de las transacciones y no como un lenguaje de propósito general. De hecho, no permite el uso de bucles (y por tanto no es Turing Completo).

Miniscript es un lenguaje que permite escribir (un subconjunto) de Bitcoin Scripts de una manera más estructurada, lo que permite un mejor análisis, composición y otras funcionalidades. El código en Miniscript se compila después a BitcoinScript

Ethereum

Ethereum ha sido sin duda el blockchain responsable de lo que la mayoría entendemos hoy día por smart contract. El título del white paper de Vitalik Buterin en el que describía lo que sería Ethereum ya era una declaración de intenciones: "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform".

Los nodos de Ethereum ejecutan una máquina virtual denominada EVM (Ethereum Virtual Machine) que ejecuta instrucciones EVM.

La máquina virtual se comporta como una máquina de pila y por tanto es Turing Completa. Sin tecnicismos: soporta bucles y puede pensarse como una máquina de propósito general sobre la que puede programarse cualquier cosa.

Estructura de la EVM - Cortesía de la web de Ehereum
Estructura de la EVM - Cortesía de la web de Ehereum

Las instrucciones EVM obviamente son de bajo nivel (equivalentes a código máquina en un lenguaje compilado) por lo que que los programadores de smart contracts de Ethereum generalmente trabajan en un lenguaje con un mayor nivel de abstracción que después compilan a instrucciones EVM para desplegarlo en el blockchain.

Solidity

El lenguaje de programación más popular en Ethereum (y posiblemente para programación de smart contracts en general) es, sin duda, Solidity. Solidity se ha hecho extremadamente popular en parte por su parecido con JavaScript lo que permitía una curva de aprendizaje mucho más suave para programadores que venían de otras disciplinas y querían entrar en el desarrollo de smart contracts.

Vyper

Vyper es un lenguaje de programación con sintaxis similar a Python que también se compila a la EVM de Ethereum. Se ha diseñado teniendo como principos y objetivos tres factores principales: seguridad, simplicidad y auditabilidad (tanto automática como humana). Para conseguir estos objetivos introduce una serie de limitaciones en el lenguaje, entre las que se puede destacar la prohibición de usar llamadas recursivas o bucles infinitos.

La propia web de Vyper declara: "Vyper no intenta ser un sustituto al 100% de todo lo que se puede hacer en Solidity; de hecho prohibirá de forma deliberada o hará algunas cosas más complicadas si considera que de esa forma se consigue el objetivo de incrementar la seguridad".

Blockchains que son compatibles con la EVM (Ethereum Virtual Machine)

Tras el éxito de Ethereum como plataforma para el desarrollo de smart contracts han ido apareciendo otros blockchains que han intentando desarrollar propuestas de valor diferenciadas, potenciando una característica u otra y asumiendo algunos compromisos de manera que fueran mejores opciones que el propio Ethereum según el tipo de aplicación que se quiera desarrollar.

Muchas de estas nuevas blockchains han elegido mantener compatibilidad con la EVM porque ello supone grandes ventajas:

  • utilizar los mismos lenguajes de programación que se utilizan en Ethereum (cualquiera que compile para la EVM como por ejemplo Solidity),
  • reutilizar (casi) todo el ecosistema ya desarrollado: proyectos, bibliotecas de código, herramientas,
  • mantener compatibilidad con Ethereum implica que las aplicaciones desarrolladas en la nueva blockchain pueden potencialmente desplegarse en Ethereum y también es más fácil el intercambio de tokens y otros criptoactivos con Ethereum y, sobre todo,
  • atraer desarrolladores que conocen el ecosistema de desarrollo de la EVM.

Este artículo en Shardeum explica muy bien y con buen detalle qué son las blockchains compatibles con la EVM. Te recomiendo que le eches un vistazo si quieres profundizar.

Algunas de las principales blockchains compatibles con la EVM a día de hoy son las siguientes:

Resumen de redes y lenguajes

Aunque en las secciones previas he nombrado los blockchains más populares y con más base de código desplegado y sus lenguajes de programación de smart contracts asociados, obviamente existen muchos más.

En la siguiente tabla (no exhaustiva) intento hacer un resumen del escenario actual de lenguajes utilizados y en qué cadenas.

Algunas consideraciones:

  • Existen lenguajes específicos para smart contracts (como Solidity o Michelson) y después algunos blockchains deciden utilizar lenguajes de propósito general (como C++ o Rust).
  • Ya hemos visto que el ecosistema Ethereum incluye, cuando hablamos de desarrollo de smart contracts, todos los blockchains que son compatibles con la EVM. No volveré a citar estas cadenas de forma explícita.
  • El modelo de máquina virtual con código en bajo nivel (bytecode) no es exclusivo de la arquitectura de Ethereum y otros blockchains han adoptado un diseño análogo. En ese caso es posible utilizar múltiples lenguajes (específicos o de propósito general) para desarollar smart contracts siempre que exista unacompilador que "traduzca" del lenguaje en alto nivel al bytecode correspondiente. En este caso, el compromiso que he adoptado en el listado es proponer el lenguaje más popular para la cadena en cuestión. Si quieres profundizar, te invito a visitar las webs del blockchain que más te interese.
  • Los lenguajes soportados por cada blockchain así como la aparición de nuevos blockchains es constante así que insisto una vez más que el listado no es exhaustivo y lo será menos a medida que pase tiempo desde la publicación de este artículo.
LenguajeTipoBlockchain
Específicos Bitcoin
C++ Propósito general
JavaScript Propósito general Near
Michelson Específico Tezos
Python Propósito general Algorand
Rust Propósito general
Específicos
Lenguajes de programación y blockchains

Aplicaciones

Cuando hablamos de las posibilidades que ofrece la tecnología blockchain más allá de la gestión de una moneda virtual, estamos hablando en realidad de las posibilidades que habilitan los smart contracts que se ejecutan en sus respectivos blockchains. Así que hablar de aplicaciones de los smart contracts es hablar de las aplicaciones que tiene la tecnología blockchain en general y eso da para un artículo dedicado o para un libro entero.

Teniendo lo anterior en cuenta, quiero centrarme aquí sólo en un pequeño subconjunto de esas aplicaciones, donde es más obvio el valor de los smart contracts porque representan el core principal de la solución. Me refiero a las aplicaciones descentralizadas (DApps por sus siglas en inglés).

Las DApps se orquestan sobre un core construido en el blockchain mediante smart contracts que controlan las funciones principales y gestionan el almacenamiento de valor (en forma de criptomoneda u otro tipo de tokens). Los usuarios interactúan conectando sus wallets sobre una interfaz web ligera que no hace más que dar una interfaz de conexión sencilla hacia el core.

Así pues, si nos centramos en las DApps, algunas aplicaciones que podemos encontrar son estas:

Conclusiones

  • Un smart contract es un programa informático que se ejecuta de manera descentralizada sobre un blockchain y que permite la ejecución automática de acuerdos establecidos previamente y que se han programado en el mismo.
  • Los smart contracts pueden administrar de forma autónoma todos aquellos activos que tienen una representación tokenizada en el blockchain sobre el que se ejecutan. Estos bienes tokenizados pueden ser dinero en forma de la criptomoneda nativa del blockchain, dinero fiat usando stablecoins o activos arbitrarios que pueden ser representados mediante un token.
  • Los smart contracts tienen algunas ventajas sobre los contratos tradicionales:
    • no puede haber diferentes intepretaciones porque el acuerdo está programado de manera determinista,
    • no puede detenerse su ejecución o cambiarse las cláusulas una vez han sido desplegados en el blockchain y
    • son más eficientes porque no requieren de terceros para su ejecución e interpretación y porque pueden mover los bienes intercambiados de manera inmediata.
  • Los smart contracts presentan también algunos retos:
    • la inmutabilidad y la transparencia propia de la tecnología los hace más vulnerables a ataques en caso de un fallo de programación y también complica la actualización de los mismos,
    • no todos los bienes son fácilmente tokenizables y en tal caso el smart contract no puede gestionar totalmente las transacciones derivadas de las cláusulas del contrato y
    • por diseño no tienen fuentes de aleatoriedad o acceso al exterior del blockchain (acceso a Internet por ejemplo) y cuando requieren de estas características han de hacer uso de "oráculos" que introducen sus propios riesgos y dificultades.
  • Existen múltiples blockchains que soportan smart contracts y cada cadena puede utilizar un lenguaje de programación diferente.
  • Ethereum se ha convertido en un estándar de facto como plataforma de smart contracts (con su modelo de máquina virtual - EVM) así como Solidity como lenguaje de programación. Por eso, muchos otros blockchains mantienen compatibilidad con la EVM y Solidity.
  • Estamos al principio de lo que la tecnología de los smart contracts va a permitir hacer. Los avances en tokenización de activos y en regulación de stablecoins ofrecen un futuro prometedor. En cualquier caso, ya existen múltiples aplicaciones y protocolos descentralizados ejecutándose sobre esta tecnología.

Referencias

En orden de aparación en el artículo: