Por qué muchos casos de uso de contratos inteligentes son simplemente imposibles

El Dr. Gideon Greenspan es el fundador y director ejecutivo de Coin Sciences, la empresa detrás de la plataforma MultiChain para cadenas de bloques privadas.

En este artículo de Opinión , Greenspan analiza los contratos inteligentes basados ​​en blockchain y por qué esta aplicación de la Tecnología puede estar sufriendo expectativas infladas.

Como desarrollador de una popular plataforma blockchain, a veces me preguntan si los contratos inteligentes similares a Ethereum están en la hoja de ruta de MultiChain. La respuesta que siempre doy es: "No, o al menos no todavía".

Pero en el mundo de las cadenas de bloques, repleto de publicidad,contratos inteligentes Están de moda, así que ¿por qué no? Bueno, el problema es que, si bien conocemos tres casos de uso sólidos para cadenas de bloques con permisos al estilo de Bitcoin (procedencia, registro de empresas y Finanzas ligeras), aún no hemos encontrado el equivalente para... Ethereumcontratos inteligentes.

No es que la gente no entienda qué quieren que hagan los contratos inteligentes. Más bien, muchas de estas ideas son simplemente imposibles. Cuando las personas inteligentes escuchan el término "contratos inteligentes", su imaginación tiende a desbordarse. Sueñan con software inteligente autónomo, que viaja por el mundo y se lleva consigo datos. Desafortunadamente, la realidad de los contratos inteligentes es más mundana.

Un contrato inteligente es un fragmento de código que se almacena en una cadena de bloques, se activa mediante transacciones de la cadena de bloques y lee y escribe datos en la base de datos de esa cadena de bloques. Eso es todo. De verdad.

Un contrato inteligente es simplemente un nombre elegante para el código que se ejecuta en una cadena de bloques e interactúa con el estado de dicha cadena. ¿Y cuál es el código? Es Pascal, es Python, es PHP, es Java, es Fortran, es C++. Si hablamos de bases de datos, son procedimientos almacenados escritos en una extensión de SQL.

Todos estos lenguajes son fundamentalmente equivalentes y resuelven los mismos tipos de problemas de la misma manera. Claro que cada uno tiene sus fortalezas y debilidades: sería una locura crear un sitio web en C o comprimir vídeo HD en Ruby. Pero al menos en principio, podrías hacerlo si quisieras. Solo pagarías un alto precio en términos de comodidad, rendimiento y, muy probablemente, en tu cabello.

El problema con los contratos inteligentes no es sólo que las expectativas de la gente sean exageradas, sino que estas expectativas llevan a muchos a gastar tiempo y dinero en ideas que no se pueden implementar.

Parece que las grandes empresas cuentan con recursos suficientes para recorrer un largo camino: desde el momento en que la alta dirección se enfrenta a una nueva Tecnología hasta que comprende plenamente sus ventajas y limitaciones. Quizás nuestra propia experiencia pueda ayudar a acortar este tiempo.

Durante los últimos nueve meses, nos han presentado muchos casos de uso de contratos inteligentes y nos hemos encontrado respondiendo, una y otra vez, que simplemente no se pueden hacer.

Como resultado, hemos identificado los tres conceptos erróneos más comunes sobre los contratos inteligentes. Estas ideas no son erróneas porque la Tecnología sea inmadura o las herramientas aún no estén disponibles.

Más bien, no comprenden las propiedades fundamentales del código que vive en una base de datos y se ejecuta de forma descentralizada.

1. Contactar con servicios externos

A menudo, el primer caso de uso propuesto es un contrato inteligente que modifica su comportamiento en respuesta a un evento externo. Por ejemplo, una Regulación de seguro agrícola que paga condicionalmente según la cantidad de lluvia en un mes determinado.

El proceso imaginado es más o menos así: el contrato inteligente espera hasta el momento predeterminado, recupera el informe meteorológico de un servicio externo y se comporta adecuadamente en función de los datos recibidos.

