Binance Square
TokenToolHub
179 Publications

TokenToolHub

On-chain intelligence for tokens, wallets, transactions and smart contracts. Built by Wisdom Uche Ijika.
1 Suivis
1 Abonnés
3 J’aime
Publications
·
--
Les signatures obsolètes doivent être revérifiéesLes signatures des portefeuilles de contrats intelligents ne restent pas toujours valides indéfiniment. Avec ERC-1271, un contrat de portefeuille détermine si une signature est valide en fonction de son code, de son stockage et de ses règles actuels. Une signature peut être validée au moment de sa création, puis échouer par la suite parce qu’un signataire a été supprimé, que le seuil d’un portefeuille multisignature a changé, qu’une preuve de Merkle est devenue obsolète, que la signature a expiré ou que l’implémentation du portefeuille a changé. C’est important pour les ordres hors chaîne, les intentions de place de marché et d’autres processus dans lesquels une signature peut être créée bien avant le règlement. Il se peut que l’utilisateur soit hors ligne lorsque l’application tente enfin de l’utiliser. Considérer les octets d’origine comme valides en permanence peut entraîner l’échec du règlement ou conduire à des hypothèses dangereuses.

Les signatures obsolètes doivent être revérifiées

Les signatures des portefeuilles de contrats intelligents ne restent pas toujours valides indéfiniment.
Avec ERC-1271, un contrat de portefeuille détermine si une signature est valide en fonction de son code, de son stockage et de ses règles actuels. Une signature peut être validée au moment de sa création, puis échouer par la suite parce qu’un signataire a été supprimé, que le seuil d’un portefeuille multisignature a changé, qu’une preuve de Merkle est devenue obsolète, que la signature a expiré ou que l’implémentation du portefeuille a changé.
C’est important pour les ordres hors chaîne, les intentions de place de marché et d’autres processus dans lesquels une signature peut être créée bien avant le règlement. Il se peut que l’utilisateur soit hors ligne lorsque l’application tente enfin de l’utiliser. Considérer les octets d’origine comme valides en permanence peut entraîner l’échec du règlement ou conduire à des hypothèses dangereuses.
Risques liés à la récupération des portefeuilles intelligentsLa feuille de route d’Ethereum en matière d’abstraction de compte oriente les portefeuilles vers une sécurité programmable. La récupération en est l’un des principaux avantages, mais elle crée aussi une nouvelle surface d’autorité que les utilisateurs et les développeurs doivent comprendre. ERC-7947 propose une interface de récupération commune pour les comptes intelligents. Un compte compatible peut enregistrer un ou plusieurs fournisseurs de récupération, stocker des engagements propres à chaque fournisseur, puis soumettre une preuve autorisant une modification du sujet ayant accès au compte. Cette flexibilité est utile. Un fournisseur peut vérifier une preuve à divulgation nulle de connaissance. Un autre peut recourir à une signature, à un processus multifacteur ou à une autre méthode de récupération. Un portefeuille peut prendre en charge plusieurs fournisseurs au lieu de dépendre d’un seul service centralisé.

Risques liés à la récupération des portefeuilles intelligents

La feuille de route d’Ethereum en matière d’abstraction de compte oriente les portefeuilles vers une sécurité programmable. La récupération en est l’un des principaux avantages, mais elle crée aussi une nouvelle surface d’autorité que les utilisateurs et les développeurs doivent comprendre.
ERC-7947 propose une interface de récupération commune pour les comptes intelligents. Un compte compatible peut enregistrer un ou plusieurs fournisseurs de récupération, stocker des engagements propres à chaque fournisseur, puis soumettre une preuve autorisant une modification du sujet ayant accès au compte.
Cette flexibilité est utile. Un fournisseur peut vérifier une preuve à divulgation nulle de connaissance. Un autre peut recourir à une signature, à un processus multifacteur ou à une autre méthode de récupération. Un portefeuille peut prendre en charge plusieurs fournisseurs au lieu de dépendre d’un seul service centralisé.
La blockchain a besoin d’une crypto-agilitéLa sécurité blockchain post-quantique n’est pas un simple remplacement d’algorithme en un clic. Il s’agit d’une migration coordonnée à travers tous les endroits qui autorisent une valeur ou prouvent un état. La surface évidente est la signature du portefeuille, mais ce n’est qu’un début. Les clés des validateurs, les comités de pont, les signataires d’oracle, les multisigs du DAO, les séquenceurs de rollup, les portefeuilles matériels, les HSM de custody et les smart contracts à longue durée peuvent tous dépendre de la cryptographie classique. Une chaîne peut renforcer sa couche de base pendant qu’un ancien pont ou un ensemble de signataires reste exposé.

