Una mirada detallada a la blockchain que no es blockchain

A medida que pasa el tiempo, el mundo blockchain se ha estado separando en dos partes distintas. Por un lado, las cadenas de bloques públicas con sus criptomonedas asociadas han tenido un notable regreso reciente, acuñando a muchos multimillonarios. Por otro lado, el uso de blockchains autorizados o empresariales ha crecido de manera silenciosa pero constante, al ver su primer implementaciones en vivo en múltiples industrias durante 2017.

Una pregunta interesante a considerar es el nivel apropiado de similitud entre estos dos tipos de cadena. Ambos implementan una base de datos compartida utilizando redes de igual a igual, criptografía de clave pública-privada, reglas de transacción y mecanismos de consenso que pueden sobrevivir a los actores maliciosos. Esa es una gran cantidad de puntos en común. No obstante, las cadenas de bloques públicas y privadas tienen diferentes requisitos en términos de confidencialidad, escalabilidad y gobernanza. Quizás estas diferencias apuntan a la necesidad de diseños radicalmente divergentes.

La Cuerda plataforma, desarrollada por el R3 consorcio bancario, adopta una postura clara sobre esta cuestión. Si bien algunos aspectos se inspiraron en las cadenas de bloques públicas, Corda se diseñó desde cero en función de las necesidades de los miembros de R3. De hecho, aunque R3 todavía usa la palabra "blockchain" se dedica ampliamente para ayudar a comercializar su producto, Corda no tiene una cadena de bloques en absoluto. Más que cualquier otra plataforma de "libro mayor distribuido" que conozco, Corda se aleja radicalmente de la arquitectura de las cadenas de bloques convencionales.

Mi objetivo en este artículo es explicar estas diferencias y discutir sus implicaciones, para bien o para mal. En realidad, lo bueno y lo malo es la forma incorrecta de decirlo, porque la pregunta más interesante es "¿Bueno y malo para qué?" Este artículo está lejos de ser breve. Pero al final, espero que los lectores comprendan las diferencias en Corda y sus consecuentes compensaciones. Corda es importante porque sus decisiones de diseño ponen de relieve muchos de los dilemas de las cadenas de bloques empresariales.

Una última cosa antes de sumergirnos. Como CEO de la compañía detrás MultiChain, una popular plataforma de blockchain empresarial, ¿por qué estoy escribiendo con tanta profundidad sobre un producto supuestamente competitivo? La razón estándar sería argumentar a favor de la superioridad de MultiChain, pero esa no es mi motivación aquí. De hecho, no veo a Corda y MultiChain como competidores, porque son fundamentalmente diferentes en términos de diseño, arquitectura y audiencia. Corda y MultiChain compiten de la misma manera que los cruceros y las motos de agua, mientras que ambos transportan a las personas por mar, casi no hay situaciones del mundo real en las que ambos puedan usarse.

En una nota más personal, he aprendido mucho del liderazgo técnico de Corda en los últimos años, ya sea a través de reuniones, correspondencia o sus escritos públicos, muchos de los cuales ocurrieron antes de unirse a R3. Parte de mi interés en Corda proviene del respeto que tengo por este equipo, y solo por esta razón, vale la pena estudiar a Corda para cualquiera que busque una comprensión del campo del libro mayor distribuido.

Introduciendo blockchains

Para entender a Corda, es útil comenzar con blockchains convencionales. El propósito de una cadena de bloques es permitir que una base de datos o un libro mayor sean compartidos de manera directa y segura por personas que no son de confianza. Esto contrasta con las bases de datos centralizadas, que son almacenadas y controladas por una sola organización. Una cadena de bloques tiene múltiples "nodos", cada uno de los cuales almacena una copia de la base de datos y puede pertenecer a una organización diferente. Los nodos se conectan entre sí de una manera densa de igual a igual, utilizando un "protocolo de chismes" en el que cada nodo constantemente le dice a sus pares todo lo que aprende. Como resultado, cualquier nodo puede transmitir rápidamente un mensaje a toda la red a través de muchas rutas alternativas.

Una base de datos, ya sea centralizada o basada en blockchain, comienza en un estado vacío y se actualiza a través de "transacciones". Una transacción se define como un conjunto de cambios en la base de datos que son "atómicos", lo que significa que tienen éxito o fallan en su conjunto. Imagine una base de datos que representa un libro mayor financiero, con una fila por cuenta. Una transacción en la que Alice paga $ 10 a Bob tiene tres pasos: (1) verificar que la cuenta de Alice contenga al menos $ 10, (2) restar $ 10 de la cuenta de Alice y (3) agregar $ 10 a la cuenta de Bob. Como requisito básico, cualquier plataforma de base de datos debe garantizar que ninguna transacción interfiera con otra. Este "aislamiento" se logra bloqueando las filas tanto para Alice como para Bob mientras se realiza el pago. Cualquier otra transacción que involucre estas filas debe esperar hasta que esta finalice.

En una cadena de bloques, cada nodo procesa independientemente cada transacción en su propia copia de la base de datos. Las transacciones se crean en cualquier lugar de la red y se propagan automáticamente a todos los demás nodos. Dado que las organizaciones que ejecutan nodos pueden tener intereses diferentes (o incluso conflictivos), no pueden confiar entre sí para realizar transacciones equitativas. Las cadenas de bloques, por lo tanto, necesitan reglas que definan si una transacción en particular es válida o no. En un libro de contabilidad financiero compartido, estas reglas evitan que los usuarios gasten el dinero de los demás, o conjuren fondos de la nada.

Junto con las reglas que determinan la validez de la transacción, las cadenas de bloques también deben definir cómo se ordenarán las transacciones, ya que en muchos casos este orden es crítico. Si Alice tiene $ 15 e intenta enviar $ 10 a Bob y Charlie en dos transacciones separadas, solo uno de estos pagos puede tener éxito. Si bien nos gustaría decir que la primera transacción tiene prioridad, una red punto a punto no tiene una definición objetiva de "primero", ya que los mensajes pueden llegar a diferentes nodos en diferentes órdenes.

Reglas de transacción

En un sentido general, la información en cualquier base de datos se separa en registros o "filas", y una transacción puede hacer tres cosas diferentes: eliminar filas, crear filas y / o modificar filas. Estos se pueden reducir aún más a dos, ya que modificar una fila es equivalente a eliminar esa fila y crear una nueva en su lugar. Para volver al pago de Alice a Bob, se elimina su fila que contiene $ 15 y se crean dos filas nuevas: una que contiene $ 10 para Bob y la otra con $ 5 en "cambio" para Alice.

Siguiendo la terminología de bitcoin y Corda, denotamos las filas eliminadas por una transacción como sus "entradas", y aquellas creadas como sus "salidas". Cualquier fila eliminada por una transacción debe haber sido creada por una transacción anterior. Por lo tanto, cada entrada de transacción consume (o "gasta") la salida de una transacción anterior. El contenido actualizado de la base de datos está definido por el conjunto de "salidas de transacciones no gastadas" o "UTXO".

En una cadena de bloques, una transacción es válida si cumple las siguientes tres condiciones:

1. Exactitud. La transacción debe representar una transformación legítima de entradas a salidas. Por ejemplo, en un libro mayor financiero, la cantidad total de fondos en las entradas debe coincidir con el total en las salidas, para evitar que el dinero aparezca o desaparezca mágicamente. Las únicas excepciones son las transacciones especiales de "emisión" o "retiro", en las que los fondos se agregan o eliminan explícitamente.
2. Autorización. La transacción debe ser autorizada por el propietario de cada salida consumida por sus entradas. En un libro de contabilidad financiera, esto evita que los participantes gasten el dinero de los demás sin permiso. La autorización de transacción se gestiona mediante criptografía asimétrica (o clave pública-privada). Cada fila tiene un propietario, identificado por una clave pública, cuya clave privada correspondiente se mantiene en secreto. Para ser autorizado, una transacción debe ser firmada digitalmente por el propietario de cada una de sus entradas. (Tenga en cuenta que las filas también pueden tener propietarios de "firma múltiple" más complejos, por ejemplo, donde dos de cada tres partes pueden autorizar su uso).
3. Exclusividad. Si una transacción consume una salida particular, entonces ninguna otra transacción puede consumir esa salida nuevamente. Así es como evitamos que Alice haga pagos contradictorios tanto a Bob como a Charlie. Si bien las transacciones para ambos pagos podrían ser correctas y autorizadas, la regla de unicidad asegura que la base de datos procesará solo una.

En una cadena de bloques convencional, cada nodo verifica cada transacción en términos de estas tres reglas. Más adelante, veremos cómo Corda divide esta responsabilidad de manera diferente.

Bloques de construcción

Una cadena de bloques es, literalmente, una cadena de bloques, en la que cada bloque se vincula con el anterior a través de un "hash" que identifica de manera única su contenido. Cada bloque contiene un conjunto ordenado de transacciones que no deben entrar en conflicto entre sí o con los de los bloques anteriores, así como una marca de tiempo y alguna otra información. Al igual que las transacciones, los bloques se propagan rápidamente a través de la red y son verificados independientemente por cada nodo. Una vez que una transacción aparece en un bloque, se "confirma", lo que lleva a los nodos a rechazar cualquier transacción en conflicto.

¿Quién es responsable de crear estos bloques y cómo podemos estar seguros de que todos los nodos estarán de acuerdo en la cadena autorizada? Esta cuestión de "algoritmos de consenso" es un tema enorme en sí mismo, lleno de acrónimos maravillosos como PoW (Prueba de trabajo), PBFT (Tolerancia práctica a fallos bizantinos) y DPoS (Prueba de participación delegada). No vamos a entrar en todo eso aquí. Baste decir que las cadenas de bloques autorizadas para las empresas utilizan algún tipo de esquema de votación, donde los votos se otorgan a los "nodos validadores" que son colectivamente responsables. El esquema garantiza que, siempre que una buena mayoría de los nodos de validación funcionen de manera correcta y honesta, las transacciones ingresarán a la cadena en un orden (cercano) justo, las marcas de tiempo serán (aproximadamente) correctas y las transacciones confirmadas no podrán revertirse posteriormente.

Antes de discutir algunos de los desafíos de las cadenas de bloques, me gustaría aclarar tres puntos adicionales. Primero, mientras uso un libro de contabilidad financiera por ejemplo a lo largo de este artículo, el modelo de transacciones de entrada-salida admite una variedad mucho más amplia de casos de uso. Cada fila puede contener un objeto de datos enriquecido (piense en JSON) que contiene muchos tipos diferentes de información; de hecho, Corda usa la palabra "estado" en lugar de "fila" por este motivo. Los estados más ricos no cambian nada fundamental sobre las reglas de transacción: la corrección todavía se define en términos de entradas y salidas, la autorización aún se requiere para cada entrada y la unicidad asegura que cada salida solo se pueda gastar una vez.

En segundo lugar, hay muchos casos de uso de blockchain en los que las filas solo se crean en la base de datos y nunca se eliminan. Estas aplicaciones se relacionan con el almacenamiento general de datos, la marca de tiempo y la certificación notarial, en lugar de mantener algún tipo de libro mayor que está en constante cambio. En estas aplicaciones de solo datos, las transacciones agregan datos en sus resultados pero no consumen ninguno en sus entradas, lo que permite simplificar las reglas de corrección, autorización y unicidad. Aunque los casos de uso solo de datos son un foco creciente de nuestro propio desarrollo en MultiChain, solo los menciono de pasada aquí, ya que Corda claramente no fue diseñado teniendo en cuenta estos.

Finalmente, vale la pena señalar que algunas plataformas blockchain no usan un modelo de entrada-salida. Ethereum presenta un paradigma alternativo, en el que la cadena controla una computadora virtual con un estado global que es administrado por "contratos", y las transacciones no se conectan entre sí explícitamente. Una discusión sobre el modelo de Ethereum en blockchains autorizados está más allá de nuestro alcance aquí, pero vea este artículo para una explicación detallada y crítica. Una ventaja clave del paradigma de entrada-salida es que la mayoría de las transacciones pueden procesarse en paralelo e independientemente unas de otras. Esta propiedad es crucial para Corda, como veremos más adelante.

Desafíos de blockchain

Imaginemos que los bancos del mundo crearon un libro mayor compartido para representar la propiedad, transferencia e intercambio de una variedad de activos financieros. En teoría, esto podría implementarse en una cadena de bloques regular, como se describió anteriormente. Cada fila contendría tres columnas: un identificador de activo, como GOOG o USD, la cantidad que poseía y la clave pública del propietario. Cada transacción transferiría uno o más activos de sus entradas a sus salidas, con casos especiales de emisión y retiro.

Cada banco de la red ejecutaría uno o más nodos que se conectan a los demás, propagando y verificando transacciones. Los miembros superiores actuarían como validadores, con la responsabilidad colectiva de confirmar, ordenar y sellar las transacciones. El mal comportamiento de cualquier validador sería visible para todos los nodos de la red, lo que llevaría a la censura, el destierro y / o los procedimientos legales. Con todo esto en su lugar, cualquier activo financiero podría moverse en todo el mundo en segundos, con las reglas de corrección, autorización y unicidad que garanticen la integridad del libro mayor.

Qué está mal con esta imagen? En realidad, hay tres problemas: escalabilidad, confidencialidad e interoperabilidad. La cuestión de la escalabilidad es bastante simple. Nuestra cadena de bloques interbancaria propuesta requeriría que cada miembro verifique, procese y almacene cada transacción realizada por cada banco en el mundo. Incluso si esto fuera técnicamente factible para las instituciones financieras más grandes, el costo de cómputo y almacenamiento crearía una barrera significativa para muchos. Seguramente preferiríamos un sistema en el que los participantes solo vean aquellas transacciones en las que están involucrados de inmediato.

Pero dejemos de lado la escalabilidad, ya que en última instancia se puede resolver usando computadoras costosas e ingeniería inteligente. Una cuestión más fundamental es la confidencialidad. Si bien puede parecer utópico que todas las transacciones sean visibles en todas partes, en el mundo real, una transparencia tan radical no es un comienzo en términos de competencia y regulación. Si JP Morgan y HSBC intercambian un par de activos, es poco probable que quieran que Citi y el Banco de China vean lo que hicieron. Si la transacción se realizó en nombre de los clientes de estos bancos, podría ser ilegal que la expongan de esta manera.

Una solución propuesta al problema de la confidencialidad son los "canales", tal como se implementan en Hyperledger Fabric. Cada canal tiene ciertos miembros, que son un subconjunto de los nodos en la red como un todo. Las transacciones de un canal son visibles solo para sus miembros, de modo que cada canal actúa efectivamente como una cadena de bloques separada. Si bien esto ayuda con la confidencialidad, también socava todo el punto del ejercicio. Los activos no se pueden mover de un canal a otro sin la ayuda de un intermediario confiable que esté activo en ambos. La dificultad de este enfoque fue destacada recientemente por SWIFT prueba de concepto de reconciliación, que estimó que se necesitarían más de 100,000 canales en producción. Son 100,000 islas entre las cuales los activos no se pueden mover directamente.

En los casos de uso de solo datos, donde las transacciones no consumen datos en las entradas, el problema de confidencialidad se puede eludir cifrando o cifrando los datos en las salidas, y entregando la clave de descifrado o los datos no compartidos fuera de la cadena. Pero para una transacción cuyas entradas consumen las salidas de otras transacciones, cada nodo tiene que ver esas entradas y salidas para validar la transacción. Mientras que las técnicas criptográficas avanzadas como activos confidenciales y cero pruebas de conocimiento Si se han desarrollado para resolver parcial o completamente este problema para los libros de contabilidad financieros, estos imponen una carga de rendimiento significativa y / o no pueden generalizarse a ninguna regla de corrección.

Finalmente, hablemos de interoperabilidad. En un mundo ideal, cada banco se uniría de inmediato a nuestra cadena de bloques global el día de su lanzamiento. Sin embargo, en realidad, los diferentes grupos de bancos adoptarían múltiples blockchains, en función de la geografía o las relaciones preexistentes. Con el tiempo, un miembro de un grupo puede desear comenzar a realizar transacciones con un miembro de otro, transfiriendo un activo entre cadenas. Al igual que con los canales, esto solo se puede lograr con la ayuda de un intermediario de confianza, que anula el propósito de la cadena de bloques.

Corda tiene como objetivo resolver estos problemas interrelacionados de escalabilidad, confidencialidad e interoperabilidad a través de un replanteamiento radical de cómo funcionan los libros distribuidos.

Vista parcial de Corda

La diferencia fundamental en Corda es fácil de explicar: cada nodo solo ve algunas, en lugar de todas, las transacciones procesadas en la red. Si bien todas estas transacciones definen un único libro de contabilidad lógico y conceptual, ningún nodo individual ve ese libro de contabilidad en su totalidad. Para hacer una comparación, en cualquier momento, cada billete de un dólar en el mundo está en un lugar particular, pero nadie sabe dónde están todos.

Entonces, ¿qué transacciones ve un nodo Corda? En primer lugar, aquellos en los que está directamente involucrado, porque posee una de las entradas o salidas de esa transacción. En un libro de contabilidad financiera, esto incluye todas las transacciones en las que un nodo envía o recibe fondos. Digamos que Alice crea una transacción que consume sus $ 15 en una entrada y tiene dos salidas: una con $ 10 para mí y la otra con $ 5 en "cambio" para ella. Después de que Alice me envía esta transacción, puedo verificar que sea correcta y autorizada, verificando que las entradas y salidas se equilibren y que Alice haya firmado.

Sin embargo, esta transacción por sí sola no es suficiente. También necesito verificar que el estado de entrada de $ 15 de Alice realmente exista, y que no solo lo inventó. Eso significa que necesito ver la transacción que creó este estado y verificar que sea correcta y que también esté autorizada. Si esta transacción anterior, que envió a Alice $ 15, tiene una entrada de $ 10 perteneciente a Denzel y otra entrada de $ 5 de Eric, entonces también debo verificar las transacciones que las crearon. Y así sucesivamente, todo el camino de regreso a la transacción de "emisión" original en la que se creó el activo. La cantidad de transacciones que necesito verificar dependerá de cuántas veces los activos hayan cambiado de manos y el alcance de la ramificación hacia atrás.

Dado que los nodos de Corda no ven automáticamente cada transacción, ¿cómo obtienen las que necesitan? La respuesta es del remitente de cada nueva transacción. Antes de que Alice cree una transacción que consuma sus $ 15, ya debe haber verificado la transacción en la que la recibió. Y dado que Alice debe haber aplicado la técnica recursiva anterior, tendrá una copia de cada transacción necesaria para esta verificación. Bob simplemente solicita estas transacciones a Alice como parte de su interacción. Si Alice no responde apropiadamente, Bob concluye que Alice está tratando de engañarlo y rechaza el pago entrante. En el caso en el que Bob recibe una nueva transacción cuyas entradas tienen múltiples propietarios, puede obtener las pruebas necesarias de cada uno.

Presentando notarios

Hasta ahora hemos explicado cómo Bob puede verificar la corrección y autorización de una transacción entrante, incluido el rastreo recursivo de los orígenes de sus entradas. Pero hay una regla más en la que debemos pensar: la unicidad. Digamos que Alice es maliciosa. Puede generar una transacción en la que paga $ 10 a Bob, y otra en la que paga los mismos $ 10 a Charlie. Puede enviar estas transacciones a Bob y Charlie respectivamente, junto con una prueba completa de la corrección y autorización de cada uno. Si bien ambas transacciones entran en conflicto entre sí al consumir el mismo estado, no hay forma de que Bob y Charlie sepan esto.

