Desde o "Verão das Inscrições" em 2023, as tecnologias Layer2 do Bitcoin têm estado na vanguarda da revolução Web3. Apesar de terem entrado no campo mais tarde do que as soluções Layer2 do Ethereum, o Bitcoin aproveitou o apelo único do POW e o lançamento sem problemas dos ETFs spot, que estão livres de riscos de "securitização", para atrair bilhões de dólares de investimento para este setor em crescimento em apenas seis meses. Entre estes, a Merlin destaca-se como a entidade mais substancial e seguida no panorama do Bitcoin Layer2, comandando bilhões em valor total bloqueado (TVL). Graças a incentivos claros de staking e retornos impressionantes, a Merlin rapidamente se destacou, superando até mesmo o conhecido ecossistema Blast em questão de meses. Com o burburinho crescente em torno da Merlin, a exploração da sua infraestrutura técnica tem cativado uma audiência crescente. Neste artigo, a Geek Web3 concentra-se em decifrar as estratégias técnicas por trás da Merlin Chain. Ao desembrulhar os documentos disponíveis publicamente e a lógica por trás do seu design de protocolo, pretendemos desmistificar os processos operacionais da Merlin e aprimorar a compreensão do seu framework de segurança, proporcionando uma visão mais clara de como esta solução líder do Bitcoin Layer2 funciona.

Rede de Oráculos Descentralizados da Merlin: Um Comitê DAC Off-Chain Aberto

Para todas as tecnologias de Camada2, lidar com a disponibilidade de dados (DA) e o custo da publicação de dados continua a ser um desafio crítico, quer se trate de uma Camada2 Ethereum ou de uma Camada2 Bitcoin. Dadas as limitações inerentes da rede Bitcoin, que luta com uma grande carga de dados, estrategizar o uso eficiente do espaço valioso de DA é um teste significativo para a criatividade dos desenvolvedores de Camada2.

É evidente que se os projetos Layer2 publicassem diretamente dados de transações brutos na blockchain do Bitcoin, não conseguiriam alcançar alta capacidade e baixas taxas. As soluções predominantes incluem altamente comprimir os dados para reduzir significativamente seu tamanho antes de carregá-los na blockchain do Bitcoin, ou optar por publicar os dados fora da cadeia.

Entre aqueles que empregam a primeira estratégia, Citrea destaca-se. Eles têm como objetivo carregar alterações nos estados da Camada2 ao longo de intervalos específicos, o que envolve gravar os resultados das alterações de estado em várias contas, juntamente com as provas de conhecimento zero (ZKPs) correspondentes, na blockchain do Bitcoin. Sob este arranjo, qualquer pessoa pode aceder às diferenças de estado e ZKPs da mainnet do Bitcoin para acompanhar as alterações de estado da Citrea. Esta abordagem reduz eficazmente o tamanho dos dados carregados para a blockchain em mais de 90%.

Embora isso possa comprimir bastante o tamanho dos dados, o gargalo ainda é óbvio. Se um grande número de contas mudar seu status em um curto período de tempo, a Camada 2 deve resumir e carregar todas as mudanças nessas contas para a cadeia do Bitcoin. O custo final de liberação de dados não pode ser mantido muito baixo. Isso é verdade em muitos Ethereums. Isso pode ser visto no ZK Rollup.

Muitas camadas secundárias do Bitcoin simplesmente seguem o segundo caminho: usam diretamente a solução DA sob a cadeia do Bitcoin, seja construindo uma camada DA por si mesmas, ou usando Celestia, EigenDA, etc. B^Square, BitLayer e o protagonista deste artigo, Merlin, todos usam esta solução de expansão DA fora da cadeia.

