NEM Blockchain Faucet and Transactions using ReasonML
This article explains how to get some virutal juice flowing in form of currency known as XEM. Including transactions using NEM SDK with ReasonML. Let’s get this bread pt.2🥖😎
This article is a follow up on the previous ReasonML and NEM Blockchain; Let’s get this bread🥖😎. To see the steps explained in this article working, it’s necessary to complete the tutorial found in the first article.
The Objective
Our goal is to transfer XEM, from one account to another — for that, we need to create our two accounts, and fill them with XEM, using a faucet.
In case you want to learn only about the faucet, you can skip the throwback time section completely
Throwback time
In case you’ve followed the previous article, you’ve ended up with a file structure as shown below — we’ll use it to integrate the faucet.
Thanks to @44uk_i3, NEM2 Faucet exists. And we’ll set it up right now, let’s start by cloning the repository, once it’s cloned, create a Dockerfile, that we can use to start it up.
Faucet Dockerfile
Next logical step is to build an image, where we can actually run the faucet. We will need nodejs — so let’s use the same version as we have used in the previous article for our ReasonML environment. (node:11.4)
Then, we will have to fill out a bunch of ENV variables, in order for the faucet to function properly. Let’s go trough the variables and explain how and where to obtain the needed values.
API_HOST:
This will be the docker-network URL of the container, where our NEM Rest gateway runs, we know that in our setup, name of the container is catapult-service-bootstrap_rest-gateway_1
API_PORT:
This is the default gateway port, 3000.
PRIVATE_KEY:
This is a private_key of an account, generated when our catapult stack starts. Part of so-called nemesis addresses, that are pre-populated with xem.
How can you find the required private key? First step is to launch the catapult stack.
Then, navigate to catapult-service-bootstrap/build/generated-addresses/addresses.yaml, and look for nemesis_addresses.
Take the first private key that you find, it should be populated with enough xem to fuel our faucet.
So our value value will be:
F1C69759140256420EB42CF39906A01DD02A57FB6D0676AE134343A13A1CBC21
RECAPTCHA_CLIENT_SECRET & RECAPTCHA_SERVER_SECRET
Faucet features google’s recaptcha, so in case your faucet is public, it will be protected from certain types of abuse.
Where can we get those secrets? Navigate to google’s recaptcha site. And enter the admin interface.
Once you’re in, fill out your site’s information, in our case localhost / 127.0.0.1, agree to terms and conditions, and confirm. You’ll be navigated to a page where we can finally extract the secrets for our faucet’s recaptcha.
Our secrets would be visible below, in the colored area.
RECAPTCHA_CLIENT_SECRET = Site key
RECAPTCHA_SERVER_SECRET = Secret key
With all the secrets at our disposal, for our environment config, let’s write the Dockerfile itself, so we can build an image to run our faucet.
We’ve created the Dockerfile previously, we’ll just fill it out now
We’re ready to hop back into the terminal, to build our image and run the faucet. We’ll use a run-in-docker.sh file, similar to the one created in the previous article.
Make sure your catapult stack is up and running first
To finish the faucet setup, let’s install it’s dependencies. Run npm install using run-in-docker.sh.
Time for some juice 🥤
If the stars are aligned in our favour, we should be able to run the faucet now.
First let’s create an account using nem2-cli, where we can send some sweet xem.
Fire up a docker container with nem2-cli installed, ideally app/run-in-docker.sh. Detailed explanation on how to create a NEM Blockchain account / wallet, can be found in the first article.
Troubleshooting
In case you run into troubles with the catapult services, you can try running the docker-compose up, using this commit from July 2018.
You can clear up all the build files and other ‘mess’ that catapult creates, by running ./clear-all inside the catapult directory.
Don’t forget to update your faucet’s private key env variable & rebuild the docker image, each time you clear-all and compose up your catapult services — because the nemesis addresses will change.
We will use this account, to verify that our faucet is working as expected. Let’s start the faucet now. Use nem2-faucet/run-in-docker.sh and run the following commands.
Navigate to http://localhost:9000 in your favourite browser, to verify that the faucet is running as expected.
Transfering XEM from Faucet to your NEM Account
In previous steps we’ve created a NEM account with public address of SD5BOY-KFIWDU-PTSJEK-64RVG2-CQGQYQ-63UXEN-DDKU.
Let’s use the faucet, to send some XEM to our address. Fill out the form, and press claim. Don’t forget to convince google that you’re not a robot 🤖.
How can we verify that the XEM actually arrived at our address? We can use nem2-cli to see our ballance. Let’s use app/run-in-docker.sh and check the balance of our account, using nem2-cli.
Congratulations, you have successfully transfered 1000 XEM, from the faucet, to your own account. Now you’re ready to trade and explore the NEM Blockchain!
Time to hustle 💸
Now that we have enough ‘racks in our pockets’, we can try transfering XEM programatically, using NEM2-SDK.
Let’s start by creating a second acccount, where we can transfer our virtual money.
Now we have two accounts, saved under two profiles: my_account (1000 xem) and my_other_account (0 xem).
Let’s write a ReasonML script, to transfer some xem, from one to another.
The Flow
First, we need to define the recipient’s address, in our case it’ll be our new/second account.
Recipient address: SB7COE-YWEP7K-LAKHJX-VPMBL5–4PIYU7-KTNA7J-LYY3
Then, we need a private key, of the account that holds our 1000xem, because will use it, to sign the transaction.
Private key: 5EBAFD9F3258188E6C1F2AC44CFBF89BF352878FECC517847D4953AD7518EEDD
Next we have to specify the amount we want to send, we’ll send a 100xem, because it’s Christmas time and we’re feeling generous.
Amount of XEM to send: 100
Other than that, we just need to specify our REST gateway URL, but we did it many times before, you’ll see in the code.
Things that are done in our ReasonML code:
- Turn the recipient address into a NEM account
- Turn the private key into a NEM Account, used to sign the transaction
- Define the transfer transaction object, including Deadline, Recipient, Mosaics to transfer (in our case only XEM), Message and the Network
- Sign the transaction, using the NEM Account, created from our private key.
- Announce the transaction to the blockchain network
Most of the file shown below, are type definitions, those would go away, once NEM-SDK provides a ReasonML mapping/version. But for now, we can specify the types ourselves, so the JS-interop works flawlessly.
Let’s create a new file, transferXem.re with the following contents.
We can compile and execute it from our ReasonML container, using run-in-docker.sh, with this command.
The Result
Let’s check if our XEM arrived successfuly to the my_other_account. We can do so using NEM-CLI, and checking the account info as we did previously.
We can see that one of our accounts, has 900 XEM, instead of a 1000 XEM, and the second account now has 100 XEM, instead of 0 / no history on the blockchain. 👏
What’s next?
In the next article, we will create custom mosaics, and trade them between accounts using multi-signature transactions.
