Bonjour tout le monde ! La prochaine mise à jour majeur de Steem s'en vient assez vite (le 25 septembre 2018 !) et peut d'entre-nous savent ce qui va se passer. J'ai donc traduit en français cet article du @steemitblog qui fait le sommaire de tous les changements qui auront lieu. Je vous conseil de jeter un œil particulièrement au nouveau système de RC (Crédits de Ressources), car il permettra de créer de nouveaux comptes gratuitement (ou à moindre frais) !

Bonne lecture !

---

Dans le post d'aujourd'hui, nous vous fournirons un résumé des changements dans le Hardfork Vélocité (i.e. Hardfork 20). L'objectif de ce billet est d'être le guide définitif de tous les changements inclus dans le Hardfork qui doit avoir lieu le mardi 25 septembre, à 11h00 HNE. Les changements dans le Hardfork Vélocité dépendent de l'approbation d'une super majorité (17/21) des témoins votant en faveur du Hardfork.

Crédits de ressources

L'un des principaux changements apportés par la Hardfork Vélocité est le passage de notre système de bande passante actuel à un système nouveau et amélioré basé sur les crédits de ressources (RC).

Steem est l'une des seules chaînes de bloc freemium au monde. Le nouveau système RC en fera la chaîne de blocs freemium la plus avancée au monde sans compromettre les caractéristiques et les fonctionnalités existantes qui font de Steem une plate-forme si puissante pour construire des DApps.

Les détails sur le fonctionnement de ce nouveau système RC sont décrits dans notre récent post
Blockchain Update 4: Resource Credit Implementation Details.

 GitHub Issue 2457, GitHub Issue 2511, GitHub Issue 2512, GitHub Issue 2521, GitHub Issue 2549, GitHub Issue 2563, GitHub Issue 2600, GitHub Issue 2621, GitHub Issue 2624, GitHub Issue 2625, GitHub Issue 2626, GitHub Issue 2627, GitHub Issue 2631, GitHub Issue 2546, GitHub Issue 2547, GitHub Issue 2648, GitHub Issue 2649, GitHub Issue 2650, GitHub Issue 2679, GitHub Issue 2685, GitHub Issue 2694, et GitHub Issue 2703

Mises à jour de la création de compte

L'objectif principal du la Hardfork Vélocité est de changer le système de création de compte afin de réduire les coûts et d'améliorer le processus d'intégration des nouveaux utilisateurs.

Création d'un compte à prix réduit

La Hardfork Vélocité donnera aux utilisateurs la possibilité de créer de nouveaux comptes à un tarif réduit, potentiellement sans avoir à payer le moindre STEEM ou à déléguer des Steem Power. Lors de la création d'un nouveau compte, les utilisateurs pourront utiliser les RC au lieu d'une partie (ou la totalité) des frais de création de compte STEEM.

Les RC qui sont dépensés lors de la création de comptes à prix réduit sont les mêmes que ceux qui sont consommés lorsque les utilisateurs interagissent avec la chaîne de blocs. Cela limite la capacité des utilisateurs à interagir avec la chaîne de blocs lorsqu'ils sont à court de RC. Les utilisateurs (en particulier ceux qui ont une quantité modérée ou faible de Steem Power) doivent faire attention à ne pas dépenser trop de leurs RCs pour créer des comptes à prix réduits, sinon ils ne pourront plus interagir avec la chaîne de blocage jusqu'à ce que leur mana de RC ne se recharge.

GitHub Issue 1771, GitHub Issue 1772, GitHub Issue 2651, GitHub Issue 2700, et GitHub Issue 2710

Jetons de création de compte à prix réduit

La chaîne de blocs disposera d'un bassin mondial de jetons de création de compte à prix réduit qui représenteront le nombre de comptes à prix réduit qui peuvent être créés. Chaque fois qu'un utilisateur crée un nouveau compte en payant une partie (ou la totalité) des frais avec des RC au lieu de STEEM, un des jetons sera consommé. S'il n'y a plus de jetons dans le pool, alors aucune création de compte à prix réduit supplémentaire ne sera autorisée.

