Em Bangkok, anunciámos que iremos analisar seriamente os sistemas de prova. O nosso objetivo é expor todas as suposições de confiança, tornar estes sistemas de prova transparentes e - o mais importante - dar a todos os utilizadores fácil acesso ao código-fonte dos programas que estão a ser provados. O novo Catálogo ZK é o resultado de meses de trabalho, e isto é apenas o começo.

O espaço de design dos rollups do Ethereum é enorme. Não vou negar que avaliar o @0xFacet foi desafiador para toda a equipe, uma vez que seu design não é o que você esperaria de um rollup típico. No entanto, adoramos ser desafiados e, como resultado, alguns novos painéis relacionados a ativos canônicos e externamente conectados estão em desenvolvimento. O aspecto mais desafiador do @0xFacet é, sem dúvida, seu token de gás não padrão. Seu uso desafia a definição central de um ativo "canônico", uma vez que normalmente assumimos que o token de gás deve ser conectado de forma canônica, mas e se você não "conectar" o token de gás de forma alguma? O que é um ativo canônico e uma ponte canônica então? Leia a análise completa e o anúncio do @0xFacet para mais detalhes técnicos.

Eu tenho uma visão muito diferente * muitos projetos conseguiram fazer uma lavagem cerebral em todos de que postar dados na AWS ou 1/1 DAC é "bom o suficiente". Os usuários finais não se importam, mas nós (comunidade profissional) devemos fazê-los se importar, desencorajando fortemente tais arquiteturas. Em vez disso, eles são realmente encorajados por algumas equipes de rollup e RaaS * O mecanismo de descoberta de preços no Ethereum e Celestia é desagradável - os projetos querem confiabilidade de preço Web2 para que eles possam manter um preço baixo e previsível para seus usuários. Picos de preços repentinos não são aceitáveis quando você opera em escala * Os projetos de AD devem se concentrar na promoção de casos de uso legítimos e não em projetos centralizados que nem se preocupam em publicar seu código para que a comunidade possa verificar suas reivindicações. Se tudo o que construímos forem clones hiperlíquidos, então todos iremos a zero. Ninguém quer, a longo prazo, um intercâmbio centralizado e de custódia que pretenda ser descentralizado * Ataques de retenção de dados (literalmente a principal razão para usar DA) são difíceis de explicar aos usuários - poderíamos fazer com mais educação e, em geral, a consciência da comunidade de um problema. A grande maioria dos usuários profissionais não vê a diferença entre publicação e recuperação de dados. Os usuários não-profissionais não veem nenhum problema, pois para eles os dados "parecem" estar sempre disponíveis, então é difícil explicar a eles qual problema estamos tentando resolver aqui