Autores: krane, lamby (Asula), sylve, lancelot (Hyle) Fonte: bedlam research Tradução: Shanooba, Golden Finance

Introdução

Na última semana, vimos várias propostas sobre o roteiro da camada de Consenso do Ethereum (ETH). O mais notável foi o discurso de Justin Drake na Devcon 2024, onde ele apresentou sua visão para a era ZK do Ethereum. Ela é chamada de cadeia Beam ou forquilha Beam e traz várias atualizações importantes para o Ethereum, incluindo a redução do tempo de slot, aceleração da finalização e a 'snarkificação' do Consenso do Ethereum. As reações em relação a essa proposta e o cronograma dessas mudanças têm sido variadas. No entanto, considerando o tamanho da economia do Ethereum, também devemos reconhecer a importância de sermos cautelosos com o Ethereum. Apesar disso, é útil considerar qual é a ambição máxima para a camada base de um ecossistema centrado no rollup. Seguindo o espírito de 'não sermos sobrecarregados pelo passado, apenas pelo futuro', este artigo apresenta um futuro que aproveita o progresso da pesquisa em ZK e Consenso.

Vamos começar por estudar a camada básica a partir de princípios fundamentais e depois explorar os conceitos-chave da pesquisa de Consenso. Por fim, vamos investigar como aplicar esta pesquisa ao design da próxima geração da camada básica, especialmente no mecanismo ZK.

Camada Básica

Hoje, a maioria dos rollups emprega sequenciadores centralizados para classificar e executar transações. Uma vez que o sequenciador gera um bloco, ele também é responsável por gerar uma prova de execução para outros verificarem. Para que a execução seja verificável, o terceiro precisa dos dados de estado do rollup, bem como da prova de execução. Os dados de estado e os atestados são normalmente publicados na camada de Disponibilidade de Dados (DA) e as transições de estado são verificadas pela camada de validação (muitas vezes erroneamente chamada de camada de liquidação).

Nos primeiros dias, a Ethereum estabeleceu um roteiro centrado no rollup e tornou-se a camada base original, ao mesmo tempo em que executa DA e verificação. O estado exclusivo da Ethereum (ou seja, a grande quantidade de ativos valiosos emitidos na Ethereum) a torna uma camada de liquidação natural para o rollup. Ao utilizar a Ethereum como base, o rollup não só pode herdar a sua segurança, mas também a sua liquidez. De qualquer forma, naquela época, não havia opções especializadas de liquidação ou DA no mercado.

Mesmo num mundo com muitas camadas especializadas, ter a maior coleção de validadores PoS e suporte a blob do Ethereum como uma camada DA é uma escolha muito segura. Além disso, o número de ativos na família Ethereum e a capitalização de mercado têm continuado a subir. Como a liquidação é específica para ativos, a validação na cadeia é necessária para a emissão de ativos que permitam saídas forçadas em rollup. Se um rollup desejar permitir saídas forçadas de ativos emitidos pelo Ethereum, ele deve validar na cadeia do Ethereum.

O Ethereum de hoje parece assim:

No entanto, as camadas DA especializadas e a camada de Liquidação também estão competindo diretamente com a Ethereum para executar essas operações. Por exemplo, Celestia e EigenDA já oferecem uma capacidade de processamento DA significativamente maior (embora com modelos de segurança diferentes). Da mesma forma, Initia está expandindo o conceito de verificação ou centro de Liquidação, oferecendo uma experiência unificada de Carteira, Máquina Oracle e interoperabilidade integrada para proporcionar uma experiência mais perfeita aos usuários do ecossistema (o que também se tornou um ponto importante na rota da Ethereum nos últimos meses).

Todos esses sistemas seguem a mesma forma que o Ethereum (ETH), onde a camada base é dividida em disponibilidade de dados e validação, e cada camada atua como um hub especializado para suas respectivas operações:

A nova visão chave do projeto reside na otimização separada necessária da camada DA e da camada de verificação. O objetivo original do blockchain é alcançar a Descentralização de terceiros confiáveis entre duas partes não confiáveis. Em um sistema centrado no rollup, a função da camada base é atuar como um terceiro confiável Descentralização entre os rollups para garantir a interoperabilidade entre eles. Uma vez que a camada base valida o estado do rollup, todos os outros rollups podem confiar implicitamente na camada base. Outra propriedade central do design centrado no rollup é que ele permite que os aplicativos forneçam acesso rápido e barato à confirmação de transações para os usuários em cenários médios (através de um classificador centralizado em certa medida), sem comprometer a resistência à revisão final no pior cenário (através da saída forçada da camada base).

