Vitalik: Que tipo de Camada3 é significativo

Se pudermos construir o protocolo L2 para ancorar a L1 para alcançar segurança e aumentar a escalabilidade, então podemos construir o protocolo L3 para ancorar a L2 para alcançar segurança e aumentar mais escalabilidade?

Um tópico que muitas vezes ressurge na discussão da expansão da camada 2 é o conceito de "camada 3s". Se pudermos construir um protocolo de camada 2 ancorado na camada 1 para alcançar sua segurança e aumentar sua escalabilidade como objetivo principal, então certamente podemos expandir sua escala construindo um protocolo de camada 3 "ancorado na camada 2 para alcançar segurança e adicionar mais escalabilidade"?

Uma versão simples desta ideia é: se você tem um esquema que permite alcançar o crescimento quadrático, você pode empilhar esse esquema em si mesmo e alcançar o crescimento exponencial? Ideias semelhantes incluem-me; Documentos de extensibilidade em 2015 e; Extensão multicamada mencionada no papel Plasma. Infelizmente, um conceito tão simples de camada 3s não é tão fácil de formar uma solução viável. Devido à limitação da disponibilidade de dados, dependência da largura de banda da camada 1 extraída urgentemente, ou muitos outros problemas, há sempre algumas coisas no design que não são empilháveis e só podem lhe dar uma melhoria de escalabilidade.

Ideias mais novas em torno da camada 3s, como & nbsp; Os frameworks da Starkware são mais complexos: eles não apenas empilham as mesmas coisas em si mesmos, mas também alocam diferentes usos para a camada 2 e a camada 3. Se for feito da maneira correta, a forma subjacente dessa abordagem pode funcionar. Este artigo apresentará em detalhes o que pode ou não ser significativo na arquitetura de três camadas.

Por que você não pode continuar rolando através de rolos empilhandoExpansão de capacidade?

Rollups (veja meu artigo mais longo aqui) é uma tecnologia de extensão que combina diferentes tecnologias para resolver dois grandes gargalos de expansão na execução de blockchains: computação e dados. O cálculo foi comprovado por fraude ou; SNARK e outros métodos resolvem o problema. Eles dependem de alguns participantes para processar e verificar cada bloco, e exigem que outros executem apenas uma pequena quantidade de cálculos para verificar se o processo está concluído corretamente. Estes esquemas, especialmente SNARK, podem ser expandidos quase ilimitadamente; Podemos continuar a fazer "SNARKs de muitos SNARKs" para reduzir mais cálculos a uma única prova.

Os dados são diferentes. Rollups usa uma série de técnicas de compactação para reduzir a quantidade de dados que as transações precisam armazenar na cadeia: transferências de moeda simples são reduzidas de cerca de 100 bytes para cerca de 16 bytes, e transferências ERC20 na cadeia compatível com EVM são provenientes; Cerca de 180 bytes reduzidos para about  Uma transação ZK-SNARK protegida pela privacidade pode ser comprimida de cerca de 600 bytes para cerca de 80 bytes. Aproximadamente 8 vezes compressão em todos os casos. No entanto, o rollback ainda precisa disponibilizar dados na cadeia na mídia que possam garantir o acesso e autenticação dos usuários, para que os usuários possam calcular independentemente o status do rollback e participar como um certificador quando o certificador existente estiver offline. Os dados podem ser comprimidos uma vez, mas não podem ser comprimidos novamente - em caso afirmativo, geralmente há uma maneira de colocar a lógica do segundo compressor no primeiro compressor e obter os mesmos benefícios comprimindo-o uma vez. Portanto, "Rollups em cima de Rollups" não pode realmente fornecer enormes benefícios em termos de escalabilidade, mas, como veremos abaixo, este modelo pode ser usado para outros fins.

Então camada  Qual é a versão "sã" do 3?

Bem, vamos ver o que a Starkware defende em seus posts sobre a camada 3. Starkware é formado por criptologistas muito inteligentes, eles são racionais. Então, se eles defendem a camada 3s, sua versão será muito mais complexa do que "se os rollups compactarem dados 8 vezes, então obviamente os rollups acima dos rollups compactarão dados 64 vezes"

Esta é a figura no post da Starkware:

image

Para citar:

A figura acima mostra um exemplo de tal ecossistema. A sua L3 inclui:

1. StarkNet com disponibilidade de dados válida, por exemplo, é frequentemente usado em aplicativos que são extremamente sensíveis a preços.

