Limite d'admission pour les robots autonomes@Fabric FoundationLa passerelle de réessai est actuellement réglée sur 3. Je n'ai pas commencé là. Le protocole Fabric a par défaut une seule validation de confirmation lorsque j'ai d'abord connecté l'un de nos agents robotiques à sa couche d'identité sur chaîne. L'appel renvoyait "vérifié", le robot procédait à demander une allocation de tâche, et le reste du pipeline supposait que l'identité avait été réglée. Ce n'était pas le cas. Le protocole Fabric se situe directement dans cette poignée de main. Ce n'est pas un registre d'identité abstrait. C'est le système qui décide si une machine peut participer. Lorsque je l'ai d'abord intégré, j'ai traité la vérification d'identité comme une porte booléenne. Vrai, avancer. Faux, arrêter. Ce que j'ai appris, c'est que dans les systèmes autonomes, la confirmation n'est pas la même chose que la stabilité. Sous charge, la limite d'admission change. Nous exécutons un lot de 42 robots simulés, chacun essayant d'enregistrer des capacités et de demander des droits de coordination dans une fenêtre d'exécution serrée. Le contrat d'identité de Fabric a traité les attestations, les credentials engagés et les preuves de capacité, puis a renvoyé le succès. La confirmation sur chaîne est arrivée dans une fenêtre de bloc prévisible. Tout semblait propre. Puis deux agents ont commencé à dupliquer des revendications de tâche. Pas de manière malveillante. Pas parce que le protocole a échoué. Parce que la finalité d'identité est arrivée plus vite que la convergence comportementale. Les robots ont traité l'événement de succès d'identité comme une visibilité globale. Ce n'était pas le cas. Certains pairs avaient encore une vue obsolète des identités qui étaient liées et de celles qui ne l'étaient pas. Fabric avait confirmé l'engagement, mais le réseau ne l'avait pas entièrement intégré. C'est alors que j'ai ajouté la passerelle de réessai. Au lieu d'une confirmation d'identité, l'agent nécessite maintenant trois confirmations espacées sur des lectures d'état distinctes. La première confirme la présence de l'engagement. La seconde vérifie la latence de reconnaissance des pairs. La troisième valide qu'aucune revendication d'identité conflictuelle n'est apparue dans une fenêtre limitée. L'espacement est de 1,2 secondes entre les lectures. Ce nombre n'est pas arbitraire. En dessous d'une seconde, nous avons encore observé des conditions de course. Au-dessus de deux, la latence d'allocation de tâche est devenue perceptible pour les utilisateurs surveillant le tableau de bord. L'identité est devenue une négociation limitée dans le temps plutôt qu'un événement unique. Voici le changement mécanique : avant la passerelle, environ 6% des robots ont connu un écho de capacité où deux agents croyaient avoir des droits exclusifs sur le même créneau de tâche. Après la passerelle, cela est tombé en dessous de 1%. Le coût était visible. Le temps de démarrage moyen de la tâche a augmenté de 3,4 secondes. Si vous concevez une coordination de robots autonomes, demandez-vous ceci : préféreriez-vous avoir un robot plus rapide qui agit parfois en double, ou un robot plus lent qui attend une certitude sociale ? L'identité sur chaîne de Fabric rend cette question inévitable car elle lie l'admission à l'engagement économique. L'agent s'engage à exister. Cet engagement signale le sérieux, mais il crée également un nouveau mode d'échec. Lorsque l'identité équivaut à un capital lié, les réessais ne sont plus simplement du bruit réseau. Ils sont une friction économique. L'une des premières tensions que j'ai ressenties était autour des budgets de réessai. Chaque lecture de confirmation supplémentaire est une autre interaction avec la chaîne, une autre dépense de gaz, une autre couche de retard. À grande échelle, cela s'accumule. Avec 100 agents passant par un rafraîchissement d'identité toutes les 15 minutes, la différence entre un passage et trois passages n'est pas triviale. Cela change votre enveloppe opérationnelle. Il y a une ligne forte qui revenait sans cesse à moi pendant les tests : La fiabilité n'est pas ajoutée à la fin. Elle est achetée à la limite d'admission. Le choix de Fabric d'ancrer l'identité des robots sur chaîne signifie que l'admission est coûteuse par conception. Vous n'apparaissez pas comme participant de manière décontractée. Vous vous engagez. Vous vous enregistrez. Vous êtes noté. Cela repousse les bots. Cela repousse également l'expérimentation. J'ai ressenti ce compromis directement en faisant tourner des agents éphémères pour des tests de stress. Dans un registre hors chaîne traditionnel, je pouvais créer et jeter des identités librement. Sur Fabric, même les agents de test doivent passer par l'entonnoir d'identité. Cela signifiait des blocages de capital et des cycles d'engagement. Cela a ralenti l'itération. Mais cela m'a également fait remarquer quelque chose d'inconfortable. Lorsque les identités sont bon marché, les mauvais comportements sont bon marché. Nous avons une fois mené une expérience parallèle en utilisant un cache d'identité léger hors chaîne pour accélérer le prototypage. En quelques heures, nous avons vu des agents spamer des mises à jour de capacité parce qu'il n'y avait pas de coût significatif à réaffirmer l'identité. Le routage des tâches s'est dégradé. Les files d'attente de priorité ont été faussées. Revenez à Fabric avec des identités liées et le spam a disparu. L'exigence d'engagement n'a pas seulement sécurisé le système. Elle a façonné le comportement en amont. Voici un test concret que vous pouvez effectuer si vous touchez un jour quelque chose comme cela. Faites tourner dix agents avec des capacités identiques. Variez légèrement le poids de l'engagement, même par un petit pourcentage. Observez la préférence de routage sur une fenêtre de plusieurs heures. Sur Fabric, la couche de notation d'identité favorise subtilement les signaux de stabilité liés à l'engagement. Les agents liés de haut niveau ont connu moins de réaffectations de routage lors de nos essais. Non pas parce que le protocole a annoncé du favoritisme, mais parce que la notation de stabilité a intégré la fiabilité historique ancrée à l'identité. C'est là que le doute s'immisce. Lorsque la qualité de routage commence à se corréler avec la profondeur de l'engagement, sommes-nous encore purement ouverts ? Ou gateons-nous discrètement la qualité de coordination derrière le poids économique ? Je n'accuse pas le protocole de biais intentionnel. J'admets qu'une fois que l'identité devient économique, la neutralité devient coûteuse à maintenir. Un autre exemple mécanique. Nous avons introduit un délai de garde après l'enregistrement d'identité avant de permettre les enchères de tâche. Il est fixé à 5 blocs. Sans cela, les agents nouvellement enregistrés pouvaient immédiatement inonder la file d'enchères avant que les pairs ne mettent à jour leurs vues locales. Avec le délai, nous avons éliminé le microburst où de nouvelles identités dominaient brièvement l'allocation. L'inconvénient était évident. Les agents légitimes attendaient inactifs pendant ces blocs supplémentaires. Ce délai de garde a stabilisé la coordination plus que toute modification de notation. Si vous pensez que l'identité concerne des noms et des clés, essayez de regarder des robots entrer en collision parce que la confirmation est arrivée trop rapidement. L'architecture de Fabric m'a forcé à déplacer la friction à l'avant du pipeline. Au lieu de déboguer le chaos émergent en aval, j'ai absorbé le coût à la couche d'admission. Plus de lectures. Plus d'attente. Plus de validation d'engagement. Deux tests ouverts pour quiconque évaluant ce design. Premièrement, réduisez votre passerelle de réessai à un passage et exécutez sous une charge de 2x attendue. Surveillez les chevauchements de capacité fantômes. Si vous le voyez, demandez-vous si votre confirmation d'identité signale une finalité sociale ou juste une exécution de contrat. Deuxièmement, réduisez votre délai de garde de moitié. Observez la volatilité des enchères pour les agents nouvellement enregistrés. L'allocation penche-t-elle brièvement vers les nouveaux venus ? Si oui, votre limite d'identité est plus fine que vous ne le pensez. Le point n'est pas que le protocole Fabric a tout résolu. Le point est qu'en rendant l'identité sur chaîne et économiquement liée, cela m'a forcé à confronter l'admission comme une surface d'ingénierie de première classe. Ce n'est qu'après avoir lutté avec cela que le jeton a semblé inévitable. Lorsque l'existence des robots nécessite un engagement, et que l'historique de fiabilité est ancré à cet engagement, le jeton n'est pas un accessoire. C'est le régulateur de pression. Il détermine qui peut entrer, à quelle fréquence ils peuvent réessayer, à quel point l'instabilité devient coûteuse. J'ai retardé ma réflexion à ce sujet parce que je ne voulais pas réduire un problème de coordination à l'économie. Mais l'économie était déjà intégrée dans la couche d'identité. Il y a un biais en moi vers des portes plus strictes. Je préfère des systèmes plus lents et plus prévisibles. Quelqu'un qui construit des robots destinés aux consommateurs pourrait ne pas être d'accord. Ils pourraient accepter un chevauchement occasionnel en échange de rapidité. La posture de Fabric penche vers la discipline. J'ai toujours la passerelle de réessai réglée sur 3. J'ai envisagé de la pousser à 4 pendant les fenêtres de pointe. Cela réduirait probablement encore une fraction des conflits de coordination. Cela ferait également passer la latence de tâche au-delà de ce que certains utilisateurs tolèrent. Donc, je laisse cela ici pour l'instant. L'identité sur chaîne ne concerne pas les slogans de décentralisation. Il s'agit de décider où vous voulez payer pour la certitude. Dans notre cas, nous payons à la porte. Et je ne suis toujours pas sûr si c'est du courage ou de la prudence.