J'ai suivi les réactions à ce que j'ai dit sur les L2 il y a environ 1,5 jour. Une chose importante que je crois est : "créer encore une autre chaîne EVM et ajouter un pont optimiste vers Ethereum avec un délai d'une semaine" est à l'infrastructure ce que le fork de Compound est à la gouvernance - quelque chose que nous avons fait bien trop souvent et pendant trop longtemps, parce que nous sommes devenus à l'aise, et cela a épuisé notre imagination et nous a mis dans une impasse. Si vous créez une chaîne EVM *sans* un pont optimiste vers Ethereum (c'est-à-dire un alt L1), c'est encore pire. Nous n'avons pas besoin de plus de chaînes EVM copypasta, et nous n'avons certainement pas besoin de plus de L1. Le L1 est en train de se développer et va apporter beaucoup d'espace de bloc EVM - pas infini (les IA en particulier auront besoin à la fois de plus d'espace de bloc et d'une latence plus faible que ce qu'un L1 grandement évolué peut offrir), mais beaucoup. Construisez quelque chose qui apporte quelque chose de nouveau. J'ai donné quelques exemples : la confidentialité, l'efficacité spécifique aux applications, la latence ultra-faible, mais ma liste est sûrement très incomplète. Une deuxième chose importante que je crois est : concernant "la connexion à Ethereum", les vibrations doivent correspondre à la substance. Personnellement, je suis fan de nombreuses choses qui peuvent être appelées "app chains". Par exemple, je pense qu'il y a une grande chance que l'architecture optimale pour les marchés de prédiction soit quelque chose comme : le marché est émis et résolu sur L1, les comptes utilisateurs sont sur L1, mais le trading se fait sur un rollup basé ou un autre système de type L2, où l'exécution lit le L1 pour vérifier les signatures et les marchés. J'aime les architectures où la connexion profonde au L1 est de première classe, et pas une réflexion après coup ("nous sommes à peu près une chaîne séparée, mais oh oui, nous avons un pont, et d'accord, mettons 1-2 développeurs pour le porter à l'étape 1 afin que les gens de l2beat mettent une coche verte dessus pour que Vitalik nous aime"). L'autre extrême de "l'app chain", par exemple, la version où vous convincez un registre gouvernemental, ou une plateforme de médias sociaux, ou un jeu, de commencer à mettre les racines merkle de sa base de données, avec des STARKs qui prouvent que chaque mise à jour a été autorisée, signée et exécutée selon un algorithme pré-engagé, sur la chaîne, est également raisonnable - c'est ce qui a le plus de sens pour moi en termes de "L2 institutionnels". Ce n'est évidemment pas Ethereum, pas crédiblement neutre et pas sans confiance - l'opérateur peut toujours choisir de dire "nous passons à une version différente avec des règles différentes maintenant". Mais cela permettrait une transparence algorithmique vérifiable, une propriété que beaucoup d'entre nous aimeraient voir dans le gouvernement, les algorithmes des médias sociaux ou ailleurs, et cela pourrait permettre une activité économique qui ne serait autrement pas possible. Je pense que si vous êtes la première chose, il est valide et génial de vous appeler une application Ethereum - cela ne peut pas survivre sans Ethereum même technologiquement, cela maximise l'interopérabilité et la composabilité avec d'autres applications Ethereum. Si vous êtes la deuxième chose, alors vous n'êtes pas Ethereum, mais vous (i) apportez à l'humanité plus de transparence algorithmique et de minimisation de la confiance, donc vous poursuivez une vision similaire, et (ii) selon les détails, vous êtes probablement synergique avec Ethereum. Donc, vous devriez simplement dire ces choses directement ! En gros : 1. Faites quelque chose qui apporte réellement quelque chose de nouveau. 2. Les vibrations doivent correspondre à la substance - le degré de connexion à Ethereum dans votre image publique doit refléter le degré de connexion à Ethereum que votre chose a en réalité.

Je ne pense en fait pas que ce soit compliqué. À mon avis, l'avenir de la conception des mécanismes onchain va principalement s'inscrire dans un schéma : [quelque chose qui ressemble à un marché de prévisions] -> [quelque chose qui ressemble à un gadget de définition de préférences résistant à la capture et non financiarisé] En d'autres termes : * Une couche qui est maximement ouverte et maximise la responsabilité (c'est un marché, tout le monde peut acheter et vendre, si vous prenez de bonnes décisions vous gagnez de l'argent, si vous prenez de mauvaises décisions vous perdez de l'argent) * Une couche qui est décentralisée et pluraliste, et qui maximise l'espace pour la motivation intrinsèque. Cela ne peut pas être basé sur des tokens, car les propriétaires de tokens ne sont pas pluralistes, et n'importe qui peut acheter et obtenir 51 % d'entre eux. Les votes ici devraient être anonymes, idéalement MACID pour réduire le risque de collusion. Le marché de prévisions est la bonne façon de faire un "exécutif décentralisé", car le primitif le plus logique pour "responsabilité" dans un concept sans permission est exactement cela. Bien que parfois vous voudrez garder cela simple, et faire un exécutif centralisé à cette couche à la place : [exécutif centralisé remplaçable] -> [quelque chose qui ressemble à un gadget de définition de préférences résistant à la capture et non financiarisé] Penser explicitement en ces deux couches : (i) qui exécute votre exécution, (ii) qui définit vos préférences et juge les exécutants, est la meilleure approche.