Juste au niveau de la terminologie, je propose d’utiliser ces termes :
preuve de travail (PoW) : protocole de communication, niveau réseau
résolution de fork : protocole local de sélection de branche suivie
J’insiste sur ces définitions, car dans Bitcoin tout est mélangé et cela apporte de la confusion.
La preuve de travail est bien au niveau de la couche réseau, elle sert de métronome à l’ensemble des pairs du réseau pour faire évoluer leur blockchain respective, dans l’espoir qu’elle soit commune.
La résolution de fork est bien un algorithme local, personnel, et qui n’a pas besoin d’être commun à tous. Par exemple, je connais l’algorithme de @Moul sur TestNet : quand il voit que ça forke, il choisit lui-même la branche qu’il veut aider. Les branches ETC et ETH ne sont pas autre chose. Bien sûr il est possible (et souhaitable) d’avoir un algorithme qui fait ça tout seul, c’est infiniment plus efficace.
En fait c’est plus que 1667, puisque la branche locale peut aussi avancer simultanément ce qui incrémente d’autant l’avance nécessaire par rapport au point de fork.
Mais bon tu vois l’idée : on peut mettre la résolution de fork qu’on souhaite, il existe une infinité de possibilités. Ce n’est pas un problème fondamental à mes yeux, bien qu’important à résoudre dans les années à venir.
A une époque, la résolution de fork de Duniter refusait tout bonnement de rejoindre un fork dont le point de fork était plus de 100 blocs en arrière. Ce peut être une solution, très simple à réaliser.
Ha pas bête, autoriser de rejoindre un fork seulement si c’est 5 blocs maxi en arrière et 6 blocs ou plus d’avance
(pour notre exemple: si la place de marché a bien attendu 6 blocs, la blockchain ne pourra être réécrite)
mais du coup en cas de split d’internet au bout d’un temps les fork se bloque et ne convergera jamais
donc ajouter une autre condition, par exemple une fois les 5 blocs dépassés,
rejoindre le fork qui contient le plus de noeuds membres.
Ce peut être tout simplement ça l’algorithme : rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre). Aujourd’hui Duniter n’a pas de vision du réseau façon Sakia, mais c’est assez simple à ajouter.
Ce problème devient également corrigé par la règle: rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre)
cette méthode à l’avantage de trouver un consensus extrêmement rapidement.
Bon il faut quand même ajouter une petite condition en cas d’égalité parfaite, prendre la branche qui a la bockchain la plus longue.
Arrivez-vous à trouver des cas dangereux avec cette méthode?
Je cherche différente attaque possible, mais rien de réellement faisable si il y a un nombre de noeuds conséquent.
mais par sécurité je rajouterais la condition que tu avais préalablement:
Pour éviter un drop complet de la blockchain en local. mais l’attaque semble quand même très compliqué à réaliser pour la propager à l’ensemble du réseau.
Pour l’instant je n’en vois pas, mais il faut quand même trouver un moyen d’obtenir l’état du réseau avec 5.000 nœuds. Ce n’est pas si trivial que ça ! Mais possible, à n’en pas douter.
oui j’imagine…
En plus des contraintes réseau, il va falloir vérifier si chaque nœud est bien membres dans la blockchain.
et Je propose que la réponse de l’état d’un nœud soit signé par la clef privée du noeud, afin de s’assurer que l’on parle bien au bon nœud.
mais on pourrait aller bien plus loin avec ce principe de signature:
il serait possible d’éviter ces 10000 connexions, (5000 inputs, 5000 outputs) pour chacun des noeuds avec un système de cache, je m’explique:
quand on interroge un noeud, celui-ci renvoie toute sa vue qu’il a en cache, avec l’état de chaque noeud, dans l’état de chaque noeud en plus du numéro de bloc, hash, et autres info => on ajoute un timestamp de quand il a été requêté pour la dernière fois.
Le tout signé par la chef privée du nœud correspondant
Dans cette grande liste reçu, si ce timestemp + X min est dépassé pour certains noeuds, alors ont considère que les infos ne sont plus valables et donc on va aller interroger le premier noeud expiré directement.
Celui-ci nous renverra ses infos à jour mais également sa liste complète de l’état des autres noeuds, cette nouvelle liste complète permettra peut-être d’éviter d’aller interroger d’autres noeuds qui avaient également un timestamp +x. Min dépassé, et on continue ainsi jusqu’à obtenir une liste complète des nœud à jours.
Grâce à cela on limite très très fortement les communications entre tt les nœuds.
et comme chaque état d’un nœud est signé par sa clef privé, il n’y a aucun risque de falsification.
j’ai réussi être compréhensible?
Edit: du coup la vue du réseau par les client (sakia/cesium) devient scalable et donc réellement faisable (ce qui n’était pas le cas pour moi avant)
Oui j’ai bien compris : on demande à un nœud les dernières infos qu’il connaît, ce qui évite de démultiplier les requêtes.
Comme ça, je dirais que le seul point qui me gêne est : que vaut ce “timestamp signé” ? Car c’est sur lui que tout repose. Notamment un nœud peut marquer absolument n’importe quelle valeur, contrairement à un blockstamp (n° de bloc + hash) qui ne peut être qu’une valeur passée. Donc un nœud peut facilement “changer d’avis”.
pas vraiment car,
si le noeud au moment du requêtage direct, répond un timestamp qui n’est pas proche du timestamp du requêteur, on peut simplement l’ignorer.
maintenant as tu dans duniter une valeur de temps synchroniser entre les nœud? le problème viens probablement de là…
Edit: il est vrais qu’une coalition entre 2 nœud peut permettre d’ajouter dans la grande liste d’etat des noeud sur le noeud 2 un faux timestamp émise par le noeud 1.
mais si un noeud 3 requête le noeud 2 et trouve un valeur future du timestamp du noeud 1 (Temp actuel +X Min) alors il supprime le noeud1 de sa grande liste (et pourquoi pas le nœud 2 par la même occasion ^^)
et si ce faux timestamp est un temps déjà dépassé, le noeud 1 ne gagne qu’a se faire légèrement flooder (et ignoré a chaque fois)
J’ai pensé à la possibilité autre qui serait qu’une ID ayant déjà calculé “2 / nombre de noeuds calculants” en % des x derniers blocs calculés (par exemple l’équivalent de 1 jour de calcul ou 24h00 / 5 minutes par bloc par exemple), devrait attendre qu’ 1/3 des autres noeuds actifs aient calculé “1 / nombre de noeuds calculants” eux-mêmes sur 1 jour glissant, de manière à ce qu’il n’y ait jamais sur 1/3 des noeuds un noeud ayant plus de (1/nombre de noeuds calculants) de blocs calculés sur la dernière période de temps de calcul (1 jour).
Avec 10 noeuds, cela signifie que sur 1 jour glissant, aucun noeud ne devrait aller au delà de 2/10 = 20% des blocs calculés sur les dernières 24 heures.
L’avantage de la POW de la 0.4 est qu’un membre ne peut bloquer la blockchain que 5 min toute les (NB noeud) * 2/3 * 5min
Alors que la technique que tu proposes permet de calculer plusieurs blocs consécutivement, et permet donc un déni de service de la blockchain sur une durée plus longue. (sauf bien sûr s’il y a minimum 576 nœuds ce qui impose 1 bloc maximum par 24h par ID membre)
je suis d’accord que cette nouvelle idée est bien mieux si l’on garde la méthode actuelle de résolution des fork (6 blocs supplémentaires + 30 min), mais semble moins bien que la 0.40 si une autre méthode de consensus plus rapide est mise en place (comme proposé précédemment)
Dans le cas ou l’on garde la méthode actuelle de résolution des fork (6 blocs supplémentaires + 30 min)
cette nouvelle technique facilite également la réécriture d’une chaine à part, plus rapide, pour la publier plus tard, afin de supprimer une transaction préalable. car il y a moins de comptes membres à voler pour générer des blocs consécutifs (dans le cas de la présence de peu de noeuds dans le réseau [< 576] )
Le prestataire n’est pas obligatoirement une banque comme celles que l’on connait. Un gestionnaire de compte comme le -compte nickel- fait parfaitement l’affaire…
Le protocole en version 0.6 est désormais exploitable. Nous pourrons donc voir dès demain l’impact du retour de l’ancienne règle de difficulté 0.4 (légèrement modifiée toutefois).
An interesting thing would be mesure this relatively to the handicap, which is not shown here. Pafzedog issues more blocks than others, but his personal difficulty is also higher.
Suite à notre discussion sur le chat, je reprends les trois points de tortue qui me semblent corrects :
le déni de service lui est réglé par le fait que seuls les membres peuvent miner + le protocole d’exclusion de la 0.40.
la double dépense par l’envoi de 2 TX simultané doit être réglé par un mécanisme de consensus plutôt rapide (et pas 1667 bloc) afin d’être sur que tout le réseau est OK pour dire que ces coins reçus sont bien a moi (6 blocs me semblent bien)
la réécriture d’une chaine à part, plus rapide, pour la publier plus tard, afin de supprimer une transaction préalable, est le gros point noir d’aujourd’hui. Car facilement réalisable avec le piratage de la clef de quelques identités membres, et extrêmement facilité par la preuve de travail personnalisé qui réduit fortement la complexité moyenne de la blockchain.
Et je cite cgeek :
Ce peut être tout simplement ça l’algorithme : rejoindre systématiquement la branche où l’on observe le plus de calculateurs sur le réseau (à raison de 1 par membre). Aujourd’hui Duniter n’a pas de vision du réseau façon Sakia, mais c’est assez simple à ajouter.
Qui d’un algo de la forme suivante :
Quand un noeud ajoute un block sur son HEAD, il broadcast le block ET ajoute sa signature au broadcast
Quand un noeud reçoit un block d’un fork différent, il switch si les signatures accumulées sur ce block sont plus nombreuses
Dans cette forme, pas besoin de connaître tous le réseau pour observer la majorité : le broadcast de signatures et leur accumulations permet de savoir de manière isolée quel block est majoritaire dans le réseau.
