En discutant aujourd’hui, on m’a dit que pour gérer un grand nombre de transactions, les monnaies libres n’auraient pas d’autres choix que de collecter un impôt pour financer l’installation des nœuds.
Effectivement, si on se place dans un contexte futuriste où les Monnaies Libres deviennent la norme. Il pourrait y avoir un millier de monnaies libres pour, au pif, ~16 milliards d’être humains. (À moins d’augmenter la toile de confiance ou de trouver une autre manière de garantir un unique DU par personne.) Il y aurait aussi des millions de transactions par jour.
Comment gérer le nombre de nœuds nécessaires à un tel réseau ? En comptant sur les bonnes volontés et le bénévolat ? J’aimerais y croire… En installant un nœud Duniter sur chaque modem internet ? En finançant par don des associations neutres pour monter et maintenir des nœuds ?
Je n’ai pas réussis à trouver de solution aux problèmes liés à la montée en charge. Si vous aviez des idées…
Oui les idées ne manque pas, entre les LN les side chains et autres, je ne vois aucune barrière absolue a ce problème
Ensuite ce n’est pas un “nombre de nœuds” qui est nécessaire mais plutôt une capacité totale d’absorption de la part du réseau, on en a beaucoup discuté avec @nanocryk, ya moyen a terme de faire quelque chose d’optimiser a coup de DHT et co, bref il n’y a pas de problème il y a que des solutions
Une idée de protocole est en cours de travail et pourrait permettre de faire passer à l’échelle Duniter ainsi que d’augmenter drastiquement ses capacités. A pas besoin d’impot pour ça
@elois, je n’ai pas dis que c’était vrai. J’ai dis que c’était quelque chose qu’on m’avait dis au cours d’une discussion et que je n’avais pas trouvé comment y répondre.
@nanocryk, il y a déjà des infos quelque part à ce sujet? -
J’en ai pour l’instant surtout discuté avec @elois en privé, mais je pense ouvrir un sujet public quand la RFC sera avancée à ce sujet. La RFC est disponible ici, mais attention car elle est en cours d’écriture et contiendra sûrement quelques erreurs avant les revues groupées.
Juste une idée qui me passe par la tête : n’y aurait-il pas moyen de baisser légèrement la difficulté lorsqu’il y a beaucoup de transactions, afin d’accélérer la production des blocs, et faire l’inverse en périodes creuses ? Bien sûr, en laissant la difficulté dans une fenêtre raisonnable (si on produit des blocs trop vite, on sait que le réseau devient instable, à l’inverse personne n’a envie d’attendre une heure pour que ses transactions soient acceptées). L’avantage étant qu’en période de pointe la validation des transactions aille plus vite pour un grand nombre d’utilisateurs, et qu’à l’inverse en période creuse, moins de blocs soient forgés, qui prennent de la place pour rien dans la blockchain. Je ne pense pas que ça compromettrait la sécurité tant qu’on reste dans des fenêtres de temps raisonnables. Mais bon, c’est peut-être une idée foireuse.
L’historique complet de la blockchain n’aura plus besoin d’être stocké dans ce nouveau protocole. La seule limite qui sera imposée sera la taille maximum des blocs de telle manière que toute personne ayant un débit descendant et montant supérieur à une valeur pourra participer. La première proposition est de 100kbit/s alloué aux transfert de blocs, ce qui fait des blocs de 10Mo, sachant qu’on laisse un peu de place pour d’autres échanges (réception de transactions à écrire dans la blockchain, résolution des forks, etc).
Il n’y a pas de gaspillage de place si la blockchain ne prend pas plus de place au court du temps Avec un historique de résolution de fork de 100 blocs le maximum d’historique a stocker est d’environ 1 Go. Avec quelques autres données à stocker à côté, on ne devrait pas dépasser les 1.5 Go pour avoir un noeud de vérification, auquel tu rajoute la taille de la piscine pour un noeud calculateur.
Ça sera expliqué dans la RFC. Les données seront stockées dans des nœuds “instances” pour les clients (stockant uniquement les données des clients qui font appel à lui), et en plus de ça l’utilisation d’un DHT pourra permettre de distribuer le stockage des données sur le réseau.
@jytou en fait c’est déjà le cas puisque la difficulté du réseau s’adapte au temps qui est mis pour trouver un bloc. Donc si les blocs mettent plus de temps a être générés par contiennent plus de données ce temps est déjà pris en compte dans le calcul de la difficulté commune
Non je pensais par exemple à générer 1 bloc toutes les 2 minutes en heure de pointe et toutes les 10 minutes quand il n’y a pas de transaction (genre la nuit, quoi). Quelque chose comme ça.
EDIT : non c’est un mauvaise idée, la taille des blocs peut augmenter autant que nécessaire, mais il faut garder une fréquence cible fixe pour le rythme des blocs !
@jytou le rythme des blocs c’est comme un métronome, un repéré sur lequel se basent plusieurs calculs important : notamment le calcul du temps blockchain ainsi que le calcul de la difficulté commune du réseau, ce temps cible doit impérativement rester fixe !
