Introdução:

A cena atual da camada Bitcoin Layer2 está agitada com diversas soluções tecnológicas diversas convergindo no caldeirão do ecossistema BTC. Dada a rápida iteração no campo da blockchain, onde o vocabulário profissional e os padrões evoluem continuamente através da pesquisa, inovação e implementação de engenharia, muitos projetos recorrem à 'criação de conceitos' ou 'carona de conceitos' para diferenciação e atenção, tornando-se uma regra tácita dentro da indústria. Por exemplo, vários projetos de blockchain modulares inicialmente ativos dentro do ecossistema Ethereum/Celestia pularam no 'vagão da Bitcoin Layer2', denominando-se 'Rollups', apesar de suas soluções técnicas frequentemente 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 projetos se rotulam forçosamente como Rollups ou bifurcam o conceito principal de Rollup com qualificadores vagos, como 'Rollup Soberano'. Descascando as camadas desses 'XX Rollups', muitos projetos são essencialmente baseados em 'validação do lado do cliente' ou 'sidechains', usando o slogan 'XX Rollup' apenas por conveniência. Embora essa estratégia promocional seja comum, tende a ser enganosa, causando mais mal do que bem àqueles que buscam a verdade.

(Esta abordagem, resumida pelo Ministro da Propaganda Nazi Goebbels como “propaganda baseada em mentiras,” é frequentemente observada entre os operadores de projetos.) Como podemos então discernir tal comportamento de “apanhar boleia do conceito Rollup”? Talvez, começando pelos primeiros princípios, definindo diferentes categorias de projetos de Camada2 e seus níveis de segurança e funcionalidades com base em padrões amplamente aceites no Ocidente e em toda a indústria, poderia oferecer clareza. Não se trata necessariamente da solução escolhida; o cerne está em saber se o design do mecanismo do projeto garante a segurança e confiabilidade da rede de Camada2 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 dos slogans de “Rollup” de alguns projetos. O 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 da sua implementação. Chainway, tipicamente uma validação do lado do cliente Layer2, propôs um esquema de transação contra a censura desencadeado em BTC com validação off-chain, empregando Provas ZK recursivas semelhantes às usadas pela cadeia pública MINA, posicionando-se à frente de muitos projetos Bitcoin Layer2. Acreditamos que pesquisar a tecnologia da Chainway é valioso, oferecendo insights significativos para observadores da camada Bitcoin Layer2. (As imagens promocionais da Chainway a rotulam como um ZK Rollup, mas sua solução antiga era validação do lado do cliente, com a ZKR sendo 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, muitas vezes referido como um "ZK Rollup" por muitos KOLs, enquanto sua documentação técnica o posiciona como um "Sovereign Rollup". Recentemente, a Chainway também anunciou seu novo projeto, Citrea, alegando ser um ZK Rollup baseado em BitVM. No entanto, como a 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 divulgada publicamente pela Chainway envolve a publicação de dados DA através do protocolo Ordinals, usando BTC como sua camada DA, e a publicação de detalhes de mudança de estado (State diff) + ZK Proof verificando a correção das alterações de estado na Layer1, equivalente à publicação de dados de transação completos e verificáveis. No entanto, como a Layer1 não verifica diretamente as ZK Proofs, com verificação conduzida por clientes/nós independentes off-chain, e a base de código atual da Chainway não alcançou consenso entre os clientes off-chain, nem alegou resolver esse problema nas mídias sociais, a solução técnica divulgada publicamente da Chainway pertence essencialmente à categoria "validação do lado do cliente", assemelhando-se até mesmo 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 Off-chain

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 mais ampla (Rollup de contrato inteligente). Então, qual é exatamente a estrutura de um Sovereign Rollup?

Em essência, um Sovereign Rollup baseado em Bitcoin é um pouco semelhante a um "grupo de clientes off-chain/sidechain publicando dados DA no blockchain BTC". Sua principal característica é que ele não requer contratos inteligentes na Camada 1 para verificar transições de estado/ações de cadeia cruzada para a Camada 2. Essencialmente, ele usa BTC como a camada DA, e seu modelo de segurança é amplamente semelhante à "validação do lado do cliente". É claro que algumas soluções Sovereign Rollup mais seguras dependem de uma camada de liquidação de terceiros fora da cadeia Bitcoin (semelhante a uma sidechain) para realizar verificações de transição de estado. Além disso, entre diferentes clientes independentes/nós completos, existe um nível de consenso ou transmissão de mensagem confiável para chegar a um "acordo" sobre certas ações contenciosas. No entanto, alguns projetos do Sovereign Rollup são puramente baseados na "validação do lado do cliente", sem qualquer mensagem confiável passando entre clientes/nós independentes.

Para entender melhor o conceito único de “Sovereign Rollup”, é útil compará-lo com o seu homólogo, o Rollup de contrato inteligente. Na 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 seguinte:

(Imagine um diagrama aqui)

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

• Camada de execução: Executa transações do usuário, atualiza o estado da blockchain e envia dados para a camada DA e 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): Atua 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 não confiável para qualquer pessoa.

• Camada de consenso: Garante a finalidade da ordenação das transações. A sua função parece ser um pouco semelhante à da camada DA (a abordagem da comunidade Ethereum à estratificação modular da blockchain não inclui uma camada de consenso).
  
  Da arquitetura dos 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.
  
  Em contraste, os Rolups Soberanos diferem significativamente pelo facto de descentralizarem algumas destas responsabilidades longe de uma blockchain monolítica como o Ethereum. Especificamente, não dependem de contratos inteligentes na camada base (Camada 1) para verificar as transições de estado ou lidar com disputas. Em vez disso, essas tarefas são geridas por clientes off-chain ou através de uma camada de liquidação de terceiros, enfatizando uma abordagem diferente para alcançar escalabilidade e segurança em sistemas blockchain.

Os contratos Rollup na Ethereum recebem provas de validade ou provas de fraude para verificar a validade das transições de estado da Camada 2. Vale mencionar que os contratos inteligentes Rollup atuam como entidades de camada de liquidação na arquitetura modular da blockchain. Os contratos de camada de liquidação frequentemente incluem módulos de ponte para lidar com ativos transferidos do Ethereum para a Camada 2. Para Disponibilidade de Dados (DA), os contratos de camada de liquidação podem exigir que o Sequenciador publique os detalhes mais recentes de transações/detalhes de alteração de estado na cadeia. Sem publicar DA na cadeia, é impossível atualizar com sucesso o estado L2 registrado nos contratos Rollup.

(O ZK Rollup ou Optimistic Rollup pode forçar que os dados DA sejam publicados na cadeia; sem ele, o estado registrado na camada de liquidação não pode ser atualizado.) Ao analisar o modelo de segurança e os indicadores de risco das soluções de Camada 2 de Bitcoin/Ethereum com a teoria do barril, é claro que os Rollups de contratos inteligentes dependem fortemente dos contratos inteligentes da Camada 1. Para uma Camada 1 como BTC, que luta para suportar lógica de negócios complexa, construir uma Camada 2 que se alinhe com os Rollups de Ethereum é essencialmente impossível. Por outro lado, as soluções Sovereign Rollup não requerem contratos na Camada 1 para verificação/ligação de estado. Sua arquitetura é a seguinte: (Aqui, a descrição da arquitetura está em falta, implicando que uma ilustração ou mais detalhes deveriam ter sido incluídos, mas não são fornecidos no texto.)

Nos 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 liquidação não está localizado na Camada 1, os Rollups soberanos, em teoria, não podem alcançar pontes com segurança equivalente à Camada 1. Muitas vezes, dependem de pontes notariais ou de soluções de transição 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 fora da cadeia e ao consenso, existe 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 4MB por bloco e um tempo médio de bloco de 10 minutos, traduzindo-se em uma taxa de transferência de dados de apenas 6KB/s. Soluções de camada 2 alegando ser soberanas Rollups 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 off-chain e armazenar o datahash na cadeia BTC como uma forma de "compromisso", ou encontrar uma maneira de comprimir 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" não publicará todos os dados de DA na cadeia BTC, então suas soluções práticas provavelmente não corresponderão às reivindicações "ZK Rollup" ou "OP Rollup" feitas em seus whitepapers.

Finalmente, vamos resumir brevemente as diferenças entre os Rollups soberanos e os Rollups de contratos inteligentes:

1. Atualizabilidade:As iterações de atualização dos Rollups de contratos inteligentes envolvem atualizar os contratos inteligentes, exigindo que a equipe de desenvolvimento utilize contratos atualizáveis. Este tipo de autoridade de atualização de contrato inteligente é geralmente controlado pela equipe de desenvolvimento do Rollup através de multi-assinatura. Em contraste, as regras de atualização para Rollups soberanos são semelhantes às bifurcações suaves e duras de blockchain convencionais, onde os nós podem escolher atualizar versões de forma independente, e diferentes clientes podem escolher se aceitam a atualização. Do ponto de vista, os Rollups soberanos são superiores aos Rollups de contratos inteligentes em termos de capacidade de atualização.

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

Estrutura BTC DA

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

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

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, ilustrado da seguinte forma:

Este script de transação é inspirado na abordagem do Protocolo dos Ordinais de usar OP_0 OP_IF para escrita de dados para escrever os dados de DA (Disponibilidade de Dados) da Rollup na cadeia BTC. Isso envolve a publicação de alterações de estado e Provas de Conhecimento Zero (ZK Proofs), o que é equivalente em termos de segurança à publicação dos dados de transação originais, mas permite uma redução significativa no tamanho dos dados. Além dos dados de DA, o sequenciador também escreve alguns dados de autenticação na transação, sendo o mais crucial a assinatura do sequenciador da Rollup nos dados de DA com sua chave privada para garantir que a submissão venha do sequenciador. É importante observar que qualquer transação que envolva a submissão de dados de 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 exemplo do gráfico de transações mencionado anteriormente, o número aleatório "b715" é usado para ajustar o valor hash da transação de modo que o seu final carregue 16 zeros específicos. Este princípio é semelhante à mineração de Bitcoin, onde um número aleatório nonce é adicionado para fazer com que os N bits principais do hash sejam todos zeros, cumprindo condições específicas de restrição. Este design tem como objetivo simplificar a dificuldade de obtenção de dados de DA (Disponibilidade de Dados). Quando qualquer nó da Camada2 deseja aceder a dados de DA, só precisa de analisar o bloco BTC (Bitcoin) para todas as transações definidas para terminar com 16 zeros, distinguindo eficazmente as transações iniciadas pelo classificador Chainway ao submeter dados de outras transações na blockchain do Bitcoin. No texto seguinte, tais transações que contêm dados de DA e cumprem o requisito de terminar com 16 zeros são referidas como "transações padrão Chainway". O foco deste artigo é como a Chainway alcança resistência à censura. Visto que um classificador da Camada2 pode recusar deliberadamente um pedido de transação de um utilizador específico, deve ser empregue um esquema especial que permita aos utilizadores iniciar transações que resistam à censura. Em resposta a esta questão, a Chainway permite aos utilizadores lançar "Transações Forçadas". Uma vez que um utilizador submete esta declaração de transação dentro de um bloco BTC, o classificador Chainway deve processar este pedido de transação na Camada2; caso contrário, não será capaz de produzir normalmente um bloco, ou o bloco produzido não será reconhecido pelos clientes off-chain. A estrutura de parâmetros da transação forçada é a seguinte:

Esta transação será submetida à blockchain do Bitcoin como uma "Transação de Especificação 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 Camada2" que foram divulgadas na blockchain BTC mas ainda não foram registadas no livro-razão L2, e agregá-las numa Árvore de Merkle, escrevendo a sua raiz de Merkle no cabeçalho do bloco L2. Uma vez que um utilizador inicia uma transação forçada diretamente na blockchain BTC, o classificador deve processá-la; caso contrário, não pode gerar o próximo bloco válido. O cliente 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 de forma verídica o pedido de transação forçada. O fluxo de trabalho pode ser consultado no seguinte diagrama. Note que, devido a limitações de espaço, o diagrama abaixo está a faltar uma avaliação de condição em verify_relevant_tx_list:

Em resumo, o cliente/nó da Chainway sincroniza com os blocos principais da BTC e procura por "dados DA" publicados pelo classificador da Chainway a partir deles. Verifica que estes dados são publicados pelo classificador designado e de facto contêm todas as "transações padrão da Chainway" submetidas à cadeia BTC. É evidente que, desde que os utilizadores possam construir uma transação que cumpra os critérios especificados como uma "transação padrão" e submetê-la à cadeia BTC, esta transação acabará por ser incluída no L2 local do cliente da Chainway. Caso contrário, o bloco L2 publicado pelo classificador da Chainway será rejeitado pelo cliente. Se combinado com uma transmissão de mensagens de alerta/consenso fiável fora da cadeia, o esquema de transação anti-censura da Chainway aproxima-se do método anti-censura ideal dos Rollups soberanos. Por exemplo, algumas soluções de Rollup soberanas declararam explicitamente que, no caso de um bloco inválido, mensagens de alerta seriam difundidas entre os clientes fora da cadeia para reforçar a segurança, especialmente informando os clientes leves que não podem sincronizar dados DA completos sobre anomalias de rede. Se um bloco não incluir de forma verdadeira as "transações obrigatórias", obviamente irá desencadear uma difusão de alerta fora da cadeia. No entanto, a Chainway ainda não implementou este aspeto (pelo menos os materiais atualmente publicados e os repositórios de código mostram que ainda não empreendeu a implementação técnica desta parte).

Material de referência: Os investigadores da Celestia analisam 6 tipos de variantes de Rollup: Sequenciador=Aggregator+Gerador de Cabeçalho. Mesmo com o consenso alcançado entre os clientes/nós fora da cadeia, a eficácia anti-censura das “transações forçadas” da Chainway não é tão robusta quanto a dos Rollups de contratos inteligentes como Arbitrum, porque o Arbitrum One acabará por garantir que as “transações forçadas” sejam incluídas no livro-razão da Camada2 através de contratos na Camada1, herdando totalmente as propriedades anti-censura da Camada1. Os Rollups soberanos claramente não conseguem igualar os Rollups de contratos inteligentes neste aspeto, visto que a sua eficácia anti-censura depende fundamentalmente dos componentes fora da cadeia. Isso também determina que a abordagem dos “Rollups soberanos” e os esquemas de “verificação de clientes” fundamentalmente não podem herdar totalmente as propriedades anti-censura da Camada1, como o Arbitrum One, Loopring, dydx e Degate, porque a inclusão suave das transações forçadas no livro-razão da Camada2 depende das decisões das entidades fora da cadeia da Camada2, não relacionadas com a Camada1 em si. Evidentemente, a abordagem da Chainway, que depende exclusivamente do critério dos clientes fora da cadeia, apenas herda a fiabilidade DA da Camada1, não as suas propriedades anti-censura completas. Semelhante às provas ZK recursivas da MINA.

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

O classificador na rede Chainway, depois de processar as transações do usuário, gera a prova final ZK (Zero-Knowledge) juntamente com os detalhes das mudanças de estado (state diff) 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 apenas sincroniza cabeçalhos de bloco, também conhecido como nó leve, 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 se gerada, não é reconhecida), como mostrado no diagrama abaixo:

Resumo

Como resumido no início deste artigo, o Chainway é fundamentalmente um esquema soberano de verificação de Rollup/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 dos dados históricos de toda a cadeia a qualquer momento. O problema atual com a Chainway reside no mecanismo de confiança da sua ponte de cadeia cruzada. Como adota uma abordagem soberana de Rollup sem detalhar como planeja abordar as especificidades técnicas em sua solução de ponte de cadeia cruzada, é um desafio julgar sua segurança final.

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

Aviso legal：

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