# Prototype de GVA **URL:** https://forum.duniter.org/t/prototype-de-gva/7688 **Category:** Duniter-v1 **Tags:** gva **Created:** [18 October 2020 14:40 UTC](https://forum.duniter.org/t/prototype-de-gva/7688 "2020-10-18T14:40:53Z") **Posts on this page:** 20 **Page:** 5
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [31 December 2020 15:07 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/82 "2020-12-31T15:07:54Z")
> [@kimamila](#): > > Le champ `amount` est un simple différentiel, entre ce qui ce qui sort et ce qui entre. Ok en fait on ne se comprend pas car nous ne donnons pas le même sens aux mots. En fais ce que tu veux c’est la variation du solde du compte dont on regarde l’historique. Un tel champ pourrait se nommer `accountBalanceVar` et est bien définissable pour tout doc tx donc il ne vaudra jamais null 🙂 Parler de `amount` me semble incorrect, car ce terme sous-entend que l’on désigne une propriété intrinsèque de la transaction, alors que l’on désigne en réalité le bilan d’un compte impliqué dans cette transaction. Ce champ `accountBalanceVar` serait positif pour les transactions reçus et négatif pour les transactions émises. On pourrait d’ailleurs se baser sur ce champ pour définir la direction. > [@kimamila](#): > > Les seuls cas où il peut valoir null, c’est dans le cas de condition avec des « OR » (ex: SIG(0) || SIG(1) ) Non, car l’historique fourni par GVA est indexé par compte, pas par clé publique. Si tu requête l’historique de compte `SIG(A) || SIG(B)` tu auras bien une valeur pour `accountBalanceVar` pour chaque tx dans l’historique. Tu pourras connaître tous les comptes liés à une clé publique P via une query `accountsWithPubkey` qui te retournera un tableau des scripts des comptes ayant un solde strictement positif et ayant la clé publique P dans leur script. ---
### Author: ![kimamila](https://forum.duniter.org/user_avatar/forum.duniter.org/kimamila/32/185_2.png) [@kimamila](https://forum.duniter.org/u/kimamila) #### Post date: [31 December 2020 16:23 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/83 "2020-12-31T16:23:28Z")
> [@elois](#): > > En fais ce que tu veux c’est la variation du solde du compte dont on regarde l’historique. Un tel champ pourrait se nommer `accountBalanceVar` et est bien définissable pour tout doc tx donc il ne vaudra jamais null Ca pourrait être aussi `accountDelta`. Mais on ne comprend pas qu’il s’agit d’une quantité de monnaie. Ou alors `txBalance`. L’abbrévation `Var` peut avoir plusieurs sens. Et inutile de préciser account, puisqu’on le donne en argument obligatoire de la fonction. > [@elois](#): > > Ce champ `accountBalanceVar` serait positif pour les transactions reçus et négatif pour les transactions émises. Oui voila. Comme dans l’historique des TX de Cesium 🙂 > [@elois](#): > > On pourrait d’ailleurs se baser sur ce champ pour définir la direction. Oui, ca parait logique. A voir ou l’on mettra les TX “opération de change”, du coup. Par exemple, si filtrage par direction : alors on ne les retourne pas. Si aucune direction n’est précisée, alors on les retourne, avec une txBalance = 0. > [@elois](#): > > Tu pourras connaître tous les comptes liés à une clé publique P via une query `accountsWithPubkey` qui te retournera un tableau des scripts des comptes ayant un solde strictement positif et ayant la clé publique P dans leur script. ok, ca me va. Dans ce cas pourquoi ne pas renommer “pubkeyOrScript” en “account” ? ca paraitrait logique que : - accountsWithPubkey =\> renvoi t des “account” - TxHistory(account) =\> renvoi les TX concernant ce compte (un script ou nue pubkey). ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [31 December 2020 16:42 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/84 "2020-12-31T16:42:23Z")
> [@kimamila](#): > > Et inutile de préciser account, puisqu’on le donne en argument obligatoire de la fonction. Au contraire, préciser «account » dans le nom du champ permet de prendre conscience que c’est un champ dont la valeur est relative au compte qu’on observe, que ce n’est pas une propriété intrinsèque de la transaction. Voici pourquoi le nom `txBalance` ne me conviens pas non plus. > [@kimamila](#): > > L’abbrévation `Var` peut avoir plusieurs sens. Le sens de `Var` sera précisé dans la doc. Il vaut mieux indiquer ce suffixe `Var` afin que l’utilisateur de l’API se pose la question et donc lise la doc du champ plutôt que de ne pas indiquer ce suffixe et laisser l’utilisateur de l’API mal interpréter ce champ. Après si dans le code de cesiumV2 tu veux manipuler un nom différent tu peux utiliser la syntaxe de renommage des champs graphql, exemple : ![image](https://forum.duniter.org/uploads/default/original/2X/1/1c3ca941b87d31464480f30ba0b837121daa9efd.png) > [@kimamila](#): > > À voir ou l’on mettra les TX « opération de change », du coup. > Par exemple, si filtrage par direction : alors on ne les retourne pas. Si aucune direction n’est précisée, alors on les retourne On peut également considérer qu’une transaction de change est une transaction envoyée. Où alors l’enum Direction peut avoir des variantes supplémentaires : ```auto enum Direction { SENT RECEIVED ALL CHANGE SENT_AND_CHANGE } ``` Avec ALL comme variante par défaut. > [@kimamila](#): > > Dans ce cas pourquoi ne pas renommer « pubkeyOrScript » en « account » ? C’est bien le nom `account` que j’avais choisi au début. Il fallait alors entrer `"SIG(A)"` pour avoir l’historique du compte `SIG(A)`. Dans un 2ème temps, pour simplifier l’usage, j’ai décidé de convertir automatiquement une pubkey A en SIG(A), c’est là que j’ai changé le nom pour bien signifier qu’une clé publique seule est acceptée. Mais ça peut-être signifié dans la doc, donc oui or peut revenir à `account` comme nom d’input. ---
### Author: ![kimamila](https://forum.duniter.org/user_avatar/forum.duniter.org/kimamila/32/185_2.png) [@kimamila](https://forum.duniter.org/u/kimamila) #### Post date: [1 January 2021 21:52 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/85 "2021-01-01T21:52:56Z")
> [@elois](#): > > Au contraire, préciser «account » dans le nom du champ permet de prendre conscience que c’est un champ dont la valeur est relative au compte qu’on observe, que ce n’est pas une propriété intrinsèque de la transaction. Voici pourquoi le nom `txBalance` ne me conviens pas non plus. Sinon, la comptabilité utilise les concepts de crédit/débit, dont la différence est le solde (balance). Si l’argument “account” est obligatoire, franchement “balance” suffit largement. C’est un historique de TX, donc autant utiliser les concepts existants, et ne pas reinventer la roue. > [@elois](#): > > Où alors l’enum Direction peut avoir des variantes supplémentaires : Cool. L’énumération SENT\_AND\_CHANGE ne me semble pas nécessaire. Il suffira de faire deux requêtes (ce qui est facile en graphql) > [@elois](#): > > Mais ça peut-être signifié dans la doc, donc oui or peut revenir à `account` comme nom d’input. Super. Du coup oui il suffit de détecter si l’argument est une clé publique ou un script. ---
### Author: ![matograine](https://forum.duniter.org/letter_avatar/matograine/32/5_5575768a8748004e209b776fc1b2916d.png) [@matograine](https://forum.duniter.org/u/matograine) #### Post date: [2 January 2021 16:17 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/86 "2021-01-02T16:17:16Z")
> [@kimamila](#): > > Dans ce cas pourquoi ne pas renommer « pubkeyOrScript » en « account » ? Pour ma part, je trouve que “pubkeyOrScript” est bien plus clair que “account”. Le script SIG(\) n’étant pas équivalent à \. ---
### Author: ![kimamila](https://forum.duniter.org/user_avatar/forum.duniter.org/kimamila/32/185_2.png) [@kimamila](https://forum.duniter.org/u/kimamila) #### Post date: [3 January 2021 18:16 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/87 "2021-01-03T18:16:06Z")
> [@matograine](#): > > Pour ma part, je trouve que « pubkeyOrScript » est bien plus clair que « account ». Le script SIG() n’étant pas équivalent à . Script est plus clair que account selon toi ? ---
### Author: ![matograine](https://forum.duniter.org/letter_avatar/matograine/32/5_5575768a8748004e209b776fc1b2916d.png) [@matograine](https://forum.duniter.org/u/matograine) #### Post date: [3 January 2021 19:20 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/88 "2021-01-03T19:20:18Z")
Pour moi oui. Account (compte) est un terme assez vague, qui indique simplement qu’on compte des unités. Script (de déblocage) désigne précisément les conditions à remplir pour utiliser une ou des UTXO. Je comprends bien que, coté Duniter, un `account` est un ensemble de conditions à remplir pour débloquer la monnaie, et que cette notion se confond avec celle de Script de déblocage. Mais coté client, un compte peut désigner autre chose. Deux exemples pour ce « coté client » : - le script `SIG() && XHX()` désigne de la monnaie disponible pour le compte SIG(\), avec une condition. La monnaie bloquée par ce script est uniquement à destination du compte SIG(\). - Un client qui dériverait une clef maître pour envoyer le change des tx sur de nouvelles clefs publiques gèrerait un seul compte, mais de très nombreux scripts de déblocages différents. Qui plus est, la clef publique maître de ce compte pourrait ne jamais être publiée en blockchain, et donc ce « compte » coté client n’existerait pas pour Duniter. (c’est le fonctionnement du client Electrum pour Bitcoin, et certainement d’autres) ---
### Author: ![poka](https://forum.duniter.org/user_avatar/forum.duniter.org/poka/32/6827_2.png) [@poka](https://forum.duniter.org/u/poka) #### Post date: [3 January 2021 19:23 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/89 "2021-01-03T19:23:36Z")
Rien à voir, avec GVA comment peut on savoir l’heure à laquelle a été émise une transaction en Mempool ? Je pense par exemple au cas où une transaction reste en Mempool pendant plusieurs jours, ce qui peut arriver, avons nous le moyens de dater cette entrée ? Pour moi la réponse est « c’est impossible » car aucune date n’est associé à cette entrée en blockchain, mais je peux me tromper. Pour le moment j’affiche _now_ pour les transactions en mempool. ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [3 January 2021 19:58 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/90 "2021-01-03T19:58:42Z")
> [@poka](#): > > comment peut on savoir l’heure à laquelle a été émise une transaction en Mempool ? En théorie c’est l’heure du bloc référencé dans le champ `blockstamp` de la TX, mais il est possible de référencer un bloc dans le passé. Et dans DUBPv13 il deviendra possible de dater une TX dans le futur, donc en effet il deviendra impossible de savoir la date **d’émission** d’une tx. En revanche, étant donné que Duniter sera obligé de stocker de la date de **réception** d’une tx avec DUBPv13 (nécessaire pour l’élagage des piscines), il sera possible pour un contributeur de GVA d’exposer ce champ. L’inconvénient de cette date de **réception** c’est qu’elle ne représente pas nécessairement la date d’envoi sur le réseau, ça peut être plusieurs heures après lors d’une synchro des mempool. ---
### Author: ![tuxmain](https://forum.duniter.org/user_avatar/forum.duniter.org/tuxmain/32/6423_2.png) [@tuxmain](https://forum.duniter.org/u/tuxmain) #### Post date: [16 January 2021 22:07 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/91 "2021-01-16T22:07:45Z")
La requête `query{node{peer{blockstamp}}}` sur ton nœud renvoie un blockstamp vide, est-ce normal ? ---
### Author: ![poka](https://forum.duniter.org/user_avatar/forum.duniter.org/poka/32/6827_2.png) [@poka](https://forum.duniter.org/u/poka) #### Post date: [17 January 2021 01:36 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/92 "2021-01-17T01:36:15Z")
Le noeud est hs depuis cet aprem ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [22 February 2021 23:45 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/93 "2021-02-22T23:45:31Z")
je viens de merger la contribution de @tuxmain qui a ajouté la possibilité d’obtenir le username d’une clé publique : ![image](https://forum.duniter.org/uploads/default/original/2X/1/18b7c12a0a75002d954a38f5a2b12fa5ad017e18.png) Félicitation @tuxmain, tu es le 1er contributeur de GVA 😊 À quand le 2ème ? 😃 ---
### Author: ![tuxmain](https://forum.duniter.org/user_avatar/forum.duniter.org/tuxmain/32/6423_2.png) [@tuxmain](https://forum.duniter.org/u/tuxmain) #### Post date: [24 February 2021 11:30 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/94 "2021-02-24T11:30:58Z")
J’ai fait une MR pour obtenir un bloc à partir de son numéro. D’ailleurs les requêtes currentBlock et node.peer.blockstamp disent qu’il n’y a pas de blockchain, chez moi, même si la requête block marche. Ça le fait parfois aussi sur ton nœud. Après ça le plus important est d’ajouter les certifications aux identités, je pense, mais là il faut toucher à la db… Edit: Est-ce que ça pourrait avoir un rapport avec le bug (ou un des bugs) de blocage des nœuds ? Mon nœud s’est bloqué (un bloc considéré invalide) et j’ai vu ça dans le log, ça parle d’empty blockchain : ```auto 2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Block resolution: 0 potential blocks after current#401670... 2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: 9 potential block(s) found... 2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: 1 potential suite(s) found... 2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: HEAD = block#401670 2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: suite 1/1 (-> #401684-000000) revert to fork point block#401669 2021-02-24T13:46:27+01:00 - ^[[32minfo^[[39m: Fork resolution: suite 1/1 REFUSED block#401670: Try to apply non genesis block on empty blockchain 2021-02-24T13:46:27+01:00 - ^[[31merror^[[39m: Unhandled rejection: Error: ruleNumber 2021-02-24T13:46:27+01:00 - ^[[31merror^[[39m: Error: ruleNumber at Function.checkBlock (/home/tuxmain/Documents/projets/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19) at process._tickCallback (internal/process/next_tick.js:68:7) ``` ---
### Author: ![vit](https://forum.duniter.org/user_avatar/forum.duniter.org/vit/32/2775_2.png) [@vit](https://forum.duniter.org/u/vit) #### Post date: [24 February 2021 16:58 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/95 "2021-02-24T16:58:28Z")
Excellent ! J’en aurais besoin pour Tikka ! 👍 ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [25 February 2021 02:08 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/96 "2021-02-25T02:08:14Z")
> [@tuxmain](#): > > D’ailleurs les requêtes currentBlock et node.peer.blockstamp disent qu’il n’y a pas de blockchain, chez moi, même si la requête block marche. Ça le fait parfois aussi sur ton nœud. Oui c’est normal c’est le cas quand le noeud viens d’être restart et qu’il n’a appliqué aucun nouveau bloc entre temps. > [@tuxmain](#): > > Edit: > Est-ce que ça pourrait avoir un rapport avec le bug (ou un des bugs) de blocage des nœuds ? Houla non absolument rien à voir ! ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [26 February 2021 02:43 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/97 "2021-02-26T02:43:34Z")
9 messages ont été scindés en un nouveau sujet : [Erreur GVA: Upgrade Required](https://forum.duniter.org/t/erreur-gva-upgrade-required/8120) ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [11 March 2021 00:27 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/98 "2021-03-11T00:27:12Z")
Plusieurs changements importants sur la taille d’une page (paramètre `pageSize`) de toutes les requêtes paginées : - `pageSize` vaut désormais 10 par défaut. - La valeur maximale de `pageSize` est fixée à 1000. - Si `pageSize` vaut zéro, cela est interprété comme l’infini (une seule page qui contient tout). **Seuls les clients whitelistés ont le droit d’utiliser la valeur zéro** pour `pageSize`, c’est une idée que@tuxmain m’a donné il y a quelques semaines et que j’ai implémenté ce soir 🙂 @tuxmain du coup tu vas devoir adapter ta MR en cours sur la requête blocks 😛 ps: notez également que les clients whitelistés ne sont pas soumis à la limite 1000. La valeur maximale de `pageSize` est pour eux la valeur maximale d’un entier non-signé de 32 bit 😉 ---
### Author: ![tuxmain](https://forum.duniter.org/user_avatar/forum.duniter.org/tuxmain/32/6423_2.png) [@tuxmain](https://forum.duniter.org/u/tuxmain) #### Post date: [11 March 2021 11:09 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/99 "2021-03-11T11:09:13Z")
> [@elois](#): > > @tuxmain du coup tu vas devoir adapter ta MR en cours sur la requête blocks 😛 C’est fait ! J’espère que c’est prêt à merger maintenant ? Ce pauvre commit aura été amendé plein de fois… Au passage tu as laissé `/// Transactions history` devant la requête `utxos_of_script`… Une requête importante pour la suite serait les certifications. Est-ce que c’est faisable actuellement ? (avec `CIndexDbV1` ?) Est-ce qu’il faudrait l’intégrer dans `idty` ou la mettre à part ? ---
### Author: ![elois](https://forum.duniter.org/user_avatar/forum.duniter.org/elois/32/1541_2.png) [@elois](https://forum.duniter.org/u/elois) #### Post date: [11 March 2021 16:28 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/100 "2021-03-11T16:28:42Z")
> [@tuxmain](#): > > J’espère que c’est prêt à merger maintenant ? Je viens de reviewer, il marquait juste un map\_or\_else, j’ai amend puis mergé 😃 > [@tuxmain](#): > > tu as laissé `/// Transactions history` devant la requête `utxos_of_script` Bien vu je corrige 🙂 > [@tuxmain](#): > > Une requête importante pour la suite serait les certifications. Est-ce que c’est faisable actuellement ? (avec `CIndexDbV1` ?) Est-ce qu’il faudrait l’intégrer dans `idty` ou la mettre à part ? Non tout ce qui touche à la wot n’est pas encore faisable. DbV1 n’est pas accessible par Duniter car verrouillé par nodejs, seul dex peut y accéder (si duniter est arrêté). ---
### Author: ![poka](https://forum.duniter.org/user_avatar/forum.duniter.org/poka/32/6827_2.png) [@poka](https://forum.duniter.org/u/poka) #### Post date: [11 March 2021 19:36 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/101 "2021-03-11T19:36:54Z")
Noeud p2plegal upgrade avec succès. [Previous page](https://forum.duniter.org/t/prototype-de-gva/7688.md?page=4) [Next page](https://forum.duniter.org/t/prototype-de-gva/7688.md?page=6)