La blockchain a besoin d’une crypto-agilité

La sécurité blockchain post-quantique n’est pas un simple remplacement d’algorithme en un clic. Il s’agit d’une migration coordonnée à travers tous les endroits qui autorisent une valeur ou prouvent un état.
La surface évidente est la signature du portefeuille, mais ce n’est qu’un début. Les clés des validateurs, les comités de pont, les signataires d’oracle, les multisigs du DAO, les séquenceurs de rollup, les portefeuilles matériels, les HSM de custody et les smart contracts à longue durée peuvent tous dépendre de la cryptographie classique. Une chaîne peut renforcer sa couche de base pendant qu’un ancien pont ou un ensemble de signataires reste exposé.
Le risque quantique sans le sensationnalismeL’informatique quantique appartient à une planification sérieuse de la sécurité en matière de crypto, mais pas à des publications guidées par la panique. Aucun ordinateur quantique ne peut aujourd’hui briser la cryptographie d’Ethereum. La raison pour laquelle le sujet compte maintenant, c’est que les grandes migrations cryptographiques prennent des années. Les portefeuilles, les validateurs, les rollups, les ponts et les systèmes de conservation ne peuvent pas remplacer leurs hypothèses de sécurité sans risque du jour au lendemain. Le domaine le plus exposé est la cryptographie à clé publique. L’algorithme de Shor pourrait, à terme, affaiblir largement les systèmes de signature utilisés comme ECDSA et BLS si des ordinateurs quantiques tolérants aux fautes suffisamment puissants deviennent disponibles. Les fonctions de hachage sont plus robustes, bien que l’algorithme de Grover puisse réduire leur marge de sécurité effective.

Le risque quantique sans le sensationnalisme

L’informatique quantique appartient à une planification sérieuse de la sécurité en matière de crypto, mais pas à des publications guidées par la panique.
Aucun ordinateur quantique ne peut aujourd’hui briser la cryptographie d’Ethereum. La raison pour laquelle le sujet compte maintenant, c’est que les grandes migrations cryptographiques prennent des années. Les portefeuilles, les validateurs, les rollups, les ponts et les systèmes de conservation ne peuvent pas remplacer leurs hypothèses de sécurité sans risque du jour au lendemain.
Le domaine le plus exposé est la cryptographie à clé publique. L’algorithme de Shor pourrait, à terme, affaiblir largement les systèmes de signature utilisés comme ECDSA et BLS si des ordinateurs quantiques tolérants aux fautes suffisamment puissants deviennent disponibles. Les fonctions de hachage sont plus robustes, bien que l’algorithme de Grover puisse réduire leur marge de sécurité effective.
L’ERC-7683 n’est pas un sceau de sécuritéL’ERC-7683 est conçu pour réduire la fragmentation entre les protocoles d’intention inter-chaînes en offrant aux solveurs une manière commune de comprendre les ordres. Le brouillon actuel est centré sur le résolveur. Un protocole peut conserver sa propre charge utile, son mécanisme d’autorisation, son modèle d’enchères et de règlement, tout en publiant un résolveur qui traduit l’ordre en étapes, variables, paiements et hypothèses explicites qu’un solveur peut évaluer. Cela diffère de nombreuses anciennes explications relatives à l’ERC-7683. Les premiers brouillons décrivaient des structures et des interfaces universelles telles que GaslessCrossChainOrder, IOriginSettler, IDestinationSettler, open, openFor et fill. Ces idées restent un contexte historique utile, mais elles ne constituent pas la frontière normative actuelle.

L’ERC-7683 n’est pas un sceau de sécurité

L’ERC-7683 est conçu pour réduire la fragmentation entre les protocoles d’intention inter-chaînes en offrant aux solveurs une manière commune de comprendre les ordres.
Le brouillon actuel est centré sur le résolveur. Un protocole peut conserver sa propre charge utile, son mécanisme d’autorisation, son modèle d’enchères et de règlement, tout en publiant un résolveur qui traduit l’ordre en étapes, variables, paiements et hypothèses explicites qu’un solveur peut évaluer.
Cela diffère de nombreuses anciennes explications relatives à l’ERC-7683. Les premiers brouillons décrivaient des structures et des interfaces universelles telles que GaslessCrossChainOrder, IOriginSettler, IDestinationSettler, open, openFor et fill. Ces idées restent un contexte historique utile, mais elles ne constituent pas la frontière normative actuelle.
Les intentions inter-chaînes nécessitent des contrôlesLes intentions inter-chaînes peuvent rendre une expérience multi-chaînes fragmentée bien plus simple. Au lieu de choisir manuellement chaque pont, routeur, échange et action de destination, un utilisateur décrit le résultat souhaité. Des solveurs se disputent ensuite l’exécution de cette intention. Cette interface améliorée est utile, mais elle supprime pas le risque inter-chaînes. Elle déplace simplement là où le risque se situe. Le cadre Open Intents fournit une infrastructure modulaire pour exprimer, découvrir, résoudre, valider et régler des intentions inter-chaînes. Une commande typique peut définir l’actif d’entrée et la chaîne, la sortie et la destination souhaitées, le destinataire, une échéance ainsi que des limites économiques.

Les intentions inter-chaînes nécessitent des contrôles

Les intentions inter-chaînes peuvent rendre une expérience multi-chaînes fragmentée bien plus simple. Au lieu de choisir manuellement chaque pont, routeur, échange et action de destination, un utilisateur décrit le résultat souhaité. Des solveurs se disputent ensuite l’exécution de cette intention.
Cette interface améliorée est utile, mais elle supprime pas le risque inter-chaînes. Elle déplace simplement là où le risque se situe.
Le cadre Open Intents fournit une infrastructure modulaire pour exprimer, découvrir, résoudre, valider et régler des intentions inter-chaînes. Une commande typique peut définir l’actif d’entrée et la chaîne, la sortie et la destination souhaitées, le destinataire, une échéance ainsi que des limites économiques.
Le risque caché dans les données RWALes actifs tokenisés peuvent évoluer sur la chaîne, mais la plupart des faits qui leur confèrent de la valeur vivent encore ailleurs. Une blockchain ne peut pas, de manière indépendante, confirmer si un dépositaire détient toujours un titre, si un bien a été vendu, si un emprunteur a fait défaut, si une réserve a été grevée ou si l’administrateur d’un fonds a révisé sa valeur liquidative. Les contrats intelligents ont besoin de systèmes externes pour faire entrer ces faits sur la chaîne. C’est pourquoi le risque lié aux oracles RWA est plus large que la manipulation des prix. Un oracle peut publier une valeur correctement, tandis que la source elle-même est obsolète, incomplète ou basée sur la mauvaise définition économique. Un flux de prix de marché n’est pas la même chose que la valeur liquidative (NAV) d’un fonds. Un solde de réserve n’est pas une preuve de solvabilité. Le fait qu’un actif existe ne prouve pas que les détenteurs de tokens disposent d’une créance opposable à ce titre.

Le risque caché dans les données RWA