Dado o nosso entendimento da separação entre a disponibilidade de dados e a verificação, bem como a funcionalidade central da interoperabilidade entre a resistência final e a emissão de ativos entre as camadas base e o Rollup, podemos inferir como construir uma camada base melhor. Atualmente, o Rollup publica os dados de estado na camada base a cada poucas horas, o que significa que as pré-confirmações fornecidas pelo ordenador do Rollup são finalizadas na camada base apenas dentro desse intervalo de tempo. A capacidade de processamento de dados na camada base é maior do que a do L1 da Ethereum, o que permite ao Rollup publicar dados com mais frequência, reduzindo o tempo entre a pré-confirmação do Rollup e a confirmação na camada base, aumentando assim a segurança do Rollup. Da mesma forma, a verificação em maior velocidade pode permitir uma interoperabilidade mais rápida entre os Rollups, sem a necessidade de pontes de liquidez e criadores de mercado. Podemos usar insights específicos sobre a forma como a carga de trabalho que a camada base deve lidar para construir uma camada base com maior capacidade de processamento e comunicação mais rápida entre os Rollups.

A integração da cadeia de blocos Bloco possui uma área de 'estado quente', como as pools DEX que são frequentemente alvo de ataques. Isso torna a ordem relativa das transações de todos os participantes muito importante. Por outro lado, o rollup geralmente opera em um espaço de estado amplamente independente, onde a maioria das transações afeta apenas o estado interno do próprio rollup. Embora as interações entre rollups ocorram (por exemplo, quando os usuários transferem ativos entre rollups ou combinam rollups), essas interações são explícitas, bem definidas e conhecidas antecipadamente. Como a maioria das transações em cada rollup é executada em um estado desconectado e as transações entre rollups são tratadas por meio de mecanismos específicos de interoperabilidade, a necessidade de uma rigorosa ordenação global de todos os dados do rollup na camada base é menor. Em vez disso, a ordenação pode ser realizada seletivamente apenas quando houver interações explícitas entre rollups:

Dois Rollups publicam uma lista de diferenças de estado para a camada base e sua prova de ZK para a transição de estado.

注意：Assumimos que Rollup publica uma lista de diferenças de estado aqui e a prova de ZK de sua transição de estado Rollup.

As principais ideias aqui giram em torno das relações de causa e efeito entre as transações e suportam um trabalho extenso em torno do modelo de Consenso de Gráfico Acíclico Direcionado (DAG). Em geral, o Algoritmo DAG tenta determinar claramente as dependências para permitir cálculos/processamentos paralelos. Com base nessas ideias, esperamos que uma camada base de rollup surja, onde o Consenso é relaxado em grande parte para suportar maior throughput e menor latência.

A divisão natural do estado Rollup indica que impor uma ordem total em todas as transações Rollup pode ser um custo desnecessário. Sistemas como delta e Hylé aproveitam essa visão, permitindo que o Rollup opere de forma independente, coordenando apenas a transferência de ativos entre domínios. No entanto, isso não elimina completamente o Consenso; é uma melhoria em relação aos lugares onde o Consenso é realmente necessário. A inovação está em reconhecer que essa ordenação pode ser limitada aos locais onde é realmente necessário, em vez de ser aplicada globalmente a todas as transações.

O impacto máximo dessa partição é criar uma solução de Rollup elegante para aumentar a taxa de transferência do ambiente de execução especializado sem comprometer a composabilidade com outros Rollups.

Ordem de Causa e Efeito e Ordem Total

Antes de prosseguirmos, vamos revisar a classificação. Em termos gerais, o Consenso é o consenso de todos Nó na rede sobre a classificação das transações válidas:

• A cadeia de Bloco linear deve chegar a um consenso sobre a ordem total das transações, ou seja, a ordem linear completa dos eventos, à vista de todos os nós participantes. As transações não relacionadas entre si ainda serão colocadas em ordem global.
• Por outro lado, a ordenação causal apenas ordena as transações, ou seja, as transações que ocorrem primeiro são classificadas antes das transações que dependem de suas saídas. As transações sem relação de causa e efeito não precisam ser classificadas entre si. Isso também é conhecido como parcialidade. DAG é apenas uma estrutura de dados que implementa parcialidade em um conjunto de transações. A parcialidade também abre as portas para a execução de transações paralelas entre partes não intersecionadas do DAG. Aqui, não há uma única ordenação global de transações que todos os Nó concordem.

