Work in progress Transaction / Module

Yop,

non, pas avec le smart contract

je vais commencer par définir ce que j’entends par “smart contract”

Pour moi, c’est l’utilisation d’une source soumise a des conditions.
de maniere simple, utiliser un operateur [et, ou] c’est definir un smart contract.

De la, c’est destiné a celui qui sait se débrouiller a minima pour composer un tel document


pour eviter toute confusion, oui je fais bien référence aux opcodes existants SIG,XHX et les operateurs… qui ne me permettent pas de deverrouiller des sources.
pas encore de la creation de nouveau opcodes / operateurs. (ca va peut etre venir…)


A ce titre, j’ai vaguement survoler comment ils definissent “smart contract” dans ethereum,
puis j’ai regardé P2SH dans bitcoin

l’un dans l’autre, cela nécessite d’implementer une machine virtuelle.


Dans ethereum, ce sont les devs qui ecrivent un bout de code et ce code est inscrit dans la blockchain,

j’ai pas encore trouver les infos expliquant , quand comment, tout ca c’est gérer
a quel moment ce code s’execute, par qui…
et a premiere vue ca me semble délicat.
Sachant qu’un “contrat” peut en appeler un autre, qu’il y a egalement une limite du nombre d’appel de fonction,
et que enfin de compte, il est possible d’arriver a ce qu’un contrat n’execute pas l’ensemble de ses instructions dans ce cas où il y a une succession d’appel d’autre fonction appartenant a d’autre contrat…


Coté P2SH

si je considere que en l’etat aujourd’hui dans duniter, je dispose des opcodes SIG , etc…les operateurs et/ou

les seuls operateurs manquant
ce serait eventuellement des operateurs de comparaison, >, >= , <, <= , == , !=

j’ai vu tourner un document qui date de 2014 sur le bitcoin
99,9% des transactions sont "simple signature"
je ne sais pas ce qu’il en est aujourd’hui

C’est pour en venir au fait que , oui, implementer une machine virtuelle dans duniter,
je trouve cela techniquement parlant interessant,
cela ne “me” semble pas pour autant etre une priorité
dans la mesure où
on peut déjà proposer des contrats intéressants avec ce dont on dispose,
commencer par s’assurer que tout cela soit bien en place


a l’ecriture de ce post,
je vous propose 1 opcode :
NOTSIG => en parametre une clé publique dont la signature est exclue du document de transaction, exemple : NOTSIG(7t38…)
:rofl:

Ça sera corrigé dans la 1.6 officielle.

Exactement.

Mais d’ailleurs il n’était pas dans mon intention que Duniter soit une machine à tout faire, mais juste une machine à gérer de la monnaie libre. J’ai quand même pris compte de certains développements de Bitcoin concernant les transactions crosschain (permettre réaliser un change de monnaie automatique et sans tiers de confiance) et les lightning networks (permettre des paiements instatanés hors blockchain), qui ouvrent un champ des possibles considérable et à très court terme.

Mais on reste dans l’utilisation de monnaie. Je ne souhaite pas que Duniter fasse autre chose, toutefois désormais mon avis pèse moins lourd qu’avant, je ne suis plus le seul développeur sur le projet, et donc libre aux futurs contributeurs de changer cet état de fait :slight_smile:

Pas besoin de machine virtuelle pour le P2SH :wink:

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 :slight_smile:

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 ?

Duniter fonctionne avec une grammaire BNF lisible par une machine.

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 :slight_smile: 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 :slight_smile:
une v1 perfectible et du coup une v2 à l’étude


6 Likes

Tu seras pret pour les RML11 ? :wink: