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 por 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 carregar o índice de armazenamento e o hash de dados da DA para a cadeia Bitcoin para acesso público.

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

· Em relação à verificação de status, B^2 adota uma abordagem de verificação híbrida para validar provas ZK off-chain e aproveita o conceito bitVM para desafiar traços 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, este processo de verificação de status é essencialmente híbrido na natureza;

·De acordo com o roadmap 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 Layer 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 apoiar vários cenários, prevê-se que o desenvolvimento de uma camada de expansão funcional off-chain se torne uma prática prevalente dentro do ecossistema Layer 2.

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

O ecossistema atual do Bitcoin assemelha-se a um vasto campo de oportunidades e riscos, onde o rescaldo do Verão das Inscrições deu nova vida a este domínio, semelhante a um solo fértil e intocado com o aroma da riqueza pairando no ar. A chegada do Bitcoin Layer 2 no início deste ano transformou esta paisagem outrora desolada num centro de aspirações para inúmeros visionários.

Voltando ao cerne da questão: a definição da Camada 2 continua a ser um ponto de discórdia entre os indivíduos. É uma side chain? Um indexador? A expressão Camada 2 abrange correntes que estabelecem conexões? Pode um simples plug-in dependente do Bitcoin e do Ethereum qualificar-se como uma Camada? Estas perguntas assemelham-se a equações não resolvidas sem uma solução definitiva.

De acordo com as perspetivas 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 de segunda camada. A segurança em si engloba 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 à rede Bitcoin, não é intrinsecamente propícia para apoiar 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 de 6,8 KB/s, aproximadamente 1/20 da capacidade do Ethereum. Consequentemente, o espaço de bloco congestionado resulta em custos elevados para a publicação de dados.

(O custo de publicação de dados num bloco Bitcoin pode até alcançar $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 capacidade de processamento ou baixas taxas de transação. Para lidar com isso, uma abordagem é comprimir significativamente os dados antes de enviá-los para o bloco do Bitcoin. A Citrea atualmente emprega este método, afirmando que irá enviar as alterações de estado (diferencial de estado) que ocorrem em várias contas para a cadeia do Bitcoin, acompanhadas pelos 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 baixada da rede principal do Bitcoin enquanto mantém dados leves na cadeia.

(O antigo documento técnico do Polygon Hermez explica o princípio do esquema de compressão acima mencionado)

Apesar da significativa compressão do tamanho dos dados alcançada por este método, pode encontrar gargalos em cenários onde numerosas transações levam a alterações de estado em muitas contas dentro de um curto período. Embora mais leve do que o envio direto de dados de transações individuais, o envio 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 Celestia. Em contraste, o B^2 implementa uma abordagem diferente, estabelecendo uma rede de Disponibilidade de Dados (DA) diretamente sob a cadeia, conhecida como B^2 Hub. Neste design, dados cruciais como dados de transações ou diferenças de estado são armazenados fora da cadeia, sendo apenas os seus índices de armazenamento e hashes de dados (referidos como dados para simplificação) carregados para a rede principal do Bitcoin.

Estes hashes de dados e índices de armazenamento são registados na cadeia Bitcoin, semelhante a inscrições. Ao executar um nó Bitcoin, os indivíduos podem aceder localmente ao hash de dados e ao índice de armazenamento. Usando o valor do índice, 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 DA em relação ao hash correspondente na cadeia Bitcoin. Esta abordagem direta permite que as soluções de Camada 2 mitiguem a dependência na mainnet do Bitcoin para questões de DA, reduzam os custos de transação e atinjam alta taxa de transferência.

No entanto, é crucial reconhecer que plataformas DA de terceiros sob a cadeia podem envolver-se 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 maneira diferente, com o objetivo comum de disseminar dados rapidamente e amplamente para evitar que alguns nós selecionados 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 à rede Celestia. Os produtores de blocos da Celestia organizarão esses fragmentos de dados na forma de Árvore de Merkle, colocá-los em blocos TIA e transmiti-los para a rede. Validador/nó completo.

Uma vez que existem muitos dados e os blocos são relativamente grandes, a maioria das pessoas não consegue suportar 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 a última roadmap da B^2 Network, a sua solução DA inspira-se na Celestia. Sob este design, os fornecedores de dados externos fornecem continuamente dados à rede Celestia. Os produtores de blocos dentro da Celestia organizam estes fragmentos de dados numa estrutura de Árvore de Merkle, incorporam-nos em blocos TIA e disseminam-nos para os validadores e nós completos da rede. Devido ao volume substancial de dados e aos grandes tamanhos de bloco, muitas pessoas optam por executar nós leves em vez de nós completos. Os nós leves sincronizam apenas os cabeçalhos de bloco que contêm 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 folha específicos dos nós completos. Os nós completos fornecem os nós folha solicitados juntamente com as 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 multiplicidade de nós leves que se envolvem na amostragem de dados de alta frequência a partir de vários nós completos. Esses nós leves selecionam aleatoriamente fragmentos de dados específicos da Árvore de Merkle e os disseminam rapidamente e eficientemente para outros nós conectados, com o objetivo de distribuir dados para uma ampla audiência de pessoas e dispositivos. Esta 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 provedores de dados. Este objetivo fundamental ressalta a essência central da Disponibilidade de Dados (DA) e da distribuição de dados.

No entanto, apesar da eficácia da solução mencionada anteriormente em permitir um 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 num 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, não podem restaurar o conjunto de dados completo que “deveria estar incluído”. (Nota: A palavra “deveria” é importante aqui).

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

No contexto delineado acima, compreender a disponibilidade de dados refere-se a saber se os dados de transações dentro de um bloco estão completos, acessíveis e prontamente partilháveis para fins de verificação. Contrariamente à perceção comum, a disponibilidade não denota apenas a acessibilidade de dados históricos de blockchain para entidades externas. Assim, os funcionários da Celestia e os fundadores da L2BEAT defendem a mudança de nome da disponibilidade de dados para “libertação de dados”, significando a publicação de um conjunto abrangente e acessível de transações dentro de um bloco.

Para lidar com o problema dos ataques de retenção de dados, o 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, os indivíduos 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 torna-se inviável. É de salientar que a presença excessiva de dados inúteis num bloco pode ser prontamente identificada pelos nós leves, atuando como um impedimento contra atividades maliciosas por parte dos produtores de bloco.

Ao implementar esta solução, Celestia mitiga eficazmente a retenção de dados na sua plataforma de distribuição de dados. A rede B^2 planeia utilizar a metodologia de amostragem de dados da Celestia como ponto de referência fundamental no futuro, potencialmente integrando tecnologias criptográficas como o compromisso KZG para melhorar 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 acima aborda a retenção de dados dentro da própria plataforma DA, na infraestrutura Layer 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 camada DA.

Em casos em que surgem anomalias dentro de um lote gerado pelo Sequenciador, existe o risco de retenção de dados ou outras atividades maliciosas. Como tal, ao receber o lote, a rede DA do B^2 Hub verifica meticulosamente os seus conteúdos 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 à CKB no protocolo RGB++.

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

De acordo com o último roadmap tecnológico da rede B^2, uma vez que o B^2 Hub recebe e verifica um lote, ele o retém por um período específico antes de expirar e removê-lo do nó local. Para abordar preocupações de obsolescência e perda de dados 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, os indivíduos dificilmente operarão um nó de armazenamento B^2 sem uma razão convincente. Para incentivar mais participantes a executar nós de armazenamento e melhorar a confiança da rede, é necessário estabelecer um mecanismo de incentivo. 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 os nós de armazenamento forneçam certificados de armazenamento como evidência para demonstrar que realmente armazenaram dados de forma segura dentro de um prazo especificado. No entanto, este método de prova de armazenamento envolve a geração de provas ZK, que são computacionalmente intensivas e colocam exigências significativas de hardware nos nós de armazenamento, potencialmente tornando-o economicamente inviável.

No último roteiro de tecnologia da B^2 Network, os nós de armazenamento implementarão um mecanismo semelhante ao Arweave, competindo pela oportunidade de produzir blocos para ganhar incentivos de token. Se um nó de armazenamento deletar dados secretamente, sua probabilidade de se tornar o próximo produtor de blocos diminui. Os 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 iremos aprofundar no seu mecanismo de verificação de estado. O termo "esquema de verificação de estado" refere-se 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 de Estado refere-se ao esquema de verificação de estado)

Como 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 da Camada 2, novos dados são originados pelo sequenciador. Esta entidade consolida e processa transações iniciadas pelo utilizador juntamente com as alterações de estado resultantes após a execução. Estas modificações são agrupadas em lotes e disseminadas para vários nós dentro da rede de Camada 2, abrangendo nós completos padrão da Camada 2 e nós do B^2 Hub.

Após a receção dos dados do lote, o nó Hub B^2 analisa meticulosamente e verifica o seu conteúdo, abrangendo a anteriormente mencionada "verificação de estado." Essencialmente, a verificação de estado implica validar a precisão das "alterações de estado após a execução da transação" documentadas no lote gerado pelo sequenciador. Qualquer estado erróneo dentro de um lote provoca a rejeição pelo nó Hub B^2.

Atuando 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 de Lote enviados pelo sequenciador, espelhando um processo semelhante ao Celestia. Nós externos frequentemente solicitam fragmentos de dados do nó B^2 Hub, facilitando a distribuição de dados de Lote para inúmeros dispositivos de nó, incluindo a rede de armazenamento mencionada anteriormente.

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

Certamente, é evidente que no processo supramencionado, B^2 Hub, encarregado de validar transições de estado da Camada 2, opera de forma independente da rede principal do Bitcoin, servindo apenas como uma camada de verificação fora da cadeia. Como resultado, o esquema de verificação de estado da Camada 2 neste momento não consegue igualar a 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 em falta de capacidades diretas de verificação de prova ZK, nenhuma solução da Camada 2 no Bitcoin pode rivalizar com o modelo de segurança do Ethereum, particularmente aquelas que empregam técnicas ZK Rollup como Citrea e BOB.

Até agora, a abordagem mais viável, conforme elucidado no white paper do BitVM, envolve descarregar processos computacionais complexos da cadeia Bitcoin. Apenas cálculos essenciais são migrados para a cadeia quando necessário. Por exemplo, os traços de computação gerados durante a verificação de prova de conhecimento zero (ZK) podem ser publicamente divulgados e compartilhados com entidades externas para escrutínio. Se surgirem discrepâncias em etapas de cálculo intrincadas, indivíduos podem verificar esses cálculos controversos na cadeia 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 esforço possa exigir esforços significativos de engenharia, permanece um empreendimento 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 outra VM)

Na solução técnica da rede B^2, uma vez que o sequenciador gera um novo lote, este é 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 transfere-o para o nó B^2 Hub compatível com a EVM. A Prova ZK é autenticada através de um contrato Solidity, com todos os processos computacionais decompostos em circuitos de lógica de baixo nível intricados. Estes circuitos são codificados na linguagem de script do Bitcoin, formatados e submetidos a uma plataforma de Disponibilidade de Dados (DA) de terceiros com capacidade de processamento adequada.

Se os indivíduos questionarem os vestígios de verificação ZK divulgados e suspeitarem de um erro num passo específico, têm a opção de emitir um “desafio” na cadeia Bitcoin. Este desafio faz com que o nó Bitcoin analise diretamente o passo contestado e aplique as consequências apropriadas, se necessário.

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

Então quem é punido? Na verdade, é o Committer. No âmbito da Rede B^2, o Committer não só transmite o hash de dados previamente mencionado para a cadeia Bitcoin, mas também divulga o "compromisso" de verificação do certificado ZK à rede principal do Bitcoin. Através de configurações específicas do Bitcoin Taproot, as pessoas mantêm a capacidade de fazer perguntas 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 “compromisso”, significa que os indivíduos afirmam a precisão de certos dados off-chain e publicam uma declaração correspondente na blockchain. Esta declaração serve como um “compromisso” onde os valores prometidos 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 Committer, têm a opção de desafiá-lo.

Pode-se questionar por que o B^2 Hub precisa verificar o certificado ZK "repetidamente e de forma abrangente" se ele já valida o lote após o recebimento. Por que não divulgar o processo de verificação de lote publicamente para desafios diretos em vez de introduzir a prova ZK? A inclusão da prova ZK serve para condensar os traços de cálculo em um tamanho mais gerenciável antes da liberação. Revelar publicamente o processo de verificação envolvendo transações de Camada 2 e mudanças de estado em portas lógicas e scripts Bitcoin resultaria em tamanho de dados substancial. ZKization efetivamente comprime 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 verificadora do DA e verificador da B^2 (Hub B^2).

3. O nó Hub B^2 verifica se a Prova ZK do agregador está alinhada com o Lote do Sequenciador. A correspondência bem-sucedida indica passagem de verificação. O hash de dados do Lote verificado e o índice de armazenamento são transmitidos à cadeia Bitcoin por um nó Hub B^2 designado (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 submetido à cadeia Bitcoin para possíveis desafios. Um desafio bem-sucedido resulta em penalidades econômicas para o nó emissor B^2 Hub (o seu UTXO na cadeia Bitcoin é desbloqueado e transferido para o desafiante).

Esta abordagem de verificação de estado da Rede B^2 integra metodologias ZK e à prova de fraude, constituindo um método de verificação de estado híbrido. Com pelo menos um nó honesto na cadeia disposto a desafiar ao detetar 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 uma potencial bifurcação futura da mainnet do Bitcoin para suportar capacidades computacionais aprimoradas. Isso poderia abrir caminho para a verificação direta de prova ZK na cadeia do Bitcoin, anunciando mudanças transformadoras para todo o panorama da Camada 2 do Bitcoin. Servindo como uma camada de verificação e DA fundamental, o B^2 Hub não só funciona como um componente central da Rede B^2, mas também capacita outras camadas secundárias do Bitcoin. No competitivo cenário das soluções de 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 deste panorama em evolução.

Aviso legal:

1. Este artigo foi reproduzido a partir de [Geek Web3) com o título original 'Análise do novo roadmap de tecnologia B^2: a necessidade da camada DA e de verificação sob a cadeia Bitcoin.' Os direitos autorais são atribuídos ao autor original, Faust da Geek Web3. Se houver objeções à reimpressão, entre em contato com o Equipe de Aprendizado da Gatepara rápida resolução 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 constituem aconselhamento de investimento.

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