Les actifs tokenisés peuvent évoluer sur la chaîne, mais la plupart des faits qui leur confèrent de la valeur vivent encore ailleurs.
Une blockchain ne peut pas, de manière indépendante, confirmer si un dépositaire détient toujours un titre, si un bien a été vendu, si un emprunteur a fait défaut, si une réserve a été grevée ou si l’administrateur d’un fonds a révisé sa valeur liquidative. Les contrats intelligents ont besoin de systèmes externes pour faire entrer ces faits sur la chaîne.
C’est pourquoi le risque lié aux oracles RWA est plus large que la manipulation des prix.
Un oracle peut publier une valeur correctement, tandis que la source elle-même est obsolète, incomplète ou basée sur la mauvaise définition économique. Un flux de prix de marché n’est pas la même chose que la valeur liquidative (NAV) d’un fonds. Un solde de réserve n’est pas une preuve de solvabilité. Le fait qu’un actif existe ne prouve pas que les détenteurs de tokens disposent d’une créance opposable à ce titre.
Les actifs tokenisés ont besoin de vrais droitsLa tokenisation des actifs du monde réel passe des présentations à une infrastructure de production. La DTCC a indiqué avoir réalisé des transactions en conditions réelles avec des titres détenus par la DTC tokenisés en juillet et a précisé que cette étape visait à soutenir un lancement en octobre 2026 de son service de tokenisation. C’est significatif, mais la leçon la plus importante n’est pas que chaque actif deviendra soudainement liquide ou sûr dès qu’il apparaît sur une blockchain. Un token n’est que la représentation numérique. La vraie valeur dépend des droits qui se trouvent derrière.

Les actifs tokenisés ont besoin de vrais droits

La tokenisation des actifs du monde réel passe des présentations à une infrastructure de production. La DTCC a indiqué avoir réalisé des transactions en conditions réelles avec des titres détenus par la DTC tokenisés en juillet et a précisé que cette étape visait à soutenir un lancement en octobre 2026 de son service de tokenisation.
C’est significatif, mais la leçon la plus importante n’est pas que chaque actif deviendra soudainement liquide ou sûr dès qu’il apparaît sur une blockchain.
Un token n’est que la représentation numérique. La vraie valeur dépend des droits qui se trouvent derrière.
Un seul portefeuille, trop de risquePar commodité, un seul portefeuille crypto se transforme souvent en compte de trading, en atelier DeFi, en adresse d’airdrop et en vault de long terme en même temps. Cette structure semble simple jusqu’à ce qu’une approbation malveillante, une fausse interface ou une session compromise atteigne tout. Une stratégie multi-portefeuilles réduit ce rayon d’explosion en attribuant des activités différentes à différents portefeuilles. Le modèle de base est pragmatique : un portefeuille pour le trading, un pour la DeFi et un pour les avoirs de long terme. Le portefeuille de trading est conçu pour la rapidité. Il peut se connecter à des exchanges, des bridges, des tableaux de bord et des outils d’exécution, donc il signe plus souvent et subit davantage de bruit opérationnel. Il doit détenir du capital de travail plutôt que la partie la plus profonde d’un portefeuille.

Un seul portefeuille, trop de risque

Par commodité, un seul portefeuille crypto se transforme souvent en compte de trading, en atelier DeFi, en adresse d’airdrop et en vault de long terme en même temps. Cette structure semble simple jusqu’à ce qu’une approbation malveillante, une fausse interface ou une session compromise atteigne tout.
Une stratégie multi-portefeuilles réduit ce rayon d’explosion en attribuant des activités différentes à différents portefeuilles. Le modèle de base est pragmatique : un portefeuille pour le trading, un pour la DeFi et un pour les avoirs de long terme.
Le portefeuille de trading est conçu pour la rapidité. Il peut se connecter à des exchanges, des bridges, des tableaux de bord et des outils d’exécution, donc il signe plus souvent et subit davantage de bruit opérationnel. Il doit détenir du capital de travail plutôt que la partie la plus profonde d’un portefeuille.
Les portefeuilles intégrés ont besoin de limitesL’infrastructure des portefeuilles s’oriente vers un objectif utile mais exigeant : rendre les produits en auto-garde familiers, sans retirer discrètement le contrôle à l’utilisateur. C’est pourquoi l’annonce du 28 septembre de Tether et Shiga est importante. Leurs produits prévus, reposant sur WDK et destinés à l’Afrique et au Conseil de coopération du Golfe, associent intégration accessible, prise en charge de plusieurs actifs et contrôle des clés et des fonds. C’est un exemple opportun de la direction explorée par les concepteurs de portefeuilles, mais il ne faut pas y voir la preuve que tous les portefeuilles intégrés sont en auto-garde ou aussi sécurisés les uns que les autres.

