Contratos inteligentes: lo bueno, lo malo y lo flojo

Marca de tiempo: 1 de noviembre de 2015 8:59 p.m.

Por qué las cadenas de bloques privadas no deberían estar ansiosas por ejecutar código

No soy un fanático del término "contratos inteligentes". Para empezar, ha sido utilizado por tanta gente para tantas cosas diferentes, que probablemente deberíamos prohibirlo por completo. Por ejemplo, la primera referencia conocida es de 1997, cuando Nick Szabo la usó para describir objetos físicos que cambiar su comportamiento basado en algunos datos. Más recientemente, el término se ha utilizado para exactamente lo contrario: para describir el cálculo en una cadena de bloques. que esta influenciado por eventos externos como el clima. Por ahora dejemos de lado estos dos significados.

Quiero centrarme aquí en los "contratos inteligentes" en el sentido de la computación de propósito general que tiene lugar en una cadena de bloques. Este significado fue popularizado por Ethereum, ¿De quién detalles de la moneda se subtitula “Un contrato inteligente de próxima generación y una plataforma de aplicaciones descentralizadas”. Como resultado de la atención que ha recibido Ethereum, este significado se ha convertido en el dominante, con los bancos (y otros) trabajando en pruebas de concepto de contratos inteligentes. Por supuesto, dado que estamos hablando de instituciones financieras reguladas, esto ocurre principalmente en el contexto de cadenas de bloques privadas o autorizadas, que tienen un conjunto limitado de participantes identificados. Por razones que son ahora bien entendido, las cadenas de bloques públicas, a pesar de su genialidad, aún no son adecuadas para fines empresariales.

Entonces, ¿es brillante el futuro para los contratos inteligentes en cadenas de bloques privadas? Bueno, algo así, pero no realmente. Ves, el problema es:

En las cadenas de bloques privadas, los contratos inteligentes combinan cuatro buenas ideas con una mala.

Entonces, ¿cuáles son las buenas ideas? (a) expresar la lógica empresarial como un programa de computadora, (b) representar los eventos que desencadenan esa lógica como mensajes para el programa, (c) usar firmas digitales para probar quién envió los mensajes, y (d) poner todo lo anterior en una cadena de bloques.

¿Y el malo? Ejecutando cada programa para cada mensaje en cada nodo de blockchain. En otras palabras, hacer que el ejecución de todos los programas, el trabajo de la cadena de bloques, en lugar de simplemente usarlo como STORAGE para los programas y mensajes. Y, sin embargo, esta ejecución global es la razón por la que se desarrolló Ethereum.

Si conoces el naturaleza determinista de la computación, saber sobre el problema de detencióny entender como dependencias de datos evitar la concurrencia, entonces es posible que ya esté convencido. Pero si no, prepárate un café, respira hondo y sígueme por la madriguera del conejo ...

Entendiendo Ethereum

Para comprender los contratos inteligentes al estilo de Ethereum, debemos comenzar con bitcoin, la primera cadena de bloques pública (y aún la más popular). La cadena de bloques de bitcoin se diseñó originalmente para una sola cosa: mover la moneda bitcoin de un propietario a otro. Pero una vez que estuvo en funcionamiento, la gente empezó a incorporar "metadatos" en las transacciones para otros fines, como recursos digitales y notarización de documentos. Mientras que algunos bitcoiners luchó estas aplicaciones, un mecanismo oficial para metadatos se introdujo en marzo de 2014, con el uso creciendo exponencialmente desde entonces.

Además de los proyectos basados ​​en la cadena de bloques de bitcoin, se desarrollaron y lanzaron muchas cadenas de bloques públicas de próxima generación, como NXT, Bitshares, Ripple y Stellar. Estos fueron diseñados desde cero para respaldar una gama más amplia de actividades, como activos creados por usuarios, intercambio descentralizado y préstamos garantizados. Cada una de estas cadenas de bloques tiene un conjunto diferente de características, según lo decidan sus desarrolladores, y todos sus usuarios deben actualizar cada una cuando se agrega una nueva característica. Las cosas empezaron a ponerse bastante complicadas.

Habiendo participado en algunos de estos proyectos, Vitalik Buterin planteó una pregunta simple pero brillante: en lugar de muchas cadenas de bloques específicas de la aplicación, ¿por qué no tener una sola cadena de bloques pública que se pueda programar para hacer lo que queramos? Esta super-blockchain sería infinitamente ampliable, limitada solo por la imaginación de quienes la usan. El mundo de los criptoentusiastas quedó casi unánimemente convencido por esta poderosa idea. Y así, con $ 18 millones en financiación colectiva y con gran entusiasmo, nació Ethereum.

Ethereum es una nueva cadena de bloques pública con una criptomoneda asociada llamada "ether", como centenares que vino antes. Pero a diferencia de otras cadenas de bloques, Ethereum permite a cualquiera crear un "contrato" dentro de la cadena de bloques. Un contrato es un programa de computadora con una base de datos en miniatura asociada, que solo puede ser modificado por el programa que lo posee. Si un usuario de blockchain desea cambiar una base de datos, debe enviar un mensaje firmado digitalmente a su contrato. El código del contrato examina este mensaje para decidir si reaccionar y cómo hacerlo. (Esta "encapsulación"De código y datos también es una base de orientado a objetos programación.)

Los contratos de Ethereum se pueden escribir en uno de varios lenguajes de programación nuevos, como Solidez y Serpiente. Como la mayoría de los lenguajes de programación, estos son Turing completo, lo que significa que pueden expresar cualquier cálculo de propósito general. Una característica clave de los lenguajes completos de Turing es la estructura de bucle, que realiza una operación repetidamente hasta que se cumple alguna condición. Por ejemplo, se puede usar un bucle para imprimir los números del uno al millón, sin requerir un millón de líneas de código. En aras de la eficiencia, los programas escritos para Ethereum son compilado (es decir, convertido) en más compacto bytecode antes de ser almacenado en la cadena. Los nodos de Ethereum luego ejecutan este bytecode dentro de un máquina virtual, que es esencialmente una computadora simulada que se ejecuta dentro de una real.

Cuando se crea un contrato de Ethereum en la cadena de bloques, configura el estado inicial de su base de datos. Luego se detiene, esperando cortésmente hasta que se le solicite. Cuando un usuario de la cadena de bloques (u otro contrato) le envía un mensaje en una transacción, el contrato entra en acción. Dependiendo del código que contenga, puede identificar la fuente del mensaje, activar otros contratos, modificar su base de datos y / o enviar una respuesta a la persona que llama. Todos estos pasos se realizan de forma independiente en cada nodo de la red, con idénticos resultados.

Para dar un ejemplo, un Ethereum simple contrato de sub-moneda mantiene una base de datos de los saldos de los usuarios para un activo en particular. Si recibe un mensaje para transferir fondos de Alice a Bob, (a) comprobará que el mensaje fue firmado por Alice, (b) comprobará que Alice tiene fondos suficientes, (c) transferirá fondos de Alice a la cuenta de Bob en la base de datos y (d) responda que la operación fue exitosa. Por supuesto, no necesitamos Ethereum para eso, porque una simple cadena de bloques de estilo bitcoin con soporte de activos nativos puede hacer lo mismo. Ethereum realmente se destaca por la lógica empresarial compleja de múltiples etapas, como el crowdfunding, los intercambios descentralizados y las estructuras de gobierno jerárquicas. O así, al menos, la promesa va.

Rompiendo con las

Ahora que sabemos cómo funcionan los contratos inteligentes de Ethereum, podemos dividirlos en cinco partes constituyentes:

  1. Expresando la lógica empresarial como programas informáticos.
  2. Representar los eventos que desencadenan esa lógica como mensajes a los programas.
  3. Uso de firmas digitales para demostrar quién envió los mensajes.
  4. Poner los programas, mensajes y firmas en una cadena de bloques.
  5. Ejecutando cada programa para cada mensaje en cada nodo.

Para repetir lo que dije al principio, creo que las partes 1 a 4 son muy buenas ideas. Comencemos con los dos primeros (que, por cierto, no son nuevos). A diferencia de los contratos legales que pueden tener diferencias de interpretación, los programas de computadora son inequívocos. Para cualquier programa dado en un lenguaje de programación bien definido, la misma entrada siempre conduce a la misma salida. Entonces, si alguna lógica comercial se expresa como un programa de computadora y los eventos se representan como mensajes para ese programa, entonces el resultado comercial es inamovible. De hecho, esta propiedad determinista de la computación hace aleatoriedad un problema delicado en la informática, e incluso los geeks de Google pueden hacerlo mal.

¿Qué pasa con las firmas digitales y las cadenas de bloques? Éstos evitan la necesidad de que una autoridad central determine qué mensajes se enviaron, en qué orden y por quién. En cambio, cada participante crea un par de claves privadas y públicasy distribuye su clave pública una vez a los demás participantes. Después de eso, ellos firmar cada mensaje con su clave privada antes de distribuir ese mensaje a través de la red. Los otros participantes pueden luego verificar la fuente del mensaje usando solo la clave pública del remitente. Es un material criptográfico inteligente. Finalmente, al colocar el programa y los mensajes firmados en una cadena de bloques, podemos asegurarnos de que cada participante tenga una visión idéntica de quién hizo qué y cuándo. Combinado con el cálculo determinista, esto significa los participantes no pueden estar en desacuerdo sobre el resultado comercial final.

Pero, ¿qué pasa con la última idea, de que cada nodo ejecute todos los programas para cada mensaje? Aquí llegamos a la parte contenciosa. Porque si bien puede ser bueno tener esta ejecución global, tampoco es necesaria. Debido a que el cálculo es determinista, no importa si un programa es ejecutado por un nodo, cada nodo o algún proceso externo. Tampoco importa si esto sucede en tiempo real, bajo demanda o 10 años después. El resultado del cálculo siempre será el mismo. Y si por alguna razón este no es el caso, esto solo puede deberse a una problema en el software o la red de blockchain.

El problema con la computación

Si no importa dónde se realiza el cálculo, ¿por qué? no hacerlo en todas partes? Bueno, resulta que los programas de computadora son impredecibles. Por muy inocentes que parezcan, pueden tardar mucho en correr. Y, a veces, siguen corriendo para siempre. Considere el siguiente ejemplo clásico (conocido como LCG):

  1. Set x a un número de un solo dígito de su elección
  2. Set y a 123 * x + 567
  3. Set x a los dos últimos dígitos de y, Es decir, y módulo 100
  4. If x Es mas que 2 luego vuelve al paso 2
  5. De lo contrario, deténgase y emita el valor de x

Bastante simple, ¿verdad? Así que aquí tienes una pregunta: ¿Terminará algún día este programa? ¿O se atascará en un Bucle infinito? ¿No tan seguro? Bueno, déjame sacarte de tu miseria: Depende del valor inicial de x.

If x is 0, 1, 2, 5, 6, 7 or 8, el programa se detiene bastante rápido. Pero si x is 3, 4 or 9, continúa indefinidamente. ¿No me crees? Abra Excel y pruébelo usted mismo (necesitará la función "MOD").

Si no puede predecir eso con solo mirar el código, no se sienta tan mal. Porque esto no solo es difícil para las personas, es imposible para las computadoras. El problema de determinar si un programa dado terminará de ejecutarse se llama problema de detención. En 1936, Alan Turing, de "Turing completo" y El Juego de imitación fama, demostró que no se puede resolver para el caso general. Salvo excepciones triviales, la única forma de saber si un programa terminará de ejecutarse es ejecutarlo durante el tiempo que sea necesario, y eso podría ser para siempre.

Para aquellos de nosotros que preferiríamos vivir sin pantallas azules de la muerte y pelotas de playa giratorias, todo es bastante inconveniente. Pero vivimos con él y, sorprendentemente, la mayoría del software funciona sin problemas la mayor parte del tiempo. Y si no, los sistemas operativos modernos como Windows nos protegen contra el código fuera de control permitiéndonos terminar los programas manualmente. Sin embargo, no se puede hacer lo mismo en una cadena de bloques como Ethereum. Si permitiéramos que los nodos individuales terminaran los cálculos a voluntad, diferentes nodos tendrían opiniones diferentes sobre el resultado de esos cálculos. En otras palabras, el el consenso de la red se rompería. Entonces, ¿qué puede hacer una cadena de bloques?

La respuesta de Ethereum se basa en tarifas de transacción, también conocidas como Natural. El remitente de cada transacción país por los cálculos que dispara, y este pago lo cobra el minero que lo confirma en un bloque. Para ser más precisos, cada transacción de Ethereum establece por adelantado cuánto del "éter" del remitente se puede gastar en procesarlo. La tarifa se gasta gradualmente a medida que se ejecuta el contrato, paso a paso, dentro de la máquina virtual Ethereum. Si una transacción se queda sin tarifas antes de que termine de ejecutarse, cualquier cambio en la base de datos se revierte y la tarifa no se devuelve. Si una transacción se completa con éxito, cualquier tarifa restante se devuelve al remitente. De esta manera, las transacciones solo pueden sobrecargar la red en la medida en que estén dispuestos a pagar por ellas. Sin duda, es una buena solución económica, pero Requiere una moneda blockchain nativa para funcionar..

Contratos inteligentes vs simultaneidad

Si el gas puede evitar un cálculo descontrolado, ¿los contratos inteligentes reciben luz verde? Bueno, no tan rápido, porque hay otro problema con los contratos inteligentes del que debemos hablar:

Los contratos inteligentes funcionan mal para un alto rendimiento de transacciones.

Concurrencia es uno de los temas más fundamentales en la arquitectura de computadoras. Un sistema tiene buena concurrencia si permite que sucedan varios procesos simultáneamente y en cualquier orden. Los sistemas concurrentes reducen los retrasos y permiten un rendimiento general mucho mayor, haciendo un uso óptimo de tecnologías como programación de procesos, procesamiento paralelo y particionamiento de datos. Así es como busca Google 30 billones páginas web casi 100,000 equipos por segundo.

En cualquier sistema informático, un conjunto de transacciones solo se puede procesar simultáneamente si no dependen o interfieren entre sí. De lo contrario, diferentes órdenes de procesamiento pueden dar lugar a resultados completamente diferentes. Ahora recuerde que un contrato inteligente tiene una base de datos asociada y que realiza cálculos de uso general, incluidos los bucles. Esto significa que, en respuesta a un mensaje en particular, un contrato inteligente podría leer o escribir cada pieza de información en su base de datos. Por ejemplo, si está administrando una sub-moneda, podría decidir pagar algún interés a cada tenedor de esa moneda. Por supuesto, este no siempre será el caso. Pero el problema es: antes de ejecutar el programa del contrato para un mensaje en particular, un nodo blockchain no puede predecir qué subconjunto de la base de datos del contrato va a utilizar. Tampoco puede decir si este subconjunto podría haber sido diferente en diferentes circunstancias. Y si un contrato puede desencadenar cualquier otro, este problema se extiende al todo el contenido de cada base de datos de cada contrato. Por lo tanto, cada transacción debe tratarse como si pudiera interferir con las demás. En términos de base de datos, cada transacción requiere un bloqueo global.

Ahora piense en el mundo en el que vive un nodo de blockchain. Las transacciones provienen de diferentes pares, sin ningún orden en particular, ya que no hay una cola administrada de forma centralizada. Además, a intervalos promedio de entre 12 segundos (Ethereum) y 10 minutos (bitcoin), entra un nuevo bloque que confirma un conjunto de transacciones en un orden específico. Es probable que un nodo ya haya visto la mayoría de las transacciones de un bloque, pero algunas pueden ser nuevas. De cualquier manera, es poco probable que el orden de las transacciones en el bloque refleje el orden en el que llegaron individualmente. Y dado que el orden de las transacciones puede afectar el resultado, esto significa las transacciones no se pueden procesar hasta que se confirme su pedido en la cadena de bloques.

Ahora bien, es cierto que una transacción de bitcoin no confirmada podría necesitar revertirse debido a una doble gasto. Pero una transacción Ethereum no confirmada no tiene ningún resultado predecible. De hecho, las implementaciones actuales de Ethereum ni siquiera procesan transacciones no autorizadas. Pero si un nodo Ethereum fue para procesar las transacciones de inmediato, aún sería necesario rebobinarlas y reproducirlas en el orden correcto cuando ingrese un bloque. Este reprocesamiento es una gran pérdida de esfuerzo y evita que los procesos externos concurrentemente leyendo la base de datos de Ethereum mientras continúa. (Para ser justos, debe tenerse en cuenta que bitcoin Implementación de referencia también rebobina y reproduce transacciones cuando entra un bloque, pero esto se debe solo a una falta de optimización).

Entonces, ¿qué tiene el modelo de transacciones de bitcoin que hace posible la ejecución fuera de orden? En bitcoin, cada transacción estados explícitamente su relación con otras transacciones. Tiene un conjunto de entradas y salidas, en el que cada entrada está conectada a la salida de una transacción anterior que “gasta”. No hay otras dependencias de las que preocuparse. Siempre que (a) dos transacciones de bitcoin no intenten gastar la misma salida, y (b) la salida de una no conduce a la entrada de otra, un nodo de bitcoin puede estar seguro de que las transacciones son independientes y puede procesarlos en cualquier orden. Sus posiciones finales en la cadena de bloques no importan en absoluto.

Para utilizar terminología informática formal, las transacciones de Ethereum deben estrictamente totalmente ordenado, lo que significa que se debe definir el orden relativo entre cada par de transacciones. Por el contrario, las transacciones de bitcoin forman una Gráfico Acíclico Dirigido que es solo parcialmente ordenado, lo que significa que se permite cierta ambigüedad en el orden de las transacciones. Cuando se trata de simultaneidad, esto marca la diferencia en el mundo.

Para verlo en términos prácticos, se ha hablado mucho sobre las cadenas de bloques privadas en la empresa. Pero una cadena de bloques privada es solo una base de datos distribuida con algunas características adicionales. Y si intentó vender una base de datos de clase empresarial hoy que no admite concurrencia, te reirían fuera de la habitación. Igualmente ridícula sería la sugerencia de que un nodo individual tiene que esperar 12 segundos antes de ver el resultado de sus propias transacciones. Como el propio Vitalik recientemente tuiteó:

Para nosotros en Coin Sciences, esto no es solo una cuestión académica, porque tenemos que decidir si incorporar contratos inteligentes en MultiChain. Curiosamente, a pesar de los cientos de solicitudes de funciones y frecuentes que hemos recibido hasta ahora, solo dos se han relacionado con contratos inteligentes, e incluso entonces en una forma más débil que la que proporciona Ethereum. Entonces, aunque mantenemos la mente abierta, puede resultar que los contratos inteligentes no resuelvan ningún problema real para nuestros usuarios.

A favor de Ethereum

Si solo está interesado en un lado del argumento, puede dejar de leer aquí. Pero quizás se esté preguntando: ¿Son estúpidos los creadores de Ethereum? ¿Por qué demonios requerirían la ejecución global en una base de datos distribuida pública, si cada nodo pudiera simplemente elegir qué programas le importaba ejecutar? ¿Existen buenas razones para el método Ethereum?

En realidad, si estamos hablando de blockchains públicas, creo que las hay. Pero para comprender estas razones, debemos pensar en la dinámica de la propia red Ethereum.

Previniendo el spam de transacciones

Una cadena de bloques se mantiene mediante una red de igual a igual, en la que cada nodo está conectado a un subconjunto aleatorio de los otros nodos. Cuando se crea una nueva transacción en un nodo, se propaga rápida y aleatoriamente a los demás a través de un proceso llamado "retransmisión". En una red pública abierta, cualquiera puede crear transacciones, por lo que necesitamos una forma de protegernos contra spam de transacciones lo que podría abrumar al sistema. Dado que la red está descentralizada, esto solo se puede lograr si los nodos individuales evalúan las nuevas transacciones a medida que ingresan y deciden si las retransmiten o no. Si bien este mecanismo no puede evitar que un spammer abrumador un nodo individual, protege la red en su conjunto.

En una red pública, cuando un nodo decide si retransmitirá una nueva transacción, un criterio clave es la relación entre su tarifa y su costo para la red. En el caso de bitcoin, este costo se basa principalmente en el tamaño bruto de la transacción en bytes. En Ethereum, un fórmula más compleja se utiliza, en función del esfuerzo computacional que consumirá la transacción. De cualquier manera, las tarifas actúan como un mecanismo basado en el mercado para prevenir el spam de transacciones.

Pero, ¿cómo sabe un nodo si el remitente tiene fondos suficientes para cubrir la tarifa que ofrece? En el caso de Ethereum, el saldo de "ether" de cada usuario se ve afectado por el resultado de transacciones anteriores, ya que los contratos pueden gastar y pagar éter. Entonces, sin ejecutar todos los programas para todos los mensajes anteriores, un nodo Ethereum no tiene forma de conocer el saldo actualizado de un usuario. Por lo tanto, no puede evaluar si una transacción debe transmitirse a otros nodos. Y sin eso, una red abierta podría destruirse trivialmente.

Pruebas de datos compactas

En una cadena de bloques, los bloques se llenan principalmente con las transacciones que confirman. Sin embargo, cada bloque también tiene un "encabezado" compacto, que contiene información importante, como una marca de tiempo y un enlace al bloque anterior. Para blockchains públicas basadas en prueba de trabajo hash, la entrada para el algoritmo hash es este encabezado de bloque solo. Esto significa que la autoridad de una cadena puede ser evaluada por un "cliente ligero" sin descargar la mayor parte de su contenido. Por ejemplo, en noviembre de 2015, el conjunto completo de encabezados de bitcoin tiene un tamaño de 30 MB, en comparación con 45 GB para la cadena completa. Esa es una proporción de 1500: 1, lo que marca una diferencia crucial con respecto a los dispositivos móviles con ancho de banda y almacenamiento limitados.

El encabezado de cada bloque de Ethereum contiene una "raíz de estado", que registra el estado de la cadena después de procesar las transacciones en ese bloque. Entre otras cosas, este estado cubre el contenido de la base de datos de cada contrato, con la huella digital calculada de manera eficiente utilizando un árbol de funciones hash unidireccionales. El más mínimo cambio en la base de datos de cualquier contrato conduciría a una raíz de estado completamente diferente, por lo que la raíz "ata" el contenido de la base de datos. (Una noción equivalente de "compromisos UTXO" para bitcoin ha sido discutido pero aún no implementado.)

El método en forma de árbol para calcular las raíces estatales tiene una propiedad importante: Dada una raíz de estado conocida, el valor de una entrada particular en una base de datos de contratos se puede probar de manera eficiente. El tamaño de esta prueba es proporcional a la profundidad de un árbol binario cuyas hojas son las entradas individuales de la base de datos, es decir, el registro2 el tamaño total de la base de datos. Eso significa que, para una entrada individual, la prueba solo dobles de longitud cuando el tamaño de la base de datos es al cuadrado - el tipo de escalabilidad por la que los científicos informáticos matan. Ahora recuerde que la raíz del estado de cada bloque está en su encabezado, que un cliente ligero puede verificar. Como resultado, los clientes ligeros pueden consultar de forma segura y eficiente cualquier nodo completo de la red para obtener entradas de base de datos individuales, y los nodos completos no pueden mentir.

Pero si nuestros encabezados de blockchain incluyen una raíz de estado, y la raíz de estado depende del contenido de la base de datos, entonces cada nodo debe mantener actualizada la base de datos de la cadena de bloques. A su vez, esto significa ejecutar cada contrato para cada mensaje que ha recibido hasta ahora. Sin esto, un nodo de minería no sabría la raíz del estado para colocar en un encabezado de bloque, ni otros nodos podrían verificar los bloques que reciben. La conclusión es: si queremos que los clientes ligeros recuperen de forma segura pruebas de datos compactos de la red, los nodos completos deben realizar todos los cálculos descritos por los datos en la cadena.

El veredicto de las blockchains privadas

Repasemos estos dos argumentos en el contexto de las cadenas de bloques privadas. Lo primero que hay que tener en cuenta sobre las cadenas privadas es que tienden a no tener un token nativo o una criptomoneda. Esto se debe a varias razones:

  • El tipo de entidades interesadas en cadenas privadas no quieren lidiar con una nueva clase de activos.
  • El modelo de consenso para cadenas privadas se basa en un acuerdo entre un conjunto de mineros cerrados, en lugar de una prueba de trabajo. Entonces, el costo de la minería es mínimo y los mineros no necesitan mucha recompensa.
  • Dado que todos los participantes de una cadena privada son examinados, existe menos preocupación por el spam y el abuso.

