Este artículo forma parte de una serie que pretende comparar Ardor con otros proyectos blockchain con características u objetivos similares. A continuación puedes encontrar las entradas anteriores:

Esta semana he analizado Ethereum, el cual creo que no necesita introducción alguna.

Al estudiar varios de los proyectos que he investigado en esta serie, en ocasiones ha sido difícil encontrar información técnica detallada sobre ellos. En Ethereum sucede exactamente lo contrario: hay tanta información disponible que es difícil resumirla en un artículo de una longitud razonable sin riesgo a simplificar en exceso las ideas.

Por este motivo, he elegido solo dos aspectos de Ethereum para compararlos con Ardor. Esta entrega compara sus contratos inteligentes con las transacciones inteligentes de Ardor y el próximo artículo comparará la manera en que ambas plataformas se enfrentan al problema del crecimiento desmesurado de la blockchain (blockchain bloat). Hay muchos más temas sobre los que me habría gustado hablar, como por ejemplo su plan para convertirse en Proof-of-Stake (Casper), su estrategia state-channel (Raiden y Plasma), su asociación con grandes compañías a través de la Enterprise Ethereum Alliance y ejemplos de proyectos que lo utilizan, pero poder hablar aunque solo sea de un par de estos temas con la rigurosidad necesaria ya es suficiente desafío. Además, los dos temas que he elegido ofrecen, en mi opinión, la comparativa más interesante entre las dos plataformas (visita también el artículo de Ardor Frente a Plasma, enlazado más arriba, para algunas reflexiones sobre Plasma).

Sin más dilación, hablemos sobre los contratos inteligentes o smart contracts.

Los Contratos Inteligentes y la “Diversidad de Estados de una Cuenta”

El diseño de Ethereum combina elementos de Bitcoin y Nxt y añade además varias características novedosas. Al igual que Bitcoin, Ethereum usa un lenguaje de programación de bajo nivel para codificar las transacciones y almacena los contenidos de cada bloque en árboles del tipo Merkle cuyos hashes de raíz están almacenados en las cabeceras de los bloques (más sobre este tema en el próximo artículo). Al igual que Nxt, realiza un seguimiento del estado actual de los saldos de las cuentas y otros datos específicos de las cuentas directamente, en lugar de seguir el modelo de Bitcoin de Salida de Transacciones sin Gastar (Unspent Transaction Output – UTXO).

Las innovaciones más importantes que Ethereum añade a esta combinación son dos: la capacidad de almacenar scripts (contratos) en las llamadas “cuentas de contratos”, las cuales realizan transacciones automáticamente sin estar controladas por un usuario; y la capacidad de que las transacciones persistan en una cuenta desde una transacción hasta la siguiente. El lenguaje de programación de Ethereum es también, de algún modo, más potente que el de Bitcoin, permitiendo que los contratos incluyan loops e invoquen a otros contratos.

Combinando estas ideas, es posible crear los llamados “contractos inteligentes” con estados, que son unas líneas de código y datos que residen en las cuentas de contratos como agentes autónomos, escuchando los inputs de los usuarios y otros contratos y realizando transacciones con ellos de acuerdo a las reglas definidas en el código de su contrato. El apelativo “con estados” de la frase anterior es fundamental: puesto que un contrato inteligente puede tener su propio estado interno, es posible que una transacción afecte la forma en que las transacciones subsecuentes son procesadas. Esto es una diferencia significativa con el modelo de Bitcoin, dónde los scripts de transacciones solo se ejecutan una única vez y dónde el concepto de “estado” disponible para un script esta esencialmente limitado a si un determinado output se ha gastado o no.

(Quizá te hayas dado cuenta de que no he dicho nada sobre la exhaustividad del Turing. Dependiendo de lo escrupuloso que te quieras poner, podrías argumentar en favor de cualquiera de las posiciones acerca de si el lenguaje de programación de Ethereum es realmente Turing en su totalidad. Tal y cómo explica el presentador de este excelente vídeo, ser completamente Turing puede actuar en ocasiones cómo un falso indicador. Es mucho más importante el hecho de que los contratos inteligentes está repletos de estados y pueden realizar transacciones entre ellos y con otros usuarios de maneras muy interesantes.)

