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 porporcionaba 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: