Un plafond de dépenses qui ne compte plus est déjà en panne

DEV - 19/07
Un plafond de dépenses qui ne compte plus est déjà en panne. Lorsque l’oracle des coûts se tait, la question est de savoir si le grand livre continue d’évoluer. Cinq stratégies.

Deux des cinq façons dont un plafond de dépenses peut gérer un prix manquant produisent exactement le même flux de décision : le même sha256, octet par octet. L’un d’eux est ce que tout le monde appelle le fail-open. L’autre est ce que tout le monde recommande à la place : adopter un modèle local gratuit.

Laissez-moi vous dire ce qu'est ce hachage et ce qu'il n'est pas avant qu'il ne fonctionne. Il couvre(séquence, étiquette, admis, charge)et supprime délibérément les chaînes de raison lisibles par l'homme, de sorte que deux politiques qui impriment des mots différents hachent de la même manière lorsqu'elles décident de la même chose. Une fois que vous voyez cela, la collision est un théorème plutôt qu'une découverte : un repli gratuit coûte zéro, un échec d'ouverture coûte zéro, et un registre construit à partir de frais ne peut pas les distinguer car il n'y a rien à distinguer. Le sha256 prouve seulement que mon implémentation ne triche pas discrètement.

La raison pour laquelle cela vaut toujours la peine d'être publié est que personne ne les expédie selon la même politique. L’un est le bug pour lequel vous vous excusez ; l'autre est le correctif que vous recommandez dans le fil de discussion. Sur l’axe qui compte, il y a une seule politique, et l’une d’elles a une meilleure image de marque.

Divulgation de l'IA. j'ai écritblind_spend_cap.pyavec l'aide de l'IA et je l'ai exécuté moi-même. Chaque numéro et hachage ci-dessous est collé à partir d'une exécution réelle : hors ligne, stdlib uniquement, pas de réseau, pas de clés, pas de fonds. L'oracle est injecté, donc les exécutions sont déterministes. Je l'ai exécuté trois fois ; la sortie était identique en octets à chaque fois. Codesha256ddc42590…, sortie sha2569ebe1b4a…. Les figures extérieures sont liées et étiquetées, et je dis clairement celles que je n'ai pas reproduites.

TL;DR

  • Un plafond de dépenses nécessite un oracle des coûts pour évaluer la prochaine action. L'oracle a sa propre panne.
  • Le cadrage habituel (fail-open vs fail-closed) est le mauvais axe. La véritable scission : le grand livre continue-t-il de bouger pendant que l'oracle se tait ?
  • Les stratégies qui imposent un prix que le budget restant peut encore absorber maintiennent le grand livre en vie et rétablissent le plafond. Chargez zéro etdépenségèle pour toujours. Chargez plus que ce qui vous convient et vous avez écritrefuseravec des étapes supplémentaires - le harnais le prouve sur lui-même.
  • Une solution de secours locale gratuite ne coûte rien. Dans mon harnais, il produit un flux de décision identique à un simple échec d'ouverture : le même sha256.
  • Mais un registre mobile est un plancher, pas un certificat. Toute fiction positive le satisfait – prix un0,05 $appeler au0,01 $et votre plafond est tranquillement cinq fois supérieur à celui que vous avez configuré. L'axe réel est le biais de votre estimateur ; zéro est exactement l'endroit où ce biais atteint -100 %.
  • Le chiffre du titre que vous attendez de moi ici (34 actions supplémentaires) est arithmétique et non une preuve. Je le démonte ci-dessous plutôt que de le vendre.

La branche que personne n'écrit

Chaque plafond de dépenses que j'ai expédié a la même forme. Évaluez l’action, comparez-la à un budget, autorisez ou bloquez. L'étape de tarification suppose que les réponses d'Oracle.

Ce n'est pas toujours le cas. CoinGecko 429s. Un point de terminaison d’utilisation expire. Un compteur de jetons se trouve derrière une passerelle renvoyant 526. À ce moment-là, votre plafond prend une décision qui ne figure probablement pas dans vos notes de révision de code, car elle ne figure pas dans votre code : que faire d'une action dont il ne peut pas fixer le prix.

Je sais que ce n'est pas écrit parce que je l'ai expédié de cette façon. Le 8 juin 2026, j'ai publié SpendGuard, un plafond de pré-exécution de 40 lignes. Cela fonctionne et il n'a jamais déclaré cette branche. L'appel de l'oracle se trouve à l'intérieurcoût_fnà la ligne 121, eteth_price_usd()appelsraise_for_status()avant de retourner quoi que ce soit. Ainsi, sur un 429, l'exception passe directement devant la porte et sort de l'emballage. Fermeture par échec accidentel, au moyen d'une exception non interceptée qui fait tomber l'appelant au lieu de renvoyer un verdict que vous pouvez compter.

Copiez la boucle de démonstration de ce même message et vous obtenez le contraire. Il évalue une fois avant la boucle et réutilise ce numéro à chaque tour. Une panne à mi-boucle est invisible. Ouverture accidentelle.

Même fichier, deux câblages, deux comportements opposés, et je n'ai déclaré ni l'un ni l'autre.

Cinq stratégies, une fourchette

J'ai donc construit le plus petit truc qui isole la branche.blind_spend_cap.pyexécute un ping-pong Analyseur/Vérificateur à travers une seule porte budgétaire, selon cinq stratégies identiques partout sauf dans lela citation est Aucunebloc:

else : if stratégie == "refuse": return _v(seq, "BLOCK", "no quote: refuse", False, 0, priced) if stratégie == "admit-unpriced": return _v(seq, "ADMIT", "no quote: admet, charge 0 (ledger gelé)", True, 0, priceed) if stratégie == "stale": si last_known est Aucun : return _v(seq, "BLOCK", "no quote et no dernier prix connu : refuser", False, 0, prix) est, tag = last_known, "stale " elif stratégie == "pessimiste": est, tag = per_action_cap, "pessimiste " elif stratégie == "fallback": est, tag = fallback_cents, "fallback "
Entrer en mode plein écran Quitter le mode plein écran

Deux choix de conception méritent d’être soulignés, car tous deux vont à l’encontre du résultat que j’aurais pu souhaiter.

Un BLOC n'arrête pas la boucle. Un véritable fugitif réessaye. Mon harnais précédent donnait à la politique de refus un accès gratuitcasser, ce qui lui a discrètement valu la victoire : il "a arrêté la fugue" parce que j'ai écrit la boucle de cette façon. Ici, la por...
[Courte citation de 8% de l'article original]

Loading...