Ben c’est une simple distorsion linéaire en fonction du nombre moyen de transactions sur les derniers blocs. Je ne vois pas ce qui vous… bloque. 
Du coup quelqu’un pourrait remplir un bloc de transactions bidons mais valides pour avoir un bonus “bloc rempli donc plus vite” ?
Ben non:
ce qui voulait dire « sur les blocs précédents ».
Ca me semble quand même bien plus compliqué que de faire des blocs de taille dynamique à intervalle fixe.
1 Like
Cela n’empêche pas d’avoir des blocs de taille variable aussi.
Pourquoi faire varier l’intervalle si une variation de la taille peut absorber le surplus ?
2 Likes
Because we can?
Plus sérieusement, c’était pour avoir des transactions un peu plus rapides et aussi avoir une capacité d’absorber plus de transactions en heures de pointe, mais pour ça il faudra plutôt se tourner vers les lightning networks de toute façon. Donc bon, oubliez mon idée, elle n’apporte visiblement pas grand-chose à part de la complexité dont on n’a pas vraiment besoin.
C’est prévu d’utiliser du Lightning plus tard 
Par contre, je me demande si on reste sur du 5min/bloc ou si on dessends ?
Il faut trouver un équilibre entre temps de confirmation et leur taille sachant, sachant que mon protocole augmente en efficacité quand la taille des données par bloc augmente. Je pense qu 1 bloc par minute sera un bon compromis, et que des systèmes off-chains comme LN pourront assurer des temps plus court si nécéssaires.
C’est trop court, 5 min c’est un moyenne mais la véritable fréquence est aléatoire a cause de la PoW, ce qu’on peut éventuellement faire et qui reste beaucoup plus simple que al proposition de @jytou c’est de pdémarrer a 5 min par bloc puis de réévaluer cette fréquence tout les 3 mois en fonction de la charge moyenne des blocs sur les 3 derniers mois, ce qui permettra déjà de nous ajuster a la charge tout évitant de calculer des distorsions linéaires trop complexes 
Si on défini un débit minimal nécéssaire pour faire tourner un noeud, augmenter la fréquence des blocs ne pemet pas de s’ajuster à la charge. Pour gérer une charge plus importante, un protocole optimisé pour ça et des solutions off-chains semblent plus adaptés et surtout n’excluent pas d’utilisateurs ayant un débit faible.
Par contre trouver l’équilibre entre des petits blocs très reguliers ou des gros blocs plus espacés permettrait d’avoir une blockchain dynamique et scalable.
3 Likes