Introdução:

O cenário atual do Bitcoin Layer2 está repleto de diversas soluções tecnológicas convergindo no caldeirão do ecossistema BTC. Dado o rápido ritmo de iteração no campo do blockchain, onde o vocabulário profissional e os padrões evoluem continuamente por meio de pesquisa, inovação e implementação de engenharia, muitos projetos recorrem à "criação de conceitos" ou "caronas de conceitos" para diferenciação e atenção, tornando-se uma regra tácita dentro da indústria. Por exemplo, vários projetos modulares de blockchain inicialmente ativos dentro do ecossistema Ethereum/Celestia entraram na onda "Bitcoin Layer2", apelidando-se de "Rollups", apesar de suas soluções técnicas muitas vezes não atenderem aos padrões Rollup. No entanto, o termo "Rollup" carrega um reconhecimento significativo, tornando-o vantajoso para fins promocionais. Muitos operadores de projeto se rotulam como Rollups ou bifurcam o conceito Rollup convencional com qualificadores vagos, como "Sovereign Rollup". Descascando as camadas desses "XX Rollups", muitos projetos são essencialmente baseados em "validação do lado do cliente" ou "sidechains", meramente usando o slogan "XX Rollup" por conveniência. Embora essa estratégia promocional seja comum, ela tende a ser enganosa, causando mais danos do que benefícios a quem busca a verdade.

(Essa abordagem, resumida pelo ministro da Propaganda nazista Goebbels como "propaganda baseada em mentiras", é frequentemente observada entre os operadores do projeto.) Como, então, podemos discernir esse comportamento de "carona do conceito Rollup"? Talvez, começando com os primeiros princípios, a definição de diferentes categorias de projetos Layer2 e seus níveis de segurança e funcionalidades com base em padrões amplamente aceitos no Ocidente e em toda a indústria possa oferecer clareza. Não se trata necessariamente da solução escolhida; o núcleo está em saber se o design do mecanismo do projeto garante a segurança e a confiabilidade da rede Layer2 e realmente capacita a mainnet BTC.

Este artigo usará Chainway, um projeto Bitcoin Layer2, como um estudo de caso para dissecar a natureza de "validação do lado do cliente" escondida por trás de alguns slogans de "Rollup" de projetos. Nosso objetivo é distinguir claramente entre "Sovereign Rollup" e "validação do lado do cliente," e as diferenças significativas dos ZKRollups ou OPRollups padrão da indústria que dependem de contratos inteligentes. Isso não quer dizer que Sovereign Rollups ou validações do lado do cliente sejam inferiores aos ZK Rollups em segurança e confiabilidade; tudo depende dos detalhes específicos de implementação. Chainway, tipicamente uma validação do lado do cliente Layer2, propôs um esquema de transação anti-censura desencadeado no BTC com validação off-chain, empregando Provas ZK recursivas semelhantes às usadas pela cadeia pública MINA, posicionando-a à frente de muitos projetos Bitcoin Layer2. Acreditamos que pesquisar a tecnologia da Chainway é valioso, oferecendo insights significativos para observadores do Bitcoin Layer2. (As imagens promocionais da Chainway a posicionam como um ZK Rollup, mas sua solução antiga era validação do lado do cliente, e o ZKR é outro projeto deles. Atualmente, não alcançou consenso do cliente off-chain ou troca de mensagens confiável.)

Texto Principal: Chainway é um projeto Bitcoin Layer2 bem conhecido na comunidade ocidental, frequentemente referido como um “ZK Rollup” por muitos KOLs, enquanto sua documentação técnica o posiciona como um “Rollup Soberano”. Recentemente, a Chainway também anunciou seu novo projeto, Citrea, alegando ser um ZK Rollup baseado em BitVM. No entanto, como Citrea ainda não detalhou sua solução de verificação ZK baseada em BitVM, este artigo se concentrará na interpretação técnica das soluções anteriores da Chainway. Em resumo, a solução técnica publicamente divulgada pela Chainway envolve a publicação de dados DA através do protocolo Ordinals, usando BTC como sua camada DA, e publicando detalhes de mudança de estado (State diff) + Prova ZK verificando a correção das mudanças de estado na Camada1, equivalente à publicação de dados de transação completos e verificáveis. No entanto, como a Camada1 não verifica diretamente as Provas ZK, com a verificação realizada por clientes/nós independentes fora da cadeia, e a base de código atual da Chainway não alcançou consenso entre clientes fora da cadeia, nem afirmou ter resolvido esse problema nas redes sociais, a solução técnica publicamente divulgada pela Chainway essencialmente pertence à categoria de “validação do lado do cliente”, chegando a se assemelhar a um protocolo criptograficamente indexado que suporta a ponte de ativos. As seções a seguir apresentarão a implementação técnica específica da Chainway e analisarão seu modelo de segurança.

O que é um Sovereign Rollup: Publicação da camada de Disponibilidade de Dados (DA) + Verificação fora da cadeia

Na documentação técnica da Chainway, é usado o conceito de um Sovereign Rollup da Celestia. Um Sovereign Rollup é fundamentalmente diferente do conceito de Rollup mainstream dentro da comunidade Ethereum e da indústria em geral (Rollup de contrato inteligente). Então, qual é exatamente a estrutura de um Sovereign Rollup?

Essencialmente, um Sovereign Rollup baseado no Bitcoin é um tanto semelhante a um “grupo de clientes fora da cadeia/sidechain publicando dados DA na blockchain BTC.” Sua principal característica é que não requer contratos inteligentes na Camada 1 para verificar transições de estado/ações entre cadeias para a Camada 2. Basicamente, ele usa BTC como a camada DA, e seu modelo de segurança é em grande parte semelhante à “validação do lado do cliente.” Claro, algumas soluções mais seguras de Sovereign Rollup dependem de uma camada de liquidação de terceiros fora da cadeia do Bitcoin (semelhante a uma sidechain) para realizar verificações de transições de estado. Além disso, entre diferentes clientes/nós completos independentes, existe um nível de consenso ou passagem de mensagens confiável para alcançar um “acordo” sobre certas ações controversas. No entanto, alguns projetos de Sovereign Rollup são puramente baseados na “validação do lado do cliente,” sem qualquer passagem de mensagens confiável entre clientes/nós independentes.

Para entender melhor o conceito único de "Sovereign Rollup", é útil compará-lo com seu equivalente, o Rollup de contrato inteligente. No Ethereum, as soluções de Camada 2 são predominantemente Rollups de contrato inteligente, como Arbitrum e StarkNet. A estrutura de um Rollup de contrato inteligente pode ser visualizada no diagrama a seguir:

(Imagine um diagrama aqui)

No diagrama, podemos ver vários termos relacionados à narrativa do blockchain modular, explicados da seguinte forma:

• Camada de Execução: Executa transações do usuário, atualiza o estado do blockchain e envia dados para a camada DA e a camada de liquidação.

• Camada de Liquidação: Verifica as transições de estado da camada de execução, resolve disputas (como provas de fraude) e fornece um módulo de ponte para lidar com ativos de ponte L1-L2.

• Camada de Disponibilidade de Dados (DA): Age como um grande quadro de avisos, recebendo dados de transição de estado enviados pela camada de execução e fornecendo esses dados de forma confiável a qualquer pessoa.

• Camada de Consenso: Garante a finalidade da ordenação de transações. Sua função parece ser um tanto próxima à da camada DA (a abordagem da comunidade Ethereum para a estratificação modular de blockchain não inclui uma camada de consenso).
  
  Da arquitetura de Rollups de contratos inteligentes, vemos que o Ethereum assume o papel das últimas três camadas, além da camada de execução. Outro diagrama poderia fornecer uma visão mais detalhada dos papéis que o Ethereum desempenha nos Rollups de contratos inteligentes.
  
  Por outro lado, os Sovereign Rollups diferem significativamente ao descentralizar algumas dessas responsabilidades longe de um blockchain monolítico como o Ethereum. Especificamente, eles não dependem de contratos inteligentes na camada base (Camada 1) para verificar transições de estado ou resolver disputas. Em vez disso, essas tarefas são gerenciadas por clientes off-chain ou por meio de uma camada de liquidação de terceiros, enfatizando uma abordagem diferente para alcançar escalabilidade e segurança em sistemas blockchain.

Os contratos de rollup no Ethereum recebem provas de validade ou provas de fraude para verificar a validade das transições de estado da Camada 2. Vale a pena mencionar que os contratos inteligentes Rollup atuam como as entidades da camada de liquidação na arquitetura modular de blockchain. Os contratos da camada de liquidação geralmente incluem módulos de ponte para lidar com ativos ligados do Ethereum para a Camada 2. Para Disponibilidade de Dados (DA), os contratos da camada de liquidação podem obrigar o Sequencer a lançar os dados de transação/detalhes de alteração de estado mais recentes na cadeia. Sem lançar DA on-chain, é impossível atualizar com êxito o estado L2 registrado nos contratos de Rollup.

(ZK Rollup ou Optimistic Rollup pode garantir que os dados DA sejam postados on-chain; sem isso, o estado registrado na camada de liquidação não pode ser atualizado.) Ao analisar o modelo de segurança e indicadores de risco das soluções de Camada 2 do Bitcoin/Ethereum com a teoria do barril, fica claro que os Rollups de contratos inteligentes dependem fortemente dos contratos inteligentes da Camada 1. Para uma Camada 1 como BTC, que tem dificuldade em suportar lógica de negócios complexa, construir uma Camada 2 que esteja alinhada com os Rollups do Ethereum é essencialmente impossível. Por outro lado, as soluções de Sovereign Rollup não exigem contratos na Camada 1 para verificação/interligação de estados. Sua arquitetura é a seguinte: (Aqui, a descrição da arquitetura está faltando, o que implica que uma ilustração ou mais detalhes deveriam ter sido incluídos, mas não são fornecidos no texto.)

Em Rollups soberanos, os nós fora da camada de Disponibilidade de Dados (DA) servem como as entidades para a execução de transações e operações de liquidação, oferecendo um maior grau de liberdade. O fluxo de trabalho é o seguinte:

Os nós na camada de execução do Rollup soberano enviam dados de transação/detalhes de alteração de estado para a camada DA, enquanto a camada de liquidação/clientes se esforçam para obter e verificar os dados. É importante notar que, como o módulo da camada de assentamento não está localizado na Camada 1, os Rollups soberanos, em teoria, não podem alcançar pontes com segurança equivalente à Camada 1. Eles geralmente dependem de pontes cartorárias ou soluções de ponte de terceiros. Atualmente, a implementação de esquemas soberanos de Rollup/verificação de clientes é relativamente simples, exigindo apenas a publicação de dados sobre a cadeia Bitcoin (BTC) usando um protocolo semelhante ao Ordinals. Quanto à verificação e ao consenso fora da cadeia, há uma grande flexibilidade. Na verdade, muitas sidechains simplesmente publicam dados DA na cadeia BTC, essencialmente se tornando "Rollups soberanos baseados em BTC", embora a segurança específica seja questionável. No entanto, a questão é que a taxa de transferência de dados do Bitcoin é extremamente baixa, com um máximo de 4 MB por bloco e um tempo médio de bloco de 10 minutos, traduzindo-se em uma taxa de transferência de dados de apenas 6 KB/s. As soluções de camada 2 que afirmam ser Rollups soberanos podem não ser capazes de publicar todos os dados DA na cadeia BTC, portanto, eles podem optar por métodos alternativos, como publicar dados DA fora da cadeia e armazenar o datahash na cadeia BTC como uma forma de "compromisso", ou encontrar uma maneira de compactar dados DA altamente (por exemplo, usando State diff + ZK Proof como alegado pela Chainway). Claramente, este modo não está de acordo com a definição de "Rollup soberano" ou um Rollup adequado, representando uma variante cuja segurança é questionável. Prevemos que a maioria dos projetos de Camada 2 com o banner "Rollup" acabará não publicando todos os dados de DA na cadeia BTC, então suas soluções práticas provavelmente não corresponderão às alegações de "ZK Rollup" ou "OP Rollup" feitas em seus whitepapers.

