Resumo:

A rede B^2 Network estabeleceu uma camada de Disponibilidade de Dados (DA) conhecida como B^2 Hub dentro da cadeia Bitcoin, inspirando-se nos conceitos da Celestia. Esta rede de camada DA implementa amostragem de dados e codificação de apagamento para garantir a distribuição rápida de novos dados para inúmeros nós externos e para evitar a retenção de dados. Além disso, o Committer dentro da rede B^2 Hub é responsável por enviar o índice de armazenamento e o hash de dados da DA para a cadeia Bitcoin para acesso público.

Para aliviar o fardo dos nós da camada DA, os dados históricos no B^2 Hub não são retidos permanentemente. Consequentemente, B^2 se esforçou para reconstruir uma rede de armazenamento, empregando um mecanismo de incentivo ao armazenamento semelhante ao Arweave para incentivar mais nós a armazenar conjuntos abrangentes de dados históricos em troca de recompensas de armazenamento;

· Em relação à verificação de status, o B^2 adota uma abordagem de verificação híbrida para validar provas ZK off-chain e alavanca o conceito de bitVM para desafiar rastros de verificação de prova ZK on-chain. A segurança da rede B^2 é garantida quando um nó desafiante inicia um desafio ao detectar um erro, alinhando-se com o modelo de confiança do protocolo à prova de fraudes. No entanto, devido à utilização de provas ZK, esse processo de verificação de status é essencialmente híbrido por natureza;

· De acordo com o roteiro futuro da rede B^2, o B^2 Hub compatível com EVM tem o potencial de servir como uma camada de verificação off-chain e camada DA conectando várias soluções de camada 2 do Bitcoin. O objetivo é evoluir para uma camada de expansão funcional off-chain do Bitcoin semelhante ao BTCKB. Dadas as limitações do Bitcoin em suportar vários cenários, o desenvolvimento de uma camada de expansão funcional off-chain é esperado se tornar uma prática prevalente dentro do ecossistema da Camada 2.

B^2 Hub: camada de Disponibilidade de Dados (DA) universal e camada de verificação dentro da cadeia Bitcoin

O ecossistema atual do Bitcoin se assemelha a uma vasta extensão de oportunidades e riscos, onde o rescaldo do Verão das Inscrições trouxe nova vida a este domínio, semelhante a um solo fértil intocado com o odor da riqueza pairando no ar. A chegada da Camada 2 do Bitcoin no início deste ano transformou esta paisagem uma vez desolada em um centro de aspirações para inúmeros visionários.

Retornando ao cerne da questão: a definição da Camada 2 ainda é um ponto de contenda entre os indivíduos. Seria uma side chain? Um indexador? O termo Camada 2 abrange cadeias que estabelecem conexões? Pode um simples plug-in dependente do Bitcoin e do Ethereum qualificar-se como uma Camada? Essas perguntas se assemelham a equações não resolvidas sem uma solução definitiva.

De acordo com as perspectivas das comunidades Ethereum e Celestia, a Camada 2 representa uma instância distinta de uma blockchain modular. Neste contexto, existe uma interdependência próxima entre a chamada 'segunda camada' e 'primeira camada'. A segurança da Camada 1 pode ser parcial ou significativamente herdada pela rede da segunda camada. A segurança em si abrange várias subcategorias, incluindo DA, verificação de status, verificação de retirada, resistência à censura e resistência à reorganização.

Dadas as limitações inerentes da rede Bitcoin, ela não é inerentemente propícia para suportar uma rede abrangente de Camada 2. Por exemplo, em termos de DA, a capacidade de processamento de dados do Bitcoin fica significativamente atrás da do Ethereum. Com um tempo médio de geração de bloco de 10 minutos, a taxa máxima de processamento de dados do Bitcoin é apenas 6,8KB/s, aproximadamente 1/20 da capacidade do Ethereum. Consequentemente, o espaço de bloco congestionado resulta em custos elevados para publicação de dados.

(O custo de publicar dados em um bloco de Bitcoin pode chegar a $5 por KB)

