Tard dans la nuit du dimanche 5 juin 2022, de nombreuses activités suspectes ont commencé à être signalées sur le réseau principal d’Elrond, notamment d’importants transferts d’EGLD et d’importants échanges sur la bourse Maiar. L’équipe s’est rapidement réunie pour enquêter sur cette activité, dans ce qui allait devenir une nuit longue et cruciale. Maintenant que la poussière est retombée, les vulnérabilités corrigées, la plupart des fonds manquants récupérés et tous les systèmes fonctionnent, il vaut la peine de regarder en arrière et de retracer ce qui s’est réellement passé au cours des 5 derniers jours.
Que s’est-il réellement passé ?
Tout commence par le déploiement d’une nouvelle fonction VM sur le réseau principal. Le point de terminaison en question est appelé « exécuter sur le contexte de destination par l’appelant », « executeOnDestContextByCaller » comme le voient les contrats. Il est très similaire au plus courant « exécuter sur le contexte de destination », que nous utilisons pour les interactions synchrones sur le même fragment entre les contrats , mais avec une mise en garde : l’action se produit comme si elle était directement envoyée par l’appelant d’origine de la transaction.
Décomposons-le étape par étape : disons que l’utilisateur A appelle le contrat B, qui à son tour appelle le contrat C en utilisant « executeOnDestContextByCaller ». Le contrat C reçoit une transaction de B qui semble avoir été envoyée directement par l’utilisateur A. Pourquoi voudrions-nous cette fonctionnalité ? Disons par exemple que l’utilisateur A essaie de créer un NFT pour lui-même en utilisant un contrat de frappeur NFT (contrat B), mais veut être le créateur du NFT. Normalement, le contrat B est le créateur, car il appelle la fonction NFT mint elle-même, mais en utilisant « executeOnDestContextByCaller », le NFT semble avoir été créé directement par l’utilisateur A.
Tout va bien jusqu’à présent. La semaine dernière, un petit groupe de développeurs de la communauté tente de construire un contrat de loterie capable de résister à toutes sortes d’exploits. Le problème est que les utilisateurs de cette loterie peuvent en principe annuler toute transaction où ils ne gagnent pas en utilisant un contrat intelligent, gagnant effectivement 100% du temps (il s’agit d’un défaut plus large dans cette conception de contrat de loterie particulière, mais cette discussion est hors du cadre de cet article). Le contrat est corrigé pour ne pas autoriser les appels provenant d’autres contrats, mais quelqu’un trouve une solution de contournement en utilisant « executeOnDestContextByCaller ». Maintenant, le contrat de loterie peut être amené à croire qu’un portefeuille ordinaire a envoyé une transaction qui provenait vraiment d’un autre contrat.
Une vague d’activités s’ensuit sur la chaîne de développement officielle, alors que la communauté joue avec cette fonction, jusqu’à ce que quelqu’un remarque quelque chose d’inquiétant. Le contrat B peut également transférer des fonds au nom de l’appelant (utilisateur A) en utilisant cette fonction. Un utilisateur pourrait être amené à envoyer une transaction à un contrat malveillant, sans fonds, pour voir son portefeuille vidé par ledit contrat.
Pour s’assurer de ne pas voir une vague d’escroqueries utilisant cet exploit, l’équipe d’Elrond publie rapidement un correctif, interdisant tout transfert de valeur via « executeOnDestContextByCaller ». La mise à niveau du réseau est un processus complexe et sensible, donc pour le faire correctement, il faut normalement au moins une semaine pour qu’un correctif atteigne le réseau principal. La raison en est qu’il faut 2 à 4 jours pour valider le correctif, plus plusieurs jours pour le proposer et donner aux validateurs suffisamment de temps pour l’adopter et le mettre à niveau. Le patch est censé entrer en vigueur le lundi 8, au changement d’époque. À ce stade, le temps restant est assez court pour qu’un escroc régulier construise et déploie une dApp malveillante, et les utilisateurs pourraient toujours être avertis de rester à l’écart, de sorte que le danger semble minime.
Mais voyez, si c’était juste que nous ne serions pas ici pour discuter de cela.
Le week-end venu, la communauté continue de jouer avec la fonctionnalité et tombe accidentellement sur quelque chose de plus menaçant. Le sharding est sans doute le plus gros problème concernant Elrond, et pour que le sharding soit vraiment une chose, vous avez besoin de contrats pour communiquer correctement entre les fragments. Les appels synchrones de type EVM ne suffisent pas pour cela, donc les contrats sur Elrond envoient la plupart du temps des appels dits asynchrones à d’autres contrats et attendent un rappel pour confirmer si les choses se sont bien passées ou non de l’autre côté. Les appels asynchrones fonctionnent de manière similaire dans la même partition, dans ce cas, le rappel intervient immédiatement après la fin de l’appel asynchrone. La communauté a découvert que vous pouviez appeler « executeOnDestContextByCaller » dans un rappel, auquel cas un contrat malveillant pourrait effectuer des actions non au nom de son appelant,
C’est vrai, en utilisant « executeOnDestContextByCaller » dans un rappel asynchrone, un attaquant est capable de vider EGLD de n’importe quel contrat qu’il veut, et il n’y a rien que le contrat de la victime puisse faire à ce sujet.
Il y a quelques mises en garde : l’attaque ne fonctionne que si le contrat malveillant et la cible se trouvent dans le même fragment, de sorte que tous les EGLD jalonnés sont hors de portée, car ils résident sur la métachaîne. Les jetons ESDT sont également sûrs, car pour les transférer, le contrat malveillant doit appeler une fonction intégrée, comme « ESDTTransfer », ce que la VM interdit dans ce cas. Mais ce sont toutes les bonnes nouvelles.
De manière déconcertante, ces découvertes sont discutées assez nonchalamment sur la chaîne publique Elrond Developers pendant le week-end, sans soulever de problèmes de sécurité ou de sûreté. Étant donné qu’un correctif est connu pour arriver sur le réseau en 2 jours, peu d’attention est accordée à la divulgation responsable et à l’action immédiate.
L’attaque
L’attaquant encore inconnu choisit dimanche soir comme heure de l’attaque, moins de 36 heures avant la fermeture de la fenêtre d’opportunité.
Il (ou elle/ils ?) cible probablement le pot de miel EGLD le plus important : le contrat egld-esdt-swap. Il s’agit du contrat qui crée et échange Wrapped EGLD (WEGLD) vers et depuis EGLD. C’est un contrat très simple et sécurisé : tous les utilisateurs qui ont besoin de WEGLD doivent déposer le même montant d’EGLD dans ce contrat, de sorte que le montant d’EGLD stocké ici est égal à tous les WEGLD là-bas.
Il y a un de ces contrats d’échange déployé dans chacun des 3 fragments réguliers, l’attaquant les cible tous. Pour accéder aux fonds, il crée des portefeuilles dans tous les fragments et déploie une copie du contrat malveillant dans chacun.
L’un de ces contrats peut être trouvé ici:
https://explorer.elrond.com/accounts/erd1qqqqqqqqqqqqpgq8urd3mza45z6th63h52e00zpgvrc5zxll9cshfqmhg
Nous n’avons pas les sources originales, mais en principe, cela devait ressembler beaucoup à ceci :
À ~ 1 h EEST, l’attaque commence. Il envoie les transactions dont les rappels drainent EGLD des contrats de swap, comme suit :
- Sur le fragment 0 : 400 000 EGLD
- Sur le fragment 1 : 800 000 EGLD
- Sur le fragment 2 : 450 000 EGLD
Maintenant, les choses sont un peu plus compliquées que cela. Si la description technique de l’attaque ne vous intéresse pas, n’hésitez pas à sauter les quelques paragraphes suivants.
En fait, l’attaquant déploie un contrat supplémentaire en plus du contrat malveillant dans chaque fragment, vraisemblablement pour masquer les transactions ou le contrat malveillant. Cela porte le total à 6 contrats déployés. Il utilise également 2 portefeuilles différents dans chaque partition, un pour lancer l’appel et un pour sortir l’EGLD.
Les petits fonds initiaux pour l’attaque proviennent tous du portefeuille chaud Binance erd16x7le8dpkjsafgwjx0e5kw94evsqw039rwp42m2j9eesd88x8zzs75tzry.
Malheureusement, le transfert intra-shard qui draine les fonds n’est actuellement pas visible dans l’explorateur, mais une nouvelle mise à jour le rendra bientôt disponible. Cela semble avoir conduit à une certaine confusion dans la communauté quant à la manière dont l’attaquant a obtenu les fonds.
Maintenant, l’attaquant essaie d’une manière ou d’une autre de sortir ce trésor de la chaîne Elrond.
Son plan est d’utiliser le Maiar Exchange pour l’échanger contre quelque chose qui peut être relié à Ethereum. La première étape pour ce faire consiste à envelopper l’EGLD volé, qui, ironiquement, doit avoir lieu dans les contrats mêmes qu’il vient de pirater. Cette fois, il utilise correctement les fonctions des contrats, comme prévu, en renvoyant l’EGLD volé au contrat et en recevant un nouveau WEGLD à la place. Mais parce qu’il a utilisé EGLD volé pour ce faire, le WEGLD qu’il reçoit n’est plus correctement sauvegardé 1: 1 avec EGLD dans le pool, nous pouvons donc le considérer comme un «WEGLD piraté» qui se propagera désormais sur le réseau.
Il en convertit ensuite une grande partie en USDC dans le Maiar Exchange, mais le pool de liquidités, bien qu’important, ne fait pas le poids face à une somme aussi gargantuesque. Il plonge ainsi à lui seul le prix EGLD dans le pool de liquidités à environ 4 $, vendant son WEGLD piraté à perte énorme. Les robots d’arbitrage fonctionnant sur le LP à cette heure font de sérieux bénéfices, mais n’ont pas le volume pour faire remonter le prix avant que l’échange ne soit interrompu par l’équipe.
Il ne centralise pas les fonds volés dans un seul portefeuille, mais continuera à utiliser les deuxièmes portefeuilles de chaque fragment (voir dans le tableau) pour interagir avec le Maiar Exchange en parallèle. Il y a une limite de transaction de 200 000 $ sur le pont et pour une raison quelconque, il ne se contente pas de partager le montant lors de l’utilisation du pont, mais également lors de l’interaction avec l’échange. Il en résulte de très nombreuses interactions avec les pools de liquidités, trop nombreuses pour être énumérées ici, mais les lecteurs curieux peuvent les consulter dans l’explorateur :
Éclat 0 : https://explorer.elrond.com/accounts/erd16syfkds2faezhqa7pn5n8fyjkst70l5qefpmc0r960467snlgycq4ww0rt
Éclat 1 :
https://explorer.elrond.com/accounts/erd1cura2qq8skel5fsxrpxyysjkaw6durengtkencrezkw78y6y2zhscf854j
Éclat 2 :
https://explorer.elrond.com/accounts/erd1yrf9qeuqkcjeh5c4xn628mags7cse4r9ra2p2ggmlgfqq3l3v6pqxfu950
Voyant qu’il a fait chuter le prix EGLD dans le pool EGLD-USDC et qu’il vend à perte énorme, il convertit également une partie du montant en UTK, dont il relie également une partie à Ethereum.
Une note technique : les jetons ETHUSDC et ETHUTK que vous voyez dans les transactions sont des jetons intermédiaires utilisés par le pont. USDC et UTK, respectivement, doivent être convertis en eux avant de pouvoir être pontés.
Le montant total qu’il parvient à relier à Ethereum avant que le pont ne soit temporairement désactivé est d’environ 4 millions USDC et 1 million UTK. Un autre 1,4 million d’USDC est gelé dans le pont par l’équipe, avant que l’attaquant n’ait la possibilité de le retirer.
Toute cette activité sur le central et sur le pont commence bientôt à déclencher des alarmes, et l’équipe se rassemble rapidement pour enquêter sur l’incident.
L’attaque est contrée
La première priorité est de limiter au maximum les dégâts. L’échange, l’échange Wrapped EGLD et le pont sont immédiatement mis en pause. A noter que l’activité sur le pont ne peut être suspendue que dans des circonstances exceptionnelles, de vie ou de mort, et avec l’accord des relais de confiance du pont.
L’API publique est maintenue mais la fonction d’envoi est désactivée, de sorte qu’aucune transaction ne peut passer par elle. Cependant, l’attaquant ne s’appuie pas sur la passerelle publique et n’est donc pas découragé par cela.
Enfin, de nombreux ESDT ont une fonction de gel s’ils sont configurés à la frappe ou à la création. Notez que toutes les pièces stables, par exemple, ont cette fonction activée sur toutes les chaînes, pour des raisons de sécurité évidentes. En l’utilisant, l’équipe est en mesure de geler temporairement tous les transferts USDC et UTK. EGLD, en revanche, ne peut pas être gelé, l’attaquant est donc libre de le déplacer.
En attendant, l’équipe est également en contact avec tous les principaux échanges, faisant circuler une liste noire, pour empêcher l’attaquant d’y extraire l’EGLD. Il est également en pourparlers avec les forces de l’ordre pour lancer plusieurs enquêtes.
Vient ensuite la tâche principale de corriger la vulnérabilité dès que possible. Il est clair qu’attendre le patch régulier à 18h EEST est inacceptable compte tenu de la gravité de la situation. Un correctif d’urgence est prêt à 7 h 07 EEST et dans quelques minutes, des messages commencent à circuler sur les canaux de validation.
Étant donné que l’équipe ne contrôle actuellement qu’une minorité des nœuds de validation, la large participation de la communauté des validateurs, via un consensus approximatif et une gouvernance hors chaîne, est nécessaire et importante même pour une telle mise à jour de correctif d’urgence. Cela signifie communiquer le correctif, la proposition et l’adoption. En principe, plus de 66 % des nœuds sont nécessaires pour adopter un changement en toute sécurité, de sorte que la majorité des agences de jalonnement doivent être de la partie.
Il est décidé de réparer les choses sur place, à l’époque actuelle. Pour éviter toute complication lors de la mise à niveau, la communauté doit agir avec la plus grande rapidité. L’équipe a des plans d’urgence pour tout événement possible pendant la mise à niveau, mais c’est plus facile si cela n’arrive pas. Une fois qu’au moins ~67 % des nœuds ont été mis à niveau, tout danger potentiel est écarté.
Miraculeusement, à 7 h EEST, une grande partie de la communauté des validateurs est réveillée et prête à l’action. L’équipe effectue les tests finaux pour la construction et 20 minutes plus tard, la mise à niveau commence. Il faut environ une demi-heure pour que la majeure partie du réseau exécute la nouvelle version. Tout se passe bien et sans incident ni temps d’arrêt pour le réseau, au grand soulagement de tous. La réponse des validateurs est irréprochable. Les contrats sont à nouveau en sécurité.
Conséquences immédiates
Il est tôt lundi matin, la crise immédiate est évitée, mais les fonds manquent toujours et l’équipe ne sait pas si le correctif du matin est une solution complète, ou s’il pourrait y avoir plus de vulnérabilités cachées.
Une partie de l’équipe profite de la journée pour tester d’autres scénarios et réfléchir à d’autres exploits potentiels. Bien qu’aucune autre vulnérabilité ne semble se cacher dans le code, l’équipe se sent toujours mal à l’aise quant à l’existence continue de la fonction « executeOnDestContextByCaller ». Pour apaiser d’autres soupçons, il est finalement décidé d’avoir un autre deuxième patch le même jour, dans lequel « executeOnDestContextByCaller » est complètement supprimé. Les avantages d’avoir cette fonction autour ne l’emportent plus sur les risques. Ce patch arrive lundi soir, et cette fois la mise à jour se fait selon le protocole, et relativement sans souci.
Une autre partie de l’équipe étudie des solutions pour récupérer les fonds. Entre-temps, la plupart des fonds ont été récupérés auprès des agresseurs, mais comme il s’agit toujours d’une enquête ouverte, pour des raisons juridiques, nous ferons un suivi avec un aperçu plus détaillé dès que l’enquête sera close.
La poussière s’installe
Mardi matin, la plupart des fonds sont récupérés et l’équipe commence à restaurer l’état d’avant l’attaque.
Tout d’abord, le pool de liquidités EGLD-USDC est toujours déséquilibré. Afin de récupérer entièrement ce qui a été perdu, c’est l’équipe d’Elrond qui doit racheter l’EGLD qui a été vendu par l’attaquant et le ramener au juste prix du marché.
Il n’y a pas encore de mécanisme de liste blanche dans le DEX, donc l’équipe doit d’abord le mettre en œuvre. C’est le seul moyen pour l’équipe d’effectuer les swaps avant de rouvrir les contrats au public. Aucun raccourci n’est acceptable : la nouvelle version du contrat LP est testée en profondeur pendant plusieurs heures avant le déploiement.
Il en va de même pour la paire EGLD-UTK, l’équipe doit vendre l’UTK volé de la même manière qu’il a été acheté par l’attaquant pour récupérer le WEGLD exploité.
Deuxièmement, le contrat d’échange Wrapped EGLD doit être rééquilibré. Dans des circonstances normales, il y a toujours un ratio de 1:1 entre EGLD dans le contrat et WEGLD, mais à cause de l’attaque, cet équilibre est rompu. L’excédent de WEGLD doit être brûlé.
C’est plus délicat que prévu. L’attaquant a converti une grande partie de l’EGLD volé en WEGLD, puis en a jeté la majeure partie dans l’échange. Une partie de ce WEGLD a été perdue à cause des frais et des robots d’arbitrage qui fonctionnaient à l’époque, il y a donc encore un excès de WEGLD réparti sur tout le réseau.
L’équipe parvient à récupérer des fonds auprès du pirate. Plus précisément les fonds qui n’étaient pas encore liés à Ethereum. Les fonds récupérés sont envoyés à l’adresse suivante :
https://explorer.elrond.com/accounts/erd1pml9k2tsqsnvtmmalglt2su0sn3cguvr8e8jq0gy69zw2ldcej2qapml9a
Ainsi, le processus de récupération peut commencer. L’équipe commence par réparer les dommages causés aux pools de liquidités et aux contrats de swap WEGLD.
En rachetant WEGLD aux pools au prix auquel l’attaquant l’a vendu, une partie de la perte peut être récupérée. L’équipe effectue cela en plusieurs étapes plus petites, jusqu’à ce que le prix EGLD corresponde au prix EGLD actuel sur Binance (68,5 $ à ce moment-là). A noter que ce prix est un peu moins élevé qu’il ne l’était lors de l’attaque.
Cela ne revient malheureusement pas à l’équipe de tous les « WEGLD exploités » qui se sont propagés sur tout le réseau. L’équipe ne peut acheter que 728k WEGLD avec l’USDC et l’UTK retournés par l’attaquant.
Vient maintenant le temps des contrats d’échange. L’attaquant a volé 1650k EGLD des contrats, mais n’a converti que 917k EGLD en WEGLD. Une partie de ce WEGLD à double frappe a ensuite été vendue par les bots d’arbitrage après avoir réalisé des bénéfices. Ce n’est pas si important, cependant. Ce qui est important, c’est qu’il y a 1650 000 WEGLD de plus que EGLD dans les contrats.
Il y a 2 façons d’éliminer cette différence : brûler WEGLD ou ajouter EGLD manquant aux contrats.
L’équipe fait les deux :
un. Les 728k WEGLD achetés à l’échange sont brûlés dans la transaction suivante :
b. Les 922 000 EGLD restants sont directement intégrés aux contrats, sans plus frapper de WEGLD. Cela se fait via un point de terminaison de « rééquilibrage » écrit spécifiquement pour cette occasion. 200k de l’EGLD utilisé dans cette opération proviennent de la réserve de la Fondation Elrond. Les opérations de rééquilibrage sont les suivantes :
Enfin, après de nombreuses autres séries de vérifications et de tests, l’échange Maiar n’est plus suspendu et les services reprennent leur fonctionnement normal le mercredi 8 juin.
Erreur commune
Au lendemain de l’attaque, la communauté était en effervescence avec des théories et des suppositions sur ce qui s’était passé. Quelques-uns ont bien compris les événements, mais beaucoup d’autres ont succombé à la confusion et à la désinformation.
Pour dissiper les idées fausses les plus courantes :
- « C’était une attaque DEX » . Ce n’était pas le cas, le DEX a fonctionné comme prévu tout le temps. Deux des pools de liquidités se sont déséquilibrés lors de la vente massive, mais le DEX n’a pas été la cible de cette attaque.
- « C’était un problème de liquidité/quelque chose de similaire à UST/LUNA ». Non, cet exploit n’a rien à voir avec le récent effondrement de l’écosystème Terra. À aucun moment, ce n’était un problème de sous-garantie, c’était du pur vol.
- « C’était une attaque de pont » . Non, le pont a fonctionné comme prévu. Certains des fonds ont été transférés à Ethereum, période pendant laquelle le pont a fonctionné comme prévu. Il a ensuite été désactivé exprès, pour empêcher que davantage de fonds ne quittent l’écosystème.
- « C’était une attaque de contrat intelligent » . L’attaquant n’a exploité aucune vulnérabilité de code de contrat intelligent, le problème était dans la machine virtuelle. Il n’y avait pas de bogue dans le contrat egld-esdt-swap lui-même.
- « L’attaquant a réussi à frapper EGLD à partir de rien » . Non, tout l’EGLD a été volé directement du solde du contrat intelligent egld-esdt-swap. C’était déjà là.
- « L’attaquant a réussi à frapper WEGLD à partir de rien » . C’est en partie vrai. Bien que l’attaquant n’ait pas exploité WEGLD directement, en enveloppant l’EGLD volé, le résultat a été qu’il y avait plus de WEGLD en circulation qu’il n’aurait dû l’être, 900 000 WEGLD pour être précis. Cela équivaut à frapper illégalement WEGLD sans support. L’équipe a réussi à récupérer ce WEGLD illégal et l’a brûlé, donc à l’heure actuelle, chaque jeton WEGLD est à nouveau soutenu par 1 EGLD.
- « La blockchain Elrond a été désactivée » . À aucun moment la blockchain n’a été désactivée ou inactive. Des blocs et même certaines transactions ont été ajoutés pendant tout le temps. Seul le point de terminaison de transaction d’envoi de l’API publique a été désactivé.
- « C’était un « travail de l’intérieur » » . L’une des informations erronées les plus flagrantes est la théorie selon laquelle quelqu’un de l’équipe l’aurait fait. Il est absurde de croire que quelqu’un travaillant sur un projet pendant des années mettrait ledit projet en péril, tout en risquant sa propre liberté personnelle pour un profit rapide.
- « Le piratage du chapeau noir en vaut la peine ». Même si vous réussissez à réussir un piratage, il est très difficile de retirer les fonds. Même les pirates les plus qualifiés laissent des traces partout, tous les CEX ont mis en place des KYC et il est presque impossible d’échapper à la loi. Si vous trouvez une vulnérabilité logicielle, la chose la plus intelligente à faire est de la signaler à l’équipe. Cela vous rapportera une belle prime tout en vous gardant du bon côté de la loi, libre d’explorer le monde en dehors de la prison.
Leçons apprises, pas en avant
Le logiciel est difficile . La blockchain est difficile . Écrire une machine virtuelle à partir de zéro est également très difficile, mais cela en vaut la peine si vous recherchez vraiment la vitesse, la sécurité et l’évolutivité, ainsi qu’un impact significatif sur le monde.
Parfois, les choses tournent mal. Ce n’est évidemment pas quelque chose que nous devons accepter, c’est quelque chose que nous devons surmonter. La décentralisation est ce que nous recherchons tous, mais elle ne s’entend pas bien avec les bogues et les vulnérabilités.
Nous ne serions pas en mesure de maintenir le réseau aussi décentralisé qu’il l’est sans une communauté de validateurs aussi réactive et engagée. Ils ont vraiment brillé au moment du défi maximal.
Les créateurs de contrats et de jetons ESDT peuvent choisir de s’octroyer le pouvoir d’arrêter temporairement lesdits contrats et jetons ESDT en cas de crise. Dans de tels événements malheureux, l’importance et la nécessité des précautions auxiliaires peuvent être clairement comprises. Au fur et à mesure que la technologie mûrira, nous verrons ce pouvoir être abandonné progressivement et en toute sécurité via différentes formes de gouvernance.
Quant au code lui-même, il y a 3 façons de s’assurer qu’il fonctionne correctement : les tests, le temps et les mathématiques. Les tests ne sont clairement pas suffisants pour les infrastructures complexes et critiques. Le temps finit par révéler et éliminer toutes les vulnérabilités cachées, mais c’est un processus douloureux et plein d’embûches. La meilleure approche est d’y réfléchir profondément, de le modéliser mathématiquement, de le simuler et de l’auditer, et c’est quelque chose dans lequel nous devons investir davantage à l’avenir. Nous avons déjà des modèles partiels de la VM et de nombreux outils pour tester l’exactitude de notre code, nous avons juste besoin d’en tirer le meilleur parti et de les développer davantage. Des événements comme celui-ci sont une évaluation intense de nos normes et méthodologies d’ingénierie.
Hélas, cette semaine commence un nouveau chapitre dans l’histoire d’Elrond. Nous avons décidé de repenser non seulement notre architecture de sécurité, mais toute notre philosophie de création de logiciels.
Cette semaine déjà, nous avons identifié plusieurs fronts sur lesquels la lutte pour éliminer les vulnérabilités sera menée. Il y a déjà plusieurs équipes à la recherche de problèmes dans le protocole, la VM, les services et le frontend. Nous avons également examiné quels outils peuvent apporter les résultats les plus complets le plus rapidement, et avons déjà commencé à développer certains d’entre eux.
Le processus interne consistant à signaler les problèmes de sécurité potentiels, à faire émerger les problèmes et à les traiter avec la plus grande rapidité et minutie a également été réitéré et simplifié. Le processus externe de divulgation responsable de la sécurité , via l’envoi d’un e-mail à security@elrond.com , et la réception d’une grosse prime pour tout bogue valide et significatif, sera constamment porté à l’attention de tous les membres de la communauté, pour aider à renforcer ce comportement constructif.
Dire que ces quelques jours ont été difficiles est un euphémisme. En fin de compte, rien d’important ne peut être construit sans difficultés. Étant donné que les difficultés viendront invariablement, nous ferons de notre mieux pour nous préparer, fortifier notre détermination et renforcer notre réponse face à cela.
Après tout cela, le Maiar DEX est entièrement en direct. Les API sont entièrement en direct. Les échanges sont entièrement en direct.
Tous les fonds sont en sécurité, tous les utilisateurs sont en sécurité.
Quelle force et quelle joie tenaces ces mots véhiculent.
Avec ces nouvelles leçons apprises, nous allons ouvrir un nouveau chapitre pour Elrond.
Venez construire avec nous. Fortifions ce réseau ensemble.
Echangez vos Locked Mex (LKMEX) en Egld avec https://lockedmex.exchange/
MultiversX • Le portefeuille crypto révolutionnaire 