J’ai eu une idée en réfléchissant aux usages du système de script pour faire des contrats intelligents.
On pourrait permettre d’avoir plus d’une valeur sur la pile après exécution du script, la tête déterminant toujours si la transaction étant autorisée ou non. Les autres valeurs pourraient être utilisées et “injectées” dans les scripts des outputs avec un opcode spécial.
Par exemple, on pourrait suivant une valeur dans l’unlock script définir la somme de chaque output, ou passer une valeur à l’un des lock script des outputs qui pourra l’utiliser à son tour.
L’utilisation principale que je vois c’est des contrats intelligents qui peuvent s’effectuer en plusieurs étapes et qui peuvent en quelque sort “stocker des valeurs”, sans pour autant être Turing-complet comme dans Ethereum, et qui pourraient difficilement être gérés via des canaux de paiements car il nécessiterai trop de signatures.
Je vais essayer de concevoir un petit exemple de ce qu’on pourrait faire avec, mais j’aimerais déjà avoir votre avis sur le concept.
Après, je pense qu’il faut se concentrer sur un protocole V11 accessible en terme de développement. Cette évolution n’implique pas de fork violent, par contre elle implique beaucoup de tests pour vérifier le comportement.
Je serais d’avis de clore les fonctionnalités en terme de transactions sur la V11 pour cadrer un peu la charge de développement et avoir quelque chose qui pourra sortir un jour ! Elle sont déja suffisamment (et extraordinairement) complètes
Ca n’empêche pas de prévoir une telle fonction pour le protocole V12. Mais il faut savoir limiter ce qu’on fait à chaque incrément de développement… Il suffit de voir la 1.6, pour quelques changement mineurs, elle prends du temps à sortir… Un réseau décentralisé c’est complexe !
Donc je pense qu’il faudrait être raisonnable et faire “le juste minimum” qui permette de répondre aux objectifs de la V11 :
Développer un protocole plus robuste et évolutif
Qui règle les défauts détectés après plus d’1 an d’utilisation de la V10 :
PoW
Vérifications des clients légers
…
Si le protocole V11 répond bien à ses objectifs, développer le protocole V12 devrait être relativement simplifié !
Il faut surtout déterminer comme ça peut être intégré au système.
Si c’est intégrable en soft-fork, on peut attendre.
On peut en modifiant peu le protocole permettre un ajout ultérieur en soft-fork.
On l’ajoute directement dans le gros hard-fork v11.
Déjà il faut que je modifie le protocole actuel pour autoriser plus d’une valeur sur la stack après exécution. Je pensais a premier abord que c’était un vecteur d’attaque mais après réflexion il ne me semble pas qu’on puisse exploiter ça. Avec ça il me semble possible d’ajouter cette fonctionnalité avec un nouvel opcode (récupérer telle donnée) et sûrement l’utilisation du champ d’extension.
De manière générale il faut que le nouveau protocole v11 nous ouvre beaucoup de porte et en ferme le moins possible.
Tu veux dire que une étape n’est pas Turing-complète, ou que le tout le système ne l’est pas. Si c’est le deuxième cas, c’est super dur de ne pas l’être. Une machine de Minsky à deux compteurs suffit. Counter machine - Wikipedia
Non, car le langage de script ne possède ni boucle ni saut.
Je viens de me rendre compte qu’il est possible actuellement d’appeller des MAST de manière récursive en passant le hash du script et le script en paramètre, ce qui rend le langage Turing-Complet. Je vais modifier l’opcode MastEval pour qu’il prenne le hash du script dans les 32 bytes suivants et non dans la pile.
A part ce détail je ne vois pas ce qui pourrait le rendre Turing-complet, mais si tu vois quelque chose n’hésite pas.
Je remonte ce sujet au vue des différentes avancées.
Avec le nouveau système le langage n’est apparement pas Turing-complet mais beaucoup plus puissance qu’un langage Bitcoin-like, et permet directement le transfert d’informations d’un token à l’autre (UTXO ou autre).