Las aplicaciones potenciales de los contratos inteligentes se extienden más allá de establecer condiciones para la transferencia de dinero de una cuenta a otra. Incluso el white paper original (una gran lectura, por cierto) proponía un puñado de usos no-financieros, incluyendo el almacenamiento de archivos, votación, computación distribuida, gobernanza de organizaciones descentralizadas y mercados descentralizados. Desde entonces, los desarrolladores han encontrado multitud de otras aplicaciones, tales como mensajería descentralizada. Y, por supuesto, la aplicación de Ethereum más comúnmente utilizada hasta el momento: llevar a cabo ventas de tokens para varios proyectos.

Las “Transacciones Inteligentes” de Ardor

Si esa lista de aplicaciones te resultan familiares, puede que sea porque todas ellas ya han sido implementadas en Nxt yArdor como como “transacciones inteligentes” predefinidas. Introducidas por el predecesor de Ardor, Nxt, las transacciones inteligentes son porciones de funcionalidades de “blokchain 2.0″ que los desarrolladores de Nxt y Ardor han publicado como parte del mismo protocolo. Estas transacciones permiten a los desarrolladores crear aplicaciones blockchain sin tener que escribir y testear sus propios contratos inteligentes.

Para permitir que los usuarios comunes (es decir, los no desarrolladores) se beneficien también de esta funcionalidad, los monederos oficiales de Nxt y Ardor incluyen un puñado de transacciones inteligentes incluidas. Se trata de:

el Intercambio de Activos, dónde los usuarios pueden emitir activos, comercializarlos y pagar dividendos a los poseedores del activo;
el Sistema Monetario, dónde los usuarios pueden emitir monedas y conducir diferentes tipos de campañas de crowdfunding;
un sistema de mensajería, que permite que los usuarios envíen mensajes de texto simple o codificados;
un sistema de votación, que permite que los usuarios realicen votaciones en función de la cuenta, balance de cuenta, balance de determinados activos o balance de determinadas monedas;
un coin shuffler integrado, que puede otorgar a los usuarios un cierto grado de privacidad difuminando su historial de transacciones;
un almacenamiento de datos descentralizado, que puede grabar el hash de un archivo permanentemente en la blockchain y, opcionalmente, almacenar el archivo en si mismo permanentemente gracias a los nodos de archivo;
un mercado descentralizado, donde los usuarios pueden comprar y vender bienes y servicios entre pares (peer-to-peer);
un nuevo Intercambio de Monedas (solo en Ardor), donde los usuarios pueden comprar y vender las monedas de las diferentes child chains directamente entre sí;
un número de características avanzadas, tales como las transacciones condicionadas, que permiten a los usuarios establecer unas condiciones sobre cuándo y cómo otras transacciones son ejecutadas, y las propiedades de cuenta, que pueden usarse para asociar datos arbitrarios con una cuenta.

Por supuesto que estas no son las únicas transacciones que se pueden construir a partir de las transacciones inteligentes, pero sirven para mostrar el alcance de lo que se puede llegar a alcanzar con ellas. Todas estas características, junto a unas cuantas más, estarán disponibles en Ignis, la primera child chain de Ardor. Los creadores de otras child chains contarán con la opción de implementar tantas de estas características como necesiten hasta amoldarse a sus proyectos.

He escuchado diversas analogías para describir las transacciones inteligentes, pero mi favorita es que son como Legos, mientras que los contratos inteligentes son como arcilla: el primero de ellos no permite el mismo grado de control sobre los detalles más sutiles, pero son más rápidas y fáciles de utilizar que los segundos, y se puede combinar para formar productos finales con resultados espectaculares.

La analogía no es perfecta, por supuesto. Un potente argumento a favor de los contratos inteligentes es que, por ejemplo, es potencialmente posible que toda la lógica de negocios de una aplicación descentralizada (Dapp) se almacenada permanentemente y de forma inmutable en la blockchain, mientras que una Dapp construida a base de combinar transacciones inteligentes es muy probable que incluya algo de código externo. En este último caso, usar la Dapp puede requerir cierto grado de confianza en que el desarrollador no cambiará las reglas en futuras versionas de la misma.

