Vitalik: A Fusaka está a desenvolver a funcionalidade central PeerDAS, com o objetivo de permitir a blockchain em tempo real sem a necessidade de descarregar dados completos.

A Gold Finance report indica que o fundador do Ethereum, Vitalik Buterin, publicou no X plataforma que, para a Fusaka, a segurança em primeiro lugar é a prioridade máxima. Sua funcionalidade central PeerDAS está tentando fazer algo sem precedentes: criar um blockchain em tempo real que não requer que nenhum nó único faça o download de todos os dados. O funcionamento do PeerDAS é que cada nó solicita apenas uma pequena quantidade de "blocos de dados" (chunk) para validar probabilisticamente que mais de 50% dos blocos de dados estão disponíveis. Se mais de 50% dos blocos de dados estiverem disponíveis, então, teoricamente, o nó pode baixar esses blocos de dados e usar codificação de apagamento (erasure coding) para recuperar o restante dos dados. Na primeira versão, os dados completos do bloco ainda precisam existir em um lugar, há dois casos: (i) Difusão inicial (initial broadcasting): quando os dados são publicados pela primeira vez; (ii) Reconstrução de dados: quando o publicador publica blocos de dados entre 50% e 100%. Mas esses papéis são todos sem necessidade de confiança: só precisamos de um participante honesto para executar essas tarefas, mesmo que haja 100 participantes desonestos, o protocolo os contornará. E diferentes nós podem executar essa tarefa para diferentes blocos. No futuro, a comunicação a nível de célula (cell-level messaging) e a construção de blocos distribuídos (distributed block building) permitirão que essas duas funções também possam ser distribuídas. Estas são todas novas tecnologias, e é prudente que os desenvolvedores principais mantenham uma abordagem extremamente cautelosa durante os testes, mesmo que já trabalhem nisso há anos. É também por isso que o número inicial de blobs aumentará de forma conservadora, e depois se tornará mais agressivo com o passar do tempo. Mas esta é a chave para a escalabilidade L2 (e, em última análise, também a chave para a escalabilidade L1, uma vez que o limite de gas L1 se torne tão alto que precisemos colocar os dados de execução L1 em blobs).