Introdução:

O cientista americano de gestão Lawrence Peter uma vez propôs a “teoria do barril”, que acredita que o desempenho geral de um sistema é limitado pela sua parte mais fraca. Em outras palavras, quanto á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 ignoraram a prioridade e importância de diferentes componentes, e basicamente focaram na confiabilidade da transição de estado e questões da DA, mas ignoraram os elementos de nível inferior e mais importantes. Dessa forma, toda a base teórica pode ser insustentável. Portanto, ao discutirmos um sistema complexo de vários módulos, devemos primeiro descobrir qual peça é 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 curto”. Nesse sentido, podemos inicialmente priorizar a importância/base de diferentes componentes no modelo de segurança da Camada 2 principal da seguinte maneira:

1. Se os direitos de controle da ponte do contrato/oficial estão razoavelmente dispersos (quão centralizados os direitos de controle de múltiplas assinaturas estão)

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 implantado na Camada 1 (o Bitcoin L2 requer a ajuda do BitVM)

Devemos absorver moderadamente os resultados da pesquisa da comunidade do Ethereum sobre a Camada 2 e evitar o Lysenkoismo

Em comparação com o sistema Ethereum Layer 2 altamente ordenado, o 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. Enquanto eles trazem esperança para o ecossistema Bitcoin, eles deliberadamente escondem seus próprios riscos de segurança. Algumas pessoas até ameaçaram "negar o Ethereum Layer 2 e seguir o caminho único do ecossistema Bitcoin", mostrando uma forte tendência a seguir um caminho extremista. Considerando as diferenças nos atributos funcionais entre Bitcoin e Ethereum, o Bitcoin Layer 2 está destinado a ser incapaz de se alinhar com o Ethereum Layer 2 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. (Consulte o "incidente 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, esses padrões de avaliação, que foram alcançados por "antecessores" com grandes esforços, já mostraram forte persuasão depois de amplamente reconhecidos. Definitivamente, não é um movimento racional negar deliberadamente o valor dessas conquistas.

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

Isso é como discutir as semelhanças e diferenças entre os "Ocidentais" e os "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á uma 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 à "Camada 2 do Ethereum" também se aplicam à "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.

Adotando o propósito de "buscar pontos em comum enquanto reserva 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 mesmo a comunidade Ethereum discutiu "qual é a Camada 2 do Ethereum e qual não é Camada 2" e alcançou 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. Até mesmo a palavra segurança é um conceito composto que inclui vários atributos subdivididos. Anteriormente, o fundador da EigenLayer uma vez simplesmente subdividiu a "segurança" em quatro elementos: "irreversibilidade da transação (resistência à reorganização), resistência à censura, confiabilidade de DA/liberação de dados e validade de transição de estado".

(O fundador da EigenLayer uma vez expressou suas opiniões sobre como o esquema de rollup soberano/verificação do lado do cliente pode herdar a segurança da mainnet do Bitcoin) L2BEAT e a Comunidade OG do Ethereum propuseram um modelo de avaliação de risco da Camada 2 mais sistemático. Claro, essas conclusões são direcionadas para a 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 Bitcoin L2, ainda contém muitas conclusões dignas de reconhecimento, e a maioria de suas opiniões tem sido amplamente reconhecida na comunidade ocidental. Isso também facilita para nós avaliarmos objetivamente os riscos de diferentes Bitcoins L2.

(Vitalik uma vez disse que, uma vez que a solução Rollup não pode alcançar a perfeição teórica em seu lançamento inicial, ela deve usar alguns meios auxiliares para melhorar a segurança, e esses meios auxiliares são chamados de "rodinhas de treinamento" e introduzirão suposições de confiança. Esses meios auxiliares são chamados de "rodinhas de treinamento" e introduzirão suposições de confiança. Suposições 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 o Ethereum Layer 2 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 maliciosos (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 ativos sob custódia. Isso é atribuído ao "problema de alocação de várias assinaturas de contratos", e o problema de alocação de várias assinaturas também se aplica ao Bitcoin Layer 2. Como o Bitcoin Layer 2 geralmente depende da "ponte notarial" e requer vários nós para liberar solicitações de cadeia cruzada por meio de várias assinaturas, o Bitcoin Layer 2 também tem o problema de como distribuir razoavelmente 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 Camada 2 não enviar dados para a Camada 1, mas escolher alguns locais de lançamento de DA não confiáveis, se esta camada de DA fora da cadeia (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, um ataque de retenção de dados ocorrerá. Isso fará com que a rede se torne obsoleta e pode impedir que os usuários retirem fundos com facilidade.

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

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

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

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

4. Em relação aos contratos relacionados à Camada 2 - o controle da ponte oficial de interligação entre cadeias é suficientemente descentralizado? Se o poder for relativamente centralizado, no caso de 'insiders agindo de forma nefasta', os usuários têm tempo suficiente para responder a uma emergência? (Janela de Saída)

(“Gráfico de exibição de fatores de risco” definido para diferentes projetos da 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 restringir efetivamente essas situações perigosas através do design do mecanismo. Se certos comportamentos maliciosos não puderem ser eliminados, quanto “confiança” precisamos introduzir, quantos indivíduos em um grupo precisam ser confiáveis, e quantas “rodas de treinamento” precisamos depender. Abaixo, analisaremos os fatores de risco presentes no modelo geral da Camada 2 do Ethereum/Bitcoin. (Os objetos discutidos neste artigo não incluem “canais de estado” ou “canais de pagamento”, nem incluem protocolos de índice de inscrição, pois eles são especiais. E tentaremos explorar quais fatores são mais básicos, de nível mais baixo e mais importantes no modelo de segurança da Camada 2. Essas deficiências mais básicas serão riscos de confiança que merecem mais atenção do que outras deficiências.)

Efeito de barril da Camada 2 - quais são suas deficiências?

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

Aqui, podemos muito bem usar o “efeito barril” para analisar as questões de segurança da Camada 2. É fácil ver que a placa mais curta é a “atualização de contrato” mencionada acima (principalmente para a Camada 2 do Ethereum), ou ainda, os “direitos de administração da ponte oficial de interoperabilidade” (aplicável tanto ao Bitcoin quanto à Camada 2 do Ethereum).

Para o Ethereum Camada 2, desde que os oficiais da Camada 2 possam atualizar rapidamente os contratos na cadeia da Camada 1, teoricamente, eles podem roubar os tokens bloqueados no depósito da ponte oficial da Camada 2 e no endereço de retirada, independentemente de quão confiável seja sua camada de Disponibilidade de Dados (DA) ou sistema de prova. Pode-se dizer que a autoridade de controle do contrato da 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 puder ser atualizado e iterado sob controle de assinatura múltipla, 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á o mal.

(Os atrasos de atualização de contrato de diferentes projetos da Camada 2 são marcados no L2BEAT. A maioria dos contratos da L2 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 pela L2 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 depende muito 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 da Ethereum, dependendo de contratos, não pode ser realizada no Bitcoin L2. Essa “Ponte sem Confiança” requer a implantaçã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. Contanto 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 entre N observadores seja honesto para garantir a segurança. O modelo de confiança é 1/N)

Uma vez que o Bitcoin Camada 2 não pode implantar componentes de contrato na Camada 1 (não estamos falando sobre a Rede Lightning aqui), suas pontes oficiais são basicamente pontes de "notário" compostas por um pequeno número de nós, ou pontes de "multisig". A segurança desse tipo de ponte A confiabilidade depende de como as assinaturas de múltiplas partes/limite são configuradas, o que requer a introdução de fortes pressupostos de confiança: assumindo que esses 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 sem confiança" oficial da Camada 2 do Ethereum em termos de segurança (a premissa é que o contrato da Camada 2 do Ethereum não será maliciosamente atualizado). Obviamente, a segurança dos ativos sob custódia da rede da Camada 2 do Bitcoin será limitada pela segurança de sua ponte oficial, ou pela descentralização do poder da ponte de assinatura múltipla, que é sua primeira "roda auxiliar". Uma vez que os "direitos de atualização" dos contratos relacionados à ponte oficial da Camada 2 do Ethereum frequentemente estão concentrados nas mãos de alguns controladores de assinatura múltipla, se os controladores de assinatura múltipla conspirarem, 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 longo (atualmente apenas Degate e Fuel V1).

(Toda vez que os contratos Degate forem atualizados, será reservado um período de escape seguro de 30 dias para os usuários. Durante esse período, desde que todos percebam que a nova versão do código do contrato contenha lógica maliciosa, eles podem escapar com segurança através da função de retirada/fuga 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: você precisa confiar que o controlador de assinatura múltipla não irá conluio para fazer maldades. Esse grupo de multi-assinaturas pode controlar a ponte oficial da L2 e alterar sua lógica de código ou liberar diretamente solicitações inválidas de retirada. O resultado final é: os ativos do usuário podem ser roubados. A única diferença entre os dois é que, desde que o contrato da Camada 2 do Ethereum não faça upgrade maliciosamente / a janela de upgrade seja longa o suficiente, sua ponte oficial será sem confiança, mas a Camada 2 do Bitcoin não pode alcançar esse efeito de qualquer maneira.

O segundo link mais curto - retiradas forçadas resistentes à censura

Se assumirmos que a questão dos contratos de múltiplas assinaturas/controle oficial da ponte mencionada acima pode ser ignorada, ou seja, não há problema nesse nível, então a próxima camada mais importante deve ser a resistência à censura de saques. Em relação à importância da funcionalidade de saque 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 usuário pode ou não retirar com sucesso os ativos da Camada 2 para a Camada 1 é um indicador de segurança muito importante.

Se o sequenciador da Camada 2 continuar rejeitando suas solicitações de transação, ou falhar/estiver inativo por um longo período, seus ativos serão “congelados” e nada poderá ser feito. Mesmo que os sistemas de prova de DA e de prova de fraude/ZK estejam disponíveis, sem uma solução anti-censura, tal Camada 2 não é suficientemente segura e seus ativos podem ser retidos a qualquer momento. Além disso, a solução Plasma, que já foi muito popular no ecossistema Ethereum, permite que qualquer pessoa retire seus ativos com segurança para a Camada 1 quando o DA falha ou a prova de fraude falha. Neste momento, toda a rede da Camada 2 é basicamente descartada, mas ainda há uma maneira de seus ativos escaparem ilesos. Obviamente, a função de saque resistente à censura é mais básica e de nível inferior do que os sistemas de DA e prova.

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

Alguns projetos Ethereum Camada 2, como Loopring e StarkEx, dYdX, Degate, etc., irã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 enviado pelo usuário na Camada 1 não receber resposta do sequenciador da Camada 2 ao final do período de 7 dias, a função de Congelamento pode ser acionada manualmente para colocar a L2 em 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 ficará congelada por um ano. Em seguida, os usuários podem enviar uma prova de Merkle para comprovar o status de seus ativos na Camada 2 e retirar diretamente o dinheiro na Camada 1 (na realidade, 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 saída de emergência só pode ser implementado em uma cadeia como o Ethereum que suporta contratos inteligentes. O Bitcoin não pode executar lógica tão complexa. Em outras palavras, a função de saída de emergência é 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 é a segunda "roda auxiliar". No entanto, é muito mais conveniente simplesmente declarar uma "solicitação de saque forçado" do que ativar diretamente a saída de emergência. O primeiro requer apenas 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 enviar a todos os nós da Camada 2 (isso pode contornar diretamente o sequenciador e comunicar solicitações a outros nós da Camada 2). Se a "solicitação de saque forçado" não receber resposta por um longo tempo, é um projeto mais razoável para o usuário acionar o modo de cabine de saída.

(Reference: Quão importantes são as funções de saque forçado e cabine de escape para a Camada 2）

Atualmente, já existem equipes de Camada 2 do Bitcoin que planejam imitar o método de implementação de transações forçadas do Arbitrum e permitir que os usuários emitam declarações de transações forçadas (Envelopes de Transações Forçadas) na cadeia do Bitcoin. Sob essa solução, os usuários podem contornar o sequenciador e 'transmitir suas vozes' diretamente para outros nós da Camada 2. Se o sequenciador ainda rejeitar a solicitação do usuário após ver a declaração de transação forçada do usuário, isso será notado por outros nós da Camada 2 e pode ser punido.

Mas o problema é que a função de transação forçada do Arbitrum, beneficiando-se de seu sistema à prova de fraudes, pode punir Sequencers/Proponentes que têm ignorado as transações dos usuários. No entanto, o Bitcoin Camada 2, que é difícil de verificar a prova de fraudes na Camada 1, encontrará certos desafios a esse respeito. (Não vamos discutir o BitVM por enquanto) Se for uma solução como 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 sua confiabilidade, e talvez precisemos avaliar os detalhes de implementação de diferentes projetos.

É claro que, dado que muitos Bitcoin Camada 2 atualmente operam de forma semelhante a side chains, é equivalente perceber que o sequenciador descentralizado pode resolver o problema de anti-censura em certa medida. Mas isso é apenas um meio auxiliar eficaz, certamente não é a solução definitiva.

PS: Algumas soluções atuais de Camada 2, como Validium, etc., não são perfeitas no design do mecanismo de cabine de escape. Quando o sequenciador lança um ataque de retenção de dados/DA não está disponível, os usuários não podem sacar dinheiro. Mas isso se deve ao design imperfeito da cabine de escape da Camada 2. Teoricamente, a retirada ideal da escotilha de fuga 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, o nome DA/disponibilidade de dados acabou sendo falso.

A liberação de dados, como o nome sugere, refere-se a se os dados de blocos/transações/parâmetros de transição de estado mais recentes podem ser recebidos com sucesso por aqueles que precisam. Os dados publicados em cadeias diferentes têm confiabilidades diferentes.

(Reference:Mal-entendido sobre disponibilidade de dados: DA = liberação de dados ≠ recuperação de dados históricos)

É geralmente aceite na comunidade ocidental que as cadeias públicas estabelecidas, como o Bitcoin e o Ethereum, são as camadas de DA mais confiáveis. Se o classificador de Camada2 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 escala pura 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 Camada1, o que é garantido por meio de prova de validade/prova de fraude.

Por exemplo, após o sequenciador ZK Rollup publicar os dados da transação na Camada 1, ele acionará 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 submetidos pelo Proponente estão associados aos dados Tx submetidos pelo Sequenciador, ou seja, Novo Stateroot=STF(Stateroot Antigo，Txdata). STF é a função de transição de estado. Isto garante que os dados/DA de transição de estado sejam carregados forçosamente para a cadeia. Se você apenas submeter o stateroot e o certificado de validade, não será capaz de passar na verificação do contrato validador. Quanto à questão de 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 enfrentar problemas de “Ataque de Retençã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 reter 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 se tornar “cego”.

Se isso acontecer, toda a rede da 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 Camada 2 (Plasma e Optimium) baseado em prova de fraude, o classificador pode reescrever os dados/ativos sob qualquer conta à vontade; se for Camada 2 (Validium) baseado em prova de validade, embora o classificador não possa reescrever sua conta à vontade, neste momento, toda a rede da Camada 2 se tornou uma caixa preta. Ninguém sabia o que aconteceu lá dentro, e não era diferente de ser descartado. Por causa disso, as soluções ortodoxas da Camada 2 no ecossistema do Ethereum são basicamente Rollup, enquanto Validium e Optimium muitas vezes não são reconhecidos pela Ethereum Foundation.

(Reference: Prova de Retenção de Dados e Fraude: Por que o Plasma Não Suporta Contratos Inteligentes）

Portanto, a confiabilidade da camada DA/disponibilidade de 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 o Bitcoin Camada 2, 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, contanto 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 (o BitVM não é discutido aqui). Vamos primeiro supor que o Bitcoin L2 não tenha um sistema de verificação de prova. Idealmente, se o classificador L2 realmente fizer algo mal e publicar uma raiz de estado que não está relacionada aos dados DA na camada de liquidação/BTC, ainda não poderá realmente roubar os ativos do usuário porque a raiz de estado/resultado de transição de estado que ele apresenta unilateralmente não será reconhecida pelos nós honestos, mas no final pode ser apenas auto prazer. (Neste momento, contanto que os nós executados pelos provedores de instalações periféricas no ecossistema, como exchanges e pontes entre cadeias, não coludam com o sequenciador, o sequenciador não pode perceber rapidamente os ativos roubados publicando dados errôneos. Depois, assim que um nó honesto descobrir que algo está errado e emitir um alarme em um 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 instalações de terceiros como pontes entre cadeias e exchanges não reconheçam dados errôneos, os controladores maliciosos da Camada 2/side chain não serão capazes de sacar com sucesso. A menos que ele convença outros a negociar diretamente OTC 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 mesmo)

Há aqui um ponto muito interessante. Na verdade, tanto o Ethereum Layer 2 quanto o Bitcoin Layer 2 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 de consenso social (desde que haja um sistema maduro de prova de fraude/prova de validade). A solução de "verificação do cliente" do Bitcoin Layer 2 muitas vezes depende muito do "consenso social" e trará riscos correspondentes. (Para o Bitcoin Layer 2, esse risco de segurança é basicamente controlável, mas ainda pode fazer com que algumas pessoas percam ativos. Para Ethereum Layer 2, como sua ponte oficial precisa provar a cooperação do sistema, se o sistema de prova não for perfeito, a ordem O servidor pode roubar ativos do usuário e fugir em L1. Claro, os detalhes dependem de como o componente de ponte de cadeia cruzada é projetado). Assim, uma Camada 2 que possa implementar um sistema de verificação à prova de fraude/validade na Camada 1 será sempre muito melhor do que um simples modelo de "verificação de cliente". PS: Como a maioria dos Bitcoin Layer 2s que usam sistemas à prova de fraude/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 Bitcoin através da solução BitVM na Camada 1. No entanto, a implementação desta solução é muito difícil e encontrará grandes desafios. Como a comunidade Ethereum já discutiu muito sobre o sistema de prova e verificação baseado em Layer1, que já é bem conhecido, este artigo não pretende entrar em detalhes sobre o "sistema de prova e verificação baseado em Layer1".

Conclusão

Após uma análise do modelo de barril simples, podemos inicialmente chegar a uma conclusão: No modelo de segurança da Camada 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 do contrato/oficial estão razoavelmente dispersos

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

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

4. Se um sistema confiável de prova de fraude/prova de validade for implantado na Camada 1

É claro, não analisamos a Rede Lightning/Canal de Estado e o ecossistema da ICP com ckBTC, Protocolo de Índice de Inscrição e outras soluções, pois são bastante diferentes das soluções típicas de Rollup, Plasma, Validium ou verificação de cliente. Devido a restrições de tempo, é difícil para nós realizar uma avaliação prudente de sua segurança e fatores de risco, mas considerando sua importância, o trabalho de avaliação relevante será realizado conforme programado no futuro. Ao mesmo tempo, existem sérias diferenças 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 eventualmente explodirá com grande vitalidade.

Disclaimer:

1. Este artigo é reimpresso de [Gate极客web3]. Todos os direitos autorais pertencem ao autor original [Faust & 难月，极室web3]. Se houver objeções a esta reedição, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.