Les portefeuilles intégrés ont besoin de limites

L’infrastructure des portefeuilles s’oriente vers un objectif utile mais exigeant : rendre les produits en auto-garde familiers, sans retirer discrètement le contrôle à l’utilisateur.
C’est pourquoi l’annonce du 28 septembre de Tether et Shiga est importante. Leurs produits prévus, reposant sur WDK et destinés à l’Afrique et au Conseil de coopération du Golfe, associent intégration accessible, prise en charge de plusieurs actifs et contrôle des clés et des fonds. C’est un exemple opportun de la direction explorée par les concepteurs de portefeuilles, mais il ne faut pas y voir la preuve que tous les portefeuilles intégrés sont en auto-garde ou aussi sécurisés les uns que les autres.
Comment fonctionnent les listes d’accès aux blocsLes blocs Ethereum contiennent des transactions ordonnées, mais l’état touché par ces transactions est souvent découvert seulement pendant l’exécution de celles-ci dans la machine virtuelle EVM. Un échange peut commencer sur un routeur, appeler un pool, lire les soldes de jetons, entrer dans la logique de transfert, invoquer des hooks et atteindre des implémentations de proxy dont l’accès au stockage dépend de l’état actuel. Les clients d’exécution peuvent optimiser de manière agressive, mais ils découvrent traditionnellement beaucoup de comptes et d’emplacements de stockage puisque le travail est déjà en cours. La norme EIP-7928 modifie le moment où cette information devient disponible.

Comment fonctionnent les listes d’accès aux blocs

Les blocs Ethereum contiennent des transactions ordonnées, mais l’état touché par ces transactions est souvent découvert seulement pendant l’exécution de celles-ci dans la machine virtuelle EVM.
Un échange peut commencer sur un routeur, appeler un pool, lire les soldes de jetons, entrer dans la logique de transfert, invoquer des hooks et atteindre des implémentations de proxy dont l’accès au stockage dépend de l’état actuel. Les clients d’exécution peuvent optimiser de manière agressive, mais ils découvrent traditionnellement beaucoup de comptes et d’emplacements de stockage puisque le travail est déjà en cours.
La norme EIP-7928 modifie le moment où cette information devient disponible.
Glamsterdam atteint SepoliaLa prochaine mise à niveau du protocole d’Ethereum est passée d’une fenêtre de feuille de route globale à une étape de testnet public spécifique. La Fondation Ethereum a programmé l’activation de Glamsterdam sur Sepolia pour le 6 octobre 2026 à 13:53:36 UTC. L’annonce couvre Sepolia uniquement. Les dates pour Hoodi et pour le mainnet n’ont pas encore été décidées. Glamsterdam combine Amsterdam sur la couche d’exécution avec Gloas sur la couche de consensus. Ses changements sont reliés par un objectif unique : augmenter la capacité d’Ethereum tout en gardant la construction des blocs, la propagation, la validation et la croissance de l’état gérables.

Glamsterdam atteint Sepolia

La prochaine mise à niveau du protocole d’Ethereum est passée d’une fenêtre de feuille de route globale à une étape de testnet public spécifique.
La Fondation Ethereum a programmé l’activation de Glamsterdam sur Sepolia pour le 6 octobre 2026 à 13:53:36 UTC. L’annonce couvre Sepolia uniquement. Les dates pour Hoodi et pour le mainnet n’ont pas encore été décidées.
Glamsterdam combine Amsterdam sur la couche d’exécution avec Gloas sur la couche de consensus. Ses changements sont reliés par un objectif unique : augmenter la capacité d’Ethereum tout en gardant la construction des blocs, la propagation, la validation et la croissance de l’état gérables.
Explication de la divulgation sélectiveL’adoption de la blockchain par les institutions crée une tension difficile. Les organisations doivent prouver qu’une transaction est autorisée et conforme aux politiques, mais elles peuvent aussi avoir besoin de protéger les contreparties, les circuits de trésorerie, les stratégies de négociation, les conditions commerciales et les règles internes de risque. Publier tout n’est pas la même chose qu’être responsable. La divulgation sélective offre une approche plus précise. Au lieu de révéler l’identité complète ou l’historique complet des transactions, un utilisateur ou une institution prouve un fait étroit requis pour une décision spécifique. Ce fait peut être que l’un des participants a réussi un processus de vérification approuvé, qu’il est autorisé à utiliser un service, qu’il remplit une condition de compétence territoriale ou qu’il dispose de la bonne autorité de signature.

