Transaction per second / temps blockchain

c’est la solution que je compte utiliser… cette fonction sera gérée par le cron_MINUTE.sh des Stations « June / Zen Fontaine » …

Je compte passer ce confinement à la réécriture de G1sms+ vers Astroport.com = G1Bot multicanal + SSB et IPFS :wink:

On active le Web4D.
« Anoptical P2P System », où tous les pouvoirs sont délégués aux individus.

Voila le plan de transformation…
P2Pmesh

Ce sera https://p2p.legal en Monnaie Libre

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 :heart: " 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.

Ce qui est faux, il existe des crypto dont le TPS (Transactions per Second) est bien supérieur à 1000.

txWindow vaut 1 semaine mais ce paramètre va être supprimé en v13 (je vais bientôt soumettre les spec justement).

Chaque nœud sera alors libre de décider combien de temps il gardera une tx dans sa mempool (ce sera probablement fixé a une semaine par défaut).

OK lesquelles?

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…

L’une d‘elle est elle vraiment totalement décentralisé à consensus public ?
Il y a le Zen dans ipf aussi :wink:

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 :slight_smile:

Le median time blockchain ressemble beaucoup à la synchro des GPS :wink:

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 :wink:

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?

Quel problème ?

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.

C’est ce qu’il me semblait…

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…

1 J'aime

Je trouve les réflexions de Fred pertinentes.

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

ok, je vais voir…

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?

Y’a même des implémentations en rust

Alors je vois pas pourquoi s’en priver?

@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 ».

1 J'aime