Le nombre de nouveaux jetons de création de compte à prix réduit créés chaque jour sera contrôlé par les témoins. La raison pour laquelle la fourniture de jetons de création de compte est confiée aux témoins est qu'ils sont incités à veiller à ce que le rythme auquel les nouveaux comptes sont créés n'impose pas un fardeau injustifié à la chaîne de blocs.

Le nombre total de jetons permis à un moment donné sera également contrôlé par les témoins. Il s'agit d'éviter qu'une quantité excessive de jetons ne s'accumule si la demande est insuffisante pour les utiliser.

GitHub Issue 1770, GitHub Issue 2628, et GitHub Issue 2688

Marché de création de comptes à prix réduit basé sur le principe de la participation [Stake-Based]

Conformément à notre préférence d'exploiter les marchés pour gérer les complexités de l'affectation des ressources, le coût de la création de comptes à prix réduit (en utilisant des RC) variera en fonction d'un marché interne.

Lorsque l'offre disponible de comptes à prix réduit est faible et/ou que la demande pour ces comptes est élevée, le nombre de RC qui devront être utilisés à la place des frais de création de compte STEEM sera élevé. Lorsque l'offre disponible de comptes à prix réduit est élevée et/ou que la demande pour ces comptes est faible, moins de RC seront nécessaires pour remplacer les frais de création de compte STEEM.

Il convient de noter qu'en fonction de l'offre et de la demande de comptes à prix réduit disponibles, il peut n'être possible qu’aux utilisateurs puissants (ceux qui détiennent beaucoup de STEEM Power) d'avoir les moyens de créer un compte à prix réduit.

GitHub Issue 1767 et GitHub Issue 1769

Frais de création de compte brûlés

Au lieu d'augmenter les frais de création de compte sur de nouveaux comptes, il sera "brûlé" en le transférant sur le compte @null.

GitHub Issue 1762

Desactivation de la création de compte avec l'opération de délégation

Après le Hardfork Vélocité, il ne sera plus possible de créer des comptes en utilisant une délégation de Steem Power, puisque les frais de création de compte seront brûlés. Par conséquent, l'opération account_create_with_delegation sera obsolète.

Les utilisateurs pourront toujours déléguer du SP à d'autres utilisateurs via les procédures de délégation standard.

GitHub Issue 1760

Frais de création de compte réversible modifié

Lorsque nous avons initialement ajouté la prise en charge de la création de comptes avec le SP délégué, nous avons modifié la façon dont le account_creation_fee des témoins étaient utilisés pour permettre qu'une partie des frais soit payée avec une délégation 5x de Steem Power. Avec ce changement, le prix de la création d'un compte sans PS délégué est devenu 30 fois les frais de création de compte. Par exemple, à l'heure actuelle, les frais de création de compte sont de 0,1 STEEM et il en coûte 3,0 STEEM pour créer un nouveau compte.

Comme la création de comptes avec délégation ne sera plus prise en charge, il n'est plus nécessaire de multiplier les frais de création de compte. Nous allons annuler le changement pour multiplier les frais par 30. Par exemple, si les témoins fixent les frais de création de compte à 3,0 STEEM, il en coûtera 3,0 STEEM pour créer un compte.

Au moment du Hardfork, il y aura un changement unique de 30 fois les frais de compte du témoin, de sorte que le prix de la création d'un compte ne diminuera pas de 30 fois lorsque le Hardfork aura lieu. Par exemple, si les frais de création de compte de tous les témoins sont fixés à 0,1 STEEM au moment du Hardfork, ils seront tous changés à 3,0 STEEM, de sorte qu'il en coûtera toujours 3,0 STEEM pour créer un compte. Après la mise à jour unique de 30x, les témoins pourront mettre à jour leurs frais de création de compte normalement.

GitHub Issue 1761

Changements au seuil de vote poussiéreux

