À Bangkok, nous avons annoncé que nous allons examiner sérieusement les systèmes de preuve. Notre objectif est d'exposer toutes les hypothèses de confiance, de rendre ces systèmes de preuve transparents et - surtout - de donner à tous les utilisateurs un accès facile au code source des programmes prouvés. Le nouveau Catalogue ZK est le résultat de mois de travail, et ce n'est que le début.

L'espace de conception des rollups Ethereum est immense. Je ne vais pas nier que l'évaluation de @0xFacet a été un défi pour toute l'équipe, car son design n'est pas ce à quoi vous vous attendriez d'un rollup typique. Néanmoins, nous aimons être mis au défi et, en conséquence, certains nouveaux tableaux de bord liés aux actifs canoniques et aux actifs bridés de manière externe sont en cours de développement. L'aspect le plus difficile de @0xFacet est sans aucun doute son jeton de gaz non standard. Son utilisation remet en question la définition même d'un actif "canonique", car normalement nous supposons que le jeton de gaz doit être ponté de manière canonique, mais que se passe-t-il si vous ne "pontez" pas du tout le jeton de gaz ? Qu'est-ce qu'un actif canonique et un pont canonique alors ? Lisez l'examen complet et l'annonce de @0xFacet pour plus de détails techniques.

J'ai une vision très différente * De nombreux projets ont réussi à laver le cerveau de tout le monde en faisant croire que publier des données sur AWS ou 1/1 DAC est "suffisant". Les utilisateurs finaux s'en moquent, mais nous (la communauté pro) devrions les inciter à s'en soucier en décourageant fortement de telles architectures. Au lieu de cela, elles sont en fait encouragées par certaines équipes de rollup et de RaaS. * Le mécanisme de découverte des prix dans Ethereum et Celestia est rebutant - les projets veulent une fiabilité des prix Web2 afin de pouvoir maintenir un prix bas et prévisible pour leurs utilisateurs. Des pics de prix soudains ne sont pas acceptables lorsque vous opérez à grande échelle. * Les projets DA devraient se concentrer sur la promotion de cas d'utilisation légitimes et non sur des projets centralisés qui ne prennent même pas la peine de publier leur code afin que la communauté puisse vérifier leurs affirmations. Si tout ce que nous construisons ce sont des clones de Hyperliquid, alors nous irons tous à zéro. Personne à long terme ne veut d'un échange centralisé et de garde qui prétend être décentralisé. * Les attaques par rétention de données (littéralement la principale raison d'utiliser DA) sont difficiles à expliquer aux utilisateurs - nous pourrions bénéficier de plus d'éducation et, en général, d'une sensibilisation de la communauté à un problème. La grande majorité des utilisateurs pro ne voient pas la différence entre la publication de données et la récupération de données. Les utilisateurs non pro ne voient pas de problème du tout car pour eux, les données "apparaissent" toujours disponibles, donc il est difficile de leur expliquer quel problème nous essayons de résoudre ici.