Como seria a agregação de assinaturas em consenso enxuto do ponto de vista do proponente? Resumindo o que @drakefjustin me explicou: "Com consenso enxuto, o objetivo é permitir que qualquer pessoa opte por ser agregador, em vez de ter agregadores dedicados. Isso basicamente permite que o validador padrão entre com requisitos de hardware extremamente fracos. O meme é que, mesmo que você esteja no Raspberry Pi ou seja mais fraco, deveria poder participar como validador. Então, em vez disso, a suposição que fazemos é que apenas 10% dos validadores têm hardware suficiente, ou seja, um processador de laptop, e basicamente optariam por se tornar agregadores nessas sub-redes. E então teremos múltiplas camadas de agregação onde os agregados dentro das sub-redes seriam comunicados para uma próxima rodada, onde haveria agregação entre os agregados. Então você tem a metaagregação. E então há um agregado final, que é escolhido pelo próximo proponente. Mas esse é um processo muito barato de escolher o melhor agregado, em vez de o próximo proponente ter que fazer a agregação sozinho." Ouça o episódio completo para mais detalhes.

Minha pergunta para o Justin era: qual foi a consideração para a função hash do Poseidon ser a mais apropriada para a SNARKificação da camada de consenso. Veja o que @drakefjustin disse sobre os benefícios e desvantagens de escolher a função hash do Poseidon: "... Em geral, se você pegar qualquer função hash, ou pelo menos a maioria das funções hash, acredita-se que elas sejam pós-quânticas seguras. Mas, o importante é que, ao construir suas assinaturas e seus SNARKS, é usar apenas a função hash e não introduzir outras suposições como o log discreto, que não é seguro pós-quântico. Por que Poseidon? Não é porque seja seguro pós-quântico, mas sim porque é amigável ao SNARK. As funções tradicionais de hash são construídas para usar portas binárias como XORs, ANDs e SHIFTs. Essas operações binárias não são nada amigáveis aos SNARKs. E assim, em vez disso, temos essas chamadas funções hash aritméticas que são construídas usando corpos finitos, matrizes e polinômios. E então, você tem esses vetores que você multiplica por matrizes. E essa forma muito mais aritmética de embaralhar as coisas internamente que leva a pelo menos uma ordem de magnitude de desempenho. Então, a diferença entre Poseidon e SHA-2 é pelo menos 10 vezes maior quando se trata de sarcasmo. E porque queremos poder agregar o máximo possível de assinaturas por segundo, torna-se muito importante escolher uma boa função de hash. A principal desvantagem de escolher o Poseidon é que ele é uma nova função de hash. E por novo, quero dizer que tem apenas seis anos. Tradicionalmente, quando você trabalha com uma função de hash, há um tempo de cozimento em que a comunidade demora muito para se acostumar com essa função de hash. De forma geral, o tempo de cozimento para a função de hash que tenho em mente é de oito anos. Por que oito anos? Porque quando Satoshi escolheu Sha256, ele tinha oito anos. E quando Vitalik escolheu Keccak para Ethereum, ele também tinha oito anos. Então, espero que, em dois anos, mais ou menos, tenhamos essa função de hash, que tem oito anos e já é bem testada em batalha..." Para quem se interessa em testar a função de hash do Poseidon, você pode acessar um local onde pode saber mais sobre a recompensa de $1 milhão que @ethereumfndn está oferecendo por quebrar o Poseidon. Também em 20 de março, haverá uma chamada EthProof dedicada à segurança de Poseidon. Se for interessado, por favor envie uma mensagem privada @drakefjustin.

Perguntei ao Justin que tipo de infraestrutura Lean Ethereum pretende usar. O que @drakefjustin respondeu foi um vislumbre da "fronteira de gás Terra para L2s". Aqui está o que ele disse: "... o objetivo é chegar à "fronteira de gás Terra para os L2". Isso significa que todos os L2s juntos terão disponibilidade de dados suficientes para suportar um Teragas por segundo. Se você tem um consumo médio de cem mil gás por transação, isso equivale a 10 milhões de transações por segundo. E se você quiser olhar em bytes, é um gigabyte por segundo, o que é ordens de magnitude a mais do que temos. Poucas coisas que vão nos ajudar a chegar lá. > Primeiro, todos os aprendizados que teremos no curto prazo com as melhorias incrementais serão muito importantes. >Dois, teremos a lei de Nielsen, que basicamente é o equivalente à lei de Moore para largura de banda, que diz que a cada ano a largura de banda de uma conexão de internet comum crescerá cerca de 50%. E quando você acumula 50% ao longo de 10 anos, obtém cerca de 100x. > E a terceira coisa que estamos analisando é basicamente um redesenho do zero dos blobs que viriam junto com a mudança para pós-quântico. A criptografia KZG, como usada para blob, não é segura pós-quântica. Estamos olhando para designs, por exemplo, inspirados em ZODA (@alexhevans et al.) da Celestia (@celestia). Infelizmente, a Celestia faz várias suposições que não se traduzem bem no contexto do Ethereum. Eles assumem, por exemplo, uma maioria honesta para a disponibilidade de dados. Essa não é uma suposição que queremos fazer. Então teremos que trabalhar bem mais do que a Celestia para conseguir isso. E uma das ideias candidatas, que parece muito promissora, é reutilizar a criptografia que estamos desenvolvendo para a agregação de assinaturas pós-quânticas para a camada de dados também. Temos uma infraestrutura chamada Lean VM, que é um ZKVM mínimo, especialmente otimizado para criptografia baseada em hash. E a ideia poderia ser que basicamente provamos a correção da merculização de um código de apagamento de uma mancha..." Ouça o episódio completo para mais detalhes.