Escrito por: Pesquisa de Chakra

Além da solução de expansão nativa mencionada no primeiro volume, outro caminho de expansão para Bitcoin usa uma camada adicional de protocolo sobre o Bitcoin, chamada Camada 2. Os dois pontos mais críticos da solução da Camada 2 são a ponte bidirecional segura e a herança da segurança de consenso do Bitcoin.

Cadeia lateral

A origem do conceito de sidechain pode ser rastreada até "Enabling Blockchain Innovations with Pegged Sidechain" apresentado pela blockStream em 2014. É um plano de expansão relativamente simples.

princípio de trabalho

A cadeia lateral é uma blockchain que opera de forma totalmente independente da cadeia principal. Possui seu próprio protocolo de consenso e pode ser usada como campo experimental para inovação da cadeia principal. Quando ocorre um incidente maligno na cadeia lateral, o dano é completamente limitado à própria cadeia lateral e não tem impacto na cadeia principal. A cadeia lateral pode usar um protocolo de consenso TPS mais alto para aumentar as capacidades de programação na cadeia e alcançar o aprimoramento do BTC.

A cadeia lateral pode realizar a transferência de Bitcoin entre diferentes blockchains por meio de peg bidirecional ou unidirecional. É claro que, na verdade, o BTC só pode permanecer na rede Bitcoin, então precisamos de um mecanismo de ancoragem para fazer a cadeia lateral. O BTC na cadeia está conectado ao BTC na rede Bitcoin.

A indexação unidirecional exige que os usuários enviem BTC na rede principal para um endereço indisponível para destruição e, em seguida, o número correspondente de BTC será obtido na cadeia lateral, mas o processo não pode ser revertido. A indexação bidirecional é uma atualização adicional da indexação unilateral, permitindo que o BTC se mova para frente e para trás entre a cadeia principal e as cadeias laterais. Em vez de enviá-lo para um endereço indisponível para destruição, a indexação bidirecional bloqueará o BTC por meio de scripts de controle, como assinaturas múltiplas e cunhará novos BTC na cadeia lateral. Quando o usuário quiser retornar à rede principal, o BTC da cadeia lateral será queimado e o BTC originalmente bloqueado será liberado na rede principal.

A implementação da indexação unidirecional é muito mais simples do que a indexação bidirecional, porque não há necessidade de gerenciar o estado relevante na rede Bitcoin, mas os ativos da cadeia lateral gerados por meio da indexação unilateral podem ser inúteis devido ao falta de mecanismo de ancoragem reversa.

Existem diferentes soluções e diferentes níveis de segurança para a verificação de transações de bloqueio na cadeia principal e de transações de destruição na cadeia lateral. O mais simples é usar a verificação externa por participantes com múltiplas assinaturas, mas o risco de centralização é alto. Uma opção melhor é usar o SPV Proof para obter uma verificação descentralizada. É claro que, como a rede principal do Bitcoin não possui os recursos de programação necessários, a verificação SPV não pode ser realizada e outros métodos só podem ser escolhidos, geralmente a custódia com múltiplas assinaturas.

Perguntas e ideias

Existem dois problemas principais pelos quais as cadeias laterais são criticadas:

A dependência dos ativos entre cadeias dos verificadores: Como a rede principal do Bitcoin ainda não é capaz de implementar contratos inteligentes, a transferência de ativos entre cadeias não pode ser processada por meio de uma lógica de contrato sem confiança. necessidade de contar com um grupo de verificadores Para completar a operação, há uma suposição de confiança e há risco de fraude.

A cadeia lateral não pode herdar a segurança da cadeia principal: A cadeia lateral funciona de forma completamente independente da rede principal e não pode herdar a segurança da rede principal. Podem ocorrer eventos como reorganização maliciosa de blocos.

A este respeito, as ideias de cadeias laterais incluem confiança na autoridade (tipo aliança), confiança na segurança económica (PoS), confiança em mineiros Bitcoin descentralizados (Merged Mining), dependência em módulos de segurança de hardware (HSM), custódia de fundos e cadeia lateral no Bitcoin. Diferentes funções podem ser responsáveis ​​pela produção de blocos da cadeia, introduzindo assim mecanismos de segurança mais complexos.

Introdução de caso

Líquido

A primeira forma de cadeia lateral é a cadeia lateral de aliança, na qual múltiplas entidades previamente selecionadas servem como verificadores e são responsáveis ​​pela custódia dos principais fundos da rede e pela produção de blocos da cadeia lateral.

Liquid é o representante da cadeia lateral da aliança, com 15 participantes atuando como verificadores. O método de gerenciamento de chave privada não é divulgado e 11 assinaturas são necessárias para verificação. Os blocos da cadeia lateral Liquid também são mantidos em conjunto por 15 participantes. A cadeia de aliança com um baixo número de nós pode atingir TPS mais elevado e atingir metas de expansão.

A abordagem da cadeia lateral da aliança apresenta riscos de segurança centralizados significativos.

Porta-enxerto (RSK)

A RSK também possui 15 nós que servem como custodiantes de fundos da rede principal e apenas 8 assinaturas são necessárias para verificação. A diferença do Liquid é que a chave de assinatura múltipla é gerenciada pelo módulo de segurança de hardware HSM, e a instrução de peg-out é assinada de acordo com o consenso PoW para evitar que o verificador que possui a chave manipule diretamente os fundos de garantia.

Em termos de consenso da cadeia lateral, a RSK usa o Merged Mining para usar o poder de computação da rede principal para garantir a segurança das transações na cadeia lateral. Quando a proporção do poder de computação da mineração mesclada na rede principal é alta, ela pode prevenir melhor o lado. cadeia seja comprometida. A RSK fez melhorias na Merged Mining para garantir a segurança das cadeias laterais sob baixas taxas de hash. Ela adota um método de reconhecimento de bifurcação para realizar uma intervenção de consenso fora da cadeia no comportamento da bifurcação e reduzir a probabilidade de gastos duplos.

No entanto, a Merged Mining altera os incentivos dos mineiros e intensifica os riscos do MEV, o que pode, em última instância, desestabilizar o sistema. No longo prazo, a Mineração Fundida poderá aumentar a centralização da mineração.

Pilhas

Stacks ancora a história da cadeia Stacks ao Bitcoin, enviando o hash do bloco da cadeia lateral ao bloco Bitcoin. Ele tem a mesma finalidade do Bitcoin. O fork do Stacks só pode ser causado pelo fork do Bitcoin. resistir ao gasto duplo.

sBTC apresenta um novo token STX e um modelo de incentivo, usando uma abordagem de staking bridge que permite até 150 validadores de mainnet. Na chamada ponte de staking, os validadores precisam apostar tokens STX para obter permissão para aprovar depósitos e retiradas. A segurança da ponte de penhor depende fortemente do valor dos ativos penhorados. Quando o valor dos ativos penhorados flutua violentamente, a segurança da cadeia cruzada do BTC é facilmente danificada. Se o valor dos activos prometidos for inferior ao valor dos activos cross-chain, o validador tem um incentivo para fazer o mal.

Existem também algumas propostas de sidechain que estão sendo amplamente discutidas na comunidade.

Corrente de transmissão

Aquele que atraiu mais atenção é o Drivechain proposto por Paul Sztorc em 2015. As principais tecnologias do plano foram atribuídas ao BIP 300 (mecanismo peg) e ao BIP 301 (mineração cega mesclada). O BIP 300 define detalhadamente a lógica de adição de uma nova cadeia lateral. A ativação de uma nova cadeia lateral é semelhante à ativação de um soft fork por meio de sinais de mineradores. O BIP 301 permite que mineradores de Bitcoin se tornem produtores de blocos sidechain sem verificar o conteúdo específico da transação.

Os mineradores de Bitcoin também são responsáveis ​​por aprovar as transações de retirada. Os mineradores primeiro precisam criar uma saída OP_RETURN na transação coinbase do bloco que mineraram para propor uma transação de retirada. pode votar a favor ou contra a proposta a qualquer momento. Assim que uma transação de retirada excede o limite (13.150 blocos), a transação de retirada é oficialmente executada e confirmada pela cadeia principal do Bitcoin.

Na verdade, os mineradores têm controle total sobre os fundos no Drivechain. Se os fundos forem roubados, os usuários só poderão se salvar por meio do UASF (soft fork ativado pelo usuário), mas é muito difícil chegar a um consenso. Além disso, a posição única dos mineiros no Drivechain agrava os riscos do MEV, como já foi demonstrado no Ethereum.

Cadeia espacial

A Spacechain adotou uma abordagem diferente, usando a indexação perpétua de 1 via (P1WP). Os usuários queimam BTC para obter tokens na Spacechain, ignorando diretamente a questão da segurança do fundo. Este token só pode ser usado para leiloar espaço de bloco na cadeia espacial e não possui nenhuma função de armazenamento de valor.

Para garantir a segurança da cadeia lateral, o Spacechain adota a mineração de fusão cega. Outros usuários usam ANYPREVOUT (APO) para licitar publicamente para competir pelo direito de construir blocos. cadeia lateral. No entanto, o lançamento do Spacechain requer o apoio do Covanent, e a comunidade Bitcoin ainda está discutindo a necessidade de um soft fork para adicionar o opcode do Covanent.

Em geral, o Spacechain pode realizar uma cadeia lateral com as mesmas propriedades de descentralização e resistência à censura do Bitcoin e mais programabilidade através da função de licitação de blocos no Bitcoin.

Cadeia macia

Softchain é uma proposta de cadeia lateral 2wp proposta pelo autor do Spacechain, Ruben Somsen. Ela usa o mecanismo de consenso PoW FP para garantir a segurança da cadeia lateral. Em circunstâncias normais, o nó completo do Bitcoin só precisa baixar o cabeçalho do bloco do softchain e verificar a prova de trabalho. Quando ocorrer uma bifurcação, baixe o bloco órfão e o compromisso do conjunto UTXO correspondente para verificar a validade do bloco.

Para o mecanismo 2wp, durante a peg-in, uma transação de depósito é criada na cadeia principal, e a transação da cadeia principal é referenciada na softchain para obter fundos durante a peg-out, uma transação de retirada é criada na softchain, e a transação de retirada é criada na softchain; a transação é referenciada na cadeia principal para recuperar fundos BTC, e o processo de retirada precisa esperar por um longo período de desafio antes de ser concluído. Os mecanismos específicos de peg-in e peg-out requerem suporte de soft fork, por isso a solução é chamada Softchain.

A solução Softchain impõe custos adicionais de verificação nos nós completos da rede principal do Bitcoin. A divisão de consenso da Softchain pode afetar a obtenção do consenso da rede principal e se tornar um possível meio de ataque à rede principal do Bitcoin.

Rede relâmpago

A Lightning Network lançou um white paper em 2015 e foi lançada oficialmente em 2018. Como um protocolo de pagamento p2p de camada 2 no Bitcoin, ele visa transferir um grande número de transações de pequena quantidade e alta frequência para processamento fora da cadeia. há muito tempo, é considerada a tecnologia mais avançada da rede Bitcoin.

módulo principal

A implementação da Lightning Network é indissociável de vários módulos importantes no Bitcoin, que juntos garantem a segurança das transações da Lightning Network.

A primeira é a transação pré-assinada. As transações pré-assinadas só se tornaram seguras e disponíveis após a atualização do SegWit. O SegWit separa assinaturas do restante dos dados da transação, resolvendo problemas como possíveis dependências circulares, adulteração de transações de terceiros e adulteração de transações de terceiros. A segurança da computação na cadeia Lightning Network é garantida pelo compromisso irrevogável da outra parte, e esse compromisso é concretizado por meio de transações pré-assinadas. Após receber a transação pré-assinada dada pela outra parte, o usuário pode transmitir a transação para a rede a qualquer momento para completar o cumprimento da promessa.

O segundo é a assinatura múltipla. As transferências frequentes de fundos fora da cadeia entre duas partes exigem uma transportadora. Esta transportadora exige que ambas as partes mantenham certos direitos de controle, portanto, são necessárias assinaturas múltiplas. Geralmente, são usadas assinaturas múltiplas 2/2, o que garante a transferência de fundos. deve ser realizado com o consentimento mútuo de ambas as partes.

Porém, a assinatura múltipla 2/2 causará problemas de vivacidade, ou seja, se a outra parte não cooperar, o usuário não poderá transferir nenhum ativo do endereço de assinatura múltipla, resultando na perda dos fundos originais. Os bloqueios de tempo podem resolver o problema de vitalidade. Ao pré-assinar um contrato com um bloqueio de tempo para devolver os fundos, pode-se garantir que, mesmo que uma parte fique inativa, a outra parte possa recuperar os fundos iniciais.

Finalmente, existe o hash lock, que pode conectar vários canais de status e construir uma rede. A imagem original do hash será usada como meio de comunicação para coordenar o correto funcionamento de múltiplas entidades.

Executar processo

canal bidirecional

Ambas as partes que usam a Lightning Network para realizar transações primeiro precisam abrir um canal de pagamento bidirecional no Bitcoin. Ambas as partes podem realizar qualquer número de transações fora da cadeia. Depois que todas as transações forem concluídas, o status mais recente será enviado à cadeia Bitcoin. para concluir a liquidação e fechar o corredor de pagamento.

Especificamente, a implementação de canais de pagamento envolve as seguintes etapas principais:

  1. Crie um endereço com várias assinaturas. Ambas as partes do canal precisam primeiro criar um endereço com múltiplas assinaturas 2 de 2 como o endereço de bloqueio de fundos do canal. Cada parte possui uma chave privada de assinatura e fornece sua própria chave pública.

  2. Inicialize o canal. Ambas as partes transmitem uma transação na cadeia e bloqueiam uma certa quantidade de Bitcoin no endereço de múltiplas assinaturas como os fundos iniciais do canal. Esta transação é chamada de transação “âncora” do canal.

  3. Atualizar o status do canal. Ao efetuar um pagamento dentro do canal, ambas as partes atualizam o status do canal trocando transações pré-assinadas. Cada atualização gerará uma nova “transação de compromisso”, representando o status atual da alocação de fundos. A transação de compromisso tem duas saídas, correspondentes às cotas de fundos de ambas as partes.

  4. Transmita o status mais recente. Qualquer uma das partes do canal pode transmitir a última transação de compromisso para o blockchain a qualquer momento para retirar sua parte dos fundos. Para evitar que a outra parte transmita o status antigo, cada transação de compromisso tem uma "transação de punição" correspondente. Se a outra parte trapacear, você poderá obter todos os fundos da outra parte.

  5. Feche o canal. Quando duas partes decidem fechar um canal, elas podem cooperar para gerar uma “transação de liquidação” que transmite o status final de distribuição de fundos para o blockchain. Dessa forma, os fundos bloqueados no endereço com múltiplas assinaturas são liberados de volta para os endereços pessoais de ambas as partes.

  6. Arbitragem em cadeia. Se as duas partes não conseguirem chegar a um acordo ao fechar o canal, qualquer uma das partes poderá transmitir unilateralmente a última transação de compromisso e iniciar o processo de arbitragem em cadeia. Se não houver objeções dentro de um determinado período de tempo (como 1 dia), os fundos serão enviados a ambas as partes de acordo com a alocação da transação comprometida.

rede de pagamento

Os canais de pagamento podem ser conectados entre si para formar uma rede, suportando roteamento multi-hop, implementado através de HTLC. O HTLC usa bloqueio de hash como condição direta e pagamento de assinatura com bloqueio de tempo como condição de backup. Os usuários podem interagir em torno da imagem original com hash antes que o bloqueio de tempo expire.

Quando não existe um canal direto entre dois usuários, o pagamento pode ser concluído com a ajuda de HTLC entre roteadores. A pré-imagem hash R desempenha um papel fundamental em todo o processo, garantindo a atomicidade do pagamento. Ao mesmo tempo, o bloqueio de tempo do HTLC está definido para diminuir ao longo do caminho, garantindo que cada salto tenha tempo suficiente para processar e encaminhar o pagamento.

Problemas

Em essência, a Lightning Network contorna a suposição de confiança externa de ponte de ativos por meio de canais de estado p2p, enquanto usa scripts de bloqueio de tempo para fornecer a garantia final de ativos e proteção contra falhas. Quando a outra parte perde actividade e não coopera, a retirada unilateral pode ser concluída. Portanto, a Lightning Network tem alto valor em cenários de pagamento, mas também possui muitas limitações, incluindo:

  • Limite de capacidade do canal. A capacidade do canal de pagamento na Lightning Network é limitada pelos fundos inicialmente bloqueados e não pode suportar grandes pagamentos que excedam a capacidade do canal. Isto pode limitar certos cenários de aplicação, como o comércio de mercadorias.

  • On-line e sincronizado. Para receber e encaminhar pagamentos em tempo hábil, os nós da Lightning Network precisam permanecer online. Se um nó ficar off-line por um longo período, ele poderá perder algumas atualizações de status do canal, fazendo com que o status fique fora de sincronia. Isto pode ser um desafio para usuários individuais e dispositivos móveis e também aumenta o custo das operações dos nós.

  • Gestão de liquidez. A eficiência de roteamento da Lightning Network depende da distribuição de liquidez dos canais. Se os fundos forem distribuídos de forma desigual, algumas formas de pagamento poderão falhar, afetando a experiência do usuário. A gestão do equilíbrio de liquidez do canal exige determinados custos técnicos e de capital.

  • Violação de privacidade. Para encontrar caminhos de pagamento disponíveis, o algoritmo de roteamento da Lightning Network requer algum nível de conhecimento da capacidade do canal e das informações de conectividade. Isto pode revelar a privacidade de alguns utilizadores, tais como distribuição de fundos, contrapartes, etc. A abertura e o fechamento de canais de pagamento também podem expor informações sobre participantes relevantes.

RGB

A ideia original do protocolo RGB foi inspirada na verificação do lado do cliente e nos conceitos de vedação única propostos por Peter Todd. Foi proposto por Giacomo Zucco em 2016. É um protocolo Bitcoin de segunda camada escalonável e que preserva a privacidade. .

idéia principal

Validação do cliente

O processo de verificação do blockchain consiste em transmitir os blocos compostos por transações para todos, permitindo que cada nó calcule as transações do bloco e conclua a verificação. Na verdade, isso cria um bem público, ou seja, nós em toda a rede ajudam cada indivíduo que envia uma transação a concluir a verificação, e os usuários fornecem BTC como uma taxa de manuseio como um incentivo para ajudar na verificação. A verificação do lado do cliente é mais centrada no indivíduo. A verificação do estado não é realizada globalmente, mas é verificada por indivíduos que participam de transições de estado específicas. Somente as partes que geram a transação verificam a validade da transição de estado. a carga sobre os nós e melhora a escalabilidade.

Selo descartável

Existe um perigo oculto na transição de estado ponto a ponto. Se os usuários não conseguirem coletar o histórico completo de transição de estado, eles poderão ser fraudados e gastar o dobro. A vedação descartável é proposta para resolver este problema. Utiliza um objeto especial que só pode ser usado uma vez para garantir que não ocorram gastos duplos e melhorar a segurança. O UTXO do Bitcoin é o objeto selado único mais adequado, garantido pelo mecanismo de consenso do Bitcoin e pelo poder de computação de toda a rede, para que os ativos RGB possam herdar a segurança do Bitcoin.

Promessa criptográfica

O selo único precisa ser combinado com o compromisso de criptografia para garantir que o usuário conheça a transição de estado e evitar a ocorrência de ataques de gasto duplo. O chamado compromisso é informar aos outros que algo aconteceu e não pode ser modificado posteriormente, mas não há necessidade de expor eventos específicos até o momento em que a verificação for necessária. Podemos usar uma função hash para fazer um compromisso. No RGB, o conteúdo do compromisso é a transição de estado. Através do gasto do UTXO, o destinatário do ativo RGB receberá o sinal de transferência de estado e, em seguida, verificará o compromisso em relação aos dados específicos transmitidos fora da cadeia pelo gastador do. ativo.

processo de trabalho

RGB usa o consenso do Bitcoin para garantir segurança contra gastos duplos e resistência à censura, e toda verificação de transferências de estado é transferida para fora da cadeia e verificada apenas pelo cliente que aceita o pagamento.

Para o emissor de ativos RGB, um contrato RGB precisa ser criado iniciando uma transação, e o comprometimento das informações específicas será armazenado no script OP_RETURN de uma determinada condição de gasto na transação Taproot.

Quando o detentor de um ativo RGB deseja gastar, ele precisa obter informações relevantes do destinatário do ativo, criar uma transação RGB, confirmar os detalhes da transação RGB e colocar o valor do compromisso no UTXO especificado pelo destinatário do ativo , e emita uma transação que gasta o UTXO original e cria o UTXO especificado pelo receptor. Quando o destinatário do ativo observa que o UTXO que originalmente armazenou o ativo RGB está gasto, ele pode verificar a validade da transação RGB por meio do compromisso na transação Bitcoin. Uma vez válida a verificação, ele acredita que de fato recebeu o ativo. Ativo RGB.

Para o destinatário dos ativos RGB, o pagador precisa fornecer o estado inicial e as regras de transição de estado do contrato, as transações Bitcoin usadas para cada transferência, as transações RGB cometidas por cada troca de Bitcoin e a validade de cada transação Bitcoin. verificado pelo cliente do destinatário com base nesses dados, verifica a validade da transação RGB. Entre eles, o UTXO do Bitcoin é usado como contêiner para salvar o estado do contrato RGB. O histórico de transferência de cada contrato RGB pode ser expresso como um gráfico acíclico direcionado. O destinatário do ativo RGB só pode obter as informações relacionadas ao RGB. ativo que ele possui histórico e não pode acessar outras filiais.

Vantagens e desvantagens

Verificação leve

Comparado com a verificação completa do blockchain, o protocolo RGB reduz bastante o custo da verificação. Os usuários não precisam percorrer todos os blocos históricos para obter o status mais recente, mas apenas sincronizar os registros históricos relacionados aos ativos que recebem para verificar. a eficácia da transação.

Esta verificação leve facilita as transações peer-to-peer, eliminando ainda mais a necessidade de prestadores de serviços centralizados e aumentando o nível de descentralização.

Escalabilidade

O protocolo RGB herda a segurança do Bitcoin apenas por meio do comprometimento de um hash. Por meio de scripts Taproot, quase não há consumo de espaço adicional na cadeia Bitcoin, o que possibilita uma programabilidade complexa de ativos. Devido ao uso do UTXO como contêiner, o protocolo RGB possui simultaneidade natural. Os ativos RGB em diferentes ramos de transferência não se bloquearão e poderão ser gastos ao mesmo tempo.

Privacidade

Diferente dos protocolos gerais, apenas o destinatário dos ativos RGB pode obter o status histórico da transferência dos ativos RGB. Uma vez concluído o gasto, o status da transferência futura não pode ser obtido, o que garante significativamente a privacidade do usuário. Não há correlação entre a transação de ativos RGB e a transferência de Bitcoin UTXO, e outros não conseguem obter vestígios de transações RGB na cadeia Bitcoin.

Além disso, o RGB também apoia despesas cegas, e o pagador não pode saber em qual UTXO os ativos do RGB serão pagos, melhorando ainda mais a privacidade e aumentando a resistência à censura.

insuficiente

Quando os ativos RGB mudam de mãos muitas vezes, os novos usuários que recebem ativos serão forçados a verificar um longo histórico de transferência, resultando em uma carga de verificação mais pesada, o tempo de verificação pode ser maior e a capacidade de confirmar rapidamente é perdida. Para nós que permanecem em execução no blockchain, como o status mais recente está sempre sincronizado, o tempo para receber a transferência rápida do status de verificação da nova zona é limitado a cada vez.

A comunidade está discutindo a possibilidade de reutilizar cálculos históricos, e o ZK Proof recursivo tem a oportunidade de obter verificação constante do estado de tempo e tamanho.

Rolar

Visão geral

Rollup é a melhor solução de expansão que o ecossistema Ethereum alcançou após anos de exploração, dos canais estaduais ao Plasma e finalmente ao Rollup.

Rollup é um blockchain independente que coleta transações fora da cadeia Bitcoin, empacota múltiplas transações em um lote e as executa, e envia os dados e compromissos de status desse lote para a cadeia principal, realizando processamento fora da cadeia e atualizações de status. Para atingir a expansão máxima, o Rollup normalmente utiliza um sequenciador centralizado nesta fase para melhorar a eficiência de execução sem perder a segurança, pois a segurança é garantida pela verificação das transições de estado do Rollup na cadeia principal.

À medida que a solução Rollup do ecossistema Ethereum amadurece, o ecossistema Bitcoin também começou a experimentar o Rollup. No entanto, a diferença mais crítica entre Bitcoin e Ethereum é a falta de recursos de programação e a incapacidade de realizar os cálculos necessários para construir o Rollup na cadeia. Isso faz com que as pessoas atualmente tentem apenas implementar o Rollup soberano e o OP Rollup.

Classificação

De acordo com os diferentes métodos de verificação de transferência de estado, o Rollup pode ser dividido em duas categorias principais, Rollup Otimista e Rollup de Validade (ZK Rollup).

O Optimistic Rollup adota um método de verificação otimista. Durante o período de disputa após o envio de cada lote de transação, qualquer pessoa pode verificar os dados fora da cadeia, levantar objeções a lotes de transações problemáticos, enviar provas de fraude à cadeia principal e perder o sequenciador. Se não houver prova de fraude válida após o período de disputa, o lote de transações é considerado válido e a atualização do status é confirmada na cadeia principal.

O Validity Rollup usa Validity Proof para concluir a verificação, e o Sequencer usa um algoritmo de prova de conhecimento zero para gerar uma prova de validade concisa para cada lote de transação, provando que a transferência de estado do lote está correta para cada atualização. a cadeia principal prova de validade, a cadeia principal verifica a prova e então entende e confirma a atualização de status.

A vantagem do Optimistic Rollup é que ele é relativamente simples de implementar e requer menos modificações na cadeia principal. Mas tem tempos de confirmação de transação mais longos (dependendo do período de objeção) e exige maior disponibilidade de dados. As transações de Rollup de Validade são confirmadas rapidamente, não dependem de períodos de objeção e os dados da transação podem permanecer privados, mas gerar e verificar provas de conhecimento zero requer alta sobrecarga computacional.

Celestia também propôs o conceito de rollup soberano. Os dados de transação do rollup são publicados em um blockchain dedicado da camada DA, que é responsável pela disponibilidade dos dados, e o próprio rollup soberano é responsável pela execução e liquidação.

Explorar e discutir

O rollup no Bitcoin ainda está em seus estágios iniciais Devido às diferenças entre o modelo de contabilidade e a linguagem de programação e o Ethereum, é difícil copiar diretamente a experiência prática do Ethereum.

Acúmulo de Soberania

Em 5 de março de 2023, o Rollkit foi anunciado como a primeira estrutura para oferecer suporte a rollups soberanos de Bitcoin. Os construtores de rollups soberanos podem publicar dados de disponibilidade em Bitcoin por meio do Rollkit.

Rollkit é inspirado em Ordinals e publica dados por meio de transações Taproot. Uma transação Taproot padrão através do mempool público pode conter até 390 KB de dados, e uma transação Taproot não padrão emitida diretamente por um minerador pode conter quase 4 MB de dados arbitrários.

O trabalho real do Rollkit é fornecer uma interface para o Rollup soberano ler e gravar dados no Bitcoin, fornecer serviços de middleware aos clientes e transformar o Bitcoin em uma camada DA.

A ideia de um rollup soberano foi recebida com muito ceticismo, com muitos oponentes alegando que um rollup soberano no Bitcoin nada mais é do que usar o Bitcoin como um quadro de avisos e completamente incapaz de herdar a segurança do Bitcoin. Na verdade, se você enviar apenas dados de transação para Bitcoin, você só poderá melhorar a vivacidade, ou seja, todos os usuários poderão obter os dados correspondentes para verificação através do Bitcoin, mas a segurança só pode ser definida pelo próprio Rollup soberano e não pode ser herdada. Além disso, o espaço em bloco é valioso no Bitcoin e enviar dados completos da transação pode não ser uma boa decisão.

Rollup de OP e Rollup de Validade

