Bonjour à toutes et à tous.

Il est parfois difficile de faire une mise à jour de witness quand n'y a pas suffisamment de matière... Mais on va pouvoir remédier à ça.

Je vais profiter des derniers événements pour donner mon avis et aller un peu plus loin qu'un update.

Mais avant cela, on va commencer sagement.

Il faut sauver le soldat Dtube Community Support

Projet créé et maintenu par votre witness, il consiste à faire persister les vidéos dtube francophone sur un de mes serveurs dédiés.

Il se trouve que j'ai de gros problème de stabilité faisant planter très régulièrement mon noeud. Je songe à le migrer sur un serveur disposant de stockage très rapide.

J'espère pouvoir faire ça durant les congés d’août. Je croise les doigts.

SteemActivities

C'est le bébé de Hive account@sebbbl et Hive account@orlandumike auquel je contribue à ma façon.

Suite aux différents travaux de Hive account@planetenamek sur son bot de curation DiscoSteem-Bot, j'ai apporté quelques modifications facilitant le travail de curation.

Concrètement, le bot détecte automatiquement toutes les contributions #steemactivites et les partagent sur le salon discord associé. Ceci permet d'avoir un accès plus rapide aux contributions. D'autre part, un upvote permet de publier automatiquement un commentaire permettant de promouvoir le projet.
Dernier point, j'ai ajouté une fonction de optout pour les steemians ne souhaitant pas recevoir de commentaire de promotion (oui ce n'est pas très RGPD friendly).

Blockchain is freezing

On commence à attaquer le dur...

En début de semaine, la blockchain steem s'est entièrement arrêtée !!
Une dingueurie incompréhensible lorsqu'on est habitué à la résilience du Bitcoin.

Le sujet a été abordé dans plusieurs articles mais en gros, le compte Hive account@nijeah a réalisé un power down négatif.

Cette transaction invalide a bloqué la production de blocs de la part des witness.

Heusement, *Steemit Inc a réagit en quelques heures en proposant le correctif suivant https://github.com/steemit/steem/pull/2583/files. Suite à cela, les witness (mais pas tous) ont appliqué le correctif.

Période estival oblige, pas mal de witness n'ont pas encore appliqué le correctif et sont donc exclus de la production de blocs. C'est pour cela que mon witness a légèrement progressé dans le classement.

Au delà de ça, j'ai quand même deux réflexions à ce sujet...

Quand le sage montre la lune...

...l'idiot regarde de le doigt.
Suite à ce bug, un certain nombre de personnes ont accusé le witness Hive account@netuoso d'être à l'initiative de la transaction. Erreur de sa part ou exploitation intentionnelle, ce dernier s'est défendu d'être propriétaire du compte Hive account@nijeah.

Même si c'était le cas, ce n'est pas vraiment le plus important. Initialement, ~~la blockchain~~ le bitcoin fonctionne dans un système non coopératif et sans besoin de confiance. Par conséquent, les noeuds (full node) ne se font pas confiance pour valider une transaction.

De ce fait, une blockchain doit encore plus reposer sur un mode de fonctionnement paranoïaque... Et en développement, une des règles d'or est de ne jamais faire confiance aux données soumises par un utilisateur.

Je trouve donc effarent qu'on soit si rapide à accuser quelqu'un alors que la démarche serait de se demander pourquoi nous sommes passés à côté d'une faille aussi béante.

Une blockchain est ouverte au quatre vents et il faut donc partir du postulat qu'elle est plus exposée aux attaques... Et je tiens à dire que la bêta ne justifie rien.

Décentralisons le dev

Si j'aime bien comparer sur le plan technique Steem à Bitcoin, c'est qu'il permet de se rendre compte de certains écarts assez incroyables.

Une chose frappante est la diversité des noeuds sur le réseau. Il en existe en C++, en Node.js en GO. Et c'est vraiment là qu'on se rend compte de l'activité de la communauté. Si le développement est poussé par l'équipe Bitcoin CORE, la communauté est suffisamment résiliente.

Et sur STEEM ? il y a :

steemd
steemd
steemd (j'ai failli l'oublier...)

Le malaise vient du fait qu'en l'état, le cycle de développement de la blockchain repose entièrement sur Steemit Inc. A quand de la diversité dans tout ça ? Je pense que cela permettrait d'avoir une expertise supplémentaire sur la compréhension du code.

HF20

C’est LE gros sujet du moment et qui anime les passions.

Steemit Inc a encore récemment fait une publication à ce sujet. Les promesses sont nombreuses :

modification de la curation
suppression de la limite des 20 secondes entre chaque commentaire
expiration des ordres de marchés
création de compte à prix réduit
meilleur allocation des ressources

Mais ici, je ne vais pas m’étendre sur chaque nouveauté et correctif. Je vais me concentrer sur l’aspect suivant.

With the current blockchain rules, if authors vote for themselves right away, they get their author rewards, plus 100% of the curation rewards from their vote, plus a portion of the curation rewards coming from everyone who votes for the post after them. Any other curator voting at the same time as the author would get 0% of the curation rewards. This gives the author an unfair advantage over other curators, because the author can earn additional curation rewards through self-voting.

In order to eliminate this advantage, the unused portion of the curation rewards will be returned to the rewards pool instead of being awarded to the author, thereby increasing the overall percentage of rewards that will be paid to curators. This will better serve the original mission of the curation rewards budget: to ensure that the Steem blockchain distributes rewards to the most valuable content.

self vote VS HF20

