Blockchain Developer Path from ground zero #2

— Part 2

Hello little Padawan!

This is the second part of the blockchain developer path that started in my last post.

Now that you have acquired a basic but solid knowledge of how Solidity works and the power of Smart Contracts, it is time to take it to the next level.

Essential and to keep in mind from now on: Advancing in blockchain development means going deep down; Unlike many common languages, where they usually tend to go to more high-level topics and you do not keep in mind, for instance, memory resources, here, advancing in your seniority means knowing more and more how things work in detail and how to work with them securely and efficiently.

Advanced Solidity

First, we will add a new and probably unknown data type to your path, the bytes type

• Official doc
• Encode and decode functions (It uses an old version of Solidity though it is recommendable anyway)

Learning how to work with bytes is highly important because most of the time the information is saved and encoded as a hash. It will be handy when we talk about more complex data structures that have been built in the ecosystem (like Merkle proofs for instance)

Then, if you recall, the last post mentioned some features that Soldity has that are common to other languages like inheritance, libraries, and function overriding.

Let´s now add some not so common, but highly important features Solidity has, like the ability to call other contract functions from within your sc. It can be accomplished in two ways:

• Call (Not recommended due to being a low-level call)
• Delegate Call: This article is one of the best resources you could find to understand a complex topic for every newcomer to blockchain dev. It is extremely and thoroughly well documented and explained. It is a must-read.

The next part right now should talk about the concept we stated in our last article: “Smart Contracts are immutable”. However, you must take your time to learn how delegate calls and internal storage work when making a call from another contract. We will come back to it in our next chapter.

Solidity Patterns

Code patterns exist in every language and Solidity is not an exception. Here we provide some of them:

1. Check Effects Interactions Pattern

This is the most important one and you should always follow it. It will always help you to avoid reentrancy problems. It means that while designing a function in Solidity, any state modification in the function must happen before an external call is made.

• Check: Implement necessary checks or input validations to ensure that the arguments passed to a function are the right ones.
• Effects: Now that step one is done, you will modify the state variables of your contract.
• Interactions: Last and only when steps one and two are done, you should make any external call that your function needs.

2. Factory Pattern

This is a common pattern in almost any language. However, why would you want to use it in Solidity?

• Creation of multiple instances of the same contract and you want to manage and keep track of them.
• It is cheaper than deploying each contract individually, thus, it saves gas.
• Security: Because the contract definition is kept on an on-chain function, child smart contracts are generated by calling a function defined in the factory contract, and thus, there´s no possibility of manipulation on the creation of the children's contracts.

Example:

contract FactoryPattern {
      Child[] public children;

      function createChild(uint data){
         Child child = new Child(data);
         children.push(child);
      }
}

3. Emergency stop Pattern

A useful pattern to stop the execution of certain sensitive functions.

Reasons to use it:

• Security
• Stop possible critical bugs in a function
• To halt the execution of a contract for a while (similar to a pause button)

It is accomplished using two really simple modifiers that you could add to your functions:

... 

bool stopExecution = false; 

modifier stopInEmergeny {
  require(!stopExecution);
  _;
}

modifier enableInEmergeny {
  require(stopExecution);
  _;
}

This way you could have functions that will stop its execution when the stopExectuion boolean is set to true, and you could have another bunch of functions that will only be able to run only when the condition is also true.

“Do not reinvent the wheel”

This famous phrase also applies here in a young development world.
Lucky for many Solidity developers, there is a famous company that provides us with secure and thoroughly well-tested Smart Contracts we could use in our projects; Its name is OpenZeppelin and their contracts can be found here.
They have been developing standard contracts we could use to make our development process easier, and with the confidence we are not making any mistakes by importing them. They have, for instance, the emergency stop pattern implemented as the Pausable contract.

It is not a recommendation to use them, it is rather an order. I have been developing blockchain projects for more than six years in a row, and I have scarcely found a project that did not make use of OpenZeppelin contracts.

However, it is an excellent exercise to go through its contracts and how they were developed. I am sure you will find out a lot of things you might have missed out at this point, and it will probably be the first productive Solidity code you might be looking at.

Also, you might discover things called ERCs and EIPs… but those will come in the next article.

There is always more to come

That´s all for today. The next article will start with smart contracts immutability. Hope you are enjoying this path and starting to discover the power and the possibilities that come with blockchain development.

Goodbye, not so little Padawan!