Introdução:

O cientista de gestão americano Lawrence Peter propôs uma vez a “teoria do barril”, que acredita que o desempenho geral de um sistema é limitado pela sua parte mais fraca. Em outras palavras, quanto de água um barril pode conter é determinado pela sua tábua mais curta. Embora este princípio seja simples, é frequentemente negligenciado. No passado, os debates sobre a segurança da Camada 2 geralmente ignoravam a prioridade e importância de diferentes componentes, e basicamente focavam na confiabilidade da transição de estado e questões de DA, mas ignoravam os elementos de nível inferior e mais importantes. Desta forma, toda a base teórica pode ser insustentável. Portanto, ao discutirmos um sistema complexo de múltiplos módulos, devemos primeiro descobrir qual é a “tábua mais curta”. Inspirados na teoria do barril, fizemos uma análise do sistema e descobrimos que existem dependências óbvias entre diferentes componentes no modelo de segurança da Camada 2 do Bitcoin/Ethereum, ou que alguns componentes são mais fundamentais e importantes para a segurança do que outros, o que pode ser considerado como “mais curtos”. Neste sentido, podemos inicialmente priorizar a importância/base de diferentes componentes no modelo de segurança da Camada 2 mainstream da seguinte forma:

1. Se os direitos de controle da ponte do contrato/oficial são razoavelmente dispersos (quão centralizados são os direitos de controle de multi-assinatura)

2. Existe uma função de saque resistente à censura (saque forçado, saída de emergência)

3. O formulário de liberação de dados da camada DA é confiável? (Se os dados DA são publicados no Bitcoin e Ethereum)

4. Se um sistema confiável de prova de fraude/prova de validade for implementado na Camada 1 (Bitcoin L2 requer a ajuda do BitVM)

Devemos absorver moderadamente os resultados da pesquisa da comunidade Ethereum na Camada 2 e evitar o lisenkoísmo

Comparado com o sistema altamente ordenado Ethereum Layer 2, Bitcoin Layer 2 é como um novo mundo. Este novo conceito, que se tornou cada vez mais importante após a mania das inscrições, está a mostrar um impulso crescente, mas o seu ecossistema está a tornar-se cada vez mais caótico. Do caos, vários projetos da Camada 2 brotaram como cogumelos após uma chuva. Embora tragam esperança ao ecossistema Bitcoin, eles deliberadamente escondem seus próprios riscos de segurança. Algumas pessoas até ameaçaram "negar a Camada 2 do Ethereum e seguir o caminho único do ecossistema Bitcoin", mostrando uma forte tendência a tomar uma rota extremista. Considerando as diferenças nos atributos funcionais entre Bitcoin e Ethereum, a Camada 2 do Bitcoin está destinada a ser incapaz de se alinhar com a Camada 2 do Ethereum nos estágios iniciais, mas isso não significa que devemos negar completamente o senso comum industrial que há muito foi estabelecido no Ethereum e até mesmo na indústria de blockchain modular. (Veja-se o "incidente de Lysenko", em que o ex-biólogo soviético Lysenko usou questões ideológicas para perseguir os defensores da genética ocidental). Pelo contrário, estes padrões de avaliação, que foram alcançados pelos "antecessores" com grandes esforços, já mostraram forte persuasão depois de serem amplamente reconhecidos. Definitivamente, não é um movimento racional negar deliberadamente o valor dessas conquistas.

Ao construir o Bitcoin Camada 2, devemos compreender plenamente a importância de "aprender com o Ocidente e aplicar no Oriente" e absorver e otimizar adequadamente as muitas conclusões da comunidade Ethereum. No entanto, ao buscar perspectivas fora do ecossistema Bitcoin, devemos estar cientes das diferenças em seus pontos de partida e, em última análise, buscar pontos em comum enquanto reservamos diferenças.