Artigo anterior no geek web3——“Análise da Estrada Tecnológica da Nova Versão B^2: A Necessidade da Camada de DA e Verificação sob a Cadeia de Bitcoins”, mencionámos que B^2 imitou diretamente Celestia e construiu uma rede DA que suporta a função de amostragem de dados sob a cadeia, chamada B^2 Hub. Os dados 'DA' como dados de transação ou diferença de estado são armazenados sob a cadeia Bitcoin, e apenas o datahash / raiz de merkle é transferido para a rede principal do Bitcoin.

Essencialmente, isso trata o Bitcoin como um quadro de avisos sem confiança: qualquer pessoa pode ler o datahash a partir da cadeia do Bitcoin.Depois de obter os dados do DA a partir do fornecedor de dados off-chain, você pode verificar se corresponde ao datahash on-chain., ou seja, hash(data1) == datahash1? . Se houver correspondência entre os dois, significa que os dados fornecidos pelo fornecedor de dados off-chain estão corretos.

Camada DA no Layer2 do Bitcoin explicada:

(Fonte da imagem: Geek web3)

Este sistema garante que os dados dos nós off-chain se correlacionam com pistas específicas ou provas na Camada1, protegendo-se contra o potencial problema da camada DA fornecer informações falsas. No entanto, surge uma preocupação significativa se o originador dos dados—o Sequenciador—falhar na distribuição dos dados reais relacionados com um datahash. Suponhamos que o Sequenciador apenas transmita o datahash para a blockchain Bitcoin enquanto retém intencionalmente os dados correspondentes do acesso público. O que acontece então?

Considere cenários em que apenas a Prova ZK e o StateRoot são tornados públicos, mas os dados DA acompanhantes (como diferenças de estado ou dados de transação) não são divulgados. Embora seja possível validar a Prova ZK e garantir que a transição do Prev_Stateroot para o New_Stateroot seja precisa, permanece desconhecido quais estados de contas foram alterados. Nestas circunstâncias, embora os ativos dos utilizadores permaneçam seguros, a condição real da rede permanece incerta. Ninguém sabe quais transações foram incorporadas no blockchain ou quais estados de contratos foram atualizados, tornando efetivamente a Layer2 inoperante, quase como se tivesse ficado offline.

Esta prática é referida como “retenção de dados.” Em agosto de 2023, Dankrad da Fundação Ethereum iniciou uma discussão no Twitter sobre um conceito conhecido como “DAC.”

Em muitas configurações Layer2 do Ethereum que utilizam soluções de disponibilidade de dados fora da cadeia (DA), há frequentemente alguns nós com privilégios especiais que formam um comitê conhecido como o Comitê de Disponibilidade de Dados (DAC). Este comitê serve como garantidor, assegurando que o Sequenciador de fato lançou dados DA completos (dados de transação ou diferença de estado) fora da cadeia. Os membros do DAC então criam uma multi-assinatura coletiva. Se esta multi-assinatura atingir o limite necessário (por exemplo, 2 em 4), os contratos correspondentes na Layer1 são projetados para assumir que o Sequenciador atendeu aos padrões de verificação do DAC e lançou genuinamente os dados DA completos fora da cadeia.

Os comités DAC da camada Ethereum Layer2 aderem predominantemente ao modelo de Prova de Autoridade (POA), limitando a adesão a um grupo seleto de nós que passaram no KYC ou foram oficialmente designados. Esta abordagem efetivamente rotulou o DAC como um marco de "centralização" e "blockchain de consórcio". Além disso, em certas Ethereum Layer2s que utilizam a abordagem DAC, o sequenciador distribui dados DA exclusivamente para nós membros do DAC, com uma disseminação externa mínima. Consequentemente, quem procura dados DA deve obter aprovação do DAC, semelhante a operar dentro de uma blockchain de consórcio.

Está claro que os DACs precisam de ser descentralizados. Embora a Camada2 possa não ser necessária para carregar diretamente os dados do DA para a Camada1, o acesso dos membros do DAC deve ser publicamente acessível para evitar a colusão e a má conduta de alguns indivíduos. (Para mais informações sobre esta questão, consulte as discussões anteriores de Dankrad no Twitter.)

A proposta da Celestia de BlobStream tem como objetivo fundamental substituir um DAC centralizado pelo Celestia. Sob este modelo, um sequenciador Ethereum L2 iria postar dados DA na blockchain da Celestia. Se dois terços dos nós da Celestia validarem estes dados, o contrato especializado da Camada 2 no Ethereum validaria que o sequenciador publicou com precisão os dados DA, posicionando assim os nós da Celestia como garantidores. Dado que a Celestia opera com centenas de nós validadores, esta configuração maior do DAC é considerada relativamente descentralizada.

A solução DA adotada pela Merlin é na verdade relativamente próxima do BlobStream da Celestia, ambos abrem acesso ao DAC através de POS, tornando-o mais descentralizado. Qualquer pessoa pode executar um nó DAC desde que aposte ativos suficientes. Na documentação da Merlin, o nó DAC mencionado acima é chamado de Oracle, e é apontado que irá apoiar apostas de ativos de BTC, MERL e até tokens BRC-20 para implementar um mecanismo de aposta flexível e também apoiar apostas por procuração semelhantes ao Lido. (O acordo de aposta POS da máquina oráculo é basicamente uma das próximas narrativas centrais da Merlin, e as taxas de juros de aposta fornecidas são relativamente altas)

Aqui descrevemos brevemente o fluxo de trabalho do Merlin (imagem abaixo):

1. Depois de o sequenciador receber um grande número de pedidos de transação, ele os agrega e gera um lote de dados (lote de dados), que é passado para o nó Prover e o nó Oracle (DAC descentralizado).

2. O nó Prover do Merlin é descentralizado e utiliza o Prover da lumoz como um serviço. Após receber várias cargas de dados, o pool de mineração do Prover irá gerar provas de conhecimento zero correspondentes. Posteriormente, as ZKP serão enviadas para o nó Oracle para verificação.

3. O nó do Oráculo verificará se a Prova ZK enviada pelo pool de mineração ZK de Lmuoz corresponde aos dados Batch enviados pelo Sequenciador. Se os dois puderem ser correspondidos e não contiverem outros erros, a verificação é aprovada. durante este processo, os nós do Oráculo Descentralizado gerarão multi-assinaturas através de assinaturas de limiar e declararão ao mundo exterior que o sequenciador enviou completamente os dados DA, e o ZKP correspondente é válido e passou pela verificação dos nós do Oráculo.

4. O sequenciador recolhe resultados de multi-assinatura dos nós do Oracle. Quando o número de assinaturas atinge os requisitos do limiar, a informação da assinatura é enviada para a cadeia do Bitcoin, juntamente com o datahash dos dados DA (lote de dados), e é entregue ao mundo exterior para leitura e confirmação.

(Diagrama do princípio de funcionamento de Merlin fonte: Geek web3)

1. Os nós oráculo realizam um processamento especial no processo de cálculo para verificar a Prova de Conhecimento Zero, geram compromissos de Comprometimento e enviam-nos para a cadeia de Bitcoins, permitindo a qualquer pessoa desafiar o 'compromisso'. O processo aqui é basicamente o mesmo que o protocolo de prova de fraude do bitVM. Se o desafio for bem-sucedido, o nó oráculo que emitiu o Compromisso será punido financeiramente. Claro, os dados que o Oráculo deseja publicar na cadeia de Bitcoins incluem também o hash do estado atual da Camada 2 - StateRoot, bem como o ZKP em si, que deve ser publicado na cadeia de Bitcoins para detecção externa.

Referências:Uma Interpretação Minimalista do BitVM: Como Verificar Provas de Fraude na Cadeia BTC