Desde otro punto de vista, esta comparación también pone de relieve el mayor inconveniente de los contratos inteligentes: La facilidad con que los programadores pueden cometer errores de varios millones de dólares que no se puedan corregir.

Consideraciones de Seguridad

Casi cualquier software que es mínimamente complejo contiene imperfecciones y en muchas ocasiones estas imperfecciones hacen que el software pueda ser vulnerable a ataques de un hacker. Los desarrolladores de contratos inteligentes se enfrentan a una tarea particularmente difícil, puesto que el código que escriben es inmutable y, como resultado, sus vulnerabilidades son permanentes.

Desafortunadamente, descubrir fallos catastróficos en contratos inteligentes no ha sido excepcional. El ataque que congeló el equivalente en ether a $150 M almacenado en monederos multifirma de Parity o el hackeo de $30 M del mismo monedero unos meses antes son solo los ejemplos más recientes que hemos visto en diversos titulares, pero no son los primeros y, con toda seguridad, no serán los últimos. Para una vista general de algunas de las vulnerabilidades comunes y un análisis de diversos ataques reales, incluyendo el desafortunado hackeo del DAO, recomiendo fervientemente leer este excelente documento elaborado por tres investigadores de la Universidad de Cagliari.

No hay que pasar por alto que ni el protocolo de Ethereum ni la Máquina Virtual de Ethereum (Ethereum Virtual Machine – EVM) fueron responsables de ninguno de estos ataques. Los seguidores de Ethereum a menudo sacan a relucir este punto, argumentando que Ethereum en si mismo es bastante seguro y todo lo que se necesita es que los desarrolladores escriban mejores contratos inteligentes. En un sentido literal tienen razón, por supuesto: En todos los casos Ethereum hizo lo que se suponía que debía hacer y la culpa recae en último lugar en los desarrolladores de los contratos inteligentes.

Pero personalmente me pregunto si este juicio que pretende absolver a Ethereum es demasiado rápido y si el problema podría ser mayor que unas pocas líneas erróneas en un contrato inteligente. De cualquier modo, por ahora me parece que el argumento fundamental de Ethereum es que otorga a los desarrolladores un poder tremendo pero unas herramientas insuficientes para usar ese poder de forma segura.

La ambición de los desarrolladores casi siempre excede el nivel de complejidad que se puede alcanzar mientras se mantiene, a la vez, el código perfectamente libre de errores, y siempre existirá la tentación de hacer que las funcionalidades tengan prioridad sobre la seguridad (esto es casi universal en el desarrollo de software, por cierto). Al inmortalizar el código que han creado, que contiene errores, almacenándolo en una blockchain, el brutal y despiadado Ethereum hará que paguen por sus pecados.

Afortunadamente, hay ciertas maneras de mitigar el riesgo de escribir contratos inteligentes vulnerables. Por ejemplo, es posible designar un contrato inteligente que pueda ser actualizado delegando para ellos sus responsabilidades en un segundo contrato, habitualmente denominado “contrato librería”, en una dirección que se puede cambiar para apuntar a una nueva librería más adelante.

Este enfoque permite a los desarrolladores parchear vulnerabilidades pero, como consecuencia, introduce la peliaguda cuestión de quien debe estar autorizado para cambiar a un nuevo contrato librería. Si es una única cuenta de un tercero, entonces el diseño introduce un cierto grado de confianza entre esa cuenta y el resto de usuarios. Por otro lado, si el desarrollador toma otro enfoque, tal como permitir votar a una mayoría de usuarios para aprobar cada nuevo contrato librería, entonces pueden emerger nuevos problemas a solucionar, tales como escribir un mecanismo de votación, asegurarse de que los usuarios están lo suficientemente informados y comprometidos para votar, y evitar que un hacker cause un daño considerable durante todo el tiempo que se tarda en organizar una votación.

