Demostración de PIECHAIN: Explorando un marco práctico de interoperabilidad de Blockchain

Autores: (1) Daniel Reijsbergen, Universidad Tecnológica de Nanyang, Singapur, Singapur; (2) Aung Maw, Universidad de Tecnología y Diseño de Singapur, Singapur, Singapur; (3) Jingchi Zhang, Universidad Tecnológica de Nanyang, Singapur, Singapur; (4) Tien Tuan Anh Dinh, Universidad Deakin, Melbourne, Australia; (5) Anwitaman Datta, Universidad Tecnológica de Nanyang, Singapur, Singapur. Descripción general del contenido Resumen e introducción Descripción general de PIEChain Implementación de PIEChain Plan de demostración Extensiones Referencias Abstracto En los últimos años ha surgido una gran cantidad de plataformas blockchain diferentes, pero muchas de ellas operan en silos. Como tal, existe la necesidad de una comunicación confiable entre cadenas para permitir la interoperabilidad de la cadena de bloques. La interoperabilidad de Blockchain es un desafío porque las transacciones generalmente no se pueden revertir; por lo tanto, si se confirma una transacción, el protocolo debe garantizar que todas las transacciones relacionadas también se confirmen. Los enfoques de interoperabilidad existentes, por ejemplo, Cosmos y Polkadot, son limitados en el sentido de que solo respaldan la interoperabilidad entre sus propias subcadenas o requieren cambios intrusivos en las cadenas de bloques existentes. Para superar esta limitación, proponemos PIECHAIN, un marco general de comunicación entre cadenas basado en Kafka. Utilizamos PIECHAIN para un estudio de caso práctico: una subasta entre cadenas en la que los usuarios que poseen tokens en varias cadenas pujan por un boleto vendido en otra cadena. PIECHAIN es la primera implementación práctica disponible públicamente de un marco general para la comunicación entre cadenas. I. INTRODUCCIÓN Una cadena de bloques es una base de datos replicada y a prueba de manipulaciones diseñada para entornos hostiles. Consta de una serie de nodos, algunos de los cuales pueden ser maliciosos, que mantienen un libro de contabilidad de sólo anexos. El libro mayor almacena transacciones que modifican algunos estados globales. En el ejemplo canónico, es decir, las criptomonedas [7], los estados globales son cuentas de usuario y tokens nativos (fungibles), y el libro mayor contiene transacciones que transfieren tokens de una cuenta a otra. En otra aplicación emergente, las cadenas de bloques almacenan tokens no fungibles (NFT) que representan de forma única activos, por ejemplo, obras de arte digitales o entradas para conciertos. Muchas cadenas de bloques también admiten contratos inteligentes que permiten a los usuarios definir sus propios estados y códigos que modifican los estados. Los contratos inteligentes se almacenan en el libro mayor y todos los nodos de la cadena de bloques los replican y mantienen consistentes. En los últimos años, han surgido muchas plataformas blockchain independientes, lo que ha dado como resultado un ecosistema con una larga cola. Por un lado, hay una pequeña cantidad de plataformas blockchain de uso general y muy populares, como Ethereum e Hyperledger. Por otro lado, hay miles de cadenas de bloques más pequeñas diseñadas para aplicaciones específicas, la mayoría de las cuales se encuentran sólo en las primeras etapas de desarrollo. Esto incluye más de 10 000 criptomonedas [3] a principios de 2023, junto con cadenas de bloques para atención médica, gestión de identidades e IoT. En general, estas cadenas de bloques no interoperan, es decir, existen en silos. Como tal, la interoperabilidad de blockchain, es decir, la capacidad de los usuarios de intercambiar información o activos en diferentes blockchains, es un tema que está atrayendo cada vez más interés por parte de la comunidad investigadora [6], [10], [4], [1], [ 11]. Uno de los principales desafíos en el diseño de un marco de interoperabilidad blockchain seguro es garantizar la atomicidad, es decir, que todos los pasos de un conjunto acordado de transacciones terminen exitosamente o que ninguno lo haga. Esto es más complicado en las cadenas de bloques que en las bases de datos tradicionales porque las transacciones de las cadenas de bloques son (en principio) irreversibles. Por ejemplo, si ya se realizó un pago por un NFT en la Cadena A en la Cadena B, entonces la atomicidad requiere que la transacción en la Cadena A debe continuar porque la transacción en la Cadena B no se puede revertir. Un enfoque común para garantizar la atomicidad es custodiar todos los tokens involucrados en el acuerdo en contratos inteligentes y liberarlos solo a través de un mensaje de confirmación firmado por todas las partes [6]. Otro desafío importante en la interoperabilidad de blockchain es garantizar la vida, de modo que los tokens depositados no puedan congelarse para siempre. Para garantizar la vida, los nodos deben poder enviar un mensaje de cancelación que permita a todas las partes retirar sus activos del depósito en garantía. Para garantizar tanto la atomicidad como la vitalidad, un marco de interoperabilidad debe ser capaz de tolerar nodos adversarios que envían un mensaje de confirmación a una cadena de bloques y un mensaje de cancelación a otra. Se sabe que en las redes asíncronas (es decir, donde no hay límites en los retrasos de los mensajes) esto es imposible de lograr sin un tercero confiable (TTP) [10]. Hay dos enfoques principales para superar este desafío [6]. El primer enfoque es combinar una suposición de sincronía con un período de recuperación para los abortos, es decir, suponiendo que un voto de confirmación, una vez generado, se puede agregar a todas las cadenas de bloques afectadas antes de que finalice cualquier período de recuperación para los abortos. Este enfoque se adopta, por ejemplo, en contratos con hash bloqueado en el tiempo [5]. El segundo enfoque es reemplazar el TTP con otra cadena de bloques para garantizar que se pueda crear un mensaje de confirmación o de cancelación válido, pero no ambos [6], [9]. Aunque se han propuesto enfoques de ambos tipos en la literatura científica, o no tienen una implementación disponible públicamente [5], [6], [9], o tienen un alcance de aplicación limitado, por ejemplo, la creación de activos respaldados en otra cadena de bloques. [11] o intercambios de tokens [8]. En un desarrollo separado, han surgido varias plataformas blockchain que permiten la interoperabilidad de forma predeterminada, por ejemplo, Cosmos y Polkadot. Sin embargo, estas plataformas solo admiten la interoperabilidad entre sus propias subcadenas o requieren cambios intrusivos en las cadenas de bloques existentes. Esto motiva la necesidad de un marco de interoperabilidad general y práctico que pueda conectarse a las plataformas blockchain existentes sin modificarlas. Nuestro objetivo es proporcionar dicho marco. : Presentamos PIECHAIN para lograr este objetivo. Como la sincronía es difícil de asumir en la práctica, PIECHAIN utiliza servicios entre cadenas para reemplazar el TTP. Los servicios entre cadenas se comunican mediante un registro de eventos que utiliza el protocolo Kafka de Apache para mayor eficiencia. Para demostrar la relevancia práctica de PIECHAIN, hemos implementado un servicio entre cadenas para un estudio de caso realista: una subasta entre cadenas. Hemos conectado PIECHAIN con algunas de las plataformas blockchain más populares que admiten contratos inteligentes: Ethereum, Hyperledger Fabric y Quorum. Finalmente, hemos desarrollado una GUI para nuestro caso de estudio. El caso de estudio de la subasta es uno de los tres casos de estudio (dos subastas y un préstamo rápido [6]) cuyo código se puede encontrar en el repositorio de códigos PIEChain en GitHub. Contribuciones y Novedad II. DESCRIPCIÓN GENERAL DE PIECHAIN A. Entidades Las principales entidades en PIECHAIN son las siguientes (ver también Figura 1): Blockchains, que almacenan activos (por ejemplo, tokens, claves) en poder de los usuarios. Un usuario puede tener activos en varias cadenas de bloques. Cada cadena de bloques tiene su propio protocolo para determinar quién tiene acceso de lectura y escritura: las cadenas de bloques suelen tener permisos, es decir, un conjunto fijo de nodos tiene acceso de lectura y escritura, o no tienen permisos, es decir, todos tienen acceso de lectura y pueden crear transacciones, y los nodos con suficiente potencia (por ejemplo, velocidad de procesamiento) puede agregar transacciones a la cadena de bloques. Servicios entre cadenas (CC-SVC), que permiten a los usuarios intercambiar activos en diferentes cadenas de bloques. Cada CC-SVC consta de un servidor que interactúa con los clientes usuarios para facilitar la comunicación entre cadenas. En la práctica, CC-SVC cobra a los usuarios por participar y puede interactuar con cualquier cantidad de blockchains. A continuación, cada CC-SVC corresponde a un conjunto de eventos involucrados en un intercambio atómico de activos que un servidor envía al libro mayor de Kafka. En la práctica, un único servidor puede operar muchos CC-SVC. La red Kafka, que sirve como un registro de eventos generados por los CC-SVC. Los eventos corresponden a transacciones realizadas en blockchains subyacentes. La red Kafka es operada por un conjunto fijo de nodos que cobran a los CCSVC por cargar eventos. En PIECHAIN, asumimos que los CC-SVC son semiconfiables y que están motivados a comportarse honestamente al tener una reputación que mantener, similar a los proveedores de servicios comerciales subcontratados. Los operadores de la red Kafka no son de confianza, pero no tienen ningún incentivo para comportarse mal, ya que no interactúan con las cadenas de bloques subyacentes. Esto nos permite ejecutar un protocolo (Kafka) que prioriza la eficiencia sobre la seguridad. Un diseño alternativo es hacer que los CC-SVC no sean de confianza y que la red Kafka sea confiable. En este caso, cada nodo de Kafka ejecuta un cliente (ligero) para cada una de las cadenas de bloques subyacentes para validar la inclusión de transacciones en esas cadenas. En este caso, el registro de eventos tendría que utilizar un protocolo más seguro como PBFT [2]. Dejamos tal diseño como trabajo futuro. B. Flujo del proceso Dadas las entidades de la Sección II-A, el flujo de proceso en PIECHAIN tiene la misma estructura que los acuerdos entre cadenas propuestos por Herlihy et al. [6]. Los acuerdos entre cadenas son acuerdos entre múltiples usuarios para intercambiar activos en diferentes cadenas de bloques y constan de cinco fases (ver también la Figura 2): Fase de compensación: el CC-SVC crea los contratos inteligentes en las diferentes cadenas de bloques que se utilizan para depositar y transferir los activos involucrados en el acuerdo. Fase de depósito en garantía: los usuarios depositan en custodia sus activos salientes transfiriéndolos a los contratos inteligentes. Fase de transferencia: los activos se intercambian tentativamente, es decir, se especifica la lógica de ejecución de los contratos inteligentes. Fase de validación: cada usuario comprueba si el resultado de la lógica de ejecución sería de su agrado. Fase de compromiso: el acuerdo se concluye mediante el compromiso si todas las partes están satisfechas, o mediante el aborto en caso contrario. Compromiso significa que la lógica de ejecución de los contratos inteligentes se ejecuta y que los activos se intercambian según lo especificado en el acuerdo. El aborto significa que los activos de cada contrato inteligente se devuelven a sus propietarios originales. Para confirmar, los usuarios construyen interactivamente un voto de confirmación, que CC-SVC envía al libro mayor de Kafka. Para cancelar, un único usuario envía un mensaje de cancelación al CC-SVC. Para cada CC-SVC, se puede agregar un mensaje de confirmación o de cancelación al libro mayor de Kafka, pero no ambos. Todos los contratos inteligentes en las diferentes cadenas de bloques aceptan una prueba de inclusión de una votación de confirmación en el libro mayor de Kafka; esto garantiza que una vez que se construye una votación de confirmación, se pueden ejecutar todas las transferencias de activos o ninguna. III. IMPLEMENTACIÓN DE PIECHAIN Para ilustrar la aplicabilidad práctica de PIECHAIN, lo hemos conectado a varias plataformas blockchain de uso común y lo hemos utilizado para implementar una aplicación de la literatura científica [6]: una subasta entre cadenas para un activo digital. El soporte de blockchain se extiende a otros estudios de caso, como analizamos en la Sección V. A. Soporte de cadena de bloques Para interconectar una cadena de bloques subyacente con PIECHAIN, los CC-SVC deben poder validar transacciones en esas cadenas. Nuestra implementación admite las siguientes plataformas blockchain: Ethereum (las versiones de prueba de trabajo y prueba de autoridad de Ethereum privado), Hyperledger Fabric y Quorum. Los dos últimos admiten cadenas de bloques autorizadas, mientras que Ethereum tiene una cadena principal sin permiso pero también admite cadenas privadas con la misma funcionalidad. B. Subasta En nuestro caso de estudio, un subastador vende un activo en una cadena de bloques y recibe el pago en forma de activos en otra cadena de bloques. Como en [6], utilizamos el ejemplo de un vendedor de entradas. El billete es un NFT en una cadena de bloques dedicada, mientras que la otra cadena de bloques admite tokens fungibles más utilizados (por ejemplo, Ether). La primera cadena de bloques se llama cadena de bloques de boletos y la segunda, cadena de bloques de monedas. Esto se generaliza fácilmente a entornos con más de una cadena de bloques de monedas. A continuación, consideramos una subasta de primer precio (es decir, el postor con la oferta más alta paga su oferta y recibe el activo). Las cinco fases del protocolo son entonces las siguientes: El subastador contrata un CC-SVC que crea contratos inteligentes en la cadena de bloques de boletos y en las cadenas de bloques de monedas. El subastador transfiere su activo (el NFT del boleto) al contrato del boleto y los postores transfieren sus ofertas al contrato en su cadena de bloques de monedas. La lógica de ejecución está determinada: el subastador actualiza cada uno de los contratos de billetes y monedas especificando qué parte recibe el billete y qué oferta se transfiere al subastador. (Tenga en cuenta que esta lógica no se puede especificar en el contrato de boletos a priori porque el contrato en la cadena de boletos no puede leer datos de las cadenas de bloques de monedas). Cada usuario (es decir, el subastador y los postores) determina si el resultado del protocolo de transferencia les conviene, es decir, si el billete se transfiere realmente a la parte correcta. Todos los usuarios crean un voto de confirmación; una vez creado, se envía a cada contrato para implementar las transferencias especificadas en la fase de transferencia. En PIECHAIN, la subasta requiere dos tipos (lógicos) de CC-SVC: el retransmisor y el firmante. El retransmisor escucha eventos (ofertas) en las cadenas de monedas y los transmite a la cadena de bloques de boletos. El firmante ayuda a crear el voto de confirmación. IV. PLAN DE DEMOSTRACIÓN Para nuestra demostración, hemos desarrollado una interfaz gráfica de usuario (GUI) utilizando el marco React para ilustrar una subasta entre cadenas. La GUI consta de tres páginas principales: una página de panel que muestra una lista de subastas conocidas como se muestra en la Figura 3, una vista detallada de subastas individuales como se muestra en la Figura 5 y una página para la creación de nuevas subastas (no mostrada). La opinión es la misma para un subastador que para los postores. En la vista del panel, los posibles subastadores pueden hacer clic en el botón "Crear nueva subasta" para iniciar una subasta: el subastador selecciona un CC-SVC, el activo que se subastará, de qué otras cadenas de bloques aceptar ofertas, el tipo de cambio de los tokens entre diferentes blockchains (que deben fijarse de antemano) y el momento en que concluye la subasta. A continuación, el relé CC-SVC crea los contratos relevantes y envía la dirección del contrato en la cadena de activos al subastador. Luego, el subastador puede agregar la subasta en su panel agregando la dirección del contrato y haciendo clic en el botón "Agregar subasta existente". Mientras tanto, anuncia la dirección del contrato a los posibles postores. Cuando los postores conocen la dirección del contrato de activos, también pueden agregarla a sus paneles. Una vez que el postor haya agregado la subasta, podrá verla con más detalle presionando el botón "Ver" en el panel de la subasta, que lo llevará a la página de vista detallada. En esta página, el postor puede ver información crucial sobre la subasta, como los tiempos de creación y finalización, y una lista de ofertas. La oferta más alta está marcada con un asterisco. Si la subasta aún está en curso, el postor puede agregar una oferta especificando la cadena de bloques. sobre el cual se realiza la oferta y la cantidad de tokens a ofertar. Luego se realiza una transacción con el contrato de moneda correspondiente y la información se envía al relé CC-SVC. Un usuario también puede cancelar cualquier oferta que haya realizado a través de CC-SVC. Una vez concluida la subasta, el CC-SVC de retransmisión informa a todos los participantes y especifica la transferencia tentativa de bienes en los contratos inteligentes. Luego, el CC-SVC solicita a los clientes de todos los participantes que participen en la creación de una votación de confirmación. (La falta de participación debería dar lugar a una penalización [4].) Cuando se ha creado el voto de compromiso, se envía a todos los contratos para iniciar la transferencia final de activos. En este punto, la GUI mostrará que la subasta ha concluido. El flujo exacto de la demostración será el siguiente: Un usuario, el subastador, abre una GUI basada en un navegador web y la utiliza para iniciar una subasta de un activo seleccionado. En este proceso, se demuestran todas las funciones de la página de creación de subastas. El activo existe en una cadena de tickets dedicada que se ejecuta en Hyperledger Fabric. Los contratos se crean en todas las cadenas de bloques involucradas (paso 1 de la Figura 2. Al menos otros dos usuarios, que utilizan ventanas del navegador en diferentes máquinas, navegan a la página de detalles de la subasta recién creada y envían sus ofertas individuales para el activo (paso 2 de la Figura 2). Al menos un postor usa Ethereum (privado) y el otro usa Quorum. Después de un tiempo, la subasta concluye y se determina la oferta ganadora (paso 3 de la Figura 2). Esto hará que el subastador envíe un evento de “finalización de subasta” al CCSVC de retransmisión. Los firmantes, que están escuchando este tipo de evento, lo notarán y crearán un voto de confirmación (paso 4 de la Figura 2). Luego, el voto de confirmación se envía a Kafka y el nodo de retransmisión lo reenvía al contrato de subasta y a los contratos de la cadena de monedas. En este punto, el activo se transfiere al postor ganador y la oferta ganadora al subastador (paso 5 de la Figura 2). A lo largo de la demostración, usaremos una ventana de terminal para consultar los estados de las cadenas de bloques subyacentes después de cada paso, como se muestra en la Figura 4. Esto permitirá a la audiencia observar los cambios que ocurren en segundo plano e interactuar con el flujo de la demostración: por ejemplo, solicitando nuevas acciones para ver cómo cambian los estados de fondo. Para ilustrar el flujo de la demostración, se puede encontrar un vídeo en línea 2 que muestra las diapositivas de la demostración provisionales y la pantalla si el subastador y los postores realizaran sus acciones usando una sola computadora. (Esto no es una limitación de PIECHAIN, pero facilita la grabación de vídeo). V. EXTENSIONES El marco CC-SVC y la interfaz para las cadenas de bloques compatibles se pueden utilizar para extender fácilmente PIECHAIN a otros casos de uso. Uno de ellos es un préstamo rápido entre cadenas como se describe en [6]. Una GUI para préstamos rápidos tendría una relevancia práctica limitada, ya que las oportunidades de arbitraje normalmente se resuelven rápidamente, por lo que las interacciones con CC-SVC normalmente se realizarían mediante robots comerciales. Sin embargo, si el tiempo lo permite, mostraremos una visualización del impacto de los pasos de un préstamo rápido en los estados de los distintos contratos involucrados. REFERENCIAS [1] Rafael Belchior, André Vasconcelos, S ´ ergio Guerreiro y Miguel ´ Correia. Una encuesta sobre la interoperabilidad de blockchain: tendencias pasadas, presentes y futuras. Encuestas de Computación ACM (CSUR), 2021. [2] Miguel Castro y Bárbara Liskov. Práctica tolerancia a fallos bizantinos. En OsDI, volumen 99, páginas 173–186, 1999. [3]CoinLore. https://www.coinlore.com/all monedas, 2023. [4] Daniel Engel, Maurice Herlihy y Yingjie Xue. El fracaso es (literalmente) una opción: compromiso atómico versus opcionalidad en las finanzas descentralizadas. En SSS 2021, 2021. [5] Maurice Herlihy. Intercambios atómicos entre cadenas. En ACM PODC, páginas 245–254, 2018. [6] Maurice Herlihy, Barbara Liskov y Liuba Shrira. Acuerdos entre cadenas y comercio adversario. La revista VLDB, 2021. [7]Satoshi Nakamoto. Bitcoin: un sistema de efectivo electrónico entre pares, 2008. [8] Sri AravindaKrishnan Thyagarajan, Giulio Malavolta y Pedro Moreno-Sánchez. Intercambios atómicos universales: intercambio seguro de monedas en todas las cadenas de bloques. En IEEE S&P, 2022. [9] Victor Zakhary, Divyakant Agrawal y Amr El Abbadi. Compromiso atómico en blockchains. Actas del VLDB Endowment, 13(9), 2021. [10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias y William J. Knottenbelt. SoK: comunicación entre libros de contabilidad distribuidos. En Criptomoneda financiera, 2021. [11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais y William Knottenbelt. Xclaim: activos respaldados por criptomonedas, interoperables y sin confianza. En IEEE S&P, 2019. Este documento está bajo licencia CC 4.0. disponible en arxiv