TL;DR
1) Uma vez que tanto a camada 2 quanto a camada 3 teoricamente dependem da mainnet para liquidação, uma suposição comum é que a camada 3 primeiro comprime os dados e depois os envia para a camada 2 para compressão secundária, essencialmente adicionando outro Rollup em cima de um Rollup. Essa abordagem tem sido criticada e questionada porque se imaginarmos que a camada 4 e a camada 5 usem uma arquitetura semelhante, isso levaria a um beco sem saída, já 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 necessariamente envolver compressão e depois re-compressão. Nas estratégias da camada 3 planejadas por várias pilhas da camada 2, como Arbitrum e zkSync, a camada 3 é definida como uma cadeia de aplicativos específica. Ela 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, compartilhando componentes-chave como Sequencers e Provers com a cadeia da camada 2.
Isso 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 o papel de habilitar 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 entrar na fila na camada 2 para empacotamento, tornando sensato tratar a cadeia de aplicativos da camada 3 como um tipo especial de canal Sequenciador.
3) Supondo que a camada 3 funcione puramente como um aninhamento de cadeias dentro de cadeias, naturalmente limita a escalabilidade, mas essa prática é apenas uma suposição teórica. Se a camada 2 e a camada 3 compartilham componentes críticos como Sequenciadores e Provadores, existem muitas maneiras de possibilitar a escalabilidade horizontal das cadeias da camada 3, especialmente quando a interoperabilidade entre cadeias é aprimorada.
- Conforme mencionado pelo fundador da 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 da informação sem revelar os detalhes. Quando os ativos são transferidos da Camada 3 para a Camada 2, isso pode ser realizado de forma contínua através de uma ponte ZK, possibilitando transferências atômicas de ativos entre cadeias sem a necessidade de consenso inter-cadeias adicional ou outros processos.
A tecnologia aprimorada ZK bridging 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 via Provas ZK, o que não afeta a relação entre a Camada 2 e a mainnet;
- Conforme descrito pelo fundador da Eigenlayer, @sreeramkannan, tendo os nós ativos AVS do consenso coordenado da Eigenlayer em diferentes blockchains envolve essencialmente o mesmo conjunto de nós participando na construção de consenso em várias cadeias. Ao implementar um mecanismo de recompensa e penalidade (Slash) para AVS, é teoricamente possível reduzir a probabilidade de os nós agirem de forma maliciosa. 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 punições.
Esse tipo de mecanismo econômico de recompensa e punição também pode ser aplicado a questões de confiança em um ambiente multi-cadeia. Embora não possa alcançar o mesmo nível de confiança que a tecnologia ZK, ele pode criar aproximadamente um ambiente confiável com base em um modelo econômico.
4) @VitalikButerin, em resposta a discussões que frequentemente carregam preconceitos inerentes, reiterou sua opinião de que a Camada 3 não deve ser simplistamente vista apenas como uma pilha ou extensão da Camada 2, pois isso não necessariamente traz escalabilidade efetiva. Uma vez que a Camada 3 depende da Camada 2 como sua infraestrutura e a própria Camada 2 não pode se expandir indefinidamente, o mesmo é verdade para a Camada 3. No entanto, em cenários específicos, como privacidade, aplicações específicas da Camada 3 orientadas para a privacidade podem atender algumas das preferências transacionais para a privacidade.
Em conclusão, a Camada 3 representa um recurso altamente personalizável com potencial para expansão personalizada. Do meu ponto de vista, a expansão da Camada 3 deve ser baseada nas necessidades específicas da aplicação e desenvolvida de maneira personalizada, ao contrário de um paradigma de desenvolvimento único, que não é viável em uma direção multi-cadeia para aplicações da Camada 3.
Aviso legal:
- Este artigo é reproduzido de [GateTwitter], Todos os direitos autorais pertencem ao autor original [@tmel0211]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
- Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
- As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.
