IMPORTANT : Proposition de migrer la Ğ1 sur une blockchain substrate

2 « J'aime »

Très bon ! C’est une excellente proposition qui va dans le sens de l’histoire.

Tous les bons projets durables passent forcément par des étapes de refonte, pour adapter la solution aux innovations. C’est ainsi que Mozilla a carrément créé le RUST pour ensuite recoder Firefox, il est donc tout à fait cohérent d’envisager de recoder le logiciel Ğ1 en Rust, et de bénéficier de l’apport considérable des développements Rust déjà réalisés par la communauté du Libre.

Substrate est un framework écrit en RUST, ce qui démontre la robustesse et l’engouement autour de RUST, qui est 1°) Rassurant en terme de pérennité et 2°) Peut générer l’intérêt et l’engagement des développeurs anciens et nouveaux pour le projet qui leur permettra aussi de développer leurs compétences sur un outil potentiellement très porteur.

Une preuve en est que Jbar est intéressé, ce qui est déjà en soi la démonstration que la piste est très prometteuse !

C’est aussi l’occasion de regrouper autour de cette nouvelle étape de nouveaux développeurs enthousiastes à l’idée de développer la monnaie libre, et l’occasion pour les anciens de regrouper les compétences autour d’un langage de programmation commun.

Cela pourrait ainsi être aussi l’occasion de mettre en place une plus grande cohérence globale en terme de langage fondamental, sur un plus grand ensemble des outils dédiés à la Ğ1.

C’est enthousiasmant !

14 « J'aime »

@elois Est-ce que tu as étudié d’autres frameworks pour blockchain ? Je pense notamment à Exonum en Rust, mais il y en a d’autres en open source : Hyperledger, Openchain, Graphene, Corda, MultiChain…
C’est juste pour savoir. Une réponse oui/non me conviendra très bien :slight_smile:
De plus, le fait que tu travailles pour Parity est évidemment un gros point positif à prendre en compte dans la balance.

Aussi, j’avais une question qui s’est noyé dans une autre discussion :
Est-ce que polkadot-js sera utilisable en l’état ou est-ce qu’il faudra réimplémenter une api client spécifique à nos besoins (certifs,…) ?

@kimamila Pour du graphql, il y ce dépôt qui utilise Hasura. J’utilise Hasura depuis plus de 2 ans et c’est vraiment un outil génial. Je ne sais pas du tout ce que vaut l’intégration avec substrate. A tester…
Par contre, Hasura permet de merger plusieurs api graphQL, donc on pourrait implémenter notre propre api spécifique (gestion des certifs par ex) et l’intégrer à Hasura pour ne plus avoir qu’un seul endpoint graphql. C’est ce que je fais généralement en utilisant fastify/mercurius pour créer mon api spécifique…

2 « J'aime »

De ce que j’ai lu, les « palettes » spécifiques sont accessibles directement dans l’API client RPC.
En fait c’est configurable avec le fichier JSON dont elois parle dans sa vidéo. Ce sont les déclaration des fonctions et types et méthodes exposées.

A priori c’est du PostgreSQL derrière, qui indexe les données à partir d’un noeud.
Je risque de regretter un peu ElastiSearch, en terme de perf :frowning:

Autre point à voir : la question de la compatibilité P2P des libs cliente Substrate. De ce que j’ai vu ici, l’API JS communique avec un seul noeud.
Pour ne pas retomber sur les travers actuels, comment faire pour :

  • répartir la charge sur le réseau ?
  • garantir que le noed requetés est à jour.

Je continue à creuser…

5 « J'aime »

Je pense aussi, d’autant que des développeurs expérimentés sur substrate il y en a, j’en connais quelques uns :smiley:

Oui ça fait des années que je regarde plein de framework blockchain, j’avais nottament regardé Exonum, Hyperledger et Openchain, il n’y en à aucun qui arrive ne serait-ce qu’a la cheville de substrate par rapport à mes critères, qui sont:

  1. Doit être suffisamment customisable pour qu’on puisse l’utiliser sans le forker (rien que ce critère exclu déjà 80% des framework blockchain)
  2. Doit être ready to production (mature)
  3. Doit être maintenu par une entité ayant suffisamment de visibilité pour le maintenir sur le long terme, et donc doit être déjà massivement utilisé, notamment par des gros projets, pour garantir que ça va pas mourir dans 3 ans.
  4. Doit apporter suffisamment d’avantages pour que le « coût » d’une migration en vaille la chandelle.
  5. Dois fournir le plus possible de briques que l’on peut reprendre tel quel
  6. Dois être écris dans un langage performant et fiable

Outre ces critères, substrate apporte de nombreux concepts très puissant que je n’ai vu nulle part ailleurs, comme la notion de runtime wasm qui peut être mis à jours de manière forkless, y a plein de notions puissantes dont je vous ai pas encore parlé, car je suis lent pour structurer ma pensée à l’écrit, ça viendra au fils du temps, mais le format vidéo est plus rapide pour moi, je pense donc faire d’autres vidéos ainsi que des visios :slight_smile:

Alors je bosse pas pour Parity, mais pour une boite qui développe un gros projet sur substrate oui (bien plus gros et plus complexe que Duniter). Donc je dois de toute manière monter en compétences sur substrate dans le cadre du boulot UNL, ça me permet de faire d’une pierre deux coups.

Rien n’empêche de développer un serveur proxy ElastiSearch qui lui même tape l’api RPC de substrate pour indexer les données. Comme le font les pod Cs+ avec Duniter.

Tout comme on pouvais faire un client multi-nœud basé sur l’API BMA ou GVA, ou peut tout à fait faire un client multi-noeud basé sur l’API RPC de substrate, et c’est ce qu’on va essayer de faire dans ğecko.

On peut facilement customiser l’API RPC: Custom RPCs - Substrate Recipes
Donc on peut très bien y ajouter ce qu’il faut pour récupérer une liste de nœuds connus, etc :slight_smile:

Bref on peut faire ce qu’on veut, on est pas limité (sauf par le temps de vie dont on dispose) ^^

1 « J'aime »

J’ai gratté vite-fait un conteneur qui a l’air de se lancer :

$ docker run --rm -it --entrypoint lc-core lc-core-substrate
2021-07-15 21:32:25 Substrate Node    
2021-07-15 21:32:25 ✌️  version 3.0.0-unknown-x86_64-linux-musl    
2021-07-15 21:32:25 ❤️  by Substrate DevHub <https://github.com/substrate-developer-hub>, 2017-2021    
2021-07-15 21:32:25 📋 Chain specification: Local Testnet    
2021-07-15 21:32:25 🏷 Node name: uncovered-shop-7452    
2021-07-15 21:32:25 👤 Role: FULL    
2021-07-15 21:32:25 💾 Database: RocksDb at /root/.local/share/lc-core/chains/local_testnet/db    
2021-07-15 21:32:25 ⛓  Native runtime: lc-core-100 (lc-core-1.tx1.au1)    
2021-07-15 21:32:25 🔨 Initializing Genesis block/state (state: 0x1977…6482, header-hash: 0xead5…6f97)    
2021-07-15 21:32:25 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
2021-07-15 21:32:25 ⏱  Loaded block-time = 6s from block 0xead586daa5151fc8b7ef3e8cca37bd2dafe27e7eb477438d526b77a8a70b6f97    
2021-07-15 21:32:25 Using default protocol ID "sup" because none is configured in the chain specs    
2021-07-15 21:32:25 🏷 Local node identity is: 12D3KooWLGWZXa8GGrqUQwLbGFsDmSZyhfMZAGtFzQefHpjuFRv3    
2021-07-15 21:32:25 📦 Highest known block at #0    
2021-07-15 21:32:25 〽️ Prometheus server started at 127.0.0.1:9615    
2021-07-15 21:32:25 Listening for new connections on 127.0.0.1:9944.    
2021-07-15 21:32:30 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0    
2021-07-15 21:32:35 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0    
2021-07-15 21:32:40 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0    
2021-07-15 21:32:45 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0  

Mais je ne sais pas trop quoi faire avec ensuite :slight_smile:

1 « J'aime »

Woah, merci @elois pour ta réponse !
On devrait éditer le 1er post pour lister les questions/réponses comme ça…

3, 4, 10 coups même ! En tant que dev qui a envie de bien faire, ce n’est pas super motivant d’avoir à bricoler de l’existant pour arriver à ses fins alors que l’on sait que l’on pourrait faire mieux et plus simple en repartant d’une bonne base. Et en plus ça va profiter à toute la communauté, c’est enthousiasment !

Oui, Hasura construit une api graphql sur une ou plusieurs bases de données postgresql mais aussi des bdd sql. Moi je ne vais pas regretter du tout ElasticSearch. C’est un moteur de recherche est je n’ai jamais compris l’intérêt de l’utiliser comme base de données. En termes de perf, Hasura peut tenir un million de connexions websocket. On a de quoi voir venir. J’ai des fonctions postgresql pour faire de la recherche en langage naturel, et de la recherche par géolocalisation. Hasura transforme n’importe quelle vue et fonction postgresql en api graphql… Avec les remote schemas, c’est un outil vraiment génial pour construire une architecture en microservices. Si vous voulez tester en 2 min, il y a https://cloud.hasura.io/ ou sur heroku.

2 « J'aime »

Ce n’est pas qu’un moteur de recherche. Il permet de faire du schemaless : stocker du JSON directement, en indexant chaque attribut et donc de permettre de faire des recherches ET des calculs (AVG, SUM, COUNT, etc).
Le gain de temps est énorme, surtout quand le format des documents changent beaucoup (ex: les blocs, les profiles, etc.). Mais tout cela est sans doute moins utile, maintenant qu’on a un framework bien cadré comme Substrate. Je vais regarder du côté de Hasura. J’avoue que ca m’arrange de ne pas à avoir à migrer les pod Cesium+ :slight_smile:

2 « J'aime »

Super sympa, j’ai réussi à compiler ton PoC sans problèmes, c’est très bien documenté !

Tu veux que je te fasse une petite CI qui compile le programme automatiquement à chaque commit (ou tag) ?

3 « J'aime »

Très bonne initiative @llaq . Cependant je pense que @elois gère sa CI lui même au mieux, car il est expert git ^^
Mais il te dira si il a besoin d’aide je pense :slight_smile:

2 « J'aime »

J’annonce :

Tikka va être publié rapidement sur notre gitlab.
C’est un client de bureau qui se veut le plus complet possible.

La partie api n’a pas été encore faite. C’est le moment idéal pour coder en python ce qui est nécessaire pour piloter substrate.

Ya plus ka. :wink:

S’il existe des bibliothèques python pour substrate, je ne sais pas si une bibliothèque commune est encore utile . sûrement, à réfléchir car ça ralentit les développements (pour ne pas impacter tous les clients encas d’erreur ).

6 « J'aime »

Oui si tu veut, je n’ai pas le temps je pensais mettre en place ça plus tard, mais ça peut être l’occasion pour toi de monter en compétence la dessus :slight_smile:

2 « J'aime »

Pas de problèmes, je fais ça vite :slightly_smiling_face:.
Tu veux que ça compile à chaque tag ou commit ?

1 « J'aime »

En fait je vais pas faire de tag pour l’instant c’est trop tôt, mon besoin le plus urgent c’est d’avoir une CI qui controle les MR, vérifier que fa compile bien, que les tests passent, et vérifier fmt et clippy aussi :slight_smile:

Nouvelle version de la POC, avec gestion des certifications et du renouvellement des identités, présentation en vidéo :

https://drive.infomaniak.com/app/share/144117/73a15508-28d7-4f3a-81d9-0a011a62de84

En lien avec : Ğ1v2: Changement de la gestion des identités

6 « J'aime »

Bonjour à tou.te.s

Tout d’abord, ravi de voir qu’une nouvelle dynamique d’évolution règne autour du projet G1. Je suis un adepte depuis plusieurs années, j’ai beaucoup œuvré pour faire connaitre la G1 notamment au sein du groupe monnaie libre touraine depuis au moins 3 ans.
Je constate aujourd’hui une sorte de plafond de verre (ou résistance) autour des 3000 utilisateurs. A vous lire, on peut imaginer que cela est dû à des problèmes techniques, je pense que c’est bien le cas mais je crains que ce ne soit que secondaire.
Face à cette stagnation d’intérêt de la G1, j’ai fini par m’intéresser plus largement à la technologie blockchain et donc tout l’écosystème des cryptomonnaies. Aujourd’hui j’ai fortement l’impression que la résistance des 3000 utilisateurs soit aussi du au fait que la G1 ne puisse avoir une perspective de listing sur des exchanges, ni de conversion vers d’autre monnaies.
Je m’intéresse trouver des crypto-éthique tel que la G1 mais que l’on peut convertir.
Avec ce nouveau projet y aurait-il des perspectives de conversion ?
Belle journée

2 « J'aime »

Je pense aussi que la technique n’est qu’une cause secondaire de la lente croissance de la G1, mais la technique actuelle ne permettrait pas de croître beaucoup plus, de toute façon. La changer ne résoudra pas tout, mais c’est nécessaire.

Le problème de la conversion est un problème de manque d’utilisation réelle : techniquement les échanges sont possibles. C’est l’offre qui manque. Et si le manque d’offre de conversion vers d’autres monnaies est perçu comme un frein, ça peut juste signifier que l’offre dans la monnaie est trop faible.

Cependant l’utilisation d’un framework assez répandu permettra plus d’interopérabilité avec d’autres outils, donc peut-être une mise en place plus facile d’outils de conversion. (mais il faudra toujours trouver des gens prêts à faire les conversions)

5 « J'aime »

Oui clairement, plusieurs blockchains substrate sont déjà listés sur des exchanges, donc techniquement ont pourrait lister la Ğ1 infiniment plus facilement.
Je suis d’avis également que c’est indispensable pour que la Ğ1 se développe, mais pas suffisant bien sur :wink:

4 « J'aime »

Génial, si tu peux t’occuper de la dockerisation à ma place ce serait top, je sais très bien le faire, mais je gère trop de truc faut que le délègue, tu veux les droits sur le dépôt pour pouvoir pousser une branche ?

Utiliser PolkadotJs apps pour interagir avec ta blockchain locale comme je le montre dans mes vidéos :slight_smile:

1 « J'aime »

Juste pour info, pontem est basé sur substrate et polkadot.
Pontem est une blockchain de test pour diem (anciennement libra), la future crypto-monnaie de Facebook !

2 « J'aime »