A ordem total pode ser estabelecida em cima do DAG. Isso requer um Mecanismo de consenso adicional para chegar a um consenso sobre a ordem de eventos concorrentes. Um exemplo disso é a evolução mais recente do protocolo Narwhal And Tusk ou Mysticeti do SUI.

As transações dentro do DAG podem ser confirmadas independentemente de outras transações não relacionadas. Uma vez que uma transação é reconhecida pela maioria dos validadores, ela é considerada válida. Permitir a confirmação de transações individualmente, em vez de dentro de um bloco, pode aumentar significativamente a capacidade de processamento de transações, pois muitas transações podem ser propostas e confirmadas em paralelo. Isso pode ser considerado uma generalização do consenso do líder único, onde qualquer validador pode propor novas transações (Nota: isso também pode ser considerado a proposição de um bloco que contém uma única transação).

Resumindo o princípio de funcionamento da verificação de transações em DAG:

• O usuário dá um subconjunto de Difusão de transacções para o nó validador Nó.
• Quando um Nó recebe uma transação, ele primeiro verifica se a transação está em conflito com qualquer transação que ele conhece atualmente, com base na visão local do gráfico.
• Se houver um conflito, como tentar gastar os mesmos fundos, a transação será rejeitada.
• Se não houver conflitos, o Nó receptor interage com outros Nós na rede para chegar a algum tipo de consenso sobre a validade da transação. Um método é subamostragem, no qual o Nó inicia algumas rodadas de consultas, questionando um subconjunto de outros Nós se consideram a transação válida com base em seus próprios pontos de vista locais. Se a resposta afirmativa atingir o limiar de amostragem de Nós, a rodada de consulta é considerada bem-sucedida e representa a aprovação legal. Repita esse processo de amostragem até que o Nó tenha confiança na validade da transação. Esse processo permite que o Nó alcance rapidamente um consenso sobre a validade da transação, sem a necessidade de um consenso global. A amostragem repetida ajuda a garantir que toda a rede alcance um consenso, tornando altamente improvável que transações conflitantes sejam aceitas simultaneamente.

Realizar subamostragem de verificação de transações

Precisa-se salientar que, a qualquer momento, qualquer Nó pode executar este processo interativo para alcançar um número legal, permitindo várias vias para alcançar o Consenso. Em certo sentido, cada validador ou réplica executa sua própria blockchain e sincroniza regularmente com outros Nós. A ideia de avançar vários blockchains diferentes antes da coordenação também foi explorada em designs não DAG, como o Autobahn (ainda dependente da separação entre propagação e ordenação de dados). No Autobahn, cada validador mantém seu próprio canal de transações e depois coordena durante o processo de sincronização. Embora neste documento não os chamemos explicitamente de blockchains, consideramos que os canais são muito semelhantes às blockchains e o processo de sincronização é semelhante à fusão de várias blockchains.

Relações de causa e efeito na camada básica

Agora, agora que entendemos o conceito de causalidade, podemos tentar entender como o conceito se relaciona com a camada fundacional. Como mencionado anteriormente, os pacotes cumulativos normalmente publicam dados de estado ou listas de comparação de estado que correspondem a atualizações de estado em seu próprio estado de partição persistente. Os dados publicados pelos dois rollups não são controversos para algum "estado quente" porque os dados não se cruzam entre si. Isso relaxa a necessidade de ordenação global na camada base. Além disso, para verificar o novo estado de rollup, basta verificar o estado de rollup publicado anteriormente. Como resultado, a camada base é livre para classificar essas transações de rollup, permitindo que elas prossigam independentemente umas das outras sem ter que esperar pelo pedido global:

De forma mais ampla, o rollup deve poder publicar dados e provas na camada base livremente, sem se preocupar com custos. À medida que os dados se propagam pela rede, os validadores da camada base verificarão as provas publicadas pelo ordenador rollup. Se um número específico de validadores verificar a prova, assume-se que a transação foi confirmada. Esse sistema permitirá que o rollup alcance a confirmação à velocidade com que os dados se propagam pela camada base. Teoricamente, isso também deverá reduzir o tempo entre a pré-confirmação do ordenador e a confirmação da camada base.

