Sobre Minimização de Confiança e Escalonamento Horizontal

O Ethereum é um computador mundial sem permissão que possui (indiscutivelmente) 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 de um vasto número de ativos, aplicações e serviços. O Ethereum tem as suas limitações — o blockspace é um recurso escasso e caro na camada um do Ethereum (L1). A escalabilidade da camada dois (L2) tem sido vista como a solução para este problema, com inúmeros projetos a chegar ao mercado nos últimos anos, principalmente sob a forma de rollups. No entanto, os 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 escale indefinidamente, permitindo apenas alguns milhares de transações por segundo.

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

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

Neste artigo, argumentamos que os sistemas minimizados pela confiança e horizontalmente escaláveis são a maneira mais promissora de escalar aplicações blockchain, mas estão atualmente subexplorados. Apresentamos o argumento explorando três questões:

1. Porque é que as candidaturas devem ser minimizadas pela confiança?
2. Porquê construir sistemas 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 a base L1 neste artigo, a maior parte do que discutimos aqui se aplica a camadas de liquidação descentralizadas além do Ethereum.)

Porque é que as candidaturas devem ser minimizadas pela confiança?

As aplicações podem ser ligadas ao Ethereum de uma forma fidedigna — podem escrever e ler a partir da cadeia de blocos Ethereum mas é colocada confiança nos operadores para executar a lógica empresarial corretamente. Trocas centralizadas como a Binance e a Coinbase são ótimos exemplos de aplicações fidedignas. Estar ligado ao Ethereum significa que as aplicações podem aceder a uma rede de liquidação global com um conjunto diversificado de ativos.

Existem riscos significativos associados a serviços fora da cadeia de confiança. O colapso das principais bolsas e serviços em 2022, como FTX e Celsius, é um grande conto de advertência do que acontece quando os serviços confiáveis se comportam mal e falham.

Por outro lado, as aplicações minimizadas pela confiança podem escrever e ler a partir do Ethereum de forma verificável. Os exemplos incluem aplicações 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 o L1. Como resultado, os serviços financeiros minimizados pela confiança podem ser oferecidos sem riscos de contraparte ou custodiante.

Existem três propriedades principais que as aplicações e serviços podem ter, que podem ser terceirizadas para L1:

1. Vida (e ordenação): as transações enviadas pelo utilizador devem ser incluídas (executadas e liquidadas) atempadamente.
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 da aplicação, são disponibilizados ao utilizador.

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

Porquê construir sistemas escaláveis horizontalmente?

A escala horizontal refere-se ao escalonamento através da adição de instâncias independentes ou paralelas de um sistema, por ex. aplicação ou rollup. Isto não requer nenhum gargalo global para estar presente. A escala horizontal permite e facilita o crescimento exponencial.

A escala vertical refere-se ao escalonamento através do aumento da taxa de transferência de um sistema monolítico, como Eth L1 ou uma camada de disponibilidade de dados. Quando a escala horizontal se depara com gargalos num recurso tão partilhado, muitas vezes é necessária uma escala vertical.

Reivindicação 1: Os rollups (dados da transação) não podem ser dimensionados horizontalmente porque podem ser estrangulados pela disponibilidade de dados (DA). As soluções de DA para escalonar verticalmente exigem compromissos na descentralização.

A disponibilidade de dados (DA) continua a ser o gargalo para os rollups. Atualmente, cada bloco L1 tem um tamanho alvo máximo de ~1 MB (85 Kb/s). Com o EIP-4844, haverá mais ~2 MB (171 Kb/s) disponibilizados (a longo prazo). Com o Danksharding, o Eth L1 poderá eventualmente suportar até 1,3 MB/s de largura de banda DA. O Eth L1 DA é um recurso partilhado pelo qual muitas aplicações & dos serviços competem. Portanto, embora a utilização de L1 para DA forneça a melhor segurança, estrangula-se a escalabilidade potencial de tais sistemas. Os sistemas que utilizam L1 para DA (normalmente) não serão capazes de escalar horizontalmente e ter deseconomias de escala. Camadas alternativas DA, como Celestia ou eIGenda, também têm limites de largura de banda (embora maiores, a 6,67 MB/s e 15 MB/s, respectivamente). Mas vem à custa de mudar a suposição de confiança do Ethereum para outra rede (muitas vezes menos descentralizada), comprometendo a segurança (económica).

Reivindicação 2: A única maneira de escalar horizontalmente os serviços minimizados pela confiança é obter (perto de) zero dados L1 marginais por transação. As duas abordagens conhecidas são os rollups de diferença de estado (SDR) e os validiums.

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

