Prototype de GVA

Nodes Duniter
#1

J’ai réalisé un prototype de GVA permettant de faire un paiement !

Prototype réalisé en Rust async avec async-graphql et warp (framework web utilisé également par le projet Deno).

Pour le moment ce prototype permet de :

  • Consulter l’historique des transactions d’un compte
  • Consulter les sources de monnaie d’un compte (UTXOs uniquement)
  • Envoyer une transaction
  • Souscrire à l’événement « réception d’une transaction par le serveur »

Attention peinture fraîche, c’est une version de dev (pre-alpha), accessible ici : https://g1.librelois.fr/gva

J’ai réalisé une petite présentation vidéo dans laquelle je fais un paiement « à la main » :

Réaliser ce prototype m’a permis d’explorer techniquement beaucoup de choses qui vont être un fondement pour la suite. Cela à nécessité notamment la migration de la DB SQLite des transactions (qui contenait à la fois les transactions en mempool et l’historique des transactions).

J’ai dû créer deux nouvelles DB :

  • txs_mp_v2 : Une base de donnée contenant les transactions en mempool
  • gva_v1 : une base de donnée dédiée à GVA contenant pour le moment l’historique des transactions ainsi qu’une indexation des UTXOs optimisée pour les clients (càd par compte plutôt que par identifier).

Le code source est disponible sur la branche gva-proto.

La prochaine étape est bien sûr l’indexation des dividendes universel, c’est plus compliqué car cela demande d’indexer au préalable la liste des comptes membres. J’ai déjà conçu les collections nécessaires dans la DB, reste à les remplir.

Concernant la pagination, je propose d’utiliser les spécifications officielles de graphql, c’est ce que j’ai mis en place pour la consultation des UTXOs.

Le schéma va bien évidemment être modifié selon les retours des dev des clients, c’est juste un 1ᵉʳ jet :slight_smile:

8 J'aimes
#2

Wahou !! Je suis comme un petit enfants depuis le sapins de Noël !
Voila du concret pour me motiver à avancer sur Cesium2 !

Merci pour ce travail :slight_smile:

Yes, je regarde ca aussi vite que je peux.
A ce propos un petit graphiql intégré à ton proto serait utile. Est-ce possible ? :slight_smile:
Ca rend les tests plus accessible, je trouve.

Aucun problème pour moi.

3 J'aimes
#3

Ton nœud donne une erreur 502, du coup j’ai essayé de compiler cette branche chez moi, mais la commande cargo xtask build ne marche pas :

    Finished dev [unoptimized + debuginfo] target(s) in 0.06s
     Running `target/debug/xtask build`
rustc 1.49.0-nightly (e160e5cb8 2020-10-14)
cargo 1.48.0-nightly (9d1a4863a 2020-10-05)
Check node version …
Install node v10.22.1 …
Install nvm v0.35.3 …
bash: #!/usr/bin/env bash
# ... ici il y a un long script bash qui semble devoir installer nvm ...
: Nom de fichier trop long

Je vais essayer d’intégrer GVA dans ĞMixer, les possibilités d’avoir la date d’une source et de souscrire aux transactions m’intéressent. :slight_smile:

2 J'aimes
#4

Bonjour à tous, je vous prie de m’excuser pour ma longue absence, un drame familial m’a demandé toute mon attention pendant plusieurs semaines, ce n’ai d’ailleurs pas fini, mais je commence enfin à pouvoir me poser un peu, pour tout vous dire il s’agit du décès de ma Maman (elle était d’ailleurs membre de la Ğ1 sous le username SylvieAude).

Depuis ce week-end j’ai retravaillé sur GVA et j’ai ajouté les sources de type Dividende Universel :slight_smile:

Je vous laisse découvrir le nouveau schéma toujours à la même adresse : https://g1.librelois.fr/gva

Merci pour ton enthousiasme, ton soutien est important pour moi, c’est ce qui me motive à avancer :slight_smile:

C’est déjà intégré sauf que j’utilise Graphql playground, un fork de graphiql que je trouve mieux fait, c’est accessible par le même endpoint, clique donc sur ce lien : https://g1.librelois.fr/gva

Oui c’est une version de dev donc encore instable, et comme je n’avais plus le temps de le surveiller… c’est rétabli maintenant :slight_smile:

Ok alors tu peux faire à l’ancienne façon, installer node 10 via nvm puis compiler avec la commande npm install. Tu peux aussi m’aider à comprendre pourquoi mon script Rust ne fonctionne pas comme attendu sur ta distrib :slight_smile:

