Bug du transfert groupé : comment marche le correctif proposé
Le correctif proposé additionne les éléments d’un même token id : 40 + 40 compte pour 80. Est-il fusionné, et que faire d’autre ?
EN 30 SECONDES
Un contrôle cumulé par id est un correctif qui additionne les éléments d’un batch de même token id et compare ce total cumulé au solde brut et au montant non gelé. La PR n° 2045 le propose pour le code de référence d’ERC-7943 ; elle n’était pas fusionnée au 7 octobre 2026.
À RETENIR · 3
- Avec la PR n° 2045, le batch de 40 + 40 sur un même id est refusé au second élément, avant tout débit.
- Au 7 octobre 2026, la PR était ouverte, non fusionnée et sans revue, et l’issue n° 1814 restait ouverte.
- Tout correctif doit montrer au contrôle le total par id. Un contrôle du solde après le débit est un filet de sécurité de plus, pas un remplacement.
Sur cette page
Un exemple concret : le même batch, avant et après le correctif
EN BREF Avec la PR n° 2045, le même batch est refusé au second élément : le contrôle additionne désormais les éléments d’un même id.
LES MOTS À CONNAÎTRE
- Test de non-régression
- Un test qui rejoue un bug une fois corrigé, pour qu’il ne puisse jamais revenir sans qu’on le voie.
- Pull request
- Une proposition de modification du code d’un projet, ouverte à la relecture. Elle ne change rien tant que personne ne la fusionne.
- Transfert vers soi-même
- Un transfert dont l’expéditeur et le destinataire sont le même compte.
UN EXEMPLE CONCRET
REFUSÉPR n° 2045 appliquée : l’id 1 deux fois, 40 chacun
ENTRÉE
- Solde
- 100
- Gelé
- 60
- Batch
- id 1 deux fois : 40 + 40
CE QUI SE PASSE
- Premier élément : le total cumulé de l’id 1 vaut 40, dans la limite des 40 non gelés.
- Second élément : le total cumulé de l’id 1 passe à 80, au-delà des 40 non gelés.
- L’appel échoue (revert) avant tout débit.
SORTIE
- Déplacé
- 0
- Solde / gelé
- 100 / 60
CONTOURNÉContrat de référence avant le correctif, même batch
ENTRÉE
- Batch
- id 1 deux fois : 40 + 40
CE QUI SE PASSE
- Chaque élément est comparé aux mêmes 40 non gelés : les deux passent.
- Ensuite seulement, les deux éléments sont débités : 80 au total.
SORTIE
- Déplacé
- 80
- Solde / gelé
- 20 / 60
OBJET OBTENU
Additionner par id
Chiffres tirés de la reproduction de la PR, pas inventés. Sans correctif, le contournement reste limité : vers un autre compte, jamais plus que le solde brut, et chaque élément doit tenir dans les 40 non gelés. Mais tout détenteur sur liste blanche peut s’en servir, sans rôle particulier.
Un Test de non-régression Un test qui rejoue un bug une fois corrigé, pour qu’il ne puisse jamais revenir sans qu’on le voie. Voir le glossaire rejoue exactement ce batch, et il passe une fois les modifications de la PR appliquées.
Coming up next: Alors, ce correctif est-il fusionné ?
Où en sont l’issue n° 1814 et la PR n° 2045
EN BREF Au 7 octobre 2026, le correctif attendait dans une pull request ouverte, sans revue, et l’issue restait ouverte.
ÉTAPE PAR ÉTAPE
Étape 1. Final. Le commit « Update ERC-7943: Move to Final » fait passer le texte de l’ERC en Final.
- Final Le commit « Update ERC-7943: Move to Final » fait passer le texte de l’ERC en Final.
- Signalé @MavenRain ouvre une issue, un signalement public, sur le contournement par id répété dans uRWA1155, avec une preuve de concept.
- Renvoyé Un contributeur recommande de publier sur le fil de l’ERC dans Ethereum Magicians, le forum des standards.
- Correctif proposé @Kshot3000 ouvre la PR n° 2045 : elle corrige les branches de transfert et de burn (un burn détruit des tokens) et ajoute trois tests de non-régression.
- Toujours ouverte La PR est ouverte et non fusionnée, sans revue. Le bot indique qu’il faut une revue d’auteur et deux revues d’éditeurs. L’issue reste ouverte, elle aussi.
EN CLAIR
Quatre façons de combler l’écart
EN BREF Tout correctif doit montrer au contrôle le total par id, et chaque option a son compromis.
J’aime le contrôle après débit comme seconde ligne de défense. Sur les transferts du détenteur qui partent d’un solde couvrant le gel, il vérifie directement que les tokens gelés restent en place.
ATTENTION
Le gel peut dépasser le solde : ces transferts ne doivent alors pas aggraver l’écart. Transferts forcés et burns privilégiés ont leur règle : s’ils entament le gel, ils mettent à jour le montant gelé et émettent Frozen avant l’événement de transfert.
Dans OpenZeppelin v5, ERC-1155 exécute _update avant le contrôle de réception, l’appel qui demande au contrat destinataire d’accepter les tokens. Un contrôle en fin de _update passe donc en premier.
ATTENTION
Quand j’ai lancé le test du niveau 4, pour cet article et pas sur le code d’un client, la version avec ce contrôle en passait deux sur trois, et la PR n° 2045 les trois, transferts vers soi compris.
Gardez donc le contrôle agrégé, et voyez le contrôle après débit comme un filet de sécurité.
Sources : issue n° 1814 des ERC, PR n° 2045 des ERC (ouverte au 7 oct. 2026).
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Où en était le correctif au 7 octobre 2026 : ouvert, non fusionné, sans revue.
- Pourquoi un contrôle après le débit peut compléter le correctif sans le remplacer.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Vous refusez tout batch qui répète un id. L’astuce du 40 + 40 est-elle bloquée, et à quel prix ?
Bloquée : chaque élément est alors le total de son id. Le prix, c’est de refuser des batchs que l’ERC-1155 autorise.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.