2. Um sistema StarkNet específico do aplicativo personalizado para melhor desempenho do aplicativo, por exemplo, usando uma estrutura de armazenamento especificada ou compressão de disponibilidade de dados.

3. Os sistemas StarkEx (como aqueles que servem dYdX, Sorare, Immune e DeversiFi) têm a disponibilidade de dados Valid ou Rollup, o que traz imediatamente à StarkNet a vantagem comprovada de escalabilidade.

4. A instância privada da StarkNet (também como L4 neste exemplo) permite que transações do tipo proteção de privacidade existam sem incluí-las na StarkNet pública.

Podemos comprimir o artigo em "três visões de L3s":

  • L2 é usado para expansão de capacidade, e L3 é usado para funções personalizadas, como privacidade. Nesta visão, não há nenhuma tentativa de proporcionar "crescimento quadrático de escalabilidade"; Pelo contrário, há uma camada na pilha para ajudar a expansão do aplicativo e, em seguida, há uma camada independente para atender aos requisitos funcionais personalizados de diferentes casos de uso.

  • L2 é usado para expansão de capacidade geral, e L3 é usado para expansão de capacidade personalizável. A expansão de capacidade personalizável pode assumir diferentes formas: aplicações especiais que usam algo diferente do EVM para cálculo, rollups que otimizam o formato de dados de aplicações específicas para compressão de dados (incluindo separar "dados" de "prova" em cada bloco, e substituir a prova por um único SNARK), etc.

  • L2 é usado para extensões sem confiança, e L3 é usado para extensões de confiança fracas& nbsp; Validium  É um sistema que usa SNARK para verificar a computação, mas deixa a disponibilidade de dados para terceiros ou comitês confiáveis. Na minha opinião, o Validium é seriamente subestimado: em particular, muitos aplicativos de "blockchain empresarial" podem realmente ser melhor atendidos pelo certificador executando o Validium e regularmente enviar o hash para o servidor centralizado da cadeia para fornecer o melhor serviço. O nível de segurança do Validium é inferior aos rolos, mas pode ser muito mais barato.

Na minha opinião, todas as três visões são basicamente razoáveis. A ideia de que a compressão de dados especial precisa de sua própria plataforma é provavelmente a proposta mais fraca - é muito fácil projetar L2 com um esquema de compressão de camada base comum. Os usuários podem usar sub-compressores específicos da aplicação para expandir automaticamente, mas, além disso, esses casos de uso são razoáveis. Mas isso ainda deixa uma grande questão: a estrutura de três níveis é a maneira certa de alcançar esses objetivos? Qual é o ponto de ancorar autenticação, sistemas de privacidade e ambientes personalizados para L2 em vez de apenas L1? Os factos provaram que a resposta a esta pergunta é bastante complexa.

image

É mais barato e fácil depositar e retirar dinheiro na árvore subconjunto de L2?

Um possível argumento de que o modelo de três camadas é superior ao modelo de duas camadas é que o modelo de três camadas permite que todo o sub ecossistema exista em um único rollup, o que permite que operações de domínio cruzado dentro do ecossistema ocorram muito barato sem a necessidade de completar L1 caro.

Mas acontece que mesmo em dois L2s; Mesmo entre L3, depósitos e levantamentos podem ser muito baratos. A chave é que tokens e outros ativos não precisam ser emitidos na cadeia raiz. Ou seja, você pode ter token ERC20 no Arbitrum, criar seu wrapper no Optimism, e mover-se para trás e para frente entre eles sem qualquer transação L1!

Vamos ver como esse sistema funciona. Existem dois tipos de contratos inteligentes: o contrato básico no Arbitrum e o contrato de token encapsulado no Optimismo. Para transferir da Arbitrum para Optimism, você precisa enviar tokens para o contrato subjacente, o que gerará um recibo. Uma vez finalizado o Arbitrum, você pode obter o certificado Merkle do recibo e enraizá-lo no status L1 e, em seguida, enviá-lo para o contrato de token de embalagem em Optimism, que o verifica e emite um token de embalagem. Para mover o token de volta, você pode fazer a mesma coisa ao contrário.

image

Embora o caminho Merkle necessário para provar o depósito no Arbitrum deva passar pelo status L1, Optimism só precisa ler a raiz de status L1 para processar o depósito - nenhuma transação L1 é necessária. Observe que, como os dados de rollups são o recurso mais escasso, a implementação real deste esquema usará a certificação SNARK ou KZG em vez da certificação Merkle para economizar espaço.