Le seuil de vote poussiéreux est une règle qui prévient l'apparition de votes extrêmement faibles et a été mise en œuvre pour lutter contre l’engorgement de la chaîne de bloc. Actuellement, les comptes doivent posséder environ 1 SP pour qu'un vote à 100% avec droit de vote puisse être affiché avec succès dans la chaîne de blocs. Si un vote inférieur au seuil requis est placé, il est rejeté par la chaîne de blocs. Cela peut créer une mauvaise expérience utilisateur pour les nouveaux utilisateurs, car leurs votes peuvent échouer pour apparemment aucune raison.

Le système de la Hardfork Vélocité changera le fonctionnement du Seuil de vote poussiéreux en permettant aux utilisateurs ayant un nombre quelconque de SP de voter tant qu'ils ont suffisamment de RC. Les votes qui se situent en dessous du seuil seront affichés dans la chaîne de blocs, mais ils n'auront pas d'impact sur les récompenses. Cela permettra aux utilisateurs d'avoir une meilleure expérience utilisateur sur toutes les applications Steem en leur permettant de voter quand ils le souhaitent (quelle que soit la taille de leur vote), à condition qu'ils aient suffisamment de RC.

Ce changement fera que les votes très faibles ne vaudront plus rien. Afin de traiter tous les votes (grands et petits) de façon égale, tous les votes au-dessus du seuil seront retirés de leur puissance de vote pour un montant équivalent de récompenses. Cela permet d'établir un pouvoir de vote de base qui s'applique à tout le monde. En plus de la rendre plus équitable, il y a aussi l'avantage d'introduire une légère courbe de récompenses non linéaire à l'extrémité inférieure du spectre (pour décourager le pourriel), tout en maintenant une courbe de récompenses linéaire pour les votes au-dessus du niveau de référence.

GitHub Issue 1764 et GitHub Issue 2515

Suppression de la restriction de retrait minimale de STEEM Power

Actuellement, les comptes avec moins de 10 fois les frais de création de compte courant (en SP) ne peuvent pas être désinvestit par la chaîne de blocs. Ceci a été conçu pour empêcher les gens de créer de nouveaux comptes et de les désactiver immédiatement.

Après le Hardfork Vélocité, les frais de création de compte seront brûlés au lieu d'être désinvestit sur le nouveau compte. Comme le nouveau compte ne recevra aucun STEEM Power, il n'y aura rien d'autre à mettre désinvestir que les STEEM Power que le créateur du compte achète. Pour cette raison, l'exigence 10x sera supprimée.

GitHub Issue 1860

Mises à jour de la durée

Fenêtre de durée de 30 minutes

Les titulaires de comptes Steem (y compris les comptes de robots) sont actuellement découragés par la chaîne de blocs Steem de voter sur une publication dans les 30 premières minutes. Plus tôt un vote est effectué dans la fenêtre initiale de 30 minutes, moins le compte de vote reçoit de récompenses pour sa conservation. À l'origine, cette mesure visait à uniformiser les règles du jeu entre les conservateurs humains et les robots à une époque où la majorité du contenu de Steem était du contenu écrit de forme longue.

Bien qu'il ait été couronné de succès, beaucoup de choses ont changé pour Steem depuis lors. Steem héberge maintenant toutes sortes de contenu et alimente des centaines d'applications décentralisées qui élargissent considérablement les types de contenu qui peuvent être consommés sur Steem. Pour cette raison, la communauté et les témoins sont parvenus à un consensus sur le fait que la règle des 30 minutes prive les électeurs humains qui consomment activement du contenu et votent sur le matériel qu'ils aiment des récompenses de conservation. Pour cette raison, le Hardfork Vélocité réduira la fenêtre de curation de 30 minutes à 15 minutes.

GitHub Issue 1878

Récompenses des auto-votes

Selon les règles actuelles de la chaîne de blocs, si les auteurs votent pour eux-mêmes immédiatement, ils obtiennent leur récompense d'auteur, 100% de la récompense de la durée de leur vote, et une partie de la récompense de la durée provenant de tous ceux qui votent pour le poste après eux. Tout autre curateur votant en même temps que l'auteur obtiendrait 0% des récompenses de curation. Cela donne à l'auteur un avantage injuste par rapport aux autres curateur, parce que l'auteur peut obtenir des récompenses de curation supplémentaires en votant lui-même.

