Ce que je constate autour de moi, c’est que aujourd’hui les smartphones sont connectés en permanence.
Je pense que l’idéal, se serait que chaque smartphone est un light client qui tourne en fond en permanence, ça consomme beaucoup moins que de nombreuses autres app qui tournent déjà en permanence en fond sans que l’utilisateur s’en rende compte.
Smoldot fourni des metrics, lors de mes tests le constate un usage ram de seulement 36 Mo, et un usage réseau moyen de l’ordre de 150Ko/s , c’est dérisoire.
Et je n’ai jamais dit que les light node devait être obligatoire, mais privilégiées lorsque c’est possible. l’API RPC exposée étant la même que celle d’un full node, les développeurs des wallet peuvent facilement de fall back en mode full node distant si besoin.
Pour ton cas de paiement rapide par exemple, lorsque utilisateur ouvre l’app, tu peux choisir selon le cas:
- l’app tournait déjà en fond avec son light node: tu utilises le light node
- l’app ne tournait pas en fond: tu te connectes à un full node au hasard parmi les endpoint connus
Je pense que tu es inquiet, car tu ne connais pas le fonctionnement des light node, ils ne font pas un scan complet du réseau, ils n’en ont pas besoin, ce n’est pas ud multi-noeud, c’est beaucoup plus robuste que ça:
Le light node par d’un checkpoint (hash d’un block et set des autorités), qui peut être le block genesis, où un block plus récent inscrit en dur dans le code par les développeurs, ça peut être fait par exemple tout les 6 mois.
Le light node va alors récupérer tout les headers depuis ce checkpoint et recalculer les hash pour s’assurer que toutes les preuves de changement d’état sons valides.
cette tache peut (et doit de préférence), être exécuté en tache de fond sur la machine de l’utilisateur final, ça ne demande que de récupérer quelques centaines d’octets toutes les 6 secondes.
Lorsque le light node a besoin d’une donnée dans le storage, il lui suffit de requeter un seul full node, vu qu’il a les merkel root de chaque bloc, il est impossible de uli mentir.
Avec un light node, il est donc possible d’avoir la rapidité ET la décentralisation réelle, le seul compromis n’est pas la lenteur, mais le fait de laisser de light node tourner en tache de fond.
tu penses bien que les développeurs de blockchain ont déja réfléchi y ce problème depuis des années, c’est pour cela que les light node ont été inventés, ils n’ont pas besoin de truster les bootnodes.
La différence c’est que les données d’un indexeur sont beaucoup moins critiques, c’est pratique pour afficher des stat où afficher l’historique d’un compte, mais il faut garder en tête qu’un indexeur c’est centralisé, et qu’il ne faut donc pas se baser sur les informations qu’il donne pour prendre des décisions importantes, il faut vérifier sur un full node archive la donnée au numéro de bloc concerné.
Je n’ai jamais dit qu’il fallait s’en empêcher, reste à définir ce qu’est un nœud de confiance, ce n’est pas parce qu’un full node distant a été utilisé récemment qu’il est de confiance.
- l’utilisateur ni gagnera pas forcément en rapidité, car le full node contacté peut être débordé. S’il a déjà un light node en tache de fond, il sera plus rapide d’utiliser le light node.
- Comment détermine tu que le risque de centralisation est quasi nul ? Et qu’entend tu par “nœuds connus” ?
Ce que je n’ai pas précisé, c’est qu’un light node local permet également plus de fonctionnalités, qu’un full node ne peut pas exposer publiquement pour des raisons de sécurité.
Comme le light node récupère le runtime onchain localement, il peut exécuter n’importe-quelle runtime API, ce qui inclus le dry run d’un extrinsic.
Ça permet à l’application de tester l’exécution de l’extrinsic avant de le soumettre, ce qui permet d’éviter d’inscrire en blockchain un extrinsic qui échoue et qui fait consommer des frais ou quota pour rien.
Et plus généralement, c’est préférable de déplacer les traitements cotés utilisateur, plutôt que coté serveur, ça permet une meilleure montée en charge, et une meilleure décentralisation.
Je pense que vous ne vous rendez pas compte car dans la Ğ1 on a pas de charge, 5000 utilisateurs dont beaucoup sont tors peu actif, peut être l’équivalent de 500 utilisateurs quotidiens en termes de charge.
On a dimensionné les paramètre de la toile de confiance Ğ1 pour 1 million d’utilisateurs, ce qui signifie une charge de l’ordre de 10.000 fois supérieure à aujourd’hui.
Moi je vois ce que c’est tous les jours au boulot que de gérer une crypto avec forte charge, et c’est l’enfer pour les fulls node qui exposent une API RPC publique.
Ça induit de fortes contraintes techniques sur la capacité à proposer des fulls node RPC publics, peu d’acteurs peuvent gérer la charge, ce qui induit plus de centralisation mais également plus de fragilité et cas de panne chez l’un des acteurs.
Si une grande partie des utilisateurs avait un light node local, les fulls node RPC publics seraient beaucoup moins surchargés, et il en faudrait peu, ce qui réduit le besoin en datacenter.
On parle souvent de lowtech et de soutenabilité, c’est facile sous faible charge, mais sous forte charge c’est impossible sans light nodes.
Les contraintes que pose la compatibilité avec smoldot sons infiniment plus simple à satisfaire que les contraintes que pose le support des rpi.
Duniter-v2s ne restera livré que pour du linux x86_64.
Seul smoldot à besoin d’être compatible sur toutes les plateformes des utilisateurs, et les développeurs de smoldot ont déjà fait en sorte que ce soit le cas. Ça ne nous donne donc pas plus de travail de notre côté.
Hum je pense que tu n’as pas compris, duniter-v2s ne va pas tourner partout, ça reste un logiciel différent qui ne tourne que sous linux x86_64.
Un full node doit faire beaucoup de choses qu’un light node n’a pas besoin de faire, c’est donc 2 logiciels différents, on doit juste s’assurer de leur compatibilité.
Et grâce au système ultra générique de runtime spécifique à substrate, on a pas besoin de faire des développements spécifiques coté light node, le light node smoldot de base fonctionne déjà avec notre blockchain.
Si on adopte le système de stockage libre que je propose, alors on peut vérifier toutes les données fournies par l’indexeur, donc pas besoin de lui faire confiance, et si on a un light node pour vérifier la présence des hash en blockchain, on n’a pas besoin de faire confiance non-plus au full nodes.