Sidechains federados são a implementação de sidechain atualizável original do Bitcoin PlatoBlockchain Data Intelligence. Pesquisa Vertical. Ai.

Sidechains federados são a implementação de sidechain atualizável original do Bitcoin

Este é um editorial de opinião de Shinobi, um educador autodidata no espaço Bitcoin e host de podcast Bitcoin orientado para tecnologia.

Cadeias laterais federadas são atualmente o único tipo implantado de sidechain Bitcoin (o artigo mais recente SUA PARTICIPAÇÃO FAZ A DIFERENÇA). A ideia de usar um sistema federado de indexação e consenso era na verdade um apêndice no white paper sobre sidechains originais. Não havia nenhum projeto concreto para qualquer tipo de indexação bidirecional envolvendo mineradores, então uma indexação federada foi descrita como uma forma de implantar uma cadeia lateral agora e atualizar para uma indexação verificada bidirecional usando provas de verificação de pagamento simples (SPV) semelhantes a o que cadeias macias fazer, quando algo foi concretamente projetado que era seguro e implantável. Também foi apontado que, em termos de incentivos, para sistemas muito pequenos, pode ser perigoso usar uma indexação baseada em mineradores, pois eles poderiam roubar de um grupo muito pequeno de pessoas sem muito consenso sobre fazer algo a respeito no sistema Bitcoin mais amplo. . As federações podem ser úteis para sistemas menores, onde o grupo de usuários não é grande o suficiente para desincentivar os mineradores a roubar moedas.

A ideia geral é efetivamente ter uma blockchain onde um grupo selecionado de partes confiáveis ​​custódia o bitcoin atrelado ao sistema usando multisig e produza os blocos na sidechain, assinando-os com chaves criptográficas em vez de usar prova de trabalho. Todo o modelo de segurança baseia-se em ter um conjunto decentemente grande de participantes distintos no grupo, ou federação, que estão muito distribuídos geograficamente e são conhecidos publicamente.

As federações usam um limite de membros tanto para a custódia do bitcoin na cadeia principal quanto para a assinatura de bloco, ou seja, um multisig 5 de 7. Isto é feito em vez de exigir que todos os sete membros assinem, a fim de equilibrar os dois principais riscos de tal sistema: roubo versus perda. A federação em conjunto pode roubar todos os fundos bloqueados numa sidechain federada se decidirem cooperar para o fazer; é por isso que todo o modelo de segurança se baseia em muitos intervenientes diferentes em muitas jurisdições legais diferentes. Você quer que seja extremamente difícil e improvável que muitos governos diferentes cooperem para forçar uma federação a fazer algo malicioso, então você quer que um grande número de pessoas seja necessário para assinar as coisas. Por outro lado, se você exigir que todos os sete membros assinem tudo, basta que um único membro perca o acesso às suas chaves, resultando na perda permanente de todos os fundos na sidechain. Exige, portanto, que a maioria dos membros assine, mas não todos. Isto deixa alguma margem de erro para perdas importantes, ao mesmo tempo que ainda exige que um elevado número de membros sejam coagidos ou conspirem para resultar num roubo de fundos.

Isto torna o modelo de segurança do sistema bidirecional em termos de limites de segurança. Conforme afirmado anteriormente, para que os fundos sejam ativamente roubados, cinco dos sete participantes nesta situação hipotética devem conspirar ou ser coagidos a conspirar para roubar os fundos da cadeia lateral. No entanto, apenas três dos sete participantes devem perder, destruir ou ser coagidos a desativar as suas chaves, a fim de deixar os fundos da sidechain congelados e incapazes de serem movidos – possivelmente permanentemente. Os limiares constituem um ato de equilíbrio entre estes dois riscos.

Ambos precisam simultaneamente ser altos o suficiente para tornar improvável a ocorrência de ambos os piores casos.

Além dessas propriedades principais, há um grande grau de liberdade em como você pode implementar uma cadeia lateral federada, tanto em termos de como projetar a cadeia lateral em si quanto de como lidar com o gerenciamento de chaves para assinatura de bloco e chaves de custódia de fixação.

Líquido

Liquid foi a primeira sidechain federada implantada no Bitcoin, projetada para transações privadas entre bolsas para negociação e emissão de outros ativos, como stablecoins ou tokens de ações. Sua base de código é construída quase inteiramente sobre o próprio Bitcoin. Uma das principais características da rede Liquid foi a implementação de Transações confidenciais, um recurso que usa provas de intervalo criptográfico para ocultar os valores enviados nas transações, mas ainda fornece uma garantia, sob certas suposições, de que nenhum dinheiro que não exista está sendo gasto. Liquid também implementado Ativos Confidenciais, uma extensão para Transações Confidenciais. Os Ativos Confidenciais ocultam qual token está sendo gasto, além do valor.

Esses dois recursos combinados fornecem uma solução sólida para uma das grandes deficiências possíveis de uma cadeia lateral federada: a censura. Uma maioria limite (em nossa hipotética federação 5 de 7 acima) poderia concordar em censurar transações específicas ou UTXOs se todos tivessem motivos para isso, como atividades ilegais suspeitas ou confirmadas. Nesse caso, teriam até um incentivo racional para o fazer, para não dar aos governos uma razão para perseguirem todo o sistema. Transações/Ativos Confidenciais podem fornecer um nível de privacidade alto o suficiente para que, mesmo que uma federação tenha motivos para censurar certos tipos de transações, ela teria muita dificuldade em selecioná-los para fazê-lo.

Uma transação peg-in no Liquid é um processo relativamente simples de duas etapas. Um usuário que deseja fazer o peg-in pega o endereço multisig da federação e então “ajusta” cada chave pública envolvida nele usando pagamento por contrato com um endereço Liquid que eles controlam, para criar novas chaves públicas. Os membros da federação podem derivar as chaves privadas correspondentes assim que aprenderem o endereço Liquid usado. Até que essa informação seja revelada, ninguém, nem mesmo a federação, sabe que uma transação para este endereço ajustado é uma indexação líquida. Em seguida, o usuário transmite a transação na mainchain e aguarda 100 confirmações. Uma vez acumuladas as confirmações, o usuário pode enviar uma transação na rede Liquid para enviar suas moedas para si mesmo. Esta transação usa uma entrada especial que contém o endereço Liquid com o qual eles ajustaram as chaves da federação, uma assinatura provando que eles a controlam e uma prova Merkle mostrando que a transação peg-in da cadeia principal tem pelo menos 100 confirmações.

O processo de fixação é muito mais simples. Um usuário constrói uma transação que queima bitcoin no Liquid usando OP_RETURN, contém um endereço para enviar na mainchain e uma prova especial de conhecimento zero de um dos membros da federação (qual deles está oculto). Quando os membros da federação virem tal transação com uma prova de membro válida, eles assinarão um saque na cadeia principal. A prova é implementada para evitar saques fraudulentos ou inválidos e permite que qualquer membro da federação que forneça a prova aplique listas de permissões ou restrições a peg-outs. Qualquer pessoa pode vincular livremente o bitcoin à rede Liquid, mas é necessário um relacionamento com um membro da federação para a vinculação.

Em termos de gerenciamento de chaves e manuseio de segurança, a Blockstream desenvolveu Módulos de Segurança de Hardware (HSMs) para lidar com as chaves e realizar operações de assinatura. Esses dispositivos protegem as chaves usadas para assinatura de bloco e peg-ins/outs, mantendo-as protegidas contra adulteração ou extração de chaves. A fim de fornecer alguns meios de recuperação no caso de dispositivos com falha perderem chaves, mas também para proteger contra a extração de chaves para fins maliciosos, os backups de cada chave de membro são mantidos criptografados de forma a exigir que tanto esse membro quanto a Blockstream cooperem para descriptografar a chave para carregar em um novo HSM. Nenhuma das partes pode descriptografar o backup por conta própria. Uma última linha de defesa contra a perda de chaves são as chaves de Retirada de Emergência. Cada endereço para o qual a federação varre moedas indexadas tem dois caminhos de gastos: o limite exigido da federação e, após aproximadamente um mês de bloqueio de tempo (embora o período de tempo possa ser alterado), o limite exigido das chaves de emergência. Trata-se de um segundo conjunto de chaves que pode ser mantido pela federação, por outra parte ou por uma combinação delas para garantir que as moedas possam ser recuperadas caso muitas chaves da federação sejam perdidas. A federação move regularmente as moedas na cadeia principal sob sua custódia antes que o timelock expire, portanto, desde que a federação não tenha falhado, esse caminho de emergência nunca poderá ser gasto. Atualmente a Blockstream mantém as chaves de recuperação distribuídas geograficamente.

Por último, existe uma funcionalidade chamada “Federações Dinâmicas”. Isto permite que uma grande maioria da federação atualize a filiação, adicionando ou removendo membros. Isso é feito por meio de uma atualização de software do software de assinatura, após decidir quais novos membros adicionar ou quais membros existentes remover e, em seguida, um período de sinalização de um mês. Se, durante um mês, quatro quintos dos blocos sinalizarem para a mudança de federação, a rede “bifurca-se” para reconhecer a nova federação como signatária do bloco. A rede então começa a usar novos endereços de peg-in com a nova federação, mas ainda reconhece os antigos por mais um mês para garantir que nenhum peg-ins seja invalidado durante a mudança de federação. Também não é permitido retirar tantos membros da federação a ponto de não sobrar o suficiente para assinar saques em endereços antigos. Todos esses aspectos das atualizações da federação fazem parte das regras de consenso e são aplicados/validados pelos HSMs.

Porta-enxerto (RSK)

Rootstock é uma cadeia lateral federada com muitas diferenças de design em relação ao Liquid. Em primeiro lugar, é essencialmente um clone copiar e colar do Ethereum em termos de funcionalidade. Ele oferece suporte total ao Solidity, a linguagem de script usada pelo Ethereum, de modo que qualquer contrato implantado no Ethereum seja trivialmente portável para o Rootstock. A justificativa para fazer isso é obviamente que o Ethereum tem muita demanda e pode fornecer funcionalidades que o Bitcoin não é capaz. Obviamente, existem muitas desvantagens e riscos na arquitetura do Ethereum, mas não se pode negar que há demanda por ela.

Outra grande diferença em termos de arquitetura é o que a federação faz – eles gerenciam coletivamente um multisig que custodia os fundos na cadeia principal, mas a federação não participa, em circunstâncias normais, na cunhagem de blocos. Isso é feito pelos mineradores de Bitcoin por meio da mineração combinada, permitindo-lhes extrair Bitcoin e Rootstock ao mesmo tempo. Embora isso não forneça nenhuma diferença de segurança significativa para o Bitcoin vinculado à cadeia Rootstock, fornece alguma diferença para outros ativos emitidos na cadeia lateral. A federação sempre pode roubar o Bitcoin na cadeia principal se houver conluio suficiente, mas como os mineradores realmente exploram a cadeia lateral, ela pode continuar e permitir que outros ativos continuem sendo transacionados. Se esses outros ativos tiverem valor suficiente, mesmo sem serem respaldados por bitcoin real, o token Rootstock BTC ainda deverá ter demanda de mercado suficiente para pagar taxas de utilização de outros ativos para incentivar os mineradores a continuarem a minerar.

No entanto, o envolvimento dos mineiros não é absoluto. Enquanto a maioria dos mineradores de Bitcoin também estiver minerando Rootstock, eles terão controle total sobre a organização das transações e a mineração em blocos, mas se essa porcentagem de mineradores cair para metade (ou um pouco menos), existem regras de consenso que permitem a federação assine pontos de verificação evitando reorganizações antes do ponto de verificação. Se a taxa de hash cair mais drasticamente do que isso, eles serão capazes de assumir o controle como blocksigners, como os membros da federação da Liquid. É um sistema muito dinâmico que pode funcionar tanto sem mineradores quanto sem a federação, a fim de manter o progresso do blockchain.

O processo de peg-in é muito simples: envie bitcoin para o endereço de peg-in RSK e aguarde confirmações suficientes. Depois que confirmações suficientes forem acumuladas, um contrato inteligente Solidity na sidechain reconhecerá a transação e creditará-a em uma conta na sidechain controlada pela mesma chave na qual o UTXO que você vinculou estava bloqueado. A pegging-out também é controlada por um contrato inteligente, que se comunicará com os HSMs da federação, que assinarão uma transação de retirada da cadeia principal quando solicitado pelo contrato.

Quando Roostock foi lançado pela primeira vez, tudo o que era necessário para a fixação era a maioria dos HSMs da federação assinando a transação após serem instruídos pelo contrato inteligente na cadeia lateral. Em 2020, eles implementaram um novo mecanismo de fixação chamado POWPeg. Esta atualização permitiu que os HSMs realmente validassem as provas SPV dos mineradores. Os HSMs agora se recusam a assinar transações de peg-out, a menos que a maioria do conjunto atual de mineradores RSK aproveite a transação desde o início da peg-out. Em última análise, o modelo de segurança se resume a que os HSMs permaneçam seguros, mas, a menos que a maioria deles seja adulterada e as chaves extraídas, eles não assinarão sem uma Prova de Trabalho suficiente que ateste as ligações.

Fechar

As pessoas têm trabalhado no projeto de cadeias laterais há oito anos e enquanto nós se foi através de quatro designs diferentes (e há mais alguns por aí: estes são apenas os que ganharam força com os Bitcoiners técnicos), não há nada implantado atualmente, exceto cadeias federadas. Os sistemas federados podem não ser a cadeia lateral sem confiança que muitas pessoas desejam, mas ainda são sistemas muito úteis — especialmente em qualquer contexto onde a única maneira de atender a uma demanda do mercado é confiar em um único custodiante para arbitrar algo. As federações tornam-se imediatamente uma melhoria padrão ao distribuir o risco da contraparte a vários jogadores.

Bem, em poucas palavras, isso são cadeias laterais federadas. A última peça a seguir aborda todas as desvantagens e pontos negativos das principais propostas atuais, pelo menos algumas reflexões de alto nível sobre o que as pessoas realmente desejam de uma cadeia lateral “perfeita” e como potencialmente conseguir isso.

Este é um post convidado por Shinobi. As opiniões expressas são inteiramente próprias e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.

Carimbo de hora:

Mais de Bitcoin Magazine