Things to consider before coding in solidity. The concepts are important
Where are we in the development of blockchain applications? So far Ethereum is one of the most known blockchains and the one that makes more sense to study the design of blockchains. Yet, we still need to figure how we can implement these technologies in the daily basis of our solutions to avoid falling into creating ICOs that end up in scams or over hoped promises without understanding the technology at hand.
I have been trying to understand public and private blockchains in the application layer and the communication layer since 2 years ago and so far is really challenging changing your mindset in terms of system design.
I am writing to clarify some of the concepts we tend to forget when we start developing in solidity. I suffered the same problem that most software developers experience, that is to start coding as if it was just another web framework, its not, its not that simple. We must consider the implications of the back end systems to even start wondering about the GUI. There is no sense of building beautiful GUIs with React, Angular, or any web framework if the backend systems are still behaving as centralized services or ad hoc systems.
I had the same problem with Hyperledger Composer. It gives you all the SDKs you like to develop REST services without worrying about the architecture of the peers that run under the network. The default configurations give you a sense of safety, but they trap you in a black box, where you don't really understand what is going on in the underlying network. That was my mistake, I hope you guys don’t fall in the same.
Blockchain supposes to be a decentralized network, either private or public. Hyperledger Composer is useful if you want a centralized network. You can still set it up with several nodes, but the early adopters will stop educating themselves after they code an application with its default configurations. Therefore, Hyperledger Composer is too abstract that we lose the sense of what the decentralized solutions are. Unless you really wanna risk the customization, I suggest focussing instead on the understanding of Hyperledger Fabric, Ethereum or any other open blockchain project at the Machine Layer.
Anyway, the purpose of this post is to share some of the concepts I am learning at the core of Ethereum Technology, to not replicate the same mistake I did with Hyperledger Composer. I want to understand it first, rather than coding it desperately. Start with the official documentation or in my case, I read the book “Blockchain: A Practical Guide to Develop Business, Law and Technology Solutions” by Joseph J. Bambara and Paul R.Allen.
Therefore, with the concepts of the book, I mention some of the core principles the technology holds to decentralized solutions by summarizing what Bambara and Allen have written:
- Ethereum Accounts Properties
Each account within Ethereum has 20 bytes of address, which is a digital object with 4 main attributes:
Nonce: A counter that is used to ensure that each transaction is processed once and once only.
Ether Balance: The amount of Ether
Contract Code: Container for the Logic(Solidity)
Storage: Empty by default, its a space for storing data on the account.
2. External Owned Accounts(EOA) and Contract Accounts
Both accounts are indexed by the address. Although, the main difference is that EOAs have no Ether balance, no logic, and are controlled by private keys. Meanwhile, Contract Accounts have Ether but are controlled by Solidity logic, can write and read to the internal storage, and send additional messages or create other contracts(In solidity a contract is such as a Bean in Java).
Important: If we leave the system just with EOAs, the system becomes such as another altcoin of Bitcoin, losing the value of the programmable logic.
3. Ether incentives, Gas Price and Gas Limit: Ether is an incentive for the miners but also to develop quality code since the inefficient code will cost more Ether. I recommend using Remix for testing your contracts first. Therefore you can set it up in order to save the processes that cost more Ether. The cost of the execution of the contracts is determined by the multiplication between the Gas Limit(approximate calculation of costs-computational resources costs are called opcodes/instructions), and the Gas Price(In Ether). Usually, is recommended that designers should analyze the boundaries and the current price of transactions here. Additionally, the Gas Limit helps the user know how much is willing to spend in the transaction cost. The system sets up a limit that is allowed to take from the user, preventing Denial of Service(DoS) attacks. If you want to know more about the gas relationships, there is useful information in this StackOverflow help.
Ultimately, Ether usually is issued at a rate of 5 Eth per block on a block time target of 12 seconds(the completion of a transaction timeframe).
3. Contract Best Practices
Lets first start by acknowledging that Solidity contracts have some similarities with Object-Oriented Programming Languages such as Java. I will show this following contract with its main functionalities.
As you can see, I added several getters and setters as in any Java Bean. We have different types of variables where you can set the new values. Additionally, mapping a struct is the way to create Lists. In the same way, we can call any item of the list of Structs by defining the id of the item. Also, there are event logs that can be used for listening to specific actions in the blockchain or just as in my case to follow the code debugging. There is a good tutorial of arrays and structs that I recommend here. Ultimately, since Ethereum Virtual Machine tries to save processing its possible that you guys will soon find the STACK TOO BIG ERROR when you exceed the number of declared variables in a function. You should check this blog to read more about this. We see in the following sections that you can call these functions from other contracts located in other addresses.
4. Interaction with other Contracts
When I started to program in Solidity I realized the obstacles coming from an open environment such as javascript where you can easily interact with other files and APIs by simply importing them. This is not the case for Solidity. In Ethereum, the contracts are stored in different Contract Account Addresses. Therefore, there are some considerations when we want to call functions or variables from other contracts.
In some point, I wanted to call a function that was allocated to other contracts. Using Remix I tried to just import the other contract and have access to its variables and functions just by creating an instance of the contract, such as you do with Objects in Java. The following won't work.
When we create a new instance of the Contract in another file just by importing it, we are just referring to a piece of code but nothing else. We can create a temporary instance that can be called, for setting and getting values. Although, we cannot get any persisted data from that contract since we must specify the address of the contract we are calling to. The following code reflects the best way to find a contract and interact with its methods.
This method is called delegated calls by creating proxies with the addresses, by pointing the contract address, we can interact with it without any problem. (I just was running with some problems with the setter functions, I will have to figure this out still). Also, consider that this will also add the gas cost. If you want more information about this issue you can check this blog.
4. Infura and Web3
I just heard about INFURA since I read this book but it makes sense how we can connect with Ethereum clients without having to download and maintain Ethereum nodes with Frameworks such as Web3. INFURA is a scalable, standards-based, globally distributed cluster and API endpoint for Ethereum, IPFS(Interplanetary File System), and other emerging decentralization infrastructures(Bamara and Allen). It is mainly focused on Transport Layer Security. The following picture can give more insights into the architecture.
Although, I am still trying to understand the use of these APIs at the level of data transportation. If you want more information visit the official page of INFURA.
Ultimately, I want to show some basic code to connect with an Ethereum client in localhost. It can be Ganache Testing network or Parity, you decide. In the following code, we are using truffle-contract for deploying and interacting with our contracts. We deployed the contract with truffle compile and then truffle migrate. Therefore we got the artifact and we can create the contractABI with truffle-contract. Ultimately, we can access the contract instance and interact with it.
6. Events Handling and third parties
Events are not just for logging the outputs, also we use them for letting other accounts in applications know that certain conditions were met. For example, if an agreement in a transaction needs the signature of two users, if one user proposed the agreement, then the other user must sign. Therefore, third-party software needs to listen to those events in the blockchain and execute some UI or backend actions. From the book I read, specifically in NodeJs we can use Web3 to accomplish this.
Each library needs a different implementation to listen for the events. Right now I am just exposing the case for NodeJs. Let me know if you find other ways because there are still not so many examples of these functionalities.
7. Immutability of Deployed Contracts
We must be careful when we deploy the contracts. Once is deployed there is no way of revert it in the same EOA account. If you want to modify the contract the only way to do it is to deploy a contract in another account with the new updates or call a proxy contract with new methods. Additionally, if the contract address changed due to a new version of the contract, we must point to the new address if we want to use delegated calls(what I just explained in the contract interaction).
That is all for now. If you like this post please share it or like it, it really helps me, let's keep building this new future with blockchain!!!
REFERENCES:
Bambara, Joseph J, Allen, Paul R. “Blockchain: a Practical Guide to Developing Business, Law, and Technology Solutions”. Mc Graw Hill, 2018
Ethereum Docs, taken from http://www.ethdocs.org/en/latest/
…
If you want to know more about me and my projects follow me in my social media:
