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 tranquilo dos ETFs spot, que estão livres de riscos de “securitização”, para atrair bilhões de dólares em investimentos para este setor em crescimento em apenas seis meses. Entre eles, o Merlin se destaca como a entidade mais substancial e seguida no cenário do Bitcoin Layer2, comandando bilhões em valor total bloqueado (TVL). Graças a incentivos claros de staking e retornos impressionantes, o Merlin rapidamente ganhou destaque, superando até mesmo o conhecido ecossistema Blast em questão de meses. Com o burburinho em torno do Merlin, a exploração de sua infraestrutura técnica cativou um público crescente. Neste artigo, o Geek Web3 concentra-se em decifrar as estratégias técnicas por trás da Merlin Chain. Ao desempacotar os documentos disponíveis publicamente e a lógica por trás do design de seu protocolo, nosso objetivo é desmistificar os processos operacionais do Merlin e aprimorar o entendimento de sua estrutura de segurança, fornecendo uma visão mais clara de como essa solução líder do Bitcoin Layer2 funciona.

Rede de Oráculo Descentralizado de Merlin: Um Comitê DAC Off-Chain Aberto

Para todas as tecnologias Layer2, abordar a disponibilidade de dados (DA) e o custo da publicação de dados permanece um desafio crítico, seja para a Layer2 do Ethereum ou para a Layer2 do Bitcoin. Dadas as limitações inerentes da rede Bitcoin, que luta com grande taxa de transferência de dados, estrategicamente usar de forma eficiente o valioso espaço de DA é um teste significativo para a criatividade dos desenvolvedores de Layer2.

É evidente que se os projetos Layer2 publicassem diretamente dados de transações brutos na blockchain do Bitcoin, eles falhariam em alcançar tanto alta capacidade quanto baixas taxas. As soluções predominantes incluem altamente comprimir os dados para reduzir significativamente seu tamanho antes de enviá-los para a blockchain do Bitcoin, ou optar por publicar os dados fora da cadeia.

Entre aqueles que empregam a primeira estratégia, Citrea se destaca. Eles têm como objetivo fazer upload de mudanças nos estados da Camada 2 em intervalos específicos, o que envolve gravar os resultados das mudanças de estado em várias contas, juntamente com as provas de conhecimento zero (ZKPs) correspondentes, na blockchain do Bitcoin. Sob este acordo, qualquer pessoa pode acessar as diferenças de estado e ZKPs da mainnet do Bitcoin para rastrear as mudanças de estado da Citrea. Esta abordagem reduz efetivamente o tamanho dos dados enviados para a blockchain em mais de 90%.

Embora isso possa comprimir muito 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 fazer upload de todas as mudanças nessas contas para a cadeia Bitcoin. O custo final da 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 de Bitcoin Layer 2 simplesmente seguem o segundo caminho: usam diretamente a solução DA sob a cadeia do Bitcoin, constroem uma camada DA por si mesmas ou usam Celestia, EigenDA, etc.B^Square, BitLayer e o protagonista deste artigo, Merlin, todos usam esta solução de expansão off-chain DA.

Artigo anterior no geek web3——“Análise do Roadmap da Tecnologia da Nova Versão B^2: A Necessidade da Camada de DA e Verificação sob a Cadeia Bitcoin”, mencionamos que B^2 imitou diretamente a 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 do Bitcoin, e apenas o datahash / raiz de merkle é carregado para o Bitcoin mainnet.

Isso essencialmente trata o Bitcoin como um quadro de avisos sem confiança: qualquer um pode ler o datahash da cadeia do Bitcoin. Após obter os dados do DA do provedor 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 provedor de dados off-chain estão corretos.

Camada DA explicada na Camada 2 do Bitcoin:

(Fonte da imagem: Geek web3)

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

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

Essa prática é conhecida como "retenção de dados." Em agosto de 2023, Dankrad da Ethereum Foundation iniciou uma discussão no Twitter sobre um conceito conhecido como "DAC".

