Demonstração PIECHAIN: Explorando uma estrutura prática de interoperabilidade Blockchain

Autores: (1) Daniel Reijsbergen, Universidade Tecnológica de Nanyang, Singapura, Singapura; (2) Aung Maw, Universidade de Tecnologia e Design de Singapura, Singapura, Singapura; (3) Jingchi Zhang, Universidade Tecnológica de Nanyang, Singapura, Singapura; (4) Tien Tuan Anh Dinh, Universidade Deakin, Melbourne, Austrália; (5) Anwitaman Datta, Universidade Tecnológica de Nanyang, Singapura, Singapura. Visão geral do conteúdo Resumo e introdução Visão geral do PIEChain Implementação do PIEChain Plano de Demonstração Extensões Referências Abstrato Uma infinidade de diferentes plataformas blockchain surgiram nos últimos anos, mas muitas delas operam em silos. Como tal, há uma necessidade de comunicação confiável entre cadeias para permitir a interoperabilidade da blockchain. A interoperabilidade da Blockchain é um desafio porque as transações normalmente não podem ser revertidas – como tal, se uma transação for confirmada, o protocolo deve garantir que todas as transações relacionadas também sejam confirmadas. As abordagens de interoperabilidade existentes, por exemplo, Cosmos e Polkadot, são limitadas no sentido de que apenas suportam a interoperabilidade entre as suas próprias subcadeias ou requerem alterações intrusivas nas cadeias de bloqueio existentes. Para superar esta limitação, propomos PIECHAIN, uma estrutura geral de comunicação entre cadeias baseada em Kafka. Utilizamos PIECHAIN para um estudo de caso prático: um leilão entre cadeias em que usuários que possuem tokens em várias cadeias fazem lances por um ingresso vendido em outra cadeia. PIECHAIN é a primeira implementação prática disponível publicamente de uma estrutura geral para comunicação entre cadeias. I. INTRODUÇÃO Um blockchain é um banco de dados replicado e inviolável, projetado para ambientes hostis. Consiste em vários nós, alguns dos quais podem ser maliciosos, que mantêm um livro-razão somente para anexos. O razão armazena transações que modificam alguns estados globais. No exemplo canônico, ou seja, criptomoedas [7], os estados globais são contas de usuário e tokens nativos (fungíveis), e o livro-razão contém transações que transferem tokens de uma conta para outra. Noutra aplicação emergente, as blockchains armazenam tokens não fungíveis (NFTs) que representam exclusivamente ativos, por exemplo, obras de arte digital ou bilhetes para concertos. Muitos blockchains também suportam contratos inteligentes, permitindo que os usuários definam seus próprios estados e códigos que modifiquem os estados. Os contratos inteligentes são armazenados no livro-razão e replicados e mantidos consistentes por todos os nós do blockchain. Nos últimos anos, surgiram muitas plataformas blockchain independentes, resultando em um ecossistema com cauda longa. Por um lado, há um pequeno número de plataformas blockchain de uso geral extremamente populares, como Ethereum e Hyperledger. Por outro lado, existem milhares de blockchains menores projetados para aplicações específicas, a maioria dos quais estão apenas em estágios iniciais de desenvolvimento. Isto inclui mais de 10 000 criptomoedas [3] no início de 2023, juntamente com blockchains para cuidados de saúde, gestão de identidade e IoT. Em geral, essas blockchains não interoperam, ou seja, existem em silos. Como tal, a interoperabilidade da blockchain, ou seja, a capacidade dos usuários trocarem informações ou ativos em diferentes blockchains, é um assunto que está atraindo interesse crescente da comunidade de pesquisa [6], [10], [4], [1], [ 11]. Um dos principais desafios na concepção de uma estrutura segura de interoperabilidade de blockchain é garantir a atomicidade, ou seja, que todas as etapas de um conjunto acordado de transações terminem com sucesso, ou nenhuma o faça. Isto é mais complicado em blockchains do que em bancos de dados tradicionais porque as transações de blockchain são (em princípio) irreversíveis. Por exemplo, se um pagamento por um NFT na Cadeia A já foi feito na Cadeia B, então a atomicidade exige que a transação na Cadeia A prossiga porque a transação na Cadeia B não pode ser revertida. Uma abordagem comum para garantir a atomicidade é depositar todos os tokens envolvidos no negócio em contratos inteligentes e liberá-los apenas por meio de uma mensagem de commit assinada por todas as partes [6]. Outro desafio importante na interoperabilidade da blockchain é garantir a vitalidade, para que os tokens que estão sob custódia não possam ser congelados para sempre. Para garantir a vivacidade, deve ser possível aos nós enviar uma mensagem de aborto que permita a todas as partes retirarem os seus activos do depósito. Para garantir a atomicidade e a vivacidade, uma estrutura de interoperabilidade deve ser capaz de tolerar nós adversários que enviam uma mensagem de confirmação para uma blockchain e uma mensagem de aborto para outra. É sabido que em redes assíncronas (ou seja, onde não há limites para atrasos de mensagens) isso é impossível de ser alcançado sem um terceiro confiável (TTP) [10]. Existem duas abordagens principais para superar esse desafio [6]. A primeira abordagem é combinar uma suposição de sincronia com um período de espera para abortos – ou seja, assumindo que um voto de confirmação, uma vez gerado, pode ser anexado a todos os blockchains afetados antes do final de qualquer período de espera para abortos. Esta abordagem é adotada, por exemplo, em contratos timelocked com hash [5]. A segunda abordagem é substituir o TTP por outra blockchain para garantir que uma mensagem válida de commit ou abort possa ser criada, mas não ambas [6], [9]. Embora abordagens de ambos os tipos tenham sido propostas na literatura científica, elas não têm uma implementação publicamente disponível [5], [6], [9], ou são limitadas em seu escopo de aplicação, por exemplo, criando ativos garantidos em outra blockchain. [11] ou trocas de token [8]. Num desenvolvimento separado, surgiram várias plataformas blockchain que permitem a interoperabilidade por padrão, por exemplo, Cosmos e Polkadot. No entanto, essas plataformas suportam apenas a interoperabilidade entre suas próprias subcadeias ou exigem alterações intrusivas nas blockchains existentes. Isto motiva a necessidade de uma estrutura de interoperabilidade geral e prática que possa ser interligada às plataformas blockchain existentes sem modificá-las. Nosso objetivo é fornecer tal estrutura. : Apresentamos PIECHAIN para atingir esse objetivo. Como a sincronia é difícil de assumir na prática, o PIECHAIN utiliza serviços cross-chain para substituir o TTP. Os serviços cross-chain se comunicam usando um log de eventos que usa o protocolo Kafka do Apache para maior eficiência. Para demonstrar a relevância prática do PIECHAIN, implementamos um serviço cross-chain para um estudo de caso realista: um leilão cross-chain. Fizemos a interface do PIECHAIN com algumas das plataformas blockchain mais populares que suportam contratos inteligentes: Ethereum, Hyperledger Fabric e Quorum. Finalmente, desenvolvemos uma GUI para nosso estudo de caso. O estudo de caso do leilão é um dos três estudos de caso (dois leilões e um empréstimo instantâneo [6]) cujo código pode ser encontrado no repositório de código PIEChain no GitHub. Contribuições e novidades II. VISÃO GERAL DO PIECHAIN A. Entidades As principais entidades em PIECHAIN são as seguintes (ver também Figura 1): Blockchains, que armazenam ativos (por exemplo, tokens, chaves) que são mantidos pelos usuários. Um usuário pode manter ativos em vários blockchains. Cada blockchain tem seu próprio protocolo para determinar quem tem acesso de leitura e gravação – blockchains normalmente são permitidos, ou seja, um conjunto fixo de nós tem acesso de leitura e gravação, ou sem permissão, ou seja, todos têm acesso de leitura e podem criar transações, e nós com poder suficiente (por exemplo, velocidade de processamento) pode adicionar transações ao blockchain. Serviços cross-chain (CC-SVCs), que permitem aos usuários trocar ativos em diferentes blockchains. Cada CC-SVC consiste em um servidor que interage com os clientes dos usuários para facilitar a comunicação entre cadeias. Na prática, o CC-SVC cobra a participação dos usuários e pode interagir com qualquer número de blockchains. A seguir, cada CC-SVC corresponde a um conjunto de eventos envolvidos em uma troca atômica de ativos que são enviados por um servidor para o razão Kafka. Na prática, um único servidor pode operar vários CC-SVCs. A rede Kafka, que serve como um log somente anexado de eventos gerados pelos CC-SVCs. Os eventos correspondem a transações feitas em blockchains subjacentes. A rede Kafka é operada por um conjunto fixo de nós que cobram dos CCSVCs pelo upload de eventos. No PIECHAIN, assumimos que os CC-SVCs são semiconfiáveis e que são motivados a se comportar honestamente por terem uma reputação a defender, semelhante aos prestadores de serviços comerciais terceirizados. Os operadores da rede Kafka não são confiáveis, mas não têm incentivos para se comportarem mal, pois não interagem com os blockchains subjacentes. Isso nos permite executar um protocolo (Kafka) que prioriza a eficiência em relação à segurança. Um projeto alternativo é tornar os CC-SVCs não confiáveis e a rede Kafka confiável. Neste caso, cada nó Kafka executa um cliente (leve) para cada uma das blockchains subjacentes para validar a inclusão de transações nessas cadeias. Neste caso, o log de eventos teria que utilizar um protocolo mais seguro como o PBFT [2]. Deixamos tal projeto como trabalho futuro. B. Fluxo do Processo Dadas as entidades da Seção II-A, o fluxo do processo em PIECHAIN tem a mesma estrutura das negociações entre cadeias propostas por Herlihy et al. [6]. Os acordos entre cadeias são acordos entre vários usuários para trocar ativos em diferentes blockchains e consistem em cinco fases (veja também a Figura 2): Fase de compensação: o CC-SVC cria os contratos inteligentes nos diferentes blockchains que são usados para garantir e transferir os ativos envolvidos no negócio. Fase de garantia: os usuários garantem seus ativos de saída, transferindo-os para contratos inteligentes. Fase de transferência: os ativos são trocados provisoriamente, ou seja, a lógica de execução dos contratos inteligentes é especificada. Fase de validação: cada usuário verifica se o resultado da lógica de execução seria satisfatório para ele. Fase de compromisso: o acordo é concluído através do compromisso, se todas as partes estiverem satisfeitas, ou através do aborto, caso contrário. Compromisso significa que a lógica de execução nos contratos inteligentes é executada e que os ativos são trocados conforme especificado no negócio. O aborto significa que os ativos de cada contrato inteligente são devolvidos aos seus proprietários originais. Para confirmar, os usuários constroem interativamente um voto de confirmação, que é enviado pelo CC-SVC ao livro-razão Kafka. Para cancelar, um único usuário envia uma mensagem de cancelamento para o CC-SVC. Para cada CC-SVC, uma mensagem de confirmação ou de cancelamento pode ser adicionada ao razão Kafka, mas não ambas. Uma prova de inclusão de um voto de confirmação no livro-razão Kafka é aceita por todos os contratos inteligentes nas diferentes blockchains – isso garante que, uma vez construído um voto de confirmação, todas as transferências de ativos podem ser executadas ou nenhuma. III. IMPLEMENTAÇÃO DO PIECHAIN Para ilustrar a aplicabilidade prática do PIECHAIN, nós o conectamos a várias plataformas blockchain comumente usadas e o usamos para implementar uma aplicação da literatura científica [6]: um leilão entre cadeias para um ativo digital. O suporte do blockchain se estende a outros estudos de caso, conforme discutimos na Seção V. A. Suporte Blockchain Para fazer a interface de um blockchain subjacente com o PIECHAIN, os CC-SVCs devem ser capazes de validar transações nessas cadeias. Nossa implementação suporta as seguintes plataformas blockchain: Ethereum (ambas as versões Proof-of-Work e Proof-ofAuthority do Ethereum privado), Hyperledger Fabric e Quorum. Os dois últimos suportam blockchains autorizados, enquanto o Ethereum tem uma cadeia principal sem permissão, mas também suporta cadeias privadas com a mesma funcionalidade. B. Leilão Em nosso estudo de caso, um leiloeiro vende um ativo em uma blockchain e recebe o pagamento na forma de ativos em outra blockchain. Tal como em [6], utilizamos o exemplo de um vendedor de bilhetes. O bilhete é um NFT em uma blockchain dedicada, enquanto a outra blockchain suporta tokens fungíveis mais comumente usados (por exemplo, Ether). O primeiro blockchain é chamado de blockchain de tickets e o último de blockchain de moedas. Isso é facilmente generalizado para configurações com mais de um blockchain de moedas. A seguir, consideramos um leilão de primeiro preço (ou seja, o licitante com o lance mais alto paga seu lance e recebe o ativo). As cinco fases do protocolo são então as seguintes: O leiloeiro contrata um CC-SVC que cria contratos inteligentes na blockchain do bilhete e na blockchain da moeda. O leiloeiro transfere seu ativo (o NFT do bilhete) para o contrato do bilhete, e os licitantes transferem seus lances para o contrato em seu blockchain de moedas. A lógica de execução é determinada: o leiloeiro atualiza cada um dos contratos de bilhetes e moedas, especificando qual parte recebe o bilhete e qual lance é transferido para o leiloeiro. (Observe que esta lógica não pode ser especificada a priori no contrato do bilhete porque o contrato na cadeia do bilhete não pode ler dados dos blockchains de moedas.) Cada usuário (ou seja, o leiloeiro e os licitantes) determina se o resultado do protocolo de transferência é aceitável para eles, ou seja, se o bilhete é de fato transferido para a parte correta. Todos os usuários constroem um voto de confirmação – uma vez construído, ele é enviado a cada contrato para decretar as transferências especificadas na fase de transferência. No PIECHAIN, o leilão requer dois tipos (lógicos) de CC-SVC: o retransmissor e o assinante. O retransmissor escuta eventos (ofertas) nas cadeias de moedas e os retransmite para o blockchain do ticket. O signatário auxilia na criação do voto de confirmação. 4. PLANO DE DEMONSTRAÇÃO Para nossa demonstração, desenvolvemos uma interface gráfica de usuário (GUI) usando a estrutura React para ilustrar um leilão entre cadeias. A GUI consiste em três páginas principais: uma página de painel que exibe uma lista de leilões conhecidos, conforme ilustrado na Figura 3, uma visualização detalhada de leilões individuais, conforme ilustrado na Figura 5, e uma página para a criação de novos leilões (não exibida). A visão é a mesma para um leiloeiro e para os licitantes. Na visualização do painel, os possíveis leiloeiros podem clicar no botão “Criar novo leilão” para iniciar um leilão – o leiloeiro seleciona um CC-SVC, o ativo a ser leiloado, de quais outras blockchains aceitar lances, a taxa de câmbio dos tokens entre diferentes blockchains (que devem ser fixadas antecipadamente) e o momento em que o leilão é concluído. Em seguida, o relé CC-SVC cria os contratos relevantes e envia o endereço do contrato na cadeia de ativos ao leiloeiro. O leiloeiro pode então adicionar o leilão em seu painel adicionando o endereço do contrato e clicando no botão “Adicionar Leilão Existente”. Enquanto isso, anuncia o endereço do contrato aos potenciais licitantes. Quando os licitantes tomam conhecimento do endereço do contrato do ativo, eles também podem adicioná-lo aos seus painéis. Após o licitante adicionar o leilão, ele poderá visualizá-lo com mais detalhes pressionando o botão “Visualizar” no painel do leilão, que o levará à página de visualização detalhada. Nesta página, o licitante pode visualizar informações cruciais sobre o leilão, como os prazos de criação e conclusão, além de uma lista de lances. O lance mais alto está marcado com um asterisco. Se o leilão ainda estiver em andamento, o licitante poderá adicionar um lance especificando o blockchain em que a licitação é feita e a quantidade de tokens a licitar. Uma transação é então feita para o contrato de moeda relevante e a informação é enviada para o relé CC-SVC. Um usuário também pode cancelar quaisquer lances que tenha feito por meio do CC-SVC. Após a conclusão do leilão, o relé CC-SVC informa todos os participantes e especifica a tentativa de transferência de mercadorias nos contratos inteligentes. O CC-SVC então pede a todos os clientes dos participantes que participem na criação de um voto de confirmação. (A não participação deverá resultar em penalidade [4].) Quando o voto de confirmação for criado, ele será enviado a todos os contratos para iniciar a transferência final de ativos. Neste ponto, a GUI mostrará que o leilão foi concluído. O fluxo exato da demonstração será o seguinte: Um usuário – o leiloeiro – abre uma GUI baseada em navegador da web e a utiliza para iniciar um leilão para um ativo selecionado. Neste processo são demonstradas todas as funcionalidades da página de criação do leilão. O ativo existe em uma cadeia de tickets dedicada em execução no Hyperledger Fabric. Os contratos são criados em todas as blockchains envolvidas (etapa 1 da Figura 2. Pelo menos dois outros usuários, que usam janelas de navegador em máquinas diferentes, navegam até a página de detalhes do leilão recém-criado e enviam seus lances individuais para o ativo (etapa 2 da Figura 2). Pelo menos um licitante usa Ethereum (privado) e o outro usa Quorum. Após algum tempo, o leilão é concluído e o lance vencedor é determinado (etapa 3 da Figura 2). Isso fará com que um evento de “leilão final” seja enviado ao retransmissor CCSVC pelo leiloeiro. Os signatários, que estão atentos a esse tipo de evento, perceberão o evento e construirão uma votação de commit (etapa 4 da Figura 2). O voto de confirmação é então enviado ao Kafka e encaminhado pelo nó de retransmissão para o contrato de leilão e os contratos da cadeia de moedas. Neste ponto, o bem é transferido para o licitante vencedor, e o lance vencedor para o leiloeiro (etapa 5 da Figura 2). Ao longo da demonstração, usaremos uma janela de terminal para consultar os estados dos blockchains subjacentes após cada etapa, conforme exibido na Figura 4. Isso permitirá que o público observe as mudanças que acontecem em segundo plano e interaja com o fluxo do demonstração: por exemplo, solicitando novas ações para ver como os estados de fundo mudam. Para ilustrar o fluxo da demonstração, um vídeo pode ser encontrado online 2 que mostra os slides provisórios da demonstração e a tela caso o leiloeiro e os licitantes executassem suas ações usando um único computador. (Esta não é uma limitação do PIECHAIN, mas facilita a gravação de vídeo.) V. EXTENSÕES A estrutura CC-SVC e a interface para os blockchains suportados podem ser usadas para estender facilmente o PIECHAIN a outros casos de uso. Um deles é um empréstimo rápido entre cadeias, conforme descrito em [6]. Uma GUI para empréstimos rápidos teria relevância prática limitada, uma vez que as oportunidades de arbitragem são normalmente resolvidas rapidamente, de modo que as interações com o CC-SVC normalmente seriam feitas por bots de negociação. No entanto, se o tempo permitir, exibiremos uma visualização do impacto das etapas de um empréstimo rápido nos estados dos diversos contratos envolvidos. REFERÊNCIAS [1] Rafael Belchior, André Vasconcelos, S´ergio Guerreiro, e Miguel´ Correia. Uma pesquisa sobre interoperabilidade de blockchain: tendências passadas, presentes e futuras. Pesquisas de Computação ACM (CSUR), 2021. [2] Miguel Castro e Bárbara Liskov. Tolerância prática a falhas bizantinas. Em OsDI, volume 99, páginas 173–186, 1999. [3] CoinLore. https://www.coinlore.com/all moedas, 2023. [4] Daniel Engel, Maurice Herlihy e Yingjie Xue. O fracasso é (literalmente) uma opção: Compromisso atômico versus opcionalidade nas finanças descentralizadas. Em SSS 2021, 2021. [5] Maurício Herlihy. Swaps atômicos de cadeia cruzada. Em ACM PODC, páginas 245–254, 2018. [6] Maurice Herlihy, Barbara Liskov e Liuba Shrira. Acordos entre cadeias e comércio adversário. Revista VLDB, 2021. [7] Satoshi Nakamoto. Bitcoin: um sistema de dinheiro eletrônico peer-to-peer, 2008. [8] Sri Aravinda, Krishnan Thyagarajan, Giulio Malavolta e Pedro Moreno-Sanchez. Trocas atômicas universais: troca segura de moedas em todos os blockchains. Em IEEE S&P, 2022. [9] Victor Zakhary, Divyakant Agrawal e Amr El Abbadi. Compromisso atômico entre blockchains. Anais do Fundo VLDB, 13(9), 2021. [10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias e William J Knottenbelt. SoK: Comunicação entre livros distribuídos. Em criptografia financeira, 2021. [11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais e William Knottenbelt. Xclaim: Ativos confiáveis, interoperáveis e apoiados por criptomoedas. Em IEEE S&P, 2019. Este artigo está sob licença CC 4.0. disponível no arxiv