Afin d'éliminer cet avantage, la partie des récompenses de curation qui n'est pas remise aux curateurs en raison de la pénalité du vote anticipé sera retournée dans la réserve de récompenses au lieu d'être remise à l'auteur, ce qui augmentera le pourcentage global des récompenses versées aux curateurs. Cela permettra de mieux servir la mission originale du budget des récompenses de curation : s'assurer que la chaîne Steem distribue les récompenses au contenu le plus précieux.

GitHub Issue 1877

Expiration des ordres du marché interne

La mise en œuvre actuelle du marché interne impose que les ordres à cours limité ne soient jamais forcés d'expirer. Cela permet aux utilisateurs de passer des ordres sur le marché intérieur qui nécessitent une bande passante consensuelle de longue durée, ce qui nuit à la performance globale de la chaîne de blocs. Après Vélocité, la chaîne de blocs exigera que tous les ordres sur le marché interne expirent après 28 jours. Ceci est cohérent avec la mise en place de carnets d'ordres sur bon nombre des grandes places boursières. Les ordres à cours limité existants verront leur expiration limitée à 28 jours après le Hardfork.

GitHub Issue 1449

Changements pour les témoins

Ces changements s'appliquent principalement aux témoins.

Mise à jour du format du flux de prix des témoins

Le Hardfork Vélocité fera une mise à jour des exigences relatives aux flux de prix des témoin. Les flx de prix nécessiteront maintenant que la base soit le SBD et que la cotation soit le STEEM. Les flux de prix qui indiquent la base comme STEEM et la cotation comme SBD seront rejetés.

GitHub Issue 409

Paramètres flexibles pour les témoins

Une nouvelle opération witness_set_properties sera ajoutée. Il permettra aux témoins de mettre à jour les paramètres individuels au lieu d'avoir à faire un appel update_witness avec tout en même temps. L'opération prendra en charge : les frais de création de compte, la taille maximale du bloc, l'intérêt sbd, la clé de signature, et l'URL témoin. Les témoins pourront également soumettre des données sur les prix à l'aide de la nouvelle méthode.

Cette nouvelle opération s'authentifiera avec la clé de signature du témoin au lieu de sa clé active. Cela signifie que les témoins qui soumettent leurs flux de prix à l'aide de la nouvelle opération pourront désormais les soumettre à l'aide de leur clé de signature. Les témoins bénéficient ainsi d'un avantage sur le plan de la sécurité, puisqu'ils n'auront plus besoin de stocker leur clé active sur aucun de leurs serveurs.

L'opération actuelle de mise à jour des témoins restera fonctionnelle, mais aucun nouveau paramètre de témoin ne sera ajouté. Il est important que cette opération reste fonctionnelle, car elle fournit une méthode pour mettre à jour la clé de signature du témoin avec l'autorité active du compte.

GitHub Issue 352 et GitHub Issue 1620

Limite de la taille maximale des blocs

Les témoins pourront régler la taille maximale des blocs acceptés par la Blockchain Steem. Le protocole Pair à Pair (p2p), cependant, aura une limite de 2MiB sur la taille d'un bloc que le réseau p2p peut traiter. Les témoins ne devraient pas être en mesure de régler une valeur supérieure à celle autorisée par le réseau p2p.

Afin d'empêcher les témoins d'autoriser des blocs supérieurs à cette limite de 2MiB, nous ajoutons une limite maximale de 2MiB au paramètre de taille maximale des blocs soumis par les témoins.

GitHub Issue 1655 et GitHub Issue 2642

Nouveaux paramètres pour les témoins

Les témoins auront deux nouveaux paramètres à soumettre. Le account_subsidy_daily_rate (taux de subvention quotidien de comptes) contrôlera le montant des jetons de création de compte à prix réduit qui sont ajoutés quotidiennement au pool global. Le account_subsidy_pool_cap contrôlera le nombre maximum de jetons de création de compte escomptés autorisés dans le pool. Ces valeurs seront soumises via la nouvelle opération witness_set_properties décrite ci-dessus.

GitHub Issue 1765 et GitHub Issue 2688

Limite de 20 seconde des commentaires

