Adding contracts - and “Ethereum compatible” contracts specifically - to the Polkadot Hub has some far reaching implications. With this post I’d like to investigate those a bit closer, hoping to highlight some important aspects to our builders in the ecosystem.
UNIX, POSIX and Blockchains
We can learn valuable lessons if we think about Polkadot Hub and in general Blockchains as platforms for decentralized application like we think about operating systems as platform powering applications. Operating systems are not exactly a new concept and arguably have suffered from similar problems.
In that sense, contracts are user space (decentralized) applications. They can be installed (instantiated, deployed) and used (called) by anyone, permissionless. Interactions with the host environment however happens via a syscall interface or a special contract address (so called precompiles). Like traditional computer programs they can also interact with each other.
The analogy isn’t perfect but with how the blockchain landscape currently unfolds I see a lot of similarities with operating systems.
Unix eventually gained a lot of popularity but since there was not just the UNIX operating system but rather UNIX was (is) a diverse family of operating systems. This caused friction for Application developers. The Portable Operating System Interface (..) is a family of standards (..) for maintaining compatibility between operating systems. POSIX is a collection of interfaces and tools on which applications more or less can rely on being available and share common behavior ond POSIX compliant operating systems.
The analogy to today’s blockchain landscape seems fairly obvious. Traditional operating systems provide the platform powering applications. Blockchains provide the platform for decentralized applications. Likewise there are different ways to approach blockchains and many of them (probably a majority?) in the Ethereum familiy. The compatibility degree of any Ethereum compatible blockchain with the Ethereum mainnet itself varies highly. Not all chains in that family support all transaction types, implement all EIPs, or provide an EVM at all. Some provide features unique to them. Not all Ethereum tooling, wallets and block explorers support all Ethereum compatible blockchains.
Ethereum compatibility
With the addition of PolkaVM contracts, Polkadot is no longer not only a platform framework but also platform itself (Polkadot Hub). Thanks to the PVM JIT compiler, our applications can execute around as fast as native code, something so far unseen in major blockchain networks. And thanks to PVM being based on a non domain specific ISA (RISC-V), dApps can be written in major programming languages. Combined with Polkadots unique features like OpenGOV, parachains and XCM, we should be set up for success.
Now, while, this is a strong foundation, arguably it would be wise to also join a family of blockchains. Be part of some family, profit from and contribute to their network effect, instead of fighting against every other blockchain family ecosystem out there. This very effectively short cuts a massive amount of tech and business development efforts.
Whenever I hear or read that Polkadot Hub is getting Ethereum or EVM compatible contracts, I think of it as we would finally join the Ethereum family of blockchains. POSIX of course is much more well defined though and I am not aware that a “POSIX for Ethereum compatible chains” standard actually exists. I also would not be surprised if something like this will emerge in the future: We already see a lot of friction for Solidity dApp developers in the ecosystem. Having a well defined standard that dApps can rely on (and request from chains interested in deploying them) would certainly help greatly in removing friction.
How I don’t think about EVM compatibility - but what a lot of people seem to think - is that we are aiming to become another Ethereum scaling solution (EVM equivalent). Achieving the highest degree of compatibility possible is not our main goal here (achieving the highest degree of Ethereum compatibility possible while still delivering the breakthroughs of PVM is a goal). In fact, with pallet-revive on Asset Hub, Ethereum compatibility is entirely opt-in. Although I would not generally recommend it, you can just deploy a dApp with a custom interface, and rely entirely on Substrate transactions.
For most existing dApps and dApp developers however, Polkadot Hub joining the Ethereum family of blockchains immediately decreases friction and increases the network effect (even if compatibilty is not 100%). This is the reason behind Ethereum compatibility. It is also a reason why not compatibility with something else or multiple things. Ethereum, as of currently, is the incumbent blockchain ecosystem.
Solidity ABI
A foreign function interface (FFI) is a mechanism by which a program written in one programming language can call routines or make use of services written or compiled in another one. Adding Ethereum compatibility, essentially joining the Ethereum family of blockchains, we declare Solidity ABI as our ABI for dApps. Just like on UNIX (like) operating system, the C ABI is the defacto FFI applications use. Solidity ABI is to Ethereum what the C ABI is to UNIX.
I think this is especially important for Polkadot. Unlike on many Ethereum blockchains where dApps are only written in Solidity and this is therefor implied. This is seems especially important for us since Polkadot itself is much more generic and language agnostic. Add to that, PolkaVM as a general purpose VM supports dApps written in all kinds of languages. Yet we want our dApps be compatible with each other regardless the language they were written, regardless whether underneath executes a precompile.
Therefor, I think that any dApp and broader, any code, that interfaces with contracts, should speak the Solidity ABI. dApps should expose external functions using the Solidity ABI regardless the language they are written in. Pallet authors should expose their interfaces via precompiles that understand the Solidity ABI. Everything else only creates unnecessary friction and is contraproductive for an Ethereum compatible blockchain.
WE DO NOT BREAK USERSPACE!
Linux, as a platform for Applications is kind enough trying it’s hardest to never break userspace. Polkadot Hub, as a platform for decentralized Applications, must be kind enough to never break contract space.
For blockchains this gets even more important than for traditional operating systems. WE DO NOT BREAK EXISTING CONTRACTS. It should be the last thing we ever do intentionally or willingly. Saying that people will be unhappy if their unstoppable dApp in fact may break any time an update is pushed and this is expected is an understatement.
In the revive pallet we make absolutely sure to never change or remove a syscall that was already deployed and marked stable. But for precompiles this is harder to track because we expect many pallets to expose new precompiles. I therefor want to bring it to the attention of pallet authors that they should carefully think about the APIs they are adding via precompiles and make absolutely sure to never ever break or remove any existing precompile functionality.
TL;DR
“Ethereum compatibility” does not mean “Ethereum equivalent”. web3 is way beyond the state where “Ethereum” or “EVM” are globally understood as single, well defined things. Trying to be as compatible to Etherum mainnet as possible doesn’t matter anymore. What matters is that we a) learn from similar platforms suffering similar problems (e.g. operating system families) and b) offer unique features setting us apart from direct competitors.
pallet authors: Please use Solidity ABI encoding, established ERC token standards, think carefully about what precompiles to add and how the interfaces look like, and please never break existing contracts.
dApp builders: If you are writing contracts in another language than Solidity, or creating new contract framework and languages, please use the Solidity ABI encoding scheme for any public interfaces.