Otra aproximación muy prometedora sobre la seguridad de los contratos inteligentes es usar técnicas de verificación formal tomadas prestadas de las matemáticas. No sé mucho sobre estos métodos formales, así que tomad con pinzas lo que escribo aquí, pero no se si es más sencillo (o simplemente realizable) con programas sencillos cuya funcionalidad puede ser expresada como una serie de reglas sencillas y cortas. En estos casos, puede ser posible demostrar con certeza que el programa no contiene errores. Sin embargo, incluso técnicas evidentes como el looping o la recursividad pueden complicar el análisis significativamente, así que es mejor si el programa a testear es lo más sencillo posible.

¿Por qué insisto tanto en este tema? Poniendo todas estas ideas juntas podría parecer que la mejor manera para escribir contratos inteligentes implicaría: 1) mantenerlos lo más cortos y sencillos posibles; 2) delegar la lógica del núcleo de negocios a una librería de contratos que pudiese ser actualizada, en caso necesario; y 3) reutilizar librerías que han sido concienzudamente examinadas, para reducir al mínimo la cantidad de código nuevo. Si el segundo de estos puntos requiere que los usuarios de un contrato tengan que depositar su confianza en el autor de un contrato en cierto grado, como sucede habitualmente, entonces los contratos designados de acuerdo a los anteriores tres puntos comienzan a parecerse mucho a las transacciones inteligentes de Ardor: bits de código estable y concienzudamente testeado que permiten obtener las funcionalidades más comúnmente necesitadas, las cuales los desarrolladores pueden combinar para formar programas más complejos.

El Equilibro entre Seguridad y Flexibilidad

No estoy sugiriendo que las transacciones inteligentes de Ardor puedan realizar todo lo que puedan llegar a realizar los contratos inteligentes de Ethereum, ni estoy diciendo que combinaciones de transacciones inteligentes puedan siempre emular a los contratos inteligentes. Sin embargo, lo que estoy diciendo es que creo que hay una tensión natural entre la flexibilidad que una plataforma ofrece y la seguridad del código que, irremediablemente, los desarrolladores tienden a escribir usándola.

Desde este punto de vista, las plataformas blockchain están siempre asentadas en un bucle seguridad-flexibilidad. Próximo al extremo de la “seguridad” está Bitcoin, cuyo lenguaje de programación es deliberadamente bastante limitado para evitar que los usuarios bloqueen sus cuentas con scripts vulnerables (aunque esto es posible, por supuesto). Nxt y Ardor ocupan una posición intermedia en este espectro, limitando a los desarrolladores con un juego de tipos de transacciones predefinidas, pero incorporando una enorme variedad de funcionalidades en esos tipos.

Los contratos inteligentes de Ethereum, por su parte, abarcan todo el espectro. Es posible escribir scripts extremadamente simples, triviales y seguros en Ethereum y también es posible escribir scripts más complicados que contengan vulnerabilidades muy sutiles. Y lo que quizá sea igual de importante, es difícil para los usuarios diferenciar entre esos casos, y no sería razonable en ningún caso esperar que el usuario lo hiciese. Usar Ethereum de manera segura implica evitar la parte del espectro que está más próxima a la “flexibilidad”, incluso aunque esto suponga la introducción de un cierto grado de confianza entre usuarios y desarrolladores.

Finalmente, vale la pena mencionar que Ardor ofrece una nueva característica, no disponible previamente en Nxt, que le ayuda a aproximarse al lado de la “flexibilidad”: la habilidad para combinar transacciones condicionadas usando operadores booleanos tales como AND, OR y NOT, para conseguir un comportamiento semejante a unos contratos inteligentes primitivos.

En pocas palabras, las transacciones condicionadas permiten a los usuarios condicionar la ejecución de una transacción latente a que tenga lugar un determinado evento, tal como la aprobación por parte de un determinado número de cuentas específicas, una votación en la que pueden participar todas aquellas cuentas que posean un determinado activo, el paso de una determinada cantidad de tiempo (timelock) o la revelación de un secreto (por ejemplo, un hashlock). En Ardor, las combinaciones de estos tipos de transacciones condicionadas pueden dar lugar a condiciones más complejas, tales como “la transacción X es válida si la mayoría de los accionistas de la compañía ABC la aprueban antes de una fecha Y, salvo que sean vetadas por una gran mayoría de los miembros de la junta de la empresa ABC.”

