Installer l’outil ft

La première étape de notre voyage consiste bien entendu à installer ft. La façon la plus rapide est d’utiliser Docker, qui permet d’exécuter ft sous Linux, Mac et Windows. Les courageux qui souhaitent bénéficier des dernières améliorations opteront pour la compilation depuis les sources avec opam.

Installer ft avec Docker

La manière la plus simple d’installer ft consiste à utiliser docker, comme indiqué ici. Il est conseillé d’utiliser une version récente de docker .

Cette méthode consiste simplement à télécharger un script, et à utiliser ce script en lieu et place de ft . Le script téléchargera l’image depuis le Docker-Hub à la première exécution et se comportera ensuite simplement comme ft , avec quelques limitations mineures (pas de commande ft exec , accès aux fichiers uniquement dans les sous-répertoires).

L’image est mise à jour assez régulièrement, il suffit alors de lancer la commande docker pull ocamlpro/ft pour utiliser la dernière version.

Installer ft avec opam

Pour suivre le développement de ft au jour le jour, le mieux est de construire le programme depuis les sources. Cette méthode fonctionne bien sous Linux, mais n’a pas été testée sous Mac et Windows.

La méthode consiste ici à installer opam , le gestionnaire de paquets de référence de OCaml, d’ajouter le dépôt des paquets d’OCamlPro, puis d’installer les paquets nécessaires. Il faut aussi installer cargo , le gestionnaire de paquets de Rust, dont dépend le SDK de FreeTON. Cela donne les commandes suivantes pour préparer l’environnement:

$ sh <(curl -sL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh)
$ opam init --comp=4.10.0
$ opam repo add ocp git+https://github.com/OCamlPro/ocp-opam-repository
$ opam update
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ opam install --deps-only ft

Il faut ensuite installer le paquet freeton_wallet ou ft avec opam . La commande ft doit alors apparaître dans le PATH en faisant eval $(opam env) :

$ opam install freeton_wallet
$ eval $(opam env)
$ ft

Soit de compiler depuis les sources sur Github. La commande ft apparaît alors dans le répertoire local:

$ git clone https://github.com/OCamlPro/freeton_wallet
$ cd freeton_wallet
$ eval $(opam env)
$ drom build --switch 4.10.0
$ ./ft

ft n’utilisant pas de fichiers externes, il est tout à fait possible de copier l’exécutable dans un endroit plus pratique, ou de créer un lien symbolique:

$ sudo ln -s $(which ft) /usr/local/bin/ft

Vous pourrez à tout moment consulter la liste des commandes à l’aide de ft --help :

Vous pouvez aussi demander de l’aide sur une sous-commande, par exemple ft account create --help :

Tout wallet FreeTON est un “multisig”… ou presque !

Dans la suite, pour un utilisateur, nous allons distinguer les termes clé, passphrase, wallet, adresse et compte.

• La clé d’un utilisateur est en fait une paire de clés cryptographiques, composée d’une clé secrète (ou privée) et d’une clé publique (pubkey); la clé secrète ne doit jamais être communiquée à quiconque; au contraire, la clé publique peut être librement partagée, elle permet aux autres utilisateurs de reconnaître cet utilisateur.
• La passphrase d’un utilisateur est un ensemble de mot permettant de créer une paire de clés, secrète et publique. Elle a l’avantage de pouvoir être facilement mémorisable, ou écrite sur papier pour être stockée dans un coffre, alors que la clé secrète l’est difficilement. Comme la clé secrète, elle doit rester secrète. Sur FreeTON, la passphrase est généralement composée de 12 mots, facilement distinguables.
• Un wallet est un emplacement sur la blockchain, contrôlé par la clé d’un utilisateur. De la crypto-monnaie peut y être stockée. Sur FreeTON, cet emplacement est toujours géré par un smart contract, qu’il est donc nécessaire de déployer pour pouvoir déplacer les tokens.
• Une adresse est l’adresse sur la blockchain d’un wallet, qui permet d’accéder à ce wallet, au smart contract qu’il contient, et de demander des transferts de tokens. Sur FreeTON, l’adresse d’un wallet est uniquement déterminée par le clé de l’utilisateur, le code du smart contract et les données statiques du contrat.
• Finalement, un compte est le nom associé par ft à une clé ou une adresse mémorisée dans son carnet de contacts. Ce nom permet de référencer une clé ou une adresse beaucoup plus facilement que leur version numérique.

Sur FreeTON, l’adresse d’un wallet dépend donc du code du smart contract qu’il abrite. Pour simplifier les choses, la plupart des utilisateurs déploient un contrat standard, appelé “multisig”, pour gérer leurs tokens. Nous reviendrons plus tard sur l’ensemble des possibilités offertes par ce type de contrats, mais pour l’instant, il suffit de savoir qu’il s’agit quasiment toujours du contrat historiquement appelé SetcodeMultisigWallet2 (et récemment renommé SurfMultisigWallet), déployé par défaut par TON Surf, et par ft avec l’option --surf .

La notion de “switch” pour manipuler les réseaux

Je suppose à présent que vous disposez d’un exécutable ft . Comme toutes les blockchains, FreeTON dispose de plusieurs réseaux: mainnet est la blockchain principale, testnet la blockchain de test… Parfois, à l’occasion de contests particuliers, de nouveaux réseaux sont déployés. C’était le cas pour le contest auquel nous avons participé, un réseau prenant en charge un opérande de vérification des preuves zero-knowledge avait été déployé par la Nil Foundation.

ft permet de changer facilement d’univers sans se soucier de perdre d’informations. Il permet aussi de créer des bacs à sable ou sandbox dans lesquelles on peut facilement, et rapidement, déployer des contrats, tester des scénarios, et disposer d’argent de poche sans avoir à en demander à quiconque. Ces univers sont appelés des switch et on passe de l’un à l’autre ainsi:

$ ft switch to mainnet

Si vous n’avez pas encore d’argent sur un compte FreeTON, ou si vous préférez commencer doucement en sandbox, vous pouvez lancer:

$ ft switch create sandbox1

puis

$ ft node start

Par défaut, une sandbox vient avec des utilisateurs user0 , user1 , etc à qui vous pouvez facilement verser des TON:

$ ft node give user0 --amount 1000000

Vous voilà armé(e) pour la suite.

Créer un compte avec ft

Si vous possédez déjà un compte TON Surf:

Peut-être possédez-vous déjà un compte sur FreeTON, par exemple sur TON Surf. Dans ce cas, cela signifie que vous avez à la fois un compte (défini par votre clé privée, que vous avez probablement stockée en lieu sûr sous la forme de douze mots ou dans un Ledger) et un contrat multisig déployé (seulement si vous avez de l’argent sur ce compte) depuis ce compte, à partir duquel TON Surf calcule votre adresse. Vous pouvez facilement importer votre compte TON Surf dans ft :

