Uma Camada 2 que possa implementar um sistema de verificação à prova de fraude/prova de validade na Camada 1 será sempre muito melhor do que um simples modelo de “verificação do cliente”.
Escrito por: Faust & Wuyue, geek web3
Consultor: Kevin He (@0xKevinHe), vice-presidente de tecnologia Xinhuo
Introdução: O cientista de gestão americano Lawrence Peter propôs certa vez a “teoria do barril”, que acredita que o desempenho geral de um sistema é limitado pela sua parte mais fraca. Em outras palavras, a quantidade de água que um barril pode conter é determinada pela placa mais curta. Embora este princípio seja simples, muitas vezes é esquecido. **Os debates anteriores sobre a segurança da Camada 2 ignoraram principalmente a prioridade e a importância dos diferentes componentes. Eles basicamente se concentraram na confiabilidade da transição de estado e nas questões de DA, mas ignoraram elementos de nível inferior e mais importantes. Dessa forma, toda a base teórica provavelmente nem mesmo sustentável. Portanto, quando discutimos um sistema complexo multimódulo, devemos primeiro descobrir qual peça é a “placa mais curta”.
Inspirados pela teoria do barril, fizemos uma análise do sistema e descobrimos que existem dependências óbvias entre diferentes componentes no modelo de segurança Bitcoin/Ethereum Layer 2, ou que alguns componentes são mais seguros que outros. O sexo é mais básico e importante, então -chamado de “mais curto”.
Nesse sentido, podemos inicialmente priorizar a importância/base dos diferentes componentes no modelo de segurança principal da Camada 2 da seguinte forma:**
- Se a autoridade de controle do contrato/ponte oficial está razoavelmente dispersa (quão concentrada está a autoridade de controle de assinaturas múltiplas)?
- Existe uma função de retirada resistente à censura (retirada forçada, saída de emergência)
- Se a camada DA/forma de liberação de dados é confiável (se os dados DA são liberados em Bitcoin ou Ethereum)
- Se um sistema confiável à prova de fraude/validade foi implantado na Camada 1 (Bitcoin L2 requer BitVM)
Devemos absorver moderadamente os resultados da pesquisa da Camada 2 da comunidade Ethereum e evitar o Lysenkoismo
Comparado com o altamente ordenado sistema Ethereum Layer 2, o Bitcoin Layer 2 é como um mundo totalmente novo. Este novo conceito, que se tornou cada vez mais importante após a mania das inscrições, está mostrando um impulso crescente, mas seu ecossistema está se tornando cada vez mais caótico e caótico. do caos, vários projetos da Camada 2 surgiram como cogumelos depois da chuva. Embora tragam esperança ao ecossistema Bitcoin, eles escondem deliberadamente 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”. Eles têm uma forte tendência a seguir um caminho extremista.
Considerando as diferenças nos atributos funcionais entre Bitcoin e Ethereum, Bitcoin Layer 2 está destinado a ser incapaz de se alinhar com Ethereum Layer 2 nos primeiros dias, mas isso não significa que devemos negar completamente que Ethereum e até mesmo a indústria de blockchain modular há muito tempo que o bom senso da indústria chegou à conclusão final (consulte o “incidente de Lysenko”, no qual o ex-biólogo soviético Lysenko usou questões ideológicas para perseguir os defensores da genética ocidentais).
Pelo contrário, estes padrões de avaliação, obtidos pelos “antecessores” com grandes esforços, já demonstraram forte poder de persuasão depois de serem amplamente reconhecidos.Definitivamente, não é um movimento racional negar deliberadamente o valor destas conquistas. **
**Ao construir a Camada 2 do Bitcoin, devemos compreender plenamente a importância de “aprender com o Ocidente e aplicá-lo ao Oriente” e absorver e otimizar adequadamente as muitas conclusões da comunidade Ethereum. Mas ao recorrer a perspectivas fora do ecossistema Bitcoin, devemos estar cientes das diferenças nos seus pontos de partida e, em última análise, procurar um terreno comum, reservando as diferenças. **
Isto é como discutir as semelhanças e diferenças entre “ocidentais” e “orientais”. Independentemente de ser ocidental ou oriental, o sufixo “人” expressa muitas características semelhantes, mas quando corresponde a prefixos diferentes como “ocidental” e “oriental”, as características de subdivisão serão diferentes.
Mas, em última análise, é provável que haja uma sobreposição entre “ocidentais” e “orientais”, o que significa que muitas coisas que se aplicam aos ocidentais também são aplicáveis aos orientais, e muitas coisas que se aplicam à “camada 2 do Ethereum”, também aplica-se a “Bitcoin Layer2”. **Antes de distinguir as diferenças entre Bitcoin L2 e Ethereum L2, pode ser mais importante e significativo esclarecer a interoperabilidade entre os dois.
Aderindo ao propósito de “buscar pontos comuns e ao mesmo tempo reservar diferenças”, o autor deste artigo não pretende discutir “o que é Bitcoin Layer 2 e o que não é”, ** porque este tópico é muito controverso, até mesmo a comunidade Ethereum tem não discutimos “o que é Ethereum Layer 2”, quais não são Layer 2" e alcançamos uma visão objetiva e consistente.
**Mas o certo é que embora diferentes soluções técnicas tragam efeitos de expansão ao Bitcoin, elas também apresentam diferentes riscos de segurança. Os pressupostos de confiança existentes em seus modelos de segurança serão o tema que este artigo pretende focar. **
Como entender os critérios de segurança e avaliação da Camada2
Na verdade, a segurança da Camada 2 não é um ponto de discussão novo. Até a palavra segurança é um conceito composto que inclui vários atributos subdivididos.
Anteriormente, o fundador do **EigenLayer havia simplesmente subdividido a “segurança” em quatro elementos, incluindo “irreversibilidade da transação (anti-reversão), resistência à censura, confiabilidade de liberação de DA/dados e validade de transição de estado”. **
(O fundador da EigenLayer certa vez expressou sua opinião 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 Ethereum Community OG propuseram um modelo de avaliação de risco relativamente sistemático da Camada 2. É claro que essas conclusões visam a Camada 2 de contratos inteligentes, em vez da Camada 2 de contratos não inteligentes típicos, como rollup soberano e verificação de clientes.
**Embora não seja 100% adequado para Bitcoin L2, ainda contém muitas conclusões dignas de reconhecimento. A maioria de suas opiniões foram amplamente reconhecidas na comunidade ocidental, ** e também facilita nossa avaliação objetiva dos riscos de diferentes Bitcoins. L2.
(Vitalik disse uma vez que, como a solução Rollup não pode atingir 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 “rodas de treinamento” e introduzirão suposições de confiança. Essas 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 de um pequeno número de nós formando um “comitê” na forma de uma cadeia lateral. ser centralizado. Se o sequenciador/comitê não for restrito, ele pode roubar ativos do usuário e fugir a qualquer momento. Ele pode recusar solicitações de transação dos usuários, fazendo com que os ativos sejam congelados e inutilizáveis. **Isso envolve a eficácia da transição de estado e a resistência à censura mencionadas anteriormente pelo fundador da EigenLayer. **
Ao mesmo tempo, como o Ethereum Layer2 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, o Layer2 oficial) puder atualizar rapidamente a lógica do contrato, adicionar 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 ativos sob custódia.
**Isso é atribuído ao “problema de distribuição de múltiplas assinaturas de contrato”, e o problema de distribuição de múltiplas assinaturas também se aplica à Camada 2 do Bitcoin, ** porque a Camada 2 do Bitcoin geralmente depende da “Ponte Notarial” e requer vários nós para liberar por meio de solicitações de cadeia cruzada com múltiplas assinaturas, o Bitcoin Layer 2 também tem o problema de como distribuir razoavelmente as assinaturas múltiplas.Podemos até considerá-lo como a “roda auxiliar” mais básica do Bitcoin Layer 2. **
**Além disso, a questão do DA é extremamente importante. **Se a Camada2 não fizer upload de dados para a Camada1, mas escolher alguns locais de lançamento de DA não confiáveis, se esta camada DA fora da cadeia (comumente conhecida como Comitê de Disponibilidade de Dados DAC) conspirar e se recusar a liberar os dados de transação mais recentes para o mundo exterior, os ataques de retenção de dados tornarão a rede obsoleta e poderão impedir que os usuários retirem fundos sem problemas.
L2BEAT resumiu as questões acima e resumiu vários elementos principais do modelo de segurança Layer2:
- Validação de Estado/Prova se o sistema é confiável (Validação de Estado)
- O método de publicação de dados DA é confiável? (Disponibilidade de dados)
- Se a rede Layer2 rejeitar deliberadamente sua transação/encerramento, você pode forçar a retirada dos ativos da Layer2 (Sequencer Faliure, Proposer Failure)
- Contratos relacionados à camada 2 – se o controle da ponte oficial entre cadeias é suficientemente descentralizado. Se a energia estiver relativamente concentrada, os usuários terão tempo suficiente para responder quando ocorrer “roubo de vigilância” (janela de saída)
(“Exibição do fator de risco” definida para diferentes projetos Layer2 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 puderem ser eliminados, quanta “confiança” precisamos introduzir, quantos indivíduos em um grupo precisam ser confiáveis e em quantas “rodas auxiliares” precisamos confiar.
A seguir analisaremos os fatores de risco no modelo geral Ethereum Layer2/Bitcoin Layer2** (Os objetos mencionados neste artigo não incluem “canal de estado” ou “canal de pagamento”, nem inclui o protocolo de índice de inscrição, porque são especial). **E tentaremos explorar quais fatores são mais básicos, de nível inferior 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 nossa atenção mais do que outras deficiências.
O efeito barril da Layer2 - quais são as deficiências?
A prancha mais curta - contrato/direitos oficiais de gerenciamento da ponte
Aqui, podemos também usar o “efeito barril” para analisar problemas de segurança da Camada 2. É fácil ver que a placa mais curta é a “capacidade de atualização do contrato” mencionada acima (principalmente para a Camada 2 do Ethereum), ou, além disso, é o “direito de gerenciamento da ponte oficial entre cadeias” (aplicável tanto ao Bitcoin quanto ao Ethereum Layer 2). **
Para Ethereum Layer 2, desde que o oficial da Camada 2 possa atualizar rapidamente o contrato na cadeia da Camada 1, o Token bloqueado na ponte oficial L2 de depósito e endereço de retirada pode teoricamente ser roubado, não importa quão confiável seja sua camada DA ou sistema de certificação é.
Pode-se dizer que a autoridade de controle do contrato de ponte está relacionada à segurança de todo o sistema, sendo a parte mais básica 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 múltiplas 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á o mal. **
(Os atrasos na atualização do contrato de diferentes projetos da Camada 2 são marcados no L2BEAT. A maioria dos contratos 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 por L2 Definitivamente 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 originalmente não suporta contratos inteligentes. Relativamente falando, todo o fluxo de trabalho do Ethereum Layer2 é altamente dependente do contrato na Layer1, enquanto o Bitcoin Layer2 não pode fazer isso.
(Esquema Starknet)
**Este é um problema inevitável para o Bitcoin Layer 2. Pode-se dizer que tem vantagens e desvantagens. Atualmente, parece que a “ponte sem confiança” implementada pela Camada 2 do Ethereum, baseada em contratos, não pode ser realizada no Bitcoin L2. **Esta “Ponte Confiável” requer a implantação de um contrato dedicado na Camada 1 e a cooperação do sistema à prova de fraude DA+/à prova de ZK. É essencialmente semelhante à “ponte otimista” como Orbiter ou pontes ZK como Polyhedra.
A visão dominante atual na indústria é que se você não considerar possíveis bugs na prática e considerar apenas modelos teóricos, o nível de segurança do Optimistic Bridge e do ZK Bridge é basicamente o nível mais alto. Desde que o código do contrato não contenha bugs ou não pode ser atualizado de forma maliciosa. É basicamente confiável.
(A Ponte Otimista só precisa garantir que 1 em cada N observadores seja honesto para garantir a segurança. O modelo de confiança é 1/N)
Como o Bitcoin Layer 2 não pode implantar componentes de contrato na Camada 1 (não estamos falando da Lightning Network aqui), suas pontes oficiais são basicamente “** Pontes Notariais” compostas por um pequeno número de nós, ou “Pontes Multi-Assinaturas”. Este tipo de ponte A segurança depende de como as assinaturas múltiplas/limites são configuradas, o que requer a introdução de fortes pressupostos de confiança: presume-se que estes notários não irão conspirar ou ter as suas chaves privadas roubadas. **
Atualmente, a maioria das pontes baseadas em assinaturas notariais/limites não podem ser comparadas com a “ponte confiável” oficial da Camada 2 do Ethereum em termos de segurança (a premissa é que o contrato da Camada 2 do Ethereum não será atualizado de forma maliciosa). Obviamente, a segurança dos ativos da custódia da rede **Bitcoin Layer 2 será limitada pela segurança de sua ponte oficial, ou pela descentralização do poder da ponte multi-assinatura. Esta é sua primeira “roda auxiliar”. **
Como os “direitos de atualização” dos contratos oficiais relacionados à ponte Ethereum Layer 2 são frequentemente concentrados nas mãos de alguns controladores com múltiplas assinaturas, ** se os controladores com múltiplas assinaturas conspirarem, a ponte Ethereum Layer 2 também terá problemas, a menos que it O contrato não pode ser atualizado ou está sujeito a um longo atraso** (atualmente apenas Degate e Fuel V1).
(Cada vez que os contratos Degate forem atualizados, ele reservará um período de fuga segura de 30 dias para os usuários. Durante esse período, desde que todos descubram que a nova versão do código do contrato tem lógica maliciosa, eles podem escapar com segurança por meio da retirada forçada /função de cabine de fuga)
Em relação à 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: os controladores que precisam confiar na assinatura múltipla não conspirarão para fazer o mal. **Este grupo de multi-assinaturas as assinaturas podem controlar a ponte oficial L2 ou alterá-la. A lógica do código é liberar diretamente solicitações de retirada inválidas e o resultado final é: os ativos do usuário podem ser roubados.
A única diferença entre os dois é que A ponte oficial do Ethereum Layer 2 não é confiável, desde que o contrato não seja atualizado de forma maliciosa/a janela de atualização seja longa o suficiente, mas o Bitcoin Layer 2 não pode alcançar esse efeito de qualquer maneira.
O segundo quadro mais curto - retirada forçada resistente à censura
Se assumirmos que a questão dos contratos de múltiplas assinaturas/controlo de ponte oficial mencionada acima pode ser ignorada, ou seja, não há problema com esta camada, então a próxima camada mais importante deve ser a resistência à censura das retiradas.
Em relação à importância da função de retirada forçada/cabine de fuga resistente à censura, Vitalik enfatizou em seu artigo “Diferentes tipos de camada 2” há alguns meses que o fato de os usuários conseguirem retirar ativos da Camada 2 para a Camada 1 com sucesso é um fator chave. indicador. **
Se o sequenciador da Camada 2 continuar rejeitando suas solicitações de transação ou falhar/ficar inativo por um longo período, seus ativos serão “congelados” e nada poderá ser feito. **Mesmo que sistemas DA e à prova de fraude/ZK estejam disponíveis, sem uma solução anticensura, essa Camada 2 não é segura o suficiente e seus ativos podem ser detidos a qualquer momento. **
Além do mais, a solução Plasma, que já foi muito popular no ecossistema Ethereum, permite que qualquer pessoa retire 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 está basicamente desmantelada, mas ainda há uma maneira de seus ativos escaparem ilesos. **Obviamente, a função de retirada resistente à censura é mais básica e de nível inferior do que os sistemas DA e de 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 Layer 2, como Loopring, StarkEx, dYdX, Degate, etc., configurarão uma função de ativação de retirada forçada/cabine de fuga resistente à censura na Camada 1. Tomando Starknet como exemplo, se o usuário enviar Forçado na Camada 1 Se a solicitação de retirada não receber uma resposta do sequenciador Layer2 no final do período de janela de 7 dias, a função de solicitação de congelamento pode ser chamada manualmente para colocar L2 no estado congelado e ativar o modo de cabine de fuga.
Neste momento, o classificador não pode enviar dados ao contrato Rollup em L1, e toda a Camada2 será congelada por um ano. Então, ** os usuários podem enviar uma prova merkle para comprovar o status de seu ativo na Camada 2 e sacar dinheiro diretamente na Camada 1 (na verdade, eles retiram sua própria quantia igual de fundos do endereço oficial de depósito e retirada da ponte). **
Obviamente, o modo de saída de emergência só pode ser implementado em uma cadeia como Ethereum que suporta contratos inteligentes, e o Bitcoin não pode executar uma lógica tão complexa. **Em outras palavras, a função de escotilha de fuga é basicamente uma patente da Ethereum Layer 2. Bitcoin Layer 2 deve usar alguns meios auxiliares adicionais para imitar o gato e o tigre. Esta é a segunda “roda auxiliar”. **
**Mas simplesmente declarar um “pedido de retirada forçada” é muito mais conveniente do que ativar diretamente a escotilha de fuga. **O primeiro requer apenas que o usuário envie uma transação para o endereço especificado na Camada1 e, nos dados adicionais da transação, declare os dados que deseja enviar para todos os nós da Camada2 (**Isso pode ignorar diretamente o classificador e enviar dados para outros nós da camada 2 (o nó comunica a solicitação). **Se a “retirada forçada” não receber resposta por um longo tempo, é um design mais razoável para o usuário acionar o modo cabine de fuga.
(Referência: Qual a importância das funções de retirada forçada e cabine de fuga para a Camada2?)
**Atualmente, já existem equipes Bitcoin Layer 2 que planejam imitar a implementação de transações forçadas da Arbitrum e permitir que os usuários emitam declarações de transações forçadas (Envelopes de Transações Forçadas) na cadeia Bitcoin. **Nesta solução, os usuários podem ignorar o sequenciador e “transmitir suas vozes” diretamente para outros nós da Camada2. Se o sequenciador ainda rejeitar a solicitação do usuário após ver a instrução de transação forçada do usuário, isso 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 de seu sistema à prova de fraude, pode punir o Sequenciador/Proponente que tem ignorado as transações do usuário. No entanto, a Camada 2 do Bitcoin, que é difícil de verificar à prova de fraude na Camada 1, encontrará certos desafios a este respeito. (Não vamos discutir o BitVM por enquanto) ** 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, será difícil avaliarmos seriamente sua confiabilidade, e poderemos precisar avaliar o detalhes de implementação de diferentes projetos.
Claro, dado que muitos Bitcoin Layer 2 operam atualmente de uma forma semelhante às cadeias laterais, é equivalente a realizar um ** sequenciador descentralizado, que pode resolver o problema da anticensura até certo ponto. Mas este é apenas um meio auxiliar eficaz e certamente não a solução definitiva. **
ps: Algumas soluções atuais da Camada 2, como Validium, etc., não são perfeitas no design do mecanismo da cabine de fuga. Quando o sequenciador lança um ataque de retenção de dados/DA está indisponível, os usuários não podem sacar fundos. Mas isso se deve ao design imperfeito da cabine de fuga da Camada 2. Teoricamente, a retirada ideal da cabine de fuga só pode contar com dados históricos e não precisa depender da disponibilidade de DA/novos dados)
A terceira placa mais curta: a confiabilidade da liberação de dados da camada DA
**Embora DA seja chamado de disponibilidade de dados, este termo na verdade se refere à liberação de dados. **É apenas porque Vitalik e Mustafa não pensaram cuidadosamente quando nomearam esse conceito originalmente que o nome DA/disponibilidade de dados não corresponde. Nome real.
**A liberação de dados, como o nome sugere, refere-se a se os últimos blocos/dados de transação/parâmetros de transição de estado podem ser recebidos com sucesso por aqueles que precisam. **A publicação de dados em cadeias diferentes tem confiabilidade diferente.
(Referência: Incompreensão da disponibilidade de dados: DA=liberação de dados ≠ recuperação de dados históricos)
As comunidades ocidentais geralmente acreditam que cadeias públicas estabelecidas, como Bitcoin e Ethereum, são as camadas DA mais confiáveis. Se o classificador Layer2 publicar novos dados no Ethereum, qualquer pessoa que execute o cliente Ethereum geth poderá baixar os dados e sincronizá-los sem qualquer obstáculo. **Isso ocorre porque Isso é alcançado pela enorme escala da rede Ethereum e pelo ampla variedade de fontes de dados públicos.
**Vale ressaltar que Ethereum Rollup forçará o sequenciador a publicar dados de transação/parâmetros de transição de estado na Camada1, o que é garantido através de prova de validade/prova de fraude. **
Por exemplo, após o sequenciador do ZK Rollup publicar os dados da transação na Camada1, ele acionará a lógica do contrato para gerar um datahash, e o contrato validador deverá confirmar se o certificado de validade enviado pelo Proponente tem um relacionamento correspondente com o datahash.
Isso equivale a: confirmar que o zk Proof e Stateroot enviado pela Proponente estão associados aos dados Tx enviados pelo Sequenciador, ou seja, New Stateroot=STF(Old Stateroot, Txdata). STF é a função de transição de estado.
**Isso garante que os dados de transição de estado/DA sejam carregados à força na cadeia. Se você enviar apenas a raiz de estado e o certificado de validade, ele não será capaz de passar na verificação do contrato do validador. **
Quanto a se a liberação de dados DA ou o sistema de verificação de provas é mais básico, a comunidade Ethereum/Celestia já teve uma discussão completa. A conclusão geral é: **A confiabilidade da camada DA é mais importante do que a integridade da prova de fraude/ sistema de prova de 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 "ataques de retenção de dados", o que significa:
** O sequenciador/proponente pode conspirar com os nós da camada DA sob a cadeia ETH para atualizar a raiz de estado na camada 1, mas os parâmetros de entrada correspondentes à transição de estado são retidos e não enviados, tornando impossível para estranhos julgar se o novo stateroot está correto, o que torna “olhos abertos” cegos". **
**Se isso acontecer, toda a rede da Camada 2 será equivalente a 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) com base na prova de fraude, o classificador poderá reescrever os dados/ativos sob qualquer conta à vontade; se for a Camada 2 (Validium) com base na prova de validade, embora o classificador não possa reescrever sua conta em vai, isso Naquela época, toda a rede da Camada 2 se tornou uma caixa preta. Ninguém sabia o que acontecia lá dentro e não era diferente de ser desmantelado. Por causa disso, as soluções ortodoxas da Camada 2 no ecossistema Ethereum são basicamente Rollup, enquanto Validium e Optimium muitas vezes não são reconhecidos pela Fundação Ethereum.
(Referência: Retenção de dados e prova de fraude: Por que o 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 integridade do sistema à prova de fraude/prova de validade. **Para Bitcoin Camada 2, especialmente Camada 2 baseada no modelo de verificação do cliente, mesmo que não haja sistema de verificação à prova de fraude/prova de validade na Camada 1, desde que a camada DA funcione normalmente, todos ainda podem saber se existe um erro na transição de estado da rede L2.
Atualmente, é difícil para a rede principal do Bitcoin verificar a prova de fraude/prova de validade (BitVM não será discutido aqui).Vamos primeiro supor que o Bitcoin L2 não possui um sistema de verificação de prova. Idealmente, se o classificador L2 realmente fizer o mal e publicar uma raiz estatal que não esteja relacionada aos dados DA na camada de liquidação/BTC, ele ainda não poderá realmente roubar os ativos do usuário porque enviou unilateralmente a raiz estatal/O resultado do estado a transição não será reconhecida pelos nós honestos e, no final, poderá ser apenas para prazer próprio.
*(***Neste momento, desde que os nós executados pelos provedores de instalações periféricas do ecossistema, como exchanges e pontes de cadeia cruzada, não conspirem com o sequenciador, o sequenciador não poderá realizar rapidamente os ativos roubados publicando dados incorretos. **Depois disso, desde que um nó honesto descubra que algo está errado e emita um alarme num 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 surtir efeito imediatamente)
Se for um modelo semelhante a uma cadeia lateral, onde a maioria dos nós conspiram para realizar mudanças de estado maliciosas, as pessoas poderão descobrir rapidamente o problema. Enquanto instalações de terceiros, como pontes e exchanges de cadeia cruzada, não reconhecerem dados errados, o controlador mal-intencionado da camada 2/cadeia lateral não será capaz de sacar com sucesso, a menos que ele convença outros a fazê-lo diretamente. OTC com ele na cadeia.
(Viatlik apontou uma vez no artigo que a verificação do cliente é a verdadeira base para garantir a segurança da rede blockchain, verifique você mesmo)
Há um ponto muito interessante aqui: 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 provas para garantir a validade das transições de estado e basicamente não precisa depender do consenso social (desde que haja uma prova/validade de fraude madura sistema de prova).
O esquema de “verificação do cliente” do Bitcoin Layer 2 geralmente depende fortemente do “consenso social” e trará riscos correspondentes (Para o Bitcoin Layer 2, esse risco de segurança é basicamente controlável, mas ainda é. Pode causar alguns pessoas perderem ativos. Para Ethereum Layer 2, porque sua ponte oficial precisa provar a cooperação do sistema, se o sistema for imperfeito, o sequenciador pode roubar ativos do usuário e fugir em L1. Claro, os requisitos específicos Veja como projetar o componente da ponte entre cadeias).
Portanto, uma Camada 2 que possa implementar um sistema de verificação à prova de fraude/prova de validade na Camada 1 será sempre muito melhor do que um simples modelo de “verificação de cliente”. **
**PS: Como a maior parte do Bitcoin Layer 2 que adota o sistema de prova de fraude/prova de validade não pode permitir que a Camada 1 participe diretamente do processo de verificação de prova, sua essência ainda é apenas tratar o Bitcoin como a camada DA, e o modelo de segurança é equivalente a “verificação final 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”.
Resumir
Após uma análise simples do modelo barril, podemos inicialmente tirar uma conclusão**: No modelo de segurança mainstream Layer2, de acordo com o grau de importância/grau básico, ele pode ser classificado da seguinte forma:**
- Se a autoridade de controle do contrato/ponte oficial está razoavelmente dispersa
- Existe uma função de retirada resistente à censura?
- O formulário de liberação de dados/camada DA é confiável?
- Se um sistema confiável à prova de fraude/validade é implantado na Camada 1
É claro que não analisamos o ckBTC, Inscription Index Protocol e outras soluções do ecossistema Lightning Network/State Channel e ICP, porque eles são bastante diferentes das soluções típicas de Rollup, Plasma, Validium ou verificação de cliente. Devido a limitações de tempo, é-nos difícil realizar uma avaliação prudente dos seus factores de segurança e de risco, mas tendo em conta a 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 sobre se o Protocolo de Índice de Inscrição deve ser considerado como Camada 2. No entanto, independentemente da definição de Camada 2, coisas novas, como o Protocolo de Índice de Inscrição, trouxeram inovação tecnológica suficiente ao ecossistema Bitcoin e eventualmente explodirá com grande vitalidade.