5 J'aimes
#5

J’ai moi aussi été touché cette année par la perte de mon père début mars. Toute mes condoléances…

Merci pour ton travail.

Je vais vérifier que ma branche client graphQL de DuniterPy fonctionne avec ton prototype et si oui on sortira une nouvelle version avec des exemples basés sur ton schema !

Keep up the good job ! :+1:

3 J'aimes
#6

3 messages ont été scindés en un nouveau sujet : Duniter: manual compilation with command xtask

#7

Toutes mes condoléances Éloïs encore une fois. Dur période.

Je confirme que je dialogue bien avec GVA en curl:

curl -s -X POST https://g1.librelois.fr/gva \
    -H "Content-Type: application/json" \
    --data '{ "query": "{currentUd {amount}}" }' \
    | jq .data.currentUd.amount

–> 1023

2 J'aimes
#8

Ben c’est parti !

J’essaie d’envoyer une requête, mais j’ai erreur 400 Bad Request en réponse…
Peux-tu regarder si tu me vois me vautrer à ta porte de serveur et me dire ce qui cloche dans ma requête ? :wink:

#9

A tu testé préalablement ta requête sur le playground puis avec curl ?

Je te vois dans les log de nginx mais pas dans les log de Duniter. Nginx bloque tes requêtes, peut être parce qu’il manque un body ? Essaye une requete (par exemple le montant du DU):

*.*.*.219 - - [10/Nov/2020:16:44:32 +0000] "POST //gva HTTP/1.1" 500 21 "-" "Python/3.6 aiohttp/3.7.2"
*.*.*.219 - - [10/Nov/2020:16:44:59 +0000] "POST /gva HTTP/1.1" 400 54 "-" "Python/3.6 aiohttp/3.7.2"
*.*.*.219 - - [10/Nov/2020:16:48:17 +0000] "POST /gva HTTP/1.1" 200 38 "-" "curl/7.58.0"
*.*.*.219 - - [10/Nov/2020:16:48:24 +0000] "POST /gva HTTP/1.1" 200 38 "-" "curl/7.58.0"
*.*.*.219 - - [10/Nov/2020:16:53:14 +0000] "POST /gva HTTP/1.1" 400 56 "-" "curl/7.58.0"
*.*.*.219 - - [10/Nov/2020:17:00:06 +0000] "POST /gva HTTP/1.1" 400 56 "-" "Python/3.6 aiohttp/3.7.2"
#10

Bon, je réussi maintenant à faire des requêtes graphQL sur swapi (la base de données Star Wars) comme avant.

Je reviens donc sur ton serveur et là j’ai un 500 INTERNAL_SERVER_ERROR !

On progresse… Je pense que j’ai passé ngynx et que je tape Rust maintenant !

#11 
*.*.*.219 - - [10/Nov/2020:19:06:10 +0000] "POST //gva HTTP/1.1" 500 21 "-" "Python/3.6 aiohttp/3.7.2"
*.*.*.219 - - [10/Nov/2020:19:06:36 +0000] "POST //gva HTTP/1.1" 500 21 "-" "Python/3.6 aiohttp/3.7.2"

@vit c’est parce que tu contacte un endpoint invalide, le path doit être /gva et pas //gva, peut-être un problème d’échappement de string

#12

Ah merci ! Oui, un petit bug dans DuniterPy avec le path…

Maintenant ton serveur ne comprend pas mon content-type on dirait :

Unknown content-type « application/json; charset=utf-8 »

#13

Utilise «application/json» uniquement :slight_smile:

1 J'aime
#14

Aujourd’hui j’ai travaillé sur :

  • La configurabilité de GVA (uniquement via le fichier conf.json pour le moment)
  • La création de la doc de configuration de gva
  • La génération des endpoint GVA et leur ajout dans la fiche de peer
  • La récupération de la fiche de peer du nœud via GVA:

image
image1435×204 18.1 KB

J’ai gardé les mêmes conventions que pour les autres types d’endpoint à une différence près : la couche TLS est explicitée par un S. Cela permettra à ceux qui le souhaitent de pouvoir fournir un endpoint sécurisé sur un autre port que 443 (via l’option remoteTls, voir doc).