$ ft account create mon_compte --passphrase “votre passphrase” --contract SetcodeMultisigWallet2

(mon_compte est simplement l’alias que vous souhaitez donner à votre compte.) Cela vous permet simplement de contrôler votre compte depuis ft en plus de TON Surf, et ne va rien transférer ou modifier à votre compte. Alternativement, vous pouvez ajouter votre compte “en lecture seule”:

$ ft account create mon_compte --address <une de vos adresses> --surf

Vous ne pourrez alors pas initier de transactions depuis votre compte sur ft, mais vous pourrez consulter l’état (typiquement, le solde) de votre compte.

Si vous n’avez pas encore de compte:

Si vous n’avez pas encore de compte, vous pouvez simplement appeler la commande:

$ ft account create blog_example
[...]
Passphrase: "produce coconut gospel observe wild bounce make sudden capital blur banana pen"
{ "public": "0bbb94fc6e2876c9eda45e904e1e4fb34c0a8373bb7ea3963f6c295e6ca89b51",
  "secret": "ed9c7b590b26473ac583f63487f73495a622c4229d4e56e063d6743d39d8a7ee" }
Key for user "blog_example" generated
Saving wallet file /home/thomas/.ft/sandbox1/wallet.json
Saving config file /home/thomas/.ft/config.json

Vous pouvez voir votre clé privée sous forme hexadécimale et sous forme de “passphrase”, ainsi que votre clé publique. Vous n’avez pas encore d’adresse puisque vous n’avez pas encore créé de wallet. D’ailleurs, vous n’avez pas besoin de déployer un wallet pour connaître sa future adresse:

$ ft account create multisig_blog_example --passphrase "produce coconut gospel observe wild bounce make sudden capital blur banana pen" --contract SetcodeMultisigWallet2
[...]

Account "multisig_blog_example" created.
{
  "name": "multisig_blog_example",
  "passphrase": "produce coconut gospel observe wild bounce make sudden capital blur banana pen",
  "pair": {
    "public": "0bbb94fc6e2876c9eda45e904e1e4fb34c0a8373bb7ea3963f6c295e6ca89b51",
    "secret": "ed9c7b590b26473ac583f63487f73495a622c4229d4e56e063d6743d39d8a7ee"
  },
  "account": {
    "address": "0:51ea97d220272fca86bf7c85446df4d7e5e8f70891433c50ec6383f72ed02fba",
    "contract": "SetcodeMultisigWallet2"
  }
}

Lorsque mon compte recevra de l’argent, je pourrai déployer le contrat SetcodeMultisigWallet2 et mon adresse sera celle renvoyée par la commande précédente (0:51ea97d220272fca86bf7c85446df4d7e5e8f70891433c50ec6383f72ed02fba ). Vérifions-le:

$ ft multisig create multisig_blog_example
[...]

