Block issuance distribution

Tortue · 14 November 2016 16:09

Personnellement, j’apprécie le fait que l’on ne soit pas obligé d’avoir une machine de guerre pour miner des block.
j’apprécie également que ce soit le plus équitable possible entre les membres.
Maintenant je comprends qu’avoir des noeuds exclus du calcul de la POW peut poser des problèmes en cas de fork, ou l’une des branches est dans l’impossibilité de miner d’autre block car la plupart des nœuds sont exclus.
Mais ce problème sera-t-il toujours présent quand plus de nœuds seront dans le réseau?

Autre sujet (mais lié):
Pour moi il faut garder en tête l’impossibilité de calculer plus de 5 blocs consécutifs par un même membre.
Mais que ce passe-t-il si plusieurs membres (qui n’ont que la POW min car jamais miner de block ) se mettent d’accord pour calculer (par un super calculateur) des blocs consécutifs afin de supprimer un précédent transfert de la chaine?

cgeek · 14 November 2016 16:22

Pour cela, ils doivent donner leur clé privée au super calculateur. Ce qui fait qu’ils prennent le risque de perdre le contrôle total sur leur identité, leur compte en monnaie, et la production du DU.

Nul doute que cela se produira ne serait-ce que par extorsion du trousseau (via piratage par ex.), ce qui donne beaucoup de pouvoir à ce calculateur, c’est vrai. Mais ce potentiel de calcul est à mettre en balance avec la puissance totale du réseau, et donc plus y a de nœuds, plus ce pouvoir est dilué.

Maintenant, c’est aussi pour ce problème de “partage” de clé à un super calculateur que j’avais mis en place le mécanisme de rotation initial, jusqu’à DUP 0.4. Si l’on constate qu’il valait mieux le reprendre, on pourra toujours le faire. Mais plus ça traîne, plus ce sera difficile !

Inso · 14 November 2016 16:26

Je pense qu’exclure jusqu’à 1/3 du réseau est raisonnable. En général, dans les systèmes en haute-dispo, on considère que le quorum votant peut fonctionner tant qu’il reste 2/3 des nodes up. Donc ça me parait être correct. En dessous, on prend le risque que le quorum se bloque ou se split.

Tortue · 14 November 2016 17:03

avec une complexité personnalisée, ce n’est (presque) plus la “puissance totale du réseau”, mais bien le “nombre total de noeuds” qui permet de dilué ce pouvoir.

Qu’entends-tu par “le mécanisme de rotation initial”?
le faite qu’un membre est vite exclu dès qu’il a miné un bloc ?
Si c’est le cas, c’est ce que j’étais en train de décrire précédemment:

Rien n’empêche à un super calculateur de miner dans son coin un premier bloc avec la clef privée d’un premier membre piraté, puis un 2eme bloc avec la clef d’un autre membre piraté, et ainsi de suite. Afin de garder une complexité de calcul la plus faible possible. Puis de publier la nouvelle chaine d’un coup.

cgeek · 14 November 2016 17:07

Oui, mais exclu immédiatement, en fait.

Oui mais cette exclusion continue tant qu’1/3 de tous les membres calculant n’ont pas écrit eux-même un bloc. Donc sauf à avoir 1/3 des clés des membres calculant, la nuisance du super calculateur n’est que partielle.

Tortue · 14 November 2016 17:10

Ha bien vu
il me manquait cette info

Alors je vote haut la main pour la version 0.4 !

Inso · 14 November 2016 17:17

Dans la version 0.4, quelqu’un qui a calculé est exclu jusqu’à ce qu’1/3 des membres ait calculé un bloc ? Ca me parait énorme…

Moul · 14 November 2016 18:26

Une des raisons pour laquelle on est partie vers DUP 0.5 été le fait que dans le cas du réseau actuel de Test-net, avec une vingtaine de nœud membres, en cas de deux fork symétriques, les deux fork étaient bloqués étant donné qu’il arrivait qu’un nœud se retrouve tous seul a faire avancer la branche.
Ce 2/3 d’exclus n’était pas adapté aux forks avec cette taille de réseau monétaire.
Lors d’un fork, 2/3 de la branche principale se transforme en 2/3 sur chaque branche.
identités exclus / nombre d’identités qui calculent.
Sur une branche, le nombre d’identités exclus ne change pas mais le nombre d’identités qui calculent est celui du nombre total des deux branches.