Existem vários detalhes que precisam de ser elaborados aqui. Em primeiro lugar, é mencionado no roadmap do Merlin que a Oracle irá fazer backup dos dados DA para a Celestia no futuro. Desta forma, os nós da Oracle podem eliminar adequadamente os dados históricos locais sem a necessidade de os dados persistirem localmente. Ao mesmo tempo, o Commitment gerado pela Rede Oracle é na realidade a raiz de uma Árvore de Merkle. Não é suficiente divulgar a raiz para o mundo exterior. O conjunto de dados completo correspondente ao Commitment deve ser tornado público. Isto requer encontrar uma plataforma DA de terceiros. Esta plataforma pode ser a Celestia ou a EigenDA, ou outras camadas DA.

Referências:"Análise da Estrada de Tecnologia da Nova Versão B^2: A Necessidade da Camada de DA e Verificação sob a Cadeia Bitcoin"

Análise do modelo de segurança: ZKRollup otimista + serviço MPC da Cobo

Acima, descrevemos brevemente o fluxo de trabalho do Merlin, e acredito que já tenha dominado a sua estrutura básica. Não é difícil ver que Merlin, B^Square, BitLayer e Citrea seguem basicamente o mesmo modelo de segurança - ZK-Rollup otimista.

Ao ler esta palavra pela primeira vez, muitos entusiastas do Ethereum podem sentir-se estranhos. O que é o “ZK-Rollup otimista”? Na compreensão da comunidade Ethereum, o “modelo teórico” do ZK Rollup é completamente baseado na fiabilidade de cálculos criptográficos e não requer a introdução de pressupostos de confiança. A palavra “otimista” introduz precisamente o pressuposto de confiança, o que significa que as pessoas, na maioria das vezes, devem ser otimistas de que o Rollup não tem erros e é fiável. Uma vez que ocorra um erro, o operador do Rollup pode ser punido através de prova de fraude. Esta é a origem do nome Optimistic Rollup, também conhecido como OP Rollup.

Para o ecossistema Ethereum na base do Rollup, o ZK-Rollup otimista pode ser um pouco indescritível, mas ele se encaixa exatamente na situação atual da Camada 2 do Bitcoin. Devido a limitações técnicas, a cadeia do Bitcoin não pode verificar completamente a Prova ZK. Ela só pode verificar uma certa etapa do processo de cálculo da ZKP em circunstâncias especiais. Sob essa premissa, a cadeia do Bitcoin realmente só pode suportar o protocolo de prova de fraude. As pessoas podem apontar que há um erro em uma determinada etapa de cálculo da ZKP durante o processo de verificação fora da cadeia e desafiado através da prova de fraude. Claro, isso não pode ser comparado ao ZK Rollup no estilo Ethereum, mas é o melhor que a Camada 2 do Bitcoin pode alcançar atualmente. Modelo de segurança confiável e mais seguro.

Sob o otimista esquema ZK-Rollup acima, suponha que haja N pessoas na rede da Camada 2 que têm a autoridade para iniciar desafios. Desde que um dos N desafiadores seja honesto e confiável e possa detectar erros e iniciar prova de fraude a qualquer momento, a transição de estado da Camada 2 é segura. Claro, o Rollup otimista com um grau relativamente elevado de conclusão precisa garantir que sua ponte de retirada também esteja protegida pelo protocolo de prova de fraude. No entanto, quase todos os Bitcoin da Camada 2 atualmente não podem alcançar esta premissa e precisam depender de multi-assinatura/MPC. Então como escolher multi-assinatura? Assinar a solução MPC tornou-se uma questão intimamente relacionada com a segurança da Camada 2.