Las cadenas de bloques convencionales resuelven este problema haciendo que cada nodo vea cada transacción, haciendo que los conflictos sean fáciles de detectar y rechazar. Entonces, ¿cómo Corda, con su visibilidad de transacción parcial, aborda el mismo problema? La respuesta es con la ayuda de un "notario". Un notario es una parte confiable (o partes que trabajan juntas) que garantiza que un estado en particular solo se consume una vez. Cada estado tiene un notario específico, que debe firmar cualquier transacción en la que se consuma ese estado. Una vez que un notario ha hecho esto, no debe firmar otra transacción para el mismo estado. Los notarios son los guardianes de la red de la singularidad de la transacción.

Si bien cada estado puede tener un notario diferente, todos los estados consumidos por una transacción en particular deben asignarse a la misma. Esto evita problemas relacionados con puntos muertos y sincronización, que deberían ser familiares para aquellos con experiencia en bases de datos distribuidas. Digamos que Alice y Bob acuerdan cambiar los $ 10 de Alice por los £ 7 de Bob. La transacción para este intercambio debe ser firmada por los notarios de ambos estados, pero ¿cuál va primero? Si el notario de Alice firma pero Bob falla por alguna razón, entonces Alice se quedará con una transacción incompleta y nunca podrá usar sus $ 10 nuevamente. Si Bob firma primero, entonces está expuesto de manera similar. Si bien nos gustaría que los notarios simplemente trabajen juntos, en la práctica esto requiere confianza mutua y el uso de un protocolo de consenso, complicaciones que los diseñadores de Corda decidieron evitar.

Si se requieren estados con notarios diferentes como entradas para una sola transacción, sus propietarios primero ejecutan transacciones especiales de "cambio de notario", que mueven un estado de un notario a otro, sin cambiar nada más. Entonces, cuando las partes están construyendo una transacción con múltiples entradas, primero deben acordar el notario que se utilizará y luego realizar los cambios necesarios. Si bien el desarrollador en mí sintió una pequeña punzada de dolor al leer sobre esta solución, no hay ninguna razón por la que no funcionará mientras los notarios jueguen.

También debe aclararse que, si bien cada notario es un solo actor lógico en términos de firmar transacciones, no es necesario que esté bajo el control de una sola parte. Un grupo de organizaciones podría ejecutar un notario colectivamente, utilizando un protocolo de consenso apropiado en el que se necesita la mayoría de los participantes para generar una firma válida. Esto evitaría que una sola parte maliciosa socavara la unicidad al firmar transacciones que entren en conflicto. En teoría, incluso podríamos permitir que todos los nodos de la red participen en este tipo de notarización compartida, aunque en ese caso estaríamos más o menos de regreso a una cadena de bloques convencional.

Tomando puntaje

Recapitulemos las diferencias clave entre Corda y las cadenas de bloques convencionales. En Corda, no hay una cadena de bloques unificada que contenga todas las transacciones confirmadas. Los nodos solo ven aquellas transacciones en las que están directamente involucrados, o de las cuales dependen históricamente. Los nodos son responsables de verificar la corrección y autorización de la transacción, pero dependen de notarios de confianza para verificar la unicidad.

Por supuesto, Corda es mucho más que esto: el uso de certificados digitales para autenticar la identidad, "mapas de red" para ayudar a los nodos a encontrar y confiar entre sí, "contratos" por estado que definen la corrección desde la perspectiva de cada estado, un versión determinista de la máquina virtual Java que ejecuta estos contratos, "flujos" que automatizan las negociaciones de transacciones, "ventanas de tiempo" que restringen las transacciones por tiempo, "oráculos" que dan fe de hechos externos y "CorDapps" que agrupan muchas cosas para una distribución fácil . Si bien cada una de estas características es interesante, se pueden encontrar equivalentes para todos en otras plataformas de blockchain. Mi objetivo en este artículo es centrarme en lo que hace que Corda sea único.

Entonces, ¿Corda cumple con su promesa? ¿Resuelve los problemas de escalabilidad, confidencialidad e interoperabilidad de blockchains? Y al tomar sus decisiones particulares, ¿cuánto precio paga Corda?

Más escalable, a veces

Comencemos con la escalabilidad. Aquí, la ventaja de Corda parece clara, ya que los nodos solo ven algunas de las transacciones en una red. En una cadena de bloques normal, el rendimiento máximo está limitado por la velocidad del nodo más lento en el procesamiento de transacciones. Por el contrario, una red Corda podría procesar un millón de transacciones por segundo, mientras que cada nodo ve solo una pequeña fracción de eso. La escalabilidad se extiende también a los notarios, ya que la tarea de firmar transacciones por unicidad puede extenderse entre muchos notarios diferentes, cada uno de los cuales es responsable de una pequeña proporción de los estados de la red.

Dicho esto, hay una situación en la que Corda funciona mucho peor que una cadena de bloques. Esto ocurre cuando un nodo recibe una nueva transacción que depende de muchas otras transacciones que no ha visto antes. Imagine un activo altamente líquido que se emitió hace 10 años y cambia de manos cada cinco minutos. El camino desde cualquier nueva transacción de regreso a la emisión de este activo será de más de un millón de transacciones. Cuando un nodo recibe este activo por primera vez, debe recuperar estos millones de transacciones del remitente y verificar cada una por turno. A una tasa (bastante optimista) de 1000 transacciones por segundo, habría un retraso de 17 minutos antes de que el destinatario pudiera enviar el activo, claramente demasiado tiempo para algo tan líquido.