Todo esto parece bastante simple, pero también es imposible. ¿Por qué? Porque una cadena de bloques es un sistema basado en el consenso, lo que significa que solo funciona si cada nodo alcanza un estado idéntico tras procesar cada transacción y bloque.

Todo lo que ocurre en una cadena de bloques debe ser completamente determinista, sin posibilidad de que se produzcan diferencias. En el momento en que dos nodos honestos no están de acuerdo sobre el estado de la cadena, todo el sistema se vuelve inútil.

Ahora bien, recuerde que los contratos inteligentes se ejecutan de forma independiente en cada nodo de una cadena. Por lo tanto, si un contrato inteligente recupera información de una fuente externa, cada nodo realiza esta recuperación repetida e individualmente. Sin embargo, dado que esta fuente está fuera de la cadena de bloques, no hay garantía de que todos los nodos reciban la misma respuesta.

Quizás la fuente cambie su respuesta entre solicitudes de diferentes nodos, o quizás deje de estar disponible temporalmente. En cualquier caso, se rompe el consenso y la cadena de bloques muere.

Entonces, ¿cuál es la solución alternativa? En realidad, es bastante sencilla. En lugar de que un contrato inteligente inicie la recuperación de datos externos, una o más partes de confianza ("oráculos") crean una transacción que integra esos datos en la cadena. Cada nodo tendrá una copia idéntica de estos datos, por lo que pueden usarse de forma segura en el cálculo de un contrato inteligente.

En otras palabras, un oráculo empuja los datos hacia la cadena de bloques en lugar de que un contrato inteligente los extraiga.

Cuando se trata de contratos inteligentes que generan Eventos en el mundo exterior, surge un problema similar. Por ejemplo, a muchos les gusta la idea de un contrato inteligente que llama a la API de un banco para transferir dinero. Pero si cada nodo ejecuta el código de forma independiente en la cadena, ¿quién es responsable de llamar a esta API?

Si la respuesta es solo un nodo, ¿qué ocurre si ese nodo en particular falla, intencionalmente o no? Y si la respuesta es todos los nodos, ¿podemos confiar la contraseña de esa API a cada uno de ellos? ¿Realmente queremos que se llame a la API cientos de veces? Peor aún, si el contrato inteligente necesita saber si la llamada a la API fue exitosa, volvemos al problema de depender de datos externos.

Como antes, existe una solución alternativa sencilla. En lugar de que el contrato inteligente llame a una API externa, utilizamos un servicio confiable que monitorea el estado de la blockchain y realiza ciertas acciones en respuesta. Por ejemplo, un banco podría supervisar proactivamente una blockchain y realizar transferencias de dinero que reflejen las transacciones dentro de la blockchain. Esto no representa ningún riesgo para el consenso de la blockchain, ya que la cadena desempeña un papel completamente pasivo.

Mirando estas dos soluciones alternativas, podemos hacer algunas observaciones.

En primer lugar, ambos requieren una entidad confiable para gestionar las interacciones entre la cadena de bloques y el mundo exterior. Si bien esto es técnicamente posible, socava el objetivo de un sistema descentralizado.

En segundo lugar, los mecanismos utilizados en estas soluciones alternativas son ejemplos claros de lectura y escritura en una base de datos. Un oráculo que proporciona información externa simplemente escribe dicha información en la cadena. Y un servicio que replica el estado de la cadena de bloques en el mundo real simplemente lee de esa cadena. En otras palabras, cualquier interacción entre una cadena de bloques y el mundo exterior se limita a las operaciones habituales de la base de datos.

Hablaremos más sobre este hecho más adelante.

2. Aplicación de pagos en cadena

Aquí hay otra propuesta que solemos escuchar con frecuencia: usar un contrato inteligente para automatizar el pago de cupones de un llamado " BOND inteligente". La idea es que el código del contrato inteligente inicie automáticamente los pagos en el momento oportuno, evitando procesos manuales y garantizando que el emisor no incumpla.

