Blockchain - Understanding Smart Contracts

When Bitcoin was released in 2009 [1] everybody was mesmerized with the blockchain. It was an infinite and immutable ledger capable of recording and validating thousands of currency transactions without the risk of being violated, a truly decentralized broker available to anyone in the world to use.

However, soon enough people started to use Bitcoin transactions for other purposes rather than the originally intended ones. For example, deals and small agreements between parties were being stored in the space once designed to hold transaction metadata. Those "contract" transactions had small financial value, but were big in data, making the blocks less financially attractive to mine.

Proposals were made to change the blockchain, but Bitcoin was designed to be harder to change, and a core group of the community was not convinced that the solo purpose of storing currency transactions should get deviated to something else.

With that in mind, a group led by Vitalik Buterin started the development of a new blockchain, capable of recording currency transactions, but also designed to allow any other type of behavior the human mind could conceive, a Turing complete machine in which all its inputs and outputs are stored in the blockchain, a decentralized computer impossible to hack and always available. 

Welcome to Ethereum and the world of Smart Contracts.

What Are Smart Contracts?

Similar to a common API, a smart contract is a piece of code that exposes some public methods that anyone (including other contracts) can invoke [2]. Also, just as any other program, a smart contract can have private methods, a constructor, memory variables, etc. However, instead of being deployed in an on-premises server or in a cloud-based service, a smart contract is deployed in the blockchain using a deploy transaction. 

After a smart contract is deployed on the blockchain, it can never be altered or removed (not even by its owner): it will remain available, forever. It's possible to deploy new versions, but the old ones will still be valid. This is different from common deployment processes and can be beautiful and scary at the same time.

Given that smart contracts are immutable and publicly available to anyone to inspect and use, they solve the problem of a trustworthy third party. For instance, let's suppose someone deploys a contract to allow funds to be donated to a specific charity organization. In this contract, anyone would be able to call the method "deposit," but only the charity organization (owner of the wallet) would be able to call the method "withdraw."

Since every execution of a contract method is a transaction stored in the blockchain, smart contracts provide, by definition, a public record of all inputs and outputs. In addition, it would be necessary to take down the entire blockchain to prevent a contract method execution.

What Are Decentralized Applications?

As described in the previous section, contracts are immutable code running in the blockchain. However, not everything is possible, or desirable, to be in the scope of the blockchain. For instance, it’s not possible to have mobile apps or web pages running on it. Also, due to costs and performance implications, it wouldn’t be smart to have all the backend processes of an application running in the blockchain.

A normal approach is to have everything non-critical coded and deployed using standard technology, such as a Node application running on a cloud provider, and only the vital core functionality is done using smart contracts [3]. For example, an application to allow people to donate money to charity organizations would have only the core feature – transfer funds – deployed in the blockchain.

These applications that combine both common and blockchain approaches are named "Decentralized Apps" (or "dApps").  Their name is derived from the fact that the heart of the application lives in a decentralized infrastructure, and even if due to any external factor the rest of the code is taken down, anyone with knowledge about it would still be able to use the contract to perform the critical operations. Since contracts are also meant to be public, anyone could in theory build another layer around it and make it available again.

It's commonly argued that only a few hundred well-designed and implemented contracts are necessary to support millions of different dApps. For instance, it’s not necessary to create a new contract every time a peer-to-peer financial transaction is needed. That's why the Ethereum community urges the majority of dApps developers to focus on learning and using currently available contracts instead of trying to reinvent the wheel.

Disadvantages of Smart Contracts

At this point, you're probably mesmerized by the advantages and the infinite possibilities allowed by contracts. However, not everything is so nice. 

The first big issue with smart contracts is scale. In fact, this is a well know problem of any "proof of work" based blockchain. This article will not get into the details of it, but it's important to know that in this paradigm there's a significant scale problem, where only a couple hundred transactions can be handled every minute. In critical financial applications, we can expect thousands of transactions every second. This gives a good idea of the magnitude difference we are discussing here. It's true that recently Ethereum switched to a new paradigm called "proof of stake", and although it’s expected that this new form of validation will increase the network capabilities up to 100,000 transactions per second [4], it is still soon to know for sure if this plan will succeed or not.

The second biggest issue is in part derived from the first one. Due to the financial costs involved in becoming a blockchain validator and the current capacity of the network, each transaction has an execution fee, known as "gas price", that can be prohibitive for most applications. As of today, the cost per transaction on the Ethereum blockchain is at 0.55 US dollars and it's important to notice that this is a variable rate correlated to the usage of the network. Just for comparison, Amazon charges 0.20 US cents for every 1 million AWS Lambda executions (plus other costs) [5].

Common Types of Contracts

Now that we established what contracts are, how they can be combined with standard technology to provide decentralized applications, and what are the caveats of using contracts, let's discuss a little about the two of the most common contracts in use nowadays.

As you are probably anticipating at this moment, contracts are interesting tools to handle problems related to goods ownership, funds, and value transfer. These are typical situations where a contract can replace a fiduciary agent or a trustworthy third party.

To resolve a vast majority of problems related to similar situations it's important to be familiarized with the concept of fungibility, which can also be read as interchangeability. Something that's fungible is a good or asset that can be exchanged with another asset of the same class without being noticeable. A good example is dollar bills, stocks, or commodities like corn or oil. On the other hand, un-fungible things are unique, such as a house or a piece of art [6].

With those two concepts in mind, the Ethereum community created two smart contract standards [7]: the ER-20 and the ER-721 to handle fungible and non-fungible tokens, respectively. So, the next time you expend thousands of dollars in a .jpg on an NFT website or lose money trading cryptocurrency, know that this is only possible because of the ER-20 and ER-721 contracts. 

Key Takeaways

• The Bitcoin blockchain is one of the most revolutionary ideas in computing systems in recent years, however, it still has a limited scope of action.
• Through smart contracts, the Ethereum blockchain provides the capability of executing any general-purpose algorithm (Turing complete), expanding its own possibilities to virtually any problem mankind can describe.
•   With smart contracts in combination with standard web technology, anyone is able to develop decentralized applications with rich user interfaces, thus providing an easy way for non-technical users to interact with the blockchain.
  •    Running smart contracts can be expensive and sometimes performance prohibitive, thus only the necessary code should be executed on the chain. It is always important to consider whether smart contracts are a good approach to solving a particular problem. 
  •    Fiduciary problems are usually good to use cases for contracts, and the two most used contract types to solve these problems were already defined in the ER-20 and ER-721 specifications.
  
  

References

[1] Bitcoin. https://en.bitcoin.it/wiki/Bitcoin

[2] Introduction to smart contracts. https://ethereum.org/en/smart-contracts/ 

[3] Introduction to dApps. https://ethereum.org/en/developers/docs/dapps/

[4] The Merge. https://ethereum.org/en/upgrades/merge/#what-is-the-merge

[5] AWS Lambda. https://aws.amazon.com/pt/lambda/pricing/

[6] A Quick Guide To Fungible Vs. Non-Fungible Tokens. https://www.blockchain-council.org/blockchain/a-quick-guide-to-fungible-vs-non-fungible-tokens/

[7] Token Standards. https://ethereum.org/en/developers/docs/standards/tokens/

Acknowledgment

This piece was written by Pedro Artiga – Senior Systems Developer and João Longo – Systems Architect and Innovation Leader at Encora’s Engineering Technology Practices group. Thanks to Hugo Gonçalves and João Caleffi for reviews and insights.

About Encora

Fast-growing tech companies partner with Encora to outsource product development and drive growth. Contact us to learn more about our software engineering capabilities.