Finalement, je commence à être convaincu que ça n’est pas possible qu’il y ait une équité entre des identités ayant un gros CPU et d’autres ayant un faible CPU. En même temps ça serait dommage pour ceux qui mettent a disposition une forte puissance de calcul de se retrouver à calculer le même nombre de nœuds que les autres.
Je pense pas qu’on revient à 0.4, car la fenêtre s’adapte mieux en cas de fork ? Pas sûr au final. Je vois pas comment gérer ce cas.
Dans le cas de 0.5, la fenêtre est plus grande et exclus plus difficilement en cas de fork. Avec cette proposition de 0.6, ça risque, en effet, de ressembler à 0.4.

Au final avec 0.5, la difficulté du réseau a beaucoup augmentée.

(Désolé, ce que j’ai écrit est très brouillon. Mais les idés sont là ! )

Inso · 14 November 2016 18:28

Est-il possible de n’exclure qu’1/3 des noeuds tout en améliorant la distribution des blocs ? (cf mon commentaire plus haut, dans les réseaux distribués, il faut tenter d’avoir toujours 2/3 du réseau qui peut travailler…)

cgeek · 14 November 2016 18:32

edit : ma réponse était pour @inso, mais avec le déplacement de sujet, ça indique que c’est pour Moul.

1/3 des membres qui calculent, c’est-à-dire ceux qui ont émis un bloc dans la fenêtre courante.

Ça paraît beaucoup, mais ça veut aussi dire que les 2/3 restant calculent en permanence. A quelques variations prêt bien sûr, il y en a qui arrêtent et d’autres qui se mettent à participer.

Mais pour résumer, on a 2 visions :

une qui consiste à dire que n’importe quel participant devrait avoir la capacité de poursuivre la blockchain tout seul s’il le souhaite (1)
une qui consiste à dire que ce bien est commun et qu’on ne peut pas en prendre le contrôle soi-même, mais que des semblables sont nécessaire à la poursuite de l’aventure (2)

A noter que 1) est en réalité toujours possible, on peut forker la blockchain quand on veut par exemple pour changer la difficulté et faire passer une blockchain du mode 2) vers 1).

J’étais parti pour 2) jusqu’à la 0.4, j’ai voulu tenter 1) depuis la 0.5.

edit 2 : mais en effet, le problème majeur que l’on avait c’était les forks, mais ces forks ont aussi leurs raisons : notamment parce que je propageais la nouvelle version du protocole de façon instantanée et non coordonnée, contrairement à la 0.5 qui a été planifiée, où il n’y a eu aucun fork majeur.

Si l’on sait éviter les forks majeurs, alors il n’y a pas vraiment de problème à avoir un algo à la 0.4.

Tortue · 14 November 2016 22:14

en fait je ne comprends pas
Pour moi cela ne corrige pas le problème, imaginons un vol de 6 identités membres (clef privée/publique) qui n’ont jamais minée (=> pow min et non exclu) il est alors possible de miner 6 blocs consécutifs grâce à chacune de ces 6 identités.

Avec le system de POW personnalisé (ou exclue) cela réduit drastiquement la complexité moyenne de la blockchain et permet de créer une nouvelle version de la blockchain bien plus facilement.

plus j’y réfléchis, plus j’ai peur de la POW personnalisé.

cgeek · 15 November 2016 08:12

Oui, mais ça ne dure que 6 blocs. Sur 200 nœuds calculant, c’est 3% du temps qu’ils peuvent monopoliser. Et encore, cela suppose que le super calculateur soit largement plus puissant que les 194 nœuds restants, cela a un coût non négligeable pour une gêne assez infime, tout en sachant que la fonction de hashage reste aléatoire.

Par ailleurs, rien ne nous empêche, nous non plus, de calculer des blocs vides ou des blocs qui ne contiennent que des données qui nous intéressent personnellement. Nous avons alors un comportement similaire au super calculateur, sans avoir sa capacité de calcul. Si tout le monde agit en ce sens, la monnaie fonctionnera tout aussi mal, voire très mal.

Au final donc, ce n’est pas tant le super calculateur le problème (sauf en 0.5, là oui c’en est un) que la volonté des membres de sécuriser sa monnaie en démultipliant le nombre de nœuds pour la faire fonctionner.

