G1-stats.axiom-team.fr

Les sources de https://g1-stats.axiom-team.fr/ sont-elles publiées ?
Comment fait-il pour connaître les clés des comptes non membres ?
Je suis pas sûr que cette information soit disponible depuis BMA.
Est-elle récupérée depuis la BDD ?

C’est @poka qui a dev ça a l’arrache, il se base entre autre sur l’api ES des nœuds Cesium+
Je sais pas s’il a publié le code quelque part

1 J'aime

Oui, je me disais aussi que l’API ES pouvait être utilisée.
Elle offre plus de données ainsi des données plus travaillées que des donnés bruts que BMA.

Oui c’est moi qui est fait ça @Moul

Pour le calcul du nombre de wallets membres / simple portefeuille j’utilise BMA. Sont considérés comme simple portefeuille chaque adresse ayant reçus au moins une transaction.
Pour la récupération des soldes j’utilise l’API ES c’est beaucoup plus rapide.

L’un est un standard du protocole obsolète et l’autre ne l’est pas, donc je suis un peu le cul entre 2 chaises ^^

J’ai publié le code par soucis de transparence et d’audit, si ça peut servir, mais je préviens c’est du full bash pas forcément très digeste pour le peut que ça fait…

Il faudrait qu’on mette en commun les travaux de @yyy et quand on aura une vrai API on refera un truc propre en nodejs par exemple.

2 J'aimes

Tu récupères ça sur quel(s) path(s) ? Je pourrais lire le code aussi :wink:
Ok, tu fais ça en mode bourrins sur touts les blocs contenants des transactions. J’aurais pas le courage de faire ça. J’attendrais qu’une API implémente ça, ça fait beaucoup trop de calculs côté client. Mais pourquoi pas :wink:

J’ai pas compris. Tu parles de BMA et ES/Cesium+ ?


Merci de publier le code. N’oublie pas la licence :wink:

1 J'aime

Je récupère la liste des blocs contenant au moins une trasaction: ${DUNITER}/blockchain/with/tx

Et je boucle dessus pour récupérer les clé publique de destination:
curl -s ${DUNITER}/blockchain/block/${TXBLOCKS[$i]} | jq '.transactions[].outputs[]'

Simplement que BMA est obsolète et attente de remplaçant et que Cesium+ n’est pas proprement un standard du protocole mais plus pratique à manier, donc mon code est doublement pas pérenne dans le temps, c’est pour ça que je ne le diffuse pas trop et que je vais pas plus loin.

Si je devais aller plus loins je ferais au moins une db sqlite ou mysql indexé et pas jsute une génération de fichiers statiques archivés comme je fais là ^^

L’utilité de base était d’avoir la liste des simples portefeuilles actifs et connaitre approximativement leur nombre.

2 J'aimes

Merci d’avoir cherché à obtenir cette information. Le constat est que la majorité des clés publiques contenant des sources ont le statut de membre avec un taux d’environ 85 %.

Et il faut prendre en compte les porte-feuilles qui ne sont plus membres ainsi que les personnes qui ont un compte membre et plusieurs porte-feuilles.

Le pourcentage de personnes ayant uniquement un porte-feuille et pas de compte membre doit être inférieur à 10 % et proche de 5 %. La majorité arrive à avoir un compte membre.

1 J'aime

Oui j’ai été très étonné je m’attendais à beaucoup plus de simple portefeuille.

Est-ce volontaire d’afficher le solde des membres en négatif ? J’imagine que c’est parce que le DU n’est pas compté.

Oui je n’ai pas trouvé de moyen simple d’ajouter les DU.

Scanner tous les DU non consommés de chaque wallet membre rallonge la durée d’exécution de 10 minutes à 1h30 …

Du coup, si un compte est vide et n’est plus utilisé (on peut pas le savoir), alors il est quand même compté. C’est de l’à-peu-près. Mais ça donne un ordre de grandeur. L’idéal serait que GVA fournisse un max de données.

C’est le cas de tous les développeurs de clients :wink: Plus j’écris de code basé sur BMA, je me dis qu’il faudra que j’adapte le code à GVA. Mais, ça devrait être un plaisir étant donné que ça devrait être mieux pensé.

2 J'aimes

Si il a déjà reçus au moins une transaction il est considéré actif, même si il n’a jamais rien fait d’autre.

Si on peut tout faire, je peux filtrer si aucune activité depuis plus de x mois, alors considéré comme inactif, ou si jamais envoyé aucune transaction …
Mais je trouve que c’est une bonne idée à terme d’intégrer ce genre de filtrage dans les statistiques d’utilisation, en affichant plusieurs conditions comme ça.
Comme je parse déjà toutes les transactions ça ne demanderai quasiment pas plus de ressources que d’inclure les date de réception et filtre d’émission.