Maintenant j’aurais besoin qu’un ou deux d’entre vous essayent de mettre en place un serveur GVA, voici comment faire :

  1. Compilez manuellement Duniter sur la branche gva-proto-2
  2. Indexez la db de GVA, 2 méthodes possibles :
    A. Avec la commande dex migrate (nécessite de compiler le binaire dex au préalable). L’indexation prend environ 2 minutes ce qui est bien plus rapide que de resynchroniser Duniter, donc même en comptant le temps de compilation de dex cette méthode devrait rester plus rapide.
    B. Vous pouvez aussi resynchroniser Duniter avec l’option --gva (duniter sync --gva g1.duniter.org) mais cette méthode est plus longue forcément
  3. Configurez GVA en modifiant directement le fichier conf.json, voici ma conf par exemple :
{
  ...,
  "gva": {
    "host": "localhost",
    "port": 30901,
    "path": "gva",
    "subscriptionsPath": "gva-sub",
    "remoteHost": "g1.librelois.fr",
    "remotePort": 443
  }
}
  1. Lancez votre nœud duniter avec l’option --gva (nécessaire car gva est encore désactivée par défaut) : duniter start --gva
  2. Ouvrez l’url http://localhost:30901/gva dans votre navigateur (ou l’url adaptée a votre configuration le cas échéant).
  3. Faite moi un retour

Merci :slight_smile:

5 J'aimes
#15

De mon côté je suis charette sur des fins de projet pour mon boulot. Donc pas eu le temps d’avancer sur Cesium2…
Ne t’excuses pas @elois :-).
Concernant la mauvaise nouvelle que tu annonce, je ne sais pas trop quoi te dire…
Saches en tous cas que cela me touche pour toi. La vie est vraiment quelque chose de fragile… et reste pour moi un mystère.

3 J'aimes
#16

Du coup j’ai pu le compiler, j’ai bien accès à l’interface web GVA, mais :

  • dex migrate a pris environ 10 minutes après avoir affiché le dernier message « Apply chunk » sans rien dire, à écrire à 16 Mo/s dans le disque. Ça serait bien d’ajouter un message pour qu’on ne se dise pas que ça a planté. (oui j’avais oublié de le copier dans la RAM)
  • L’option --home PATH place le dossier de duniter à ~/.config/duniter/PATH apparemment, donc j’ai mis longtemps à comprendre pourquoi avec --home /dev/shm/duniter rien ne marchait (sauf l’interface web GVA, mais les requêtes renvoyaient des résultats vides), jusqu’à voir que tout était dans ~/.config/duniter/dev/shm/duniter…
2 J'aimes
#17

Chez moi ça prend 1m39s en tout, et que quelques secondes après le log du dernier chunk.
Tu es le premier à tester sled sur HDD (je n’ai que des SSD depuis des années, donc je ne pouvais pas tester).
sled est optimisé pour les SSD, mais je ne pensais pas que les perfs seraient si mauvaises sur HDD, je suis en train de regarder du côté de RocksDb mais c’est aussi optimisé pour SSD donc ce sera peut-être pareil, on verra à l’expérience. En vrai je pense que quel que soit le sgdb choisi les HDD sont de toute façon beaucoup trop lent pour le type de traitement que Duniter doit faire (indexation en particulier).

Il y a déjà un message de succès à la fin. Je viens d’ajouter un message intermédiaire pour le flush.

Ça ce n’est pas normal, je viens de vérifier dans le code et l’option --home est codée pour se comporter comme un home absolu, c’est avec le binaire dex ou duniter que tu as eu ce souci ? Que j’essaye de reproduire ! EDIT: bug trouvé et corrigé :slight_smile:

Et du coup ça y ai ton playground GVA fonctionne ? Une screen ?

2 J'aimes
#18

Yes ça marche maintenant !

Par contre la commande logs ne sort rien, mais le fichier duniter.log est bien alimenté.

image
image1525×480 54.5 KB

3 J'aimes
#19

Penses-tu que je puisse implémenter le endpoint GVA au format définit dans WS2P v2 ou bien tu vas faire un ajout à WS2P V1 ?

Bref j’ai besoin du format du endpoint GVA genre « GVA hostname ipv4 ipv6 path » pour DuniterPy… si tu l’as…

WS2P V2 correctifs cosmétiques sur le document RFC
#20

Le endpoint GVA est normalement déjà ajouté à la fiche de peer relayée par WS2Pv1, d’ailleurs si tu regardes les fiches de peer sur le réseau tu vois les 3 nœuds GVA : https://g1.elo.tf/network/peers

Je l’ai déjà indiqué dans le message #14 que tu à lu puisse que tu l’a liké :wink:

2 J'aimes