C’est une fausse peur, car quand tu regardes Bitcoin ou les altcoins à base de PoW, là c’est clairement la voie royale pour avoir un contrôle centralisé. D’ailleurs c’est déjà le cas, il y a des “pools”. Et l’inquiétude grandit chaque jour, car l’intérêt pour le minage baisse (moins de coins à miner) ce qui va à terme signifie la mort de la monnaie (voir le cas de Auroracoin qui est mort justement par manque de puissance de calcul faisant balance à un attaquant).

D’ailleurs Bitcoin peut dores et déjà être tué : il suffit de voir qu’il y une puissance globale au réseau et que celui qui le veut peut investir un gros paquet de blé dans un super-calculateur et s’amuser à créer des blocs vides. Et avec les banques qui peuvent créer de la monnaie à volonté, c’est tout à fait faisable. Bitcoin est laissé vivant, il faut bien en avoir conscience.

Alors que dans un système qui réduit les possibilités d’écritures à des membres identifiés, avec un algorithme s’assurant d’une certaine rotation, là ça pose beaucoup plus de difficultés.

A mon humble avis.

Tortue · 15 November 2016 09:05

Je ne parle pas d’un déni de service, qui lui reste effectivement tout à fait limité (et peu d’intérêt a mon sens, sauf peut être pour les banques en place) mais je parle plus dans le cas d’une place de marché qui échange la monnaie libre contre d’autres monnaies. Où le but de l’attaquant est de supprimer de la blockchain le transfert de monnaie envoyé à la place de marché qu’il a effectué précédemment. (possibilité de dépensé plusieurs fois la monnaie de l’attaquant)

un ti exemple ici:
http://www.gldcoin.com/documents/GoldCoin_0.7_51percent_defense_october_11_2013.pdf

cgeek · 15 November 2016 09:38

Ah oui, mais non, pour plusieurs raisons :

déjà le principe des crypto-monnaies des 6 blocs d’assurance du transfert : on considère un bloc comme entériné à partir de 6 autres blocs au-dessus. Si dans Duniter c’est plus, hé bien il suffira de dire que c’est plutôt 8, 15 ou 30. C’est moins bon que dans Bitcoin, mais ce n’est pas le plus important.
dans Duniter, pour que le réseau suive un fork, il faut 6 blocs au-dessus de la branche actuelle, donc là il faudrait au minimum 12 blocs consécutifs à l’attaquant pour annuler la transaction (en réalité, il y a aussi une contrainte de 30 minutes d’avance, mais l’attaquant peut donner une accélération momentanée pour y palier). [1]

[1] A noter qu’aujourd’hui ce “6 blocs + 30 minutes d’avance” est une valeur en dur, totalement arbitraire et qui n’a rien à voir avec le protocole. On pourrait tout à fait la changer pour dire “suis la branche qui a plus de [1/3 x nombre de calculateurs] de blocs supplémentaires”. Le suivi d’un fork est alors conditionné à ce que cette branche soit réellement suivie par plus d’un tiers des calculateurs.

Tortue · 15 November 2016 10:16

Pour supprimer une transaction de la blockchain aujourd’hui il faut 6 bloc (+30 min) pour qu’elle soit acceptée par le réseau.
Les blocs supplémentaires ne sont que la contrainte que le vendeur impose. Donc oui ça peut être 6 blocs de plus ou 8, 15 ou 30 mais c’est un choix du vendeur, je doute que la boulangerie du coin me demande d’attendre 30bloc avant de partir avec ma baguette ^^.

oui, c’est peu être dans ce sens qu’il faut réfléchir,
mais si on cherche à avoir [1/3 x nombre de calculateurs] de blocs supplémentaires
les fork risques de durée vraiment longtemps du coup…

Je ne suis pas là pour critiquer, mais juste que l’on réfléchies ensemble au risque potentiel et les moyens d’y remédier (si risque il y a). Car c’est la première fois qu’une POW personnalisée est mise en place, il faut faire attention.

cgeek · 15 November 2016 10:45

Pas plus qu’il ne veut bien attendre 6 blocs Bitcoin non plus