Embora muitos projetos de segunda camada do Bitcoin se autodenominam ZK Rollup, que é essencialmente mais próximo de um OP Rollup, mas envolve a tecnologia Validity Proof no processo, os recursos de programação do Bitcoin ainda não são suficientes para suportar a verificação direta da Validity Proof.

Atualmente, o conjunto de opcodes do Bitcoin é muito limitado e não pode nem calcular diretamente a multiplicação. A verificação da Prova de Validade requer a expansão dos opcodes e também depende fortemente da implementação de contratos recursivos. Os que estão sendo discutidos atualmente na comunidade incluem OP_CAT, OP_CHECKSIG,. OP_TXHASH etc. Claro, se pudéssemos adicionar um OP_VERIFY_ZKP diretamente, talvez não precisaríamos de nenhuma outra modificação, mas isso é obviamente improvável. Além disso, as limitações no tamanho da pilha também dificultam os esforços para verificar a Prova de Validade em scripts Bitcoin, e muitas tentativas estão sendo exploradas.

Então, como funciona a Prova de Validade? A maioria dos projetos publica a declaração e a prova de validade dos lotes de transações para Bitcoin na forma de inscrições e usa BitVM para verificação otimista. O BitVM Bridge substitui a solução tradicional de múltiplas assinaturas aqui. O Bridge Operator formará uma aliança de N pessoas para agendar depósitos de usuários. Antes que os usuários façam um depósito, a aliança deverá pré-assinar o UTXO a ser gerado para garantir que o depósito só possa ser cobrado legalmente pela Operadora. Após obter a pré-assinatura, o BTC será bloqueado para um endereço Taproot com múltiplas assinaturas N/N.

Quando um usuário emite uma solicitação de saque, o Rollup enviará a Prova de Validade com saque Root para a cadeia Bitcoin. A Operadora primeiro atenderá às necessidades de saque do usuário do próprio bolso e depois verificará a validade por meio do contrato BitVM. Se cada Operador acreditar que o certificado é válido, o Operador será reembolsado através de assinatura múltipla, desde que alguém acredite que há fraude, será realizado um processo de contestação e a parte errada será eliminada;

Na verdade, esse processo é igual ao OP Rollup. A suposição de confiança é 1/N. Contanto que um verificador seja honesto, o protocolo é seguro.

No entanto, poderão existir dificuldades na implementação técnica desta solução. No projeto OP Rollup do Ethereum, o Arbitrum foi desenvolvido por muitos anos, e o atual Fraud Proof ainda é submetido por nós autorizados. O Optimism anunciou recentemente que oferece suporte ao Fraud Proof, o que mostra como é difícil de implementar;

Já a operação pré-assinada na ponte BitVM, com o apoio do Bitcoin Covanent, pode ser implementada de forma mais eficiente, o que ainda aguarda consenso da comunidade.

Em termos de atributos de segurança, ao enviar o hash do bloco Rollup ao Bitcoin, obtém-se a resistência à reorganização e ao gasto duplo, e o uso da Ponte Otimista traz uma suposição de segurança 1/N, porém, a resistência à censura da ponte ainda pode. esperar por mais desenvolvimento melhorar.

Conclusão: a camada 2 não é uma panacéia

Observando tantas soluções da Camada 2, podemos facilmente descobrir que cada solução é limitada nas tarefas que pode realizar. Sob certas suposições de confiança, os efeitos que a Camada 2 pode alcançar dependem em grande parte da Camada 1 – isto é, das capacidades nativas do Bitcoin.

Sem atualizações do SegWit e bloqueios de tempo, a Lightning Network não pode ser construída com sucesso sem atualizações do Taproot, os compromissos RGB não podem ser enviados com sucesso sem OP_CAT e outros Covanent, o Validity Rollup no Bitcoin não pode ser construído com sucesso;

Muitos Bitcoin Maxi acreditam que o Bitcoin nunca deve ser alterado e novos recursos não devem ser adicionados. Todos os defeitos devem ser resolvidos pela Camada 2. Isso é impossível. Precisamos de uma Camada 1 mais poderosa para construir uma Camada 2 mais segura, eficiente e escalável.

No próximo artigo, apresentaremos tentativas de melhorar a programabilidade do Bitcoin, portanto, fique atento.