Tout le monde construit des agents et des portefeuilles. Presque personne ne se demande si les transactions aboutissent.
Les agents paient déjà pour des choses sur Ethereum. Pas dans une démo. x402 a transformé HTTP 402 en un flux de paiement en temps réel, et les portefeuilles d’agents sont désormais livrés avec des clés et des limites de dépenses. Des équipes construisent en partant du principe qu’une machine peut régler seule ses obligations sans qu’une personne soit à proximité.
Le secteur est allé vite pour donner aux agents les moyens de payer, mais ce qu’il a sauté, c’est la couche en dessous. Un rail de paiement suppose que le paiement passe, et Ethereum n’a jamais été conçu sur cette hypothèse. L’inclusion est un effort de meilleure tentative : vous soumettez, et vous espérez que cela atterrira dans le prochain bloc. Un humain peut contourner ce problème en surveillant une transaction bloquée, en augmentant les frais et en réessayant. Vous pouvez construire un agent qui fasse la même chose. Ce que vous ne pouvez pas construire, c’est la certitude : un nouvel essai est le même pari rejoué, dans un marché qui a déjà bougé.
Rien de tout cela n’a beaucoup d’importance pour une transaction. Cela compte énormément à dix mille par jour, lorsque chaque action attend la précédente.
Ethereum règle la valeur. Il ne la planifie pas encore.
Sur Ethereum, l’espace de bloc est alloué via une enchère en temps réel qui se résout approximativement toutes les douze secondes. Quand vous soumettez une transaction, vous n’achetez pas une place garantie dans le prochain bloc. Vous entrez dans une compétition, et son issue – à la fois le fait d’être inclus ou non, et ce que vous paierez au final – reste inconnue jusqu’à ce que tout soit déjà terminé. Cette conception est élégante pour un réseau sans permission. Elle est aussi étrangère à la manière dont fonctionne la finance institutionnelle.
Les institutions sont déjà sur Ethereum. Ce qu’elles ne peuvent pas faire, c’est exécuter les stratégies qui nécessitent des garanties. Lorsqu’un desk ne peut pas savoir à l’avance si une transaction sera exécutée à temps, ni ce qu’il en coûtera pour y parvenir, il ne peut pas y mettre de la taille, donc cette activité reste off-chain ou migre vers un endroit qui fournira cet engagement.
Pendant des années, la réponse aux limites d’Ethereum a été le débit : plus de transactions par seconde, plus de rollups pour diffuser la demande. Le débit est une mesure de quantité. Il ne dit rien du moment. C’est un problème de temps, pas d’espace, et ajouter plus d’espace ne le résout pas.
Combler l’écart
Plusieurs approches entrent maintenant en phase d’implémentation, chacune s’attaquant à une couche différente du problème.
Les préconfirmations permettent à un proposeur de s’engager à inclure ou exécuter une transaction avant que le bloc ne soit finalisé. C’est la réponse la plus directe au problème de timing : l’agent n’a plus à soumettre et espérer. Mais l’engagement doit signifier quelque chose. Il lui faut une large participation des validateurs, un soutien économique crédible et des conséquences applicables lorsqu’un proposeur ne respecte pas sa promesse. Les systèmes qui associent des préconfirmations à du collatéral mis en staking et à des conditions de slashing transforment une promesse en obligation responsable.
Les listes d’inclusion opèrent au niveau du protocole en limitant ce qu’un builder est autorisé à exclure. Cela en fait un outil puissant contre la censure. Mais elles résolvent un autre problème : rendre une transaction plus difficile à exclure n’équivaut pas à s’engager sur le moment où elle sera exécutée. Une liste d’inclusion fixe un plancher. Elle ne fixe pas un calendrier.
Les marchés à terme prolongent ce calendrier plus loin dans le futur. Ils permettent aux institutions et aux applications de réserver de l’espace de bloc avant d’en avoir besoin, comme l’énergie, la bande passante et la capacité de calcul sont contractualisées à l’avance par rapport à la demande. Cela transforme la capacité future en quelque chose autour de quoi un acheteur peut planifier, plutôt que de devoir se battre pour l’obtenir en temps réel. Les questions de conception portent ici sur la structure de marché : accès transparent, livraison imputable aux validateurs et mécanismes empêchant qu’une petite poignée de gros acheteurs ne verrouille la capacité.
Chaque approche peut avoir des contraintes autour desquelles il faut concevoir. Ensemble, elles dessinent la forme d’un marché sur lequel agents et institutions peuvent réellement construire : des engagements de proposeurs qui comptent, des garanties au niveau du protocole contre l’exclusion, et une capacité à terme qui s’adapte à la demande institutionnelle. Chaque approche prise isolément a encore des questions de design à résoudre. La direction, elle, est claire.
Un agent qui déboucle une position sur deux plateformes doit savoir que la seconde jambe sera réglée avant de s’engager sur la première. Sans cela, il n’exécute pas une stratégie. Il prend un pari et attend de voir.
Ethereum a déjà construit un règlement crédible. Le prochain défi consiste à rendre l’accès à ce règlement programmable à l’avance. Si les agents doivent coordonner du capital à la vitesse de la machine, l’espace de bloc ne peut pas rester quelque chose pour lequel ils se contentent d’enchérir en espérant le recevoir. Il doit devenir quelque chose qu’ils peuvent planifier dans le temps.