Por supuesto, para que esto funcione, los fondos utilizados para realizar los pagos también deben estar dentro de la cadena de bloques; de lo contrario, un contrato inteligente no podría garantizar su pago.

Recordemos que una cadena de bloques es simplemente una base de datos, en este caso, un libro de contabilidad financiera que contiene el BOND emitido y efectivo. Por lo tanto, cuando hablamos de pagos de cupones, nos referimos a operaciones de base de datos que se realizan automáticamente en un momento acordado.

Si bien esta automatización es técnicamente viable, presenta una dificultad financiera. Si los fondos utilizados para el pago de cupones están controlados por el contrato inteligente del bono, dichos pagos pueden garantizarse. Sin embargo, esto también significa que el emisor del BOND no puede utilizar esos fondos para ningún otro fin. Y si esos fondos no están bajo el control del contrato inteligente, no hay forma de garantizar el pago.

En otras palabras, un BOND inteligente es inútil para el emisor o inútil para el inversor. Y, pensándolo bien, este es un resultado completamente obvio.

Desde la perspectiva del inversor, el objetivo principal de un BOND es su atractiva tasa de rendimiento, a costa de cierto riesgo de impago. Y para el emisor, el propósito de un bono es recaudar fondos para una actividad productiva, aunque algo arriesgada, como la construcción de una nueva fábrica.

El emisor del BOND no puede utilizar los fondos recaudados y, al mismo tiempo, garantizar el reembolso al inversor. No debería sorprender que la relación entre riesgo y rentabilidad no sea un problema que las cadenas de bloques puedan resolver.

3. Ocultar datos confidenciales

Como he escrito anteriormente, el mayor desafío en la implementación de cadenas de bloques es la transparencia radical que brindan.

Por ejemplo, si 10 bancos configuran una cadena de bloques conjuntamente y dos realizan una transacción bilateral, esta será visible inmediatamente para los otros ocho. Si bien existen diversas estrategias para mitigar este problema, ninguna supera la simplicidad y eficiencia de una base de datos centralizada donde un administrador de confianza tiene control total sobre quién puede ver qué.

Algunas personas creen que los contratos inteligentes pueden resolver este problema. Parten del hecho de que cada contrato inteligente contiene su propia base de datos en miniatura, sobre la cual tiene control total. Todas las operaciones de lectura y escritura en esta base de datos están mediadas por el código del contrato, lo que imposibilita que un contrato lea directamente los datos de otro. (Esta estrecha conexión entre datos y código se denomina encapsulación y es la base del popular paradigma de la programación orientada a objetos).

Entonces, si un contrato inteligente no puede acceder a los datos de otro, ¿hemos resuelto el problema de la confidencialidad de la cadena de bloques? ¿Tiene sentido hablar de ocultar información en un contrato inteligente? Lamentablemente, la respuesta es no.

Porque incluso si un contrato inteligente no puede leer los datos de otro, estos se almacenan en cada nodo de la cadena. Para cada participante de la blockchain, se encuentran en la memoria o disco de un sistema que controla completamente. Y nada les impide leer la información de su propio sistema, si así lo desean.

Ocultar datos en un contrato inteligente es casi tan seguro como ocultarlos en el código HTML de una página web. Claro, los usuarios web comunes no los verán, porque no se muestran en la ventana de su navegador. Pero basta con que un navegador web agregue la función "Ver código fuente" (como todos tienen), y la información se vuelve visible para todos.

De manera similar, para los datos ocultos en contratos inteligentes, todo lo que se necesita es que alguien modifique su software de blockchain para mostrar el estado completo del contrato, y se pierde toda apariencia de secreto.

Un programador medianamente decente podría hacer eso en una hora más o menos.

Para qué sirven los contratos inteligentes

Con tantas cosas que los contratos inteligentes no pueden hacer, ONE podría preguntarse para qué sirven realmente. Pero para responder a esta pregunta, debemos remontarnos a los fundamentos de las cadenas de bloques. En resumen, una cadena de bloques permite que una base de datos sea compartida de forma directa y segura entre entidades que no confían entre sí, sin necesidad de un administrador central.