Explication de la divulgation sélective

L’adoption de la blockchain par les institutions crée une tension difficile. Les organisations doivent prouver qu’une transaction est autorisée et conforme aux politiques, mais elles peuvent aussi avoir besoin de protéger les contreparties, les circuits de trésorerie, les stratégies de négociation, les conditions commerciales et les règles internes de risque.
Publier tout n’est pas la même chose qu’être responsable.
La divulgation sélective offre une approche plus précise. Au lieu de révéler l’identité complète ou l’historique complet des transactions, un utilisateur ou une institution prouve un fait étroit requis pour une décision spécifique. Ce fait peut être que l’un des participants a réussi un processus de vérification approuvé, qu’il est autorisé à utiliser un service, qu’il remplit une condition de compétence territoriale ou qu’il dispose de la bonne autorité de signature.
La confidentialité a besoin de meilleures frontièresLa confidentialité et la conformité sont souvent présentées comme des opposés. Ce cadrage est trop simpliste. Un bon système de confidentialité n’a pas besoin d’éliminer la responsabilisation, et un système de conformité sérieux n’a pas besoin d’exposer chaque action à chaque observateur. La question de conception la plus pragmatique est celle de savoir où doivent se situer les contrôles. Les réseaux axés sur la confidentialité rendent le pistage conventionnel des transactions difficile, car ils peuvent masquer les expéditeurs, les destinataires, les montants ou les liens entre les transactions. Cela crée un défi réel pour les échanges, les prestataires de paiement et les institutions réglementées. Pourtant, la réponse ne peut pas être de supposer que l’analyse de la blockchain reconstituera toujours une activité que le protocole était conçu pour dissimuler.

La confidentialité a besoin de meilleures frontières

La confidentialité et la conformité sont souvent présentées comme des opposés. Ce cadrage est trop simpliste. Un bon système de confidentialité n’a pas besoin d’éliminer la responsabilisation, et un système de conformité sérieux n’a pas besoin d’exposer chaque action à chaque observateur.
La question de conception la plus pragmatique est celle de savoir où doivent se situer les contrôles.
Les réseaux axés sur la confidentialité rendent le pistage conventionnel des transactions difficile, car ils peuvent masquer les expéditeurs, les destinataires, les montants ou les liens entre les transactions. Cela crée un défi réel pour les échanges, les prestataires de paiement et les institutions réglementées. Pourtant, la réponse ne peut pas être de supposer que l’analyse de la blockchain reconstituera toujours une activité que le protocole était conçu pour dissimuler.
La conformité est une infrastructure de donnéesLa conformité crypto est souvent présentée comme un ensemble de politiques. En pratique, une politique ne peut pas enquêter sur une alerte, rapprocher un transfert de portefeuille, expliquer une décision ou prouver quel contrôle était en activité à un moment donné. Une conformité sérieuse est une infrastructure de données. Une plateforme d’échange ou de garde (custodial) doit connecter plusieurs couches de preuves : 1. Onboarding d’identité et registres de bénéficiaires effectifs 2. Signaux liés aux appareils, aux comptes et au comportement 3. Adresses de dépôt et de retrait 4. Attribution blockchain et contrôle des sanctions

La conformité est une infrastructure de données

