Vitalik: Agora estou mais otimista com rollups nativos do que antes

De acordo com reportagem da Jinse Finance, Vitalik Buterin publicou na plataforma X dizendo: Agora estou mais inclinado aos rollups nativos do que antes. Um dos principais motivos pelos quais eu era contra anteriormente era que os rollups nativos precisavam escolher entre o modo "zk" ou o modo "otimista" para a pré-compilação (precompile). Como o ZK-EVM ainda não está suficientemente maduro no modo ZK, se dermos duas opções para o L2: "usar provas totalmente endossadas pela Ethereum, com saques exigindo uma espera de 2 a 7 dias" ou "saques instantâneos, mas você mesmo precisa cuidar das provas", o L2 geralmente escolherá a primeira opção. Isso é muito prejudicial para a composabilidade da Ethereum e leva à adoção de mais pontes multisig, entre outros problemas.Mas agora parece que o cronograma para a aceitação total do ZK pela Ethereum no L1 está alinhado com o cronograma real para adicionar pré-compilações nativas de rollup, então esse problema foi resolvido.Além disso, vejo cada vez mais trabalhos colocando a composabilidade síncrona como uma das principais propostas de valor para a criação de L2s. Eu também sugeri um método: https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863, que combina rollups baseados com pré-confirmações de baixa latência em L2 para alcançar composabilidade síncrona.Portanto, sinto que este é o caminho certo para o desenvolvimento.Acredito que não devemos ser preguiçosos e precisamos dedicar mais esforços para encontrar a melhor maneira de implementar essa pré-compilação. Uma característica fundamental que desejo é: se você criar um rollup "EVM + alguns novos recursos", deve ser possível usar a pré-compilação nativa de rollup para o EVM, enquanto utiliza seu próprio provador (prover) para lidar com os novos recursos adicionados. Pode-se considerar o uso de uma tabela de pesquisa (lookup table) para conectar ambos de forma padronizada.