Las cadenas de bloques permiten la desintermediación de datos, lo que puede generar ahorros significativos en complejidad y costos.

Cualquier base de datos se modifica mediante "transacciones", que contienen un conjunto de cambios en dicha base de datos que deben ser exitosos o fallidos en su conjunto. Por ejemplo, en un libro de contabilidad financiera, un pago de ALICE a Roberto se representa mediante una transacción que (a) comprueba si ALICE tiene fondos suficientes, (b) deduce una cantidad de la cuenta de Alicia y (c) añade la misma cantidad a la de Roberto.

En una base de datos centralizada convencional, estas transacciones las crea una única autoridad de confianza. En cambio, en una base de datos compartida basada en blockchain, cualquiera de los usuarios de dicha blockchain puede crear transacciones. Dado que estos usuarios no confían plenamente entre sí, la base de datos debe contener reglas que restrinjan las transacciones realizadas.

Por ejemplo, en un libro de contabilidad financiero peer to peer, cada transacción debe preservar la cantidad total de fondos; de lo contrario, los participantes podrían darse libremente tanto dinero como quisieran.

ONE pueden imaginar diversas maneras de expresar estas reglas, pero por ahora existen dos paradigmas dominantes, inspirados en Bitcoin y Ethereum, respectivamente. El método Bitcoin , que podríamos llamar "restricciones de transacción", evalúa cada transacción en función de: (a) las entradas de la base de datos eliminadas por esa transacción y (b) las entradas creadas.

En un libro contable financiero, la regla establece que la cantidad total de fondos en las entradas eliminadas debe coincidir con la de las creadas. (Consideramos que modificar una entrada existente equivale a eliminarla y crear una ONE en su lugar).

El segundo paradigma, proveniente de Ethereum, son los contratos inteligentes. Este establece que todas las modificaciones a los datos de un contrato deben ser realizadas por su código. (En el contexto de las bases de datos tradicionales, podemos considerarlo como un procedimiento almacenado obligatorio). Para modificar los datos de un contrato, los usuarios de la blockchain envían solicitudes a su código, que determina si se cumplen dichas solicitudes y cómo.

Como en este ejemplo, el contrato inteligente de un libro de contabilidad financiero realiza las mismas tres tareas que el administrador de una base de datos centralizada: verificar si hay fondos suficientes, deducir de una cuenta y agregar a otra.

Ambos paradigmas son eficaces y cada uno tiene sus ventajas y desventajas. En resumen, las restricciones de transacciones al estilo de Bitcoin proporcionan mayor concurrencia y rendimiento, mientras que los contratos inteligentes al estilo de Ethereum ofrecen mayor flexibilidad.

Entonces, volviendo a la pregunta de para qué sirven los contratos inteligentes: los contratos inteligentes son para casos de uso de blockchain que no se pueden implementar con restricciones de transacciones.

Dado este criterio para el uso de contratos inteligentes, aún no he visto un caso de uso sólido para cadenas de bloques con permisos que califique.

Todas las atractivas aplicaciones de blockchain que conozco pueden implementarse con transacciones similares a las de Bitcoin, que permiten gestionar la concesión de permisos y el almacenamiento general de datos, así como la creación, transferencia, depósito en garantía, intercambio y destrucción de activos. Sin embargo, siguen surgiendo nuevos casos de uso, y no me sorprendería que algunos requieran el poder de los contratos inteligentes. O, al menos, una extensión del paradigma de Bitcoin .

Cualquiera que sea la respuesta, la clave para recordar es que los contratos inteligentes son simplemente un método para restringir las transacciones realizadas en una base de datos.

Esto es sin duda útil y esencial para que la base de datos sea segura para compartir. Pero los contratos inteligentes no pueden hacer nada más y, desde luego, no pueden escapar de los límites de la base de datos en la que residen.

Imagen de lápiz y borradorvía Shutterstock