Por exemplo, durante o evento de teste de stress de alta inundação de inscrições, o ZKSync viu uma redução dos dados de chamada por transação até 10 bytes por transação. Em contraste, os rollups de dados de transação como Arbitrum, Otimismo e Polygon ZkeVM, normalmente veem cerca de 100 bytes por transação para o tráfego normal.

Um validium é um sistema que posta provas de validade das transições de estado para o Ethereum, sem dados de transação ou estado associados. Os Validiums são altamente escaláveis horizontalmente, mesmo em condições de tráfego reduzido. Isto é especialmente verdadeiro porque a liquidação de diferentes valídios pode ser agregada.

Além da escalabilidade horizontal, um validium também pode fornecer privacidade na cadeia (de observadores públicos). Um valídio com DA privado tem dados centralizados e fechados e disponibilidade de estado, o que significa que os utilizadores têm de se autenticar antes de aceder aos dados e que o operador pode impor boas medidas de privacidade. Isto permite um nível de experiência do utilizador semelhante aos serviços tradicionais da web ou financeiros — as atividades do utilizador estão ocultas do escrutínio público mas há um guardião confiável dos dados do utilizador, neste caso o operador validium.

E os sequenciadores centralizados vs descentralizados? Para manter os sistemas escaláveis horizontalmente, é crucial instanciar sequenciadores independentes, centralizados ou descentralizados. Notavelmente, embora os sistemas que utilizam sequenciadores partilhados desfrutem de composição atómica < a href= " https://hackmd.io/@EspressoSystems/SharedSequencing " >, não podem escalar horizontalmente, pois o sequenciador pode tornar-se um gargalo à medida que mais sistemas são adicionados.

E a interoperabilidade? Os sistemas escaláveis horizontalmente podem interoperar sem confiança adicional se todos se estabelecerem no mesmo L1, pois 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 potencialmente ser 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 a agilidade, pedidos e disponibilidade de dados em sistemas escaláveis horizontalmente?

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

Outra solução é simplesmente descentralizar (mas não depender do L1). Em vez de um único sequenciador, os sistemas podem tornar-se mais descentralizados utilizando sequenciadores descentralizados (como Espresso Systems ou Astria), minimizando assim a confiança necessária para a vida, a encomenda e a disponibilidade de dados. Fazer isso coloca 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 de operador único ou SDRs? Há algumas direções abertas aqui.

Direção aberta 1: Disponibilidade de dados minimizada pela confiança nos validiums. OPlasma resolve o problema de disponibilidade do estado até certo ponto — resolve o problema quer para levantamentos apenas para determinados modelos de estado (que inclui o modelo de estado UTXO), ou exige que os utilizadores estejam online periodicamente (Plasma Free).

Direção aberta 2: Pré-confirmações responsáveis em SDRs e validiums. O objetivo aqui é fornecer aos utilizadores uma pré-confirmação rápida da inclusão da transação a partir de um sequenciador, e a confirmação deve permitir ao utilizador desafiar e cortar a participação económica 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 cortar) provavelmente requer dados adicionais para o utilizador, que um sequenciador pode simplesmente reter. Portanto, é razoável supor que exigimos pelo menos que o SDR ou o validium empregue um comité de disponibilidade de dados (potencialmente permissível) para os seus dados de chamada completos ou histórico de transações, o que permite ao mesmo comité fornecer prova de não inclusão (de transações pré-confirmadas) mediante pedido do utilizador.

Open direction 3: Recuperação rápida de falhas de vida. Os sistemas de operador único podem sofrer falhas de vida (ex. O Arbitrum ficou offline durante o evento de inscrição). Podemos conceber sistemas que proporcionem uma interrupção mínima do serviço neste cenário? Em certo sentido, os L2s que permitem a auto-sequência e as propostas estaduais fornecem garantias contra falhas de vida prolongadas. Projetar 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 vida, fornecendo cortes contra falhas de vida. Outra solução potencial é simplesmente encurtar o período de atraso (que atualmente está definido para ser de cerca de uma semana) antes que uma aquisição possa acontecer.

Conclusão

Dimensionar um livro-razão global de liquidação enquanto mantém a minimização da confiança é um problema difícil. Não houve uma distinção clara entre escalabilidade vertical e escala horizontal no mundo do rollup e da disponibilidade de dados hoje. Para realmente dimensionar sistemas de confiança minimizada para todos na Terra, precisamos construir sistemas minimizados pela confiança e escaláveis horizontalmente.

Agradecimentos

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 do [Espelho]. Todos os direitos de autor pertencem ao autor original [1kx]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.