fatal exception Deploy failed: {
    code:409.000000
    message:Account does not exist. You need to transfer funds to this account first to have a positive balance and then deploy its code
    data:{
      core_version:1.16.1
      account_address:0:51ea97d220272fca86bf7c85446df4d7e5e8f70891433c50ec6383f72ed02fba

     [...]
  }

Le déploiement a échoué, puisque le compte n’avait pas d’argent. Par contre, on vérifie que l’adresse est bien la même qu’auparavant! Une manière plus orthodoxe de vérifier que le compte n’est pas actif:

$ ft account info multisig_blog_example
[...]
Loading wallet file /home/thomas/.ft/sandbox3/wallet.json
Account "multisig_blog_example": not yet created (empty balance)

Transférer des tokens

Envoyons donc de l’argent à notre (futur) contrat en le parrainant avec l’option --sponsor :

ft multisig transfer 100.000 --from user0 --to multisig_blog_example --sponsor
Config loaded from /home/thomas/.ft/config.json
Network: sandbox4
Loading wallet file /home/thomas/.ft/sandbox4/wallet.json
call: 0:108f6113fb0cad8c98b70e8ea3cfd12b52710ec20441d05ceb78cacb4f5566b7
method: submitTransaction
params: {"dest":"0:51ea97d220272fca86bf7c85446df4d7e5e8f70891433c50ec6383f72ed02fba","value":100000000000,"bounce":false,"allBalance":false,"payload":""}
signed: user0
MessageId: ea235abb3a2dd6adfb9ee98aa5c4bb080f1798123d45c512f4a5522b2ac4c31e
call result:
{
  "transId": "0"
}

Effectuer un transfert de tokens dans FreeTON avec ft

Dernière opération de ce tutoriel, je vais maintenant transférer de l’argent à user1 :

$ ft multisig transfer 100.000 --from multisig_blog_example --to user1
[...]
call: 0:51ea97d220272fca86bf7c85446df4d7e5e8f70891433c50ec6383f72ed02fba
method: submitTransaction
params: {"dest":"0:108f6113fb0cad8c98b70e8ea3cfd12b52710ec20441d05ceb78cacb4f5566b7","value":100000000000,"bounce":true,"allBalance":false,"payload":""}
signed: multisig_blog_example
MessageId: b6a34407669008dce626d769e208f2b47feec3be17cc4cbbe92ceec71516f8b7
call result:
{
  "transId": "0"
}

On peut ensuite vérifier que les tokens ont bien été réceptionnés:

$ ft account info user1

Conclusion

Et voilà! Nous n’avons fait qu’effleurer la surface des possibilités de ft, mais j’espère vous avoir donné envie de l’utiliser! Les prochaines fois, nous verrons par exemple que ft:

• connaît des dizaines de contrats standard de FreeTON par défaut;
• permet d’utiliser l’ABI des contrats pour faire des vérifications de typage au moment des appels;
• permet de surveiller un contrat en direct et les transactions qui lui parviennent, et de les stocker dans une base de données;
• permet de faire des substitutions complexes à la fois dans l’entrée et la sortie des appels;
• permet à tout moment d’appeler tonos-cli pour lui faire exécuter l’équivalent de la commande actuelle;
• permet de créer et exécuter des debots , ces “bots décentralisés” privilégiés par l’écosystème FreeTON pour interagir avec les smart contracts.

Développer sur FreeTON (1): Créer son wallet avec ft was originally published in OCamlPro FreeTON FR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Le mois dernier, nous avions participé à un concours d’idées et d’implémentations de use-cases des zk-SNARKs sur la blockchain FreeTON. Nous avons le grand plaisir d’annoncer qu’OCamlPro a obtenu la première place à ce concours!

Anecdote mathématique et problème pour nos lectrices et lecteurs

Pour le use-case des Sudoku (de taille 4 dans notre implémentation), j’avais choisi d’encoder et de tester l’unicité de chacun des nombres présents dans une colonne, une ligne ou une boîte par la propriété que x + y + z + t = 1 + 2 + 3 + 4 = 10 et le produit x · y · z · t = 1 · 2 · 3· 4 = 4! = 24. Il est vrai que si x,y,z et t sont des entiers entre 1 et 4, alors les ensembles { x, y, z, t } et {1, 2, 3, 4} sont égaux. Qu’en est-il pour le Sudoku de taille 9? Peut-on se contenter de dire que la somme des 9 entiers vaut 45 et que leur produit vaut 9! pour garantir que ces 9 entiers entre 1 et 9 sont distincts?

J’ai écrit un programme pour chercher des contre-exemples, pour les premières valeurs de n (ce calcul ferait au passage un bon Project Euler!) et j’ai découvert que l’unicité de la solution est vraie jusqu’à n=8, et qu’il existe exactement un contre-exemple pour n=9 (et de plus en plus pour n plus grand). Je propose donc un petit défi pour nos lecteurs et lectrices: saurez-vous trouver ce contre-exemple de x_1, x_2, ..., x_9 de somme 45 et de produit 9! (9 factoriel)? Question bonus: Quel est le plus grand entier n pour lequel vous parvenez à calculer tous les contre-exemples en moins d’une minute?

OCamlPro remporte le concours FreeTON sur les Zk-SNARKs! was originally published in OCamlPro FreeTON FR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last year, thanks to our in-house Liquidity programming language, we had started to adapt and extend zk-SNARKs on Tezos in the Dune Network project which is in the process of merging with FreeTON. With the introduction of zk-SNARKs on FreeTON by the Nil Foundation, it was time to get back to it! We participated in the last few weeks in Contest 18, where we had to propose applications of this technology on FreeTON smart contracts. The results are not yet known, but we are proud to tell you about our submission which contains three different applications.

Verifying hidden Sudokus

The first one consists in a smart contract for solving Sudokus. The Sudoku is to zero-knowledge proofs what the Rock-Paper-Scissors game is to smart contracts: a simple example, useful to explain the concept at hand, but already sufficiently annoying to pose some technical problems. In particular, we need to find an encoding of the Sudoku constraints in the form of a quadratic program (details in our submission for the curious). Then, the principle is simple: a Sudoku instance is proposed by the contract, and the user must find a solution, generate a local zero-knowledge proof that he has found it, and submit it to the contract.

Decentralized Infrastructure for Project Euler problems

Project Euler is perhaps the site where I learned the most about programming. It submits problems mixing mathematics and computer science and of varying difficulty (the first problem was solved by a million people; some have only a dozen solutions at their output). To avoid brute-force attacks, which would consist of testing all possible solutions to a problem, the site uses a system of captchas. How could one decentralize Project Euler? The two main problems are
1. verifying solutions without revealing them in the smart contract, either in advance in the verification function or after the answer has been submitted;
2. discouraging brute-forceto attempts.

Zk-SNARKs are a perfect answer to the first problem, since they allow to check a solution without revealing it. For the second problem, we have chosen the following approach: each problem is provided with a nonce. The solution stored (but obfuscated by the zk-SNARKs) in the contract is actually :

SHA256¹⁰⁰⁰⁰⁰⁰(problem number | solution | nonce)

Computing one million iterations of SHA256 takes about 20 seconds, which in a way emulates the captcha. This does not, however, protect against a pre-computation of all possible solutions, hence the presence of the nonce and the problem number, which makes the attacker’s task much more difficult. With this simple trick, the Project Euler submission platform can be completely decentralized!

Recovering from a lost key using a passphrase

Our last use case of zk-SNARKs on FreeTON is more technical: it is to propose a backup solution to change the public key controlling a FreeTON wallet. A common solution to protect oneself from the loss of a private key is the multisig, and in fact the FreeTON wallets are multisig by default. It is then a question of keeping the recovery key in a safe place, typically in a bank safe (a paradox of the cryptocurrency world…). But this is a very slow solution, to which we propose an alternative: choose a password that allows to change the public key that controls a wallet. This solution should be avoided in the absence of zk-SNARKS: the password (or its hash) can always be intercepted and reused by an attacker to hijack the wallet to his advantage. In the framework of zk-SNARKs, the zero-knowledge proof attests to the knowledge of the password coupled with the public key, so that this proof is unusable with another public key.

Conclusion

Participating in this very fun contest allowed us to think about the different uses of zk-SNARKs on the blockchain. Although this first step is much simpler than the Z-cash applications, which are the subject of separate contests, we have already identified different categories:
1. Computation (a precise mathematical calculation is encoded in the zk-SNARK instance used): this is the case of Sudoku, it could have been the factorisation of an integer for example;
2. Static : the static answer is known, and we just check that the user knows it (possibly with a brute-force) : this is the case of Project Euler;
3. Protocol: The essential function of zk-SNARK can be a calculation or static, but the essential issue is to act at the protocol level by triggering transactions or modifying access rights: this is the case of Pincode.

It is easy to see that these categories are not isolated from one another, but they allow us to think about usage paradigms.

Wish us good luck for the upcoming vote and don’t hesitate to ask us questions in the comments section or on twitter!

—
If you want to know more about FreeTON, you can visit our website www.freeton.link and try our wallet in OCaml ft.

Zk-SNARKs, FreeTON and OCamlPro was originally published in OCamlPro on Medium, where people are continuing the conversation by highlighting and responding to this story.

L’année dernière, grâce à notre langage de programmation Liquidity, nous avions commencé à adapter et étendre les zk-SNARKs de Tezos dans la blockchain Dune Network, qui est aujourd’hui en voie de fusion avec la blockchain FreeTON. Avec l’introduction des zk-SNARKs sur FreeTON par la Nil Foundation, il était temps de s’y remettre ! Nous avons participé ces dernières semaines au Contest DevEx 18 à l’occasion duquel nous devions proposer des applications des zk-SNARKs sur les smart contracts FreeTON. Le classement n’est pas encore connu, mais nous sommes fiers de vous présenter notre soumission qui contient trois applications différentes !

Vérification de Sudokus Cachés

Notre première application consiste en un smart contract de vérification de Sudokus. Le Sudoku est un peu aux preuves zero-knowledge ce que le Pierre-Feuille-Ciseau est aux smart contracts: un exemple simple, utile pour expliquer le concept en question, mais suffisamment embêtant pour poser déjà quelques problèmes techniques. Il faut notamment trouver un encodage des contraintes du Sudoku sous forme de programme quadratique (détails dans notre soumission pour les curieux). Ensuite, le principe est simple: une instance de Sudoku est proposée par le contrat, et l’utilisateur doit trouver une solution, générer localement une preuve zero-knowledge qu’il l’a trouvée, et la soumettre au contrat. Ainsi, il prouve qu’il l’a résolu, sans fournir la solution aux autres utilisateurs !

Infrastructure pour le Projet Euler

Project Euler est peut-être le site sur lequel j’ai le plus appris à programmer. Il soumet des problèmes mêlant mathématiques et informatique et de difficulté très variable (le premier problème a été résolu par un million de personnes ; certains n’ont qu’une dizaine de solutions à leur sortie). Pour éviter les attaques brute-force qui consisteraient à tester toutes les solutions possibles à un problème, le site utilise un système de captchas. Comment décentraliser Project Euler ? Les deux problèmes principaux résident

1. dans la vérification des solutions sans les révéler dans le smart contract, soit à l’avance dans la fonction de vérification, soit par la suite après la soumission de la réponse ;
2. dans le fait de décourager le brute-force.

Les zk-SNARKs sont une réponse parfaite au premier problème, puisqu’ils permettent de vérifier une solution sans la révéler. Quant au second problème, nous avons choisi l’approche suivante : chaque problème est muni d’un nonce aléatoire à sa création. La solution stockée (mais obfusquée par les zk-SNARKs) dans le contrat est en réalité :

SHA256¹⁰⁰⁰⁰⁰⁰(numéro du problème | solution | nonce)

Calculer un million d’itérations de SHA256 prend environ 20 secondes, ce qui émule en quelque sorte le captcha. Cela ne protège pas, en revanche, contre un pré-calcul de toutes les solutions possibles, d’où la présence du nonce et du numéro de problème qui compliquent singulièrement la tâche de l’attaquant. Par ce simple tour de passe-passe, on peut complètement décentraliser la plate-forme de soumission de Project Euler!

Au final, notre solution permet de facilement créer de nouveaux problèmes en ligne, d’obtenir pour chaque problème un TOP10 des premiers à l’avoir résolu, et de conserver, pour chaque utilisateur, la liste de tous les problèmes qu’il a résolu… sans jamais qu’aucune solution ne soit révélée !

Récupération de la Perte d’une Clé Secrète via une Passphrase

Notre dernier cas d’utilisation des zk-SNARKs sur FreeTON est plus technique : il s’agit de proposer une solution de secours pour changer de clé publique quand on a perdu la clé secrète correspondante. Une solution commune pour se prémunir de la perte d’une clé privée est le multisig, et d’ailleurs les wallets FreeTON sont multisig par défaut. Il s’agit alors de conserver en lieu sûr, typiquement dans le coffre-fort d’une banque (c’est un paradoxe du monde des cryptomonnaies…) la clé de récupération. Or c’est une solution compliquée à mettre en oeuvre, lente à récupérer, qu’au final, peu de gens prennent le temps de mettre en place… prenant ainsi des risques considérables !

Nous proposons donc une alternative simple et pratique à base de sk-SNARKs : choisir un mot de passe permettant de changer la clé publique qui contrôle un wallet, et n’importe quel contrat compatible. Cette solution est à proscrire en l’absence des zk-SNARKS: le mot de passe (ou son hash) pourrait être intercepté et réutilisé par un attaquant pour détourner le wallet à son avantage. Dans le cadre des zk-SNARKs, la preuve zero-knowledge atteste la connaissance du mot de passe couplée avec la clé publique, de sorte que cette preuve est inutilisable avec une autre clé publique.

Conclusion

Participer à ce contest au demeurant très amusant nous a permis de réfléchir aux différentes utilisations des zk-SNARKs sur la blockchain. Bien que cette première étape reste beaucoup plus simple que les applications à la Z-cash, qui font l’objet de contests séparés, nous avons déjà identifié différentes catégories :

1. Calcul (un calcul mathématique précis est encodé dans l’instance de zk-SNARK utilisée) : c’est le cas du Sudoku, ça aurait pu être la factorisation d’un entier par exemple ;
2. Statique : la réponse statique est connue, et on se contente de vérifier que l’utilisateur la connaît (en se prémunissant éventuellement d’un brute-force): c’est le cas du Project Euler ;
3. Protocole : L’essentiel de la fonction du zk-SNARK peut être un calcul ou statique, mais l’enjeu essentiel est d’agir au niveau du protocole en déclenchant des transactions ou en modifiant des droits d’accès : c’est le cas du Pincode.

On voit aisément que ces catégories ne sont pas imperméables entre elles, mais elles permettent de penser des paradigmes d’utilisation.

Souhaitez-nous bonne chance pour le vote à venir et n’hésitez pas à nous poser des questions en commentaire ou sur twitter!

Si vous voulez en savoir plus sur FreeTON, vous pouvez notamment aller voir notre site www.freeton.link et essayer notre wallet en OCaml ft/freeton_wallet.

Zk-SNARKs, FreeTON et OCamlPro was originally published in OCamlPro FreeTON FR on Medium, where people are continuing the conversation by highlighting and responding to this story.

Après notre premier article sur la blockchain FreeTON, nous allons vous montrer comment créer votre compte et comment le gérer.

Il existe plusieurs logiciels (wallets) pour gérer ses tokens:

• TON Surf est probablement le plus utilisé. Ce wallet développé et maintenu par TON Labs existe en plusieurs variantes : web, mobile, sur Android, mais hélas pas encore sur iOS en France. Il présente l’avantage de supporter les DeBots, une fonctionalité spécifique à Free TON dont nous parlerons dans nos prochains articles ;
• ExtraTON est une extension de navigateur, comme Metamask, pour l’instant uniquement disponible sur Google Chrome.
• TON Crystall Wallet est un wallet desktop, développé par Broxus, qui permet de facilement staker (investir) ses tokens.
• Pour la ligne de commande, il y a le choix entre tonos-cli, le client officiel, relativement difficile au premier abord, et notre wallet orienté développeur ft , dont nous aurons l’occasion de parler plus amplement dans de prochains articles.

Dans ce tutoriel, nous allons utiliser la version web de TON Surf, qui présente le plus de potentiel à notre goût. (Si vous l’utilisez en français, vous pourrez apprécier la saveur particulière des traductions, exotiques mais toujours compréhensibles, depuis le russe.)

Important

En l’absence de support pour les Hardware Wallets de type Ledger, Free TON utilise des “passphrases” (BIP39) pour générer les clés secrètes et adresses correspondantes. Il sera indispensable, dans le suite, de sauvegarder cette liste de 12 mots correspondant à votre clé secrète, hors de votre ordinateur et loin de tout regard, pour pouvoir récupérer vos tokens à tout moment depuis n’importe où.

Le wallet web TON Surf

Rendez-vous sur web.ton.surf/settings. La page suivante doit s’afficher :

Cliquez sur “Créer un portefeuille”:

Free TON met la décentralisation au centre de sa vision. Les créateurs de ce wallet vous demandent de signaler votre accord en signant cette charte. Lisez-la et confirmez votre accord.

Avant que TON Surf ne génère notre clé secrète et le compte associé, nous allons entrer un code PIN de 6 chiffres qui permettra de le conserver sur cet ordinateur et de le protéger d’autres utilisateurs. Il faut donc entrer ce code:

puis le confirmer:

Cela étant fait, le wallet génère votre clé secrète, et vous accédez à la page d’accueil de votre compte nouvellement créé :

Nous ne possédons pour l’instant pas de tokens.

L’important, pour l’instant, est de sauvegarder la passphrase, ou clé maître. Pour cela, sur cette page “Paramètres”, cliquez sur l’option “Protection de sécurité”.

Dans ce menu, on peut accéder à son adresse avec l’option “Adresse et clés” :

L’adresse de votre compte est celle qui commence par 0: puis une suite de 64 caractère hexadécimaux. Enregistrer cette adresse pour plus tard, c’est elle qui vous communiquerez à vos contacts pour qu’ils vous transfèrent des tokens.

Maintenant, revenons dans l’onglet “Protection de sécurité”, et cliquez sur “Mot de passe principal” (“Master password” si votre interface est en anglais). Le wallet vous demande de fournir votre PIN de 6 chiffres pour pouvoir y accéder. Il affiche alors la liste de 12 mots qui composent votre passphrase. Sauvegardez là sur un papier, que vous conserverez dans un endroit sûr (coffre fort, etc.). Encore une fois, elle vous sera indispensable (mathématiquement indispensable, et pas juste pour prouver votre identité à quelqu’un: personne ne pourra la retrouver avec toutes les ressources du monde) si vous changez d’ordinateur par exemple, et elle constitue la seule garantie d’accès à votre compte.

Nous vous recommandons de suivre le processus d’enregistrement de de révérification: notez votre mot de passe sur un papier:

Appuyez sur Enregistré. Revérifier et réécrivez manuellement votre mot de passe principal:

Et voilà! Vous avez maintenant en votre possession les deux informations les plus importantes:

• une adresse de portefeuille sur laquelle recevoir et transférer des tokens
• la passphrase permettant de retrouver cette adresse depuis n’importe quel autre ordinateur (ou si vous oubliez votre code PIN…)

Nous allons voir dans nos prochains articles comment aller plus loin, d’une part à travers la délégation des tokens aux validateurs, d’autre part à travers l’utilisation de ft , notre wallet en ligne de commande, pour les développeurs.

Premiers pas sur FreeTON : créer son compte was originally published in OCamlPro FreeTON FR on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I started writing smart contracts, I assumed it would be just like any other programming task. You have your world computer, the blockchain. You write entrypoints which receive money, compute stuff and possibly send back some money. You stare really hard at the program once written, test it, maybe even prove it correct to some extent. In return, you get a sort of unbreakable vending machine that people can trust because it does exactly what its code tells it. End of story?

Well, not all your users will be keen on writing command line calls to your dapp. Perhaps then, you’ll want to build a front-end: a webapp. This webapp is going to need to interact with the blockchain constantly, either to query its state or to send transactions.

So, for the sake of usability, you’re going to want to replicate the on-chain data structures in your webapp, and sync it with the blockchain. You’ll probably need to do some of that in the back-end. Maybe you’re running a raffle, and you need to periodically insert a secret number into it, and, later, you need to reveal it? You need to crawl the blockchain for transactions to and from your smart contract, in order to monitor what’s going on.

What I’m getting at is you’ll probably need to duplicate a lot of code, in several programming languages (say Liquidity, OCaml and Javascript in our case). Smart contracts are hard to get right. You need performance and security because this piece of code will be on-chain forever, manipulating people’s money. Odds are you’re going to have to make lots of small to big changes all the way until the last stages. Every time, you’ll need to modify at least three code-bases to propagate these changes. What could go wrong?!

It is dangerous to do things this way, this much is clear. But what I’ve learned from actually developing and deploying smart contracts is that it’s also really, really tedious. My bet is that this is playing a big part in why smart contract development has not taken off as much as one might have imagined a few years ago. And when it has, spectacular bugs have occurred (at this point, I don’t think I even make a list of links to the horror stories out there!).

Dogfooding Spice

In response to both the tedium and the anxiety of getting things wrong, we started developing our own internal tool for smart contract development. Every time we wrote a new smart contract, we automated some parts of what had been done in the previous one. First, it was about scripting simple scenarios: deploy your contract, memorize its address, make some calls to it. Next, we wanted to be able to generate a simple Dapp directly from the smart contract source code. For this, we used OCaml’s outstanding fitness for programming languages manipulation. Our code would automatically spit out OCaml and Javascript interfaces to our contracts. Now, every time there was a change to a contract, we could just re-generate our dapp and get nice, readable type errors wherever we had broken things.

But wait! If our contracts were now basically OCaml interfaces, we could do so much more than just script a smart-contract deployment and a few calls! We could write full-fledged scenarios, check invariants automatically, use property-based testing (speaking of which, check out this beautiful post from the Concordium Blockchain centre).

We built all these features into a tool we call Spice, whose release is imminent. Spice is the reason we’ve been able to port Tezos’ zk-snarks to Dune Network, right as development was being made public. Using Spice, we delivered the Dune Playground game platform. We’re also using it to develop Dune Oasis in record time, as well as another, major ongoing project!

Our dedicated team of nine have developed many other awesome tools for Tezos and/or Dune Network. The Dunscan block explorer pioneered UIs for Proof-of-stake. The Liquidity and Love smart contract languages, made by our PhDs in programming languages, are both readable and strongly-typed. The Metal browser extension is a simple and elegant way to interact with dapps in the browser. The IronMin storage library has brought massive performance improvements on vanilla Tezos storage. We have ported the Solidity programming language to OCaml and are currently testing it on the Dune Network. The list goes on!

We’re constantly innovating from the ground up, developing our own smart contracts and learning the pain points! At the same time, we’re reliably delivering tools and services for the public and our clients. In the next post, we’ll go into more detail about the inner workings of Spice. I will open-source it, and detail exciting prospects for the future with Solidity integration and more formal methods. Please get in touch if you’re interested in getting Spice for other smart contract languages/blockchains!

Join the #duniverse:

Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network

Origins of Spice: lessons learned in smart contract development (Part I) was originally published in Dune Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

Explore Dune Playground website and discover our new Dune Moonshot game!

In the first part of “Introducing Dune Playground”, we set up the Dune Metal extension, got some free $DUN and played Rock-Paper-Scissors. Recall that we earned tokens, called DGG (for Dune Good Game), and I promised I would explain how these can be converted back into $DUN. Some of you actually figured out how to do it, as demonstrated by some transactions on DunScan.

The DGG token

Think of it as a Casino chip, except that we never ask you to spend it to be able to play our games: you will only receive it as a reward for playing. You can convert them to $DUN coins, or alternatively keep them as proof of your gaming skills.

The DunScan block explorer handles fungible tokens à la ERC-20 (written in Michelson or in Love languages) such as DGG. If you go search your address in DunScan after playing Rock Paper Scissors from the previous tutorial, you will notice a new tab called “Tokens”. Clicking on the “Tokens” tab, we get a summary of transactions involving the DGG token for your address:

Handily, the Dune Playground provides a special page for converting your DGG to $DUN if you wish, at the current rate of 20 DGG for 1 $DUN. For this, you need to send your DGG tokens to the address of the exchange contract, which will in return send back the corresponding amount of $DUN to your address.

As shown below, you can simply click on the exchange address at the bottom of the page, or copy it here: KT1HfsPEKiftJvexbFuTUPevW4o48JkC49aU. Input any whole amount of DGG between 1 and your current amount (in my case, 10), and then click “Send”:

Just like last time, after approving the transaction, you will see the hash of a transaction that has been injected by Metal.

The DGG transaction will appear in the “Tokens” section of your account on DunScan:

Then, you will receive your $DUN (in my case, .5 $DUN):

Now that you know how to cash out, let’s play a more exciting game than Rock Paper Scissors.

Play Dune Moonshot

You’re trying to send a rocket to the Moon, set at the realistic distance of 8 kilometers from the Earth. It may reach the moon, in which case you will make 34 DGG. Or it may blow up before. You can decide to jump off the rocket at any whole number of kilometers between 1 and 8. As long as you jump before it explodes, you earn an amount of DGG that depends on how many kilometers you already went.

Here is the welcome screen of Moonshot inside the Dune Playground.

Let’s say we guess 3 and click send.

The operation is then injected in the blockchain and Dune Playground will monitor its inclusion:

As usual, we can follow the operation on the blockchain with DunScan blocks explorer:

Nice! My guess is not greater than the oracle’s value. I jumped before the rocket explodes :-). For this move, I earned 3 DGG:

Will you be able to bet 8 and win ? In which case you’d earn 34 DGG ? In fact, you may want to know that the rewards map is as follow:

• lost game 🠆 earn 1 DGG
• bet 1 and win 🠆 earn 1 DGG
• bet 2 and win 🠆 earn 2 DGG
• bet 3 and win 🠆 earn 3 DGG
• bet 4 and win 🠆 earn 5 DGG
• bet 5 and win 🠆 earn 8 DGG
• bet 6 and win 🠆 earn 13 DGG
• bet 7 and win 🠆 earn 21 DGG
• bet 8 and win 🠆 earn 34 DGG

Do you recognize Fibonacci sequence here ? :-)

Have fun playing and come back soon for more games and technical details!

Connect with us:

Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network
Email: contact@dune.network

Introducing Dune Playground — Part 2: DGG Token and Moonshot Game was originally published in Dune Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are happy to introduce the Dune Playground! It is intended
both as a place where anyone can play games and earn tokens while
playing, and a showcase for developers to learn how to write DApps for Dune Network. This tutorial is intended for a wide audience and will walk you through the steps to install Dune Metal, get free $DUN tokens and use them to play the Rock-Paper-Scissors game.

The playground website can be found here: playground.dune.network/

1. Installing the Dune Metal extension

In order to use it, you will first need to install the Dune Metal browser extension, an in-the-browser wallet to secure your secret key. Metal will sign your transactions to the blockchain during the game, and will allow you to receive rewards and move them between accounts.