La conformité crypto est souvent présentée comme un ensemble de politiques. En pratique, une politique ne peut pas enquêter sur une alerte, rapprocher un transfert de portefeuille, expliquer une décision ou prouver quel contrôle était en activité à un moment donné.
Une conformité sérieuse est une infrastructure de données.
Une plateforme d’échange ou de garde (custodial) doit connecter plusieurs couches de preuves :
1. Onboarding d’identité et registres de bénéficiaires effectifs
2. Signaux liés aux appareils, aux comptes et au comportement
3. Adresses de dépôt et de retrait
4. Attribution blockchain et contrôle des sanctions
La révision MiCA étend la cartographieLes recommandations de l’ESMA du 30 septembre pour la révision du règlement MiCA montrent à quelle vitesse la supervision des crypto-actifs s’étend au-delà du périmètre initial de l’échange et de la conservation. La publication traite de la promotion par des influenceurs et des tiers, de la transparence des coûts, du staking, du prêt, de l’emprunt, des stablecoins non conformes, de la classification des jetons et de l’accès aux protocoles DeFi. Elle demande aussi des critères plus clairs pour décider quand une activité est réellement décentralisée. Le statut juridique compte. Il s’agit de recommandations soumises dans le cadre du processus de révision de la Commission européenne, et non de règles finales. Néanmoins, elles montrent les questions que les autorités de régulation posent et les éléments factuels produit que les équipes doivent documenter dès maintenant.

La révision MiCA étend la cartographie

Les recommandations de l’ESMA du 30 septembre pour la révision du règlement MiCA montrent à quelle vitesse la supervision des crypto-actifs s’étend au-delà du périmètre initial de l’échange et de la conservation.
La publication traite de la promotion par des influenceurs et des tiers, de la transparence des coûts, du staking, du prêt, de l’emprunt, des stablecoins non conformes, de la classification des jetons et de l’accès aux protocoles DeFi. Elle demande aussi des critères plus clairs pour décider quand une activité est réellement décentralisée.
Le statut juridique compte. Il s’agit de recommandations soumises dans le cadre du processus de révision de la Commission européenne, et non de règles finales. Néanmoins, elles montrent les questions que les autorités de régulation posent et les éléments factuels produit que les équipes doivent documenter dès maintenant.
La M C Ne Remplace Pas La PolitiqueLe calcul multipartite peut supprimer une clé privée complète en tant que point de défaillance unique. Plusieurs participants détiennent des parts distinctes et coopèrent afin de produire une signature valide uniquement lorsque le seuil est atteint. Cela est précieux, mais le seuil ne constitue pas l’intégralité du modèle de sécurité. La question opérationnelle est de savoir ce qui fait que ces parts participent. Si un service interne peut créer une requête de signature sans passer les contrôles attendus, ou si les signataires acceptent une instruction vague qui n’est pas liée à la transaction exacte, le système peut produire une signature cryptographiquement valide pour une action non autorisée.

La M C Ne Remplace Pas La Politique

Le calcul multipartite peut supprimer une clé privée complète en tant que point de défaillance unique. Plusieurs participants détiennent des parts distinctes et coopèrent afin de produire une signature valide uniquement lorsque le seuil est atteint.
Cela est précieux, mais le seuil ne constitue pas l’intégralité du modèle de sécurité.
La question opérationnelle est de savoir ce qui fait que ces parts participent. Si un service interne peut créer une requête de signature sans passer les contrôles attendus, ou si les signataires acceptent une instruction vague qui n’est pas liée à la transaction exacte, le système peut produire une signature cryptographiquement valide pour une action non autorisée.
Risque des portefeuilles chauds et froidsUne clé privée n’est qu’une partie d’un système de sécurité d’un portefeuille. Les incidents récents sur des plateformes d’échange ont renforcé une leçon difficile : les fonds peuvent bouger même lorsque les attaquants n’exfiltrent pas eux-mêmes les clés privées. Les identifiants, les instructions de retrait, les systèmes de politiques et l’accès au backend peuvent tous devenir une partie du chemin d’attaque. C’est pourquoi les portefeuilles chauds, tièdes, froids et détenus par un tiers doivent être traités comme des modèles d’exposition distincts. Un portefeuille chaud est disponible pour une activité fréquente. Il prend en charge des transferts rapides et des opérations quotidiennes, mais ses services en ligne, ses identifiants et son processus de signature créent une surface d’attaque plus large.