Isto é como discutir as semelhanças e diferenças entre “Ocidentais” e “Orientais”. Independentemente de ser Ocidental ou Oriental, o sufixo “-er (人)” expressa muitas características semelhantes, mas ao corresponder a diferentes prefixos como “Ocidental” e “Oriental”, as características de subdivisão serão diferentes. Mas, em última análise, há sobreposição entre “Ocidentais” e “Orientais”, o que significa que muitas coisas que se aplicam aos Ocidentais também se aplicam aos Orientais. Muitas coisas que se aplicam a “Camada 2 da Ethereum” também se aplicam a “Camada 2 do Bitcoin”. Antes de distinguir as diferenças entre o Bitcoin L2 e o Ethereum L2, pode ser mais importante e significativo esclarecer a interoperabilidade entre os dois.

Aderindo ao propósito de "buscar terreno comum enquanto se reservam diferenças", o autor deste artigo não pretende discutir "o que é a Camada 2 do Bitcoin e o que não é", porque este tópico é tão controverso que nem a comunidade Ethereum discutiu "qual é a Camada 2 do Ethereum e qual não é Camada 2" e chegou a uma visão objetiva e consistente. Mas o que é certo é que, enquanto diferentes soluções técnicas trazem efeitos de expansão para o Bitcoin, elas também têm diferentes riscos de segurança. As suposições de confiança existentes em seus modelos de segurança serão o foco deste artigo.

Como entender os critérios de segurança e avaliação da Camada 2

Na verdade, a segurança da Camada 2 não é um novo ponto de discussão. Mesmo a palavra segurança é um conceito composto que inclui múltiplos atributos subdivididos. Anteriormente, o fundador da EigenLayer simplesmente subdividiu a 'segurança' em quatro elementos: 'irreversibilidade da transação (resistência a re-org), resistência à censura, confiabilidade da liberação de dados/DA e validade da transição de estado'.

(O fundador da EigenLayer expressou uma vez suas opiniões sobre como o esquema de verificação/rollup soberano do lado do cliente pode herdar a segurança da rede principal do Bitcoin) L2BEAT e a Comunidade OG da Ethereum propuseram um modelo de avaliação de risco da Camada 2 mais sistemático. Claro, estas conclusões são direcionadas à Camada 2 de contratos inteligentes, em vez da típica Camada 2 não de contratos inteligentes, como rollup soberano e verificação do cliente. Embora isso não seja 100% adequado para o L2 do Bitcoin, ainda contém muitas conclusões dignas de reconhecimento, e a maioria de suas opiniões foi amplamente reconhecida na comunidade ocidental. Isso também torna mais fácil para nós avaliar objetivamente os riscos de diferentes L2 do Bitcoin.

(Vitalik já disse que, uma vez que a solução Rollup não pode atingir a perfeição teórica em seu lançamento inicial, deve usar alguns meios auxiliares para melhorar a segurança, e estes meios auxiliares são chamados de “rodas de treinamento” e introduzirão pressupostos de confiança. Esses meios auxiliares são chamados de “rodas de treinamento” e introduzirão pressupostos de confiança. Pressupostos de confiança são riscos.)

Então, de onde vêm os riscos de segurança? Considerando a situação atual, seja Ethereum Layer 2 ou Bitcoin Layer 2, muitos deles dependem de nós centralizados para atuar como sequenciadores, ou um "comitê" na forma de uma cadeia lateral composta por um pequeno número de nós. Se esses ordenadores/comitês centralizados não forem restritos, eles podem roubar ativos do usuário e fugir a qualquer momento. Eles podem rejeitar solicitações de transação do usuário, fazendo com que os ativos sejam congelados e inutilizáveis. Isso envolve a eficácia e a resistência à censura das transições de estado mencionadas pelo fundador da EigenLayer anteriormente. Ao mesmo tempo, como a Camada 2 do Ethereum depende de contratos na cadeia ETH para verificação de transição de estado e verificação de comportamento de depósito e retirada, se o controlador do contrato (na verdade, a Camada 2 oficial) puder atualizar rapidamente a lógica do contrato, adicione segmentos de código malicioso (por exemplo, Permitindo que um endereço especificado transfira todos os tokens bloqueados no contrato de depósito e retirada L1-L2), Você pode roubar diretamente os bens sob custódia. Isso é atribuído ao "problema de alocação de várias assinaturas de contrato", e o problema de alocação de várias assinaturas também se aplica à Camada 2 do Bitcoin. Como a Camada 2 do Bitcoin muitas vezes depende da "ponte notarial" e requer vários nós para liberar solicitações entre cadeias por meio de várias assinaturas, a Camada 2 do Bitcoin também tem o problema de como distribuir razoavelmente as multiassinaturas. Podemos até pensar nisso como as "rodas de treinamento" mais básicas na Camada 2 do Bitcoin.

