Pas besoin de machine virtuelle pour le P2SH 
1 Like
salut @nanocryk
j’ai regardé quelques videos de presentation de P2SH et comment implementer le bouzin pour le developpeur de tels scripts, sans rentrer dans les details des opcodes,
il s’agit bien d’implementer ce qui fait le fonctionnement d’un processeur actuel pour lire et executer du code, une stack, etc…etc… qui serait executé par duniter
c’est pourquoi
P2SH ==> language de programmation qu’un logiciel client permet d’ecrire
et il faut une machine virtuelle pour l’interpreter coté duniter
Je ne pense pas. Le langage de script de Bitcoin est non Turing-complet. Il faudrait donc simplement construire un arbre des OPCODES, puis interpréter chaque feuilles et faire remonter les résultats. Tu peux le faire directement avec un AST (Abstract Syntaxic Tree) sans avoir besoin d’implémenter une machine virtuelle avec stack, etc.
Tu aurais besoin d’une machine virtuelle comme l’EVM si justement tu veux proposer un langage Turing-complet avec une stack. Mais là il faut gérer plein d’autres problèmes, définir un système de gaz, etc; qui ne correspondrais pas avec les transactions gratuites de Duniter.
L’idée du P2SH est de ne mettre que le hash du script en condition d’utilisation, et de publier le script quand on veut s’en servir. Le niveau au dessus c’est les MAST (Merklised Abstract Syntaxic Tree) qui eux permettrait de publier uniquement la branche qu’on a utilisé sans publier la totalité du script. Il est prévu d’être intégré à Bitcoin dans le futur.
2 Likes
garantie 100% qu’ils utilisent une stack ne serait ce que pour expliquer comment coté “bitcoin” c’est interpreter
check les videos sur nenette
apres quoi, on utilise la structure de donnée que l’on souhaite si on veut l’implementer différement 
Côté bitcoin c’est une stack oui, mais ce n’est pas turing complet (donc pas de machine virtuelle).
2 Likes
Il me semble par contre qu’actuellement Duniter ne fonctionne pas avec une stack, non ?
Après si on compte proposer le P2SH dans la version 2.0, autant le faire propre et le gérer avec une stack.
D’ailleurs actuellement comment sont stockés les scripts dans les documents de transactions ? Est-ce que c’est sous format texte, ou une représentation binaire ?
Oui, mais dans le fichier c’est stocké sous forme textuel, ou en binaire avec chaque OPCODE ayant un ID ?
C’est du texte, la condition est stockée telle quelle.
Avec l’ajout du P2SH ça ne serait pas une bonne idée de passer en binaire, ne serais-ce que pour gagner (beaucoup) de place ?
On peut tout à fait passer le stockage en binaire, ça ne nécessite pas de modifier le protocole.
1 Like
Ca dépends si c’est juste pour le stockage ou au niveau du réseau. Mais vu que les documents ne sont composés que de texte ça ne serait pas pratique de mélanger les 2.
Tu peux tout aussi bien transformer les documents pour la transmission, c’est pareil.
Il vaut vraiment mieux ne toucher au protocole que pour des raisons très valables, car de sa stabilité découle la stabilité de tout le reste … les développeurs de Sakia / Cesium le savent (très) bien.
2 Likes
Je vous met de la lecture sur les Smart contract “stateless” aussi appelé “simple contract” qui ne nécessitent pas de VM …
C’est ce que font les gars de BigchainDB (très prometteur) à base de OPCODES :
1 Like
Intéressant Pour info, dans Duniter, c’est du Stateless.
Très intéressant. Il faudrait essayer de développer un peu plus les opcodes pour permettre le développement de smart contracts stateless.
Ola,
Toujours dans le prototypage,
le module qui commence a prendre forme 
une v1 perfectible et du coup une v2 à l’étude
6 Likes
Tu seras pret pour les RML11 ? 