Binarisation vs Format text du protocole blockchain

Protocols DUBP
1

Bon, ça m’agaçe un peu les échanges en privés alors je relance le sujet ici.

Pour rappel, dans les derniers mois, suite au réflexions apportées par @nanocryk, il avait été décidé de binariser le protocole blockchain à moyen terme.

Récemment, @anon2076149 est arrivé. La situation s’est envinimée en privée suite à un désaccord complet de @anon2076149 sur ce sujet. Je pense que ça mérite d’y réfléchir au regard d’une idée proposée par @cgeek il y a quelques temps.

Je liste ci-dessous 5 points que j’identifie comme “avantages” du binaire ou du texte et leur criticité à l’heure actuel.

Binarisation :

  • (1 - Important) Mieux formaliser le protocole
  • (2 - Optionnel) Améliorer les performances
  • (3 - Important) Le rendre plus robuste et évitant de s’appuyer sur des regex & co

Format texte :

  • (4 - Important) Facilité à débugger (pas besoin de lire des bytes)
  • (5 - Critique) Facilité à faire évoluer et à faire comprendre des nouveaux développeurs

Il existe une autre piste, celle de rester sur le format texte mais de faire un effort de formalisation. @cgeek avait proposé le format YAML pour les documents. (On peut envisager d’autres formats, le YAML étant quand même très complexe en terme de règles de syntaxe) L’utilisation d’un tel format permettrait de fortement formaliser le protocole et de s’appuyer sur des parsers déjà existants et robustes. Ca répond aux points (1) et (3)

Pour l’amélioration des performances (2), comment est-ce que font les protocoles suivants, tous au format texte ?

  • HTTP
  • XMPP
  • SMTP
  • Matrix
  • …

Tout simplement en compressant les données à la volée.

Ne peut-on pas s’accorder sur 2 points distincts :

Merci de m’avoir lu, j’attends vos retours ! :slight_smile:

1 Like
2

+1

+1

100% d’accord avec les propositions d’@inso. La binarisation n’est pas le seul moyen de mieux formaliser le protocole, mais il apporte beaucoup de contraintes pour les développeurs (des noeuds notamment - au pluriel car il y aura plusieurs implémentations). Cela nécessite aussi de nouvelle API spécifique pour les logiciels clients (pour récupérer un format texte et éviter le traitement côté client)

Rappelons, enfin, que les noeuds stockent généralement les données dans une base de données. La binarisation ne concerne donc QUE le stockage avant traitement (buffer), l’archivage (optionnel), et surtout la diffusion sur le réseau. C’est donc un domaine très réduit qui est concerné, qui ne concerne en aucun cas les performances de contrôle de règles, de génération de bloc, etc. Le stockage, quant à lui, ne coute vraiment rien…

1 Like
3

100% d’accord avec les propositions d’@inso.

Je soutiens donc aussi l’option la plus pragmatique à court terme qui est de :

  • :+1: Normaliser le format texte en YAML (je l’utilise tous les jours, les IDE et les parsers identifient tout de suite la validité du format).
  • :+1: Compresser les données pour les transferts (comme HTTP et consorts).

Bref, consolider l’existant avec des solutions simples, éprouvées et standardisées.

La binarisation est effectivement un projet lourd et à plus long terme. Et je pense qu’elle doit aussi s’appuyer le plus possible sur des standards existants, voir : /!\ Significant : RFC WS2P V2 /!\

3 Likes
4

