Desde o verão das inscrições em 2023 até ao presente, Bitcoin Camada 2 sempre foi o ponto alto de toda a Web3. Embora a subir deste campo seja muito posterior à de Camada 2 em Ethereum, com o charme único da POW e o pouso suave da Ponto ETF, a Bitcoin sem considerar o risco de "securitização" atraiu a atenção de dezenas de bilhões de dólares de capital para a trilha derivativa de Camada 2 em apenas meio ano.
Na faixa Bitcoin Camada 2, Merlin, que tem bilhões de dólares em TVL, é, sem dúvida, o que tem o maior volume e o mais longo seguidores. Com claros incentivos de staking e um rendimento decente, Merlin surgiu quase em questão de meses, criando um mito ecológico que transcende Blast. Com a crescente popularidade da Merlin, a discussão das suas soluções técnicas tornou-se um tema cada vez mais longo.
Neste artigo, o Geek Web3 irá focar-se nas soluções técnicas da Merlin Chain, interpretar os seus documentos publicados e protocolo ideias de design, e estamos empenhados em permitir que mais pessoas longo compreendam o fluxo de trabalho geral da Merlin e tenham uma compreensão mais clara do seu modelo de segurança, para que todos possam compreender como este "head Bitcoin Camada 2" funciona de uma forma mais intuitiva.
Rede oráculo descentralizado Merlin: um conselho aberto fora da cadeia do CAD
Para todas as camadas 2, sejam elas Ethereum Camada 2 ou Bitcoin Camada 2, os custos de DA e de publicação de dados são um dos problemas mais importantes a serem resolvidos. Devido aos problemas mais longos da própria rede Bitcoin, que inerentemente não suporte grande taxa de transferência de dados, como usar este DA shorts tornou-se um problema difícil para testar a imaginação de Camada 2 projetos.
Uma conclusão é óbvia: se Camada 2 publicar "diretamente" dados de transações não processados para o Bitcoin Bloco, não será capaz de alcançar alta taxa de transferência ou taxas baixas. A solução mais popular é comprimir o tamanho dos dados o menor possível através de alta compressão e enviá-los para o Bitcoin Bloco, ou publicar os dados diretamente no Bitcoin fora da cadeia. **
Provavelmente a mais conhecida das Camada 2 camadas que adotam a primeira abordagem é a Citrea, que pretende carregar o diff de estado de Camada 2 ao longo de um período de tempo, ou seja, os resultados da mudança de estado em longo conta, juntamente com as provas ZK correspondentes, para o Bitcoin na cadeia. Neste caso, qualquer pessoa pode baixar o diff de estado e ZKP do Bitcoin Rede principal para monitorar os resultados da mudança de estado Citrea. Este método pode reduzir o tamanho dos dados na cadeia em mais de 90%.
Embora isso possa reduzir muito o tamanho dos dados, o gargalo ainda é significativo. Se um grande número de alterações de estado de conta ocorrer em um curto período de tempo, Camada 2 precisa resumir e carregar todas as alterações desses conta para o Bitcoin na cadeia, e o custo final de liberação de dados não pode ser mantido muito baixo, o que pode ser visto no longo Ethereum ZK Rollup.
É muito longo Bitcoin Camada 2 simplesmente tomar o segundo caminho: usar diretamente a solução de DA Bitcoin fora da cadeia, construir uma camada de DA por si só, ou usar Celestia, EigenDA, etc. B^Square, BitLayer e Merlin, o protagonista deste artigo, seguem este fora da cadeia esquema de escalonamento DA.
No artigo anterior do Geek web3 - "Analyzing the New Version of B^2 Technology Roadmap: The Need of Bitcoin fora da cadeia DA and Verification Layer", mencionamos que **B^2 imita diretamente Celestia e constrói uma rede DA que suporta a função de amostragem de dados no fora da cadeia, chamada B^2 Hub. "Dados DA", como dados de transação ou diff de estado, são armazenados no Bitcoin fora da cadeia e apenas a raiz datahash/merkle é carregada no Bitcoin Rede principal. **
É realmente tratar Bitcoin como um quadro de avisos Sem confiança: qualquer pessoa pode ler datahash de Bitcoin na cadeia. Quando você obtém dados DA do provedor de dados fora da cadeia, você pode verificar se eles correspondem ao na cadeia datahash, ou seja, hash(data1) == datahash1 ?. Se houver uma correspondência entre os dois, isso significa que o provedor de dados sob o fora da cadeia lhe forneceu os dados corretos.
O processo acima pode garantir que os dados fornecidos a você pela fora da cadeia Nó estejam associados a certas "pistas" na Camada 1, impedindo que a camada DA forneça dados falsos de forma maliciosa. Mas há um cenário de pino muito importante aqui: e se a fonte dos dados, Sequencer, não enviar os dados correspondentes do datahash, mas apenas enviar o datahash para o Bitcoin na cadeia, mas deliberadamente reter os dados correspondentes de qualquer pessoa para lê-los?
Cenários semelhantes incluem, mas não estão limitados a, apenas publicar ZK-Proof e StateRoot, mas não publicar os dados DA correspondentes (diff de estado ou dados de transação), embora as pessoas possam verificar se o processo de cálculo ZKProof é válido e certificar-se de que o processo de cálculo de Prev_Stateroot para New_Stateroot é válido, mas eles não sabem qual conta estado (estado) foi alterado. Nesse caso, embora os ativos do usuário estejam seguros, você não pode determinar o estado real da rede e não sabe quais transações foram empacotadas na cadeia e quais contratos foram atualizados.
Na verdade, trata-se de "retenção de dados**", e Dankrad, da Fundação Ethereum, discutiu brevemente uma questão semelhante no Twitter em agosto de 2023, é claro, ele está vela de pavio longo principalmente por algo chamado "DAC".
A Camada de Ethereum mais longa, que adota soluções de DA fora da cadeia, geralmente configura vários nós com permissões especiais para formar um comitê, o nome completo de Comitê de Disponibilidade de Dados (DAC). Este comité do CAD atua como garante, alegando que o Sequencer publica os dados DA completos (dados de transação ou comparação de estados) fora da cadeia. Em seguida, o Nó do DAC gera coletivamente um mais longo, longo quanto o mais longo atender aos requisitos de limite (como 2/4), o contrato relevante na Camada 1 será inadimplente, e o Sequencer passou pela inspeção do comitê do DAC e divulgou com verdade os dados completos do DA fora da cadeia.
O comitê de DAC de Ethereum Camada 2 basicamente segue o modelo POA, permitindo que apenas alguns nós KYC ou oficialmente designados se juntem ao comitê de DAC, o que torna o DAC sinônimo de "centralizado" e "blockchain de consórcio". Além disso, em alguns dos Ethereum Camada 2 que adotam o modelo de DAC, o sequenciador apenas envia dados DA para nós membros do DAC, e quase nunca carrega dados em outro lugar, e qualquer pessoa que queira obter dados DA deve obter a permissão do comitê de DAC, que não é fundamentalmente diferente do Blockchain de consórcio.
Não há dúvida de que o CAD deve ser Descentralização, e Camada 2 não pode carregar dados DA diretamente para a Camada 1, mas a autoridade de acesso do comitê do CAD deve estar aberta ao mundo exterior para evitar que algumas pessoas sejam coniventes para fazer o mal. (Para uma discussão sobre o cenário de travessuras do DAC, consulte a declaração anterior de Dankrad no Twitter)
**BlobStream, anteriormente proposto pela Celestia, é essencialmente para substituir DAC centralizado por Celestia, **Ethereum sequenciador L2 pode publicar dados DA para o Celestia na cadeia, se 2/3 do nó Celestia assinar, o contrato exclusivo Layer2 implantado em Ethereum acredita que o sequenciador realmente libera dados DA, que na verdade é deixar o Celestia Nó agir como um garante. Considerando que Celestia tem centenas de nós validadores, podemos considerar este grande DAC como sendo relativamente descentralizador.
**A solução DA usada pela Merlin está na verdade próxima do BlobStream da Celestia, que abre os direitos de acesso do DAC na forma de PDV para torná-lo tendencialmente descentralizado. Qualquer pessoa pode executar um Nó de DAC tão longo quanto stake ativos suficientes. Na documentação de Merlin, o Nó de DAC acima é referido como Oracle, e é apontado que o staking de ativos de BTC, MERL e até mesmo BRC-20 Tokens será suportado, permitindo um mecanismo de staking flexível, bem como proxy staking semelhante ao Lido. (O stake protocolo POS de Máquina Oracle é basicamente uma das próximas narrativas centrais de Merlin, e as stake Taxa de juros fornecidas são relativamente altas)
Aqui está uma breve descrição do fluxo de trabalho da Merlin (imagem abaixo):
Depois de receber um grande número de solicitações de transação, o sequenciador as agrega e gera um lote de dados, que é passado para o Prover Nó e o Oracle Nó (Descentralização DAC).
O Prover Nó da Merlin é Descentralização, usando o serviço Prover as a Service da Lumoz. Depois de receber os lotes de dados mais longos, o pool de mineração do Prover gerará a zk-SNARKs correspondente, após o que o ZKP será enviado ao Nó Oracle para verificação.
O Oracle Nó verificará se a Prova ZK enviada pelo Pool de mineração ZK da Lmuoz corresponde ao Lote de dados enviado pelo Sequencer. Se os dois podem ser correspondidos, e não há outros erros, verifica-se. Nesse processo, Descentralização Oracle Nodes gerarão assinaturas mais longo por meio de assinaturas de limite e declararão externamente - o sequenciador emitiu completamente dados DA, e o ZKP correspondente é válido, o que passou pela verificação do Oracle Nó.
O sequenciador coleta longo resultados de assinatura do Oracle Nó e, quando o número de assinaturas atende aos requisitos de limite, envia as informações de assinatura para o Bitcoin na cadeia, com um datahash do lote de dados DA, e as entrega para o mundo exterior para ler e confirmar.
A Oracle Nó processamento especial de seu processo de cálculo para verificar ZK Proof, gerar um compromisso de compromisso, enviá-lo para o Bitcoin na cadeia e permitir que qualquer pessoa conteste o "compromisso", e o processo neste processo é basicamente o mesmo que o prova de fraude protocolo de bitVM. Se o desafio for bem-sucedido, o Nó Oracle que publicar o Compromisso será penalizado financeiramente. É claro que os dados que a Oracle deseja publicar no Bitcoin na cadeia, incluindo a hash do estado atual do Camada 2 - StateRoot, e o próprio ZKP, devem ser publicados no Bitcoin na cadeia para que o mundo exterior detete.
Ainda há alguns detalhes que precisam ser elaborados, em primeiro lugar, o roadmap de Merlin menciona que, no futuro, a Oracle fará backup de dados DA para Celestia, para que os Nó Oracle possam eliminar adequadamente os dados históricos locais e não precisem manter os dados localmente para sempre. Ao mesmo tempo, o Compromisso gerado pela Oracle Network é, na verdade, a raiz de um Árvore de Merkle, e não basta divulgar a raiz para o mundo exterior, mas para divulgar todos os conjuntos de dados completos correspondentes ao Compromisso, é necessário encontrar uma plataforma DA de terceiros, que pode ser Celestia, EigenDA, ou outras camadas DA.
Análise do Modelo de Segurança: Serviço de MPC da ZKRollup+Cobo otimista
Acima, descrevemos brevemente o fluxo de trabalho do Merlin, e acredito que você já tenha uma boa compreensão de sua estrutura básica. Não é difícil ver que Merlin basicamente segue o mesmo modelo de segurança que B^Square, BitLayer e Citrea - o otimista ZK-Rollup.
A primeira leitura desta palavra pode fazer com que muitos entusiastas longo Ethereum se sintam estranhos, o que é o "ZK-Rollup otimista"? Na cognição da comunidade Ethereum, o "modelo teórico" do ZK Rollup é completamente baseado na confiabilidade dos cálculos de Criptografia, e não há necessidade de introduzir suposições de confiança, e a palavra otimismo introduz precisamente suposições de confiança, o que significa que as pessoas devem ser otimistas de que os Rollups não estão errados e confiáveis quando longo um grande número de vezes. E uma vez que haja um erro, o operador do Rollup pode ser punido com prova de fraude, que é a origem do nome Optimistic Rollup, também conhecido como OP Rollup.
Para o ecossistema Ethereum da base do Rollup, o otimista ZK-Rollup pode ser um pouco incomum, mas isso está exatamente em linha com a situação atual do Bitcoin Camada 2. Devido a limitações técnicas, Bitcoin na cadeia não pode verificar totalmente ZK Proof, só pode verificar uma determinada etapa do processo de cálculo ZKP em circunstâncias especiais, sob esta premissa, Bitcoin na cadeia só pode realmente suporte prova de fraude protocolo, as pessoas podem apontar que ZKP no processo de verificação fora da cadeia, uma determinada etapa de cálculo tem um erro, e através da prova de fraude maneira de desafiar, é claro, isso não pode ser comparado com o ZK Rollup estilo Ethereum, mas Bitcoin já é o mais confiável e O modelo de segurança mais robusto.
Sob o esquema otimista ZK-Rollup acima, supondo que haja N desafiantes autorizados na rede Camada 2, longo como 1 desses desafiantes N é honesto e confiável, e pode detetar erros e iniciar prova de fraude a qualquer momento, a transição de estado de Camada 2 é segura. É claro que rollups otimistas com um grau relativamente alto de conclusão precisam garantir que suas pontes de retirada também sejam protegidas por prova de fraude protocolo e, atualmente, quase todas as Bitcoin Camada 2 não conseguem alcançar essa premissa e precisam confiar em longo assinatura/MPC, então como escolher a solução longo assinatura/MPC tornou-se um problema intimamente relacionado à segurança da Camada 2.
A Merlin escolheu o serviço de MPC da Cobo no esquema de ponte, usando medidas como isolamento de carteira fria e quente, os ativos das pontes são geridos conjuntamente pela Cobo e pela Merlin Chain, e qualquer retirada precisa ser tratada conjuntamente pelos participantes MPC da Cobo e da Merlin Chain, garantindo essencialmente a confiabilidade do ponte de retirada através do endosso de crédito da instituição. Claro, esta é apenas uma medida paliativa nesta fase, e com a melhoria gradual do projeto, o ponte de retirada pode ser substituído pelo "ponte otimista" da suposição de confiança 1/N introduzindo BitVM e prova de fraude protocolo, mas será mais difícil pousar (atualmente, quase todas as pontes oficiais da Layer2 dependem de longo sinal).
No geral, podemos descobrir que a Merlin introduziu um DAC baseado em POS, um ZK-Rollup otimista baseado em BitVM e uma solução de custódia de ativos MPC baseada em Cobo, resolveu o problema de DA abrindo permissões de DAC, garantiu a segurança da transição de estado introduzindo BitVM e prova de fraude protocolo e garantiu a confiabilidade do ponte de retirada introduzindo o serviço de MPC da conhecida plataforma de custódia de ativos Cobo.
Esquema de submissão ZKP de verificação em duas etapas baseado em Lumoz
Anteriormente, vasculhamos o modelo de segurança da Merlin e introduzimos o conceito de ZK-rollup otimista. No roteiro tecnológico da Merlin, Descentralização Prover também é discutido. Como todos sabemos, o Prover é um papel central na arquitetura ZK-Rollup, que é responsável por gerar ZKProofs para lotes lançados pelo Sequencer, e o processo de geração de zk-SNARKs é muito intensivo em recursos de hardware e um problema muito complicado.
Para acelerar a geração de provas ZK, paralelizar a tarefa é uma das operações mais básicas. **A chamada paralelização é, na verdade, dividir a tarefa de geração de prova ZK em diferentes partes, que são completadas separadamente por diferentes Provers, e finalmente o agregador agregador agregador a prova mais longa em um todo.
Em ordem de acelerar o processo de geração de provas ZK, Merlin usará o Prover da Lumoz como uma solução de serviço, que na verdade é reunir um grande número de dispositivos de hardware juntos para formar um pool de mineração e, em seguida, atribuir tarefas de computação a diferentes dispositivos e atribuir incentivos correspondentes, semelhante à mineração POW.
Neste esquema Descentralização Prover, há uma classe de cenários de ataque, comumente conhecidos como ataques front-running: Suponha que um agregador Aggregator formou um ZKP e envia o ZKP na esperança de receber uma recompensa. Depois que outros agregadores viram o conteúdo do ZKP, eles correram para postar o mesmo conteúdo na frente dele, alegando que esse ZKP foi feito pelo próprio marido, como resolver essa situação?
Uma das soluções mais instintivas que podem vir à mente é atribuir um número de tarefa específico a cada Agregador, por exemplo, apenas o Agregador A pode assumir a tarefa 1, e todos os outros não receberão uma recompensa, mesmo que concluam a tarefa 1. Mas um dos problemas dessa abordagem é que ela não protege contra um único ponto de risco. Se o Agregador A tiver uma falha de desempenho ou se desconectar, a Tarefa 1 ficará presa e não poderá ser concluída. Além disso, esta prática de atribuir tarefas a uma única entidade não é uma boa forma de melhorar a produtividade com incentivos competitivos.
A Polygon zkEVM propôs um método chamado Prova de eficiência em uma postagem de blog, que afirma que diferentes Agregadores devem ser promovidos para competir uns com os outros de forma competitiva, e que os incentivos devem ser distribuídos por ordem de chegada, e que os primeiros Agregadores a enviar ZK-Proof para a cadeia podem receber recompensas. Claro, ele não mencionou como resolver o problema MEV front-running.
Lumoz usa um método de submissão de prova ZK de verificação em duas etapas, depois que um Agregador gera uma prova ZK, ele não precisa enviar o conteúdo completo, mas apenas publica o hash do ZKP, ou seja, publica o hash (ZKP+Aggregator Endereço). Desta forma, mesmo que outros vejam o valor hash, eles não sabem o conteúdo ZKP correspondente e não podem apressá-lo diretamente;
Se alguém simplesmente copia o hash inteiro e o publica primeiro, não faz sentido, porque o hash contém o Endereço de um agregador específico X, e mesmo que o agregador A publique o hash primeiro, quando a imagem original do hash for revelada, todos verão que o agregador Endereço 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 no processo de submissão ZKP e, em seguida, realizar incentivos de geração de zk-SNARKs altamente competitivos, melhorando assim a velocidade de geração do ZKP.
Merlin's Phantom: interoperabilidade de cadeia mais longa
De acordo com o roteiro técnico do Merlin, eles também suporte a interoperabilidade entre o Merlin e outras cadeias de EVM, e seu caminho de implementação é basicamente o mesmo que a ideia anterior do Zetachain, se o Merlin for usado como a cadeia de origem e outras cadeias de EVM forem usadas como a cadeia de destino, quando o Nó Merlin perceber a solicitação de interoperabilidade cadeia cruzada feita pelo usuário, ele acionará o fluxo de trabalho subsequente no na cadeia de destino.
Por exemplo, um conta EOA controlado pela rede Merlin pode ser implantado no Polygon, ** Quando um usuário publica uma instrução de interoperabilidade cadeia cruzada no Merlin Chain, a rede Merlin primeiro analisa seu conteúdo e gera dados de transação executados no na cadeia de destino e, em seguida, o processamento de assinatura do Oracle Network MPC na transação gera uma assinatura digital da transação. O Relayer da Merlin Nó então libera a transação ** no Polygon, completando as operações subsequentes através dos ativos da Merlin no EOA conta no na cadeia alvo.
Quando a operação requerida pelo usuário for concluída, o ativo correspondente será encaminhado diretamente para o endereço do usuário no na cadeia de destino e, teoricamente, também poderá cruzar diretamente para a Cadeia Merlin. Esta solução tem algumas vantagens óbvias: pode evitar o desgaste das taxas geradas pelos cadeia cruzada de ativos tradicionais e contratos de pontes de cadeia cruzada, e é diretamente garantida pela Rede Oracle da Merlin para garantir a segurança de cadeia cruzada operações, e não mais longo necessidade de depender de infraestrutura externa. Por mais longo que os usuários confiem no Merlin Chain, não há problema em usar essa cadeia cruzada interoperabilidade.
Resumo
Neste artigo, damos uma breve explicação da solução técnica geral da Merlin Chain, que se acredita ajudar mais longo pessoas a entender o fluxo de trabalho geral da Merlin e ter uma compreensão mais clara de seu modelo de segurança. Considerando a ecologia Bitcoin atual em pleno andamento, acreditamos que este tipo de comportamento de popularização da ciência técnica é valioso e necessário para o público em geral, Vamos realizar um acompanhamento de longo prazo sobre Merlin e bitLayer, B^Square e outros projetos no futuro, e realizar uma análise mais aprofundada de suas soluções técnicas, então manter-se atento!
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Interpretação técnica do mecanismo de funcionamento da Merlin
Autor: Fausto, geek web3
Desde o verão das inscrições em 2023 até ao presente, Bitcoin Camada 2 sempre foi o ponto alto de toda a Web3. Embora a subir deste campo seja muito posterior à de Camada 2 em Ethereum, com o charme único da POW e o pouso suave da Ponto ETF, a Bitcoin sem considerar o risco de "securitização" atraiu a atenção de dezenas de bilhões de dólares de capital para a trilha derivativa de Camada 2 em apenas meio ano.
Na faixa Bitcoin Camada 2, Merlin, que tem bilhões de dólares em TVL, é, sem dúvida, o que tem o maior volume e o mais longo seguidores. Com claros incentivos de staking e um rendimento decente, Merlin surgiu quase em questão de meses, criando um mito ecológico que transcende Blast. Com a crescente popularidade da Merlin, a discussão das suas soluções técnicas tornou-se um tema cada vez mais longo.
Neste artigo, o Geek Web3 irá focar-se nas soluções técnicas da Merlin Chain, interpretar os seus documentos publicados e protocolo ideias de design, e estamos empenhados em permitir que mais pessoas longo compreendam o fluxo de trabalho geral da Merlin e tenham uma compreensão mais clara do seu modelo de segurança, para que todos possam compreender como este "head Bitcoin Camada 2" funciona de uma forma mais intuitiva.
Rede oráculo descentralizado Merlin: um conselho aberto fora da cadeia do CAD
Para todas as camadas 2, sejam elas Ethereum Camada 2 ou Bitcoin Camada 2, os custos de DA e de publicação de dados são um dos problemas mais importantes a serem resolvidos. Devido aos problemas mais longos da própria rede Bitcoin, que inerentemente não suporte grande taxa de transferência de dados, como usar este DA shorts tornou-se um problema difícil para testar a imaginação de Camada 2 projetos.
Uma conclusão é óbvia: se Camada 2 publicar "diretamente" dados de transações não processados para o Bitcoin Bloco, não será capaz de alcançar alta taxa de transferência ou taxas baixas. A solução mais popular é comprimir o tamanho dos dados o menor possível através de alta compressão e enviá-los para o Bitcoin Bloco, ou publicar os dados diretamente no Bitcoin fora da cadeia. **
Provavelmente a mais conhecida das Camada 2 camadas que adotam a primeira abordagem é a Citrea, que pretende carregar o diff de estado de Camada 2 ao longo de um período de tempo, ou seja, os resultados da mudança de estado em longo conta, juntamente com as provas ZK correspondentes, para o Bitcoin na cadeia. Neste caso, qualquer pessoa pode baixar o diff de estado e ZKP do Bitcoin Rede principal para monitorar os resultados da mudança de estado Citrea. Este método pode reduzir o tamanho dos dados na cadeia em mais de 90%.
Embora isso possa reduzir muito o tamanho dos dados, o gargalo ainda é significativo. Se um grande número de alterações de estado de conta ocorrer em um curto período de tempo, Camada 2 precisa resumir e carregar todas as alterações desses conta para o Bitcoin na cadeia, e o custo final de liberação de dados não pode ser mantido muito baixo, o que pode ser visto no longo Ethereum ZK Rollup.
É muito longo Bitcoin Camada 2 simplesmente tomar o segundo caminho: usar diretamente a solução de DA Bitcoin fora da cadeia, construir uma camada de DA por si só, ou usar Celestia, EigenDA, etc. B^Square, BitLayer e Merlin, o protagonista deste artigo, seguem este fora da cadeia esquema de escalonamento DA.
No artigo anterior do Geek web3 - "Analyzing the New Version of B^2 Technology Roadmap: The Need of Bitcoin fora da cadeia DA and Verification Layer", mencionamos que **B^2 imita diretamente Celestia e constrói uma rede DA que suporta a função de amostragem de dados no fora da cadeia, chamada B^2 Hub. "Dados DA", como dados de transação ou diff de estado, são armazenados no Bitcoin fora da cadeia e apenas a raiz datahash/merkle é carregada no Bitcoin Rede principal. **
É realmente tratar Bitcoin como um quadro de avisos Sem confiança: qualquer pessoa pode ler datahash de Bitcoin na cadeia. Quando você obtém dados DA do provedor de dados fora da cadeia, você pode verificar se eles correspondem ao na cadeia datahash, ou seja, hash(data1) == datahash1 ?. Se houver uma correspondência entre os dois, isso significa que o provedor de dados sob o fora da cadeia lhe forneceu os dados corretos.
O processo acima pode garantir que os dados fornecidos a você pela fora da cadeia Nó estejam associados a certas "pistas" na Camada 1, impedindo que a camada DA forneça dados falsos de forma maliciosa. Mas há um cenário de pino muito importante aqui: e se a fonte dos dados, Sequencer, não enviar os dados correspondentes do datahash, mas apenas enviar o datahash para o Bitcoin na cadeia, mas deliberadamente reter os dados correspondentes de qualquer pessoa para lê-los?
Cenários semelhantes incluem, mas não estão limitados a, apenas publicar ZK-Proof e StateRoot, mas não publicar os dados DA correspondentes (diff de estado ou dados de transação), embora as pessoas possam verificar se o processo de cálculo ZKProof é válido e certificar-se de que o processo de cálculo de Prev_Stateroot para New_Stateroot é válido, mas eles não sabem qual conta estado (estado) foi alterado. Nesse caso, embora os ativos do usuário estejam seguros, você não pode determinar o estado real da rede e não sabe quais transações foram empacotadas na cadeia e quais contratos foram atualizados.
Na verdade, trata-se de "retenção de dados**", e Dankrad, da Fundação Ethereum, discutiu brevemente uma questão semelhante no Twitter em agosto de 2023, é claro, ele está vela de pavio longo principalmente por algo chamado "DAC".
A Camada de Ethereum mais longa, que adota soluções de DA fora da cadeia, geralmente configura vários nós com permissões especiais para formar um comitê, o nome completo de Comitê de Disponibilidade de Dados (DAC). Este comité do CAD atua como garante, alegando que o Sequencer publica os dados DA completos (dados de transação ou comparação de estados) fora da cadeia. Em seguida, o Nó do DAC gera coletivamente um mais longo, longo quanto o mais longo atender aos requisitos de limite (como 2/4), o contrato relevante na Camada 1 será inadimplente, e o Sequencer passou pela inspeção do comitê do DAC e divulgou com verdade os dados completos do DA fora da cadeia.
O comitê de DAC de Ethereum Camada 2 basicamente segue o modelo POA, permitindo que apenas alguns nós KYC ou oficialmente designados se juntem ao comitê de DAC, o que torna o DAC sinônimo de "centralizado" e "blockchain de consórcio". Além disso, em alguns dos Ethereum Camada 2 que adotam o modelo de DAC, o sequenciador apenas envia dados DA para nós membros do DAC, e quase nunca carrega dados em outro lugar, e qualquer pessoa que queira obter dados DA deve obter a permissão do comitê de DAC, que não é fundamentalmente diferente do Blockchain de consórcio.
Não há dúvida de que o CAD deve ser Descentralização, e Camada 2 não pode carregar dados DA diretamente para a Camada 1, mas a autoridade de acesso do comitê do CAD deve estar aberta ao mundo exterior para evitar que algumas pessoas sejam coniventes para fazer o mal. (Para uma discussão sobre o cenário de travessuras do DAC, consulte a declaração anterior de Dankrad no Twitter)
**BlobStream, anteriormente proposto pela Celestia, é essencialmente para substituir DAC centralizado por Celestia, **Ethereum sequenciador L2 pode publicar dados DA para o Celestia na cadeia, se 2/3 do nó Celestia assinar, o contrato exclusivo Layer2 implantado em Ethereum acredita que o sequenciador realmente libera dados DA, que na verdade é deixar o Celestia Nó agir como um garante. Considerando que Celestia tem centenas de nós validadores, podemos considerar este grande DAC como sendo relativamente descentralizador.
**A solução DA usada pela Merlin está na verdade próxima do BlobStream da Celestia, que abre os direitos de acesso do DAC na forma de PDV para torná-lo tendencialmente descentralizado. Qualquer pessoa pode executar um Nó de DAC tão longo quanto stake ativos suficientes. Na documentação de Merlin, o Nó de DAC acima é referido como Oracle, e é apontado que o staking de ativos de BTC, MERL e até mesmo BRC-20 Tokens será suportado, permitindo um mecanismo de staking flexível, bem como proxy staking semelhante ao Lido. (O stake protocolo POS de Máquina Oracle é basicamente uma das próximas narrativas centrais de Merlin, e as stake Taxa de juros fornecidas são relativamente altas)
Aqui está uma breve descrição do fluxo de trabalho da Merlin (imagem abaixo):
A Oracle Nó processamento especial de seu processo de cálculo para verificar ZK Proof, gerar um compromisso de compromisso, enviá-lo para o Bitcoin na cadeia e permitir que qualquer pessoa conteste o "compromisso", e o processo neste processo é basicamente o mesmo que o prova de fraude protocolo de bitVM. Se o desafio for bem-sucedido, o Nó Oracle que publicar o Compromisso será penalizado financeiramente. É claro que os dados que a Oracle deseja publicar no Bitcoin na cadeia, incluindo a hash do estado atual do Camada 2 - StateRoot, e o próprio ZKP, devem ser publicados no Bitcoin na cadeia para que o mundo exterior detete.
Ainda há alguns detalhes que precisam ser elaborados, em primeiro lugar, o roadmap de Merlin menciona que, no futuro, a Oracle fará backup de dados DA para Celestia, para que os Nó Oracle possam eliminar adequadamente os dados históricos locais e não precisem manter os dados localmente para sempre. Ao mesmo tempo, o Compromisso gerado pela Oracle Network é, na verdade, a raiz de um Árvore de Merkle, e não basta divulgar a raiz para o mundo exterior, mas para divulgar todos os conjuntos de dados completos correspondentes ao Compromisso, é necessário encontrar uma plataforma DA de terceiros, que pode ser Celestia, EigenDA, ou outras camadas DA.
Análise do Modelo de Segurança: Serviço de MPC da ZKRollup+Cobo otimista
Acima, descrevemos brevemente o fluxo de trabalho do Merlin, e acredito que você já tenha uma boa compreensão de sua estrutura básica. Não é difícil ver que Merlin basicamente segue o mesmo modelo de segurança que B^Square, BitLayer e Citrea - o otimista ZK-Rollup.
A primeira leitura desta palavra pode fazer com que muitos entusiastas longo Ethereum se sintam estranhos, o que é o "ZK-Rollup otimista"? Na cognição da comunidade Ethereum, o "modelo teórico" do ZK Rollup é completamente baseado na confiabilidade dos cálculos de Criptografia, e não há necessidade de introduzir suposições de confiança, e a palavra otimismo introduz precisamente suposições de confiança, o que significa que as pessoas devem ser otimistas de que os Rollups não estão errados e confiáveis quando longo um grande número de vezes. E uma vez que haja um erro, o operador do Rollup pode ser punido com prova de fraude, que é a origem do nome Optimistic Rollup, também conhecido como OP Rollup.
Para o ecossistema Ethereum da base do Rollup, o otimista ZK-Rollup pode ser um pouco incomum, mas isso está exatamente em linha com a situação atual do Bitcoin Camada 2. Devido a limitações técnicas, Bitcoin na cadeia não pode verificar totalmente ZK Proof, só pode verificar uma determinada etapa do processo de cálculo ZKP em circunstâncias especiais, sob esta premissa, Bitcoin na cadeia só pode realmente suporte prova de fraude protocolo, as pessoas podem apontar que ZKP no processo de verificação fora da cadeia, uma determinada etapa de cálculo tem um erro, e através da prova de fraude maneira de desafiar, é claro, isso não pode ser comparado com o ZK Rollup estilo Ethereum, mas Bitcoin já é o mais confiável e O modelo de segurança mais robusto.
Sob o esquema otimista ZK-Rollup acima, supondo que haja N desafiantes autorizados na rede Camada 2, longo como 1 desses desafiantes N é honesto e confiável, e pode detetar erros e iniciar prova de fraude a qualquer momento, a transição de estado de Camada 2 é segura. É claro que rollups otimistas com um grau relativamente alto de conclusão precisam garantir que suas pontes de retirada também sejam protegidas por prova de fraude protocolo e, atualmente, quase todas as Bitcoin Camada 2 não conseguem alcançar essa premissa e precisam confiar em longo assinatura/MPC, então como escolher a solução longo assinatura/MPC tornou-se um problema intimamente relacionado à segurança da Camada 2.
A Merlin escolheu o serviço de MPC da Cobo no esquema de ponte, usando medidas como isolamento de carteira fria e quente, os ativos das pontes são geridos conjuntamente pela Cobo e pela Merlin Chain, e qualquer retirada precisa ser tratada conjuntamente pelos participantes MPC da Cobo e da Merlin Chain, garantindo essencialmente a confiabilidade do ponte de retirada através do endosso de crédito da instituição. Claro, esta é apenas uma medida paliativa nesta fase, e com a melhoria gradual do projeto, o ponte de retirada pode ser substituído pelo "ponte otimista" da suposição de confiança 1/N introduzindo BitVM e prova de fraude protocolo, mas será mais difícil pousar (atualmente, quase todas as pontes oficiais da Layer2 dependem de longo sinal).
No geral, podemos descobrir que a Merlin introduziu um DAC baseado em POS, um ZK-Rollup otimista baseado em BitVM e uma solução de custódia de ativos MPC baseada em Cobo, resolveu o problema de DA abrindo permissões de DAC, garantiu a segurança da transição de estado introduzindo BitVM e prova de fraude protocolo e garantiu a confiabilidade do ponte de retirada introduzindo o serviço de MPC da conhecida plataforma de custódia de ativos Cobo.
Esquema de submissão ZKP de verificação em duas etapas baseado em Lumoz
Anteriormente, vasculhamos o modelo de segurança da Merlin e introduzimos o conceito de ZK-rollup otimista. No roteiro tecnológico da Merlin, Descentralização Prover também é discutido. Como todos sabemos, o Prover é um papel central na arquitetura ZK-Rollup, que é responsável por gerar ZKProofs para lotes lançados pelo Sequencer, e o processo de geração de zk-SNARKs é muito intensivo em recursos de hardware e um problema muito complicado.
Para acelerar a geração de provas ZK, paralelizar a tarefa é uma das operações mais básicas. **A chamada paralelização é, na verdade, dividir a tarefa de geração de prova ZK em diferentes partes, que são completadas separadamente por diferentes Provers, e finalmente o agregador agregador agregador a prova mais longa em um todo.
Em ordem de acelerar o processo de geração de provas ZK, Merlin usará o Prover da Lumoz como uma solução de serviço, que na verdade é reunir um grande número de dispositivos de hardware juntos para formar um pool de mineração e, em seguida, atribuir tarefas de computação a diferentes dispositivos e atribuir incentivos correspondentes, semelhante à mineração POW.
Neste esquema Descentralização Prover, há uma classe de cenários de ataque, comumente conhecidos como ataques front-running: Suponha que um agregador Aggregator formou um ZKP e envia o ZKP na esperança de receber uma recompensa. Depois que outros agregadores viram o conteúdo do ZKP, eles correram para postar o mesmo conteúdo na frente dele, alegando que esse ZKP foi feito pelo próprio marido, como resolver essa situação?
Uma das soluções mais instintivas que podem vir à mente é atribuir um número de tarefa específico a cada Agregador, por exemplo, apenas o Agregador A pode assumir a tarefa 1, e todos os outros não receberão uma recompensa, mesmo que concluam a tarefa 1. Mas um dos problemas dessa abordagem é que ela não protege contra um único ponto de risco. Se o Agregador A tiver uma falha de desempenho ou se desconectar, a Tarefa 1 ficará presa e não poderá ser concluída. Além disso, esta prática de atribuir tarefas a uma única entidade não é uma boa forma de melhorar a produtividade com incentivos competitivos.
A Polygon zkEVM propôs um método chamado Prova de eficiência em uma postagem de blog, que afirma que diferentes Agregadores devem ser promovidos para competir uns com os outros de forma competitiva, e que os incentivos devem ser distribuídos por ordem de chegada, e que os primeiros Agregadores a enviar ZK-Proof para a cadeia podem receber recompensas. Claro, ele não mencionou como resolver o problema MEV front-running.
Lumoz usa um método de submissão de prova ZK de verificação em duas etapas, depois que um Agregador gera uma prova ZK, ele não precisa enviar o conteúdo completo, mas apenas publica o hash do ZKP, ou seja, publica o hash (ZKP+Aggregator Endereço). Desta forma, mesmo que outros vejam o valor hash, eles não sabem o conteúdo ZKP correspondente e não podem apressá-lo diretamente;
Se alguém simplesmente copia o hash inteiro e o publica primeiro, não faz sentido, porque o hash contém o Endereço de um agregador específico X, e mesmo que o agregador A publique o hash primeiro, quando a imagem original do hash for revelada, todos verão que o agregador Endereço 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 no processo de submissão ZKP e, em seguida, realizar incentivos de geração de zk-SNARKs altamente competitivos, melhorando assim a velocidade de geração do ZKP.
Merlin's Phantom: interoperabilidade de cadeia mais longa
De acordo com o roteiro técnico do Merlin, eles também suporte a interoperabilidade entre o Merlin e outras cadeias de EVM, e seu caminho de implementação é basicamente o mesmo que a ideia anterior do Zetachain, se o Merlin for usado como a cadeia de origem e outras cadeias de EVM forem usadas como a cadeia de destino, quando o Nó Merlin perceber a solicitação de interoperabilidade cadeia cruzada feita pelo usuário, ele acionará o fluxo de trabalho subsequente no na cadeia de destino.
Por exemplo, um conta EOA controlado pela rede Merlin pode ser implantado no Polygon, ** Quando um usuário publica uma instrução de interoperabilidade cadeia cruzada no Merlin Chain, a rede Merlin primeiro analisa seu conteúdo e gera dados de transação executados no na cadeia de destino e, em seguida, o processamento de assinatura do Oracle Network MPC na transação gera uma assinatura digital da transação. O Relayer da Merlin Nó então libera a transação ** no Polygon, completando as operações subsequentes através dos ativos da Merlin no EOA conta no na cadeia alvo.
Quando a operação requerida pelo usuário for concluída, o ativo correspondente será encaminhado diretamente para o endereço do usuário no na cadeia de destino e, teoricamente, também poderá cruzar diretamente para a Cadeia Merlin. Esta solução tem algumas vantagens óbvias: pode evitar o desgaste das taxas geradas pelos cadeia cruzada de ativos tradicionais e contratos de pontes de cadeia cruzada, e é diretamente garantida pela Rede Oracle da Merlin para garantir a segurança de cadeia cruzada operações, e não mais longo necessidade de depender de infraestrutura externa. Por mais longo que os usuários confiem no Merlin Chain, não há problema em usar essa cadeia cruzada interoperabilidade.
Resumo
Neste artigo, damos uma breve explicação da solução técnica geral da Merlin Chain, que se acredita ajudar mais longo pessoas a entender o fluxo de trabalho geral da Merlin e ter uma compreensão mais clara de seu modelo de segurança. Considerando a ecologia Bitcoin atual em pleno andamento, acreditamos que este tipo de comportamento de popularização da ciência técnica é valioso e necessário para o público em geral, Vamos realizar um acompanhamento de longo prazo sobre Merlin e bitLayer, B^Square e outros projetos no futuro, e realizar uma análise mais aprofundada de suas soluções técnicas, então manter-se atento!