Por fim, vamos resumir brevemente as diferenças entre Rollups soberanos e Rollups de contratos inteligentes:

1. Capacidade de atualização:As iterações de atualização dos Rollups de contrato inteligente envolvem a atualização dos contratos inteligentes, exigindo que a equipe de desenvolvimento utilize contratos atualizáveis. Esse tipo de autoridade de atualização de contrato inteligente é geralmente controlado pela equipe de desenvolvimento da Rollup por meio de multiassinatura. Em contraste, as regras de atualização para Rollups soberanos são semelhantes às bifurcações suaves e rígidas convencionais do blockchain, onde os nós podem optar por atualizar versões independentemente, e diferentes clientes podem escolher se aceitam a atualização. Sob essa perspectiva, os Rollups soberanos são superiores aos Rollups de contrato inteligente em termos de capacidade de atualização.

2. Ponte:Em condições ideais, as pontes para Rollups de contratos inteligentes obedecem à confiança mínima, mas a possibilidade de atualização de contratos pode afetar sua segurança. No esquema de Rollup soberano, os desenvolvedores precisam construir componentes de ponte sob a cadeia de Camada 1 por si mesmos, e as pontes construídas provavelmente confiam menos do que as pontes de contratos inteligentes.

Estrutura DA de BTC

No texto acima, mencionamos que para implementar um Rollup soberano com base em BTC, o cerne está em usar o protocolo Ordinals para fazer com que o BTC sirva como a camada de Disponibilidade de Dados (DA). A Chainway adotou essa solução.

Podemos examinar uma submissão de dados DA do sequenciador Chainway, com o hash da transação sendo:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, ilustrado como segue:

Este script de transação toma emprestado da abordagem do Protocolo Ordinais de usar OP_0 OP_IF para gravação de dados para gravar os dados DA (Data Availability) do Rollup na cadeia BTC. Isso envolve a publicação de alterações de estado e o ZK Proofs, que é equivalente em segurança à publicação dos dados originais da transação, mas permite uma redução significativa do tamanho dos dados. Além dos dados DA, o sequenciador também grava alguns dados de autenticação na transação, com o mais crucial sendo o sequenciador Rollup assinando os dados DA com sua chave privada para garantir que o envio venha do sequenciador. É importante observar que qualquer transação envolvendo o envio de dados DA tem 16 zeros binários no final do hash da transação (ou seja, dois bytes consecutivos são zero). Essa restrição pode ser vista no código:

No gráfico de transação de exemplo mencionado anteriormente, o número aleatório "b715" é usado para ajustar o valor de hash da transação para que sua cauda carregue 16 zeros específicos. Esse princípio é semelhante à mineração de Bitcoin, onde um número aleatório nonce é adicionado para tornar os N bits principais do hash todos zeros, atendendo a condições específicas de restrição. Este projeto visa simplificar a dificuldade de obtenção de dados DA (Data Availability). Quando qualquer nó Layer2 deseja acessar dados DA, ele só precisa escanear o bloco BTC (Bitcoin) para todas as transações definidas para terminar com 16 zeros, distinguindo efetivamente as transações iniciadas pelo classificador Chainway ao enviar dados de outras transações no blockchain Bitcoin. No texto a seguir, essas transações que contêm dados DA e atendem ao requisito de terminar com 16 zeros são chamadas de "transações padrão Chainway". O foco deste artigo é como a Chainway consegue resistir à censura. Como um classificador de Layer2 pode recusar deliberadamente uma solicitação de transação de um usuário específico, um esquema especial deve ser empregado para permitir que os usuários iniciem transações que resistam à censura. Em resposta a esse problema, o Chainway permite que os usuários iniciem "Transações forçadas". Depois que um usuário envia essa declaração de transação dentro de um bloco BTC, o classificador da Chainway deve processar essa solicitação de transação na Camada 2; caso contrário, ele será incapaz de produzir normalmente um bloco, ou o bloco produzido não será reconhecido por clientes off-chain. A estrutura de parâmetros da transação forçada é a seguinte:

Essa transação será submetida à blockchain do Bitcoin como uma “Transação de Especificação da Chainway”, com o hash da transação terminando em 16 zeros. O classificador ChainWay, ao gerar blocos L2, deve incluir “Transações de Especificação da Camada 2” que foram divulgadas na blockchain BTC mas ainda não registradas no livro-razão L2, e agregá-las em uma Árvore de Merkle, escrevendo sua raiz de Merkle no cabeçalho do bloco L2. Uma vez que um usuário inicia uma transação forçada diretamente na blockchain BTC, o classificador deve processá-la; caso contrário, não poderá gerar o próximo bloco válido. O cliente da Chainway fora da cadeia BTC pode primeiro verificar a prova ZK para determinar a validade do bloco L2 submetido pelo classificador, verificar a raiz de Merkle do cabeçalho do bloco L2 e julgar se o classificador incluiu honestamente o pedido de transação forçada. O fluxo de trabalho pode ser consultado no seguinte diagrama. Observe que, devido a limitações de espaço, o diagrama abaixo está faltando uma condição de julgamento em verify_relevant_tx_list:

Em resumo, o cliente/nó da Chainway sincroniza com os blocos da mainnet BTC e verifica se há "dados DA" publicados pelo classificador da Chainway a partir deles. Ele verifica se esses dados são publicados pelo classificador designado e, de fato, contêm todas as "transações padrão Chainway" enviadas à cadeia BTC. É evidente que, desde que os usuários possam construir uma transação que atenda aos critérios especificados como uma "transação padrão" e submetê-la à cadeia BTC, essa transação será eventualmente incluída no livro-razão L2 local do cliente Chainway. Caso contrário, o bloco L2 liberado pelo classificador Chainway será rejeitado pelo cliente. Se combinado com uma transmissão confiável de mensagens de consenso/alerta off-chain, o esquema de transação anticensura da Chainway se aproxima do método anticensura ideal de Rollups soberanos. Por exemplo, algumas soluções soberanas de Rollup declararam explicitamente que, no caso de um bloqueio inválido, as mensagens de aviso de alerta seriam transmitidas entre clientes fora da cadeia para aumentar a segurança, especialmente permitindo que clientes leves que não podem sincronizar dados completos do DA saibam sobre anomalias de rede. Se um bloco não incluir "transações obrigatórias", obviamente acionará uma transmissão de alerta off-chain. No entanto, a Chainway ainda não implementou esse aspecto (pelo menos os materiais e repositórios de código atualmente publicados mostram que ela não realizou a implementação técnica desta parte).

