Cuidado con el imposible contrato inteligente

Los tres conceptos erróneos sobre contratos inteligentes más comunes

Como desarrolladores de una popular plataforma blockchain, a veces nos preguntan si los contratos inteligentes similares a Ethereum están en el MultiChain mapa vial. La respuesta que siempre doy es: no, o al menos no todavía.

Pero en el mundo lleno de exageraciones de las cadenas de bloques, los contratos inteligentes están de moda, así que ¿por qué no? Bueno, el problema es que, si bien ahora conocemos tres casos de uso sólidos para blockchains autorizados de estilo Bitcoin (procedencia, registros entre empresas y finanzas livianas), aún no hemos encontrado el equivalente para los contratos inteligentes de estilo Ethereum.

No es que las personas carezcan de ideas sobre lo que quieren que hagan los contratos inteligentes. Más bien, es que muchas de estas ideas son simplemente imposibles. Verá, cuando las personas inteligentes escuchan el término "contratos inteligentes", su imaginación tiende a volverse loca. Evocan sueños de software inteligente autónomo, que salen al mundo y llevan sus datos para el viaje.

Desafortunadamente, la realidad de los contratos inteligentes es mucho más mundana que todo eso:

Un contrato inteligente es un fragmento de código que se almacena en una cadena de bloques, desencadenado por transacciones de la cadena de bloques, y que lee y escribe datos en la base de datos de esa cadena de bloques.

Eso es. De Verdad. Un contrato inteligente es solo un nombre elegante para el código que se ejecuta en una cadena de bloques e interactúa con el estado de esa cadena de bloques. Y qué is ¿código? Es Pascal, es Python, es PHP. Es Java, es Fortran, es C ++. Si estamos hablando de bases de datos, es procedimientos almacenados escrito en una extensión de SQL. Todos estos lenguajes son fundamentalmente equivalentes, resolviendo los mismos tipos de problemas de la misma manera. Por supuesto, cada uno tiene sus fortalezas y debilidades: sería una locura construir un sitio web en C o comprimir video HD en Ruby. Pero en principio al menos, podrías si quisieras. Simplemente pagarías un alto precio en términos de conveniencia, rendimiento y muy probablemente tu cabello.

El problema con los contratos inteligentes no es solo que las expectativas de las personas sean exageradas. Es que estas expectativas están llevando a muchos a gastar tiempo y dinero en ideas que no pueden implementarse. Parece que las grandes empresas tienen recursos suficientes para recorrer un largo camino, desde el momento en que la alta gerencia encuentra una nueva tecnología, hasta que las ventajas y limitaciones de esa tecnología se comprenden realmente. Quizás nuestra propia experiencia pueda ayudar a acortar este tiempo.

En los últimos nueve meses, hemos 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 de contratos inteligentes que se sostienen más comúnmente. Estas ideas no están equivocadas porque la tecnología es inmadura o las herramientas aún no están disponibles. Más bien, malinterpretan el propiedades fundamentales del código que vive en una base de datos y se ejecuta de manera descentralizada.

Ponerse en contacto con servicios externos

A menudo, el primer caso de uso propuesto es un contrato inteligente que cambia su comportamiento en respuesta a algún evento externo. Por ejemplo, una póliza de seguro agrícola que paga condicionalmente en función de la cantidad de lluvia en un mes determinado. El proceso imaginado es más o menos así: el contrato inteligente espera hasta el tiempo predeterminado, recupera el informe meteorológico de un servicio externo y se comporta adecuadamente en función de los datos recibidos.

Todo esto suena bastante simple, pero también es imposible. ¿Por qué? Debido a que 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 después de procesar cada transacción y bloque. Todo lo que ocurre en una cadena de bloques debe ser completamente determinista, sin posibilidad de que las diferencias se cuelen. En el momento en que dos nodos honestos no estén de acuerdo sobre el estado de la cadena, todo el sistema deja de tener valor.

Ahora recuerde que los contratos inteligentes se ejecutan independientemente por cada nodo en una cadena. Por lo tanto, si un contrato inteligente recupera alguna información de una fuente externa, esta recuperación se realiza de forma repetida y por separado por cada nodo. Pero debido a que esta fuente está fuera de la cadena de bloques, no hay garantía de que cada nodo reciba la misma respuesta. Tal vez la fuente cambie su respuesta en el tiempo entre solicitudes de diferentes nodos, o tal vez no esté disponible temporalmente. De cualquier manera, el consenso se rompe y toda la cadena de bloques muere.

Entonces, ¿cuál es la solución? En realidad, es bastante simple. En lugar de un contrato inteligente que inicie la recuperación de datos externos, una o más partes confiables ("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 puede usarse de manera segura en un cálculo de contrato inteligente. En otras palabras, un oráculo empuja los datos en la cadena de bloques en lugar de un contrato inteligente tracción en.

Cuando se trata de contratos inteligentes que causan eventos en el mundo exterior, aparece un problema similar. Por ejemplo, a muchos les gusta la idea de un contrato inteligente que llame a la API de un banco para transferir dinero. Pero si cada nodo ejecuta independientemente el código en la cadena, ¿quién es responsable de llamar a esta API? Si la respuesta es solo un nodo, ¿qué sucede si ese nodo en particular funciona mal, deliberadamente o no? Y si la respuesta es cada nodo, ¿podemos confiar en cada nodo con la contraseña de esa API? ¿Y realmente queremos que la API se llame cientos de veces? Peor aún, si el contrato inteligente necesita saber si la llamada API fue exitosa, volvemos al problema de depender de datos externos.

Como antes, hay una solución simple disponible. En lugar del contrato inteligente que llama a una API externa, usamos un servicio confiable que monitorea el estado de la cadena de bloques y realiza ciertas acciones en respuesta. Por ejemplo, un banco podría mirar proactivamente una cadena de bloques y realizar transferencias de dinero que reflejen las transacciones en cadena. Esto no presenta ningún riesgo para el consenso de la cadena de bloques porque la cadena juega un papel completamente pasivo.

Mirando estas dos soluciones, podemos hacer algunas observaciones. Primero, ambos requieren una entidad confiable para administrar 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 son ejemplos directos de leer y escribir una base de datos. Un oráculo que proporciona información externa es simplemente escribir esa información en la cadena. Y un servicio que refleja el estado de la cadena de bloques en el mundo real no está haciendo nada más que leer de esa cadena. En otras palabras, cualquier interacción entre una cadena de bloques y el mundo exterior está restringida a las operaciones regulares de la base de datos. Hablaremos más sobre este hecho más adelante.

Hacer cumplir los pagos en cadena

Aquí hay otra propuesta que tendemos a escuchar mucho: usar un contrato inteligente para automatizar el pago de cupones para un llamado "bono inteligente". La idea es que el código de contrato inteligente inicie automáticamente los pagos en los momentos apropiados, evitando procesos manuales y garantizando que el emisor no pueda incumplir.

Por supuesto, para que esto funcione, los fondos utilizados para realizar los pagos también deben vivir dentro de la cadena de bloques, de lo contrario, un contrato inteligente no podría garantizar su pago. Ahora recuerde que una cadena de bloques es solo una base de datos, en este caso un libro de contabilidad financiero que contiene el bono emitido y algo de efectivo. Entonces, cuando hablamos de pagos de cupones, de lo que estamos hablando en realidad es de operaciones de bases de datos que tienen lugar automáticamente a la hora acordada.

Si bien esta automatización es técnicamente factible, sufre una dificultad financiera. Si los fondos utilizados para el pago de cupones están controlados por el contrato inteligente del bono, entonces esos pagos pueden ser garantizados. Pero esto también significa esos fondos el emisor de bonos no puede utilizarlo para otra cosa. Y si esos fondos no está bajo el control del contrato inteligente, entonces no hay forma de garantizar el pago.

En otras palabras, un bono inteligente no tiene sentido para el emisor o no tiene sentido para el inversor. Y si lo piensas, este es un resultado completamente obvio. Desde la perspectiva de un inversor, el objetivo de un bono es su atractiva tasa de rendimiento, a costa de algún riesgo de incumplimiento. Y para el emisor, el propósito de un bono es recaudar fondos para una actividad productiva pero algo arriesgada, como la construcción de una nueva fábrica. No hay forma de que el emisor de bonos haga uso de los fondos recaudados, al mismo tiempo que garantiza que el inversor será reembolsado. No debería sorprendernos que La conexión entre riesgo y retorno no es un problema que las cadenas de bloques puedan resolver.

Ocultar datos confidenciales

Como yo he escrito anteriormente, el mayor desafío en el despliegue de blockchains es la transparencia radical que brindan. Por ejemplo, si diez bancos establecen una cadena de bloques juntos, y dos realizan una transacción bilateral, esto será inmediatamente visible para los otros ocho. Si bien existen varias estrategias para mitigar este problema, ninguna supera la simplicidad y la eficiencia de una base de datos centralizada, en la cual un administrador confiable tiene control total sobre quién puede ver qué.

Algunas personas piensan que los contratos inteligentes pueden resolver este problema. Comienzan con el 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 hace imposible que un contrato lea los datos de otro directamente. (Este acoplamiento estrecho entre datos y código se llama encapsulación, y es la base de la popular programación orientada a objetos paradigma.)

Entonces, si un contrato inteligente no puede acceder a los datos de otro, ¿hemos resuelto el problema de la confidencialidad de blockchain? ¿Tiene sentido hablar de ocultar información en un contrato inteligente? Desafortunadamente, la respuesta es no. Porque incluso si un contrato inteligente no puede leer los datos de otro, esos datos aún se almacenan en cada nodo de la cadena. Para cada participante de blockchain, está en la memoria o en el disco de un sistema que ese participante controla por completo. Y no hay nada que les impida leer la información de su propio sistema, si así lo eligen.

Ocultar datos en un contrato inteligente es tan seguro como ocultarlo en el código HTML de una página web. Claro, los usuarios web normales no lo verán, porque no se muestra en la ventana de su navegador. Pero todo lo que se necesita es que un navegador web agregue una función 'Ver código fuente' (como todos lo han hecho), y la información oculta se vuelve universalmente visible. Del mismo modo, para los datos ocultos en los contratos inteligentes, todo lo que se necesita es que alguien modifique su software blockchain para mostrar el estado completo del contrato, y se pierde toda la apariencia de secreto. Un programador medio 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, uno podría preguntarse para qué son realmente. Pero para responder a esta pregunta, debemos volver a los fundamentos de las propias cadenas de bloques. En resumen, una cadena de bloques permite que una base de datos sea compartida de forma directa y segura por entidades que no confían entre sí, sin necesidad de un administrador central. Las cadenas de bloques permiten la desintermediación de datos, y esto puede conducir a ahorros significativos en complejidad y costo.

Cualquier base de datos se modifica a través de "transacciones", que contienen un conjunto de cambios en esa base de datos que deben tener éxito o fallar en su conjunto. Por ejemplo, en un libro de contabilidad financiero, un pago de Alice a Bob está representado por una transacción que (a) verifica si Alice tiene fondos suficientes, (b) deduce una cantidad de la cuenta de Alice y (c) agrega la misma cantidad a Bob .

En una base de datos centralizada regular, estas transacciones son creadas por una sola autoridad confiable. Por el contrario, en una base de datos compartida impulsada por blockchain, cualquiera de los usuarios de esa cadena de bloques puede crear transacciones. Y 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 de igual a igual, cada transacción debe preservar la cantidad total de fondos, de lo contrario, los participantes podrían darse libremente tanto dinero como quisieran.

Uno puede imaginar varias formas de expresar estas reglas, pero por ahora hay 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 términos de: (a) las entradas de la base de datos eliminadas por esa transacción, y (b) las entradas creadas. En un libro de contabilidad financiera, la regla establece que la cantidad total de fondos en las entradas eliminadas tiene que coincidir con el total en las creadas. (Consideramos que la modificación de una entrada existente es equivalente a eliminar esa entrada y crear una nueva en su lugar).

El segundo paradigma, que proviene de Ethereum, son los contratos inteligentes. Esto 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 pensar en esto como un forzado procedimiento almacenado.) Para modificar los datos de un contrato, los usuarios de blockchain envían solicitudes a su código, que determina si y cómo cumplir con esas solicitudes. Como en este ejemplo, el contrato inteligente para un libro de contabilidad financiera realiza las mismas tres tareas que el administrador de una base de datos centralizada: verificar fondos suficientes, deducir de una cuenta y agregar a otra.

Ambos paradigmas son efectivos y cada uno tiene sus ventajas y desventajas, como he dicho discutido en profundidad anteriormente. Para resumir, las restricciones de transacciones al estilo de Bitcoin proporcionan una concurrencia y un rendimiento superiores, mientras que los contratos inteligentes al estilo de Ethereum ofrecen una mayor flexibilidad. Entonces, para volver 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 transacción.

Dado este criterio para usar contratos inteligentes, todavía no veo un caso de uso sólido para blockchains autorizados que califique. Todas las aplicaciones convincentes de blockchain que conozco se pueden implementar con transacciones al estilo de Bitcoin, que pueden manejar los permisos y el almacenamiento general de datos, así como la creación, transferencia, custodia, intercambio y destrucción de activos. Sin embargo, todavía aparecen nuevos casos de uso, y no me sorprendería si algunos do requieren 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. Sin duda, esto es algo útil, y es esencial para hacer que esa base de datos sea segura para compartir. Pero los contratos inteligentes no pueden hacer otra cosa, y ciertamente no pueden escapar de los límites de la base de datos en la que residen.

Por favor publique cualquier comentario en LinkedIn.