Se a Camada 2 publicar diretamente os dados da transação recém-adicionada no bloco do Bitcoin, não alcançará alta taxa de transferência ou baixas taxas de transação. Para resolver isso, uma abordagem é comprimir significativamente os dados antes de enviá-los para o bloco do Bitcoin. A Citrea atualmente emprega esse método, afirmando que enviará as alterações de estado (dif de estado) ocorridas em várias contas para a cadeia do Bitcoin, acompanhadas por certificados ZK correspondentes ao longo de um período específico.

Isso permite que qualquer pessoa verifique a validade da diferença de estado e ZKP baixados da rede principal do Bitcoin, mantendo dados leves na cadeia.

(O antigo white paper da Polygon Hermez explica o princípio do esquema de compressão acima)

Apesar da compressão significativa do tamanho dos dados obtida por este método, pode encontrar gargalos em cenários em que inúmeras transações resultam em mudanças de status em muitas contas em um curto período de tempo. Embora mais leve do que o carregamento direto de dados de transações individuais, o carregamento de alterações de contas ainda incorre em custos substanciais de liberação de dados.

Como resultado, muitas soluções de Camada 2 do Bitcoin optam por não carregar dados DA para a rede principal do Bitcoin e, em vez disso, utilizam camadas de DA de terceiros como a Celestia. Em contraste, o B^2 implementa uma abordagem diferente ao estabelecer uma rede de Disponibilidade de Dados (DA) diretamente sob a cadeia, conhecida como B^2 Hub. Neste design, dados cruciais como dados de transação ou diferenças de estado são armazenados off-chain, com apenas seus índices de armazenamento e hashes de dados (referidos como dados para simplificação) carregados na mainnet do Bitcoin.

Esses hashes de dados e índices de armazenamento são registrados na cadeia Bitcoin semelhante a inscrições. Ao executar um nó de Bitcoin, indivíduos podem acessar localmente o hash de dados e o índice de armazenamento. Usando o valor do índice, eles podem recuperar os dados originais da camada de armazenamento ou DA off-chain da B^2. O hash de dados permite a verificação da correção dos dados obtidos da camada off-chain de DA em relação ao hash correspondente na cadeia Bitcoin. Essa abordagem direta permite que as soluções de Camada 2 reduzam a dependência na mainnet do Bitcoin para problemas de DA, reduzam os custos de transação e alcancem alta taxa de transferência.

No entanto, é crucial reconhecer que plataformas DA de terceiros sob a cadeia podem se envolver em práticas de retenção de dados, impedindo o acesso externo a novos dados - um fenômeno conhecido como um 'ataque de retenção de dados'. Várias soluções DA abordam essa questão de forma diferente, com o objetivo compartilhado de disseminar dados rapidamente e amplamente para evitar que alguns poucos nós controlem as permissões de acesso aos dados.

De acordo com o novo roteiro oficial da B^2 Network, sua solução DA baseia-se em Celestia. No último design, os provedores de dados de terceiros fornecerão continuamente dados para a rede Celestia. Os produtores de blocos da Celestia organizarão esses fragmentos de dados na forma de Árvore de Merkle, os colocarão nos blocos TIA e os transmitirão para a rede. Validador/nó completo.

Uma vez que há muitos dados e os blocos são relativamente grandes, a maioria das pessoas não consegue arcar com a execução de nós completos e só pode executar nós leves. O nó leve não sincroniza o bloco completo, mas apenas sincroniza um cabeçalho de bloco com a raiz da Árvore de Mekrle escrita nele.

De acordo com o último roteiro da B^2 Network, sua solução DA se inspira na Celestia. Sob este design, os provedores de dados externos fornecem continuamente dados para a rede Celestia. Produtores de blocos dentro da Celestia organizam esses fragmentos de dados em uma estrutura de Árvore de Merkle, incorporam-nos em blocos TIA e os disseminam para os validadores e nós completos da rede. Devido ao volume substancial de dados e tamanhos de bloco grandes, muitos indivíduos optam por executar nós leves em vez de nós completos. Nós leves sincronizam apenas cabeçalhos de bloco contendo a raiz da Árvore de Merkle.

Embora os nós leves não tenham uma visão abrangente da Árvore de Merkle e não possam verificar o novo conteúdo de dados, eles podem solicitar nós de folha específicos dos nós completos. Os nós completos fornecem os nós de folha solicitados juntamente com Provas de Merkle correspondentes para convencer os nós leves de sua existência dentro da Árvore de Merkle do bloco Celestia, garantindo que não sejam dados fabricados.

(Fonte da imagem: W3 Hitchhiker)

Na rede Celestia, existem uma infinidade de nós leves que se envolvem na amostragem de dados em alta frequência de vários nós completos. Esses nós leves selecionam aleatoriamente fragmentos de dados específicos da Árvore de Merkle e os disseminam para outros nós conectados de forma rápida e eficiente, com o objetivo de distribuir dados para uma ampla audiência de pessoas e dispositivos. Essa abordagem facilita a rápida disseminação de dados, garantindo que um número suficiente de nós receba prontamente os dados mais recentes, eliminando assim a necessidade de depender de um grupo limitado de fornecedores de dados. Esse objetivo fundamental destaca a essência central da Disponibilidade de Dados (DA) e distribuição de dados.

No entanto, apesar da eficácia da solução mencionada acima em permitir acesso rápido aos dados, não garante a integridade da fonte de dados. Por exemplo, um produtor de blocos Celestia poderia potencialmente inserir dados errôneos em um bloco, complicando os esforços para reconstruir o conjunto de dados completo e preciso. Mesmo que as pessoas obtenham todos os fragmentos de dados no bloco, elas não podem restaurar o conjunto de dados completo que "deveria ser incluído". (Nota: A palavra "deveria" é importante aqui).

Além disso, em cenários onde certos dados de transação permanecem ocultos para partes externas, reter apenas 1% dos fragmentos de dados pode impedir que terceiros reconstruam todo o conjunto de dados - uma situação que lembra ataques de retenção de dados.

No contexto delineado acima, entender a disponibilidade de dados diz respeito a saber se os dados de transação dentro de um bloco estão completos, acessíveis e prontamente compartilháveis para fins de verificação. Contrariamente à percepção comum, a disponibilidade não denota exclusivamente a acessibilidade dos dados históricos do blockchain para entidades externas. Como tal, os funcionários da Celestia e os fundadores da L2BEAT defendem renomear a disponibilidade de dados como 'liberação de dados', significando a publicação de um conjunto de dados de transação abrangente e acessível dentro de um bloco.

Para resolver o problema dos ataques de retenção de dados, Celestia utiliza codificação de apagamento bidimensional. Se pelo menos 1/4 dos fragmentos de dados (códigos de apagamento) dentro de um bloco forem válidos, as pessoas podem reconstruir o conjunto de dados original. No entanto, se um produtor de bloco inserir 3/4 de fragmentos de dados errôneos, a reconstrução do conjunto de dados se torna inviável. Notavelmente, a presença excessiva de dados inúteis em um bloco pode ser prontamente identificada por nós leves, atuando como um impedimento contra atividades maliciosas por parte dos produtores de bloco.

Ao implementar essa solução, a Celestia mitiga efetivamente a retenção de dados em sua plataforma de distribuição de dados. A rede B^2 planeja utilizar a metodologia de amostragem de dados da Celestia como um ponto de referência fundamental no futuro, potencialmente integrando tecnologias criptográficas como o compromisso KZG para aprimorar a eficiência e confiabilidade dos processos de amostragem e verificação de dados realizados por nós leves.

É crucial reconhecer que, enquanto a solução mencionada aborda a retenção de dados dentro da própria plataforma DA, na infraestrutura da Camada 2, tanto a plataforma DA quanto o Sequenciador possuem capacidades de retenção de dados. Em fluxos de trabalho como o da Rede B^2, o Sequenciador gera novos dados organizando e processando transações de usuários e mudanças de status resultantes em lotes antes de transmiti-los para os nós do B^2 Hub que servem como a camada DA.

Em casos em que surgem anomalias dentro de um lote gerado pelo Sequenciador, há um risco de retenção de dados ou outras atividades maliciosas. Consequentemente, ao receber o lote, a rede DA do B^2 Hub verifica meticulosamente seu conteúdo e rejeita quaisquer lotes problemáticos. Assim, o B^2 Hub não só funciona como uma camada DA semelhante à Celestia, mas também opera como uma camada de verificação off-chain semelhante ao CKB no protocolo RGB++.

(Diagrama de estrutura subjacente da rede B^2 incompleto)

De acordo com o roteiro de tecnologia mais recente da rede B^2, uma vez que o B^2 Hub recebe e verifica um lote, ele o mantém por um período específico antes de expirar e removê-lo do nó local. Para lidar com a obsolescência de dados e preocupações com perda semelhantes ao EIP-4844, a rede B^2 estabelece uma rede de nós de armazenamento encarregados de armazenar permanentemente os dados do lote para facilitar a recuperação de dados históricos quando necessário.

No entanto, é improvável que indivíduos operem um nó de armazenamento B^2 sem um motivo convincente. Para encorajar mais participantes a executar nós de armazenamento e aumentar a confiança da rede, um mecanismo de incentivo deve ser estabelecido. A implementação de tal mecanismo requer medidas para prevenir atividades fraudulentas. Por exemplo, se um sistema de incentivo recompensar indivíduos que armazenam dados localmente em seus dispositivos, há um risco de comportamento desonesto, onde alguém deleta parte dos dados após o download, enquanto afirma falsamente que seus dados armazenados estão completos - uma forma de trapaça muito comum.

O Filecoin emprega protocolos de prova conhecidos como PoRep e PoSt, permitindo que nós de armazenamento forneçam certificados de armazenamento como evidência para demonstrar que eles realmente armazenaram dados de forma segura dentro de um prazo especificado. No entanto, essa abordagem de prova de armazenamento envolve a geração de provas de conhecimento zero (ZK), que são computacionalmente intensivas e impõem demandas significativas de hardware aos nós de armazenamento, potencialmente tornando economicamente inviável.

No mais recente roteiro de tecnologia da Rede B^2, os nós de armazenamento implementarão um mecanismo semelhante ao Arweave, competindo pela oportunidade de produzir blocos para ganhar incentivos de tokens. Se um nó de armazenamento deletar dados secretamente, sua probabilidade de se tornar o próximo produtor de bloco diminui. Nós que preservam a maioria dos dados têm uma chance maior de produzir blocos com sucesso e receber recompensas maiores. Consequentemente, é vantajoso para a maioria dos nós de armazenamento manter o conjunto de dados históricos completo para otimizar suas perspectivas de produção de blocos.

Esquema de verificação de estado misturado com ZK e prova de fraude

Anteriormente, elaboramos sobre a solução de Disponibilidade de Dados (DA) da Rede B^2 e agora vamos aprofundar em seu mecanismo de verificação de estado. O termo 'esquema de verificação de estado' diz respeito a como a Camada 2 garante uma transição de estado suficientemente 'sem confiança'.

(O site L2BEAT avalia os cinco principais indicadores de segurança para Scroll. A Validação do Estado refere-se ao esquema de verificação de estado)

Conforme destacado no site L2BEAT, que avalia os indicadores de segurança para Scroll, a Validação de Estado aborda especificamente o esquema de verificação de estado. Na Rede B^2 e na maioria dos processos de Camada 2, novos dados são originados pelo sequenciador. Essa entidade consolida e processa transações iniciadas pelo usuário juntamente com suas alterações de status resultantes pós-execução. Essas modificações são agrupadas em lotes e disseminadas para vários nós dentro da rede da Camada 2, abrangendo nós completos padrão da Camada 2 e nós do B^2 Hub.

Após a recepção dos dados em lote, o nó do Hub B^2 analisa meticulosamente e verifica seu conteúdo, abrangendo a mencionada anteriormente "verificação de status". Essencialmente, a verificação de estado implica na validação da precisão das "mudanças de estado pós-execução da transação" documentadas no lote gerado pelo sequenciador. Qualquer status errôneo dentro de um lote leva à rejeição pelo nó do Hub B^2.

Funcionando como uma cadeia pública de Prova de Participação (POS), o B^2 Hub distingue entre produtores de blocos e verificadores. Periodicamente, os produtores de blocos do B^2 Hub geram novos blocos e os disseminam para outros nós (validadores). Esses blocos encapsulam dados do Lote submetidos pelo sequenciador, espelhando um processo semelhante ao Celestia. Os nós externos frequentemente solicitam fragmentos de dados do nó B^2 Hub, facilitando a distribuição de dados do Lote para vários dispositivos de nós, incluindo a rede de armazenamento mencionada anteriormente.

Dentro do B^2 Hub opera um papel crucial conhecido como o Comitente. Esta entidade hash os dados do Lote (especificamente a raiz de Merkle), armazena o índice e o submete à cadeia do Bitcoin em forma de inscrição. O acesso ao hash dos dados e ao índice de armazenamento permite a recuperação dos dados completos da camada de armazenamento fora da cadeia DA. Supondo que N nós armazenem dados do Lote sob a cadeia, uma vez que um nó esteja disposto a compartilhar dados com entidades externas, qualquer parte interessada pode acessar os dados necessários. A suposição de confiança neste cenário é 1/N.

Certamente, é evidente que no processo mencionado, B^2 Hub, encarregado de validar transições de estado da Camada 2, opera de forma independente da rede principal do Bitcoin, servindo exclusivamente como uma camada de verificação off-chain. Consequentemente, o esquema de verificação de estado da Camada 2 neste momento não corresponde à confiabilidade da mainnet do Bitcoin.

Em geral, o ZK Rollup tem a capacidade de herdar totalmente a segurança da Camada 1. No entanto, dadas as limitações atuais da cadeia do Bitcoin em suportar apenas cálculos básicos e a falta de capacidades diretas de verificação de prova ZK, nenhuma solução de Camada 2 no Bitcoin pode rivalizar com o modelo de segurança do Ethereum, particularmente aquelas que empregam técnicas de ZK Rollup como Citrea e BOB.

Até agora, a abordagem mais viável, conforme elucidado no white paper do BitVM, envolve a transferência de processos computacionais complexos da cadeia de Bitcoin. Apenas cálculos essenciais são migrados para a cadeia quando necessário. Por exemplo, os rastros de computação gerados durante a verificação de prova ZK podem ser divulgados publicamente e compartilhados com entidades externas para escrutínio. Se surgirem discrepâncias em etapas de cálculo intricadas, indivíduos podem verificar esses cálculos controversos na cadeia de Bitcoin. Isso exige alavancar a linguagem de script do Bitcoin para emular as funcionalidades de máquinas virtuais especializadas, como a Máquina Virtual Ethereum (EVM). Embora esse empreendimento possa exigir esforços de engenharia significativos, continua sendo uma empreitada viável.

Referências:Uma interpretação minimalista do BitVM: Como verificar a prova de fraude na cadeia BTC (executar o código de operação do EVM ou de outro VM)

Na solução técnica da Rede B^2, uma vez que o sequenciador gera um novo lote, ele é transmitido para o agregador e Prover. O Prover então ZK-iza o processo de verificação de dados do lote, produz um certificado ZK e eventualmente o transfere para o nó do B^2 Hub compatível com o EVM. A Prova ZK é autenticada por meio de um contrato Solidity, com todos os processos computacionais decompostos em circuitos de lógica de portas de baixo nível intrincados. Esses circuitos são codificados na linguagem de script do Bitcoin, formatados e enviados a uma plataforma de Disponibilidade de Dados (DA) de terceiros com throughput adequado.

Se os indivíduos questionarem as trilhas de verificação ZK divulgadas e suspeitarem de um erro em uma etapa específica, eles têm a opção de emitir um “desafio” na cadeia Bitcoin. Esse desafio faz com que o nó Bitcoin examine diretamente a etapa contestada e aplique as consequências apropriadas, se necessário.

(O diagrama de estrutura geral da Rede B^2, excluindo os nós de amostragem de dados)

Então, quem é punido? Na verdade, é Committer. Dentro da estrutura da B^2 Network, o Committer não apenas transmite o hash de dados mencionado anteriormente para a cadeia Bitcoin, mas também divulga o "compromisso" de verificação do certificado ZK para a rede principal do Bitcoin. Por meio de configurações específicas do Bitcoin Taproot, os indivíduos mantêm a capacidade de levantar consultas e contestar o "Compromisso de Verificação de Prova ZK" emitido pelo Committer na cadeia Bitcoin a qualquer momento.

Para elaborar sobre o conceito de "comprometimento," ele denota indivíduos que afirmam a precisão de certos dados off-chain e publicam uma declaração correspondente no blockchain. Esta declaração serve como um "comprometimento" onde os valores da promessa estão ligados a dados específicos off-chain. Na solução B^2, se alguma parte questionar o compromisso de verificação ZK emitido pelo Comprometedor, eles têm a opção de desafiá-lo.

Alguém poderia questionar por que o B^2 Hub precisa verificar o certificado ZK "repetidamente e de forma abrangente" se ele já valida o Lote ao recebê-lo. Por que não divulgar publicamente o processo de verificação do lote para desafios diretos em vez de introduzir a prova ZK? A inclusão da prova ZK serve para condensar as trilhas de cálculo em um tamanho mais gerenciável antes da divulgação. Revelar publicamente o processo de verificação envolvendo transações da Camada 2 e alterações de estado em portas lógicas e scripts do Bitcoin resultaria em um tamanho de dados substancial. A ZKização comprime efetivamente esses dados antes da disseminação.

Aqui está um resumo conciso do fluxo de trabalho do B^2:

1. O sequenciador em B^2 gera novos blocos da Camada 2 e consolida vários blocos em lotes de dados. Esses lotes são encaminhados para o agregador e nó Validador na rede do Hub B^2.

2. O agregador envia o lote de dados para o nó Prover, permitindo a criação da prova de conhecimento zero correspondente. Posteriormente, o certificado ZK é transmitido para a rede de verificadores e DA do B^2 (B^2 Hub).

3. O nó do Hub B^2 verifica se a Prova ZK do agregador está alinhada com o Lote do Sequenciador. A correspondência bem-sucedida indica a passagem de verificação. O hash de dados do Lote verificado e o índice de armazenamento são transmitidos para a cadeia Bitcoin por um nó designado do Hub B^2 (Committer).

4. Todo o processo de cálculo para verificar a Prova de Conhecimento Zero é publicamente divulgado pelo B^2 Hub, com o compromisso deste processo sendo submetido à cadeia do Bitcoin para possíveis desafios. Um desafio bem-sucedido resulta em penalidades econômicas para o nó emissor do B^2 Hub (seu UTXO na cadeia do Bitcoin é desbloqueado e transferido para o desafiante).

Esta abordagem de verificação de estado da Rede B^2 integra metodologias ZK e à prova de fraudes, constituindo um método híbrido de verificação de estado. Com pelo menos um nó honesto na cadeia disposto a desafiar ao detectar um erro, é fornecida garantia quanto à integridade da transição de estado da Rede B^2.

De acordo com informações de membros da comunidade Bitcoin ocidental, há especulações sobre um potencial futuro fork da mainnet do Bitcoin para suportar capacidades computacionais aprimoradas. Isso poderia pavimentar o caminho para a verificação direta de provas ZK na cadeia do Bitcoin, anunciando mudanças transformadoras para toda a paisagem da Camada 2 do Bitcoin. Servindo como uma camada de DA e verificação fundamental, o B^2 Hub não apenas funciona como um componente principal da Rede B^2, mas também capacita outras camadas secundárias do Bitcoin. No competitivo cenário das soluções da Camada 2 do Bitcoin, as camadas de expansão funcional off-chain estão ganhando destaque, com o B^2 Hub e o BTCKB representando apenas um vislumbre dessa paisagem em evolução.

Aviso legal:

1. Este artigo foi reproduzido de [Geek Web3 ), com o título original “Análise da nova roadmap de tecnologia B^2: a necessidade da camada de DA e verificação sob a cadeia Bitcoin.” Os direitos autorais são atribuídos ao autor original, Faust da Geek Web3. Se houver alguma objeção à reimpressão, entre em contato com oEquipe de Aprendizado Gatepara uma resolução rápida seguindo os procedimentos relevantes.

2. As perspectivas e opiniões expressas neste artigo refletem exclusivamente os pontos de vista pessoais do autor e não servem como conselho de investimento.

3. As traduções do artigo para outros idiomas são fornecidas pela equipe Gate Learn. Os artigos traduzidos não podem ser copiados, disseminados ou plagiados sem mencionar Gate.io.