Résolution de fork

Archives Discussion
1

Je viens d’avoir une idée :

Est-ce que ça aurait du sens que lorsque deux blocs trouvés en même temps, les nœuds prennent le bloc ayant le hash le plus dur à trouver. Par exemple, le bloc avec six zéros serait pris devant celui avec cinq zéros.

Merci de me donner vos contre argumentaires.

2

Contre-argument : savoir définir “en-même temps”.

2 Likes
3

Si les nœuds ont cette valeur réglée à dix secondes.
Ils choisiront le bloc généré dans les dix secondes ayant le hash le plus grand.

Autrement, si cette valeur est réglée à une minute.
Les blocs trouvés après ayant un hash plus grand pourrons remplacer les blocs valides.
C’est problématique dans le sens où une latence réseau est présente, les nœuds peuvent encore ce trouver sur des forks. Et, alors, la solution pour résoudre les forks est la résolution de forks actuelle.

4

On peut supprimer le “en même temps” et garder cette idée. Exemple :

Je suis un nœud et mon head est A1 (A représente la branche et 1 le block number)

Actuellement si je reçoit un bloc B1, je le stocke en bdd avec un indicatif fork=n (n > 0)

Au lieu de ça on pourrait adopter comme nouveau comportement :

Si B1 a un hash plus “dur” que A1 alors je revert d’1 bloc et j’empile B1.
Sinon je stocke B1 comme un bloc de fork (comme actuellement)

EDIT : Une attaque possible : continuer a calculer un bloc alternatif X1. les nœuds honnêtes eux seraient en train de calculer le bloc 2. Cette attaque est donc d’ampleur limitée, car a chaque nouveau X1 trouver il deviens de plus en plus dur de trouver un nouveau X1 pour spammer le réseau.

EDIT2 : Une autre version de l’attaque, brancher sur le réseau un supercalculateur qui ne calcule que des blocs vides, dans ce cas seul le facteur d’exclusion nous protège, ce n’est pas satisfaisant.

1 Like
5

J’y vois une fausse bonne idée, car quand j’avais A1 j’ai déjà démarré une preuve pour le bloc A2. Revert sur B1 va donc soit :

  • faire perdre du temps au réseau à calculer A2 puis à devoir calculer B2 ensuite (double calcul)
  • faire perdre du temps au réseau à avoir débuté un calcul sur A2 qu’il va devoir annuler pour reprendre un calcul sur B2

Donc à part permettre l’interruption des calculs du reste du réseau, je ne vois pas d’avantage à utiliser cet algorithme.

6

C’était cette 2ème option a laquelle je pensais, mais ce n’est pas un problème selon moi.
En revanche, j’ai de toute façon moi même conclu que cet algo permet une attaque de blocs vides donc il n’est de toute pas satisfaisant. C’était juste une expérience de pensée pour creuser l’idée de Moul :slight_smile:

3 Likes