O sistema acima depende da Fragmentação baseada em ZK em vez da execução de cópia como o futuro de aplicativos verificáveis.

As transações inter-shard que movem dados entre dois rollups exigem ordenação, mas isso é apenas parte do processo. Por exemplo, para transferir o ativo X do rollup A para o rollup B, as transações de retirada do rollup A precisam atingir o quórum e, somente então, o rollup B pode incluir as transações de depósito. A confirmação rápida da camada base garantirá a interoperabilidade confiável entre os rollups dentro do mesmo ecossistema, criando efeitos de rede para a camada base. A interoperabilidade rápida, juntamente com muitos ativos valiosos, pode ser suficiente para tornar a camada base atraente para potenciais rollups. Em resumo, esse design específico permitirá:

• O tempo de confirmação das transações Rollup é rápido.
• Interoperabilidade rápida entre rollups (sem a necessidade de pontes de liquidez ou criadores de mercado).
• Taxa de transferência DA dedicada para Rollup.
• Ferramenta de validação exclusiva para Rollup (mais sistemas de prova).

Breve explicação: Acumulação de valor do ativo subjacente

A discussão acima fornece uma camada base barata, rápida e segura para o rollup. No entanto, grande parte da discussão em torno da rota centrada no rollup atualmente gira em torno do valor acumulado do ETH e da Ethereum abaixo da existência do rollup. Os L2 com relações de usuário, como o Base, podem cobrar um prêmio em seu espaço de bloco e apenas devolver uma pequena porção de sua receita em taxas de DA ao Ethereum.

Ao permitir que o rollup publique dados de estado com mais frequência para alcançar maior interoperabilidade, a camada básica pode obter parte da receita que seria perdida para os provedores de liquidez e pontes de Liquidez. Embora o valor que os sistemas de maior interoperabilidade trazem para a camada básica dependa inteiramente do número de rollups que precisam se comunicar entre si. Em ambientes em que o rollup não atende aos requisitos de várias aplicações, o valor acumulado da camada básica torna-se mais evidente. As aplicações podem interagir usando apenas a camada básica para alcançar a composabilidade. As aplicações podem obter alta taxa de transferência e controle sobre seu próprio espaço sem sacrificar a composabilidade.

Ainda há argumentos que afirmam que melhorar a execução da camada base aumentará a acumulação de valor do Token nativo. Isso, na verdade, permite que a camada base concorra com rollup, o que vai contra o princípio de design centrado em rollup. Outra abordagem para a execução (talvez até a nossa preferida) é construir um rollup consagrado, onde os ativos da camada base são protegidos reestacando o organizador rollup. Se necessário, até mesmo o conjunto de validadores da camada base pode atuar como o conjunto de organizadores do rollup (embora não precise ser o mesmo). Na verdade, após a palestra de Martin Köppelmann na Devcon 2024, o tema de rollup consagrado ou nativo começou a esquentar. Para ecossistemas como o Ethereum, isso permitirá que o ETH recupere parte do valor perdido, ao mesmo tempo que permitirá que os desenvolvedores experimentem mais livremente no rollup, já que o stake do rollup pode ser muito menor do que o do Layer-1 do Ethereum.

Conclusão

Em geral, acreditamos que a era do ZK representa um futuro emocionante e visionário para o Ethereum e para toda a blockchain. Neste artigo, esboçamos como a combinação avançada do Consenso com ZK representa uma nova direção potencial para a camada base em sistemas centrados em rollup. Ao combinar a prova de conhecimento zero com ideias emprestadas do Mecanismo de consenso baseado em DAG, podemos repensar a camada base otimizada para rollup. O Consenso é aplicado apenas onde o estado compartilhado real está em jogo, em vez de ser um requisito unificado para todas as operações. À medida que o ecossistema continua a evoluir em direção a um design modular, esperamos que este método mais refinado de Consenso na camada base se torne o padrão da blockchain modular.

Em termos gerais, consideramos que, dado que várias novas tecnologias de suporte acabaram de entrar em produção, a camada básica deve adotar essa tecnologia para manter a competitividade.

Não devemos ter medo de ter sonhos maiores.