TL;DR

1) Uma vez que tanto a camada 2 como a camada 3 teoricamente dependem da mainnet para o ajuste, pressupõe-se frequentemente que a camada 3 comprime primeiro os dados e depois os submete à camada 2 para compressão secundária, essencialmente colocando um Rollup em cima de outro Rollup. Esta abordagem tem sido criticada e questionada porque se imaginarmos a camada 4 e a camada 5 a utilizar uma arquitetura semelhante, isso levaria a um beco sem saída, uma vez que os dados não podem ser comprimidos indefinidamente.

2) Na realidade, a interação entre a camada 3 e a camada 2 pode não envolver necessariamente a compressão e posterior re-compressão. Nas estratégias da camada 3 planeadas por múltiplos stacks da camada 2 como Arbitrum e zkSync, a camada 3 é definida como uma cadeia de aplicação específica. Terá um alto grau de autonomia em aspectos como mecanismos de consenso, escolhas de taxas de gás e modelos econômicos. No entanto, autonomia não significa independência completa, uma vez que a arquitetura subjacente é provavelmente limitada pela infraestrutura fundamental construída para a camada 2, como a partilha de componentes-chave como Sequencers e Provers com a cadeia da camada 2.

Isto significa que as transações na camada 3 são processadas diretamente pelo Sequenciador da camada 2 e enviadas para a mainnet para confirmação do estado final. A camada 2 assume mais um papel na habilitação de funções de interoperabilidade entre várias cadeias da camada 3, onde a chamada 'camada de liquidação' é meramente para empacotamento de dados e não a liquidação final no verdadeiro sentido. As transações na camada 3 também precisam aguardar na camada 2 para empacotamento, tornando sensato tratar a cadeia de aplicação da camada 3 como um tipo especial de canal Sequenciador.

3) Supondo que a camada 3 funcione puramente como uma aninhamento de cadeias dentro de cadeias, naturalmente limita a escalabilidade, mas esta prática é apenas uma suposição teórica. Se a camada 2 e a camada 3 compartilharem componentes críticos como Sequenciadores e Verificadores, existem muitas maneiras de possibilitar a escalabilidade horizontal das cadeias da camada 3, especialmente quando a interoperabilidade entre cadeias é aprimorada.

1. Como mencionado pelo fundador do zkSync, @gluk64, usando a tecnologia ZK como base para a interoperabilidade entre várias blockchains é viável porque a tecnologia ZK permite que duas contrapartes verifiquem a autenticidade das informações sem revelar os detalhes. Quando os ativos são transferidos da Camada 3 para a Camada 2, isso pode ser facilmente realizado através de uma ponte ZK, permitindo transferências de ativos atômicos entre cadeias sem a necessidade de consenso inter-cadeia adicional ou outros processos.

A tecnologia de ponte aprimorada pela tecnologia ZK permite suporte fundamental para a expansão multi-cadeia da Camada 3 porque, independentemente de quantas Camadas 3 estejam implantadas, elas liquidam diretamente com a Camada 2 através das Provas ZK, o que não afeta a relação entre a Camada 2 e a rede principal;

1. Como descrito pelo fundador da Eigenlayer, @sreeramkannan, ter os nós ativos AVS da camada Eigenlayer coordenam o consenso entre diferentes blockchains envolve essencialmente o mesmo conjunto de nós participando na construção do consenso em várias cadeias. Ao implementar um mecanismo de recompensa e penalização (corte) para AVS, é teoricamente possível reduzir a probabilidade de os nós agirem maliciosamente. Se os nós aprovarem a transferência de ativos da Camada 3 para a Camada 2 e houver má conduta, eles estarão sujeitos a penalizações.

Este tipo de mecanismo económico de recompensa e punição também pode ser aplicado a questões de confiança num ambiente multi-cadeia. Embora não consiga alcançar o mesmo nível de confiança que a tecnologia ZK, pode criar de forma aproximada um ambiente confiável com base num modelo económico.

4) @VitalikButerin, em resposta a discussões que frequentemente apresentam viéses inerentes, reiterou sua visão de que a Camada 3 não deve ser simplistamente vista apenas como uma pilha ou extensão da Camada 2, uma vez que isso não traz necessariamente escalabilidade eficaz. Como a Camada 3 depende da Camada 2 como sua infraestrutura e a Camada 2 por si só não pode se expandir indefinidamente, o mesmo vale para a Camada 3. No entanto, em determinados cenários específicos, como privacidade, aplicações específicas de Camada 3 orientadas para a privacidade podem atender a algumas das preferências transacionais por privacidade.

Em conclusão, a Camada 3 representa uma funcionalidade altamente personalizável com potencial para expansão adaptada. Do meu ponto de vista, a expansão da Camada 3 deve ser baseada nas necessidades específicas da aplicação e desenvolvida de forma personalizada, ao contrário de um paradigma de desenvolvimento único que não é viável numa direção multi-cadeia para aplicações da Camada 3.

Aviso legal：

1. Este artigo é reproduzido a partir de [GateTwitter], Todos os direitos de autor pertencem ao autor original [@tmel0211]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles tratarão do assunto prontamente.
2. Isenção de Responsabilidade: As opiniões expressas 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.