¿Por qué las blockchains no sufren este problema? Debido a que los nodos ven y verifican cada transacción a medida que ocurre, constantemente actualizan el estado del libro mayor y saben exactamente quién es el propietario de cada activo en este momento. Incluso si un nodo nunca antes ha tenido un activo en particular, puede verificar instantáneamente la transacción en la que lo recibe y luego enviarlo de inmediato. Para decirlo de otra manera, los nodos de blockchain tienen que verificar las transacciones que podrían no ser relevantes para ellos, pero al hacerlo, pagan por adelantado el costo de verificar cualquier transacción futura que pueda entrar. Mientras que los nodos de Corda están menos ocupados en general, ejecutan el riesgo de necesitar hacer una gran cantidad de trabajo en cualquier momento. No hay nada escalable en eso.

Algo más confidencial.

Pasemos a la confidencialidad. En Corda, los nodos solo ven algunas de las transacciones de una red, lo que sin lugar a dudas significa una mejor privacidad que las cadenas de bloques convencionales. No obstante, Corda está lejos de resolver el problema de confidencialidad, porque los nodos aún ven algunas transacciones que no son de su incumbencia. Para tomar un ejemplo simple, si Alice le paga a Bob $ 10, entonces Bob envía esos $ 10 a Charlie, el nodo de Charlie tiene que mostrar la transacción entre Alice y Bob, aunque no lo involucre. En el momento en que Alice le pagó a Bob, no tenía forma de saber quién podría ver esta transacción en el futuro, y alguien podría ser enviado en cualquier momento.

Para ser justos, los desarrolladores de Corda son conscientes de este problema y lo discuten en el capítulo 15 de su Libro blanco técnico. El documento sugiere estrategias simples, como el uso de múltiples claves públicas por entidad o reducir la trazabilidad al devolver los activos a los emisores para su reemisión (similar a los "mezcladores de monedas" de criptomonedas). También menciona posibilidades futuras más avanzadas, como el uso de redes de anonimato tipo Tor para ocultar las direcciones IP de los participantes y aprovechar las pruebas de conocimiento cero o las de Intel enclaves seguros para validar transacciones sin revelar su contenido. Si bien todas estas sugerencias son válidas, también se pueden aplicar a blockchains regulares utilizando el modelo de entrada-salida, y de hecho han estado en criptomonedas como Dash, Zcash y Verge. Entonces, la única ventaja única de Corda en términos de confidencialidad sigue siendo su visibilidad reducida de las transacciones, una solución incompleta en el mejor de los casos.

Todos en la cria

Para comprender mejor la escalabilidad y la ventaja de confidencialidad de Corda, debemos observar cómo esto depende de la densidad y la superposición de las relaciones entre las transacciones. Imagine un "árbol genealógico" de las transacciones realizadas en una red, en el que los padres de cada transacción son los anteriores de los que depende inmediatamente. Específicamente, cuando la salida de una transacción es consumida por la entrada de otra, dibujamos una flecha que representa la relación de padre a hijo. Las transacciones pueden tener cualquier número de padres e hijos, aunque en la mayoría de los casos esperaríamos solo unos pocos.

Dado este árbol genealógico, definimos los antepasados ​​de una transacción como sus padres, abuelos, bisabuelos, etc. Los "Adán y Eva" de nuestro árbol son las transacciones de emisión que crearon activos y no tienen padres propios. Al igual que en los árboles genealógicos regulares, dos transacciones no pueden ser ancestros el uno del otro. En términos formales de informática, este es un Gráfico Acíclico Dirigido o DAG, en el que la ascendencia se define como el cierre transitivo de la relación principal.

Recuerde que cuando un nodo Corda procesa una transacción, debe descargar y verificar todos los antepasados ​​de esa transacción, aparte de los que ha visto antes. Entonces, si el árbol genealógico es profundo, las nuevas transacciones entrantes pueden tener una gran cantidad de antepasados ​​que deben verificarse, lo que desencadena el problema de escalabilidad de Corda. Además, si el árbol genealógico contiene un alto grado de cruzamiento, los antepasados ​​de una nueva transacción pueden incluir muchas o la mayoría de las transacciones pasadas en la red. En este caso, Corda proporcionará poca ventaja en términos de privacidad.

Por el contrario, si el árbol genealógico de las transacciones es poco profundo y contiene muchas islas desconectadas que no interactúan entre sí, las ventajas de Corda se destacan. Los nodos nunca necesitarán verificar una gran cantidad de transacciones a la vez, y pueden mantenerse en la oscuridad sobre la mayoría de las transacciones que no están relacionadas con las suyas. Si se usa como un libro mayor financiero, podríamos decir que Corda es ideal para mercados altamente fragmentados cuyos activos rara vez cambian de manos.

Interoperabilidad para la victoria

Aquí hay un área en la que Corda realmente brilla. Imagine dos redes Corda separadas, con diferentes conjuntos de activos y participantes. En algún momento, un participante en una red quiere enviar un activo a alguien en la otra. A diferencia de las cadenas de bloques convencionales, no se espera que un nodo haya verificado todas las transacciones pasadas, por lo que el nodo que recibe este nuevo activo no experimentará nada inusual. Cuando entra la transacción, simplemente solicita y verifica el historial relevante, sin darse cuenta de que se trata de una "red separada". Para estirar un cliché, podríamos decir que no hay extraños en Corda, solo amigos que aún no se han conocido.

En realidad, las cosas no son tan simples. Cualquier nodo de Corda decide explícitamente en qué notarios confiar, ya que un notario que se porta mal puede causar un caos financiero. Además, los nodos necesitan un "certificado" otorgado por un "portero" para conectarse a otros nodos en una red, ya que no podemos permitir que miembros aleatorios del público comiencen a conectarse a nodos y malgasten sus recursos. Por lo tanto, antes de que un nodo en una red pueda comenzar a solicitar y verificar transacciones de otra red, deberá agregarlo a su lista de notarios de confianza y obtener el certificado apropiado. Si bien esto implica una configuración y administración manual, es lo mínimo que se puede esperar para un sistema de esta naturaleza. En general, es justo concluir que la interoperabilidad es la gran victoria de Corda sobre las cadenas de bloques convencionales.

Reintermediación

Es hora de hablar sobre la desintermediación, el elefante en la habitación de Corda. En el contexto de blockchains, la desintermediación significa que cada participante puede verificar cada transacción por sí mismo, sin depender del buen comportamiento de terceros. En mi vista, la desintermediación es la principal ventaja de las cadenas de bloques sobre las bases de datos centralizadas, en las cuales todos los participantes dependen completamente del propietario de esa base de datos. Si los participantes en una red tienen un intermediario en el que pueden confiar, y no existe un caso comercial o regulatorio para la desintermediación, entonces hay No tiene sentido en el uso de una cadena de bloques. Las bases de datos centralizadas son más rápidas y más eficientes, y evitan el problema de la confidencialidad de las transacciones.

Entonces, ¿los participantes en una red Corda logran la desintermediación? Bueno, sí, sí y sí pero no. Para la entrega de transacciones, Corda marca la casilla, ya que los nodos involucrados en una transacción se comunican directamente entre sí. En términos de corrección y autorización, también está en buena forma, ya que cada nodo puede verificar estas propiedades por sí mismo. Sin embargo, cuando se trata de verificar la unicidad de la transacción, Corda falla la prueba de desintermediación. Los nodos no pueden confirmar la unicidad por sí mismos, ya que no ven todas las transacciones en la red, y la tarea se subcontrata a notarios de confianza.

Los participantes de Corda están a merced de los notarios de varias maneras. Primero, un notario puede negarse a firmar una transacción, incluso si sus entradas consumen salidas que nunca antes se habían usado. En un libro de contabilidad financiera, esto evita que alguien envíe o intercambie sus activos. En segundo lugar, un notario podría firmar dos transacciones en conflicto que consumen el mismo resultado, lo que lleva a dos partes a creer que recibieron lo mismo. A medida que ambos destinatarios del activo duplicado lo envían o intercambian en otras transacciones, el contagio se propaga y la integridad de todo el libro de contabilidad pronto podría verse afectada. Finalmente, un notario puede negarse a firmar una transacción de "cambio de notario" para transferir un estado a un competidor, manteniendo efectivamente al propietario del activo como rehén. Para una transacción que involucra estados con diferentes notarios, está lejos de decir que Corda introduce más intermediación que una base de datos centralizada, porque varios terceros tienen el control.

Para poner este riesgo en perspectiva, vale la pena recordar que los notarios de Corda no necesitan ser controlados por una sola organización. También pueden consistir en un grupo de nodos que ejecutan un algoritmo de consenso que puede tolerar a los malos actores. En este caso, un notario funcionará bien siempre que la mayoría de sus nodos miembros sigan las reglas. En la superficie, esto suena más bien como una cadena de bloques, que depende de que la mayoría de los validadores se comporten bien. Sin embargo, en Corda los riesgos son significativamente mayores. Lo peor que puede hacer una camarilla de validadores de blockchain es evitar que se confirmen algunas transacciones. Un notario malicioso de Corda también puede firmar transacciones conflictivas, enviando el libro mayor a un abismo inconsistente.

Un animal extraño

Al unir escalabilidad, confidencialidad, interoperabilidad y desintermediación, es difícil llegar a un veredicto simple sobre la alternativa Corda. En general, desde la perspectiva de este desarrollador de plataforma blockchain, parece, bueno ... convincente pero extraño. Diseñadas para resolver los problemas clave de escalabilidad y confidencialidad, las soluciones de Corda son incompletas y dependen en gran medida de la forma del “árbol genealógico” de la transacción. Sin embargo, para lograr estas victorias parciales, Corda pierde una propiedad central de blockchains: la eliminación de intermediarios de transacciones. Si bien Corda sin duda sobresale en interoperabilidad, ¿es eso realmente suficiente?

