Tutorial

A simple tutorial meeting you with eoslime

Step by step walk

Let's up the level of difficulty.

Scenario: We are a simple Pizza shop. We have a contract and an account serving our shop.

Shop account has the following roles and responsibilities separated

  • Cooker - only he should be able to notify when a new Pizza has been cooked

  • Shop Manager - he could order more cooking products and withdraw the daily turnover. For the manager to withdraw the money, however, he should have the approval of the owners.

  • 2 Owners - they could withdraw the daily turnover

The contract should have the following functionality

  • Ready Pizza. It should send the cooked Pizza to its buyer.

  • Order cooking products

  • Order a Pizza. By ordering we are notifying our cooker to start making it

  • Buy one piece of the whole Pizza per transaction

  • Withdraw the daily turnover. At the end of the day, the shop manager should be able to withdraw the turnover

Our scenario has been set. Let's have fun and write some code

Define our tests border

Every owner will have a private/public keys pair. These pairs should be registered in the owner's authority of the account. In this way, only the owners will be able to manage the account.

We should load the shop account with the owner's authority so we will be able to modify the authorities in it. We need to load it because when creating a random account, it comes with generated private/public keys pair. This is some kind of a 'default' keys

Your final test suite for the above preparation could like such as

Once we have our owners added to the shop account, let's add our shop manager.

Generate a random private/public keys pair for him and add his keys in a new custom authority called "shopmanager".

At the moment this authority is a brand new one and does not have access to anything in the blockchain. However, we need this person to be able to withdraw the daily turnover and order more cooking products.

We will start by giving our shop manager access to order cooking products

Nice job! We have created a custom authority and give some access to it. Let's continue with turnover access. To achieve this we will create another custom authority called "turnover". We need to configure it as a Multisignature one, so when the shop manager needs to withdraw the money, he should get at least one approval from the owners.

We have created the "turnover" authority because of the approvals. The "shopmanager" one does not need approvals to order more cooking products.

At the moment we have a brand new empty authority. Before adding its operators, let's set its approvals requisition.

Each account's authority has a threshold value and each of the keys inside the authority have weight. We will set these values such as

  • Authority threshold = 2

  • Owners keys weight = 2

  • Shop manager keys weight = 1

The above configuration works as follow. Each of the owners is able to withdraw the turnover independently as their weight is at least equal to the threshold. The shop manager, however, needs his withdrawal transaction to be signed(approved) from at least one of the owners, because his weight is not enough.

We prepared our shop manager. Yeeey! It is time to set up our cooker. For that reason, let's generate for him new keys and create an authority called "cooker".

Fantastic! We have prepared our shop account and our little shop is ready to open its doors. It is Pizza time! I almost forget to tell you about the Pizza price...

A piece will cost 2 EOS tokens. Buy-Pizza method will accept only one argument - the buyer name, so the contract could verify our buyers are the actual signers of their transactions. A bit of security stuff...

The object in the end contains options which are related to how the transaction will be structured and broadcasted

  • from - represents the signer of the transaction - Bob. To the moment our shopContract has its account as a signer of the transaction. If we leave it without from option, the shopContract will sign the transaction, but we need Bob to do it

  • tokens - In this way, you can process a transfer tokens in an atomic way. So you will process the buy action but you won't actually transfer tokens. You should do it in a separate transaction, but if it fails? You will register that you have bought a Pizza, but because of the transfer has failed, you did not give any tokens. tokens option package both of your transactions in an atomic one and if the transfer fails for some reason, you won't be able to buy a piece of Pizza

"Yummy Pizza!". Yeeah, Bob likes our Pizza and he wants to buy 2 more pieces.

Oppps.... Here you will get duplicate transaction error because you are trying to execute the same transaction twice...

To broadcast a transaction with the same parameters twice you have two choices

  • Wait for the first one to be processed and confirmed by the network and after that try to broadcast the second one

  • Force the transactions to be the unique while keeping the same parameters

We have our first client happy. Good work! Let's see how to order a whole Pizza this time.

So easy... Bob has ordered his Pizza

The Pizza has not been delivered yet! Whaaat?

Ouch... we forgot to notify our cooker.... Let's fix this for the feature

Our cheese seems to end very soon. Let's order more cooking products

Our tutorial is coming to its end and our long first day in the shop also. It is time for the shop manager to withdraw the turnover.

Let's load the multisignature "turnover" authority

Once loaded our shop manager will be able to request a withdrawal approval

We had a successful first day in our little shop. Nice work!

Here is how the complete tests could like

Last updated

Was this helpful?