Today we’re launching a whole new series – Hacking the Blockchain! It is for all developers who are just starting developing on EOSIO. It is also for all EOS Blockchain enthusiasts who are not entirely technical but want to learn how the technology work.
In each article, we’re going to explore a specific part of the blockchain. We are starting with the EOS Communication Model, so hold on!
Today, we’re going to explore the EOS Communication Model. We’re going to take a deep dive into the different types of communication models and actions. For a dessert, we’ll see how to use it in our code with a demo where we’re going to manufacture robots.
But first, let’s start with what an EOS smart contract contains. That will set the basics.
EOS Smart Contract
The contracts in EOSIO can communicate with each other. It is achieved through the message-based communication architecture.
The EOS Communication Model is all about the way they communicate. There are two types of communication models: Inline Communication Model and Deferred Communication Model.
Inline Actions (Inline Communication Model)
The inline actions are part of the Inline Communication Model. If you understand them, you’ll comprehend the inline communications.
Let’s take a look at the following diagram:
A user executes an action (Action #1) from Smart Contract A. When the action starts executing it triggers two more actions — Action #1.1 from smart contract B and Action #1.2 from smart contract C. Everything is done within the current transaction.
An action performed within the current transaction and pertinent to the completion of it, it is called an inline action.
It’s important to remember that the inline actions are executed as part of the calling action. Therefore, they operate with the same scopes and authorities of the original transaction. It is a guarantee that they will be executed. If one of the actions fails, the whole transaction will fail.
So, you already know what an inline communication is.
Requesting the execution of action as part of the calling action is an example of inline communication.
Deferred Actions (Deferred Communication Model)
The second type is the deferred communication model. The deferred actions, which represent the model are quite interesting as they are not executed in the same transaction. Let’s take a look at the following diagram:
We have the same transaction workflow. The only difference here is that the second action executed from smart contract C is not an inline but deferred. The deferred actions are scheduled to run in the future.
Deferred actions get scheduled to run, at best, at a later time, at the producer’s discretion. There is no guarantee that a deferred action will be executed.
Even that they are not part of the same transaction, they carry the authority of the contract that sends them.
Deferred communication conceptually takes the form of action notifications sent to a peer transaction.
Transaction vs Action
Before continuing with the demo, let’s check something interesting.
In EOSIO there is a difference between a transaction and an action. The action represents a single operation, whereas a transaction is a collection of 1 or more actions.
A transaction can contain N actions. However, every transaction must execute in 30ms or less. If the transaction contains several actions, and the sum of these actions is greater than 30ms, the entire transaction will fail.
We’re going to manufacturing robots. You can find the project with all the smart contracts and the code which is part of the demo in our GitHub.
As a company creating the robots of the future, we want everything to be perfect. When a new robot is built, it should be sent for sale, and a message on the terminal should be printed. To achieve this three operations, we’re going to use inline actions.
Take a look at the following snippet.
First, we’re starting with creating a new robot. When the operation is completed, it comes the first inline action. We want to send the robot for sale, so we request the action forsale from the RobotMarketplace smart contract.
Take note here that when we are asking smart contract A to execute an action from smart contract B, the appropriate permissions should be added first. We’ll cover that in the next part, for now, be sure to follow the guides in the README.md
Once the first inline action is completed, the second one takes place. This time we request the printmessage from the Messenger smart contract. Again the appropriate permissions should be added.
In both cases, when we execute the create action through the terminal we have received notification that the actions are completed (or failed).
Let’s change printmessage action from inline to deferred. For this purpose, we need to use the transaction.hpp header from EOSIO.
To create a deferred transaction, we first declare a variable tx from type transaction. Then we add a new action to its collection of actions. We have the option to set a delay. If it’s 0, the deferred transaction will proceed immediately after the calling one.
When all is set up we simply call the send method.
However, it is not guaranteed that the deferred transaction will be executed. Furthermore, we don’t receive any notification about its success or failure like in the inline actions.
As you can see 12 seconds later the deferred transaction is executed.
To summarize — they are two types of communications models in EOS — Inline & Deferred. The actions used during the inline communications are called inline actions and deferred when are used in deferred communications.
If you have any questions, comment below. We’ll be more than happy to assist.
Also, don’t forget to subscribe to our monthly Newsletter. Just scan the QR code. We have prepared some awesome things for you!