Open Simple Token

Short primer on how Mosaic scales Ethereum for tokenizing mainstream applications


#1

Short primer on how Mosaic scales Ethereum for tokenizing mainstream applications

  1. Branded Token transactions take place on OpenST side chains, not on public Ethereum. The OpenST side chains are validated and finalized by an open set of Proof-of-Stake Mosaic validators. These validators can join validation of the side chains by staking OST on Ethereum mainnet and consequently must vote on the side chain to finalize its history (with a supermajority +⅔ of the voting weight). The validators get rewarded from the transaction fees along the finalized history - there are no new tokens minted for new block produced on the side chains.

  2. The Mosaic consensus rules by which the validators finalize the history of the side chain build on work by the Ethereum Foundation and classical Byzantine fault-tolerant (BFT) consensus literature. As a result the side chain can be finalized by the validators without relying on synchronization with Ethereum mainnet.

  3. The consensus rules enforce that only a single side chain history can be finalized. If validators would cast votes such that contradicting histories of the side chain could both become finalized then it is proven that the offending validators can be efficiently held accountable with their offending vote messages. The stake of all validators is locked in a contract on Ethereum mainnet, and anyone can present proof of wrongdoing to burn the stake of offending validators.

  4. Finalized segments of the side chain can be proposed on Ethereum mainnet to be committed in bulk for a constant cost on Ethereum mainnet. A new commit can span an arbitrary amount of transactions verified and finalized on the side chain. Validators are incentivized to commit segments of the finalized history of the side chain at set amounts of computation verified; but there is no time constraint as this would couple the side chains synchronously to Ethereum mainnet.

  5. Communication between Ethereum mainnet and a given side chain happens through a message bus protocol. Messages from a source chain can only be cryptographically confirmed on the target chain given that the Mosaic validators have finalized the history of that source chain. The protocol is atomic, causally consistent with the finalization of the source chain on the target chain and does not rely on trusted actors or oracles to pass messages between the chains.

  6. To transfers ERC-20 tokens from Ethereum mainnet to a side chain the message bus protocol is used to “stake-and-mint” the tokens and “redeem-and-unstake” to return from the side chain to Ethereum mainnet, ensuring that the tokens can not be double spent in the process.

  7. By construction the side chains can now run in parallel of Ethereum mainnet as an extension of Ethereum mainnet and finalize transactions at minimally 100 transactions per second per side chain. (We are comfortable with sustained load of 300 transactions per second per side chain.) The finalized histories of the side chains can be committed asynchronously back to Ethereum mainnet.

  8. Uniquely this solution offers the full smart contract interface and tooling to developers on the layer-2 scaling solution (counter to payment channels, state channels, zkS(T/N)ARKS, or Plasma). This is important to allow new token economies to experiment with the possibilities of programmable money for their application.

  9. On the side chain we intend to deploy payment channels and zero-knowledge technology to provide privacy and an additional capacity boost. We are in conversation with the leading teams on both technologies.

  10. On top of the hub-and-spoke model with Ethereum mainnet at the center and the side chains as the spokes secured and finalized by the Mosaic validators, atomic swap technology can be used to transfer tokens directly between different side chains without passing over Ethereum mainnet. This allows to scale Branded Token economies horizontally across several side chains if-and-when the transaction volume requires it.