- Retour au menu
- Retour au menuTarifs
- Retour au menuRecherche
- Retour au menuConsensus
- Retour au menu
- Retour au menu
- Retour au menu
- Retour au menuWebinaires et Événements
Les clients Ethereum publient un nouveau logiciel suite au retard du hard fork
Les principaux clients Ethereum publient de nouvelles versions de leur logiciel pour empêcher le déclenchement du hard fork de Constantinople, désormais retardé.
Les principaux clients Ethereum , dont Go-Ethereum (Geth) et Parity, ont publié des mises à jour logicielles suite à une décision antérieure de retarder la mise à niveau prévue à l'échelle du système, baptisée Constantinople.
La mise à niveau a étéreporté mardi Lors d'une conférence téléphonique avec les développeurs, cette décision fait suite à la découverte par le cabinet d'audit blockchain Chain Security d'une faille de sécurité dans la proposition d'amélioration Ethereum (EIP) 1283, ONEune des modifications prévues pour Constantinople. Si elle avait été exploitée, la faille aurait permis des « attaques par réentrée », permettant à des acteurs malveillants de retirer des fonds de la même source à plusieurs reprises.
Un nouveau bloc d'activation pour la mise à niveau sera décidé lors d'un autre appel plus tard cette semaine.
Afin d'empêcher le fork de se produire – étant donné que certains des clients logiciels du réseau avaient déjà été mis à jour avant le fork – les développeurs des principales implémentations Ethereum ont décidé de publier de nouvelles versions.
Geth a publié un correctif d'urgence (version 1.8.21) conçu pour retarder la mise à niveau, bien que le développeur Péter Szilágyi ait noté que les utilisateurs qui ne souhaitent pas mettre à niveau vers la nouvelle version du client peuvent également rétrograder leurs clients existants vers la version 1.8.19 ou continuer à exécuter la version actuelle (1.8.20) avec un remplacement.
Les clients de Parity peuvent également mettre à niveau leurs clients existants vers la version 2.2.7 (la version stable) ou 2.3.0 (une version bêta) ou rétrograder vers la version 2.2.4 (bêta).
Kirill Pimenov, responsable de la sécurité de Parity Technologies, s'exprimant dans unDiscussion des développeurs Ethereum CORE sur Gitter, il a déclaré qu'il recommandait aux utilisateurs de mettre à niveau vers la nouvelle version, plutôt que de rétrograder vers une version plus ancienne, expliquant :
Je tiens à le répéter : rétrograder Parity aux versions antérieures à Constantinople est une mauvaise idée. Nous T le recommandons à personne. En théorie, cela devrait fonctionner, mais nous ne voulons T nous retrouver avec un tel désordre.
De même, le responsable de la publication de Parity, Afri Schoedon, a déclaré à CoinDesk qu'il recommandait la version 2.2.7, bien que les deux autres devraient également fonctionner.
Dans un article de blog, le développeur CORE Hudson Jameson a écrit que quiconque n'exécute pas de nœud ou ne participe pas au réseau n'a rien à faire.
Les propriétaires de contrats intelligents n'ont rien à faire non plus, même si « vous pouvez choisir d'examiner l'analyse de la vulnérabilité potentielle et de vérifier vos contrats », a-t-il écrit.
Il a toutefois souligné que le changement qui pourrait introduire ce problème potentiel ne sera pas activé.
Au moment de la publication de l'article de blog, les chercheurs en sécurité de ChainSecurity,qui a initialement découvert le bug, et TrailOfBits analysent la blockchain dans son ensemble.
Attaques de réentrée
Jusqu'à présent, aucun cas de vulnérabilité n'a été découvert dans les contrats en cours. Cependant, Jameson a noté qu'« il existe toujours un risque non nul que certains contrats soient affectés ».
Afin que les transferts sur Ethereum évitent les attaques de réentrée, une petite quantité d'éther appelée GAS est payée, ce qui empêche les attaquants de réutiliser un transfert pour voler des fonds.
Cependant, comme l'a expliqué à CoinDesk Hubert Ritzdorf – l'individu qui a découvert la vulnérabilité et le directeur technique de Chain Security – un « effet secondaire » de l'EIP 1283 garantit que les attaquants peuvent exploiter cette petite quantité de GAS à des fins malveillantes.
« La différence est qu'avant, on ne pouvait T faire quelque chose de malveillant avec ce petit BIT de GAS, on pouvait faire quelque chose d'utile mais pas quelque chose de malveillant et maintenant, parce que certaines opérations sont devenues moins chères, on peut maintenant faire quelque chose de malveillant avec ce petit BIT de GAS», a déclaré Ritzdorf.
Et bien que la question de la réentrance soit toujours présente à l'esprit des développeurs de contrats intelligents codant en Solidity sur Ethereum, Matthias Egli – COO de Chain Security – a expliqué que les développeurs CORE examinant strictement la mécanique de la machine virtuelle T pas pu facilement repérer cette vulnérabilité.
Il a déclaré à CoinDesk:
« C'est un problème de Solidity, et non un élément CORE de la machine virtuelle Ethereum qui, en pratique, a permis cette attaque. C'est en partie dû au fait que de légères modifications du coût du GAS permettront de nouveaux types d'attaques, ce qui n'était T envisagé auparavant. »
De plus, Ritzdorf a ajouté que la solution à ce problème n'est T aussi simple que de mettre à jour les limites de coût du GAS d'Ethereum, expliquant que « si nous modifions ce montant à un petit nombre maintenant, nous corrigerions la vulnérabilité mais nous briserions également de nombreux contrats [intelligents] existants. »
Ainsi, pour le moment, un report à Constantinople était la bonne décision de la part des développeurs CORE , selon Egli.
« C'était la bonne décision, car cela donne au moins le temps aux chercheurs d'évaluer l'impact réel. Il est fort probable que cet [EIP] soit retiré et ne soit pas inclus dans le prochain hard fork, désormais retardé d'environ un mois », a-t-il affirmé.
Prochaines étapes
Au moment de la mise sous presse, les développeurs contactent les échanges, les portefeuilles, les pools miniers et d'autres groupes qui utilisent ou interagissent avec le réseau Ethereum .
Les développeurs CORE prévoient de discuter des étapes à plus long terme, notamment du moment où exécuter Constantinople et de la manière de corriger le bogue dans EIP 1283, lors d'un autre appel le 18 janvier.
Plusieurs développeurs ont suggéré de lancer une sorte de programme de primes aux bogues axé sur l'analyse du code, afin de garantir que les futurs bogues soient découverts bien à l'avance, plutôt que «juste avant le jour du [hard fork]."
Szilágyi a souligné que le PEI avait été disponible pour examendepuis près d'un an,ajoutant que« Ce n’est peut-être pas une mauvaise idée de faire des subventions pour des yeux plus attentifs. »
Image de codevia Shutterstock
Nikhilesh De
Nikhilesh De est rédacteur en chef de CoinDesk pour la Juridique et la réglementation mondiales. Il couvre les régulateurs, les législateurs et les institutions. Lorsqu'il ne traite pas des actifs numériques et des Juridique, on le trouve en train d'admirer Amtrak ou de construire des trains LEGO. Il possède moins de 50 $ en BTC et moins de 20 $ en ETH. Il a été nommé Journaliste de l'année 2020 par l'Association des journalistes et chercheurs en Cryptomonnaie .

Christine Kim
Christine est analyste de recherche chez CoinDesk. Elle se concentre sur la production d'analyses basées sur les données concernant les secteurs des Cryptomonnaie et de la blockchain. Avant cela, Christine était journaliste technique pour CoinDesk, couvrant principalement les développements de la blockchain Ethereum . Avoirs en Cryptomonnaie : Aucun.