If you already have Metal installed and configured (or if you just want to get some free $DUNs), you can go directly to section 2. Otherwise, in any of the four supported browsers (Chromium, Firefox, Brave and Chrome), head to the Dune Metal webpage:

Click “download”. Depending on your browser, you will be taken to different pages. We only deal with Firefox and Chrome here, the other ones are similar to Chrome.

In Firefox

Click “Add to Firefox” and then “Add” in the popup window.

Go below to see how to setup Metal.

In Chrome

Click “Add to Chrome” and then “Add extension” in the popup window.

Setting up Metal

In both browsers, you will land on a setup page.

Read the instructions at your convenience and click next until you get to the page:

Unless you already have a Dune Network account that you want to use with Metal, you will want to create a new account. Anyway, Metal can manage multiple accounts if you want:

Metal generates a mnemonic which is a word representation of the secret key which controls your account. Write it down somewhere safe, and then proceed with “I wrote down my mnemonic”. Optionally choose a password, and you’re all set:

You don’t have any DUN for now, and your account has not been “revealed” to the wide world, meaning that it only exists as a number on your computer for now (unless you restored your personal account on Metal).

Let us remedy these two problems by getting some free $DUN and playing a game of Rock Paper Scissors.

2. Get Free $DUN Tokens

Even though all games on the Dune playground are free to play, you will need a little $DUN just to reveal your fresh account and to pay for fees (if the games’ smart contract doesn’t pay fees for you). We have set up a simple page where you may retrieve 0.3 $DUN every 20 minutes.

