Yep avec un Duniter plus stable et plus rapide (vive Rust !) je suis confiant en le fait qu’on peut descendre a un bloc par minute sans problème 
Une minute pour vérifier tout un bloc ? Oo Ca me semble encore beaucoup. Je pense qu’on pourrait facilement descendre à 1 bloc/10 sec, ce qui avec 6 confirmations assure qu’une transaction est validée au bout d’une minute.
C’est un peut tôt pour voir, faudra faire des simulations du temps de validation d’un bloc chargé a bloc (c’est le cas de le dire).
EDIT : faudra faire des simulation sur raspberry puisque notre contrainte c’est qu’un noeud de type mini-pc puisse pleinement contribuer au réseau.
Ethereum : 1 bloc toutes les 15 secondes
Peut t’on faire tourner un noeud Ethereum sur raspberry pi ?
Hmmm … non xD Mais … ya quand même une différence de taille entre Ethereum et Duniter 
J’attends tout de même de voir en combien de temps un raspberry arrivera a vérifier intégralement un très gros block avant de m’avancer sur une durée cible entre deux blocs.
D’ailleurs si on vise le plus court possible on sera obligés de définir une taille max de blocs, sinon quoi on arrivera nécessairement un jours a une charge que les raspberry ne pourront pas suivre.
Tout à fait. Je pense qu’il faudrait surtout définir un débit maximum, qui du coup permet de compenser si les blocs sont produits rapidement ou lentement.
Edit : je vise aussi les raspi avec fygg, donc ne t’en fait pas je le prend en compte. La suppression de la preuve de travail va déjà bien les soulager et leur permettre de se concentrer sur le plus important 
Bref, revenons à la preuve de travail D’autres améliorations avant que je code des simulations ?
2 Likes
Hello, pour une validation au comptoir, je subi déjà souvent 1min avec une carte ticket resto et c’est extrêmement long. Le “sans contact” a passé le temps d’attente de 10s à moins de 4s et c’est pour ça qu’il a marché malgré les failles en nombre.
Les virement prennent toujours 24h et c’est chiant mais sans alternatives on s’habitue. Ce sont bien 2 usages différents.
Bien que centralisé, le système de CB ne cherche pas à être fiable à 100%, ils ont des assurances. Un système aussi “fiable” qu’un virement et aussi rapide qu’une CB ? Malgré leurs moyens aucune banque ne l’a tenté.
2 Likes
Du côté utilisateur c’est quelques secondes ou 24h, mais en vrai c’est plusieurs semaines pendant lesquelles ta transaction est réversible (tu peux par exemple faire opposition). Avec une blockchain on parle bien d’une transaction définitive en moins de quelques heures.
C’est bien le but des cryptomonnaies : avoir des paiements irréversibles rapides. Dans notre cas, vu que l’on a pas encore beaucoup d’utilisateurs ça pourrait se faire directement avec le protocole actuel avec des blocs plus proches. Quand on aura plus d’utilisateurs, on pourra utiliser des techniques de scaling on-chain (merkle tree, compression, format binaire) et off-chain (payment channels).
Aussi j’ai donné un exemple avec 6 blocs de confirmation, mais on peut très bien prendre moins de blocs, ou alors afficher la “réussite” de la transaction de manière probabiliste (en prenant en compte la transaction pouvant être incluse dans plusieurs branches concurrentes, augmentant largement la probabilité qu’elle soit confirmée).
1 Like
Je sais bien que tout est réversible (tu noteras que j’ai écrit “fiable” entre “”).
Mais justement, est-ce qu’un paiement instantané a besoin d’être aussi fiable qu’une transaction en Ğ1 aujourd’hui ?
Mieux vaut une bonne pelle et un bon râteau qu’une pelteau (je vous laisse imaginer).
Des paiements irréversibles rapides (aka - de 2h) c’est très différents de “- de 10s”.
Pour ce qui est du calcul probabiliste, le grand public a facilement une aversion à ça. “tu seras payé… mais peut-être pas”. Il suffit d’une fois pour que le boulanger te demande de rester 12 blocs systématiquement, vu que ce sera indéniablement + sûr.
Désolé, on dérive du sujet original.
Avec les blockchains non.
Le paiement instantané EST la transaction Ğ1. La transaction Ğ1 permet l’irréversibilité qui est important pour des paiement instantané sans “assurance” dans la part de banques.
Je parlais dans le cadre général des cryptomonnaies, si on a un bloc toutes les 10s et qu’on prend 6 blocs de confirmation (que l’on considère irréversible) alors on a 1min, ce qui est acceptable. Quand la Ğ1 aura plus d’utilisateurs, on pourra potentiellement utiliser des transactions off-chains, qui elles sont instantanées ET irréversibles tout en profitant de la sécurité de la blockchain.
Le logiciel peux très bien afficher un indicateur “en attente”, “en cours de traitement”, “validé” en fonction de la probabilité trouvé, rien n’oblige d’afficher la valeur brute. Le logiciel du commerçant peut très bien valider une transaction avec une plus faible (mais tout de fois grande) probabilité de confirmation pour des petits montants que pour des plus gros.
1 Like
Excuses-moi, je parlais de tout réversible dans le système bancaire actuel.
La transaction Ğ1 n’est PAS instantanée, et actuellement elle est très loin d’une écriture irréversible en 4s. Je ne sais pas si c’est même utile qu’elle le devienne.
Non, si c’est pour faire du paiement “instantané” chez le commerçant c’est beaucoup trop.
Et quoi qu’on affiche sur le terminal, tant qu’il n’y aura pas “cette transaction est confirmée définitivement” tu attendras avec ta baguette. Actuellement il y a des assurances qui garantissent ce paiement. Aversion au risque, mauvaise appréciation des probabilités, etc… l’utilisateur lambda ne veux pas d’un système “probable”, même à 99%, ce sont des biais connus qui feront passer le système pour une régression de la sécurité.
Je ne comprend pas bien comment fonctionnent les transaction off-chains, mais si elles sont off-chains elles sont moins irréversibles en échange d’être plus rapide ? Parfait, c’est le nouvel outil qu’il faut. Pas besoin donc de diminuer le temps inter-bloc.
Il y a 2 usages, et à cela répondra 2 outils. Mais tirer sur Duniter pour faire + de blocs (et accessoirement + de conso) juste pour ça me semble illusoire.
1 Like
Les transactions off-chains seront des transactions Ğ1.
C’est déjà mieux que d’autres blockchains (Bitcoin : 1h), et après une minute le commerçant est assuré qu’elle ne pourra pas être annulée.
Bizarre vu le nombre de commerces qui acceptent les paiements Bitcoin sans aucune confirmations.
Absolument pas. Je t’invite à faire quelque recherches sur internet, beaucoup de ressources sont disponibles à ce sujet (voir Lightning Network).
Les channels ont besoin d’être ouverts et fermé avec une transaction on-chain. De plus tout le monde n’utilisera pas forcement les transactions off-chain. Le scaling est le problème majeur des blockchains et tous les moyens sont bon pour essayer de le régler : on-chain et off-chain. Sinon, la limite ne se trouvera clairement pas au niveau de la taille maximum de la toile.
La conso viens surtout de la preuve de travail. Effectuer 30 preuves de travail de 10 secondes consommera autant que 5 minutes de travail. En encore on pourra consommer moins, car après avoir calculé un bloc on est exclu (difficulté personnalisé), donc chaque membre va passer moins de temps à manger de l’électricité en continu. Enfin, on ne compte pas de potentielles solutions pour supprimer directement la preuve de travail.
1 Like
Je corrige. “La transaction Ğ1 actuelle n’est pas instantanée”, et dans tous les cas, j’entends “paiement instantané” aujourd’hui = “moins de 5s”. C’est la définition de instantané qui nous sépare. On ne peut pas vraiment espérer faire de l’instantané on-chain.
Quand je dois attendre 1min que ma carte TR passe ça reste beaucoup trop long.
Coinmap <= ça te parait beaucoup ? Et de ce que j’ai vu, je n’ai pas trouvé de commerce “grand public & grand débit” (café, supérette, boulangerie…). Et en ligne c’est facile d’attendre un peu, mais en IRL/AFK…
J’ai lu un peu + en détail, et j’ai fini par comprendre que la transaction d’ouverture est largement antérieure à l’achat. Cela nécessite donc de bloquer quelques unités en permanence pour avoir à la fois vitesse ET sécurité. C’est malin et effectivement une bonne solution. Mais qui fonctionne avec n’importe quel débit de bloc.
Je n’ai pas de problème avec la réduction du temps inter-bloc, tant qu’on ne le fait pas pour “concurrencer la vitesse d’un paiement CB”. C’est juste pour ça que je vous embête.
My bad, j’oublie que le temps, justement, est calé par le fait que le réseau calcule en permanence. Mais il y a quand même le coût de diffusion et le calcul de vérification des blocs, qui lui dépend du nombre de blocs, non ? Et l’exclusion, sur ce point, ne change rien. C’est la taille de la fenêtre d’exclusion qui compte.
C’est l’état des cryptos à l’heure actuelle, et c’est bien pour ça que Lightning Network est interessant.
Je parle de Bitcoin dans le monde entier, notament au Japon où plusieurs milliers de commerces l’acceptent sans attendre de confirmation.
Sauf qu’il faut s’assurer que les blocs ne soient pas plein, sinon il devient difficile de répondre à une tentative de triche (publication d’une ancienne version du channel). Il faut donc un débit capable d’absorber la fermeture d’un grand nombre de channels.
Perso je m’en fiche de la vitesse d’un paiement CB, je veux juste optimiser la blockchain pour que le plus de transactions puissent passer, permettant ainsi à plus d’utilisateurs de l’utiliser (et surtout sans avoir de frais).
.
Les blocs peuvent être plus petits mais plus rapprochés, donnant un travail similaire. De toute façon on ne descendra qu’a des temps qui sont tenable par n’importe quelle machine, notamment les RPI. Ca fait partis des objectifs de Duniter Il suffira alors de définir un débit maximum de transactions par seconde compatible avec des RPI, peut importe le temps interbloc.
1 Like
La confiance envers un concitoyen au Japon (et leur technophilie) n’est pas du tout la même qu’en europe.
On tombe d’accord sur le reste. Et merci des explications ^^