Em muitas configurações Ethereum Layer2 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 liberou 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 limiar exigido (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 realmente liberou os dados completos da DA fora da cadeia.

Comitês DAC da camada 2 do Ethereum predominantemente aderem ao modelo de Prova de Autoridade (POA), limitando a adesão a um grupo seleto de nós que passaram pelo KYC ou foram oficialmente designados. Essa abordagem efetivamente marcou o DAC como um símbolo de "centralização" e "blockchain de consórcio". Além disso, em certas camadas 2 do Ethereum que utilizam a abordagem DAC, o sequenciador distribui dados DA exclusivamente para os nós membros do DAC, com mínima disseminação externa. Consequentemente, qualquer pessoa que busque dados DA deve obter aprovação do DAC, semelhante a operar dentro de um blockchain de consórcio.

Está claro que os DACs precisam ser descentralizados. Embora a Camada 2 possa não ser necessária para carregar os dados do DA diretamente para a Camada 1, o acesso à adesão do DAC deve ser público 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 do BlobStream visa fundamentalmente substituir um DAC centralizado pelo Celestia. Sob este modelo, um sequenciador Ethereum L2 postaria dados DA na blockchain da Celestia. Se dois terços dos nós da Celestia validarem esses 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, essa configuração maior do DAC é considerada relativamente descentralizada.

A solução DA adotada pela Merlin é na verdade relativamente próxima da BlobStream da Celestia, ambos os quais abrem acesso ao DAC através do 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 ele irá suportar apostas de ativos de BTC, MERL e até tokens BRC-20 para implementar um mecanismo flexível de aposta e também suportar apostas por procuração semelhantes ao Lido. (O acordo de aposta POS da máquina oráculo é basicamente um dos próximos 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. Após o sequenciador receber um grande número de solicitações de transação, ele as 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 de Merlin é descentralizado e usa o Prover da lumoz como um serviço. Depois de receber múltiplos lotes de dados, o pool de mineração do Prover gerará provas de conhecimento zero correspondentes. Posteriormente, o ZKP será enviado para o nó Oracle para verificação.

3. O nó Oracle verificará se a Prova ZK enviada pela pool de mineração ZK do Lmuoz corresponde aos Dados da Lote enviados pelo Sequenciador. Se os dois puderem ser correspondidos e não contiverem outros erros, a verificação é aprovada. Durante esse processo, os nós Oracle descentralizados gerarão multiassinaturas por meio de assinaturas de limite e declararão ao mundo exterior que o sequenciador enviou completamente os dados DA, e o ZKP correspondente é válido e passou na verificação dos nós Oracle.

4. O sequenciador coleta resultados de multi-assinatura dos nós do Oracle. Quando o número de assinaturas atende aos requisitos de limite, as informações de assinatura são enviadas para a cadeia do Bitcoin, juntamente com o datahash dos dados DA (lote de dados), e são entregues ao mundo exterior para leitura e confirmação.

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

1. Os nós da Oracle realizam um processamento especial no processo de cálculo para verificar a Prova de Conhecimento Zero, geram compromissos de Compromisso e os enviam para a cadeia Bitcoin, permitindo que qualquer pessoa desafie 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ó da Oracle que emitiu o Compromisso será punido financeiramente. Claro, os dados que a Oracle deseja publicar na cadeia do Bitcoin incluem também o hash do estado atual da Camada 2 - StateRoot, bem como o ZKP em si, que deve ser publicado na cadeia do Bitcoin 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 ser elaborados aqui. Em primeiro lugar, é mencionado no roadmap do Merlin que a Oracle fará backup dos dados DA para Celestia no futuro. Dessa forma, os nós da Oracle podem eliminar corretamente os dados históricos locais sem a necessidade de persistência de dados localmente. Ao mesmo tempo, o Compromisso gerado pela Rede Oracle é na verdade a raiz de uma Árvore de Merkle. Não é suficiente divulgar a raiz para o mundo exterior. O conjunto de dados completo correspondente ao Compromisso deve ser tornada pública. Isso requer encontrar uma plataforma DA de terceiros. Essa plataforma pode ser Celestia ou EigenDA, ou outras camadas DA.

Referências:“Análise do Roadmap 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 da Merlin, e acredito que você já dominou sua estrutura básica. Não é difícil ver que Merlin, B^Square, BitLayer e Citrea basicamente seguem o mesmo modelo de segurança — ZK-Rollup otimista.

Ao ler esta palavra pela primeira vez, muitos entusiastas do Ethereum podem se sentir estranhos. O que é "otimista ZK-Rollup"? No entendimento da comunidade Ethereum, o "modelo teórico" do ZK Rollup é completamente baseado na confiabilidade dos cálculos criptográficos e não requer a introdução de suposições de confiança. A palavra "otimista" introduz precisamente a suposição de confiança, o que significa que as pessoas, na maioria das vezes, são otimistas de que o Rollup não tem erros e é confiável. Uma vez que ocorre um erro, o operador do Rollup pode ser punido por meio 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 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 de Conhecimento Zero (ZK Proof). Ela só pode verificar uma certa etapa do processo de cálculo do ZKP em circunstâncias especiais. Sob essa premissa, a cadeia do Bitcoin na verdade só pode suportar o protocolo de prova de fraude. Pode-se apontar que há um erro em uma determinada etapa de cálculo do ZKP durante o processo de verificação off-chain, e desafiado através de prova de fraude. Claro, isso não pode ser comparado ao ZK Rollup no estilo Ethereum, mas já é o melhor que a Camada 2 do Bitcoin pode alcançar atualmente. Modelo de segurança confiável e mais seguro.

Sob o esquema otimista 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 consiga detectar erros e iniciar a prova de fraude a qualquer momento, a transição de estado da Camada 2 é segura. Claro, o Rollup otimista com um grau relativamente alto de conclusão precisa garantir que sua ponte de saque também seja protegida pelo protocolo de prova de fraude. No entanto, quase todos os Bitcoin de Camada 2 atualmente não podem alcançar essa premissa e precisam depender de assinatura múltipla/MPC. Então, como escolher a assinatura múltipla? A solução de assinatura do MPC tornou-se uma questão intimamente relacionada à segurança da Camada 2.

Merlin escolheu o serviço MPC da Cobo para a solução de ponte. Usando medidas como isolamento de carteiras quentes e frias, os ativos da ponte são gerenciados em conjunto pela Cobo e pela Merlin Chain. Qualquer comportamento de retirada precisa ser tratado em conjunto pelos participantes do MPC da Cobo e da Merlin Chain. Essencialmente, a confiabilidade da ponte de retirada é garantida por meio do endosso de crédito da instituição. . Claro, esta é apenas uma medida paliativa neste estágio. Conforme o projeto melhora gradualmente, a ponte de retirada pode ser substituída pela “ponte otimista” com uma suposição de confiança 1/N por meio 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 da Camada 2 atualmente dependem de multi-assinatura).

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

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

Em nossas discussões anteriores, aprofundamos o arcabouço de segurança do Merlin e exploramos o conceito inovador de ZK-rollups 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 liberados 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. Esse 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 Aggregator mescla essas provas individuais em um todo unificado. Essa 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 prova de conhecimento zero do Merlim, ele adotará a solução de Prover da Lumoz como serviço, na verdade, é reunir um grande número de dispositivos de hardware para formar um pool de mineração, e então alocar tarefas de computação para diferentes dispositivos e atribuir incentivos correspondentes, o que é um tanto semelhante à mineração de 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. Após 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 seja atribuir um número de tarefa designado a cada Agregador. Por exemplo, apenas o Agregador A pode pegar a tarefa 1, e outros não receberão recompensas mesmo se completarem a tarefa 1. Mas há um problema com essa abordagem, que é que ela não pode 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, esse método de alocação de tarefas a uma única entidade não pode melhorar a eficiência de produção por meio de um mecanismo de incentivo competitivo, e não é uma boa abordagem.

Polygon zkEVM uma vez propôs um método chamado Prova de eficiência em um blog, que apontou que meios competitivos devem ser usados para promover a competição entre diferentes Agregadores, e os incentivos devem ser alocados com base no princípio do primeiro a chegar, primeiro a ser servido. O Agregador que envia a Prova ZK à 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. Em outras palavras, publica o hash (ZKP+Endereço do Agregador). Dessa forma, mesmo que outros vejam o valor do hash, eles não sabem o conteúdo ZKP correspondente e não podem avançar diretamente;

Se alguém simplesmente copiar todo o hash e publicá-lo primeiro, não há sentido, porque o hash contém o endereço de um agregador específico X. Mesmo se o agregador A publicar o hash primeiro, quando a imagem original do hash for revelada, todos também verão que o endereço do agregador contido nele é o de X, não o de 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 darão suporte à interoperabilidade entre a Merlin e outras cadeias EVM, 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 de destino, quando o nó da Merlin perceber a solicitação de interoperabilidade entre cadeias emitida pelo usuário, ele ativará o trabalho subsequente na cadeia de destino. processo.

Por exemplo, uma conta EOA controlada pela rede Merlin pode ser implantada na Polygon. Quando um usuário emite uma instrução de interoperabilidade entre cadeias na Cadeia Merlin, a Rede Merlin primeiro analisa seu conteúdo e gera dados de transação a serem executados na cadeia de destino e, em seguida, a Rede Oracle realiza o processamento de assinatura MPC na transação para gerar a assinatura do número da transação. O nó Relayer da Merlin então libera a transação na Polygon, completa operações subsequentes por meio 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 de Merlin. Esta solução tem alguns benefícios óbvios: pode evitar as taxas de processamento e desgaste causadas por contratos de ponte entre cadeias ao atravessar ativos tradicionais entre cadeias, e a segurança das operações entre cadeias é diretamente garantida pela Rede Oracle da Merlin, e não é necessário confiar em partes externas. infraestrutura. Contanto que os usuários confiem na Cadeia de Merlin, esse comportamento de interoperabilidade entre cadeias pode ser assumido como sem problemas.

Resumo

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

Aviso legal:

1. Este artigo é reproduzido de [Gategeek web3], the copyright belongs to the original author [Faust], if you have any objection to the reprint, please contactGate Aprender Equipe, a equipe irá lidar com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. As visões e opiniões expressas neste artigo representam apenas as visões pessoais do autor e não constituem nenhum conselho de investimento.

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