Merlin escolheu o serviço MPC da Cobo para a solução de ponte. Usando medidas como isolamento de carteira quente e fria, os ativos da ponte são geridos em conjunto pela Cobo e pela Merlin Chain. Qualquer comportamento de levantamento precisa ser tratado em conjunto pelos participantes MPC da Cobo e da Merlin Chain. Essencialmente, a confiabilidade da ponte de levantamento é garantida através do endosso de crédito da instituição. Claro, esta é apenas uma medida paliativa nesta fase. À medida que o projeto melhora gradualmente, a ponte de levantamento pode ser substituída pela “ponte otimista” com uma suposição de confiança de 1/N através da introdução do BitVM e do protocolo de prova de fraude. No entanto, a implementação disso será mais difícil. Grandes (quase todas as pontes oficiais de Camada 2 atualmente dependem de multi-assinatura).

No geral, podemos resolver isso,Merlin introduziu DAC baseado em POS, ZK-Rollup otimista baseado em BitVM e solução de custódia de ativos MPC baseada em Cobo, resolvendo o problema DA ao abrir as permissões do DAC; garantindo a segurança das transições de estado ao introduzir o BitVM e protocolos de prova de fraude; garantindo a confiabilidade da ponte de saque ao introduzir o serviço MPC da plataforma de custódia de ativos bem conhecida Cobo.

Estratégia de Submissão ZKP de Verificação em Duas Etapas da Lumoz

Nas nossas discussões anteriores, aprofundámo-nos no quadro de segurança do Merlin e explorámos o conceito inovador de rollups ZK otimistas. Um elemento chave na trajetória tecnológica do Merlin é o Prover descentralizado. Este papel é fundamental dentro da arquitetura ZK-Rollup, encarregado de gerar Provas ZK para lotes lançados pelo Sequenciador. A criação de provas de conhecimento zero é notavelmente intensiva em recursos, representando um desafio considerável.

Uma estratégia básica para acelerar a geração de provas ZK é dividir e paralelizar as tarefas. Este processo, conhecido como paralelização, envolve dividir a geração de prova ZK em partes distintas. Cada parte é tratada por um Prover diferente e, finalmente, um Agregador mescla essas provas individuais em um todo unificado. Esta abordagem não só acelera o processo, mas também distribui a carga computacional de forma eficaz.

Para acelerar o processo de geração de provas ZK, Merlin adotará a solução Prover como serviço da Lumoz, na verdade, é reunir um grande número de dispositivos de hardware para formar um pool de mineração e, em seguida, alocar tarefas de computação para diferentes dispositivos e atribuir incentivos correspondentes, o que é um pouco semelhante à mineração POW.

Nesta solução Prover descentralizada, existe um tipo de cenário de ataque, comumente conhecido como ataque de front-running: Suponha que um Agregador tenha estabelecido ZKP e envie ZKP para obter recompensas. Depois de outros agregadores verem o conteúdo de ZKP, eles publicam o mesmo conteúdo antes dele, alegando que ele gerou o ZKP primeiro. Como resolver esta situação?

Talvez a solução mais instintiva que todos pensam é atribuir um número de tarefa designado a cada Agregador. Por exemplo, apenas o Agregador A pode assumir a tarefa 1, e outros não receberão recompensas mesmo que completem a tarefa 1. Mas há um problema com esta abordagem, que é que não consegue resistir a riscos de ponto único. Se o Agregador A tiver uma falha de desempenho ou for desconectado, a tarefa 1 ficará parada e não poderá ser concluída. Além disso, este método de alocação de tarefas a uma única entidade não pode melhorar a eficiência de produção através de um mecanismo de incentivo competitivo, e não é uma boa abordagem.

Polygon zkEVM uma vez propôs um método chamado Proof of efficiency em um blog, que apontou que meios competitivos devem ser usados para promover a competição entre diferentes Aggregators, e os incentivos devem ser alocados com base no princípio do primeiro a chegar, primeiro a ser servido. O Aggregator que envia ZK-Proof à cadeia primeiro pode receber recompensas. Claro, ele não mencionou como resolver o problema de front-running MEV.

