Camada3: Arquitetura Multi-Chain e Expansão Tecnológica

TL;DR1) 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.

• 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;

• 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：- 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.- Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.- 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.