Material de referência: Os pesquisadores do Celestia analisam 6 tipos de variantes do Rollup: Sequencer=Aggregator+Header Generator. Mesmo com o consenso alcançado entre clientes/nós off-chain, a eficácia anticensura das "transações forçadas" da Chainway não é tão robusta quanto a de Rollups de contratos inteligentes como o Arbitrum, porque o Arbitrum One acabará garantindo que "transações forçadas" sejam incluídas no livro-razão da Layer2 por meio de contratos na Layer1, herdando totalmente as propriedades anticensura da Layer1. Os Rollups Soberanos claramente não podem corresponder aos Rollups de contratos inteligentes nesse aspecto, pois sua eficácia anticensura depende, em última análise, dos componentes off-chain. Isso também determina que a abordagem de esquemas de "Sovereign Rollups" e "verificação de cliente" fundamentalmente não pode herdar as propriedades anticensura da Layer1 na íntegra, como Arbitrum One, Loopring, dydx e Degate, porque se as transações forçadas podem ser incluídas sem problemas no livro-razão da Layer2 depende das decisões das entidades off-chain da Layer2, não relacionadas à própria Layer1. Evidentemente, a abordagem da Chainway, que depende exclusivamente da discrição de clientes off-chain, apenas herda a confiabilidade DA da Layer1, não suas propriedades anticensura completas. Semelhante às provas recursivas ZK do MINA.

Nesta seção, apresentaremos mais detalhes sobre outros componentes da Chainway, que, além de usar BTC como camada DA, também implementaram provas ZK recursivas semelhantes ao MINA. Sua estrutura geral é ilustrada no diagrama a seguir:

O classificador na rede Chainway, após processar as transações do usuário, gera a prova ZK (Zero-Knowledge) final junto com os detalhes das mudanças de estado (diff de estado) para diferentes contas e as publica no blockchain Bitcoin (BTC). Os nós completos sincronizarão todos os dados históricos da Chainway publicados no blockchain BTC. Cada prova ZK não só tem que provar o processo de transição de estado do bloco atual, mas também garantir a validade da prova ZK do bloco anterior. Com base neste esquema, podemos ver que cada vez que uma nova prova é gerada, ela essencialmente confirma a prova anterior de forma recursiva, e a última prova ZK pode garantir a validade de todas as provas ZK a partir do bloco de gênese. Este design é semelhante ao do MINA. Quando um "cliente leve" que sincroniza apenas cabeçalhos de bloco, também conhecido como nó de luz, se junta à rede, ele só precisa verificar a validade da última prova ZK divulgada no blockchain BTC para confirmar que os dados históricos de toda a cadeia e todas as transições de estado são válidos. Se o classificador agir maliciosamente, recusando-se intencionalmente a aceitar transações obrigatórias ou deixando de usar a prova ZK anterior para prova recursiva, então a prova ZK recém-gerada não pode ser aceita pelo cliente (mesmo que gerada, não é reconhecida), como mostrado no diagrama abaixo:

Resumo

Como resumido no início deste artigo, o Chainway é fundamentalmente um esquema soberano de Rollup/verificação de cliente que usa BTC como sua camada de Disponibilidade de Dados (DA). Para aumentar a resistência à censura do Rollup, a Chainway introduz o conceito de transações forçadas. Por outro lado, o Chainway emprega tecnologia recursiva à prova de ZK, permitindo que novos nós confiem mais na saída do sequenciador e verifiquem a precisão de todos os dados históricos da cadeia a qualquer momento. O problema atual com a Chainway está no mecanismo de confiança de sua ponte cross-chain. Uma vez que adota uma abordagem soberana de Rollup sem detalhar como planeja abordar especificidades técnicas em sua solução de ponte de cadeia cruzada, é desafiador julgar sua segurança final.

Hoje, ao mergulharmos na solução técnica da Chainway, descobrimos que o tipo de tecnologia promovido pela comunidade do projeto não é um Rollup no sentido convencional. Considerando que já existem dezenas de projetos Bitcoin Layer2 (que poderiam chegar a centenas em meio ano), para reduzir o custo cognitivo dos termos técnicos, continuaremos a realizar pesquisas aprofundadas sobre a classificação das soluções Layer2 e padrões de segurança, completude funcional e avaliação. Fiquem ligados!

Disclaimer:

1. Este artigo é reproduzido de [极客 Web3]. Todos os direitos autorais pertencem ao autor original [Shew & Faust, web3 geek]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learn equipe, e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.