EOS Smart Contract Development (Part — 3): Understanding fundamental concepts for writing dApps on EOS.
Article written by quillhash.com and brought to you by EOS GO
Upon observing popular dApps tracking websites, a potential EOS application developer might become attracted to the ever increasing dApps and transaction rates on EOS, and wonder if s(he) should start learning development of smart contracts over it. However upon starting research, they quickly become lost due to lack of quality resources with depth, confusing documentation and a general lack of context around smart contracts development. This leaves the developers with no choice, but to invest a lot of time in research, which might even be not possible for busy developers. Through these ongoing series of articles, we intend to make this process smooth, so that companies and application developers can leverage EOS for developing innovative decentralized applications.
In this article, we intend to give a high level overview of essential concepts like development ecosystem, basic structure of the contract, various types and modules available as a part of contract development (EOS CDT) and pointers to various resources for further research.
How to use this article
This article should be seen as an informal thread that ties various important concepts together, and touches on various aspects of EOS development. Since discussing all concepts in technical depth is out of scope for a single article, we encourage readers to research further with the pointers that we will be providing throughout the text. Further, best use of this series could be made by reading all it’s articles in order. We will bring all the discussed concepts into practice in future articles in this series with hands on development.
Before reading this, we recommend reading our first article to get a sense of the architecture of EOS compared and contrasted with Ethereum. So let’s get started!
Quick Architecture Overview
EOSIO provides a decentralized platform with characteristics like an operating system, that uses blockchain to maintain a distributed, trustless ledger of events and transactions happening on this platform. Deciding who creates new blocks (consensus) is achieved using delegated proof-of-stake, which involves staking tokens to get the right for voting for Block Producers, which are full nodes that adds new blocks to the blockchain. Suspecting any malicious activity, voters can remove block producers and vote for new ones. At a given time, only 21 block producers create new blocks, hence the transaction speed becomes very fast due to less number of verifications like proof-of-work based consensus algorithms.
EOSIO enables creation of smart contracts, whose execution and resource consumption is handled just like a typical application running on an OS. Smart contracts are written in C++ and converted to web assembly.
Computation volume and speed is described as bandwidth and CPU resources, and storage of persistent information is described as RAM. Since the requirement for CPU and bandwidth is transient, as it will be required only till the execution of some smart contract action, these resources are obtained by staking tokens for some amount of time (3 days). This ensures that the account gets minimum amount of these resources proportional to the staked tokens, and can get more if some of these resources are free (just like network bandwidth for an internet connection).
RAM however, being a persistent resource, needs to be purchased depending upon the need beforehand. RAM conventionally represents volatile memory, but in EOS context, it means the persistent memory for the smart contracts. RAM prices are volatile and are determined based on demand and supply according to Bancors algorithm by the system. Measures are being built into the the system to prevent hoarding and speculative trading on RAM, for it being a relatively rare resource.
It must be noted that this persistent information is not stored on the blockchain. Blockchain is only used to record transactions and events that points to the change in the persistent information of smart contracts. Now that we have a general idea about EOSIO architecture, let’s move on to development ecosystem.
Development Ecosystem
Any kind of smart contract development will need a local testing node, some way to communicate with the local node, a way to manage wallet/keys for accounts, setting up of IDE/code editor and compiler/converter that will convert smart contract to the executable form, a robust testing framework that can prepare a fresh state for the local node to test on, availability of a gui tool to help interact with the deployed contracts on public test networks or main networks. Let us discuss each of them with respect to EOS.
Nodeos is the core EOSIO node daemon that can be configured with plugins to run a node. It will act as a local node which can be used for development and testing purposes, although it can be configured to use as a full node and even for block production.
Cleos is the command line interface to interact with the local node daemon, and can be configured to interact with a remote node too. It is used to issue commands relating to managing wallet, configuring node and issuing transactions to smart contracts.
Keosd is the component that securely stores EOSIO keys in wallets.
Eosio.cdt is the contract development toolkit that exposes various libraries and programming constructs to aid with smart contract development. These constructs provide programmatic interface to deal with various components of EOS. Eosio.cdt also consists of eosio-cpp, which is module responsible for converting contracts written in C++ to wasm (web assembly). It also generates an ABI for the contract, which is a JSON file specifying types and actions supported by the contract. It is used to integrate smart contracts functionality with client end applications.
EOSFactory is a python based testing framework developed by Tokenika which we have found to be very robust for dapp development and testing. It provides a simple python based interface to interact with smart contacts and supports easy setting up of fresh node instances for testing. It even supports for deploying and managing contracts on public test and main networks.
Scatter is a gui application that makes it easy to connect with EOS networks and securely manage assets, and is analogous to Metamask in Ethereum. It is available as a desktop application for all major platforms.
Since the contracts are written in C++, any of the popular IDEs can be used to write smart contracts. However, EOSFactory provides some support for VS Code, and at Quillhash we use VS Code for smart contract development, although it is more a matter of personal choice.
Managing roles and permissions in EOS
Native support for managing roles and permissions in EOS makes it very powerful in enforcing access control and authority inside smart contracts. EOS consists of two persissions out of box for every EOS account. They are active and owner permissions. Owner permission is associated with the admin level operations related to the account and is the parent permission for the ‘Active’ permission. Active permission is used for common operations, like executing a smart contracts actions. Examples are token transfers, buying RAM, etc. Apart from them, we can also create new permissions, which can be enforced by handling them appropriately inside the smart contract.
Another interesting permission is the eosio.code permission. This permission is used by the smart contract if we want it to communicate with other contracts programmatically. This permission must be given by the account hosting the smart contract to itself by adding it to active permissions.
Basic overview of an EOS smart contract
Smart contract is the software that runs on the EOSIO nodes, whose persistent data is stored on the node’s RAM and events of actions are stored and synced on the blockchain. An EOS smart contract exposes executable ‘Actions’, which are functions that perform some contract specific operations, subject to constraints and authorities of the account calling that action. Considering this, we can visualize contract as a combination of 3 facets working together.
First, we have functions definitions that specify the logic of the action. Second, we have multi-index tables, which provide us with interface to connect with persistent storage (RAM). Third, we have the ‘dispatcher’, which acts as the action handler, and maps the incoming request to the contract to the action that is being requested. These three components are the basic ‘bare bones’ that every contract possess.
Each contract is defined as a class that inherits from eosio::contract class. Various variables defining state of the contract can be specified as private members of the class. Member functions of these classes can be specified as the ‘Actions’. EOSIO provides various attributes that are used by the eosio-cpp to generate web assembly bytecode along with ABI. Thus, along with various types and data structures provided by the eosio.cdt libraries, we are able to write smart contracts on EOS. Smart contracts on EOS can handle notifications from other contracts, and can even call the actions of other contracts, provided they have been given necessary permissions (eosio.code permission).
A fresh instance of the contract is created every time we call an action on the contract, which is destroyed upon execution of the action. Thus any information that represents the state of the contract must be loaded when the contract starts (in the constructor) and saved before or during destruction (inside destructors or in the called action’s body). It must be noted that only one smart contract can be associated with a single account, and we can change/upgrade smart contract code on the same account.
Conclusion
In this article, we have discussed about essential concepts that will come up frequently while developing dapps on EOS. Now that we have a high level overview of the ecosystem and architecture of EOS, we are ready to dive deeper into technical and coding aspects of the contract and build our own dapps. In next article, we will analyze the standard eosio.token contract in great detail, so as to understand all nitty gritty details that goes into building smart contracts. We will also develop a basic crowdsale application and decentralized game contract in future articles.
I hope that this article has been useful for the new EOS developers. Thanks for reading!
Stay tuned for the next part…
~~Part 2 — EOS Smart Contracts Audit checklist to Keep In mind Before Development~~
~~Part 3- Understanding fundamental concepts for writing dApps on EOS.~~
Part 4- Analysing EOS standard token contract .
Part 5- Develop a basic crowd sale application with EOS .
Part 6- EOS for high performance dApps — Games on EOS!
Disclaimer: The views expressed by the author above do not necessarily represent the views of EOS GO. EOS GO is a community where EOS GO Blog being a platform for authors to express their diverse ideas and perspectives. To learn more about EOS GO and EOS, please join us on our social medias.
EOS GO Telegram - EOS News Channel - Twitter
EOS GO is funded by EOS ASIA and powered by YOU. Join the community and begin contributing to the movement by adding eos go to your name and joining the EOS GO telegram group.