Recuerde que el primer argumento para la ejecución global fue permitir que cada nodo de Ethereum decida si retransmitir una transacción entrante, en función de la tarifa que ofrece. Bueno, la falta de un token nativo hace que esta razón sea irrelevante porque, si una cadena de bloques no tiene un token nativo, las transacciones no pueden pagar tarifas. Si por alguna razón el spam sigue siendo un problema, debe controlarse de otra manera, por ejemplo, revocando los permisos del remitente.

Ahora consideremos el segundo argumento, para permitir pruebas de datos compactas. Es probable que una cadena de bloques pública tenga usuarios finales en dispositivos móviles u otras billeteras livianas. Pero esto es menos probable con las cadenas privadas, cuya función principal es compartiendo una base de datos entre empresas más grandes. Y si el blockchain is al que se accede desde un dispositivo móvil, es probable que el usuario móvil sea un cliente de una de estas empresas y pueda confiar en lo que esa empresa les dice.

En cambio, en blockchains privados, el problemas de ejecución global son especialmente agudos. Si una cadena de bloques privada no tiene un token nativo, no tenemos un mecanismo de mercado similar al gas para prevenir el código fuera de control. En su lugar, necesitaríamos introducir algún tipo de límite fijo en términos de pasos computacionales por transacción. Pero para permitir que las transacciones realicen una gran cantidad de procesamiento intencionalmente, este límite debería ser alto. Como resultado, la red aún podría terminar desperdiciando mucha energía en bucles no deseados antes de finalmente apagarlos.

En cuanto a la concurrencia, es mucho más probable que las cadenas de bloques privadas vean el tipo de volúmenes de transacciones que hacen que la concurrencia sea esencial. La capacidad de las cadenas de bloques públicas está limitada por el hecho de que, para descentralizarse de manera significativa, necesitan miles de nodos administrados por entusiastas con presupuestos limitados. Por el contrario, es mucho más probable que las cadenas privadas conecten solo unas pocas docenas de empresas, en cuyo caso la capacidad y la velocidad son esenciales.

Blockchains de dos pisos

Entonces, si todo lo relacionado con los contratos inteligentes tiene sentido en las cadenas privadas, además de la ejecución global, ¿dónde nos deja esto? ¿Qué tipo de blockchain nos dará el rendimiento y la flexibilidad que necesitamos? Para ser honesto, todavía lo estoy pensando. Pero una respuesta podría ser: una cadena de bloques con dos niveles.

El nivel inferior se basaría en transacciones de estilo bitcoin que se procesan de forma instantánea y simultánea, y no es necesario esperar a las confirmaciones de bloque. Estas transacciones podrían realizar movimientos simples de activos, incluidos seguros intercambios atómicos, sin recurrir a contratos inteligentes. Pero este nivel inferior también se utilizaría como capa de almacenamiento ciego para los programas y mensajes que representan procesos comerciales más complejos, incrustados como metadatos de transacciones.

En cuanto al nivel superior, cada participante de la red elegiría qué programas quieren ejecutar. Algunos pueden optar por no ejecutar ninguno, porque solo están interesados ​​en movimientos simples de activos. Otros pueden ejecutar un pequeño grupo de programas que son relevantes para sus procesos internos (sabiendo que este grupo no intercambia mensajes con programas externos). Algunos incluso podrían optar por la ejecución global, procesando cada mensaje para cada programa, al igual que Ethereum. Pero la clave sería que cada nodo ejecuta solo el código que necesita. En informática, esta técnica se llama evaluación perezosa, porque implica hacer el menor trabajo posible, sin omitir nada crucial. Con la evaluación perezosa, si un cálculo de blockchain sale mal, solo los nodos que realmente ejecutan ese programa lo notarán. La red en sí no sentirá nada.

En cuanto a MultiChain, si terminamos apoyando el cálculo completo de Turing, dudo que implementemos la ejecución global. Quizás optemos por este tipo de enfoque perezoso de dos niveles, o quizás pensamos en algo mejor.

Contratos inteligentes en blockchains públicas

