D’accord mais il y a bien un moment ou si je sort un block et que je dis que je prétend avoir trouvé en 2020 les autres ne vont pas l’accepter car le timestamp est délirant en comparaison de leur propre horloge. (C’est exactement pareil que dans mon proto.)
Oui, mais pas relativement à leur horloge, relativement à celle du bloc. Donc par rapport au protocole.
C’est là tout l’enjeu. Se référer aux données communes et pas aux données individuelles.
2 Likes
Comment ça relative à celle du block je ne comprends pas? Le block c’est moi qui l’émet, je mets dedans le timestamp que je veux. En théorie rien n’empêche que 2 blocks soient espacés d’un interval aussi grand qu’on veut même si c’est très improbable dans un fonctionnement normal (mais ça arrive en cas de fork, ou quand quelqu’un sort une puissance de malade fait augmenter la difficulté puis se barre). Comment quelqu’un peut savoir que je mens dans le timestamp de mon block? Si on ne regarde pas l’horloge ça pourrait être tout à fait vrai qu’on est en 2020 (j’exagère).
En tous les cas dans la doc de bitcoin il n’y a priori pas de temps maximum entre deux timestamp de block, mais le timestamp est comparé pour être validé à un “Network-adjusted time”, qui se base sur les horloges système des pairs. Selon la doc que j’ai posté plus haut.
Bon enfin c’est pas très grave, il faut que j’y aille, merci pour la discussion.
Dans le protocole DUBP (Duniter Blockchain Protocol), le temps de référence que l’on nomme “temps blockchain” est la valeur du champ medianTime du bloc courant (bloc courant=dernier bloc).
Le champ medianTime a pour valeur la moyenne du champ time des medianTimeBlocks derniers blocs. medianTimeBlocks étant un paramètre monétaire inscrit dans le bloc genesis (24 dans le cas de la Ğ1).
En tant que forgeron du prochain bloc, tu peut inscrire la valeur que tu veut dans le champ time (la valeur de ton horloge locale si tu est honnête) mais ce champ ne détermine pas directement le temps blockchain. Pour influencer le temps blockchain d’une manière non négligeable, il te faut pouvoir calculer une part significative des 24 derniers blocs.
Or, la PoW du protocole DUBP est équipé d’un algorithme de difficulté personnalisé et d’un facteur d’exclusion qui rendent impossible le contrôle des 24 derniers blocs par 1 seul membre.
Pour être exact, si tu veut prendre le contrôle du temps blockchain il te faut N membres complices, N devant être au moins égal au tiers des membres calculant à l’instant de l’attaque.
Tout ceci rend la blockchain de la Ğ1 extrêmement résistante aux tentatives d’attaques sur le temps blockchain.
Dans une monnaie libre il est vital de se protéger des attaques influençant le temps blockchain car c’est lui qui rythme la création du DU et donc le respect du taux c de la monnaie (cf. TRM). Si tu a le pouvoir d’accélérer ou de ralentir le temps blockchain de façon significative tu peut modifier le taux c de la monnaie et donc faire en sorte que ce ne soit plus une monnaie libre !
Une force de la PoW est qu’elle permet a la blockchain de se munir d’une horloge commune pour réguler le rythme des blocs via la variation de la difficulté commune du réseau, si la différence du champ medianTime entre les bloc deviens trop faible la difficulté" commune augmente. A l’inverser si si la différence du champ medianTime entre les bloc deviens trop grande la difficulté commune diminue.
Dans l’absolu je ne suis pas opposé a ce que l’on abandonne la PoW un jour, mais cela ne se fera que si l’on trouve un autre mécanisme qui nous fourni toutes les garanties dont nous avons besoin, a savoir a minima :
-
Permettre a tout nœud membre ou miroir de déterminer quel prochain bloc est valide parmi tout ceux qu’il reçoit en se basant uniquement sur des données communes (donc pas sur son temps local). Cette subtilité est vitale pour éviter un réseau instable avec trop de fork : pour un même bloc donné, 2 nœuds honnêtes différents doivent se prononcer de la même façon concernant la validité ou non du bloc. Sinon ces nœuds vont diverger et créer des fork.
-
Anti-DDOS: Limiter le nombre potentiel de blocs valides différents, s’il y a 2 blocs valides différents en même temps, on a un fork avec 2 branches, ça arrive de temps en temps mais 2 branches c’est gérable, l’algo de résolution de fork rétabli un consensus réseau rapidement (en moins d’1h généralement).
En revanche, s’il est possible d’obtenir une dizaine de bloc valides différents voir plus encore on aura trop de fork dans tout les sens et ceux ci ne se résorberont plus de façon automatique(cad via l’algo de résolution des fork). forçant les membres calculant a effectuer une action de resynchronisation manuelle pour choisir une “bonne” branche pour continuer la monnaie. Ce type de situation très instable n’est pas acceptable pour une monnaie en production utilisée au quotidien par une masse conséquente d’utilisateurs. -
Être résistant aux manipulations du temps blockchain (qu’on peut nommer aussi “temps commun”).
-
Assurer une dilution du pouvoir en assurant une rotation dans l’écriture des blocs.
Ce que tu propose @pparent76 semble remplir l’exigence 4.
En revanche, ce qui est certain c’est que ta proposition est incompatible avec l’exigence 1 (qui correspond au point dont parle @cgeek) , donc pas utilisable pour nous en l’état.
Concernant les exigences 2 et 3, qu’en est t’il du niveau de satisfaction de ces exigences par ta proposition ?
Aussi quand tu propose de se référer a l’existant, il faut bien garder en tête que la Ğ1 est la seule monnaie libre au monde en production (je ne compte pas les monnaies de test) et que nous avons des exigences particulières que les autres crypto-monnaies n’ont pas notamment par rapport au mécanisme de création du Dividende Universel.
Nous ne pouvons donc, hélas, pas toujours reprendre tel quel ce qui fonctionne dans d’autres crypto.
2 Likes
En pratique, le DU ne rend pas la G1 différente des autres cryptos, donc vous pouvez très bien reprendre les algos qui fonctionnent déjà …
Oui je suis d’accord je point 1 n’est pas atteins.
Pour le point 2- il n’y aura ni plus ni moins de blocks valident qui arrivent que pour la POW a partir du moment ou tu règles la difficulté pour que les blocks arrivent à la même fréquence que tu aurai réglé la POW. Si tu prend 10 minutes il y a très peu de chances que deux blocs valides arrivent en même temps, en tous les cas pas plus qu’en POW.
Pour le point 3- la question ne se pose pas vraiment dans le sens ou justement le protocole ne se base pas sur le temps blockchain, mais pré-suppose un consensus sur le temps de chacun (à quelques secondes près de delta), soit directement du temps local, soit par synchro réseau au niveau du protocol p2p comme dans bitcoin. A partir du moment ou ce consensus est une évidence pour tous le temps donné dans les paquets ne peut être que le bon, au meme sens que les blocks seront valides selon les autres règles, la vérification en devient aussi évidente que n’importe-quelle autre regle et donc sera respecté au même titre.
Le point dur de mon protocol, c’est comment génerer du hasard qui ne soit pas sujet à bias problèmatique de la part d’attaquants, sans pour autant trop compliquer les choses.
La comparaison au temps local ne pose aucun pb en pratique, cf par exemple Tezos.
Salut 
si cela peut t’inspirer :
https://sawtooth.hyperledger.org/docs/core/releases/1.0/architecture/poet.html
Ca implique quand même que tout les noeuds soient synchronisés sur une source de temps (type ntp). Et que ce soit fait correctement, que ça ne fournisse pas un axe d’attaque potentiel sur le réseau (on peut imaginer un attaquant manipuler les horloges sur lesquels sont branchés les noeuds pour manipuler le temps blockchain par exemple).
Dans la pratique, je pense que les avantages dépassent les inconvénients (à condition de réussir à le faire marche de manière fiable et robuste… cf le post de @Max) :
- Dans le modèle de menace, un axe d’attaque “par la source de temps” parait fortement improbable. Et même si il arrivait, il impacterait le réseau internet de manière bien plus large que seulement duniter.
- La PoW coute cher, elle empeche de faire tourner Duniter sur des petits serveurs, et refroidit un peu les potentiels hébergeurs de noeuds
Pourquoi ne pas comparer le temps du nouveau bloc avec celui du bloc courant, en n’acceptant pas les nouveaux blocs post-datés au-delà d’une certaine limite par rapport au bloc courant ?
Pourquoi ne pas comparer le temps du nouveau bloc avec celui du bloc courant, en n’acceptant pas les nouveaux blocs post-datés au-delà d’une certaine limite par rapport au bloc courant ?
J’ai pas compris? Rien ne permets de savoir le delta entre 2 blocs, ni dans le POW ni dans ce que j’ai proposé. (même si on connait la moyenne, il peut y avoir des fluctuations importantes).
Dans la discussion le problème semblait être qu’il fallait empêcher les blocs excessivement post-datés, mais que cela supposait une mesure extérieure au protocole (la synchro via NTP). Du coup je me demandait si c’était pas plus simple de tout simplement vérifier si incoming_block.time - current_block.time < delta_max.
Comme ça le seul apport d’une horloge extérieure est (comme dans Duniter) lors de la construction du bloc par le mineur, ensuite on compare avec le commun.
incoming_block.time - current_block.time < delta_max.
Oui mais ça marche pas car il n’y a pas de limite maximum théorique entre deux blocs, et ce genre de condition pourrait bloquer la blockchain à tout jamais.
Je propose la chose suivante:
Pour chaque block reçut directement de l’émetteur lors de l’émission, le peer note la date de réception selon l’heure locale et le compare au timestamp, il en déduit un delta-t entre le timestamp du paquet et l’heure de réception.
Ensuite dès lors qu’il a reçut assez de block, il ne se base plus sur son horaire locale, mais sur son horaire plus la médiane des 100 derniers delta-t des 100 derniers blocks de la blockchain.
Cette solution fait dépendre le protocole de l’état de synchronisation des horloges des nœuds.
La comparaison avec le temps du dernier bloc fonctionne dans un cas normal, il bloque uniquement en cas de problème (arrêt trop long du réseau, désynchronisation massive…). On pourrait se référer au temps local pour la vérification des blocs seulement en cas de problème de ce type.
Remarque importante sur l’utilisabilité : on doit partir du principe que les utilisateurs de nœuds calculant (et miroirs aussi d’ailleurs) ne sont pas parfait et que donc une part non négligeable des nœuds ne seront pas synchronisés par ntp ou autre, même avec de très bon tuto.
Ce qui fait la force de la résilience du réseau c’est la simplicité d’usage de duniter : pour être membre calculant il suffit d’installer et de lancer le logiciel, la config par défaut fonctionne bien. La seule compétence nécessaire c’est être capable de choisir le nœud de confiance sur lequel se synchroniser et être capable de reset data and resync quand c’est nécessaire (en théorie ce n’est nécessaire qu’en cas de bug un d’incident réseau exceptionnel).
Ce qui en résulte: c’est qu’aujourd’hui il faut très peu de compétences techniques pour devenir membre calculant, et je trouve que c’est un bon point pour favoriser l’horizontalité et la résilience du réseau, je tiens a cette simplicité d’usage.
Alors certes, pour aller plus loin et contribuer au réseau, il faut etre capable d’ouvrir un port sur sa box et de configurer correctement duniter, c’est compliqué, mais :
- Ce n’est absolument pas nécessaire pour être membre calculant.
- Si vous avez Upnp d’activé sur votre box, duniter est capable de configurer automatiquement le réseau sans que vous n’ayez rien a faire, donc la encore c’est en réalité très simple.
Tout ça pour dire que personnellement je suis opposé a l’idée qu’il devienne nécessaire de maintenir sa machine a l’heure via ntp ou autre. Cela complexifierai fortement l’accès a calcul des blocs et bon nombre de membres calculants actuels ne pourrais plus l’être.
1 Like
@elois rien n’empeche que les requetes NTP soient faite dans le client de la monaie, et non au niveau de l’heure système, ou que le client inclue un protocole de syncrhonisation peer to peer: https://www.dis.uniroma1.it/~dottoratoii/media/students/documents/thesis_scipioni.pdf
Ca n’ajoute alors aucune complexité pour l’utilisateur.
Petite remarque: essayez de vous connecter à tor avec un ordinateur qui a une mauvaise date: vous ne réussirez pas à vous connecter au réseau.
Ps: je suis sur une piste pour générer du hasard sans biais.
1 Like
J’ai trouvé une méthode pour générer le hasard de manière non-biasée (* à une certaine probabilité faible près). Mon protocole va pouvoir être complet! Je vais rédiger tout ça, dans les jours qui suivent et je vous tiens au courant!
1 Like
Légèrement hors-sujet mais lié : https://fr.sputniknews.com/sci_tech/201907141041667291-le-systeme-de-positionnement-europeen-galileo-tombe-en-panne
2 Likes
De quoi nous rappeler que le temps ce n’est pas trivial, et qu’avoir un temps commun précis demande une incroyable complexité systémique.
Quand certains voient en la G1 la monnaie de post-effondrement, si l’on dépend d’un temps précis il n’en sera rien 
1 Like