Lumoz adota um método de submissão de certificado ZK de verificação em duas etapas. Depois que um Agregador gera um certificado ZK, não precisa enviar o conteúdo completo primeiro, mas apenas publica o hash ZKP. Ou seja, publica o hash (ZKP+Endereço do Agregador). Dessa forma, mesmo que outros vejam o valor do hash, eles não conhecem o conteúdo ZKP correspondente e não podem avançar diretamente;

Se alguém simplesmente copiar o hash inteiro e publicá-lo primeiro, não fará sentido, porque o hash contém o endereço de um agregador específico X. Mesmo que o agregador A publique o hash primeiro, quando a imagem original do hash for revelada, todos verão que o endereço do agregador contido nele é X, não A.

Através deste esquema de submissão ZKP de verificação em duas etapas, Merlin (Lumoz) pode resolver o problema de front-running existente no processo de submissão ZKP, alcançando assim incentivos de geração de prova de conhecimento zero altamente competitivos, aumentando assim a velocidade de geração de ZKP.

Fantom de Merlin: Interoperabilidade multi-cadeia

De acordo com o roteiro de tecnologia da Merlin, eles também irão suportar a interoperabilidade entre a Merlin e outras cadeias EVM, sendo o seu caminho de implementação basicamente o mesmo que a ideia anterior da Zetachain. Se a Merlin for usada como a cadeia de origem e outras cadeias EVM forem usadas como a cadeia alvo, quando o nó Merlin detetar o pedido de interoperabilidade entre cadeias emitido pelo utilizador, irá desencadear o trabalho subsequente na cadeia alvo.

Por exemplo, uma conta EOA controlada pela rede Merlin pode ser implantada na Polygon. Quando um utilizador emite uma instrução de interoperabilidade entre cadeias na Cadeia Merlin, a Rede Merlin primeiro analisa o seu conteúdo e gera dados de transação a serem executados na cadeia de destino, e depois a Rede Oráculo realiza o processamento de assinatura MPC na transação para gerar a assinatura. O nó Relayer da Merlin depois liberta a transação na Polygon, completando operações subsequentes através dos ativos da Merlin na conta EOA na cadeia de destino, como.

Quando a operação solicitada pelo usuário for concluída, os ativos correspondentes serão enviados diretamente para o endereço do usuário na cadeia de destino. Na teoria, também pode ser transferido diretamente para a Cadeia Merlin. Esta solução tem alguns benefícios óbvios: pode evitar as taxas de processamento e o desgaste causado por contratos de ponte entre cadeias ao atravessar ativos tradicionais entre cadeias, e a segurança das operações entre cadeias é garantida diretamente pela Rede Oracle da Merlin, e não há necessidade de depender de infraestruturas de terceiros. Desde que os usuários confiem na Cadeia Merlin, tal comportamento de interoperabilidade entre cadeias pode ser assumido como sem problemas.

Resumir

Neste artigo, interpretamos brevemente a solução técnica geral da Cadeia Merlin, que acreditamos permitirá que mais pessoas entendam o fluxo de trabalho geral da Merlin e tenham uma compreensão mais clara do seu modelo de segurança. Considerando que o ecossistema atual do Bitcoin está em pleno andamento, acreditamos que esse tipo de atividades de popularização tecnológica são valiosas e necessárias para o público em geral. Realizaremos um acompanhamento a longo prazo da Merlin, bitLayer, B^Square e outros projetos no futuro, para uma análise mais aprofundada de suas soluções técnicas, portanto, fique atento!

Aviso legal:

1. Este artigo é reproduzido a partir de [geek web3], the copyright belongs to the original author [Faust], if you have any objection to the reprint, please contact Equipa Gate Learn, a equipa tratará dele o mais depressa possível de acordo com os procedimentos relevantes.

2. As opiniões e pontos de vista expressos neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões do artigo em outras línguas são traduzidas pela equipe Gate Learn. Sem fazer referênciaGate.io, copiar, distribuir ou plagiar os artigos traduzidos é proibido.