Sin duda, también se podrían combinar transacciones condicionadas de manera que permitiese la obtención de resultados inesperados, lo que podría incluir la pérdida de fondos. Pero yo diría que la ventaja sobre los contratos inteligentes en términos de seguridad todavía está ahí, puesto que los desarrolladores se pueden centrar en asegurarse que la lógica de la transacción para los negocios es segura, sin tener que preocuparse por los errores de bajo nivel (low-level bugs) tales como las condiciones de la carrera. Y por supuesto, la desventaja de ofrecer menor flexibilidad que los contratos inteligentes sigue también ahí.

Conclusión

Con un protocolo definido por una serie de transacciones inteligentes pre-compiladas en lugar de un lenguaje de programación de bajo nivel, Ardor probablemente nunca será capaz de ofrecer a los desarrolladores un rango de posibilidades tan grande como hace Ethereum, al menos en los casos en que todo deba hacerse en la cadena para no tener que depositar en la confianza entre las partes. Por otro lado, escribir contratos no triviales que sigan las mejores prácticas de seguridad requiere igualmente de confianza adicional entre usuarios y desarrolladores. Y, por supuesto, los usuarios de Ethereum tienen que acabar confiando en que los autores de los contratos inteligentes no han cometido ningún error y han escrutado concienzudamente y probado su código, para estar completamente seguros de ello.

Naturalmente, puedes pensar que esto mismo sucede con cualquier software, incluyendo las transacciones inteligentes de Ardor, pero hay una diferencia clave: simplemente hay mucho más código ejecutándose en Ethereum. Nxt ha sido de código abierto desde el comienzo, ofreciendo una gran oportunidad para ser revisado. El código de Ardor, que está basado en el código base de Nxt, será liberado pronto. Además, cada nuevo cambio añadido el protocolo ha sido chequeado en profundidad en una testnet pública antes de ser lanzado oficialmente. Lo mismo debería cumplirse para cada uno de los contratos inteligentes, pero con tanto código escrito, parece que es inevitable que existan más oportunidades para que los errores se cuelen en el entorno de producción.

En cualquier caso, sospecho que el grado en que la mayoría de las Dapps exitosas dependerán de código inmutable todavía es una pregunta sin respuesta. Si el acceso a una base de datos inmutable y a un puñado de operaciones simples sobre esos datos son suficientes para la mayoría de las aplicaciones, entonces las transacciones inteligentes de Ardor parece que tienen una clara ventaja sobre los contratos inteligentes. Por el contrario, si el concepto de que “el código es la ley” resulta ser esencial para la viabilidad de la mayoría de las Dapps, dónde cada Dapp requiera que la mayoría de su exclusivo código sea almacenado en la blockchain para no depender para nada de la confianza en un tercero, entonces el enfoque de Ethereum sea probablemente superior.

Confío en que habrá aplicaciones del mundo real que encajen en estas plataformas. Pero también me pregunto si a la larga quedará dejará claro que uno de los dos enfoques va a manejar la mayoría de las aplicaciones. Que enfoque resultará el ganador no está claro para mí, pero sospecho que el factor decisivo será la valoración de los usuarios sobre el grado de confianza que requiere cada opción. Y puesto que toda la atracción de la tecnología blockchain proviene de que permite a los usuarios realizar transacciones requiriendo de un mínimo grado de confianza, yo diría que el resultado de esa valoración será el realmente válido.

¡Gracias por leer este texto! Si te ha gustado este artículo, asegúrate de leer la siguiente parte de la serie, que comparará la forma en que Ardor y Ethereum gestionan el crecimiento desmesurado de la blockchain.

Prueba Ardor en la testnet

Acerca de la última versión lanzada de Ardor para la testnet