原文：Fragmentação de dados de segurança variável —— polynya

Tradutor: Evelyn｜W3.Hitchhiker

Isenção de responsabilidade: tudo aqui é pensamento puramente especulativo, há muitas simplificações exageradas, nada disso deve ser levado a sério, só espero que haja algum motivo para reflexão.

A bela ideia do Danksharding é esta: apenas o construtor (que de qualquer maneira é uma suposição de uma minoria honesta) precisará executar o hardware caro. Com o tempo, os rollups chegam a milhões de TPS com um custo mínimo para validadores, usuários e todos os demais. O problema é que esta visão ambiciosa levará tempo para ser comprovada. Pode levar de 2 a 5 anos, dependendo de quem eu perguntar, é claro. Embora o espaço criptográfico sempre tenha sofrido com a falácia extrema do planejamento, as coisas estão definitivamente melhorando, mas me recuso a confiar em qualquer roteiro até que possa ver o surgimento de um protótipo totalmente funcional.

EIP-4844 é uma grande melhoria e acredito que será mais do que suficiente para todos os aplicativos e transações valiosas que exigem alta segurança no futuro próximo, e permite que os rollups se expandam 100x na atividade atual, ~ 1.000 vezes. No entanto, haverá diferentes categorias de aplicações que consomem muitos dados e que poderão exigir “milhões de TPS” sem exigir alta segurança.

Ao mesmo tempo, está claro que os desenvolvedores não pretendem esperar pelo danksharding completo. Hoje, dos 15 principais projetos da L2Beat, 7 não são rollups, mas validiums e cadeias otimistas que usam camadas externas de disponibilidade de dados. (Aqui, presumo que você esteja familiarizado com essas estruturas e saiba por que elas ainda são melhores que as cadeias laterais, etc.) StarkEx (6 validiums agora!), Arbitrum e Metis já possuem camadas externas de disponibilidade de dados, enquanto StarkNet, zkSync, Polygon e outras empresas têm; construindo camadas internas de disponibilidade de dados, sem mencionar empresas como EigenDA ou Celestia. Essas soluções híbridas não exigem nem o EIP-4844 nem o danksharding completo para manter baixas as taxas de transação e, o que é crucial, elas já estão aqui.

Uma maneira é deixá-los fazer o que querem e os usuários escolherão a opção validium menos segura se precisarem (mas ainda superior a alt-L1s). A mágica do Volitions é que os usuários podem escolher por transação ou por usuário.

Mas outra abordagem é: como podemos melhorar a camada externa de disponibilidade de dados?

Embora esta esteja longe de ser uma amostra representativa, 20% dos validadores Ethereum hoje excedem a faixa típica. Enquanto isso, 45% preferem ter requisitos de largura de banda/tráfego muito conservadores. Com o EIP-4844, estamos otimizando esses 45%, mas os 55% restantes continuarão a funcionar com largura de banda subutilizada. Portanto, a ideia é utilizar essa largura de banda livre adicionando fragmentação simples de dados, onde o conjunto de validadores será dividido. Não sei nada sobre engenharia, mas acredito na palavra de Dankrad de que isso é "trivial".

Com o EIP-4844, temos uma nova camada de disponibilidade de dados. Eu chamo isso de fragmento de dados número 0 (DS0). DS0 é obrigatório e garantido pelo conjunto completo de validadores Ethereum.

Aqui podemos ter mais fragmentos de dados (S1, DS2...etc.) que podem ser aceitos pelos validadores. Portanto, 30% do campo acima de 2 TB a 10 TB pode executar 2 ou 3 fragmentos de dados. Portanto, enquanto o DS0 é garantido por 100% do conjunto de validadores Ethereum, o DS1 é 55%, o DS2 é 50% e assim por diante. Agora que temos aqueles validadores hiper-especificados em execução (que aparentemente pensaram erroneamente que eram validadores Solana) que se sentem confortáveis ​​com tráfego de 20 TB ou mais ou largura de banda de 100 Mbps ou mais, esses 20% também são capazes de executar mais fragmentos. Portanto, seu último fragmento de dados (DS16) fornece apenas 10% da segurança do Ethereum. Claro, estou fazendo com que pareça casual, mas dependendo de como o comitê da Beacon Chain está estruturado, pode haver algumas divisões claras. Mas a essência disso é que o DS0 vem com 100% de segurança (portanto, todos os rollups serão HRE). DS1 é 50% seguro, DS10 é 25% seguro, DS16 é 10% seguro e assim por diante, para um novo tipo de construção, está entre o rollup completo (DS0/100% seguro) e a cadeia de validade/otimista.

Na realidade, à medida que vemos muitos validiums e camadas de dados ficando online, a segurança necessária para cada aplicação, usuário e caso de uso é um espectro. Nem tudo precisa de ser garantido por centenas de milhares de milhões de dólares em segurança económica.

Mas a questão é que, se assumirmos que 30% do fornecimento de ETH está apostado, mesmo a “segurança mínima” DS16 ainda é apoiada por US$ 5 bilhões em segurança econômica, mesmo neste mercado em baixa, e essa ainda é a faixa de segurança de nível alt-L1 superior. . Também é importante lembrar que esse perímetro de segurança serve apenas para disponibilidade de dados. As provas de validade e de fraude ainda são verificadas com 100% de segurança! Portanto, mesmo meio rollup/meio validium de um DS16 tem segurança significativamente melhor do que um alt-L1 de nível superior.

Isto ainda pode ser uma melhoria significativa em relação à opção de camada de dados externa. Com certeza, as transações financeiras de alto valor optarão por liquidar no DS0, mas alguns NFTs de valor médio podem exigir apenas o DS8 e, para aplicações de jogos de valor zero, até mesmo o DS16 pode ser redundante. Conforme mencionado acima, num ambiente voluntário, cada aplicação pode escolher o nível de segurança que necessita com base nas suas próprias circunstâncias.

E quanto aos usuários cumulativos? Eles só precisam executar os fragmentos de dados associados a eles, portanto, os requisitos do sistema não serão diferentes do EIP-4844. É por isso que mesmo que haja compromissos de segurança, não há compromissos de descentralização em relação ao EIP-4844. (A menos que seja um gigarollup estabelecido em vários fragmentos de dados - mas isso é algo que seus usuários estarão bem cientes)

Para ser claro, não espero que essas coisas aconteçam, são apenas divagações de um blogueiro amador maluco e não técnico. O caminho de menor resistência é chegar ao EIP-4844 em 2023 e, quando estiver saturado, em alguns anos, os casos de uso que exigem muitos dados se espalharão por muitas camadas de dados externas, e os dados serão todos altamente comoditizados e enriquecidos. Eventualmente, ao longo dos anos, o danksharding ficou online e se tornou a melhor solução. Mas talvez alguém leia isto e encontre uma ideia melhor para preencher a enorme lacuna entre 4844 e a fragmentação completa...