OST LIVE #003 Recap: Ben Bollen, Chief Blockchain Strategist at OST Discusses OpenST Mosaic, A Protocol For Scaling DApps on Ethereum
About a year ago, Ben Bollen, Chief Blockchain Strategist at OST and Jason Goldberg, CEO at OST, started Simple Token “OST” and the OpenST project to develop the missing technology that is needed to connect Ethereum to existing user platforms. This episode with Ben Bollen introduces Mosaic, OST’s protocol for scaling DApps on Ethereum to thousands of transactions per second.
OpenST Mosaic and Meta Blockchains
If Ethereum was scalable and cheap to run on, it would be possible to write a full blockchain with validators and a consensus engine rule within a smart contact. It would be possible to run a DApp on top of the simulated blockchain, on top of Ethereum. Essentially, a blockchain built on top of a blockchain, better known as a meta blockchain. This would allow for the possibility to write byzantine fault tolerant consensus rules where the state is kept on Ethereum. The validation of transactions and the slashing conditions would be asynchronously enforceable on Ethereum and the heavy work of running and finalizing transactions could be moved off of Ethereum onto a auxiliary chain.
Mosaic is a set of cores and a blockchain defined in a smart contract on Ethereum. Mosaic is a blockchain because it has a consensus engine with byzantine fault tolerant rules, it has an open set of stake validators, and the state route is asynchronously finalized even before the validators take the expensive effort of committing the state route back to Ethereum. However, a meta blockchain introduces the problem of additional overhead. There are now two systems that need to communicate between one another.
OpenST Gateway
A gateway is a message bus that is also asynchronous. It is ERC20 typed as it sends messages in the form of tokens by locking them up on origin and re-minting them at equivalent value on the auxiliary system and vice versa. The gateway consumes the committed state route from the blockchain on either side. All messages are confirmed with full merkle proofs of the state and the storage route of Ethereum. This protocol is a layer 2 protocol that is agnostic of layer 1. The auxiliary system is a full Ethereum Virtual Machine (EVM) that provides the same interface as Ethereum mainnet.
To confirm a message in an asynchronous way, one could declare it on Ethereum. The tokens are also minted into an escrow, meaning one needs to prove (with a merkle proof) that one has confirmed the tokens on the auxiliary system to permanently lock the tokens on origin. In order to have the resulting tokens on the auxiliary system, one needs to prove (with a merkle proof) that one has progressed the tokens on origin. This is a very expensive and very slow process, but it is the logical foundation because a reward can now be introduced to a facilitator.
An executable message can be signed to reward a fee to the facilitator who wants to perform this process. Only one merkel proof is needed because the facilitator can introduce a hash log which is sufficient enough to be confirmed on the target system. When the hash log is revealed on either side, it can be a much cheaper message confirmation and progression on both sides. There are important differences when looking at Mosaic and Casper + Sharding. Mosaic is a layer 2 for DApps, often including Casper + Sharding. The Casper voting rules are the logical foundation for the extension of the byzantine fault tolerant rules that is proposed with Mosaic.
We can now move away from the verifiers because we’re leveraging the security of an expensive Proof-of-Work (PoW) Ethereum system and using it to secure a high number transactions on scalable auxiliary systems. It is important to make sure that all the rules are asynchronous to avoid timing attacks.
Verifier’s Dilemma
In 2015, an academic journal called “Demystifying Incentives in the Consensus Computer” first introduced the idea of Verifier’s Dilemma. It is an idea that suggests if there is too much useful competition performed on Proof-of-Work (PoW), then it is no longer decidable for an honest rational miner whether to verify transactions because if there are too many transactions to verify, a miner would run behind on those who aren’t verifying the transactions on producing the next nonce for the block. The main problem is that Proof-of-Work (PoW) derives its security from a race condition for finding the nonce. This implies that there is no reward for verifying the actual transactions, which further implies that the network needs to be inefficient. This results in high gas costs and preferred small gas consumption per transaction.
Benefits of OpenST Mosaic
With Mosaic, one can now scale many auxiliary systems on Ethereum without producing a bottleneck for Ethereum. In many ways, Ethereum becomes a message bus in this system. Mosaic also makes layer 1 validators of the auxiliary system effectively only block proposers and takes the economic finality away from them and moves out onto Ethereum mainnet.
Because Mosaic is an open validator set, the data availability problem is now addressed as one would need to be able to (as a validator entering the group) start again from the genesis block before signing off on any auxiliary system transaction. These transactions are dynamically finalized. If any of the transactions on the auxiliary system were to be reverted before the state root would be committed to Ethereum, one could always prove to have the signatures to burn their stake on Ethereum.
This provides a very high transaction throughput because finalizing on the auxiliary system is equivalent to committing to Ethereum. If we assume that one auxiliary system can run at four hundred transactions per a second, then if we are not synchronously bound to committing to Ethereum, we can have a large number of these auxiliary systems dependent on Ethereum for their security.
There are new gas markets introduced and we know that a gas market price for Ethereum works. Given Ethereum is Proof-of-Work (PoW), there’s a high gas price requiring it to be inefficient. The layer 2 Mosaic validators are only rewarded collectively for validating and verifying transactions. The gas price on Mosaic is assumed to be much lower, per argument of Verifier’s Dilemma. The layer 1 validators of the auxiliary system are being paid in gas consumed for these transactions. There is also no requirement for mass exit of the system.
OST plans to publish the OpenST Mosaic draft paper by the end of September. Meanwhile, be sure to check out the code that is on Github or join our Telegram chat! Next Wednesday, we will be having a partner interview with Sean Howell, Co-Founder of Hornet and CEO of the LGBT Foundation. He will be sharing his experience with launching the LGBT Token on OST.
About OST
OST blockchain infrastructure empowers new economies. OST is a public blockchain platform designed for the needs of businesses with millions of users. Launch your own Branded Tokens with OST technology and turn your business into a dynamic ecosystem. OST is built on the OpenST Protocol, a framework for building highly scalable blockchain token economies. OST has offices in Berlin, New York, Hong Kong, and Pune. For more information, please visit: https://ost.com.