Como dije antes, en público Turing cadenas de bloques completas como Ethereum, hay en buenas razones para la ejecución global. Pero aquí hay otra pregunta: ¿cuál es el empresa caso de uso de estas cadenas? Imaginemos algún tiempo futuro en el que las empresas tengan suficiente confianza en las cadenas de bloques públicas para usarlas en procesos comerciales reales. Si un grupo de empresas desea incrustar alguna lógica computacional en una cadena de bloques pública, tiene dos opciones: (1) usar una cadena de bloques de estilo Ethereum con ejecución global, o (2) usar cualquier blockchain como una simple capa de almacenamiento y ejecutando el código ellos mismos. Y dadas estas opciones, ¿Por qué elegirían (1)?

La elección racional sería la cadena de bloques pública con (a) el precio más barato por byte de almacenamiento y / o (b) el nivel más alto de seguridad basado en la potencia minera total. Dado que el cálculo es determinista, las empresas solo necesitan pagar a la red para tienda su contrato y mensajes, no para realmente ellos. Además, al usar una cadena de bloques solo para almacenamiento, pueden usar cualquier lenguaje de programación que quieran. Este podría ser el código de bytes de Ethereum, JavaScript / ECMAScript para legibilidad o incluso codigo de maquina para un alto rendimiento. De hecho, Ethereum contrata ya se puede almacenar utilizando metadatos en la cadena de bloques de bitcoin. Este es exactamente el enfoque de dos niveles que sugerí.

Esta discusión está relacionada con la noción de capas de abstracción, hecho famoso por el Modelo de red OSI. Para una confiabilidad y flexibilidad óptimas, cada capa de un sistema debe estar tan abstraída (es decir, independiente) de las otras capas como sea posible. Por ejemplo, no queremos que nuestros controladores de disco duro contengan código para renderizar imágenes JPEG. Entonces, ¿por qué querríamos que una cadena de bloques ejecute los programas que almacena? Para la mayoría de los casos de uso, no obtenemos ningún beneficio de esto y tiene un costo significativo.

Epílogo

Si la ejecución global no tiene sentido en las cadenas de bloques privadas, ¿por qué todos están trabajando en esto? Creo que esto se puede explicar, al menos en parte, por un malentendido sobre lo que pueden hacer las cadenas de bloques. en el mundo real. Verá, las cadenas de bloques públicas como bitcoin pueden mover directamente un activo real (es decir, su moneda nativa), porque la cadena de bloques define la propiedad de esa moneda. Esto combina dos aspectos de los activos que suelen ser distintos: (a) un libro mayor que registra quién es el propietario del activo y (b) su ubicación física real. Esto hace que las criptomonedas sean lo último instrumento portador, creando un mundo feliz o un paraíso para los lavadores de dinero, dependiendo de a quién le preguntes.

Pero para otros activos que existen independientemente de una cadena de bloques, lo único que puede hacer una cadena es mantener un grabar de quienes ellos tienes pertenece a. Este seguirá siendo el caso hasta que veamos el emisión primaria de activos en una cadena de bloques, con la propiedad legal de ese activo definido en términos de la base de datos de la cadena. Para el sector de las finanzas institucionales, creo que este día aún está muy lejos, sobre todo por los cambios regulatorios requeridos. Hasta entonces, siempre habrá un paso extra, contractual y procesal, entre lo que dice la cadena de bloques y lo que sucede en el mundo real. Este paso también podría incluir algo de código completo de Turing, ejecutado con pereza en el último momento posible.

Este problema se destaca en el caso de los “bonos inteligentes” del que tanto hemos escuchado. Un bono inteligente se emite directamente en una cadena de bloques, y la cadena de bloques garantiza que los pagos de cupones se realicen a los tenedores de bonos en los momentos adecuados. Todo muy bien. Pero, ¿qué sucede si el emisor de bonos no tiene fondos suficientes en su cuenta de blockchain para cubrir un pago vencido? La cadena de bloques ciertamente puede establecer una bandera para decir que algo anda mal, pero no puede hacer nada mas. Todavía necesitamos un ejército de abogados y contadores para arreglar todo el lío, ya sea mediante un corte de pelo, una reestructuración de la deuda, una confiscación o una quiebra total. En breve:

Si los contratos inteligentes no pueden cumplir su promesa, ¿por qué estamos pagando su precio?

Gracias por leer.

Sello de tiempo:

Mas de Multicain