Les places de change, tout comme le boulanger, peuvent utiliser d’autres mécanismes pour réaliser des opérations rapides. La blockchain n’est que l’endroit où l’on consigne finalement les opérations résultantes, un peu comme les banques ne réalisent pas systématiquement des transferts de monnaie interbancaires, mais plutôt le résultat de fin de journée.

Ça dépend du niveau de fork et de sa nature (en 0.4 j’entends).

Imaginons 100 calculateurs : si 2 d’entre eux forkent, pour les 98 autres c’est comme si rien ne s’était passé. Si 20 forkent, cela devient plus long. Mais on peut imaginer d’autres cas extrêmes :

33% forkent, mais ces 33% sont aussi le 1/3 exclu de la preuve de travail, ils sont alors bloqués, et finiront par rejoindre les 2/3 non exclus.
50% forkent, dont le 1/3 exclu. Il reste alors 17% des nœuds capable de calculer la suite, face au 50% de nœuds n’ayant pas forké.
66% forkent, dont le 1/3 exclu. Il reste alors 33% de nœuds sur la branche “principale” face au fork. C’est du 33% face à du 33%, c’est le pire des cas.

Alors c’est vrai, il est possible d’attaquer la blockchain, ce d’autant plus que le nombre d’attaquants est proche ou supérieur à 1/3 des calculateurs.

Donc parmi les solutions possible à ce problème en 0.4 : augmenter le nombre de nœuds pacifiques, de façon à éloigner le plus possible l’attaquant d’une prise de contrôle par 1/3 bloquant.

Je n’en doute pas au contraire j’apprécie de ne pas être le seul à me pencher sur ce problème, j’ai aussi besoin d’aide pour orienter le projet vers ce qui nous conviendra le mieux.

Tortue · 15 November 2016 11:10

Juste pour confirmer si j’ai bien compris ce que tu proposes,
imaginons qu’il y a 5000 noeuds qui calcule les blocs (comme actuellement pour le bitcoin, même si ce n’est pas demain que l’on aura autant de noeuds)
imaginons qu’il n’y a que 1 seul noeud qui fork
celui-ci devra attendre 1667 blocs (5000/3) avant de rejoindre la branche principale?

cgeek · 15 November 2016 11:18

Si l’on ne met pas d’autre condition, oui.

1667 blocs * 5 minutes par bloc = 8335 / (60 * 24) = 5,78 jours

Un nœud qui forke tout seul, ou même un gros groupe aurait besoin de 5-6 jours pour résorber le fork. Pour une monnaie importante (5000 nœuds), cela ne me choque pas, l’inertie est grande.

Après, il est toujours possible d’intégrer d’autres conditions :

déjà en ajoutant des capteurs “je suis bloqué” et “les autres avancent”
en choisissant tel fork plutôt que tel autre, par exemple en sélectionnant celui qui a le moins d’émetteurs (pour contrer une attaque de nouveaux calculateurs)
…

Mais ce qui est bien, c’est qu’on n’a pas besoin de changer le protocole pour ça.

Tortue · 15 November 2016 13:20

Oui cela fait 5-6 jours dans le cas où il n’y a qu’un nœud qui fork, mais si c’est un gros split, la complexité moyenne de la blockchain va faire ralentir chacune des branches…
Après je ne sais pas sur combien de blocs précédant tu te bases pour faire la moyenne de la complexité.
Mais à première vu je trouve ça super long pour trouver un consensus.

Et du coup les commerçants ne devraient-ils pas attendre cette même règle avant de valider une transaction? Afin d’être sûr que la branche où a été écrite la transaction soit validée par consensus?

cgeek · 15 November 2016 14:33

Pour l’instant en tout cas, on reste sur la formule “6 blocs + 30 minutes d’avance”. C’est un problème qu’on pourra résoudre plus tard, hors protocole, on a le temps d’y repenser.

J’ai déjà répondu :

Par exemple, tu peux avoir un compte dans une banque en monnaie libre qui peut servir pour les paiements instantanés, ou encore en utilisant une version papier de la monnaie. Il y a plein de façons de faire, et la blockchain n’a non seulement pas à répondre à toutes ces problématiques, mais en plus n’est pas la meilleure pour toutes les situations.

Cela viendra au fur et à mesure. En attendant, tu peux demander à ton boulanger de te faire une ardoise !