Risque des portefeuilles chauds et froids

Une clé privée n’est qu’une partie d’un système de sécurité d’un portefeuille. Les incidents récents sur des plateformes d’échange ont renforcé une leçon difficile : les fonds peuvent bouger même lorsque les attaquants n’exfiltrent pas eux-mêmes les clés privées. Les identifiants, les instructions de retrait, les systèmes de politiques et l’accès au backend peuvent tous devenir une partie du chemin d’attaque.
C’est pourquoi les portefeuilles chauds, tièdes, froids et détenus par un tiers doivent être traités comme des modèles d’exposition distincts.
Un portefeuille chaud est disponible pour une activité fréquente. Il prend en charge des transferts rapides et des opérations quotidiennes, mais ses services en ligne, ses identifiants et son processus de signature créent une surface d’attaque plus large.
Les appels par lots ont besoin de meilleurs contrôlesERC-5792 offre aux applications une manière standard de demander à un portefeuille de traiter plusieurs appels on-chain ordonnés via wallet_sendCalls. Cela peut réduire les invites répétitives et faciliter l’exécution de flux tels que approuver, échanger et miser. La commodité n’élimine pas le risque. L’application doit vérifier les capacités du portefeuille pour la chaîne demandée, simuler l’ensemble du lot et conserver l’identifiant du lot jusqu’à atteindre un statut terminal. L’atomicité nécessite aussi une prise en charge attentive. Un portefeuille peut prendre en charge un lot atomique, refuser la capacité requise ou utiliser une voie d’exécution différente. Les applications ne doivent pas remplacer silencieusement un flux atomique requis par plusieurs transactions indépendantes.

Les appels par lots ont besoin de meilleurs contrôles

ERC-5792 offre aux applications une manière standard de demander à un portefeuille de traiter plusieurs appels on-chain ordonnés via wallet_sendCalls. Cela peut réduire les invites répétitives et faciliter l’exécution de flux tels que approuver, échanger et miser.
La commodité n’élimine pas le risque. L’application doit vérifier les capacités du portefeuille pour la chaîne demandée, simuler l’ensemble du lot et conserver l’identifiant du lot jusqu’à atteindre un statut terminal.
L’atomicité nécessite aussi une prise en charge attentive. Un portefeuille peut prendre en charge un lot atomique, refuser la capacité requise ou utiliser une voie d’exécution différente. Les applications ne doivent pas remplacer silencieusement un flux atomique requis par plusieurs transactions indépendantes.
EIP-8141 Est Toujours un ProjetEIP-8141 propose une manière différente de structurer les transactions Ethereum. Au lieu de traiter la validation, le paiement du gaz et l’exécution comme un flux fixe unique, une transaction-cadre peut contenir des cadres programmables distincts pour ces responsabilités. Cette conception pourrait prendre en charge le parrainage natif du gaz, la rotation des clés, des schémas de signature alternatifs et le regroupement atomique. Elle introduit également un problème plus difficile de sécurité du portefeuille. Un utilisateur peut autoriser une séquence impliquant un expéditeur, un payeur distinct, une logique de validation et plusieurs appels d’exécution.

EIP-8141 Est Toujours un Projet

EIP-8141 propose une manière différente de structurer les transactions Ethereum. Au lieu de traiter la validation, le paiement du gaz et l’exécution comme un flux fixe unique, une transaction-cadre peut contenir des cadres programmables distincts pour ces responsabilités.
Cette conception pourrait prendre en charge le parrainage natif du gaz, la rotation des clés, des schémas de signature alternatifs et le regroupement atomique. Elle introduit également un problème plus difficile de sécurité du portefeuille. Un utilisateur peut autoriser une séquence impliquant un expéditeur, un payeur distinct, une logique de validation et plusieurs appels d’exécution.
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Plan du site
Préférences de cookies
CGU de la plateforme