OmiseGO is one of the most exciting projects being built on top of Ethereum. Their goal is to become the world’s biggest peer-to-peer cryptocurrency exchange platform. OmiseGO describes itself as: “The answer to a fundamental coordination problem amongst payment processors, gateways, and financial institutions”.
One of the main reasons why the community is waiting for it with bated breath is because of their implementation of Plasma
The Team Behind OmiseGO
The company behind OmiseGO is Omise, a “payment gateway for Southeast Asia, based in Thailand, providing a secure and white label solution to merchants and enterprise businesses.”
The team is helmed by CEO Jun Hasegawa.
What is even more impressive, however, is their team of advisors. Their advisors are the “Who’s Who” of the crypto-world. Just look at some of the names here:
Dr. Gavin Wood.
With such a strong team behind them, you can see why people are excited about this project.
Before we get to know about anything else let’s get into the one thing that the OmiseGO project has become synonymous with, Plasma.
Why is Scaling Required?
Scaling is the name of the game. With the increased acceptance of cryptocurrencies, the strain on the blockchain has grown immensely. The reason behind that is the design of the blockchain itself.
A blockchain network is made of several nodes. A node is essentially a user connected to the network. The nodes are the lifeblood of the blockchain, not only are they responsible for the overall functioning of the chain, they are responsible for governance as well. Whenever the network needs to come to a decision, every node (or a supermajority of them) must consent and then and only then is the decision taken.
The reason why that is done so is simple:
It helps give decentralization.
It increases the security and the resilience of the network.
However, what the network gains in security, it loses out inefficiency.
Ideally we would want the blockchain system to be able to parallelize all its tasks to save up on time and increase efficiency, however, that is not something that can be achieved. There are certain tasks in the blockchain which are parallelizable while there are some which are not.
A good example of “parallelizable” task is digital signature verification. All that you need for signature verification is the key, transaction and the signature. With just three data you can conduct verifications in a parallelized manner.
However, not all the functions on a blockchain should be done that way. Think of transaction execution itself. Multiple transactions can’t be executed in parallel; it needs to be done one at a time to avoid errors like double spends.
While all this sounds good in theory, it sort of falls apart when you use it in real life implementation. The plain and simple fact is that no system, which depends on every single solitary node to consent on every single decision is ever going to scale up efficiently. Nowhere was this more apparent than during the cryptokitty fiasco.
Cryptokitties is a blockchain-based virtual game that allows players to adopt, raise, and trade virtual cats. The game was made by Vancouver based blockchain company Axiom Zen. However, what is truly important to remember is that this is the first known application of DAPP for leisure and recreation.
While all this is well and good, one thing was made abundantly clear. The Ethereum blockchain was not ready for a DApp to get as popular as Cryptokitties did.
How Cryptokitties Clogged up the Blockchain
Turns out, that Cryptokitties became so popular that it drove up Ethereum gas costs and clogged up the chain.
At one point, it was the third most gas-hungry smart contract in Ethereum.
Image Credit: ETH Gas Station
In fact, at its peak, cryptokitty transactions took up 20% of the network’s computational power!
Because of the increasing demand for kitties, the number of unconfirmed transactions on the blockchain increased exponentially.
Image Credit: Quartz
In fact, the number of total pending transactions became so much that Axiom, the company behind cryptokitties, were forced to increased their birthing fees. This is what they said:
“The excitement and adoption we’ve seen this week has been overwhelming and we couldn’t be happier!
However, the Ethereum network is completely full. The only way to keep CryptoKitties from lagging is to increase the gas prices so that all transactions can complete quickly. We know that increased prices will mean that some of you will need to slow down your breeding regimen, and we are incredibly disappointed by that. But who knows? Maybe this slowdown will just mean that you’ll love the Kitties you already have that much more.”
However, there is one solution that can truly revolutionize blockchain technology forever. If executed, this can scale Ethereum upto million of transaction per second. Keep in mind that Ethereum can right now manage just about 15-20 transactions per second.
The solution is Plasma.
What is Plasma?
Plasma is a blockchain scaling solution by Lightning Network co-creator Joseph Poon and Ethereum co-founder Vitalik Buterin.
“Plasma is a proposed framework for incentivized and enforced execution of smart contracts which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide.
These smart contracts are incentivized to continue operation autonomously via network transaction fees, which is ultimately reliant upon the underlying blockchain (e.g. Ethereum) to enforce transactional state transitions.”
Yes, that sounds very scary. Don’t get scared!
In the following sections, we will simplify the mechanism behind it to make you understand what it is and how it works.
Let’s try to get a layman’s understanding of what Plasma means.
Plasma is, in essence, blockchains built on top of blockchains. It is a series of contracts that run on top of the root chain (eg. the main ethereum blockchain).
If one were to envision the architecture and the structure, then think of the main blockchain and the plasma blockchains as a tree. The main blockchain is the root while the plasma chain aka child blockchains are the branches.
Image credit: Hackernoon
The root chain is like the universal absolute ground truth, while the child chains work around it doing their own computations and periodically feeding state information to the root chain.
The root chain comes into play only when there is a dispute that needs to be settled in the child chain, otherwise, it doesn’t involve itself with anything going on in the child chain and this point is the core underlying philosophy behind it. If the root chain is going to be the ground truth, then it must remain as devoid of activity and calculations as possible.
The root chains and the child chains will form a set of “nested blockchains.” To understand how a “nested” system works, it may be useful to take the example of nested loops. The reader maybe familiar with the concept.
This is how nested loops work:
for (i=1; i<5; i++)
for (j=1; j<5; j++)
Instead of using just one loop to execute the entire condition, we used another loop inside the main loop and split up the condition. The inner loop does a calculation and returns a value to the main loop. This makes computation a lot less complicated.
That is in essence how the nested blockchains operate. Another interesting way to understand this and especially to know how dispute resolution in plasma works, it may make sense to think of the court system.
In this case, the Supreme Court is the root chain, it lays down the law of the land. The Supreme court has its child chains (Criminal and Civil) and each of them has their own child chains.
So, if one were to bring up a civil case to the court, they can’t directly go to the Supreme court (of course this depends on how high profile the case is).
The applicant will first deal with the county courts. If they are not happy with the decision, then they can go up in the chain one at a time before finally appealing in the supreme court.
That is pretty much how the idea of plasma and nested blockchains will work, with the root chain being the supreme court with multiple child chains under it.
We will get back to dispute resolutions in Plasma later.
The Design Goals of Plasma
In order to implement plasma effectively, Joseph Poon and Vitalik Buterin had certain design goals. Let’s go through those goals and the significance of each.
#1 One Blockchain to rule them all
As stated earlier, the main blockchain will be the root blockchain and every other child chain will be derived directly or indirectly from it. The root chain will not interfere with any of the child chains except on the event of disputes.
#2 Minimization of Trust
The system needs to be as trustless as possible. None of the child chains can be completely dependent on the ethics of certain actors. There should be mechanisms for someone to exit from the child chains.
#3 Ledger Scalability
The blockchains should be able to hold a lot of data. The child chains should be able to take up the data that would normally go on the root chain.
#4 Should be Scalable
The child chain should be compatible with various scaling solutions. Basically, they should be capable of implementing solutions like sharding and lightning network as well.
#5 Localized Computations
Each child chain must be capable of doing their own calculations. On regular intervals, each chain should give their state updates to the parent chain.
#6 Fraud Proofs
On the event of a dispute, the bereaved party can send a proof of fraud to the root chain The root chain can then roll back the state of the child chain and penalize the signers of the block of the child chain.
This is extremely important and will be explored later in detail.
#7 Every Chain is Unique
Every child chain can have its own governance rules. They can be their own unique entity as long as they are constantly reporting back to the main chain.
Plasma’s functionality depends on MapReduce. According to Wikipedia, MapReduce is a programming model and an associated implementation for processing and generating big data sets with a parallel, distributed algorithm on a cluster.
What that basically means is, if you have a huge amount of data, you can simply delegate parts of it to smaller entities, who compute them in parallel and then return the result to you.
MapReduce is made of two parts:
Map: In this part, the data is divided and handed over to different entities to be solved in parallel.
Reduce: The entities solve the problem and execute a “summary” function which considerably lowers the data size and returns the summarized value.
Let’s take a real-world example of this.
Suppose Alice told Bob to count the number of words in a book. Bob then gives a page to Charlie and Dave each. They both count the number of words in their pages simultaneously and return the number of words to Bob. Bob adds the number of words and gives the final tally to Alice.
So, let’s look at this from the perspective of Map and Reduce.
Alice tells Bob to count number of words.
Bob gives a page each to Charlie and Dave.
Charlie and Dave give the number of words of each page to Bob.
Bob gives the total words to Alice.
Now if we see this in the context of blockchains it will look something like this:
Plasma chain 2 assigns each page to Plasma chain 3.
Plasma chain 3 computes and returns Merkelized data back to Plasma chain 2.
Plasma chain 2 then gets final data and sends the final Merkelized data back to Plasma chain 1.
Now, what does this “Merkelized” term mean? For that, we need to look at Merkle trees.
What is a Merkle Tree?
Image Credit: Wikipedia
The above diagram shows what a Merkle tree looks like. In a Merkle tree each non-leaf node is the hash of the values of their child nodes.
Leaf Node: The leaf nodes are the nodes in the lowest tier of the tree. So wrt the diagram above, the leaf nodes will be L1, L2, L3 and L4.
Child Nodes: For a node, the nodes below its tier which are feeding into it are its child nodes. Wrt the diagram, the nodes labelled “Hash 0-0” and “Hash 0-1” are the child nodes of the node labelled “Hash 0”.
Root Node: The single node on the highest tier labelled “Top Hash” is the root node.
So what does a Merkle Tree have to do with blockchains?
Each block contains thousands and thousands of transactions. It will be very time inefficient to store all the data inside each block as a series. Doing so will make finding any particular transaction extremely cumbersome and time-consuming. If you use a Merkle tree, however, you will greatly cut down the time required to find out whether a particular transaction belongs in that block or not.
Let’s see this in an example. Consider the following Merkle tree:
Image credit: Coursera
Now suppose I want to find out whether this particular data belongs in the block or not:
Instead of going through the cumbersome process of looking at each individual hash and seeing whether it belongs to the data or not, you can simply track it down by following the trail of hashes leading up to the data:
Doing this significantly reduces the time taken.
So, when we say “Merkelized” solution, it is the Merkle root that we are specifically referring to. Each child chain must send the Merkelized solution periodically to the parent chain.
In order for a system to work efficiently, it must make effective workarounds around malicious behavior, same goes for Plasma. So, how does dispute resolution work in Plasma?
Imagine this situation.
Suppose Alice has 1 Eth in Plasma Block 3 but for some reason sees that she no longer has that in Plasma Block 4. Suppose the person responsible for Block 4 acts in a malicious way and assigns her 1 Eth to someone else. What does she do?
The Plasma smart contract will enable her to send her or anyone else who notices this activity, a Fraud Proof to the root blockchain. The root blockchain will then check whether the fraud is real or not and if it is, it will “roll back” the malicious block. Meaning, block #4 will be rendered invalid and the state of the plasma chain goes back to block #3. The signer/creator of block #4 then gets penalized.
This is what happens:
Exiting Protocol in Plasma
According to Joseph Poon, the exiting protocols are “the core novelty of Plasma.” So, what does “exiting” mean? One of the design goals of plasma was to make sure that it doesn’t rely on itself for safety. The way it achieves that is by making sure that users have the means needed to exit a child chain whenever anything goes wrong.
How does that work?
We have a dispute resolution system in Plasma, but as we have seen above, in order to prove fraud, we must have access to the fraudulent piece of data. Eg. Alice could prove the fraud above because she could see that Block 4 was acting maliciously with her. In other words, she was only able to prove fraud because she had access to the malicious data and hence could show it to everyone.
However, what happens if the signer of the block doesn’t give Alice access to the data (this is called a block withholding attack)? Situations like these usually devolve into “my word against yours” type of scenarios. So, Alice can say “I didn’t get access to the data,” while Bob can say “I gave her access to the data, she is lying.”
Situations like these demand that we trust one of these parties for conflict resolution. However, if you remember, one of the design goals of Plasma is to create as trustless a system as possible.
So, the challenge that the designers had was to create an effective way of resolving this potential conflict without putting trust on any one of the parties.
How did they achieve that?
They coded the smart contract to have pre-designed exits in the plasma block. How does the pre-designed exit work?
Let’s bring in this image again:
Suppose Alice has 1 ETH on block 3, but she doesn’t have any access to Block 4.
Alice broadcasts to the parent chain (the root chain in this case) that she is going to exit the chain if not given access in 7 days.
The way she does that is by broadcasting an intent of spending this money within the time limit. If she doesn’t spend this money, then she will be able to exit.
The exit happens in the order of the age of the inputs inside the plasma block. This means that the older inputs will be able to exit first. This creates a fair system.
However, this brings us to another predicament. The transaction intent needs to be stored somewhere.
In order to resolve this, Plasma uses nested trees to make the system as efficient as possible.
Image Credit: Plasma Whitepaper
In the image given above, there are three levels of chains.
The root chain being level 0.
Then level 1 which is the child of the root chain.
Then we have level 2 which are the child chains of level 1.
Finally, we have level 3 which is the child of level 2.
So, as you can see, Alive has her 1 ETH stored in the solitary level 3 block. Now, suppose the Block in chain 2 starts acting in a malicious manner.
In this case:
Alice will broadcast to the immediate parent of the malicious block, i.e. Block 1.
The participants in the faulty block will move to preceding block.
The faulty block gets removed.
This is a more desirable solution because:
It is more economically viable.
The main root chain stays undisturbed which is one of the design goals of plasma. The root chain must remain undisturbed as much as possible.
Note: If all the blocks in Level 2 end up malicious then Alice will have to broadcast to the root chain.
There is another advantage of this system as well.
Having a nested architecture significantly reduces the computation involved in checking and validating the transactions to make sure that no fraudulent activity has taken place. One needs to watch only the chain which affects them directly. Let’s see an example of this by bringing this diagram back again:
Alice doesn’t need to look at the entire set. She just needs to look at the chains that concern her. In her case it would be:
Finality, in very loose terms, means that once a particular operation has been done, it will forever be etched in history and nothing can revert that operation. This is particularly important in fields which deal with finance. Imagine that Alice owns a particular amount of an asset in a company. Just give of some glitch in the company’s processes, she shouldn’t have to revert ownership of that asset.
So, how does Plasma get its finality?
Child Chain Finality: Child chain finality comes from the proof-of-stake mechanism.
Root Chain Finality: Root-chain finality comes from Ethereum which, as of right now, is using proof of work.
The finality and security of Plasma depend completely on Ethereum’s i.e. the root chain’s security. Plasma works only if Ethereum is safe and secure.
So, that is a broad and general overview of what Plasma is and how it works.
How is OmiseGO different from Normal Exchanges?
There are two features that make OmiseGO different from the others:
Normal exchanges form a very important role in the ecosystem. They are the portals between the Fiat world and the Crypto world. The problem with that is that they are vulnerable to a lot of hacks since they are centralized entities. Hundreds of millions of dollars have been stolen via hacks aimed at exchanges.
OmiseGO will provide the same functionality as centralized exchange but with a difference, it will be decentralized and all the data will be stored on the blockchain.
#2 Currency Agnostic
Most exchanges only allow one to transition from Fiat to Crypto. This means that if one were to change their BTC to ETH, they would have to convert their BTC to USD and then change their USD into ETH. In the process, they end up spending a lot of money as transaction fees.
OmiseGO mitigates this issue by being currency agnostic. This means that the conversion from USD to ETH has the same process and fees as the conversion from BTC to ETH.
The OmiseGO ICO
OmiseGO uses OMG tokens.
The ICO took place on 23rd June 2017 till 23rd July 2017 and raised 25 million dollars.
CEO Jun Hasegawa said that the pre-sale hype was so big that they could have easily raised more than $100 million dollars from the ICO. However, they kept the figure low to be more responsible. This one of the reasons why they didn’t opt for a public sale and kept the sale as stable and controlled as possible.
“We limited the OMG sale to KYC [people who can be identified] in order to prevent a very real possibility of one or two rich people buying almost all the tokens, as happened with [Brave’s] Basic Attention Token (BAT) sale,” Hasegawa explained in a statement.
“Unlike other sales, we didn’t want to raise our sale cap past $25 million because we don’t expect we need more money to accomplish our goal,” he added. “It is both irresponsible and counterproductive to take more than we think we need.”
This approach got OmiseGO a lot of positive feedback from the community.
The OmiseGO Roadmap
OmiseGO’s roadmap milestones are named after the Chinese game “Go”. Let’s go through them:
#1 Fuseki and Sente
“Fuseki” in Go represents the opening of the board. In OmiseGO this represents the opening of the deliverables to their users.
In “Sente” the company will take in the feedback from “Fuseki” and incorporate that into their product.
The OmiseGO network will be delivered and the foundations of Plasma will be laid down.
Users will gain the ability to move in and out of Fiat and get an interface to the Omise Payment gateway.
A basic form of Plasma will be introduced.
OmiseGO and Plasma will be fully deployed.
As we have said before, OmiseGO is one of the most eagerly anticipated projects in recent years. They have a strong team and a strong group of advisors.
One can only hope that their development goes smoothly. Plasma has serious game-changing capabilities. It will be interesting to see how things play out in the future and whether OMG and Plasma actually live up to the hype or not.