La limite de 20 secondes pour les commentaires sera supprimée dans le cadre du Hardfork Vélocité. La chaîne de blocs va maintenant permettre un nouveau commentaire à chaque bloc (une fois toutes les trois secondes), ce qui est la même restriction imposée au vote. Un merci spécial au développeur communautaire @mejustandrew pour avoir soumis le pull request pour ce changement !

GitHub Issue 2019

Correction pour les exploits de double vote

Deux utilisateurs ont signalé des exploits où un compte pouvait obtenir de la puissance de vote supplémentaires en utilisant toute leur puissance de vote, puis en déléguant leur SP à un autre compte, ou en désinvestissant puis à nouveau investissant du SP dans un autre compte. Nous inclurons des correctifs pour ces exploits dans le cadre de Vélocité. Plus de détails techniques sur les correctifs peuvent être trouvés ici.

GitHub Issue 2428 and GitHub Issue 2539

Diminution de la période de récupération des délégations

Dans le cadre des changements que nous apporterons aux opérations de double vote, nous pourrons réduire la période de récupération des délégations du SP de sept jours à cinq jours. Cela signifie qu'après qu'un utilisateur ait récupéré le SP délégué à un autre utilisateur, il ne lui faudra que cinq jours pour revenir sur son compte et redevenir disponible pour être utilisé.

Augmenter la précision de la puissance de vote du compte

Dans le cadre des correctifs que nous apportons aux exploits du double vote, nous augmenterons également la précision du pouvoir de vote (maintenant le mana de vote). Cela augmentera le nombre de votes qu'un compte peut faire avec moins de 2 % des droits de vote, puisque la chaîne de blocs permettra désormais plus de votes granulaires.

GitHub Issue 1808

Facilité minimale d'utilisation du compte

Même si les frais de création de compte sont brûlés, les comptes créés après le Hardfork Vélocité pourront toujours traiter avec la chaîne de blocs avec un SP nul, car le SP brûlé sera toujours pris en compte dans leurs calculs de solde de RC.

GitHub Issue 2488 et GitHub Issue 2595

Période de blocage du vote par anticipation

Dans le Hardfork 17, un changement a été mis en œuvre pour prévenir les abus de upvotes en créant une période de lock-out de douze heures à la fin de la période de paiement d'une publication. Pendant ce temps, les utilisateurs ne sont plus autorisés à upvoté. Cela empêche les utilisateurs de cacher un vote personnel à la fin de la période de paiement et d'exploiter le pool de récompenses. Toutefois, les utilisateurs ont conservé la possibilité de downvoter pour se prémunir contre le scénario où un utilisateur voterait par lui-même immédiatement avant le début de la période de lock-out de 12 heures. Bien que cela soit rare, cela a créé une possibilité pour les utilisateurs malveillants d'attendre jusqu'à la période de lock-out pour émettre des downvotes punitifs afin qu'ils ne puissent pas être contrés par des upvotes.

Velocité s'attaquera à ce scénario potentiel en modifiant le lock-out avec une de récupération. Après Velocity, les votes à la hausse et à la baisse seront permis pendant les 12 dernières heures de la période de paiement, mais leur force (pour le même nombre de votes) diminuera linéairement de 100% à 0% pendant cette période de 12 heures. En d'autres termes, il faudra deux fois plus de pouvoir de vote pour avoir le même impact sur le paiement d'une publication si le vote a lieu alors qu'il ne reste que six heures sur la fenêtre de paiement au lieu de douze. Un vote à la dernière minute n'aurait pratiquement aucun impact sur les récompenses d'un poste.

Ce changement permettra de s'assurer que, quel que soit le moment où un message reçoit un vote à la hausse ou à la baisse, les utilisateurs seront en mesure de contre-voter. Cela aidera également à stabiliser le paiement potentiel des billets au cours des 12 dernières heures en diminuant la force des votes au fur et à mesure qu'il se rapproche du moment du paiement.

GitHub Issue 1267

Changements dans la chaîne du Steem Blockchain Dollar (SBD)

Le développeur communautaire @timcliff a soumis deux changements pour mettre à jour la logique pour les Steem Blockchain Dollars (SBDs).

