PoCo Series #8 — Future-proofing iExec - Smart Contract Interoperability and Modularity
Decentralization. Like many projects in the space, decentralization is a key element of the iExec platform. Without decentralization, we wouldn't have an open (and unstoppable) market, that people know they can rely on. The importance of the blockchain here cannot be understated. It provides a reference point, used for access control, consensus, and micro-transactions between parties. These aspects are covered in previous articles in this series — click here to check back in on them. The point being is that none of this would be possible without smart contracts.
💡 Want to learn more about iExec? Check out iExec Academy!
iExec Academy aggregates all content related to the project. You’ll find articles, tech documentation, videos, interactive demos, and much more! Whether you are a beginner or an expert, a developer or crypto-enthusiast, you’ll find what you are looking for on iExec Academy!
Where is iExec at with smart contract development?
iExec V4, the fourth version was released on schedule on December 13th 2019. We are now aiming for the release of iExec V5 within the next few months. This milestone would mean that we would have delivered almost all technical features originally outlined in the iExec whitepaper, but nowhere near the end of developments. iExec V5 will focus on optimizing our existing infrastructure, with targeted business development to maximize adoption of iExec.
Concerning the latest release, some may have noticed that, unlike version 1, 2 and 3 of iExec, version 4 did not include any specific smart contract updates. In fact, the platform is still running on the smart contracts from version 3.
So, why didn’t we make any changes? The first thing to keep in mind is that version 3 was a major update, which was designed with many built-in features that were looking far beyond what we could implement on both the front-end and back-end in just 6 months. We still have many features in mind that can improve the user experience and be built on top of iExec V3’s smart contracts. In this context, there was no need to rush an update for version 4, and we were thus able to focus on the even longer-term with a version that would prepare the platform for the post-whitepaper iExec.
The main focus for iExec version 5 is not new protocol features (as mentioned, there are still features built into version 3 that are not yet exploited by the platform) but rather, the focus will be more on interoperability and modularity.
Improved Interoperability?
We believe interoperability is essential to adoption. This is clear within the Defi ecosystem. Here dapps are assembled like lego bricks to build big powerful stacks out of simple, well designed, components. Unlike cloud users, that will use iExec through web2 interfaces and APIs, blockchain users, such as smart contracts wanting to access the off-chain world through iExec, need a standardized interface to connect to. A lot can be learned from observing what is being built in the ethereum community, which is why iExec spends a lot of time evaluating the relevance of the latest developments for our own product.
Here is a list of evolutions that will improve the potential interactions between iExec and other applications in the ethereum ecosystem:
ENS Addresses
We believe ENS (or Ethereum Name Service) is a revolutionary development for Ethereum, and it is something that we want to integrate even more into the iExec toolkit. Click here to read our latest introduction to ENS addresses. Most smart contracts used in Version 3 are already registered on ENS. Users can also already register their “iExec Username” using a dedicated app on our website:
For iExec, the next step is to provide tooling to register apps, datasets, and workerpool on ENS. This registration includes two components:
- Forward registration: allowing the resolution of a human-readable name into an ethereum address.
- Reverse registration: allowing the lookup of an ethereum address into a human-readable name.
While forward registration does not require any specific tooling to be present in the smart contracts, reverse registration does. This is why version 5 will ship with a reverse registration mechanism built into all our contracts. This will not only allow the resolution of names like blender.apps.iexec.eth to the corresponding ethereum address but also doing the reverse operation (meaning finding an app’s ENS address from its ethereum address).
At some point, hex addresses should disappear from the marketplace and the explorer, being replaced by human-readable addresses.
NFTs
iExec has to deal with assets metadata and ownership. These are represented on-chain through dedicated smart contracts, built by a factory. For many reasons, ownership transfer is not supported in version 3. Current application and datasets are just owned smart contracts, that only iExec knows how to interact with. This is going to change.
In the next version, all the assets will be ERC721 NFTs!
This will also help you manage your app and dataset portfolio, making them visible in etherscan and opensea. It will be transparent to most users but will open many new use cases for some. Features we could envision include selling and renting datasets, or using datasets as collateral for loans.
I’d like a loan for xxx DAIs. If I don’t pay it back you get access to my personal data (which could include an ID card, social security number, …)
Thanks to our hybrid design, assets will remain described by smart contracts, that have their own address and methods. Ownership of these assets is however not controlled by the smart contract themselves, but rather controlled by an ERC721 registry that implements all the ownership logic. This allows token to have an ENS resolvable address/identifier.
Address predictability with create2
iExec is present on multiple networks, including Ethereum’s mainnet, the goerli testnet, and our own sidechain ‘bellecour’.
Switching from one blockchain to another can be a pain, in particular when a smart contract address changes from one chain to another. Thankfully, the create2 opcode introduced as part of the Istanbul network upgrade can change that.
In addition to using create2 for app, dataset and workerpool’s addresses being the same across blockchains, it is something we also plan to use for the deployment of the core contracts of iExec
*This was the topic of one of my talks at Devcon 5 and an ethereum magician discussion a few months later.
Meta-transaction support
UX has been a major concern lately, and many wallet providers have emerged offering solutions to this issue. Among the many developments in this space, meta-transactions are been one of the most visible innovations. iExec orders, introduced in version 3 and signed using the ERC712 signature scheme, are part of this general trend. However, some key operations, such as order cancellation, had no meta-transaction support. While we are still waiting for a generalized meta-transaction mechanism to become a standard (see our discussion during metamask’s latest hackathon), we added a dedicated endpoint for some key functions to be accessible through meta-transactions.
Pull Oracle Interface
iExec version 3 is, as far as we are aware, the only working implementation of an ERC1154. While we believed implementing it was the right thing to do, admittedly, the fact that it is not being adopted more widely reduces the interest of iExec being compatible with it. This is why we are part of the ADO (Alliance of Decentralized Oracles) effort toward a new standard replacing ERC1154. This new standard is still in its very early stage and proves a point:
Regardless of what standards are currently available and used, no one knows what tomorrow will be made of, and we have to prepare for it. This leads us to focus on the main feature of iExec next smart contracts, one that will future proof the platform and prepare it for the post-whitepaper era: modularity.
Improved Modularity?
A key feature we wanted to include in version 5 is to have the ability to expand capabilities down the line. The evolution of ERC1154 into ERC2363 is a good example of interfaces that we may want to add in the future.
To do so we did not go with the usual upgradeability pattern where a proxy contract redirect all calls to a single “implementation” contract which address can be updated. We decided to go for the pattern proposed in ERC1538.
ERC1538 relies on modules to implement the different functions that we want to expose. The ERC1538 proxy will then redirect the call to the corresponding modules following a “function signature to module” table. This allows us to add new functions that could either provide new features or act as a surgical fix in case a bug arises. This also has the added benefit of allowing many big modules to be accessible through a single proxy. This means we will no longer need to split our contracts, and the “hub” and “clerk” of version 3 will be reunited and accessible through the same proxy.
We use our own implementation of ERC1538, available to anyone as part of the iExec solidity toolkit.
We had the occasion, at NFTNYC, to discuss with other developers using ERC1538, and while we all believe this is a design pattern that should get more adoption, we also regret there not being a recognized and audited implementation for everyone to use, like the ones OpenZeppelin provides for ERC20, ERC721, and much more.
