 Ok, donc bonjour à tous et à toutes. Bienvenue à ce beat-up dans lequel Julien Roland et François Boupote vont nous faire la démonstration d'une génération pauvre et d'un chaine pote, IPL Joe Fabri. Donc je vais laisser la parole à Julien François pour se présenter et rentrer dans le vif de ce sujet. Merci, merci Kevin. Donc je suis donc Julien, donc docteurant chez EDF, où je suis encadré par Pierre-Yves Pirillou qui est présent dans ce webinaire et qui est ingénieur-chercheur et je vais présenter avec François du CEA un aperçu de notre travail autour de la génération prouvée d'un chaine code IPL Joe Fabri. Donc dans un premier temps je vais vous décrire le cadre de notre travail et on va notamment parler de l'utilisation de chaine code IPL Joe Fabri dans la filière nucléaire ainsi que de l'application de méthodes formelles au niveau de cette chaine code et dans un second temps je vous donnerai un aperçu des étapes qui composent notre génération prouvée de chaine code IPL Joe Fabri et qui répond donc à nos besoins. Et dans une seconde partie de présentation François vous présentera son travail autour de l'implémentation d'un chime dans le langage au camel et que nous utilisons. Julien, je t'arrête, on ne voit pas tes planches, enfin on ne voit que la première planche. Ah bon ? Ouais, on a une vue sur Powerpoint avec ta première planche mais... Tu dois partager l'autre écran. Ouais, ça doit être une histoire. Il faut que tu partages l'écran plutôt que partager la fenêtre. Mince, désolé. C'est malin ? Ouais, c'est mieux. C'est bon là ? Ouais, ouais. Je ne reprends plus le début, je suis désolé. Non, non, bah non. Continue d'où tu en es. D'accord, ok. Tac, tac, tac, ok. Et donc d'abord un petit peu de contexte sur notre travail. Donc le Pôle Recherche et Développement de DF a identifié le besoin de pouvoir administrer et tracer les données probantes des opérations industrielles de manière plus sécurisée et plus transparente dans le cadre de la filière nucléaire. Et ils ont donc initié un projet de DLT, technologie de registre décentralisé, pour contrôler et suivre le bon déroulé de ces procédures industrielles. Ce qui en fait donc un système critique à plusieurs égards. Donc on a l'habitude de classifier la criticité d'un système en quatre catégories. Et dans le cadre de notre système, une panne ou un comportement erroné ne menacerait pas l'avis de personne ou ne causerait pas un coup d'arrêt aux activités de DF. Par contre, une défection du système pourrait nuire à l'image de l'entreprise, à la confiance que ses partenaires et ses clients lui portent et il pourrait aussi donner lieu à une fuite d'information sensible. Donc on comprend donc qu'il est nécessaire d'apporter des garanties solides quant à la bonne exécution de ce système, qui va faire interagir les opérateurs ainsi que les sous-traitants de ces opérations industrielles, mais également les régulateurs, les autorités qui vont contrôler et auditer les données probantes en suivant donc le bon déroulement de ces opérations. Donc sachez que l'idée de dynamiser les échanges dans la filière nucléaire et d'apporter plus de transparence et de confiance vis-à-vis des régulateurs a été déjà explorée par les opérateurs falandais et australiens donc au travers des papiers que nous citons. Dans notre système, nous avons décidé d'utiliser la blockchain IPA-Lger Fabrique afin de permettre à ces différents acteurs de pouvoir interagir de manière sûre et transparente en utilisant un chain code pour encoder ou retranscrire l'application métier de chaque opération industrielle souhaitée. Donc on peut justifier l'utilisation de la blockchain IPA-Lger Fabrique en listant les différents avantages et les atouts qu'elle nous apporte. Dans un premier, la blockchain est permissionnée. Ça nous permet de contrôler qui a accès aux différentes données. Elle permet également la confidentialité des smart contracts et l'utilisation d'un système travail data collection qui permet donc de sécuriser les données qui transitent dans les smart contracts. Ces 3 fonctionnalités apportent des garanties assez substantielles qui répondent à l'aspect critique de la sécurisation des données dont nous avons besoin. Pour ce qui est de l'aspect critique du bon fonctionnement de l'application métier et donc des chain codes que nous voulons développer, on peut s'appuyer sur la fondation IPA-Lger dont la communauté est très active et ainsi que sur une documentation assez détaillée. Mais ces derniers points ne sont pas suffisants. On a besoin d'apporter plus de garanties au niveau logiciel de l'application métier notamment pour justifier de son bon fonctionnement. C'est pourquoi l'utilisation des méthodes formelles est la réponse adéquate pour répondre à ce besoin de garanties car les simples tests ne suffisent pas et ne peuvent pas éprouver exhaustivement le programme. Grâce aux méthodes formelles, on va pouvoir obtenir des garanties de correction et mais ce à plusieurs niveaux. Le premier niveau serait donc d'utiliser un langage de programmation qui est fortement tippé. On va aussi vouloir chercher à prévenir les erreurs d'exécution du programme comme les overflows. On veut garantir les propriétés fonctionnelles du code de l'application métier et on peut également vouloir effectuer une génération correcte de deux programmes et qui est la méthode qui apporte le plus de garanties. On en vient donc à notre contribution et à notre positionnement. Lors d'un précédent webinaire, il vous a déjà été présenté, si vous y avez assisté, un Chim Hyperledger Fabric qui a été développé dans le langage Asclel qui intègre un système de typage fort et ce qui permet de développer des chaines codes dans ce langage en tirant partie de cette notion de typage sûr. Notre approche reprend elle ces quatre niveaux de correction formelles et notamment la génération correcte à partir d'une spécification graphique dont voici un exemple. Il ne s'agit pas d'une opération industrielle mais de la recette du tiramisu un peu simplifiée et représentée avec notre formalisme de spécification. Ici on cherche à spécifier l'ordre qui doit être respecté entre les différentes tâches réalisées donc il y a un ordre parfois strict et donc séquentiel mais également plus lâche à certains endroits de la recette à certains moments comme dans la boîte pointillée la plus petite où l'on veut effectuer deux tâches dans n'importe quel ordre à noter aussi que chaque action réalisée va correspondre à une méthode du chaine code qui encodera cette procédure. Une fois cette spécification graphique réalisée il y a plusieurs étapes qui sont nécessaires avant d'obtenir un chaine code exécutable et exploitable sur la blockchain Hyperledger Fabrique et dans notre système de consortium industriel. On doit d'abord générer une spécification logique et une implémentation en YML qui est le langage dédié à l'outil Y3 que nous utilisons et cet outil de vérification déductive va nous permettre de prouver l'implémentation par rapport à la spécification générée. Là vous avez un exemple de la fonction moyenne où l'on a exprimé en plus de la fonction une pré-condition exprimée au niveau de requires qui doit être vrai lors de l'appel à cette fonction et une post-condition qui définit le résultat et ce qui doit être vrai à la sortie de cette fonction. Une fois cette présentation terminée d'ailleurs vous aurez la possibilité d'assister à un tutoriel que François vous a préparé et vous pourrez d'ailleurs expérimenter vous-même l'outil Y3 à cette occasion. À partir de notre implémentation prouvée l'outil Y3 permet d'extraire un code au camel correct par construction qui lui est exécutable. Il suffit alors de déployer ce code sous forme de chain code pour par exemple pouvoir l'utiliser avec le Chimo camel et ainsi interagir avec la blockchain Hyperledger Fabrique. Mais revenons maintenant plus en détail sur les étapes qui composent cette génération prouvée et on reprend donc par la première étape de spécification graphique d'une procédure et vous avez ici un exemple où on a spécifié de manière simplifiée le mécanisme de revue par les pairs qui donne lieu à la publication de papier scientifique. Donc tout d'abord on a l'appel à la publication qui est effectuée par le journal. La soumission du papier par le scientifique. Puis on a une première issue qui s'effectue et qui donne son accord pour la publication mais dans le cas présent une autre review qui s'effectue mais qui elle ne donne pas son aval et donc demande au scientifique de republier une nouvelle version de son papier et donc dans ce scénario les deux reviews suivantes sont correctes et acceptent la publication qui elle est effectuée par le journal. Ce formalisme comprend donc une notion de rendez-vous symbolisée par le symbole plus et une notion d'interruption symbolisée par ce symbole moins et sachant que la transition empruntée par l'action review dans cet exemple dépend des conditions exprimées sur les arguments de la méthode du chain code correspondante mais qui sont ici simplifiées par OK pour l'accord après la review ou KO pour il faut une nouvelle version du papier à soumettre. Donc on vient ensuite la génération de code à partir des contraintes exprimées dans cette spécification graphique et où l'on produit à la fois la spécification logique et l'implémentation dans le langage YML qui est donc le langage dédié à l'outil Y3 et on peut ainsi prouver l'implémentation par rapport à la spécification de manière automatique à l'aide de prouver donc dans notre cas Altergo, CVC4 et Z3 ce qui requiert bien évidemment de l'ingénierie de preuve d'une certaine expérience de l'outil cependant il n'est pas si facile d'exprimer toutes les propriétés possibles comme celle que l'on souhaiterait par exemple pouvoir exprimer en logique temporelle et donc là je vous parle de propriété que l'on voudrait exprimer car on peut souhaiter vouloir éprouver la spécification car l'implémentation sera prouvée par rapport à cette spécification elle peut être sujette à des défauts de conception donc sachant qu'il ne s'agit pas du squelette sachant qu'il ne s'agit dans le code généré donc le workflow que du squelette du Jane code donc à partir de la spécification graphique il est tout à fait possible d'ajouter aussi des fonctionnalités au niveau du code YML et également de spécifier ces fonctionnalités afin de prouver leur correction et donc on en vient à la dernière étape qui consiste à extraire automatiquement depuis YML un code au KML et donc dans le code YML il n'y a pas l'implémentation des fonctionnalités qui sont présentes dans le ChIM il faut donc faire un code à trou où on déclare simplement les fonctions qu'ils seront disponibles dans le ChIM en OCaml et on va donc pouvoir faire un mapping lors de cette étape d'extraction et maintenant je vais laisser la parole à François qui va vous présenter son travail sur le ChIM qu'il a réalisé en OCaml merci Julien donc le ChIM comme dans les autres cas pour les autres langages en fait il se place tout en bout de chaîne tout en haut on a l'ordreur comme c'est habituel on lui parle déjà de fabrique et il va choisir ce qui est du lait les transactions et ensuite les endorsers ils vont exécuter et pour ça Hypergear Fabrique a choisi de mettre les chain codes dans des images dockers ce qui permet d'utiliser de nombreux langages différents que ce soit Abo, Javascript, Java et donc à Askel qui avait déjà été présenté il y a les dernières et là donc avec OCaml c'est là on veut faire un peu la même chose et en fait le endorser communique avec le ChIM à base d'un protocole réseau assez classique alors la passion nous comme dans le cas de Askel pour l'instant on fait le cas où on est en mode développement c'est-à-dire en mode développement on peut faire en sorte quand on pouriter est un peu plus rapidement faire en sorte de mettre l' endorser en mode développement et ce sont là les ChIM peuvent directement se connecter à l' endorser de manière à pouvoir vite créer de nouvelles versions d'un chain code et tout de suite en reexécuter un recompiler et reexécuter c'est pas l' endorser qui génère qui compile le chain code dans l'image docker c'est quelque chose qu'on voudrait faire dans le futur on verra mais c'est encore un peu compliqué alors le ChIM en fait il se base la communication se base sur GRPC qui est un protocole assez commun et donc on a utilisé à Librariser qui est aussi utilisé dans les autres langages et au-dessus de cette Librariser on met un stub au camel qu'on a appelé GRPC qui permet de lier aux fonctionnalités du C et en fait tout le protocole est décrit les données, le format des données d'échange du protocole sont définies en protobuf au protobuf il y a un outil qui se fait de protoc et on peut ajouter des plugins donc ici c'est au camel protoc plugin pour à partir du protobuf générer du code qui décrit le protocole et de cette manière en fait on peut directement utiliser le protobuf qui est défini pour y parler de GRFabric si tu peux passer le protobuf protobuf fabric proto et directement à partir du camel protoc plugin on peut générer le protocole en au camel fabric protocole et avec celui-ci et de l'autre côté GRPC protoc plugin qui permet de lier ça au protocole à l'exécution réelle du protocole mais on peut plus facilement écrire une librairie qui s'appelle Fabric chain code shim et qui permet de décrire un chain code en au camel alors on voit là l'exemple d'un jouet d'un hello world on pourrait dire de chain code donc au départ on dit de ouvrir la librairie Fabric chain code shim qui permet d'accéder aux fonctionnalités on a une partie où on définit chaque méthode par exemple ici on a query où on va pouvoir récupérer avec un get state la valeur dans le ledger pour un argument donné de la valeur et ensuite on la renvoie directement parce que c'est vraiment un exemple de jouet on récupère et on renvoie et de l'autre côté on a un autre méthode qui permet de changer les valeurs à la commande put state et enfin on a la dernière partie, la troisième partie c'est un peu un code qu'on peut du boilerplate on peut récupérer directement peut-être qu'on pourrait le générer ou le automatiquement en tout cas là on peut voir qu'à chaque fois qu'on récupère qu'on a une nouvelle requête qui est faite ce qui est au niveau de 1 voc on récupère la fonction et les arguments on regarde quelle fonction nous a demandé donc query ou put et dans le cas on exécute la première fonction dans le cas de la deuxième fonction sinon on dit que la réponse est une erreur donc ça c'est rapide pour faire aussi du chaine code et c'est bien pour hyperlégion fabrique très pratique qu'ils aient fait en sorte de ne pas être liés à un seul langage de formation de la liberté donc il y a beaucoup de... ce travail n'aurait pas pu être possible si on n'avait pas eu le Askelschirm qui avait été défini parce que ça permettait d'avoir un shim un peu plus simple et qui permettait parce que certaines parties du protocole n'étaient pas bien définies c'est un peu de cette manière là qu'on peut le voir la définition la description de Protobuf est vraiment très pratique utiliser un format qui n'est pas lié qui n'est lié à aucun langage pour décrire un protocole ça fait gagner beaucoup de temps mais Protobuf décrit pas tout par exemple il y a dans certains cas on a certaines données pour lesquelles on a différents types de messages pour différents messages les données sont un peu différentes celles qui sont accessibles et ça c'est pas dit dans Protobuf beaucoup de choses sont implicites il suffit de lire un autre chaine pour avoir les réponses sur qu'est-ce qu'il faut utiliser et enfin dans ce qui est pas encore implémenté on a les étérateurs qui sont pas encore implémentés pour des queries un peu plus complexes sur les clés et on a aussi du parallélisme en tout cas gérer plusieurs requêtes en même temps qui sont pas complètement traités je peux vous montrer juste très rapidement un peu l'exécution qu'on peut avoir sur je vais prendre la main tout de suite après je te la rendrai juste après donc en fait c'était juste pour montrer un exemple c'est vrai que c'est juste un script mais ça va vraiment pas être très long mais en fait on a un premier script et ça c'est quelque chose qui était assez pratique utile à faire pour après qui nous permet de directement de charger le code de compilé tous les programmes qu'on a besoin comme l'orderer les pires ensuite de lancer un orderer puis de lancer un pire et il y a un peu il y a des temps on attend que chaque application est finie de travailler donc ça met 30 secondes mais si je saute directement au moment on arrive à ce moment-là en fait on arrive dans un bâche comme ça on s'est mis où on a déjà toutes les commandes qui ont été compilées qui sont accessibles par exemple la commande pire donc la commande pire c'est une commande qui permet d'exécuter d'envoyer une requête une transaction donc là on va créer la transaction query A pour demander query A et sur l'autre terminal qui est à droite là on voit le chain code au camel qu'on demande d'exécuter il se connait là vous pouvez voir en va droite à 127.001.7052 c'est sur ce port-là qui perd la chaufferie et donc quand il démarre il s'enregistre il attend et donc là il va attendre qu'on ait fait la requête de l'autre côté en bas à gauche donc on l'exécute et là quand on l'a exécuté la transaction a été reçue par le chain code donc on a le numéro d'identification de la transaction qui cite XID et ça a été exécuté on a renvoyé la réponse c'était 90 et on a à gauche bien 90 c'est un effet très simple comme c'est par contract mais là on peut en place modifier la valeur en A mettre la valeur 40 on réexécue d'autre côté on l'a bien reçu au niveau du chain code on a correctement traité et quand on redemande fin query avec A maintenant on a bien la valeur 40 vas-y je te laisse la main vous pouvez voir comme ça c'est quand même on a avec ce shimo camel ça nous permet de lier les résultats de l'extraction de WAI 3 ou Hyperledger Fabric de manière assez naturelle donc on vous a présenté dans un premier temps les étapes de notre génération certifiée de chain code Hyperledger Fabric qui implémentent des procédures mais dans notre cas du usage des opérations industrielles dans le cadre de la chaine claire et puis François vous a présenté un shim implémenté à nos camels et pour les perspectives possibles du côté de la génération certifiée on peut imaginer augmenter ajouter des nouvelles fonctionnalités au niveau de la représentation graphique mais qu'il faudra donc prendre en compte lors de la traduction lors de la génération de la spécification et de l'implementation et François a déjà évoqué les perspectives possibles pour augmenter les fonctionnalités qui sont possibles sur le shim au camel donc les requêtes riches sur les clés et également de pouvoir utiliser ce shim dans le mode normal et pas dans le mode développement c'est bien ça donc merci merci à vous de nous avoir écoutés et on reprendra avec plaisir à vos questions si vous en avez et donc juste après c'est en fait présenté juste un petit tutoriel sur faire de la preuve de c'est de smart contracts solidity en WAI 3 mais c'est pour vous montrer un peu comment fait utiliser WAI 3 et en fait vous pouvez le faire directement dans votre browser donc ce sera assez rien à installer si personne n'a de questions on peut être passé directement au tutoriel du coup que tu propose tout à fait juste après de la main sûrement hop et donc donc là vous voyez sur une page web là du projet rich donc projet rich est d'un projet européen fait pour aider des entreprises des startups à pouvoir utiliser des outils pour sécuriser pour avoir plus de confiance dans des données dans des services qui proposent des données donc c'est un projet européen qui est un peu spécial enfin c'est des projets européens où il y a les startups peuvent demander pour les entreprises en plus grand peuvent demander un financement donc il y a plusieurs fois au cours c'est un projet donc c'est 3-4 fois où les entreprises peuvent proposer un projet dire qu'est-ce qu'elles voudraient utiliser et à ce moment-là elles peuvent recevoir un peu d'argent pour avoir du temps pour essayer ces outils et aussi pour pouvoir discuter avec les gens qui font les outils pour plus facilement les utiliser il y a aussi l'accès à des grosses infrastructures de données le big data infrastructure donc en tout cas je vous conseille d'aller si vous êtes intéressés à ce dans ce projet riche alors j'ai oublié de vous mettre la hop ici donc là dans le dans le chat je vous ai mis le lien vers cette page et donc on va pas suivre le tutoriel pas à pas en fait je vous explique tout un peu plus directement mais donc pour pouvoir lancer y3 dans votre browser vous pouvez juste descendre jusqu'à avoir le lien t1 in try y3 et à ce moment-là ça vous laisse cette petite fenêtre là ou à gauche vous avez le code et à droite vous aurez les obligations de preuves c'est-à-dire c'est les formules mathématiques qui doivent être prouvées pour que le code suisse la spécification et n'a pas de problèmes à l'exécution juste une chose à faire donc par défaut ici c'est à 100 il faut le mettre à 1000 ici dans défaut 7 limites ceci est juste le nombre de pas de preuves que le prouver qui s'appelle altergo et qui est directement minici aussi en JavaScript tout ça en fait ça exécute vraiment de votre browser en local c'est tout en JavaScript et donc là dans ce code on a une certaine nombre de théories, de modules qui définissent la modélisation qu'on a fait de solidity par exemple là on a les entiers 8 256 de solidity qui sont instancés ici on a les adresses qui sont à zéro que solidity utilise que le VM en fait utilise on a la définition de ce que peut être un message donc là c'est vraiment très simple très simplifié on a juste le sender dans les messages on obtient juste qu'il est envoyé c'est juste que c'est pas le défaut les mapping où il y a toujours énormément de mapping dans solidity souvent de adresses vers d'autres valeurs beaucoup d'autres choses et donc là tout en bas on a vraiment le code qu'on veut utiliser en fait tout ce qui est au-dessus qui fait en fait la laissant 25 lignes sont réutilisables pour différents si on veut prouver différents smart contracts en effet le smart contract il n'est pas écrit en solidity ce qu'on peut faire c'est l'extraire pas dans cette interface là mais on peut l'extraire vers du solidity et l'extraire en CAMEL l'avantage c'est qu'on a un langage qui est fait pour faire de la preuve solidity n'est pas complètement fait pour même s'il y a quelques features qui le permettent et une fois qu'on a ça on peut voir un tout petit code qui lui veut juste avoir transféré au niveau de la balance entre deux personnes c'est le sender qui peut transférer de l'argent vers un receiver qui est donné en argument un nombre de tokens et la balance d'argent est représentée ici au niveau de ce mapping qui s'appelle Balenti donc le code on pourrait dire qu'il nous paraît simple à écrire on va déjà faire que le sender on va lui enlever le nombre de tokens et le receiver on va lui ajouter le nombre de tokens et si on lance en fait ça nous dit que ça n'arrive pas à le prouver ça n'arrive pas à prouver ça fait une grosse formule mathématique mais simplement en gardant dans l'interface dans l'interface des stocks on peut aussi accéder à des contre-exemples là on n'a pas l'opportunité mais en fait ici ça nous dit on a un problème on a un integral overflow possiblement un integral overflow c'est pas sûr mais il nous dit je n'arrive pas à prouver qu'il n'y en a pas là on peut regarder et là on voit qu'en effet quand on fait la soustraction de nos tokens il est bien possible qu'on arrive en dessous de zéro alors comme c'est des huines de 256 en fait il y a une sémantique dans solidity où c'est du VRA peut rendre donc ça devrait nous donner quelque chose c'est une valeur très grande cependant on a préféré choisir que c'est pas on voulait une sémantique un peu plus strict que ça donc il est quand même valide avec la manière dont s'exécute solidity mais on dit que c'est une erreur de passer d'essayer d'obtenir valeur de faire d'utiliser ce modulo le fait que ça sera VRA par contre et donc là ce qu'il faut faire il faut essayer il va falloir s'empêcher le fait de faire ce calcul lorsqu'on est possible de passer à quelque chose de négatif alors en fait on a remis un peu la même chose que le récroyeur qui avait solidity parce qu'il faut vraiment que ça fasse une erreur mais une erreur un peu qui est directement traité donc là on pourrait dire notre ténos Tokyo et ça on peut le tester en vérifiant que la balance du sender si vous avez des questions vraiment faut pas hésiter à les poser quand vous voulez je sais pas si vos micros sont accessibles mais si c'est pas le cas vous pouvez le faire et donc ça serait pardon vas-y les micros sont accessibles voilà et donc là on peut donc pas un s à requerre on aussi peut-être il y a encore une santé accélérée mais c'est peut-être qu'est-ce que je l'ai c'est pas les appostres plutôt je revois qu'est-ce que j'ai mis déjà c'était riche hop je vais revoir mon antisèche comme ça c'est juste d'accord c'est juste j'ai inversé les deux arguments ok hop hop hop voilà et donc là il dit cette expression elle renvoie des exceptions qui sont pas enregistrées parce qu'en effet cette exception cette fonction en fait ça arrête le flow du programme c'est ça fait comme un ça fait en fait reset en cas de le VM c'est ça aborte ça annule la transaction mais ça on a voulu le rendre assez clair parce qu'en fait on sait pas forcément il peut avoir un appel très bas qui va annuler l'exécution et donc ce qu'on a voulu faire c'était réutiliser le système d'exception de Y3 ça va vraiment écrire alors ça fait un tout petit peu de rondondance mais on verra dans un autre cas où cette redondance est utile ou ici on va dire que pre-quayer-fail à n'arrivera n'arrivera que si la balance est plus petite que le nombre de tokens je vais faire comme ça en reprenant celui-là qu'est-ce que j'ai tapé il l'a accepté je sais pas qu'est-ce que j'avais fait demain peut-être un copier collé de la flèche là le monde c'est peut-être le supérieur qu'il y a un unicode qui serait différent c'est à l'heure de ouin ici un espace en tout cas il y a à peu près exactement ce que j'avais pu écrire avant et là quand on lance on voit que ça nous dit il y a bien j'ai pu prouver qu'ici il n'y a pas d'integra overflow et que le re-quayer-fail qui est là en fait on arrête la transaction que dans ce cas-là que dans le cas où la balance est plus petite que le nombre de tokens on peut voir que le re-quayer c'est en fait l'opposé puisque là en fait on voulait que ça soit un fer régal et la balance donc là on a bien la négation alors pourquoi est-ce que là on n'arrive pas encore à prouver le dernier cas qui est celui-ci celui et en fait c'est sûr que celui-là on y pense souvent en fait quand il y a un tutoriel le premier tutoriel de Solidity il y a eu plusieurs versions parce que les gens ont corrigé à chaque fois ces petits vrais mais là celui-ci il est resté assez longtemps parce qu'en fait là aussi on peut avoir c'est si la balance le receiver a trop de tokens plus rarement mais ça peut arriver et donc à ce moment-là on va en effet vouloir demander à vérifier que le on voudrait peut-être vérifier que ceci est plus petit que le maximum de tokens possible alors le maximum de tokens possible c'est ça je ne me trompe pas c'est une donc on pourrait écrire quelque chose peut-être comme ça est-ce que quelqu'un voit si quel problème on pourra avoir dans ce cas-là est-ce que ici là ça devrait le prouver ou pas il me redisse il n'aime pas quand j'écris des choses quand je copicole les choses je vais refaire je vais récupérer encore le suivant quand je copicole tout parce que copicole ne marche pas là j'ai remis ce que j'avais mis avant et donc là quand on lance ça nous dit que celui-ci est bon mais celui-là quand on a fait le calcul il a dit il y a le même overflow possible donc on ne peut pas tester de cette manière-là qu'on n'est pas trop grand en fait il faut le passer de l'autre côté il faut faire la subtraction et c'est vrai que c'est tout de suite ça devient compliqué parce que même pour faire les tests pour tester qu'on est dans les bonnes qu'on fait les choses correctement il faut le faire attention parce que c'est aussi assez difficile mais là c'est bon maintenant on a tout qui a été prouvé si on peut voir que dans ce que j'ai récupéré on a dû rajouter ici que une autre raison pour laquelle on pouvait arrêter la transaction c'était que la balance plus le nombre de tokens n'était plus grand qu'une 256 max et là on a le droit de faire l'addition parce que ici c'est des calculs qui sont mathématiques on a toutes les entiers de taille arbitraire alors qu'ici on avait le droit aux entiers une 256 et donc là c'est un avantage c'est comment on peut faire exactement ce qu'on voulait et ne pas devoir faire une certaine gymnastique intellectuelle pour remettre les tests un peu à l'endroit donc là on peut voir qu'elle est quand même l'intérêt d'avoir ses specs aussi à cet endroit donc là on arrive à là et on a pu prouver au moins que l'exécution se passait correctement et qu'on n'a pas de integer overflow pour pouvoir voir un peu quels sont les cas de recette en fait on peut aller encore plus loin parce que ce qu'on pourrait vouloir prouver c'est que le la balance qui est ici en fait on fait bien un transfert c'est-à-dire qu'on n'a pas perdu des tokens ou on n'a pas recuper on n'a pas créé des tokens parce que ici on aurait pu enlever cette ligne là et comme ça on aurait créé des tokens avec cette fonction-là et c'est quelque chose que on n'a pas forcé qui serait une erreur enfin on a eu des attaques comme le DAO ou c'était un peu ça ou d'un coup on avait trop d'argent qui était un peu d'une fonction qui prenait plus d'argent que ce qu'elle aurait dû faire ou ça devait juste un transfert donc là bon j'ai collé puisqu'il est déjà directement un peu la collection vous pouvez voir là sur cette page là et donc une manière de faire c'est de simplement dire que dans notre environnement le type T qui représente toutes les champs de la classe de solidity ici en fait on avait un nombre initial de tokens et ce qu'on demande c'est un invariant et cet invariant puisqu'on le met ici au niveau de T cet invariant c'est que la somme de la balance la somme a été définie ici forcément facile on peut le faire une fois doit toujours être égal à la valeur initiale on doit montrer que cet invariant est au moins vérifié par une par intitée initiale par exemple pour une valeur qui existe et donc si on dit que on a toujours zéro et on initialise avec cette map qui a toujours qui vaut zéro partout à ce moment là en effet cette partie là sera réussie et juste en faisant ça en fait là ça nous a rajouté dans les vcs ici un type invariant qui si on regarde ce qu'il essaie de nous prouver c'est d'essayer de nous prouver que la somme à la fin d'exécution est bien toujours égal à la somme initiale et donc ça nous fait que toutes les fonctions qu'on pourrait écrire et donc cette transfert là ne vont pas créer ou perdre des tokens que ça a bien été transféré et qu'on n'a pas eu de création de tokens et comme ça prouver tous les on voit que tout est vert voilà est-ce que vous avez des questions avec Y3 vous pouvez voir il y a plein d'autres exemples sur le site de Y3 c'était plutôt des exemples parce que Y3 utilise plein de choses pour faire la preuve de C, la preuve de Hada la preuve de Java aussi pour le C le Hada dans ce cas là on part du C et du Hada et on génère soit des formules logiques soit du code comme ça Y3 ici l'exemple est plus un exemple pour des smart contracts mais sur le site de Y3 il y a plein d'autres exemples avec plein d'autres algorithmes différents et on voit la puissance de l'outil c'est vrai que là du coup c'était le cas d'un code solidity parce que du tout il était prêt comme ça mais ça marcherait un peu de la même manière pour Hyperledger en fait on a eu notamment pour implémenter le shim à spécifier en fait les primitives d'interaction avec la blockchain Hyperledger le fameux get state et put state dont on parlait tout à l'heure d'ailleurs peut-être quand on parlait un petit peu c'était une spécificité d'Hyperledger dont on avait parlé en soi oui c'était en fait en Hyperledger il y a quelque chose qu'on avait remarqué c'était le comme il y a ce exécut il est en ordre exécut c'est le contraire des autres blockchain à ce moment-là en fait quand on fait des get state on a fait un put state avant en fait on n'obtient pas la valeur qu'on a dans le put state ça c'est sans doute pour optimiser c'est un choix technique qui a été fait mais c'est là où la preuve peut être assez intéressante parce que c'est quelque chose qui n'est pas forcément naturel et dans notre modélisation on a bien fait en sorte que quand on fait un get state on obtient toujours la valeur du début la valeur mi-à-jour au niveau du put state et donc comme ça si on veut prouver une propriété fonctionnelle comme on a le pu faire là avec par exemple les tokens de transfert bah ça va vraiment vérifier avec la sémantise actuelle et pouvoir éviter ce genre de problème j'avais juste une petite question dans les préférences au départ quand tu as mille default stops de 100 à 1000 pour augmenter c'est simplement parce que en fait c'est le nombre d'étapes de preuves et simplement il y a certaines preuves il y a la dernière preuve je crois qu'il y a besoin d'un peu plus de pas de preuves et en fait l'outil le solveur qui est derrière Altergo en fait s'arrête au bout de 100 pas de preuves et va dire bah désolé j'arrive pas à le prouver mais en fait quand on lui a dit vas-y il y a 900 pas de preuves en plus il arrive à faire la preuve il peut le prouver donc en fait si on a limité le nombre de pas de preuves là c'est pour pas surcharger c'est comme exécuter en JavaScript même si les jits sont impressionnants oui c'est comme d'accord ok merci c'est vrai que là tout se passait relativement bien dans les cas où on a des propriétés un petit peu plus compliquées plus complexes à prouver mais c'est pas toujours aussi automatique il suffit pas toujours d'augmenter le temps le temps va bien oui nous on se limite quand on marche moi je me limite à 5 secondes pour lancer pour chaque prouver si souvent les choses sont pas prouver en 5 secondes soit on peut les aider avec des assertions en plus on découpe la preuve en plus petit bout soit parfois ça peut vouloir dire que c'est pas probable si on a des contre-exemples ça pourra nous indiquer pourquoi en effet c'est pas probable nous montrer un exemple d'exécution qui en effet ne vérifie pas la propriété qu'on va prouver et c'est là où parfois ça demande un peu plus d'expérience parce que voilà quand il y a quelque chose qui n'est pas prouvé pourquoi est-ce qu'il n'est pas prouvé savoir quel est un variant à rajouter ça demande quand même un peu mais les outils qui est avec de l'interprétation d'abstrait qui on commence à avoir ça peut nous aider à s'implifier au maximum ça c'est tout le travail d'ingénierie de preuves dont je viens parler tout à l'heure dans sa présentation qui parfois est un peu erdu et technique autre question je vous mets aussi le lien pour ceux qui veulent je vais mettre le lien pour le pour le projet Rich si ça peut intéresser des gens parce qu'il y a un appel qui doit je crois qu'il y a un appel qui va bientôt avoir lieu pour les open calls et donc voilà c'est plutôt pour les start-up et les SMM donc voilà c'est le 4ème trimestre 2022 Bonjour est-ce que le cas d'être en open source oui donc c'est vrai qu'on aurait pu mettre les liens donc il est celui du shim et dans niveau de sur github dans le groupe de hyperlegger lab je crois je sais pas comment ça s'appelle ouais c'est les hyperlegger labs effectivement j'ai enmis le lien dans le chat et pour WAI 3 aussi c'est open source au WAI 3 on peut l'installer assez facilement avec opam il existe aussi je crois sur des biens peut-être le shim n'est pas encore complètement trivial à installer mais bon on a toutes les instructions et s'il y a n'importe quel problème faut pas hésiter de mettre une issue pour éluurer l'installation jusqu'à la fin de l'année et voilà pour essayer de faire en sorte que ce soit le plus transparent possible pour les utilisateurs ce qui n'est pas open source c'est tout ce qui vient avant tout ce qui a présenté julien qui permet de générer du code à partir d'une spécification graphique ça c'est pas open source il y a des publications derrière je l'imagine pas encore pour cette partie pour WAI 3 sur le site WAI 3 il y a beaucoup de de listes de papier pour le c'est beaucoup moi je vais vous laisser c'était très instructif à bientôt merci au revoir je pense qu'on va pouvoir fermer vous voyez c'est beaucoup la présentation c'était vraiment super je pense que la question s'est finie et donc on remet ça encore on remet ça le 18 novembre puis là le invité des collègues le 18 novembre en anglais du coup super on a donc merci beaucoup à tous donc à la prochaine et bonne journée à tous merci au revoir