Comparado com tokens baseados em L1, este esquema tem uma fraqueza fatal (pelo menos no tempo de execução ideal  ): os depósitos ainda precisam esperar pela janela de prevenção de fraudes. Se o token estiver enraizado em L1, levará uma semana para retirar do Arbitrum ou Optimism para L1, mas o depósito é instantâneo. No entanto, neste esquema, tanto os depósitos como os levantamentos exigem um atraso de uma semana. Em outras palavras, não está claro se a arquitetura de três camadas nos rolos ideais é melhor: para garantir que o jogo antifraude que ocorre no sistema em execução no próprio jogo antifraude é seguro, há muitas complexidades técnicas.

Felizmente, nenhum desses problemas se tornará um problema para o ZK rollups. Por razões de segurança, o ZK rollups não precisa de uma janela de espera de até uma semana, mas eles ainda precisam de janelas mais curtas para os outros dois motivos (a tecnologia de primeira geração pode demorar 12 horas). Primeiro, especialmente o ZK-EVM geral mais complexo; Rollups levam mais tempo para cobrir o tempo de computação não paralelizável do bloco. Em segundo lugar, por razões econômicas, raramente é necessário apresentar provas para minimizar os custos fixos associados à transação de prova. Próxima geração, incluindo hardware dedicado; A tecnologia ZK-EVM resolverá o primeiro problema, enquanto a verificação em lote com melhor arquitetura pode resolver o segundo problema. O que vamos discutir a seguir é o problema da otimização e envio em lote de provas.

Rollups e validums têm uma troca entre tempo de confirmação e custo fixo. L3 pode ajudar a resolver este problemaMas qualquer outra coisa está bem.Faz isto

Rollups para cada transação são baratos: são apenas 16-60 bytes de dados, dependendo da aplicação. Mas os rollups devem pagar um alto custo fixo cada vez que enviam um lote de transações para a cadeia: optimal  Cada lote de rolos precisa de gás 21000 L1, enquanto os rolos ZK precisam de mais de 400000 gás (se você quiser fornecer segurança quântica apenas com STARKS, você precisa de milhões de gás).

Claro, o rollback pode simplesmente esperar por uma transação L2 com um valor de 10 milhões de gás para enviar todo o lote (transação), mas isso lhes trará um intervalo de lote muito longo, forçando os usuários a esperar mais por confirmação de alta segurança. Portanto, eles precisam equilibrar: intervalo de lote longo e custo ideal, ou intervalo de lote curto e custo muito aumentado.

Para nos dar alguns números específicos, vamos considerar uma transmissão ERC20 totalmente otimizada (23 bytes) com um custo de 600000 roll ups de gás ZK por lote e um custo de transação de 368 gás. Suponha que esse roll ups esteja no estágio inicial a meio da adoção, e o TPS seja 5. Podemos calcular o gás entre cada transação e lote:

Se entrarmos em um mundo com um grande número de verificações personalizadas e ambientes de aplicação específicos, muitos deles terão uma capacidade de processamento de muito menos de 5TPS por segundo. Portanto, é importante confirmar a troca entre tempo e custo. Na verdade, o paradigma "L3" resolve esse problema! Mesmo uma implementação simples do rollback ZK no rollback ZK tem um custo fixo de cerca de 8000 camadas de gás 1 (500 bytes para prova). Isso mudará a tabela acima para:

image

O problema é basicamente resolvido, então L3s  Não é bom? Talvez sim. No entanto, deve-se notar que existe outra forma de resolver esse problema que a ERC  4337 Inspiration of aggregation verification.

A estratégia é a seguinte. Hoje, se cada ZK rollup ou validade receber um certificado, ele provará Snovo& nbsp;= STF(S)velho,D): A nova raiz de estado deve ser o resultado do processamento correto de dados de transação ou incremento de estado na raiz de estado antiga. Neste novo esquema, a ZK rollback aceitará a mensagem do contrato de verificador de lote, que diz que verificou a prova de um lote de declarações, cada uma na forma de Snovo& nbsp;= STF(S)velho,D).Esta prova de lote pode ser realizada pelo esquema recursivo SNARK ou; Halo  Agregado para construir.

image

Este será um protocolo aberto: qualquer pacote cumulativo ZK pode ser unido, e qualquer verificador de lote pode provar a partir de qualquer agregação cumulativa ZK compatível e obter compensação pelos custos de transação do agregador. O contrato do batedor validará a prova uma vez, e então passará uma mensagem para cada rollups com o(Svelho,  SnovoD)  triplo. O fato de Triple vir do contrato do programa em lote será usado como evidência para provar que a conversão é eficaz.