Head to the Dune Playground, our game area:

Click on “Get Free $DUN”:

The Get-Free-DUNs DApp respectfully requests your permission for Dune Metal to interact with it. Approve it by clicking the green check. Your address is automatically filled in the input box of the $DUN faucet. Click “Get free $DUN” and fill the captcha. If you don’t have Metal installed or you want to airdrop another dn1 wallet, just provide the address you’d like to airdrop in the text area.

It should only take a couple of minutes (a couple of blocks on the blockchain) for you to receive your free $DUN to appear in Metal. You can also check out the Dunscan block explorer and type your address (you can find it in the Metal icon on the top right of your browser, or in the “Get Free $DUN” input box) in the search bar to monitor the incoming transaction. Eventually you receive 0.3 $DUN:

You’re now ready to play a game of Rock-Paper-Scissors.

3. Playing Rock Paper Scissors on Dune

In the Dune Playground home page, click “Play Rock Paper Scissors”.

You may be wondering why we chose this game as a first example. It turns out historically, it was one of the first “simple enough that everyone understands the game, hard enough that everybody gets it wrong the first time” examples of smart contracts studied by researchers. This gives it a bit of a Hello world (ok, maybe FizzBuzz) feel as far as DApps go. In this case, an oracle has already chosen moves that it has committed to (using a hash). Uncheck “Pay fees for me if possible” (only this first time, so your address is revealed). Choose one of Rock, Paper, or Scissors and click on it. You get a transaction request from Metal:

Note that the amount of the transaction is 0 $DUN, but the fee is something like ~ 0.011 $DUN. This fee is used to pay for the transaction to be included in the blockchain. As explained above, once you send this one transaction, all future calls to the Dune Playground games can have their fees paid for by the contract itself, thanks to our novel “collect-call” feature.

Once you send the transaction, notice the message saying “Latest choice injected with hash …” at the bottom. You may click on the link and, if the operation has been included into the blockchain (on average it takes one minute), you will see inside Dunscan:

(Bonus: if you click on the “Yes” link under “Params” at the bottom of the page, you will actually see your move encoded in the transaction)

Going back to the Rock Paper Scissors page, you will see that the current game is marked as “Ongoing”. Your transaction has been included, the oracle is now proceeding to reveal its move (which was already set in stone before you played, thanks to hash commitments). And..

Well, I lost. I’m sure you’ll do better. But I still get 1 DGG token for my trouble. These are in-house tokens for the Dune Playground, which may be earned by playing games and even sold for $DUN! We will expand on these two aspects next time. Thanks for playing, have fun!

Last, but not least, don’t hesitate to give your feedback, to spread the word, to contribute or to report bugs.

Connect with us:

Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network
Email: contact@dune.network

Introducing Dune Playground — Part 1: Free DUNs and the Rock-Paper-Scissors Game was originally published in Dune Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last time, we examined various ways for an oracle to provide randomness for games on the blockchain. Today we take a closer look at our implementation of what we call OnChainAlea, our on-chain mediator between games and oracles. It is written in the Love smart contract language.

If you haven’t , we recommend you read the last article before getting back here.

As we explained then, this contract acts as an intermediate between an oracle (or possibly several, in the future) and various users, most of which we expect to be DApps. A DApp may request a random integer (from, say, 0 to 9) from the mediator. Let’s call such a random number a prophecy in the rest of this post. The oracle can then supply a prophecy to the mediator, which is passed on to the DApp. Using this mechanism has at least two benefits. First, we provide a low transaction fee average cost (since a hash commitment to a random number takes non-negligible space on the chain, it is better to group them). Second, we provide high assurance that the prophecy is tamper-proof, meaning that the random value has not changed between its commitment by the oracle and its request by the DApp. This is at the cost of the slightly increased latency due to the indirection through our mediator.

Let’s examine our ~600-LOC smart-contract (which can be found here):

Storage

The storage of the contract is composed of owner-defined origination parameters and permanent data structures.

Owner-defined parameters

The following are set at deployment time.

• owners: the addresses controlling the oracle.
• nb_prophecies_per_commit: the number of prophecies to which the oracle commits every time it submits a hash.
• nonces_safety_limit: maximal number of batch commitments an oracle may insert without revealing them. We will see later that the oracle has to pay for every commitment it does not honor, hence it is imperative that it remain "solvable" with respect to this "debt".
• gc_protection_window: Minimal number of blocks during which prophecies may not be garbage collected: DApps may need answers to remain for say, a few days, before a game is closed. Note that we are considering ways to make the history of prophecies permanently accessible using Merkle trees and an incentive system, without clogging the storage of the contract. We may address this point in a later post.
• min_safety_deposit_per_reservation: A deposit per prophecy that the oracle may lose if it does not honor its obligations (such as actually revealing the prophecy).
• reservation_cost: cost for a DApp to reserve a slot and obtain a prophecy. This serves in part the purpose of paying the oracle for its service.
• prophecy_reveal_delay: Maximum delay to reveal a prophecy after a reservation is made.
• nonce_reveal_delay: Maximum delay to reveal a nonce after all the prophecies for a corresponding commit are revealed.

Other storage

The storage contains:

• various maps storing the address of the oracle, non garbage-collected commitments, reserved prophecies, revealed prophecies, and a lookup table to match query ids to slot indices.
• Indices for the last_inserted_commit, the last_revealed_commit, the last_GCed_commit, the last_reserved_prophecy and the last_revealed_prophecy.
• A terminated boolean which, if true, means the contract is dead and makes it unusable.
• A min_safety_deposit (which is automatically computed from user-defined parameters). It is deposited by the oracle. It allows compensation of all flouted parties in the worst case of oracle malfunction, whether accidental or malicious.
• The above user-defined parameters.

Entrypoints and views

Entrypoints and views for dapps

On the DApp-facing side, the main entrypoints are:

1. val%entry reserve storage _d (qid : query_id)
   The reserve entrypoint expects a query id of type nat (non-negative integers). This id should be unique from the point of view of the Dapp, the easiest way being to increment a counter every time a new prophecy is needed. The effect of this function is to book a "slot" in one of the upcoming batches of prophecies. The function may fail if no commitment has been inserted and all current slots have been booked.
2. val%view get_answer storage ((qid,addr) : query_id * address option) : nat option
   The get_answer view allows anyone to observe the prophecy corresponding to a given query_id and (optionally) address. Note that this function may also be called off-chain with an RPC, which can be useful when building the client-facing UI of a DApp.
3. val%entry denounce_prophecy storage d (i : slot_index)
   The denounce_prophecy entrypoint can be called by anyone, and its existence is meant to hopefully ensure that it will never be called. It takes as input the index i of a slot for which the caller thinks the oracle has not provided a prophecy, even though prophecy_reveal_delay blocks have been published since the oracle's initial commitment to its batch. This triggers a reimbursement of the DApp of min_safety_deposit_per_reservation DUN from the oracle's initial security bond.
   This reimbursement may be used in turn for the DApp to provide guarantees to its user: if a game stalls because of foul play on the oracle side, the DApp can implement a mechanism to pay the user back, no questions asked. Of course, we envision several mediators for various levels of risk: min_safety_deposit_per_reservation may be 1 cent, 1 euro or a 100 depending on the stakes.
4. val%entry denounce_comm storage d (i : comm_index)
   Similarly to denounce_prophecy, the denounce_comm entrypoint is a deterrent which can be called by anyone to punish the oracle for not revealing a nonce for a batch of prophecies (the nonce is crucial to check that prophecies have not been tampered with by the oracle). If the denunciation is well-founded, a payment is made to each Dapp of min_safety_deposit_per_reservation for each slot in a batch (there are nb_prophecies_per_commit per batch).

Entrypoints and views for the oracle

Most of the rest of the contract deals with entrypoints for the oracle.

1. val%entry insertCommitments storage d (cl : bytes list)
   insertCommitmentsenables the oracle to send one or more commitments, each for a nonce and a list of prophecies. Recall from last time that a commitment is computed as
   hₖ = sha256( nonce, u₀ … uₙ)
2. val%entry revealProphecies storage d (pl : nat list)
   revealProphecies enables the oracle to reveal one or more prophecies for already inserted commitments. Only prophecies whose slot have already been reserved by some DApp or user may be revealed. The oracle should be especially careful not to attempt to reveal values which have not been committed (for example by attempting to simulate the execution of the revealProphecies function off-chain, on a local node) because, even if the transaction fails, the value it contains should now be considered public.
3. val%entry revealNonces storage d (nl : nat list)
   In the same way, revealNonces enables the oracle to reveal one or more nonces for already made commitments whose prophecies have all been revealed. In the same way, the oracle should be careful to check that these properties are satisfied, let it should inadvertently reveal information which may be used to cheat its users.
