In 2008, Bitcoin proved it was possible to securely and frictionlessly transact in a digital native currency. Using bitcoin’s scripting language, colored coins were an early attempt to create flexible asset issuance on a public blockchain. This approach, while perhaps in the right direction, struggled to mold the limited bitcoin scripting language for this purpose.
Ethereum followed and “flipped the script”. The team said, “we don’t want to create and decentralized one thing, we want to decentralize everything”. They thought it better to start with a Turing-complete language and a trusted execution environment. So far, the Ethereum Virtual Machine (EVM) and Solidity smart contracts have introduced experiments that include NFTs, decentralized finance, and DAOs.
Hedera, in a way, has taken the best of these approaches and, at the same time, made something entirely new. Dubbed Smart Contracts 2.0, I’m happy to celebrate their availability on the Hedera mainnet.
With the availability of Smart Contracts 2.0, the Hedera ecosystem is choosing to invest in the Ethereum Virtual Machine and Solidity. We're making contributions to the open source Hyperledger Besu project alongside companies like Consensys and Splunk.
Why should Hedera bet on the EVM?
According to Electric Capital’s well-researched open source web3 report, a developer’s entry-point to the space is the EVM 30% of the time. As a Turing-complete programming language, Solidity allows for developers to run through their own idea maze, dreaming up what’s possible.
I predict there will be a growing divide between EVM compatible chains and those with a custom implementation. If you’re a developer, will you want to spend time learning and implementing a language to support a singular chain’s smart contract language? Will you want to learn a less popular technology or the default standard backed by a vibrant community? The answers to these questions help create a flywheel in favor of the EVM.
Given more developers will be trying out EVM chains, like Ethereum, Hedera, and others, the EVM-compatible ecosystem will learn faster than its bespoke language counterparts. As successful experiments find their footing, it will be easier for these projects to support a multitude of chains that are EVM compatible or for that open source code to be forked and supported.
The equation is simple, really – as developers find what works it will attract more developers. This is achieved from a combination of hard and soft benefits within the EVM-compatible ecosystem:
Hard benefits - easy to repurpose EVM tooling, and redeploy on EVM-compatible network
Soft benefits - there will always be more tutorials, StackOverflow answers, and jobs available
With these compounding flywheel effects, we’ll all go further together. If you’re a developer, project, or enterprise looking to start your smart contract journey, consider the importance of the technology you’re selecting. Whether you’re deploying your own contracts or want to tap into others’, EVM compatibility should be at the top of your priority list for choosing a network that will support you both today and into the future.
Not only is Hedera working to better support Solidity smart contracts, but doing so in a way that works for enterprise workloads and meets dapp developer needs. This is done with a combination of performance improvements, design decisions, and developer experience enhancements.
By using hashgraph, smart contract developers can now deliver a better user experience via:
Low, predictable gas fees
Transaction finality in seconds
Carbon-negative operations
Secure, leaderless architecture
In particular, for smart contract performance, we've improved the Hedera network EVM's processing speed. Achieving the equivalent of what Ethereum targets for an entire block, typically in 13 seconds, in a single second. We'll continue to make advancements here.
Since the Hedera Token Service came online a year ago we've seen everything from stablecoin proof of concepts from enterprises, creator tokens on Calaxy, to creative NFT art and communities. Hedera Token Service tokens are great for their performance but can be limited in their programmability.
When we thought about smart contracts, we wanted to close this gap while allowing developers to continue building with the growing Hedera Token Service ecosystem. For use cases that require advanced programmability, Smart Contracts 2.0 are ready for you.
With the completion of HIP-206, we can make HTS calls from a smart contract. The Hedera services Solidity libraries currently support using HTS to:
Soon, we'll support the complete set of calls. This enables the flexibility to best support your use case. As your application requires more programmability, you’ll want to use a smart contract. Let me show you what I mean, in three simple examples:
Do you need a smart contract for sending payment for a good or service? Likely not — Hedera Token Service can be used to transfer our fictitious PAUL token with transfers costing $0.001, always.
Do you need a smart contract to make a simple exchange? Projects like HashPack are using scheduled transactions to allow each participant to sign a transaction between unknown parties.
Do you need a smart contract for a decentralized finance collateralized loan? Yes, use a smart contract to avoid counterparty risk and reliance on a centralized intermediary.
We’re starting to see this decision tree in action and the community to make strides in creating standards. If you’re looking to port existing ERC-based token designs and are curious how they map to HTS tokens, take a look at mapping Hedera Token Service Standards to ERC20, ERC721, & ERC1155.
We’re on the cusp of a rapid experimentation phase on Hedera. A network is only as good as the sum of its parts. While there are a number of enterprises and existing projects looking to deploy smart contracts on Hedera, I am more eager to see new innovations.
The Hedera community has plenty of work ahead to make Hedera the best smart contract platform. A few of these have been captured in Hedera Improvement Proposals (HIP) already; a few of my favorites being:
(HIP-179) External transaction signing
(HIP-329) Support CREATE2 opcode
(HIP-218) Smart Contract interactions with Hedera Token Accounts
For those in need of support for launching, scaling, or bringing your smart contract project to Hedera we have a few resources:
HBAR Foundation
Smart contract concepts
Getting started tutorials