Quelques limitations du format YAML toutefois :

  • Certaines implémentations de parsers permettent d’exécuter du code ( https://pyyaml.org/wiki/PyYAMLDocumentation )
  • Le langage officiel permet d’utiliser plein de choses qui sont inutiles voir nuisibles dans le cas de duniter :
    • Les ancrages et références
    • Les commentaires
    • La rétro-compatibilité json
    • …

Peut-être qu’il y aurait d’autres langages plus adaptés à cette formalisation. Ou alors on spécifie un subset de yaml (mais alors on ne peut pas s’appuyer sur les parsers standards)

1 Like
5

J’identifie d’autres avantages important pour le format binaire :
4 - Réduire fortement la taille des bloc pour la même quantité de charge utile.
5 - Empêche tout bug lié a l’inscription en blockchain de documents d’un format inattendu → ce point me semble d’autant plus importants que l’on a désormais plusieurs implémentations.

Concernant les performances, il me semble que ce n’est pas optionnel si on garde la volonté que des raspberry puisse exécuter un nœud complet derrière un faible débit. Ce qui est personnellement l’un de mes objectifs.

C’est déjà ce que j’ai prévu pour WS2Pv2, Durs utilisera permessage-deflate. Permessage-deflate n’est toutefois pas envisageable pour Duniter Typescript a cause d’un gros problème de memory leak en nodeJS : zlib deflate results in a memory leak · Issue #8871 · nodejs/node · GitHub

Dans le cas de Duniter Typescript donc, la binarisation me semble important pour optimiser les transferts réseau puisse que l’on ne pourra pas compresser les données.

Concernant WS2Pv2 je suis déjà parti sur une binarisation des fiches de peer et des head, après chaque document aura aussi un format JSON pour être lisible par un humain. Tout ce que vous aurez a coder c’est une conversion du document JSON vers le document binaire pour pouvoir vérifier les signatures ou signer.

Concernant le protocole blockchain je reste favorable à une binarisation a moyen terme, je trouve au contraire le binaire plus facile a manipuler que le texte :slight_smile:
Et c’est le langage naturel pour la machine.

Ceci étant on a encore le temps de voir venir, je voudrais déjà arriver a faire une v1 du Durs complète avant de proposer une spécification pour la binarisation du protocole, donc pas avant 2020 voir 2021.

Donc soit améliorons le format Texte entre temps, ça va me faire plus de boulot mais je me plie a la majorité.

1 Like
6

Ce qui sera inutile si on se permet d’oublier les blocs passés :slight_smile:

Oui alors là, je ne vois pas pourquoi le binaire empêcherai de manière absolue l’inscription de bugs dans la blockchain. Je ne vois pas la différence avec le texte, si il y a un bug de parsing, et bien… Ca bugguera. Quelque soit le format sous jacent. Le binaire peut même apporter pas mal de risques (attaque par dépassement de mémoire, sortie de stack & co).

Pour WS2P, la binarisation me parait cohérente avec les objectifs. L’objectif est de fluidifier un maximum le réseau et les échanges entre noeuds, donc il faut que ça soit léger et rapide. Le protocole est léger et petit, donc la binarisation d’apporte pas de complexification outre-mesure.

1 Like
7

Des liens pour alimenter le débat :

Un dev .NET compare les performances des sérialiseurs

Pour la binarisation, il y a messagepack pour binariser du json et les protobuffers de go-lang.

Pour le format texte, nous avons le json qui fonctionne bien, assez lisible pour un humain. Si on le sérialise en retirant tous les espaces, on peut signer un document sans ambiguïté.

Le yaml est surtout pour créer des fichiers lisibles ET éditables facilement par des humains.
Si nous n’avons pas ce besoin, alors effectivement, YAML ajoute trop de choses (commentaires, indentation variable selon les fichiers, mais toutes acceptées par les parsers…).

Pour analyser nos besoins et problèmes sur le format des documents, il faudrait faire un schéma uml de leur cycle de vie. On verrait ainsi, à chaque étape de leur vie, si le format doit changer (sérialisation/dé-sérialisation).

2 Likes
8

MessagePack a l’air très intéressant, c’est marrant hier justement je regardai les spec du bson et j’étais assez déçu par les spec (notamment ça me gène beaucoup qu’il ne supporte pas les entiers non-signés).
MessagePack semble beaucoup plus complet et avec une plus grosse communauté derrière, en plus il il ya des lib pour Java et NodeJS et Rust donc ça sent très bon :slight_smile:

Le JSON c’est déjà beaucoup mieux que le format raw actuel, on peut effectivement réussir a signer les documents au format JSON minifié puis les transmettre sur le réseau au format MessagePack.

On pourrait notamment utiliser la structuration du json pour éviter les script string qui posent de nombreux problèmes.
Par exemple le script Sig(A) && HXH(B) pourrait devenir quelque chose du style:

{
    output_conditions: {
            op: "And",
            a: { op: "Single", a: "Sig(A)", b: null }
            b: { op: "Single", a: "HXH(B)", b: null }
    }
}
2 Likes
9

Petite remarque à propos de la signature des données, que ce soit Json ou Yaml, il faudra aller plus loin.

En effet, ce sont des formats clé-valeur. Les structures ne sont donc pas ordonnancées, et des implémentations différentes peuvent générer deux signatures différentes pour un même process : texte -> objet json -> texte -> signature.
On est alors dans une situation ou deux structures équivalentes en terme de clé-valeur mais qui les stockeraient dans un ordre différent génèrerait une signature différente.

La signature de tels documents devrait donc s’appuyer sur un algorithme précis, tel que celui utilisé dans sakia pour comparer les réponses json :

   def ordered(obj):
       if isinstance(obj, dict):
           try:
               return sorted((k, ordered(v)) for k, v in obj.items())
           except TypeError:
               return obj
       if isinstance(obj, list):
           try:
               return sorted(ordered(x) for x in obj)
           except TypeError:
               return obj
       else:
           return obj

Cet algorithme d’exemple parcours une structure de donnée clé-valeur et tri les données dans l’ordre alphanumérique, de façon à ce que les deux dictionnaires suivant soient considérés comme étant les mêmes :

{ 
   "keyA": "value"
    "keyB", [1, 4, 2]
}

et

{
   "keyB": [2, 1, 4],
   "keyA": "value"
}

Là, c’est en python, pour comparer les réponses BMA de noeuds différents, mais il faudrait définir ce qu’est un tri pour signature et s’assurer qu’il soit le même dans toutes les implémentations :

  • Dans quel ordre est-ce qu’on place les éléments 1, a et A?
  • Faut-il trier le contenu des listes ?
  • … ?
1 Like
10

Pour 1/, as-tu des exemples ?

Pour 2/, ça dépend de quoi on parle. Car il est déjà possible pour Duniter de traduire tout document texte en binaire, utilisant son propre format binaire sans gêner personne. Est-ce que Duniter en serait plus performant pour autant ? Les traitements internes seraient possiblement plus rapides, certes, mais quid du coût de transformation texte → binaire ? Ne consomme-t-il pas déjà la gain ?

Pour 3/, on peut déjà ne pas utiliser de regex, c’est juste moi qui ai codé comme ça par facilité mais il est possible de faire autrement.

Par contre je suis beaucoup plus gêné par les conditions de transactions au “format” grammaire BNF, qui est un peu trop lâche/permissive. Changer cette partie au profit d’une autre notation (mais toujours au format texte), par exemple en binaire sérialisé en Base64, permettrait de corriger efficacement ce point dès aujourd’hui.

Pour 4/, ça rejoint ma remarque à @Inso : on peut toujours traduire les blocs en internes dans le format qui convient le mieux à notre implémentation. Le format binaire n’est pas spécialement le meilleur, ça dépend de ce qu’on veut faire. Et concernant l’avantage de transfert réseau : toi-même tu expliques qu’il est possible de compresser, une méthode possible étant de transformer les documents textes en binaire (dans le format que vous avez déjà commencé à spécifier par exemple) avant envoi.

Pour 5/ je ne vois pas ce que tu veux dire.

11

On pourra par contre permettre à de petites connexions de participer, ainsi que de potentiellement augmenter la charge utile. Donc rendre le stockage “plus compact” est bénéfique, et ce peut importe s’il y a du pruning ou non.

1 Like
12

Cet aspect me semble essentiel et à cet effet, le YAML me semble un excellent candidat, pour sa lisiblité et le fait qu’il accepte les commentaire.

Les optimisation de perf/volume du passage au binaire me semble secondaire, ceci dit, pour qu’elle soit effective, il me semble en effet nécessaire de ne pas contrebalancer le gains par des conversions depuis un format texte. Du coup, je ne retient pas l’argument :
Les gain de perf binaire n’ont pas besoin d’un standard binaire puisqu’on peu convertir.

Si on est en binaire sur toute la ligne, avec les gain de volume/perf associé, ça me semble plus cohérent que de dire : les petite machine qui gagnerais à avoir du binaire vont se fader toutes les conversions vu que le standard est en format texte.

Ceci dit, le gain du binaire par rapport au texte en matière de perf et volume me semble ridicule par rapport à un une amélioration de complexité d’un algorithme.

Je trouve essentiel de pouvoir représenter les documents de la blockchain en format texte (YAML par exemple) pour en faciliter la compréhension.
Ceci dit, que ce soit le format natif interne ne me semble absolument pas indispensable du moment que des convertisseurs sont disponible dans chacun des langages que les développeurs souhaitent utiliser (là ou des format tel que YAML ou json ont des parseurs déjà existant qui évite d’avoir à faire ces développement supplémentaire).

En gros, signer un binaire plutôt qu’un YAML acceptant les commentaires me semble plus pertinent. Mais devoir me coder un interpréteur/convertisseur dans mon langage favoris pour pouvoir interagir avec la blockchain aisément me semble un frein à l’adoption.

Concrètement je serais donc favorable à un format binaire si et seulement si il est fourni avec des convertisseur bidirectionnel fiable dans tout les langages à minima de la communauté actuelle, voir plus : javascript coté client et server +(typescript/node.js), python, rust, java, pascal version wot-wizard (voir c, C++, go, ?.net )

Sinon, je suis favorable à un subset de YAML, ou à défaut un subset de json, ou à défaut un dialect xml.
Un subset tel qu’il soit possible de faire une conversion sans perte(réversible) dans un autre format de travail sans avoir besoin de stocker des informations superflu pour ne pas altérer la vérification de signature. (donc ne pas devoir stocker commentaire, ordre des champs, s’il sont inline ou non…)

Que l’ordre des champs puisse être variable ne me semble pas dramatique, mais reste mal pratique pour pouvoir stocker autrement et re vérifier les signature ulterieurement.
Qu’il n’y ai pas dans le format des block, de possibilité d’inclure des commentaire me semble en revanche essentiel pour éviter des attaque par spam de commentaire.

Pour ma part c’est une formulation différente de :

1 Like
13

Autant ignorer/trier/standardier l’ordre entre KeyA et KeyB me semble pertinent, autant l’ordre des élément [2, 1, 4] me semble généralement signifiant, et seulement marginalement superflus, du coup le rendre équivalent me semble dangereux sauf cas précis identifié.

1 Like
14

Une limitation sur laquelle j’insiste est qu’il rend le debug ainsi que l’apprentissage du protocole plus difficile (il faut lire des octets dans le debugger plutôt que du texte). Même si on dispose d’un convertisseur…

Oui j’ai directement copié collé le code de Sakia (qui fait de la comparaison entre noeud qui envoie la même info dans des ordres différents dans les cas des listes de certifications typiquement) :slight_smile:

Mais oui, dans le cas de Duniter, ça me parait absurde de trier les listes de données.

Là dessus c’est vrai, rien ne vaut la signature de données binaires ou de texte brut (tels que les documents actuels).

Tout passage par un format type “structure de données json / xml / yaml” me semble avoir un impact majeur sur la gestion des signatures. La solution me semble être de développer un subset plus strict du json / xml / yaml . Mais cette solution ne permet pas de s’appuyer sur des parseurs existants, seulement des convertisseurs vers d’autres formats (ce qui est déja intéressant en soit).

15

Là je ne suis pas d’accord :
Un parseur classique permet d’utiliser les données contenues pour tout usage sauf valider le bloc. Le fait de valider l’appartenance au subset n’est, je pense, utiles que dans les cas suivant :

  • pour valider un bloc
  • pour émettre un document à inclure dans un bloc.

Bref, l’accès de base au données peut se faire avec un parseur standard, ce qui est un gain appréciable. (gain qui peut être commun avec des parseurs standard de format binaire s’ils existe).

16

C’est justement une idée qui me traversais l’esprit ces jours-ci :slight_smile:
Par exemple pour WS2Pv2 j’aimerais bien faire une lib Rust qui pourra être bindée dans NodeJs afin de ne pas avoir besoin de réécrire deux fois le code de traitement des documents binaires de WS2Pv2.
Après tout langage qui peut binder du C peut binder du Rust car les lib dynamiques Rust sont manipulés de la même façon, ainsi il est possible d’utiliser une lib dynamique Rust dans Java, dans Python, dans Angular via WebAssembly, etc
la seule exception étant Component Pascal mais wot-wizard ne vérifie pas les signatures donc il peut sans problème récupérer les documents déjà convertis par le noeud qu’il utilise.

Il me semble que les questions de stockage et de performance sont différente. La performance c’est le temps de calcul d’un traitement, la taille des blocs c’est un problème de stockage pas de performances, et c’est un vrai problème pour toutes les crypto-monnaies qui sont passés a l’échelle.
Il me semble préférable de réfléchir maintenant a ces problématiques de stockage car si nous attendons le jours ou ça se fera sentir ce sera déjà trop tard, une bonne solution est effectivement de ne pas stocker tout les blocks comme déjà discuté dans d’autres sujets, mais nous auront toujours besoin de quelques nœuds d’archives qui garderont tout, et l’on peut vite dépasser les 10 To si l’on optimise pas le stockage.

En tout les cas stockage et performances sont deux choses différentes :wink:

Tout l’intérêt étant justement que le cœur n’aurait pas besoin de faire de conversion. La conversion, ou plutôt l’export au format texte n’a de sens que pour afficher, donc ne serait fait qu’en mode tests/debug.
Pour des performances optimales, en mode prod seul les clients feraient la conversion.

Alors deux remarques par rapport à ca:

  1. On ne peut hélas pas compresser en NodeJs : zlib deflate results in a memory leak · Issue #8871 · nodejs/node · GitHub
  2. Si on converti les données avant chaque envoi ça représente un coût, la conversion ne devrai se faire que pour afficher le document pour les tests et le débogage.

Je parle par exemple du bug détecté par @Max ou il a pu créer une source indépensable et omettant une parenthèse. Ce type de bug ne peut pas arriver en binaire, le format texte est ambigu par nature et cela ouvre des vecteurs d’attaque.
Il est quasiment impossible de définir des spec d’un format texte qui laisse zéro ambiguïté dans tout les cas possibles.

Si c’est que ça on peut exporter les documents en YAML, ça ne pose aucun problème.

1 Like
17

AMHA il reste à démontrer que cette assertion, qui est probablement vraie, ne s’appliquerait pas à un format binaire (un format binaire n’est qu’une suite de tokens de la même manière qu’un format texte).

C’est une autre piste, effectivement intéressante : développer une librairie de parsing des données, commune à plusieurs langages

18

Je suis pour !
S’il y a un format interne binaire, qu’il y ai un script léger, utilsable en cli comme en tant que module dans d’autre programme qui permette de généré un joli export YAML avec des commentaire explicatif du rôle de chaque donnée, je vote pour ! (sinon je vote pour un format texte dont les clef soit suffisamment parlante pour ne pas avoir besoin de les expliquer en plus)

Alors, si la possibilité d’avoir le contenu en clair/texte dans le navigateur passe par du webassembly, tant que les tuto/prérequis pour ça sont aussi long, ça me semble un mauvais plan. Parser du json (ou même du YAML), ça reste très simple depuis un navigateur, donc la prise en main pour un dev qui veux nous rejoindre est faible. Faire tourner du webassembly dans le navigateur, ce n’est pas insurmontable, mais ça rajoute clairement une couche de complexité.

Différente, oui, mais assimilable :
2 fois plus rapide, c’est cool, mais ça change pas la face du monde.
2 fois (ou même 10 fois) plus petit, c’est cool, mais ça ne change pas la face du monde.

Au contraire, un changement d’algo qui va permettre de passer d’une complexité n² à une complexité log(n) par exemple, ça, ça change la vie coté perf.
De même, qu’en dehors des nœud d’archive, il soit possible de ne garder que les derniers bloc, ça change tout coté stockage. De façon incomparable par rapport au gain que l’on pourrais obtenir par une binarisation.
Quand au stockage des nœuds d’archive, rien ne les empêche de convertir en interne à un format plus compacte, tout en restant réversible. En effet, leur usecase n’est pas d’être des nœuds légers dont on allège les traitement au maximum, mais d’être des nœuds d’archivage, qu’on consulte de temps à autre, quand on a besoin de vieilles info.

1 Like
19

Mwarf, dis comme ça je trouve ça ridicule. En l’occurrence je ne parle pas d’un algorithme de compression en particulier, mais simplement du fait que l’on peut traduire du texte en binaire. C’est bel et bien une forme de compression.

Ensuite s’il y a des bugs d’implémentation dans telle ou telle lib c’est un autre problème.

Dans la perspective d’un logiciel haut de gamme portant des centaines de milliers d’utilisateurs, c’est possible oui. Encore que je ne saurais pas dire à quel moment un format binaire, et transmis tel quel sur le réseau de façon à n’avoir aucune conversion nécessaire à aucun moment pour le fonctionnement du cœur, devient nécessaire.

Pour l’instant c’est de la sur-optimisation je pense, mais à long terme c’est quand même un peu indispensable.

2 Likes
20

C’est pas toujours vrai, le deflate gzip est géré par la carte reseau de nos jours, c’est des petits composant dédiés et donc ça ralentis pas ton proc. pour ce qui est du layout en memoire, ton entier 16 bit dans la plupart des proc utilisera 32 ou 64 pour etre multiplié donc ca change rien non plus , et finalement en augmentant la taille des blocs, j’ai de grand doute qu’'un mec tout seul, aussi malin soit-il compresse mieux qu’un algo generique :

si ma pubkey c’est aaaaaaaaaaaaaaaaa
que la tienne c’est bbbbbbbbbbbbbbbbb

Combien de bits ton algo va utiliser pour la stocker ? cherche pas plus loins… ton algo est ptet op, rapide tout ce que tu veux, c’est en additionnant les donnés que tu les compresse et tu peux te faire chier autant que tu veux t’arrivera tout juste au niveau des format générique de compression! tu peux avoir un format “petit” mais tu peux pas garantir qu’il sera toujours “le plus petit” parce que si tu rajoute des champs demain, un format générique compressera aussi bien qu’avant mais pas forcement le tiens et alors soit tu recode tout pour avoir le plus petit format, t’ajoutera des dictionnaires, … et t’aura perdu ton temps, un zip bien choisis fera l’affaire et emmerdera bcp moins les mainteneur du futurs.
Tu peux avoir la meilleur idée du monde en binarisant, c’est géniale de montrer que ça tiens sur arduino, en évoluant ton protocole va te sauter à la gueule. parce qu’il y aura un truc que t’as pas prevus et alors ton format va se mettre à cramer.

Des malins qui penses comme ça yen a eux pleins, résultat Cobol existe encore !!

Un algo générique oui, il le fera sans erreur, il saura le sérialisée, dé sérialisé et sera interprété par autant de langages que le standard accepte. En ce qui me concerne, ton argument de perf ou de volume est nul car tu fera pas mieux tout seul que les décennies de recherche sur le sujet. peut être, dans 30 ans t’aura gagné quelques bit en stockage et si t’arrive a faire mieux que parquet, avros, protobuf, … et que tu le prouve on en reparlera. moi j’y crois pas, tant que j’ai pas vue ton benchmark qui montre véritablement un gain, je me fais pas chier avec. et puis ton arduino ou ton raspberry, tu connais les caractéristiques du proc ? le bus ? le cache ? la mémoire ? tu sais prouver que ce que tu avance est vrai? et sur une VM ton format, ton algo il performe comment ?

Évidemment on peux faire mieux qu’un vieux format texte, mais c’est pas la pierre angulaire d’une crypto et ca ne le sera jamais. L’écrire en YAML par contre ça permet a des milliers de développeur d’hacker le truc et de ne plus dépendre d’une seule implémentation, d’avoir pleins d’outils qui l’intègre.

Du coup je code la grammaire en antlr4 et bon, ça traduis:

Cben@ben:~/ws/juniter/grammar$ antlr4 PG*.g4 ; javac PG*.java;  grun PG doc tests/certif.dup      

doc:
    version: 10
    currency: beta_brousouf
    certification: 
            issuer: DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLV
            idtyIssuer: HgTTJLAQ5sqfknMq7yLPZbehtuLSsKj9CxWN7k8QvYJd
            idtyUniqueID: lolcat
            idtyTimestamp: 32-DB30D958EE5CB75186972286ED3F4686B8A1C2CD
            idtySignature: J3G9oM5AKYZNLAB5Wx499w61NuUoS57/VccTShUbG+-MjCqj9yXXqNq7dyZpDWA6BxipsiaMZhujMeBfCznzyci
            certTimestamp: 36-1076F10A7397715D2BEE82579861999EA1F274AC
            signature: SoKwoa8PFfCDJWZ6dNCv7XstezHcc2BbKiJgVDXv82R5zYR83nis9dShLgWJ5w48noVUHimdngzYQneNYSMV3rk

ben@ben:~/ws/juniter/grammar$ cat tests/certif.dup 
Version: 10
Type: Certification
Currency: beta_brousouf
Issuer: DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLV
IdtyIssuer: HgTTJLAQ5sqfknMq7yLPZbehtuLSsKj9CxWN7k8QvYJd
IdtyUniqueID: lolcat
IdtyTimestamp: 32-DB30D958EE5CB75186972286ED3F4686B8A1C2CD
IdtySignature: J3G9oM5AKYZNLAB5Wx499w61NuUoS57/VccTShUbG+-MjCqj9yXXqNq7dyZpDWA6BxipsiaMZhujMeBfCznzyci
CertTimestamp: 36-1076F10A7397715D2BEE82579861999EA1F274ASoKwoa8PFfCDJWZ6dNCv7XstezHcc2BbKiJgVDXv82R5zYR83nis9dShLgWJ5w48noVUHimdngzYQneNYSMV3rk

Yaml, json, xml, sont des parser évidement riche en exemple pour antlr, il ne sera pas dur de les integrer.
Le binaire n’est rien d’autre qu’un lexer différent… des lors, plusieurs formats/versions peuvent être parsés au seins d’un même arbre…sémantique. récursivité quand tu nous tiens!!!

En utilisant un tel formalisme il est possible de montrer que deux formats sont compatible par exemple et de faire évoluer le protocol de manière safe à travers le temps… Quelqu’un soumet un format pour lequel il produit un parser universel, puis les gens l’implémente ou non. il pourrait y avoir des milliers de spécifications.

Grâce aux “predicates” d’antlr, je peux (en théorie) implémenter les règles de validation local des documents.

Avec antlr4, on peux générer le parseur / traducteur nativement en Python2&3, Java, Javascript, Cpp, Csharp, Go.

En principe, si je complète ce truc il ne restera “que” la machine à état a implémenter dans 7 langues pour atteindre 95% des informaticiens vivant.

Le titre de ce thread devrait être “technocratie” vs “communication” voila des concepts qui parfois s’opposent dans la recherche du consensus

2 Likes