Si quisiéramos ser escépticos, podríamos decir que al equipo de Corda se le asignó una tarea imposible: diseñar un sabor de blockchain que se adaptara a los bancos que financian R3. Pero el beneficio clave de blockchains sobre bases de datos centralizadas es la desintermediación, que tiene el precio de una confidencialidad reducida. ¿Cómo podría tener sentido esta compensación para las instituciones financieras que ganan dinero actuando como intermediarios y son muy sensibles a la privacidad? Visto desde esta perspectiva, uno podría elogiar a Corda como un compromiso heroico pero en última instancia insatisfactorio entre el deseo de los miembros de R3 de hacer algo blockchainy las restricciones comerciales y regulatorias bajo las cuales existen.

Custodio 2.0

Pero prefiero adoptar un enfoque más positivo. En lugar de centrarnos en la comparación con blockchains, podemos ver a Corda como una importante actualización técnica del statu quo financiero. Simplemente reemplace la palabra "notario" con "custodio", y todo encaja de manera bastante ordenada. (UNA custodio es una institución financiera que posee activos en nombre de otros.) Sí, los notarios son intermediarios, que pueden bloquear transacciones y permitir que ocurran conflictos, pero esto también es cierto para los custodios de hoy. Una "transacción de cambio notarial" puede verse como la transferencia de activos de un custodio a otro. Y las transacciones de Corda están firmadas por un solo notario por la misma razón por la que nos gusta que ocurran intercambios de activos en un solo lugar, para evitar que cualquiera de las partes se quede sin dinero.

Mirando a Corda de esta manera, podemos ver cómo mejora el modelo de custodia tradicional:

• Define un paradigma computacional estándar y un formato para expresar activos financieros y otros compromisos contractuales.
• Proporciona software de código abierto para interpretar y ejecutar estos compromisos, garantizando que las partes y los custodios de la transacción acuerden el resultado de cada transacción.
• Se pueden crear custodios multiparte complejos que protegen contra el abuso (¡usando solo software!) Al aprovechar algoritmos de consenso tolerantes a fallas.
• Se define un proceso estándar ("cambio notarial") para la transferencia de activos entre custodios, y ningún custodio puede rechazarlo.
• Los custodios no pueden usar un activo bajo su custodia sin el consentimiento del propietario, ya que las transacciones también deben ser firmadas por los propietarios de sus insumos.

Estoy lejos de ser un banquero, pero para mí todo esto suena bastante prometedor. Y quizás Corda podría aplicarse igualmente a otras industrias con estructuras de custodia complejas, como los seguros o el transporte marítimo. Si bien el diseño de Corda puede no proporcionar la desintermediación completa de una cadena de bloques, propone una transformación poderosa para las industrias en las que los intermediarios juegan un papel esencial.

Una vez que seguimos esta línea de pensamiento, inevitablemente surge una pregunta: si ya estamos confiando en los notarios con el trabajo de vida o muerte de verificar la unicidad, ¿por qué no confiar en ellos también para su corrección y autorización? Corda ya tiene la noción de un "notario de validación", que verifica completamente las transacciones antes de agregar su firma. En lugar de que los nodos regulares de Corda descarguen y verifiquen los antepasados ​​de sus transacciones, ¿por qué no simplemente preguntar a un notario? Esto podría ayudar con la escalabilidad y la confidencialidad, ya que la mayoría de los nodos no verían más transacciones que las suyas. Incluso podríamos sugerir que los notarios de una red confían plenamente entre sí, por lo que no hay necesidad de preocuparse por los antepasados. El notario de cada estado podría garantizar su validez, verificando solo la transacción que lo creó con la ayuda de otros notarios.

Deja que Corda sea Corda

Todo esto nos lleva de vuelta a donde comenzamos: Corda no es realmente un competidor para blockchains convencionales, MultiChain incluido. Corda es Corda: un nuevo tipo interesante de libro mayor distribuido, que se ha optimizado para las necesidades de quienes lo financian. No tengo idea de si Corda finalmente tendrá éxito o fracasará, porque no conozco sus costos y beneficios en el mundo real en comparación con la forma actual de hacer las cosas. Pero no importa lo que pase en el futuro, ciertamente vale la pena estudiarlo en términos de filosofía y diseño.

En cuanto a MultiChain, estamos adoptando un enfoque diferente. Para robar una línea de El Ala Oeste, estamos decididos a "dejar que blockchain sea blockchain". Las cadenas de bloques son lo que son, y no tenemos planes de convertirlas en algo diferente. Como la infraestructura de datos para una aplicación compartida, una cadena de bloques representa una compensación específica en comparación con una base de datos centralizada: una ganancia en la desintermediación a costa de una confidencialidad reducida. Y estamos trabajando duro para hacer que MultiChain 2.0 sea lo mejor posible blockchain plataforma para uso de desarrolladores de aplicaciones.

Por favor publique cualquier comentario en Linkedin.

Fuente: https://www.multichain.com/blog/2018/05/r3-corda-deep-dive-and-technical-review/