Mise à jour du taux d'impression du SBD

Dans le Hardfork 14, des règles ont été ajoutées pour réduire le taux d'impression SBD lorsque le "taux d'endettement" (montant des jetons SBD existants / la capitalisation boursière STEEM) était supérieur à un certain pourcentage.

En vertu des nouvelles règles, les jetons SBD continueront d'être imprimés jusqu'à ce que le ratio d'endettement atteigne 9% de la capitalisation boursière du STEEM. Entre 9% et 10%, les paiements liquides passeront linéairement de 100 % SBD et 0 % STEEM à 9 % , à payer 0% SBD et 100% STEEM à 10 %. Cela fonctionne de la même façon que le changement qui se produit aujourd'hui entre 2% et 5%.

GitHub Issue 2140

Bénéficiaires des récompenses payés en fonction des paramètres de l'auteur

Lorsqu'un auteur choisit le "paiement 50/50" sur sa publication, il recevra 50% de ses récompenses en tant que SP, et les 50% restants en tant que "paiement liquide". Le paiement liquide se fait généralement sous la forme de SBD, mais il peut parfois payer une partie (ou la totalité) en STEEM liquide si le ratio d'endettement est suffisamment élevé. L'auteur a également la possibilité de choisir d'être payé à 100% en Steem Power.

Actuellement, si un auteur ajoute des bénéficiaires à son message, les bénéficiaires seront payés en 100% Steem Power, quelle que soit la sélection faite par l'auteur pour leurs récompenses. Après Vélocité, les bénéficiaires seront payés en utilisant le même paramètre de paiement que l'auteur.

GitHub Issue 2022

Changements divers

Prise en charge des signatures canoniques BIP-0062

Pour résoudre les problèmes de malléabilité des transactions, Steem applique des signatures ECDSA "canoniques". Les signatures canoniques ECDSA que Steem utilise sont un sous-ensemble d'un système de signature canonique BIP-0062 plus largement utilisé.

Nous mettrons à jour nos signatures canoniques pour utiliser la méthode BIP-0062, afin que nos signatures puissent être plus facilement comprises par des personnes de l'extérieur, et pour faciliter l'intégration avec la chaîne de blocs Steem pour les développeurs tiers qui pourraient réutiliser le code d'autres chaînes de blocs qui utilisent la méthode BIP-0062. Cela ouvre aussi le reste de l'espace de recherche canonique, ce qui augmente l'entropie, et donc la sécurité, de nos signatures.

GitHub Issue 1944

Comptes minés

Vélocité ne prend pas en charge la création de comptes via le minage. Au lieu de cela, Vélocité inclura les changements nécessaires pour permettre le minage de comptes Steem via softfork à une date ultérieure. La raison en est que les nombreuses tentatives d'algorithmes "ASIC résistants" n'ont pas réussi à freiner les implémentations d'ASIC. Jusqu'à ce que nous puissions trouver un schéma de preuve de travaille (PoW) raisonnable qui soit accessible par les utilisateurs finaux sans être facilement exploitable, nous avons pensé que ce ne serait pas une bonne idée d'inclure le PoW pour la création de compte. Nous avons décidé qu'il était beaucoup plus important de terminer le Hardfork Vélocité et d'ajouter le support pour les comptes à prix réduit dès que possible. Puisque la fonctionnalité peut être ajoutée à tout moment à l'avenir sans nécessiter un travail supplémentaire, nous avons la flexibilité de l'ajouter une fois que nous trouvons un algorithme acceptable.

L'une des principales choses qui seront modifiées dans Vélocité pour que les comptes minés puissent fonctionner correctement une fois implémentés, est d'empêcher les comptes minés d'avoir un partenaire de récupération de compte par défaut. Parce qu'une deuxième partie n'est pas impliquée dans le processus de création du compte, il n'y a personne pour désigner le recouvrement du compte en cas de vol du compte. Si un utilisateur disposant d'un compte miné souhaite profiter du processus de récupération de compte, il peut désigner une partie consentante comme partenaire de récupération une fois le compte créé.

GitHub Issue 1782

