Ethereum é um computador mundial sem permissão que possui (sem dúvida) a maior quantidade de segurança econômica no momento em que este artigo foi escrito, atuando como o livro-razão de liquidação para um vasto número de ativos, aplicações e serviços. Ethereum tem suas limitações – o espaço de bloco é um recurso escasso e caro na camada um do Ethereum (L1). O escalonamento da camada dois (L2) tem sido visto como a solução para esse problema, com vários projetos chegando ao mercado nos últimos anos, principalmente na forma de rollups. No entanto, rollups, no sentido estrito do termo (o que significa que os dados de rollup estão no Ethereum L1), não permitem que o Ethereum seja escalonado indefinidamente, permitindo apenas alguns milhares de transações por segundo.

Confiança minimizada – (uma característica de) um sistema L2 é minimizado pela confiança se funcionar sem exigir confiança externa à base L1.

Escalabilidade horizontal – um sistema é escalável horizontalmente se instâncias puderem ser adicionadas sem impor gargalos globais.

Neste artigo, argumentamos que sistemas com confiança minimizada e escalonáveis horizontalmente são a forma mais promissora de escalar aplicações blockchain, embora sejam atualmente subexplorados. Apresentamos o argumento explorando três questões:

1. Por que os aplicativos deveriam ser minimizados em termos de confiança?
2. Por que construir sistemas que sejam escaláveis horizontalmente?
3. Como podemos maximizar a minimização da confiança e a escalabilidade horizontal?

(Isenção de responsabilidade: embora nos concentremos no Ethereum como base L1 neste artigo, a maior parte do que discutimos aqui se aplica a camadas de liquidação descentralizadas além do Ethereum.)

Por que os aplicativos deveriam ser minimizados em termos de confiança?

Os aplicativos podem ser conectados ao Ethereum de maneira confiável – eles podem escrever e ler no blockchain Ethereum, mas a confiança é depositada nos operadores para executar a lógica de negócios corretamente. Exchanges centralizadas como Binance e Coinbase são ótimos exemplos de aplicações confiáveis. Estar conectado ao Ethereum significa que os aplicativos podem acessar uma rede global de liquidação com um conjunto diversificado de ativos.

Existem riscos significativos associados a serviços fora da cadeia confiáveis. O colapso das principais bolsas e serviços em 2022, como FTX e Celsius, é um grande alerta sobre o que acontece quando serviços confiáveis se comportam mal e falham.

Por outro lado, aplicações com confiança minimizada podem escrever e ler no Ethereum de forma verificável. Os exemplos incluem aplicativos de contratos inteligentes, como Uniswap, rollups, como Arbitrum ou zkSync, e coprocessadores, como Lagrange e Axiom. Em termos gerais, a confiança é removida à medida que as aplicações são protegidas pela rede Ethereum, à medida que mais funcionalidades (veja abaixo) são terceirizadas para L1. Como resultado, os serviços financeiros com confiança minimizada podem ser oferecidos sem riscos de contraparte ou de custódia.

Existem três propriedades principais que os aplicativos e serviços podem ter, que podem ser terceirizados para L1:

1. Vivência (e ordenação): as transações enviadas pelo usuário devem ser incluídas (executadas e liquidadas) em tempo hábil.
2. Validade: as transações são processadas de acordo com regras pré-especificadas.
3. Disponibilidade de dados (e estado): os dados históricos, bem como o estado atual do aplicativo, são disponibilizados ao usuário.

Para cada uma das propriedades acima, podemos pensar qual é a suposição de confiança necessária; em particular, o Eth L1 fornece a propriedade ou é necessária confiança externa. A tabela abaixo categoriza isso para diferentes paradigmas de arquitetura.

Por que construir sistemas que sejam escaláveis horizontalmente?

A escala horizontal refere-se à escala através da adição de instâncias independentes ou paralelas de um sistema, por exemplo aplicativo ou rollup. Isto não requer a presença de gargalos globais. A escala horizontal permite e facilita o crescimento exponencial.

O escalonamento vertical refere-se ao escalonamento por meio do aumento da taxa de transferência de um sistema monolítico, como Eth L1 ou uma camada de disponibilidade de dados. Quando o escalonamento horizontal encontra gargalos em um recurso compartilhado, o escalonamento vertical geralmente é necessário.

Alegação 1: Os rollups (dados de transação) não podem ser dimensionados horizontalmente porque podem ser prejudicados pela disponibilidade de dados (DA). As soluções de DA com escala vertical exigem compromissos na descentralização.

A disponibilidade de dados (DA) continua sendo o gargalo para rollups. Atualmente, cada bloco L1 tem um tamanho máximo de aproximadamente 1 MB (85 KB/s). Com EIP-4844, serão disponibilizados ~2 MB (171 KB/s) adicionais (no longo prazo). Com Danksharding, Eth L1 pode eventualmente suportar até 1,3 MB/s de largura de banda DA. Eth L1 DA é um recurso compartilhado pelo qual muitos aplicativos e serviços competem. Portanto, embora o uso de L1 para DA forneça a melhor segurança, ele dificulta a escalabilidade potencial de tais sistemas. Os sistemas que utilizam L1 para DA (normalmente) não serão capazes de escalar horizontalmente e terão deseconomias de escala. Camadas DA alternativas, como Celestia ou EigenDA, também têm limites de largura de banda (embora maiores, de 6,67 MB/s e 15 MB/s, respectivamente). Mas isso acontece às custas da mudança do pressuposto de confiança do Ethereum para outra rede (muitas vezes menos descentralizada), comprometendo a segurança (económica).

Alegação 2: A única maneira de escalar horizontalmente serviços com confiança minimizada é obter (próximo de) zero dados L1 marginais por transação. As duas abordagens conhecidas são rollups de diferenças de estado (SDR) e validiums.

Rollups de diferenças de estado (SDRs) são rollups que publicam diferenças de estado em um lote agregado de transações para Ethereum L1. Para o EVM, à medida que os lotes de transações crescem, os dados por transação postados em L1 diminuem para uma constante que é muito menor que a dos rollups de dados de transação.

Por exemplo, durante o evento de teste de estresse de alta inundação de inscrições, o zkSync viu uma redução de dados de chamada por transação para até 10 bytes por transação. Por outro lado, rollups de dados de transação como Arbitrum, Optimism e Polygon zkEVM normalmente veem cerca de 100 bytes por transação para tráfego normal.

Um validium é um sistema que publica provas de validade de transições de estado para Ethereum, sem dados de transação ou estado associados. Validiums são altamente escaláveis horizontalmente, mesmo em condições de baixo tráfego. Isto é especialmente verdade porque a liquidação de diferentes validiums pode ser agregada.

Além da escalabilidade horizontal, um validium também pode fornecer privacidade na cadeia (de observadores públicos). Um validium com DA privado centralizou e bloqueou a disponibilidade de dados e de estado, o que significa que os usuários precisam se autenticar antes de acessar os dados e que o operador pode aplicar boas medidas de privacidade. Isto permite um nível de experiência do utilizador semelhante ao da Internet tradicional ou dos serviços financeiros – as atividades dos utilizadores ficam ocultas do escrutínio público, mas existe um guardião confiável dos dados do utilizador, neste caso o operador validium.

E quanto aos sequenciadores centralizados versus descentralizados? Para manter os sistemas escaláveis horizontalmente, é crucial instanciar sequenciadores independentes, sejam centralizados ou descentralizados. Notavelmente, embora os sistemas que usam sequenciadores compartilhados desfrutem de capacidade de composição atômica , eles não podem ser dimensionados horizontalmente, pois o sequenciador pode se tornar um gargalo à medida que mais sistemas são adicionados.

E quanto à interoperabilidade? Os sistemas escaláveis horizontalmente podem interoperar sem confiança adicional se todos se estabelecerem na mesma L1, uma vez que as mensagens podem ser enviadas de um sistema para outro através da camada de liquidação partilhada. Há uma compensação entre o custo operacional e o atraso nas mensagens (que pode ser potencialmente resolvido na camada de aplicação).

Minimização da confiança para sistemas escaláveis horizontalmente

Podemos minimizar ainda mais os requisitos de confiança para atividade, ordenação e disponibilidade de dados em sistemas horizontalmente escaláveis?

É digno de nota que, ao custo da escalabilidade horizontal, sabemos como salvar a vivacidade e a disponibilidade de dados sem confiança. Por exemplo, as transações L2 podem ser iniciadas a partir do L1 para inclusão garantida. A Volition pode oferecer disponibilidade de estado L1 opcional para os usuários.

Outra solução é simplesmente descentralizar (mas não confiar no L1). Em vez de um único sequenciador, os sistemas poderiam tornar-se mais descentralizados utilizando sequenciadores descentralizados (como Espresso Systems ou Astria), minimizando assim a confiança necessária para a vivacidade, ordenação e disponibilidade de dados. Fazer isso impõe limitações em comparação com soluções de operador único: (1) o desempenho pode ser limitado pelo desempenho do sistema distribuído e (2) para validiums com DA privado, a garantia de privacidade padrão é perdida se a rede sequenciadora descentralizada não tiver permissão.

Quanta confiança podemos minimizar adicionalmente para validiums ou SDRs de operador único? Existem algumas direções abertas aqui.

Direção aberta 1: Disponibilidade de dados com confiança minimizada em validiums. O Plasma resolve o problema de disponibilidade de estado até certo ponto – ele resolve o problema tanto para retiradas apenas para determinados modelos de estado (que inclui o modelo de estado UTXO), quanto exige que os usuários estejam online periodicamente (Plasma Free).

Direção aberta 2: Pré-confirmações responsáveis em SDRs e validiums. O objetivo aqui é fornecer aos usuários uma pré-confirmação rápida da inclusão da transação de um sequenciador, e a confirmação deve permitir ao usuário desafiar e reduzir o interesse econômico do sequenciador se a promessa de inclusão não for cumprida. O desafio aqui é que provar a não inclusão (necessária para a redução) provavelmente requer dados adicionais para o usuário, que um sequenciador pode simplesmente reter. Portanto, é razoável supor que pelo menos exigimos que o SDR ou o Validium empreguem um comitê de disponibilidade de dados (potencialmente autorizado) para seus dados de chamada completos ou histórico de transações, o que permite que o mesmo comitê forneça prova de não inclusão (de pré- transações confirmadas) mediante solicitação do usuário.

Direção aberta 3: Recuperação rápida de falhas de atividade. Sistemas de operador único podem sofrer falhas de atividade (por exemplo Arbitrum ficou offline durante o evento de inscrição). Podemos projetar sistemas que proporcionem interrupção mínima de serviço neste cenário? Em certo sentido, os L2s que permitem a auto-sequência e as propostas de estado fornecem garantias contra falhas prolongadas de vivacidade. O projeto de sistemas de operador único que sejam mais resilientes contra falhas de vida mais curtas é atualmente pouco explorado. Uma solução potencial aqui é responsabilizar as falhas de atividade, fornecendo cortes contra as falhas de atividade. Outra solução potencial é simplesmente encurtar o período de atraso (que atualmente está definido em cerca de uma semana) antes que uma aquisição possa acontecer.

Conclusão

Dimensionar um livro-razão de liquidação global e ao mesmo tempo manter a minimização da confiança é um problema difícil. Não tem havido uma distinção clara entre o escalonamento vertical e o escalonamento horizontal no mundo atual de rollup e disponibilidade de dados. Para realmente dimensionar sistemas com confiança minimizada para todos no planeta, precisamos construir sistemas com confiança minimizada e escaláveis horizontalmente.

Reconhecimentos

Muito obrigado a Vitalik Buterin e Terry Chung pelo feedback e discussão, bem como a Diana Biggs pelos seus comentários editoriais.

声明:

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [Mirror]. Todos os direitos autorais pertencem ao autor original [1kx]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos 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 do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.