In the impressive adoption of the “World Computer”, we’ve come to accept that Ethereum ERC20 tokens are tradable assets— a standardized interface following the Ethereum Improvement Proposal (EIP) definition for a limited token supply smart contract.
I had the opportunity with CodeCamp to present at IBM Place in Singapore on learnings and experiences (using ganache) for ERC20 tokens interoperability with real-world systems. My view of the current crypto-currency landscape that tokens:
- without a valid token-model will go to ZERO (and delist/disappear)
- thrive only when there is a growing supply AND demand
- MUST be directly linked with a practical use-case
Many token projects lack these three facts, and the tokens sole purpose to either (1) pay the issuing company for services, or worse (2) do not have a valid link to the business services at all. Missing is the use-case that creates value. As Jeffrey Wernick was referenced for citing “…the secret may lie in tokenizing the outcome of the value extraction and to capture the value in the hands of the originators of the data”.
By researching options for interoperability, we are specifically tackled the need to fuse an ERC20 token with the data stored in a decentralized blockchain.
Luckily, in the maturing blockchain space, a few options appear to link a token to a service. This article covers a few identified options:
Smart contracts have an interesting capability to raise events, and when caught by a listener (connected by web3.js) action code such a calling a URL. This simple mechanism can been for pay for services, and the endpoint handles the business logic.
Introductory articles covering Oracles describe their functioning in practical terms, and in a beginner developer guide. Oraclize provides a managed service with a comprehensive wrapper for greater flexibility and payload encryption.
However, there are a number of drawback: calls attract gas fees, parameters are passed in clear-text, downtime and risk of missing events, single instance of the listener, and most importantly they require the ETH sender to trust a single counterparty to run the Oracle.
Bridges are an evolution of the oracle taking steps towards a more robust ERC20 to private blockchain interop. A Bridge smart contract is hosted by multiple independent operators (who need not to trust each other), and participate to witness the inbound token transfer.
The individual Bridge updates the smart contract with a secret nonce, and a monitoring service tracks the progression to collect sufficient confirmations and release funds on the destination network.
A recent implementation of an ERC20-to-ERC20 Bridge was delivered by POA Network. To showcase to the world, POA put on a live demo.
All source code is published to the POA Bridge repo in GitHub with detailed documentation.
This approach is a plausible options to accommodate Ethereum’s probabilistic finality, however it consumes a lot of gas (due to the extensive flow), and the architecture has a number of moving parts. The design is clunky.
Furthermore, what if our destination network does not run on Parity, or support ERC20 contracts?
InterLedger has great ambitions to be the protocol that “..provides for routing payments across different digital asset ledgers while isolating senders and receivers from the risk of intermediary failures”. Its recipient naming convention (with a hierarchy similar to DNS, just in reverse) aims to give bring both routing and redundancy while guaranteeing atomic transaction across the connectors.
In theory, once a network has its connector, then transfers can take place across assets (not limited to crypto currencies) in a guaranteed 21-step process of confirmations and receipts. By this design, funds should never end up in limbo.
As their website publicly declares, InterLedger was invented at Ripple and developed by the Interledger W3C Community Group. Noteworthy that its inception was in 2015 with only a few demonstrated trails to date. Most connectors seem to be in perpetual work-in-progress.
In our R&D, we conclude the world will be taken over by an under-the-radar protocol called Tendermint. The engineers and community are amazing! We ourselves at SmartPesa are highly encouraged and building Credible on top of Tendermint (as listed in Cosmos & Tendermint Ecosystem entry #40).
The Cosmos community shared its view that smart contracts are easy to write (at least on Ethereum), but blockchains are much harder to implement. We however want to see the emergence of many blockchains and will need a mechanism for seamless interoperability!
To address this need, Cosmos implements at the heart of its ecosystem the IBC protocol, an Inter-Blockchain Communication protocol, to allow for interoperability across blockchains with instant finality, and thereby avoiding Oracles, Bridges and InterLedger! Finally! But we still have to cater to the permissionless world of Proof-of-Work (PoW) blockchains such as Bitcoin and Ethereum — and this is where the PegZone comes into play.
Now, the PegZone is the great albeit early stage bridge between the Ethereum network and ALL tokens on the Cosmos Network. You may be asking, what’s so novel about this?
In summary, the PegZone acts like a Bridge (and it looks, and quacks like a Bridge) BUT from an ERC20 to a non-ERC20 blockchain. This is a breakthrough for Cosmos since it brings the current ERC20 tokens one step closer to accessing an entirely new universe of interoperable blockchains.
A final mention to Plasma, an extension of Ethereum that embodies the concept of child-chains to the main-chain. Plasma provides a mechanism to move tokens (not limited to ERC20) into the side chains, and “Plasma exits” can move the value back onto the mainnet.
This allows private networks to become child-chains of Ethereum, and supposedly provide the necessary seamless entry- and exit for tokens.
Decentralised payment has been solved long ago with BTC among others and new technologies like Lightning and Plasma are looking to address the performance problems.
The evolution of blockchain is then about not just the token but the application in decentralised data systems where the cost of doing it centrally is so high, that the overhead costs of blockchain are well worth it. The complexities of a truly decentralizsed blockchain-based database in the real world are significant, but our R&D efforts set out above indicate there is light at the end of the tunnel.