Além disso, a questão do DA é extremamente importante. Se a Camada2 não carregar dados para a Camada1, mas escolher alguns locais de lançamento de DA não confiáveis, se esta camada de DA off-chain (comumente conhecida como Comitê de Disponibilidade de Dados DAC) colaborar e se recusar a liberar os dados de transações mais recentes para o mundo exterior, ocorrerá um ataque de retenção de dados. Isso fará com que a rede se torne obsoleta e pode impedir que os usuários retirem fundos suavemente.

L2BEAT resumiu as questões acima e sumarizou vários elementos essenciais no modelo de segurança da Camada 2:

1. Verificação de estado/provar se o sistema é fiável (Validação de estado)

2. Se o método de liberação de dados DA é confiável (Disponibilidade de Dados)

3. Se a rede da Camada 2 rejeitar deliberadamente sua transação/encerrar, você pode forçar a retirada dos ativos da Camada 2 (Falha do Sequenciador, Falha do Proponente)

4. Quanto aos contratos relacionados com a Camada 2 - o controle da ponte oficial entre cadeias é suficientemente descentralizado? Se o poder for relativamente centralizado, no caso de 'insiders agirem maliciosamente', os utilizadores têm tempo suficiente para responder a uma situação de emergência? (Janela de Saída)

(“Gráfico de exibição de fator de risco” definido para diferentes projetos de Camada 2 no L2BEAT)