4. val%entry gc storage d (() : unit)
   gc garbage collects old commitments and revealed and reserved prophecies, so as to maintain a low cost of storage for the contract. In future versions, we might keep a root hash of an off-chain Merkle tree containing all past history, and incentives for actors to store it and provide parts of it on-demand.
5. val%entry withdraw storage d ((amount, dest) : dun * address)
   If the contract is terminated and the oracle has fulfilled all its obligations, it may withdraw its security bond using this entrypoint. Nothing can be done by the contract unless the security bond is at least min_safety_deposit.
6. val%entry deposit storage d (_ : unit)
   The oracle (or anyone on its behalf) may deposit money into the contract in order to reach min_safety_deposit and be able to function normally.
7. val%entry terminate storage d (_ : unit)
   The terminate entry will only function if all obligations (nonces and prophecies revealed) are met. It will make the contract unusable from then on. All withdrawals must be made before terminate is called.
8. val%entry delegate storage d (pkh_opt : keyhash option)
   The owner may choose to delegate the contract’s balance to a baker using the delegate entrypoint.

Observations on trust

We want to address one attack channel: the oracle might offer its prophecies to the highest bidder, off-chain, before they are revealed on-chain. Thus, the oracle could theoretically cheat its users (the DApps and/or the users of the DApps) while still scrupulously meeting its (smart-)contractual obligations to them. This does not make such an oracle unusable, however:

• In the long term, a bias would show in the results of the DApp and the reputation of the oracle (which is all it has to show for itself) would take a significant blow;
• If the incentives are correctly balanced on the DApp side, the maximum feasible cost of knowing a prophecy in advance should be very low. Thus the oracle would need to sell this information to many users to make it worth its while, which in turn would increase the risk of being outed and losing all its customer base.

In our upcoming Raffle smart contract, we enable any user to add randomness to the oracle, to prevent collusion. This is too expensive however to do in the case of games with smaller stakes.

Conclusion

The full source code of the contract is available here but we hope that this article has clearly articulated the architecture of our OnChainAlea mediator contract. It plays an intermediate role, for both safety and efficiency reasons, between an oracle and DApps in need of random numbers (or prophecies) to properly function. Next time, we will showcase Dapps using slightly different oracles.

Footnotes:

1. By batching prophecies instead of sending one commitment for every prophecy.
2. that is to say, that it has not been modified upon learning what it would be used for.

Games with oracles on blockchains (Part II) was originally published in Dune Network on Medium, where people are continuing the conversation by highlighting and responding to this story.

By F.

In this series of articles, we summarize various relevant information about the Binance DEX decentralized cryptocurrency exchange, how it works, and the process of applying. In doing so, we hope to help the community with issuing and swapping tokens and make the process even smoother. This first article describes how atomic swaps work. The next will dwelve into more technical details of how atomic swaps are done on Binance DEX.

Blockchains are all about decentralization. Bitcoin was the first decentralized digital currency, i.e. controlled by no central entity: decision power was distributed proportionally to miners which meant, initially anyone with a laptop.

Besides the concentration of mining due to specialized hardware, cryptocurrency exchanges have been a major factor in the centralization of the ecosystem. Much like nowadays most email addresses are hosted at Google and Microsoft, it seems a large fraction of cryptocurrency users are giving up ownership of their coins to a few exchanges. This has made the numerous hacks of such websites extremely damaging, the most egregious example to this day remaining Mt Gox in 2014.

In the case of exchanging cryptocurrency against fiat currency, it is difficult to improve on the centralized model. However, swapping between two cryptocurrencies is elementary — as it should! — thanks to a cryptographic setup called the atomic swap.

Intro

Why the name? Atomic etymologically means “that which can not be divided in smaller parts”, and the concept comes from concurrent programming and database systems where it designates a series of operations of which either all occur, or none. In our case, suppose we wish to trade BTC for DUN: the operation will consist in two transactions, one transferring BTC, the other transferring DUN, but we never wish for one to occur without the other, in other terms we wish for the swap to be atomic.

Protocol

Suppose then Alice wants to send BTC to the White Rabbit, in exchange for DUN.

1. Alice chooses a secret random number , and hashes it into , for example using for the well-known SHA-256 function.
2. Alice creates on the Bitcoin blockchain a special transaction, called a hash time-locked (HTL) transfer, with the following properties:

• If after two days no-one has claimed the transaction, it reverts all the money (in BTC) back to Alice.
• this transaction can only be claimed by revealing , upon which it will transfer its amount to the White Rabbit: that is to say, it knows and will hash any input to check that before releasing any funds.

3. The White Rabbit, seeing this transaction, creates a quite similar
transaction on the Dune Network blockchain:

• If after one day no-one has claimed the transaction, it reverts all the money (in DUN) to the White Rabbit.
• this transaction can also only be claimed by producing (which is then hashed and compared to since the White Rabbit doesn’t know yet).

4. Now let’s examine what could happen from then on, and why this is
called an atomic transaction:

• If Alice does not reveal , the White Rabbit’s transaction expires first — upon which it receives its money back. There is no point then for Alice to release and forfeit her bitcoins, and thus the swap operation is canceled.
• if Alice reveals by releasing the White Rabbit’s transaction, then, because the Dune blockchain is public, the White Rabbit can see the value of and use it to release Alice’s transaction on the Bitcoin blockchain — which is still time-locked for at least 24 more hours, hence the White Rabbit has ample time.

Atomicity

As you may already have noticed, atomic swaps are not as “atomic” as one might expect knowing the usual definition. For example, if after the White Rabbit’s transaction expires, Alice releases by mistake, she forfeits her BTC without getting DUN in return.

Thus, as often with blockchain concepts, this “atomicity” property is conditional on agents being “rational” in the narrow economic sense, something along the lines of “if I possess information () which I can use to transfer money to myself, I will use it”. There are of course many cases in real life when this is not the case.

To make the transaction “more” atomic, one possibility is to give anyone the possibility of submitting to the smart contract locking the funds, in exchange for a reward. Creating this incentive makes it more likely that someone will act “rationally” and propagate .

One of the biggest cryptocurrency exchanges, Binance, has recently decided to launch a decentralized version of itself, Binance DEX, using atomic swaps as a building block.

Binance has its own blockchain, built on top of the Tendermint framework, and on which it maintains its own token BNB.

The Binance blockchain does not have smart contracts per se, but it provides hash time-locked transfers as a native feature. In the next article, we will first examine how things work once a token has been issued; then we will address the question of issuing your own tokens on Binance DEX. Stay duned!

Connect with us:

Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network
Email: contact@dune.network

Introduction to Binance DEX, Part I: Atomic Swaps was originally published in Dune Network on Medium, where people are continuing the conversation by highlighting and responding to this story.