Moderniser le schéma

Ce sont des changements hautement techniques pour améliorer la maintenabilité de la base de code Steem. Les personnes intéressées peuvent lire les détails dans les liens GitHub correspondants.

GitHub PR 2692, GitHub PR 2693, and GitHub Issue 683

Correction d'une coquille de message d'erreur

Le développeur communautaire @arcange a soumis un changement pour corriger une coquille dans les messages d'erreur qui sont retournés lorsque certains appels d'API sont effectués sans un nombre approprié de comptes. Le message d'erreur affiche maintenant correctement au moins un compte doit être spécifié.

GitHub PR 2673

Retrait des autorités de contestation

Challenging Authorities est un système conçu à l'été 2016 qui n'a jamais été entièrement publié. La proposition permettrait à un utilisateur de payer des frais minimes pour contester l'autorité d'un autre utilisateur, ce qui l'obligerait à signer une transaction avec une autorité de niveau supérieur pour prouver qu'il continue à avoir le contrôle d'une clé. Si cette fonctionnalité avait été mise en œuvre, elle aurait pu conduire à un scénario dans lequel un titulaire de compte innocent aurait été forcé de retirer ses clés du stockage à froid [stockage de donnés hors-ligne] par un acteur malveillant. Pour cette raison, Vélocité supprimera le code externe lié à cette fonctionnalité.

GitHub Issue 1848

Testnet

Nous lancerons un testnet Velocity Hardfork avant la date de lancement du réseau principal, ce qui donnera aux développeurs la possibilité de tester les changements à venir dans un environnement hors production avant le lancement. Nous fournirons les détails sur ce testnet une fois qu'il sera prêt à être utilisé par le public.

Calendrier

La majeure partie du développement de la Hardfork Vélocité est terminée et peut être revue sous la balise project/hf20 dans le dépôt Steem GitHub. Les problèmes sont également suivis par l'intermédiaire de notre comité de projet ici.

Le Hardfork doit avoir lieu le mardi 25 septembre à 11 h (HNE). Les changements dans le Hardfork Vélocité dépendent de l'approbation d'une super majorité (17/21) des témoins votant en faveur du Hardfork.

Nous étiquetterons la version Hardfork au plus tard le 25 août, ce qui donnera aux témoins et aux opérateurs de nœuds au moins 30 jours pour examiner et tester les changements, et les appliquer à leurs nœuds avant le 25 septembre.

Nous sommes confiants que ces changements seront des améliorations majeures à la chaîne Steem, rendant Steem encore meilleur qu'avant.

Steem on,

L'équipe Steemit Blockchain

---

Mes autres traductions :

EOS

• [Traduction] Pourquoi toutes les Blockchains ont besoins d'une constitution
• [Traduction] Comment créer une constitution de blockchain significative
• [Traduction] À quoi pourrait ressembler une constitution de Blockchain
• [Traduction] Constitution d'EOS
• [Traduction] L'intention du code est loi
  

Steem/SMT

• [Traduction fr] Garder votre mot de passe Steem en sécurité - de @anarchyhasnogods
• [Traduction] Les Jetons Médiatiques Intelligents sur la blockchain Steem.
• [Traduction] Mise à jour : Communautés/Hivemind
• [Traduction] Communautés Steem
• [Traduction] Date de sortie des SMT
• [Traduction] Busy v2 Mises à jour finales, stratégie et plan de pivot pour Busy v3 MVP et Jeton, Mise-à-jours de l’équipe & Partenariat.
  

Steem Basic Income

• [Traduction] Steem Basic Income – Une cascade de pérennité.
• [Traduction] Steem Basic Income - FAQ

Dan Larimer

• [Traduction] Droits de propriété et revenu de base - Une solution viable est possible
• [Traduction] Cryptomonnaie à prix hypothétique stable avec revenue de base
• [Traduction] Pourquoi nous battons-nous pour changer le monde?
• [Traduction] Vision pour BitShares
• [Traduction] Société d'Aide Mutuelle
• [Traduction] Société d’Aide Mutuelle vs Assurances
• [Traduction] Les limites de la gouvernance crypto-économique