De qualquer forma, quando analisamos os riscos de segurança da Camada 2, estamos na verdade discutindo quantos cenários existem na rede da Camada 2 que podem causar danos aos ativos do usuário e se o sistema da Camada 2 pode efetivamente restringir essas situações perigosas através do design do mecanismo. Se certos comportamentos maliciosos não podem ser eliminados, quanta "confiança" precisamos introduzir, quantos indivíduos em um grupo precisam ser confiáveis e em quantas "rodas de treinamento" precisamos confiar. Abaixo vamos analisar os fatores de risco presentes no modelo geral Ethereum Layer2/Bitcoin Layer2. (Os objetos discutidos neste artigo não incluem "canais estatais" ou "canais de pagamento", nem incluem protocolos de índice de inscrição, porque são especiais. E tentaremos explorar quais fatores são mais básicos, de nível inferior e mais importantes no modelo de segurança de Camada 2. Estas deficiências mais básicas serão riscos de confiança que merecem mais a nossa atenção do que outras deficiências.

Efeito de barril da Camada 2 - quais são suas desvantagens?

A placa mais curta - os direitos de gestão do contrato/ponte oficial

Aqui, poderíamos muito bem usar o “efeito barril” para analisar questões de segurança da Camada 2. É fácil ver que o quadro mais curto é a “atualização de contrato” mencionada acima (principalmente para a Camada 2 do Ethereum), ou ainda, os “direitos de gestão da ponte oficial de interligação entre cadeias” (aplicáveis tanto ao Bitcoin quanto à Camada 2 do Ethereum).

Para a Camada 2 do Ethereum, desde que os funcionários da Camada 2 possam atualizar rapidamente os contratos na cadeia da Camada 1, teoricamente, eles podem roubar os tokens bloqueados no endereço oficial de depósito e retirada da ponte da Camada 2, independentemente de quão confiável seja sua camada de Disponibilidade de Dados (DA) ou sistema de prova. Pode dizer-se que a autoridade de controlo do contrato de ponte diz respeito à segurança de todo o sistema. É a parte mais fundamental e crítica de toda a Camada 2 e até mesmo da pilha modular de blockchain. Se o componente/contrato da ponte pode ser atualizado e iterado sob controle de várias assinaturas, então precisamos introduzir uma "suposição de confiança" aqui, assumindo que o controlador do contrato/ponte oficial da Camada 2 não fará mal.

(Os atrasos na atualização de contratos de diferentes projetos de Camada 2 estão marcados no L2BEAT. A maioria dos contratos de Camada 2 pode ser atualizada imediatamente pelo controlador. Se o controlador do contrato quiser roubar ativos, ou se sua chave privada for roubada por um hacker, os ativos do usuário hospedados na Camada 2 devem sofrer)

Diferente da Camada 2 do Ethereum, a ponte da Camada 2 do Bitcoin basicamente não é controlada pelo contrato na Camada 1, porque o Bitcoin não suporta contratos inteligentes. Relativamente falando, todo o fluxo de trabalho da Camada 2 do Ethereum é altamente dependente do contrato na Camada 1, enquanto a Camada 2 do Bitcoin não pode fazer isso.

(Diagrama esquemático do Starknet)

Este é um problema inevitável para a Camada 2 do Bitcoin. Pode-se dizer que tem vantagens e desvantagens. Atualmente, parece que a “ponte sem confiança” implementada pela Camada 2 do Ethereum com base em contratos não pode ser realizada no Bitcoin L2. Esta “Ponte Sem Confiança” requer a implementação de um contrato dedicado na Camada 1 e a cooperação do sistema de prova de fraude DA+/ZK. É essencialmente semelhante à “ponte otimista” como Orbiter ou pontes ZK como Polyhedra. A visão predominante na indústria atual é que se não considerar possíveis bugs na prática e apenas considerar modelos teóricos, o nível de segurança da Ponte Otimista e da Ponte ZK é basicamente o mais alto. Desde que o código do contrato não contenha bugs ou não possa ser atualizado maliciosamente, é basicamente sem confiança.

(A Ponte Otimista só precisa garantir que 1 em cada N observadores é honesto para garantir segurança. O modelo de confiança é 1/N)

Uma vez que o Layer 2 do Bitcoin não pode implementar componentes de contrato no Layer 1 (não estamos a falar da Lightning Network aqui), as suas pontes oficiais são basicamente "pontes notariais" compostas por um pequeno número de nós, ou "pontes de multi-assinatura". A segurança deste tipo de ponte A confiabilidade depende de como as assinaturas multi-assinatura/limite são configuradas, o que requer a introdução de fortes pressupostos de confiança: supondo que estes notários não irão colaborar ou ter suas chaves privadas roubadas.

Atualmente, a maioria das pontes baseadas em assinaturas de notário/limiar não pode ser comparada com a "ponte descentralizada" oficial da Camada 2 do Ethereum em termos de segurança (desde que o contrato da Camada 2 do Ethereum não seja atualizado maliciosamente). Obviamente, a segurança dos ativos sob custódia na rede da Camada 2 do Bitcoin será limitada pela segurança de sua ponte oficial, ou pela descentralização do poder da ponte de multiassinatura, que é a sua primeira "roda auxiliar". Uma vez que os "direitos de atualização" dos contratos relacionados com a ponte oficial da Camada 2 do Ethereum estão frequentemente concentrados nas mãos de alguns controladores de multiassinatura, se os controladores de multiassinatura coludirem, também haverá problemas com a ponte da Camada 2 do Ethereum, a menos que seu contrato não possa ser atualizado, ou esteja sujeito a um limite de atraso prolongado (atualmente apenas Degate e Fuel V1).

(Sempre que os contratos Degate são atualizados, será reservado um período de escape seguro de 30 dias para os utilizadores. Durante este período, desde que todos descubram que a nova versão do código do contrato tem lógica maliciosa, podem escapar em segurança através da função de saída/escape forçada)

No que diz respeito à parte da "ponte oficial", os modelos de confiança da Camada 2 do Ethereum e da Camada 2 do Bitcoin são basicamente os mesmos: é necessário confiar que o controlador de multi-assinatura não irá coludir para fazer o mal. Este grupo de multi-assinaturas pode controlar a ponte oficial da L2 e alterar a lógica do seu código ou lançar diretamente pedidos de levantamento inválidos. O resultado final é: os ativos do utilizador podem ser roubados. A única diferença entre os dois é que, desde que o contrato da Camada 2 do Ethereum não seja maliciosamente atualizado/o período de atualização seja suficientemente longo, a sua ponte oficial será sem confiança, mas a Camada 2 do Bitcoin não pode alcançar este efeito de qualquer forma.

A segunda ligação mais curta - retiradas forçadas resistentes à censura

Se assumirmos que a questão dos contratos de múltiplas assinaturas/controlo da ponte oficial mencionada acima pode ser ignorada, ou seja, não há problema nesta camada, então a camada seguinte mais importante deve ser a resistência à censura das retiradas. Em relação à importância da funcionalidade de retirada resistente à censura/função de saída de emergência, Vitalik enfatizou em seu artigo “Diferentes tipos de camadas 2” há alguns meses que se o utilizador consegue ou não retirar ativos com sucesso da Camada 2 para a Camada 1 é um indicador de segurança muito importante.

Se o sequenciador da Camada 2 continuar a rejeitar os seus pedidos de transação, ou falhar/estiver inoperacional por muito tempo, os seus ativos serão "congelados" e nada poderá ser feito. Mesmo que existam sistemas de DA e prova de fraude/prova de ZK disponíveis, sem uma solução anti-censura, essa Camada 2 não é suficientemente segura e os seus ativos podem ser detidos a qualquer momento. Além disso, a solução Plasma, que já foi muito popular no ecossistema Ethereum, permite que qualquer pessoa retire os ativos em segurança para a Camada 1 quando o DA falha ou a prova de fraude falha. Neste momento, toda a rede da Camada 2 é essencialmente descartada, mas ainda há uma forma dos seus ativos escaparem ilesos. Obviamente, a função de retirada resistente à censura é mais básica e de nível inferior do que os sistemas de DA e prova.

(Dankrad da Fundação Ethereum disse que o Plasma ainda pode permitir que os ativos do usuário sejam evacuados com segurança quando o DA falha/os usuários não conseguem sincronizar os dados mais recentes)

Alguns Ethereum Camada 2, como Loopring e StarkEx, dYdX, Degate, etc. vão estabelecer uma função de ativação de cabine de retirada/escape resistente à censura na Camada 1. Tomando Starknet como exemplo, se o pedido de Retirada Forçada submetido pelo usuário na Camada 1 não receber uma resposta do sequenciador da Camada 2 no final do período de janela de 7 dias, a função de Pedido de Congelamento pode ser chamada manualmente para colocar a L2 em um estado congelado e ativar o modo de cabine de escape. Neste momento, o sequenciador não pode enviar dados para o contrato Rollup na L1, e toda a Camada 2 será congelada por um ano. Então, os usuários podem submeter uma prova de Merkle para provar o estado de seus ativos na Camada 2 e retirar dinheiro diretamente na Camada 1 (na verdade, eles retiram um valor igual de seus próprios fundos do endereço de depósito e retirada da ponte oficial).

Obviamente, o modo de escape só pode ser implementado numa cadeia como o Ethereum que suporta contratos inteligentes. O Bitcoin não pode executar uma lógica tão complexa. Em outras palavras, a função de escape é basicamente uma patente da Camada 2 do Ethereum. A Camada 2 do Bitcoin deve usar alguns meios auxiliares adicionais para imitar o gato e o tigre. Este é o segundo "pneu auxiliar". No entanto, é muito mais conveniente simplesmente declarar um "pedido de saque forçado" do que ativar diretamente o modo de escape. O primeiro só requer que o usuário envie uma transação para o endereço especificado na Camada 1 e, nos dados adicionais da transação, declare os dados que desejam submeter a todos os nós da Camada 2 (isso pode ignorar diretamente o sequenciador e comunicar os pedidos a outros nós da Camada 2). Se o "saque forçado" não receber uma resposta por um longo tempo, é um design mais razoável para o usuário acionar o modo de cabine de escape.

(Reference: Qual a importância das funções de retirada forçada e escape da cabine para a Camada 2）

Atualmente, já existem equipas da Camada 2 do Bitcoin que planeiam imitar o método de implementação de transações forçadas do Arbitrum e permitir aos utilizadores emitir declarações de transações forçadas (Envelopes de Transações Forçadas) na cadeia do Bitcoin. Com esta solução, os utilizadores podem contornar o sequenciador e "transmitir as suas vozes" diretamente para outros nós da Camada 2. Se o sequenciador ainda rejeitar o pedido do utilizador depois de ver a declaração de transação forçada do utilizador, será notado por outros nós da Camada 2 e poderá ser punido.

Mas o problema é que a função de transação forçada do Arbitrum, beneficiando-se do seu sistema à prova de fraudes, pode punir Sequenciadores/Proponentes que têm ignorado as transações do usuário. No entanto, a Camada 2 do Bitcoin, que é difícil de verificar a prova de fraude na Camada 1, irá encontrar certos desafios a este respeito. (Vamos não discutir o BitVM por agora) Se for uma solução como o Rollup soberano, onde o nível de segurança não é muito diferente da verificação do cliente, é difícil para nós avaliar seriamente a sua fiabilidade, e talvez seja necessário avaliar os detalhes de implementação de diferentes projetos.

Claro, dado que muitos Bitcoin Camada 2 operam atualmente de forma semelhante a side chains, é equivalente perceber que um sequenciador descentralizado pode resolver o problema da anti-censura até certo ponto. Mas isso é apenas um meio auxiliar eficaz, certamente não é a solução final.

PS: Algumas soluções atuais de Camada 2, como Validium, etc., não são perfeitas no design do mecanismo da cabine de escape. Quando o sequenciador inicia um ataque de retenção de dados/DA não está disponível, os utilizadores não podem levantar dinheiro. Mas isso se deve ao design imperfeito da cabine de escape Layer 2. Teoricamente, a retirada ideal da escotilha de escape pode depender apenas de dados históricos e não precisa depender da disponibilidade de DA/novos dados.

A terceira prancha mais curta: a confiabilidade da liberação de dados da camada DA

Embora DA seja chamado de disponibilidade de dados, o termo na verdade se refere à liberação de dados. Apenas porque Vitalik e Mustafa não pensaram cuidadosamente quando originalmente nomearam esse conceito, é que o nome DA/disponibilidade de dados se tornou falso.

A divulgação de dados, como o nome sugere, refere-se a se os dados mais recentes dos blocos/transações/parâmetros de transição de estado podem ser recebidos com sucesso por quem deles precisa. Os dados publicados em diferentes cadeias possuem diferentes níveis de confiabilidade.

(Referência:Mal-entendidos sobre a disponibilidade de dados: DA = libertação de dados ≠ recuperação de dados históricos)

Na comunidade ocidental, geralmente acredita-se que cadeias públicas estabelecidas como Bitcoin e Ethereum são as camadas DA mais confiáveis. Se o sorter da Camada 2 publicar novos dados no Ethereum, qualquer pessoa que execute o cliente geth do Ethereum pode baixar esses dados e sincronizá-los sem qualquer impedimento. Isso é alcançado aproveitando a grande escala da rede Ethereum e a ampla variedade de fontes de dados públicas. Vale ressaltar que o Ethereum Rollup forçará o sequenciador a publicar dados de transação/parâmetros de transição de estado na Camada 1, o que é garantido por meio de prova de validade/prova de fraude.

Por exemplo, após o sequenciador do ZK Rollup publicar os dados da transação na Camada 1, ele irá desencadear a lógica do contrato para gerar um datahash, e o contrato validador deve confirmar que o certificado de validade submetido pelo Proponente tem uma relação correspondente com o datahash. Isto equivale a: confirmar que a Prova zk e Stateroot submetida pelo Proponente estão associadas aos dados Tx submetidos pelo Sequenciador, ou seja, New Stateroot=STF(Old Stateroot，Txdata). STF é a função de transição de estado. Isto assegura que os dados/DA de transição de estado sejam carregados à força para a cadeia. Se apenas submeter o stateroot e o certificado de validade, não será capaz de passar na verificação do contrato validador. Quanto a saber se a liberação de dados DA ou o sistema de verificação de prova é mais básico, a comunidade Ethereum/Celestia já teve uma discussão completa. A conclusão geral é que a confiabilidade da camada DA é mais importante do que a completude do sistema de prova de fraude/validade. Por exemplo, soluções como Plasma, Validium e Optimium, onde a camada DA está sob a cadeia Ethereum e a camada de liquidação está na cadeia Ethereum, são propensas a encontrar problemas de "Ataque de Omissão de Dados", o que significa: Sequenciador/Proponente pode conspirar com os nós da camada DA sob a cadeia ETH para atualizar o stateroot na Camada 1, mas omitir os parâmetros de entrada correspondentes à transição de estado e não os enviar, tornando impossível para os externos julgar se o novo stateroot está correto, e tornar-se "cego".

Se isso acontecer, toda a rede de Camada 2 será descartada. Porque neste momento, você não tem ideia do que o livro-razão da Camada 2 se tornou. Se for a Camada 2 (Plasma e Optimium) baseada em prova de fraude, o classificador pode reescrever os dados/ativos sob qualquer conta à vontade; se for a Camada 2 (Validium) baseada em prova de validade, embora o classificador não possa reescrever sua conta à vontade, nesse momento, toda a rede de Camada 2 se tornou uma caixa-preta. Ninguém sabia o que aconteceu dentro, e não diferia de ser descartado. Por causa disso, as soluções ortodoxas de Camada 2 no ecossistema do Ethereum são basicamente Rollup, enquanto Validium e Optimium muitas vezes não são reconhecidos pela Fundação Ethereum.

(Referência: Prova de Retenção de Dados e Fraude: Por Que a Plasma Não Suporta Contratos Inteligentes）

Portanto, a confiabilidade da camada DA/disponibilidade dos parâmetros de transição de estado é mais importante e fundamental do que a completude do sistema de prova de fraude/prova de validade. Para a Camada 2 do Bitcoin, especialmente a Camada 2 baseada no modelo de verificação do cliente, mesmo que não haja um sistema de verificação de prova de fraude/prova de validade na Camada 1, desde que a camada DA funcione como de costume, todos ainda podem saber se há um erro na rede L2. Atualmente, a rede principal do Bitcoin é difícil de verificar a prova de fraude/prova de validade (BitVM não é discutido aqui). Vamos primeiro assumir que o Bitcoin L2 não tem um sistema de verificação de prova. Idealmente, se o classificador L2 realmente fizer o mal e publicar uma raiz de estado que não esteja relacionada aos dados DA na camada de liquidação/BTC, ainda assim não poderá realmente roubar os ativos do usuário, porque a raiz de estado/resultados de transição de estado que ele submete unilateralmente não será reconhecida pelos nós honestos, mas no final pode ser apenas autoprazer. (Neste momento, desde que os nós executados pelos provedores de instalações periféricas no ecossistema, como exchanges e pontes entre blockchains, não colidam com o sequenciador, o sequenciador não pode realizar rapidamente os ativos roubados publicando dados errôneos. Depois, assim que um nó honesto descobrir que algo está errado e emitir um alerta no momento crítico, o erro pode ser corrigido através do consenso social. No entanto, o custo do consenso social em si é muito alto e não pode ter efeito imediato)

Se for um modelo semelhante a uma side chain e a maioria dos nós conspirar para realizar alterações de estado maliciosas, as pessoas podem descobrir rapidamente o problema. Desde que as instalações de terceiros, como pontes entre cadeias e exchanges, não reconheçam dados errôneos, os controladores maliciosos das Camadas 2/side chains não poderão sacar com sucesso. A menos que ele convença outros a fazerem OTC diretamente na cadeia com ele.

(Viatlik apontou anteriormente no artigo que a verificação do cliente é a verdadeira base para garantir a segurança da rede blockchain. Verifique por si próprio)

Há um ponto muito interessante aqui. Na verdade, tanto a Camada 2 do Ethereum quanto a Camada 2 do Bitcoin podem alcançar a “verificação do cliente”. No entanto, com base na “verificação do cliente”, a Camada 2 do Ethereum depende da Camada 1 e do sistema de verificação de prova para garantir a validade das transições de estado e basicamente não precisa depender do consenso social (desde que haja um sistema maduro de prova de fraude/prova de validade). A solução de “verificação do cliente” da Camada 2 do Bitcoin muitas vezes depende fortemente do “consenso social” e trará riscos correspondentes. (Para a Camada 2 do Bitcoin, esse risco de segurança é basicamente controlável, mas ainda pode fazer com que algumas pessoas percam ativos. Para a Camada 2 do Ethereum, como sua ponte oficial precisa provar a cooperação do sistema, se o sistema de prova não for perfeito, o servidor de pedidos pode roubar os ativos do usuário e fugir no L1. Claro, os detalhes dependem de como o componente de ponte entre cadeias é projetado). Portanto, uma Camada 2 que pode implementar um sistema de verificação de prova de fraude/prova de validade na Camada 1 será sempre muito melhor do que um simples modelo de “verificação do cliente”. PS: Como a maioria das Camadas 2 do Bitcoin que usam sistemas de prova de fraude/prova de validade não podem permitir que a Camada 1 participe diretamente do processo de verificação de prova, sua essência ainda é apenas tratar o Bitcoin como uma camada DA, e o modelo de segurança é equivalente à “verificação do cliente”. Teoricamente, a prova de fraude pode ser verificada na cadeia do Bitcoin por meio da solução BitVM na Camada 1. No entanto, a implementação dessa solução é muito difícil e enfrentará grandes desafios. Como a comunidade Ethereum já discutiu muito sobre o sistema de prova e verificação baseado na Camada 1, que já é bem conhecido, este artigo não pretende entrar em detalhes sobre o “sistema de prova e verificação baseado na Camada 1”.

Conclusão

Após uma análise simples do modelo de barril, podemos inicialmente chegar a uma conclusão: No modelo de segurança Layer 2 principal, de acordo com o grau de importância/nível básico, pode ser classificado da seguinte forma:

1. Se os direitos de controle da ponte de contrato/oficial estão razoavelmente dispersos

2. Se existe uma função de levantamento resistente à censura

3. Se o formulário de liberação de dados da camada DA é confiável

4. Se um sistema de prova de fraude/confirmação de validade confiável está implementado na Camada 1

Claro, não analisamos o Lightning Network/Canal de Estado e o ecossistema ICP's ckBTC, Protocolo de Índice de Inscrição e outras soluções, porque são bastante diferentes das soluções Rollup, Plasma, Validium ou de verificação de cliente típicas. Devido a restrições de tempo, é difícil para nós conduzir uma avaliação prudente de seus fatores de segurança e risco, mas considerando sua importância, o trabalho de avaliação relevante será realizado conforme agendado no futuro. Ao mesmo tempo, existem diferenças sérias entre muitas partes do projeto quanto a se o Protocolo de Índice de Inscrição deve ser considerado como Camada 2. No entanto, independentemente da definição de Camada 2, novidades como o Protocolo de Índice de Inscrição trouxeram inovação tecnológica suficiente para o ecossistema do Bitcoin. E acabarão por explodir com grande vitalidade.

Aviso legal：

1. Este artigo é reproduzido a partir de [极客web3]. Todos os direitos autorais pertencem ao autor original [Faust & 雾月, web3 geek]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa, e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente da autoria e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.