The “Unblock Tokyo” conference was held on Saturday, October 5 at BinaryStar in Ginza, Tokyo. Pong Cheechrern, Technical Product Manager at OmiseGO, presented on “OmiseGO’s Plasma: Building a Production-Ready Layer 2 Solution”. Here is what he had to say.
Today, I am going to talk about the OmiseGO project itself. So I will cover what exactly the OmiseGO network is, but at the same time give some insights into the technology that could extend beyond just the project. So hopefully, what I can do today is to illustrate some of the the concepts of production readiness, what does production readiness mean, and how you can use the exact same concept of defining production readiness with different blockchains based on different technologies.
To start off with OmiseGO, what exactly is it? There are a lot of people who know the project from different angles, from the different products that we deliver. Some of the enterprise partners may know us for the eWallet suite that we produce, most of the public will know us for the OMG tokens, or the ICO in 2017. Or some people might know us for Plasma that we are building for the Ethereum ecosystem, for example. So for us to get a really good understanding of the project, I would like to go from first principles, and to discuss the very end goal that we are trying to achieve.
So consider this sort of problem. I am from Taiwan. At least we are savvy enough to have mobile back these days, which is great for us. But I realized that having come to Japan, I would not have any means to transact. As a person that owns any type of financial assets, going from one country to another, you are unable to conduct business. And such is the problem of modern financial systems, most of these systems are segregated, they are walled gardens, siloed and unable to be interoperable with one another. And this is the core of the problems that we are trying to solve.
The solution for this is one that OmiseGO is building, we are trying to get to the point where we can have a global settlement system where any type of assets, any type of transactions can be conducted, whether you are an institutional player, or an average person. We want to build a shared platform, a shared infrastructure that would service all types of individuals and all types of financial transactions, tokens or otherwise.
Let me give a little bit of background. When we actually got started, Omise was a payment gateway, conceptually quite similar to Stripe or PayPal. And then we realized quite early, around, late 2014, that the transactions that we have to conduct for our customers have to be done on existing providers like the Visa network. You only have a very few select institutions, and what you have to do when you have an intermediary is that we get charged a middleman fee, essentially. And these fees can be quite high, because there are only a few providers for these kind of services, it is an oligopoly.
So we were trying to figure out whether we can make these transactions on a different rail, in the form of a transaction where there is no central counterparty that would charge extortionate fees. So in late 2015, we came upon Ethereum, and we realized very quickly that transactions on Ethereum do not scale. We worked with different people within the Ethereum community, including Vitalik. And that really was the inception of the Plasma design, which is a way to scale Ethereum. So we created the first OmiseGO white paper and the first initial Plasma design called the “Minimum Viable Plasma”. And fast forward a little bit, we are at the point where we have the first released version of Plasma.
So about the network itself, we are able to handle over 4,000 transactions per second, we have a project now sitting on a repeat testnet. For most of the public ledgers, as you may know, if they are sufficiently decentralized in terms of the number of nodes, they have really low throughput. And that is the whole point of Layer 2 solutions, to provide scalability for Layer 1 ledgers while at the same time retaining some of the useful properties shared by this Layer 1. So properties like decentralization and security of funds are shared consistently with Layer 2 as opposed to other solutions, such as a side chain, where the security properties are not shared and you actually have to be reliant on the authority of an external provider to run the side chain approval authority for you. So unlike side chains, the security is shared with Ethereum.
In terms of ETH, we run at about one tenth of the gas cost. That means on average four cents per transaction. And the whole idea is scaling without compromise, gaining the benefits of high throughput, while at the same time, retaining the concepts of decentralization and safety & security that we enjoy on a Level 1 solution. To sum up the really high level functionality on this Plasma chain, we are able to deposit any ERC20 compliant tokens on the Plasma chain from Ethereum. Second, we are able to transact on this Plasma chain, and you are also able to exit. So after making these transactions on the Plasma network, you are able to take your funds from the Plasma chain to Ethereum. In the next version, our network will enable a way for the user to be able to add new transaction types. OmiseGo can deploy new transaction types, allowing for the Plasma chain to be upgradeable and enjoy more transactions, taking it beyond P2P payment. So an example might be exchange functionality on this OmiseGO Plasma chain.
So right now, we had version 0.2. With version 0.3 we will enable upgradeability on smart contracts themselves. Since the very first deployment in April of version 0.1, we have done about 2.6 million transactions on the testnet. We have a developer program for people to apply to. And then we have about 400 developers at this point. And also an ecosystem of projects, some of which you actually see if you are going to DevCon in Osaka.
Let us get to the main topic, what does this all mean for a project? What does it mean for a financial services provider or infrastructure provider to be what is called production ready? And this, of course, depends on the project itself. Production readiness can mean different things for different sorts of applications. If I am building a social media app, I could get that production ready within a weekend. On the other hand, if you are building a certain different types of software, what I like to call high assurance software, then any type of mistake or any failure on the software can lead to catastrophic issues. For example, in medical technologies, or in biotech, or in transportation, the software that runs in these domains must have high assurance, so you need to have a really high guarantee that things will work as expected. And obviously that takes a significant amount of time and effort spent on the software usually the lifecycle for the software is actually longer.
So just to unpack this part of benefit, to be production ready is very different from launching. Putting a software out there to the world is great. And it is great to solicit feedback from the consumers that use your software. But at the same time, it might be a little bit more complex than that, to say that a certain software is production ready. So what we mean at OmiseGo when we say production ready is that it implies certain properties.
One of them is safety. Does the software work as intended, is it a software that, once I have it released, is safe for the user. So in the context of a financial services provider, the funds that we deposited onto the network, is there a guarantee of the process’ state that no one can steal your funds and take them out of the machine? So, deep technology is really hard. And what I mean by deep is, well, there is two types of technologies, right, we have one type of risk that is called market risk. So the risk that a certain type of technology would go to market and no one would want it, also known as product/market fit. And the second type of risk is a technology risk. Is this piece of technology difficult to implement or is it even possible to build the technology? For example, that might be a rocket that lands standing when it comes back to Earth right?
So OmiseGo is not exactly a rocket science company. But at the same time any financial infrastructure provider using blockchain technologies can be considered somewhat of a deep tech company, that means to have a longer life cycle. And with this process, you do not ship right away, you start with a research phase. So this might be the sign specification, etc. Then you go to a proof of concept of this research, getting to a minimum viable version, in software that codified some of these properties that you have defined, until at the very last stage, which is the full implementation, the full production software is released to the world.
Another thing to mention is security audits. When you have financial software, and especially smart contract systems, you need to be sure to test that your software will work. And although it might be important for you to have a test done internally, and we had already said that OmiseGO also have an inhouse security team, it is definitely important to have someone audit your work. So it is going to be an external party that checks your work, making sure on the most objective level possible that the software is safe, and is fully secure.
Another point for us at OmiseGO is stability. Will a certain software continue to be stable, what happens from the perspective of an application provider that is consuming our software? So as a user, you probably do not use TCP/IP directly, you probably have a browser of an application that communicates to the lower level protocols for you. And for the OmiseGO network infrastructure, we are in a similar boat. So the wallets that connect to our network, are there synergies for these projects that the network that we provide to them is able to be be here as intended?
So one core tenet is service availability. There will not be any unexpected downtime. You can expect a certain level of guarantee such as 99.99% of the time the software will be running. These properties are very, very important for consumers’ business whose revenue is generated on top of an infrastructure provider. That is very important to us. And other test that you can do is some load testing, sending massive numbers of transactions and making sure things still work. Another factor is predictability. Is the next version of the software compatible or are changes breaking the old version of the software. The last part is having a solid ecosystem, not build any technology or software in a vacuum. The benefit of being a modern technology is that there is so many different third party applications and tools that can be combined to help build a solution. So things for us that we provide to consumer apps is a client SDK, is great documentation, providing them with a solid guide that gets them to building useful application efficiently.
If you found value in this article, please “clap” (up to 50 times).
This article is part of our Tokyo FinTech Publication, please follow us to read more from our writers, like hundreds of readers do every day.