Bonjour,
j’aimerais vous soumettre une idée et solliciter votre aide.
Mon projet de fin d’études consiste à concevoir une tokenomie et d’aller aussi loin que possible dans son développement.
Il s’agit, à partir d’un token appelé Zest, d’implémenter toute une toute économie de biens culturels pensés comme biens communs sur une plateforme technique (ZEST) dédiée.
J’ai élu la crypto-monnaie Ğ1 comme la première crypto-monnaie collatéralisable contre ce Zest (cf. Pourquoi la Ğ1 ? plus loin)
Le principe de collatéralisation est simple : chaque possesseur de Ğ1 et membre de la toile de confiance Duniter désirant participer à l’ écosystème ZEST engage un certain nombre de Ğ1 contre des Zests. Après quoi, les applications (Dapps) tournent sur une blockchain à part.
Il s’agit donc d « envoyer » des Ğ1 de la blockchain Duniter à une autre (et de pouvoir, bien sûr, les restituer à leur propriétaire, une fois effectué certains traitements)
Evidemment, ceux-ci ne peuvent pas être physiquement transportés et déplacés… Mais « envoyer » peut être compris comme la vérification que chaque blohchain a enregistré de manière fiable le crypo-actif que l’on a envoyé d’un bout d’une chaîne et reçu de l’autre.
C’est une problématique d’interconnexion de chaîne de blocs (entre la lockchain A (Ğ1) et B (Zest) dans notre cas).
J’ai une piste : le protocole IBC (mise en oeuvre notamment par Cosmos) qui exploite la propriété d’instant finality property du consensus Tendermint.
Je voudrais savoir :
a) si vous avez déjà rencontré une telle problématique d’interconnexion de votre blockchain à une autre
b) si un tel développement est possible dans l’état actuel de la publication des sources, si il existe une plateforme de test pour de tels développements consistant à gros à swapper des Ğ1 en Zests puis de les retourner.
c) si ce type de développement vous intéresse (ne serait-ce qu’à titre de PoC)
d) Si vous êtes prêts à m’aider par vos propres astuces, idées, outils*.
Merci infiniment,
Pascal Duval
j’ai commencé à lire
1 Présentation générale et philosophie du projet
2 Installation des outils
3 Récupération du code source
4 Démarrage
5 Architecture de Duniter
6 Éléments de code
7 La base de données
8 Les addons C/C++
Rem : 5 est un lien brisé et 8 n’est pas encore rédigé
Pourquoi la Ğ1 ?
Parce son code monétaire, sa conception fondamentalement démocratique et non-spéculatif est congruent à notre projet. La TRM sur laquelle elle repose évite l’écueil dit de la symétrie spatiale et temporelle. Elle estconçue comme un pas vers le post-capitalisme. Affranchi de la monnaie dette, tout détenteur de Ğ1 n’a rien à gagner à essayer de rembourser des dettes qui n’existent pas. Chaque membre collabore à la création d’un dividende universel égal pour tous assurant l’équité de chaque membre et garantissant du même coup aussi cet ethos positif éloigné de la peur de manquer et du réflexe thésaurisant-bancaire.
Parce qu’elle repose sur une communauté significative (près de 2500 membres en janvier 2020) qui est mobilisable.
Parce que chaque membre de la toile de confiance est identifié comme un individu avec
une clé publique unique. Il suffit en quelque sorte de translater les adresses publiques pour
conserver toutes les vertus de cette bijection entre la personne physique et son compte : un
membre Ğ1 = Une adresse publique g = Un membre de ZEST = Une adresse publique z = une
personne réelle.
a) si vous avez déjà rencontré une telle problématique d’interconnexion de votre blockchain à une autre
Le swap inter-blockchains n’a pas encore été implémenté sur G1, vous seriez le premier à le faire. Pour autant, c’est prévu. Je me souviens vaguement que @vit l’aurait fait avec la monnaie de test ?
b) si un tel développement est possible dans l’état actuel de la publication des sources, si il existe une plateforme de test pour de tels développements consistant à gros à swapper des Ğ1 en Zests puis de les retourner.
Je ne suis pas certain de votre besoin, donc je vous laisse lire les fils que j’ai pointé ci-dessous pour juger par vous-même si le protocole actuel permet le swap.
sur la référence au temps dans le doc de transaction. Actuellement par block hash, cela entraîne des transactions potentiellement invalides lors de forks. Dans l’avenir, la datation d’une tx se ferait par timestamp libre ou block number, et la référence valide pour les conditions CSV() serait l’inscription en blockchain. Je ne suis pas sûr que ce soit pour Duniter v1.9 ou pour plus tard.
Je pense que @elois pourra infirmer si je dis des bêtises.
c) si ce type de développement vous intéresse (ne serait-ce qu’à titre de PoC)
Une PoC, c’est bien pour montrer que ça marche mais ce n’est que mon avis.
d) Si vous êtes prêts à m’aider par vos propres astuces, idées, outils.
Nous avons des outils divers déjà disponibles, mais sans doute mal référencés. Je pense qu’on saura vous pointer l’outil adapté si vous rencontrez une question particulière.
Difficile de répondre quoi que ce soit pour moi, car il faudrait déjà indiquer ce qu’est le Zest, et pourquoi tu le nommes « token ». S’agit-il d’une autre crypto monnaie ? D’une plateforme ? Blockchain ?
Est-elle libre ? Sont code aussi ?
Développer « tout une économie » pour de faux, ou réellement ?
Tour cela ne me paraît très clair.
Il est dores et déjà possible de faire des virements inter blockchain avec la Ğ1, car il y a ce qu’il faut dans Duniter ( XHX(SHA256_HASH)) .
Par contre, rien n’est implémenté encore dans les clients.
J’ai réfléchi à une implémentation pour Sakia que j’essaierai de mettre en place en début d’année prochaine.
Merci beaucoup !
Cela permettra-t-il à terme de faire des swaps entre de la Ĝ1 et n’importe quelle token ou crypto-actif sur une autre blockchain ?
Et au niveau wallet, rien n’est envisagé avec metamask par exemple ?
Pascal
Oui, on pourra faire du atomic swap comme expliqué avec un schéma dans le second lien. Donc fonctionne avec toutes les cryptos qui supporte l’atomic swap.
Non. Je ne connais pas. Mais tu peux créer un nouveau sujet pour nous expliquer le principe, ainsi que les avantages et les inconvénients, à développer un metamask wallet, selon toi. Peut-être que cela intéressera les développeurs de clients.
Je croyais que cela ne pouvait fonctionner qu’avec les crypto-actifs pour lesquels on peut écrire un smart contract.
Donc blockchain ethereum, non ?
Et tout se ferait via le client sakia ?
Ben non plus. Pourquoi ? Cesium ou Silkaj ou un autre lient peut aussi implémenter l’atomic swap si besoin. Cela dépend du besoin des utilisateurs et de l’envie et la compétence du développeur du client.
Je trouve cela passionnant et te félicite pour ce projet.
Donc courant de l’année prochaine dis-tu ?
Tu as un petit road-map que j’ai une idée et puisse suivre ?
J’aimerais être associé. Je ne suis pas un pro de l’informatique comme toi mais je crois en la G1 et j’ai un projet de tokenisation en quelque sorte de celle-ci (très peu spéculatif je te rassure).
Donc ça veut dire, si je te suis, que si je développe un token sur une blockchain x (disons ethereum ou pas), je peux m’interfacer avec tes développements pour effectuer un swap.
Là où je ne comprends pas c’est que deviennent les G1 convertis ; ils sont bloqués ?
Par quel mécanisme ? Car Ils ne peuvent être « brûlés » n’est-ce pas ? Ce serait contraire à son code monétaire (ou alors je n’ai rien compris).
Ce qui manque (pardon) à des gens comme moi ce sont des spécifications, des cas d’usages et une documentation en langue du béotien ou du moins de l’amateur éclairé.
Mais vraiment, vraiment félicitations.
Et encore une fois, permets-moi de bien comprendre.
Im thinking that any atomic swap between g1 and another, whether started on g1 or another, will not result in destruction of either of the tokens, they’ll just end up in the counterparty’s wallet if all goes well… or be reclaimed in a timely manner (at originating end) by the one who starts the atomic swap… or perhaps in the wrong wallet if not all goes well and originator does not reclaim in time.
by the way: I have no clue of roadmap, but Id imagine it will happen after demand has demanded it. donc: Au boulot! (je vous soutiens)
Thanks for helping me to come to my point.
Actually I’m not looking for an Atomic Cross-Chain Solution.
ACCS enable secure cross-chain exchanges, e.g. using hashed timelock contracts(HTLCs). At present,they are the only mechanism to do this without necessitating trust. Unfortunately, they require several strong assumptions to maintain security, thus limiting their practicality: they are interactive, requiring all parties to be online and actively monitor all involved blockchains during execution.
I’m more looking for a cross-chain exchange using cryptocurrency-backed assets.
For example Ĝ1 to X (my own crypto).
Any hint ?
Thank you.
I’ve set a goal for myself to have something useful by mid January 2021, in the way of english documentation supported by code as a way to attract anglophone devs and introduce them to basic G1 concepts. Currently Im working on the web of trust, but next I’ll be working on advanced transactions which will include at least a multi-sig tx and 3 atomic swap examples (between g1 and g1… but still enough to prove the point) one that goes well between 2 good actors, the next which doesnt go well but gets claimed in time by the good actor, and the last which ends badly for the sleepy good actor who loses their coins to the bad actor.
When I have an example ready in git.duniter.org/spencer/learn-g1, Ill get in touch with you to let you know. I do not have any plans… yet… to doing so in a production manner with slick ui/ux so that every g1 user could easily participate in swaps.
Spencer971
P.S. I dont know about how to do trustless swaps which do NOT require both parties to monitor the activity of their counterparty.
Thanks for the pointer. Im pretty sure that I can promise you that this will take time for me to wrap my head around it… but I’m reading. Will get back to you here if I succeed understanding it. -Spencer971
Oh je vois que le projet n’est plus maintenu depuis janvier 2021.
J’aimerais bien le reprendre mais ce n’est vraiment pas facile avec les docs ici et là :
de déployer ou simplement de se connecter un réseau de test Ĝ1.
de tester ou reprendre ces débuts de développements de swap (où sont-ils ?).
Déjà dans un premier temps est-ce que je peux déployer un réseau de test Ĝ1 en local.
Je ne trouve nulle part comment le faire.
Est-ce d’autre part les scripts de swap (même embryonnaire) sont quelque part ?
Pourquoi ne pas se renconter (je suis sur Paris).
Merci !
Oui, Sakia est abandonné.
Je te conseille plutôt d’attendre la publication du dépôt de mon nouveau client Tikka.
Je vais reprendre l’atomic swap dedans.
Je laisse les autres répondre si tu veux faire un réseau fermé de g1 test. Je ne sais pas si c’est possible, peut-être en faisant une synchro avec le réseau public, puis ensuite en bloquant les connections extérieures.
Merci, j’ai hâte de voir cela !
Comment tu penses que je pourrais le tester ?
Bon, je vais essayer en attendant de faire tourner un noeud de test (utile non ?) mais c’est pas gagné…
Des pistes ?
?