Uno de los propósitos de los contratos inteligentes es la automatización de las transacciones de pago entre contrapartes. Nuestro servicio de pago
wirech blockchain
también funciona en este mercado. A pesar de la promesa de contratos inteligentes, el autor del material analiza las deficiencias de esta tecnología.
Como desarrollador de la popular plataforma blockchain, a veces me preguntan si hay un lugar para los contratos inteligentes en los planes de desarrollo de nuestro servicio Multichain, similar a los utilizados en Ethereum. La respuesta siempre suena: "No, o al menos no ahora".
Pero en el ruidoso mundo de las blockchains, los contratos inteligentes
se consideran algo muy bueno. ¿Por qué siempre no hay respuesta? Bueno, el problema es que si en el caso de bitcoin controlado como bitcoin conocemos al menos tres escenarios poderosos de su aplicación práctica (seguimiento del historial de origen, almacenamiento de documentos de la empresa, facilitación de la organización de sistemas financieros), entonces para
contratos inteligentes etéreos equivalentes en eficiencia los casos simplemente no existen.
No es que las personas no entiendan lo que quieren de los contratos inteligentes. El problema es más bien que muchas de estas ideas simplemente no son factibles. Cuando las personas inteligentes escuchan el término contratos inteligentes, tienden a dar rienda suelta a su imaginación. Dibuje en la cabeza imágenes de software inteligente independiente, montando una ola de datos y conectándose para resolver problemas del mundo real. Desafortunadamente, la imagen real de cómo funcionan los contratos inteligentes es mucho más prosaica.
Un contrato inteligente es una pieza de código almacenada en la cadena de bloques. Está alimentado por transacciones de blockchain y lee de blockchain o escribe datos en él. Eso es todo Ni más ni menos.
Un contrato inteligente es solo un nombre sonoro para un código que funciona en la cadena de bloques e interactúa con su estado. ¿Qué es este código? Esto es Pascal, Python o PHP. O tal vez Java, Fortran o C ++. Si piensa en el formato de la base de datos, puede representarse en forma de procedimientos escritos en alguna extensión de SQL.
Básicamente, todos estos lenguajes son equivalentes; resuelven los mismos tipos de problemas utilizando los mismos métodos para resolverlos. Por supuesto, cada uno de ellos tiene fortalezas y debilidades. Sería una locura tratar de crear un sitio web en C o comprimir video HD en Ruby. Pero al menos teóricamente podrías hacer esto si quisieras. Simplemente tendría que pagar un alto precio en términos de conveniencia, rendimiento, y es muy probable que pierda mucho cabello en la cabeza.
El problema de los contratos inteligentes radica no solo en expectativas excesivamente altas, sino también en el hecho de que estas expectativas conducen al hecho de que un número considerable de personas gastan tiempo y dinero en ideas que es poco probable que se realicen en la práctica.
La práctica muestra que, por regla general, las grandes empresas tienen suficientes recursos para recorrer un largo camino desde el momento en que la alta gerencia aprende sobre una nueva tecnología hasta el momento en que sus ventajas y limitaciones se entienden realmente.
Durante los últimos nueve meses, hemos escuchado muchos argumentos sobre los posibles escenarios para el uso de contratos inteligentes, y sucedió que respondimos a sus autores una y otra vez que estas ideas simplemente no podían realizarse en la vida real.
Como resultado, identificamos los tres conceptos erróneos más comunes sobre el tema de los contratos inteligentes. Estas ideas no son ciertas no porque la tecnología aún no esté lo suficientemente madura o no porque todavía no tenemos ninguna herramienta.
En cambio, se basan en un malentendido de las propiedades fundamentales del código que vive en una base de datos y se procesa de manera descentralizada.
1. Interacción con servicios externos.
A menudo puede escuchar la oferta de usar contratos inteligentes que cambian su comportamiento en respuesta a algún evento externo. Por ejemplo, una póliza de seguro agrícola que realiza pagos en función de la cantidad de lluvia que ha ocurrido en un mes determinado.
Según la idea de los autores de la idea, el proceso se lleva a cabo aproximadamente de la siguiente manera: un contrato inteligente espera un cierto tiempo predeterminado, recibe un informe meteorológico de un servicio externo y se comporta de acuerdo con los datos recibidos.
Eso suena bastante simple. Simple e imposible al mismo tiempo. Por qué Debido a que blockchain es un sistema basado en el consenso, lo que significa que funcionará solo si cada nodo de red alcanza el mismo estado después de procesar cada transacción y cada bloque.
Todas las operaciones que tienen lugar en la cadena de bloques deben estar completamente determinadas, sin la más mínima probabilidad de que alguna diferencia se infiltre en su trabajo. Tan pronto como dos nodos honestos toman posiciones diferentes en el estado de la cadena, todo el sistema se vuelve inútil.
Y ahora permítanme recordarles que cada nodo de la cadena ejecuta contratos inteligentes de forma independiente. Esto significa que si un contrato inteligente recibe información de una fuente externa, cada nodo repite el procedimiento para obtener datos de forma independiente. Pero dado que la fuente está fuera de la cadena de bloques, no hay garantía de que cada nodo reciba la misma respuesta.
Quizás la fuente cambie su respuesta en algún momento entre las solicitudes de dos nodos diferentes, o puede dejar de estar disponible temporalmente. De una forma u otra, no se alcanzará un consenso y toda la cadena de bloques dejará de funcionar.
¿Qué salida de la situación se puede encontrar? Y la solución es realmente muy simple. Solo necesita reemplazar el proceso de contactar un contrato inteligente a una fuente externa con una o más partes confiables (los llamados oráculos) creando una transacción que escriba los datos necesarios en la cadena. Luego, cada nodo tendrá una copia idéntica de los datos, y se pueden usar en los cálculos del contrato inteligente.
En otras palabras, en lugar de un contrato inteligente que "extrae" datos del exterior, el oráculo ingresará estos mismos datos en la cadena de bloques.
Problemas similares surgen cuando se trata de contratos inteligentes que desencadenan ciertos eventos en el mundo exterior. Por ejemplo, a muchas personas les gusta la idea de contratos inteligentes que utilizan la API del banco para transferir dinero. Pero si cada nodo ejecuta el código de la cadena de forma independiente, ¿cuál de los nodos será responsable de llamar a la API?
Si se trata de un nodo cualquiera, entonces, ¿qué sucederá si este nodo en particular comienza a fallar deliberada o involuntariamente? Y si todos los nodos serán contactados, ¿podemos confiar en cada nodo con una contraseña API? ¿Y está justificado hacer cientos de llamadas en lugar de una? Y lo que es peor: si un contrato inteligente necesita determinar el éxito de una llamada API, nuevamente nos enfrentamos al problema de la dependencia de datos externos.
Y también hay una salida simple. En lugar de instruir a un contrato inteligente para acceder a una API externa, podemos usar un servicio confiable que monitorea el estado de la cadena de bloques y realiza ciertas acciones en respuesta a los datos recibidos. Por ejemplo, un banco podría monitorear proactivamente la cadena de bloques y realizar transferencias de dinero correspondientes a las transacciones aprobadas en la cadena. Este enfoque no crea ningún riesgo para llegar a un consenso, ya que la cadena en este modelo juega un papel absolutamente pasivo.
Habiendo considerado las soluciones propuestas para las situaciones descritas anteriormente, podemos sacar algunas conclusiones.
En primer lugar, ambos enfoques requieren un tercero de confianza para gestionar las interacciones entre blockchain y el mundo exterior. A pesar de la posibilidad teórica de implementar dicho modelo, cualquier descentralización dentro de su marco pierde todo significado.
En segundo lugar, los mecanismos utilizados en estos ejemplos son ejemplos directos de lectura y escritura en la base de datos. El oráculo que proporciona información externa simplemente lo escribe en la cadena. Un servicio que repite el estado de la cadena de bloques en el mundo real no hace más que leer de esta cadena. En otras palabras, cualquier interacción entre blockchain y el mundo exterior en este caso se reduce a las operaciones normales de la base de datos.
Con más detalle, revelaremos este hecho más adelante en el material.
2. Realizar pagos dentro de la cadena
Otra sugerencia que escuchamos con bastante frecuencia: el uso de contratos inteligentes para automatizar los pagos de cupones de los llamados bonos inteligentes. La esencia de la idea es inicializar automáticamente los pagos en el momento requerido por el contrato inteligente. Esto evitará el procesamiento manual del pago y asegura que el emisor no pueda incumplir.
Por supuesto, para que esta idea funcione, los fondos utilizados para pagar también deben estar dentro de la cadena de bloques. De lo contrario, un contrato inteligente simplemente no puede garantizar el pago.
Recordemos que blockchain es solo una base de datos. En nuestro caso, un registro financiero que contiene bonos emitidos y algo de caja. Por lo tanto, cuando hablamos de pagos de cupones, en realidad estamos hablando de operaciones de bases de datos realizadas automáticamente a la hora acordada.
Aunque dicha automatización es factible desde un punto de vista técnico, surgen dificultades con el aspecto financiero del modelo. Si los fondos utilizados para el pago de cupones están controlados por un contrato inteligente de bonos, entonces estos pagos realmente se pueden garantizar. Pero en este caso, el emisor de bonos no podrá usar estos fondos para ningún otro propósito. Y la retirada de fondos del control de un contrato inteligente anula cualquier garantía de pago.
En otras palabras, un bono inteligente no tiene sentido ni para el emisor ni para el inversor. Si reflexiona sobre esta situación, tal conclusión se vuelve completamente obvia.
Desde el punto de vista del inversor, la esencia de comprar bonos es la capacidad de obtener una ganancia atractiva, si existe algún riesgo aceptable de incumplimiento. Para el emisor, el punto de emitir bonos es recaudar fondos para una actividad productiva pero algo arriesgada, como, por ejemplo, construir una nueva fábrica.
No hay forma de que el emisor recaude fondos y, al mismo tiempo, garantice inequívocamente los pagos a los inversores. Creo que nadie se sorprenderá por el hecho de que la regularidad existente entre riesgo y rentabilidad no está incluida en la lista de tareas que pueden resolver las cadenas de bloques.
3. La necesidad de ocultar datos confidenciales
Como escribí anteriormente, el desafío más serio que enfrentamos al implementar blockchains es el grado extremo de transparencia que brindan.
Por ejemplo, si un grupo de 10 bancos quiere crear una cadena de bloques juntos, cualquier transacción bidireccional en esta cadena de bloques será inmediatamente visible para los otros ocho participantes. A pesar de la existencia de varias estrategias que permiten nivelar este efecto, ninguna de ellas puede superar la simplicidad y la eficacia de una base de datos centralizada administrada por una determinada persona que tiene control total sobre los niveles de visibilidad y acceso de todos los participantes.
Algunas personas creen que los contratos inteligentes pueden resolver este problema. Su razonamiento comienza con el hecho de que cada contrato inteligente contiene su propia base de datos en miniatura y la controla por completo. Todas las operaciones de lectura y escritura en esta base de datos están totalmente mediadas por el código del contrato, que excluye la situación en la que un contrato lee los datos de otro. (Esta estrecha relación entre datos y código se denomina encapsulación. Subraya los paradigmas populares de la programación orientada a objetos).
Por lo tanto, ningún contrato inteligente puede acceder a los datos de otros contactos inteligentes. ¿Pero esto resuelve el problema de privacidad dentro de la cadena de bloques? ¿Tiene sentido hablar sobre ocultar información dentro de un contrato inteligente? Lamentablemente, la respuesta es no.
Sí, un contrato inteligente no puede leer datos de otros contratos, sin embargo, estas copias de estos datos todavía se encuentran en cada nodo de red individual. Cada participante almacena estos datos en su memoria o en el disco duro del sistema, que está bajo su control total. Como resultado, nada impide que este participante lea información en su propio sistema si quiere hacerlo.
Los intentos de ocultar datos en un contrato inteligente son comparables en nivel de seguridad con un intento de ocultarlos en el código HTML de una página web. Por supuesto, los usuarios web normales no verán dicha información, ya que no se mostrará en la ventana del navegador. Pero para su divulgación, solo necesita hacer clic en el botón para mostrar el "código fuente", que se encuentra en todos los navegadores modernos y los datos se vuelven inmediatamente en la palma de su mano.
Del mismo modo, en el caso de los datos ocultos en un contrato inteligente, todo lo que se requiere es realizar cambios en el software para trabajar con blockchain para que muestre el estado completo del contrato y toda la apariencia de secreto desaparezca de inmediato.
Cualquier programador de clase media hará frente a esta tarea en no más de una hora.
¿Cuál es el propósito de los contratos inteligentes?
Después de todo lo anterior, surge una pregunta razonable: ¿dónde, en general, pueden encontrar aplicación los contratos inteligentes? Pero para responder a esta pregunta, necesitamos volver mentalmente a los conceptos básicos de blockchains. En resumen, blockchain permite que un grupo de personas que no confían entre sí trabajen directamente, de manera segura y directa con la base de datos sin la necesidad de recurrir a un determinado administrador principal para obtener ayuda.
Las cadenas de bloques le permiten abandonar la mediación al trabajar con datos, lo que puede conducir a una simplificación significativa y a reducir los costos.
Para realizar un cambio en cualquier base de datos, es necesario llevar a cabo una llamada transacción que contenga un conjunto de cambios en la base de datos que se aplicarán con éxito o se rechazarán todos juntos. Tomemos, por ejemplo, la situación con el registro financiero cuando Alice hace un pago a favor de Bob. El pago se presenta en forma de una transacción que: a) verifica si Alice tiene suficientes fondos en la cuenta, b) deduce la cantidad indicada de fondos de la cuenta de Alice yc) agrega la misma cantidad a la cuenta de Bob.
En una base de datos centralizada regular, estas transacciones son creadas por un solo administrador confiable. Por el contrario, en una base de datos pública de tipo blockchain, cualquier usuario de blockchain puede crear transacciones. Y dado que no existe una confianza absoluta entre estos usuarios, debe haber reglas en la base de datos que impongan una restricción en la ejecución de las transacciones.
Por ejemplo, en el registro financiero, todos los nodos de los cuales están en la misma posición, los parámetros de cada transacción no deben conducir a una violación del saldo general de fondos. De lo contrario, los participantes podrán asignar libremente tanto dinero como quieran.
Hay muchas maneras de cumplir con estas reglas, pero actualmente dominan dos paradigmas que prevalecen bajo la influencia de Bitcoin y Ethereum. El método Bitcoin, que se puede llamar una "restricción de transacción" de otra manera, evalúa cada transacción desde el punto de vista de: a) registros en la base de datos eliminados usando esta transacción yb) registros creados.
La regla se usa en el registro financiero: la cantidad total de fondos en los registros eliminados no debe entrar en conflicto con la cantidad total en los creados. (un cambio en un registro se considera como la eliminación de este registro y su recreación con los valores necesarios).
El segundo paradigma que se origina en Ethereum son los contratos inteligentes. Según él, todos los cambios en los datos del contrato deben realizarse por su código. (En el contexto de las bases de datos tradicionales, se puede considerar que este es un procedimiento almacenado obligatorio). Para cambiar los datos del contrato, los usuarios de blockchain envían solicitudes a su código que determina si cumplir con la solicitud y cómo hacerlo.
A la luz del ejemplo anterior, un contrato inteligente para el registro financiero realiza las mismas tareas que el administrador de una base de datos centralizada: verificar la disponibilidad de una cantidad suficiente de fondos, restarlos de una cuenta y agregarlos a otra.
Ambos paradigmas funcionan de manera eficiente, y cada uno de ellos tiene sus ventajas y desventajas. En resumen, limitar las transacciones de tipo bitcoin le permite lograr mejores indicadores de accesibilidad y rendimiento simultáneos, mientras que los contratos inteligentes de tipo ethereum permiten una mayor flexibilidad.
Por lo tanto, volviendo a la pregunta de para qué sirven los contratos inteligentes: son necesarios cuando no es posible implementar un caso de blockchain usando la restricción de transacción.
Pero incluso después de haber determinado este criterio para el uso de contratos inteligentes, todavía me resulta difícil nombrar al menos un escenario para su uso para cadenas de bloques cerradas, donde el enfoque tradicional de bitcoin realmente no sería aplicable.
Todos los proyectos de blockchain realmente interesantes que conozco pueden implementarse utilizando el enfoque de bitcoin, en cuyo marco es posible implementar tanto la separación de los derechos de acceso como el almacenamiento de datos, así como la creación de activos, su movimiento, depósito, intercambio y destrucción. Sea como fuere, los casos de nuevos usuarios aparecen regularmente y no me sorprenderá si algunos de ellos realmente requieren el poder de los contratos inteligentes. O al menos una extensión del paradigma de Bitcoin.
De una forma u otra, la regla clave en cualquier situación es recordar que los contratos inteligentes son solo uno de los métodos para limitar la ejecución de transacciones en la base de datos.
, , . - . , .