Steemit Inc explique à juste titre que le self automatique est assez injuste. En plus de ne pas participer à la part des curateurs (100% du vote revient à l’auteur), l’auteur va en plus récupérer une bonne partie de la curation (les 25%).

Pour rappel, quand un vote est réalisé dans les 30 premières minutes, une partie du vote est directement distribué à l'auteur (et pas dans la curation). Par exemple, a 0 minute, l'ensemble du vote est affecté à l'auteur (et rien à la curation).

Si Steemit Inc parle d’une répartition 75% (auteur) / 25% (curateur), la réalité tend plus vers 80/20 (voire plus pour l’auteur).

Hive account@paulag a récemment publié une petite étude statistique sur la curation dans la fenêtre des 30 minutes. Vous la trouverez ici.

On y apprend que :

47% des votes sont réalisés durant les 30 premières minutes;
27% des votes sont réalisés durant les 15 premières minutes;
84% des self votes sont réalisés durant les 30 premières minutes;
78% des self votes sont réalisés durant les 15 premières minutes.

Si ces chiffres indiquent l'utilisation massive du self vote, ils ne permettent pas de se faire une idée de son impact sur le reward pool. Hive account@paulag indique qu'il n'est pas vraiment possible de se faire une idée précise à ce sujet, elle tente tout de même une approximation via une note basée sur le nombre de vote, le nombre de Steem Power et le poids moyen du vote.

On trouve donc ceci.

Crédit :

Hive account@paulag

Ce qui donne sur le mois de mai le top auteur suivant.

Crédit :

Hive account@paulag

Malheureusement, je n'arrive pas à trouver de données récentes sur la distribution des récompenses.

Ce que promet le HF20, c'est de réduire la fenêtre de 30 à 15 minutes et de redistribuer le non-gain de curation au reward pool...

Pour illustrer mon propos, voici quelques exemples.

Lorsque que vous utilisez l'option self vote de busy, 100% de la curation ira à l'auteur. En HF20, 25% du vote ira dans le pool de récompense.

Lorsqu'un curateur vote à 15 minutes (7min30 en HF20), 75% plus 12.5% (50% des 25%) ira à l'auteur. En HF20, 12% du vote restera dans le pool de récompense.

Par conséquent, la récompense maximal de l'auteur sera capée à 75%.

Pour résumer, le système a été créé pour luter contre le vote automatique. Il a été contourné en permettant aux auteurs de récupérer une partie des 25% de curation.
Le HF20 vise à lutter contre cette dérive...

Une HF20 pour que les riches deviennent plus riches

C'est la thèse soutenue par Hive account@davemccoy dans l'article suivant. Redistribuer dans le pool de récompense n'est pas sans conséquence. En effet, ce dernier est réparti en fonction des votes de chaque publication. Ce qui veut dire que votre self vote à 1 cents sera redistribué aux plus gros articles...

Pire encore, l'usage des bid bots permettra de récupérer vos précieux self vote...

Mais attention, le but de Steemit Inc est bien de désinciter le self vote dans les 15 premières minutes.
Concrètement, il faudra que les fronts ends comme condenser (steemit) et busy :

désactivent l'option de self vote durant la rédaction de la publication
Avertissent les steemians souhaitant voter durant la fenêtre de 15 minutes

Néanmoins, il subsiste un problème plus gênant. Comme le décrit Hive account@tcpolymath dans sa réponse, il y aura également une désincitation forte pour les curateurs souhaitant voter un article publié dans les 15 premières minutes. Imaginons que je tombe sur article publié il y a 7,5 minutes, ais-je vraiment envie qu'une partie de mon vote reste bloqué dans le pool de récompense ?

Heureusement que la fenêtre a été réduite à 15 minutes...

Je suis donc assez dubitatif sur cette évolution. Si je pense que le système est beaucoup trop contournable, je ne suis pas certain que la HF20 aille dans le bon sens.

L'usine à gaz

La curation est un élément majeur de l'écosystème steem. C'est tellement important que le HF17 avait été rejeté par les witness.
1- En récompensant les premiers curateurs d'une publication, Steem Inc vise à promouvoir la recherche de contenu encore sous évalué;
2- Pour éviter que des bots votent en premier, Steemit Inc a instauré un système de "punition". Un vote anticipé récompense l'auteur au détriment du curateur trop pressé;
3- Pour éviter que l'auteur détourne le système à son avantage, on fait en sorte que son vote reste dans le pool de récompense;
4- Pour éviter le détournement du pool de récompense, on... ah zut, je suis dans le futur là.

Vous comprenez la complexité à créer un système juste?

Je suis persuadé qu'un système complexe est toujours à l'avantage d'un petit nombre. En effet, la complexité vise bien souvent à créer des **lignes Maginot** facilement contournables pour celui qui se donne les moyens. **Si Bitcoin est simple sur son aspect fonctionnel, c'est justement pour faciliter son accès au plus grand nombre. Et tant pis pour les inégalités tant que nous avons à notre disposition des outils accessibles pour améliorer notre vie et celles de autres.**

Voter avec ses pieds

Alors après tout ça, on pourrait me demander de ne pas appliquer le hardfork.
C'est tout à fait possible, mais sur steem, c'est marche ou crève. Lorsqu'il y a eu consensus dans le top 20 witness (plus de la moitié), le reste des witness n'ont plus qu'à suivre. Une refus de passer le HF revient à une exclusion dans la production de blocs.

Et contrairement à une blockchain classique, un HF sur *steem ne provoque de séparation de chaîne.

Vous aurez donc compris que pour les witness comme pour les steemians, le meilleur moyen de "protester" contre une consensus majoritaire est de trouver ceci...