Après le prix de l’innovation Open Source attribué à axiom-team.fr en décembre dernier pour son action à la promotion de la monnaie libre.
Ce projet a reçu le Label "MIZ " de la part de la Fondation madeinzion.org
Je n’avais pas rencontré ce problème spécifiquement mais j’ai conscience de l’importance qu’a la façon d’agréger les sources sur la blockchain. Plus petites d’abord. Plus vieilles. Plus grosses… Chaque choix a un impact!
Et de toute façon ça ne pourra jamais encaisser 1000 TX/s
Alors temporiser et consolider est nécessaire.
Zen dans ipfs et cron ont résolut ce problème
Et ssb-g1-tip l’expérimente.
Alors déjà le TPS de visa est de l’ordre de 1700, il n’y a donc pas besoin de beaucoup plus si on voulait une même monnaie libre pour les 7 milliard d’être humains (mais avoir une même monnaie pour toute la planète ne me semble pas souhaitable).
En tout les cas il existe plusieurs blockchain qui dépassent ce TPS, notamment : fleta, eas, qtum, tron, etc
Ce qui ne veut pas dire que ce doit être un objectif, en dessous de 100 millions d’utilisateurs ont a pas besoin d’un tel TPS, je voulais simplement rappeler que la barrière n’est pas technique, les solutions techniques existent pour avoir de très bon TPS sur blockchain. Sans parler des Lighting Network qui permettent d’aller bien plus loin encore…
Pas toutes en effet. Mais de toute façon nous n’avons pas besoin de 1000 TPS aujourd’hui. Et avec les Lightning Network (qui sont dans notre roadmap) ont pourra largement dépasser les 10000 TPS (et plus encore), en restant basé sur notre blockchain, donc je ne vois pas l’intérêt d’abandonner le concept de blockchain, ni à court terme, ni a long terme
Le median time blockchain ressemble beaucoup à la synchro des GPS
SI ce n’est pour que les trains ne se percutent pas…
Parfois, on est pas obligé d’avoir une synchro temporelle aussi globale pour opérer nos transactions…
Le GPS c’est cool, la montre poignet aussi
Question stupide:
Par analogie, je me demandais si dans le protocole blockchain, les noeuds envoyaient des messages contenant leur heure relative. Cela permettrait de caler une synchro temporelle de l’ensemble comme les horloges du réseau GPS?
La synchronisation du temps n’est qu’une propriété parmi d’autres tout aussi indispensables qu’apporte une blockchain, à savoir notamment :
La garantie de l’impossibilité des doubles dépenses : grâce au consensus sur la transaction retenue dans le cas où plusieurs transactions tentent d’utiliser les mêmes sources.
La garantie de pouvoir imposer et vérifier de manière décentralisée des règles de gestion : notamment toutes les règles de gestion de la wot qui sont complexes et qui nécessitent forcément un consensus pour empêcher la création de compte qui ne respecterait pas les règles.
Ces garanties sont indispensables pour la réalisation d’une monnaie libre décentralisée, et aujourd’hui il n’existe aucun concept éprouvé autre que la blockchain qui apporte ces garanties.
Oui je connais les garanties que me propose une chaine de blocs, mais
Et le problème est lié au temps et à l’assemblage cohérent des blocs…
On retrouve ce paramètre comme Indiqué dans les timestamp, et on ajoute celui que prend un nœud à trouver le nonce (et pas en même temps qu’un autre)
Ainsi, ma question porte sur le détail protocolaire “blockchain” pour savoir si en pratique un mécanisme spécial existait pour caler le “timestamp” des noeuds?
La question n’est pas très claire, je ne sais pas exactement ce que tu demandes, mais je vais te décrire le mécanisme du “temps blockchain”, es espérant que ça réponde a ta question:
Chaque noeud honnête est censé indiquer dans ses blocs le timestamp UTC au moment de la création de leur contenu (donc avant la PoW).
Comme on part du principe qu’il peut y avoir des noeuds malhonnêtes qui vont “mentir” en inscrivant un faux temps dans leur bloc (pour fausser le rythme de création du DU par exemple), le temps considéré pour la monnaie est un “temps blockchain” qui est défini comme étant la moyenne du timestamp inscrit dans chacun des 24 derniers blocs.
Il y a également des limitations dans le timestamp qu’un noeud peut inscrire dans son bloc, il ne peut pas être antérieur a celui du bloc précédent, et il ne peut pas être plus de 2h dans le futur par rapport a celui du bloc précédent.
En fait, c’est la malhonnêteté de comptage des noeuds en G1 et en temps qui doit être contrôlée
Ne pourrait-on pas introduire dans le protocole un « timestamp » sync obligatoire des noeuds (sécurisé par chiffrage signature) qui si ils divergent trop (de la moyenne atteinte) se font jeter (si l’écart type est trop grand)? Le mode TCP dans l’UDP du temps.
Un peu comme les satellites GPS ont du faire entre eux…
C’est déjà ce qui est fait, le timestamp fourni par chaque noeud est déjà signé par ce dernier puisque contenu dans un bloc signé, bloc qui est déjà refusé si le timestamp donné diverge trop.
Relis attentivement ma réponse au dessus, et en vu de tes questions./propositions il me semble que tu à besoin de réviser comment fonctionne une blockchain, je t’invite a (re)voir cette conf : https://www.youtube.com/watch?v=1ZOb7XDk3Dc
Je ne vois nul part de synchro ntp. A part des actions de bânissement après coup (2h de décalage quand même), j’ai du mal à identifier comment se pratique l’action de convergence du timestamp de chaque noeuds? Le timestamp évolue-t-il vers (T+T’)/2 ?
Si cette propriété était acquise par le réseau, on pourrait éjecter des bad nodes avec plus de fermeté.
je ne voit pas ce que ntp viens faire la dedans, ce n’est pas notre partie.
La blockchain traite de ce qui est collectif, pas de ce qui concerne la configuration d’un serveur en particulier.
ntp est un protocole réseau ouvert et antédiluvien… il sert à synchroniser l’horloge des machines… il y a d’autres protocoles de ce type certainement… mais je me demande pourquoi la « blockchain » ne l’a pas embarqué dans ses couches applicatives réseau?
@Frederic_Renault tu est encore a coté de la plaque et tu me fait perdre mon temps, je connaît très bien ntp et l’utilise sur mes serveurs dédiés, c’est juste hors-sujet ici…
Si quelqu’un veut bien prendre le relais pour lui expliquer, moi je n’ai pas le temps.
ok, tu as une idée très précise de ce qu’est un protocole je vois… Je ne suis pas à coté de la plaque, je suis ingénieur réseau !!! Et bien soit ne nous expliquons plus rien… mais je ne comprends pas pourquoi on doit gérer La « Blockchain » avec un logiciel qui ne cherche même pas à s’imposer d’être à l’heure…
lol la bonne blague, c’est surtout moi qui t’ai expliqué beaucoup de choses de nombreuses fois, et pas seulement sur ce forum. Le problème, comme je te l’ai déjà dit en privé plusieurs fois, c’est que “tu ne sais pas que tu ne sais pas”.