Se devidamente otimizado, o custo de cada resumo neste esquema pode ser próximo de 8000, dos quais 5000 é usado para adicionar novas gravações de status atualizadas, 1280 é usado para raízes antigas e novas raízes e um adicional 1720 é usado para processamento de dados diversos. Por conseguinte, dar-nos-á a mesma poupança. Starkware realmente tem algo semelhante, chamado  SHARP, embora não seja (ainda) um contrato aberto sem licença.

Uma resposta a essa abordagem pode ser: mas essa não é realmente outra solução da camada 3? Teremos uma camada de base. mecanismo de lote <- Rollup ou  Validium para substituir a camada base rollup <- Validium. Do ponto de vista de algum quadro filosófico, isso pode ser verdade. No entanto, há uma diferença importante: o nível médio não é um sistema EVM complexo e completo, mas um objeto simplificado e altamente especializado. Portanto, é mais provável que seja seguro. É mais provável que seja construído sem outro token especial. É mais provável que seja governado no nível mais baixo e não mude ao longo do tempo.

Conclusão: O que é"Camada”?

Uma arquitetura de escala de três camadas consistindo em empilhar o mesmo esquema de escala em cima de si mesma geralmente não funciona bem. A forma de rollups em cima de rollups (em que duas camadas de rollups usam a mesma tecnologia) também é insatisfatória. No entanto, a arquitetura de três camadas de L2 e L3 com diferentes propósitos pode funcionar. Validiuns em rollups realmente fazem sentido, mesmo que eles não tenham certeza de que eles são a melhor maneira de fazer as coisas a longo prazo.

No entanto, uma vez que comecemos a entender profundamente os detalhes significativos de qual arquitetura, entraremos na questão filosófica: o que é "camada" e o que não é? camada base <- mecanismo de lote <- Rollup ou validade e camada base<- rollup <- Rollup ou validade faz o mesmo trabalho, mas em termos de seu modo de trabalho, prova que a camada de polimerização se parece mais com ERC-4337 do que rollups. Geralmente, ERC-4337 não é chamado de "camada  2". Da mesma forma, não chamaremos Tornado Cash de "Camada  2",  Portanto, se queremos ser consistentes, não vamos chamar o subsistema centrado na privacidade acima de L2 L3. Portanto, há um debate semântico não resolvido sobre o que deve ser chamado de "Camada" primeiro.

Há muitas escolas de pensamento possíveis a este respeito. Minha preferência pessoal é limitar o termo "Camada  2" a coisas com os seguintes atributos:

1. Seu objetivo é melhorar a escalabilidade

2. Eles seguem o modelo "blockchain em blockchain": eles têm seu próprio mecanismo de processamento de transações e seu próprio estado interno

3. Eles herdaram toda a segurança da cadeia Ethereum

Portanto, os rolos ideais e os rolos ZK são L2, mas é outra questão verificar e comprovar o esquema de agregação, ERC 4337, sistema de privacidade online e Solidity. Pode ser significativo chamar alguns deles L3, mas pode não ser todos eles; Em qualquer caso, parece muito cedo para determinar a definição, e a arquitetura do ecossistema multiresumo está longe de ser estática. A maioria das discussões são conduzidas apenas em teoria.

Por outras palavras, o debate sobre a linguagem não é tão importante quanto a estrutura que constitui, na realidade, o problema técnico mais significativo. Obviamente, algumas "camadas" que atendem requisitos não extensíveis, como privacidade, podem desempenhar um papel importante, e precisam ser preenchidas com funções importantes para provar agregação de alguma forma, preferencialmente através de protocolos abertos. Mas, ao mesmo tempo, temos razões técnicas suficientes para tornar o link para o ambiente orientado para o usuário e o nível médio de L1 o mais simples possível; Em muitos casos, a "camada de cola" como um resumo de EVM pode não ser o método correto. Suspeito que à medida que o ecossistema estendido L2 amadurece, as estruturas mais complexas (e mais simples) descritas neste artigo começarão a desempenhar um papel maior.

Fonte: Chain Catcher

Escrito por Vitalik, Que tipo de camada 3 faz sentido

Compilado por: Dong Yiming, Chain Catcher

  Agradecimentos especiais a Georgios Konstantopoulos, Karl Florsch e Starkware por seus comentários e comentários.