Development Direction to the L2 Interoperability
Introduction
After the release of Plasma Group’s new blog post about their new generic design concept of L2 solutions, Optimistic Virtual Machine, our research team has been discussing what positions we should take on it along with other L2 R&D teams and how we can bring more interoperability and to maximize our contributions to the community.
After the long discussion, we decided to share the conclusion we came to, describing;
- R&D topics we should focus on for the next couple of months
- Architecture of the abstracted second layer solutions
in this post, hoping to give more clarity on our development direction!
Our position: what can we do?
As we have been stressing that our final goal as to bring mass adoption of Ethereum in the real world, our primary development goal has been set to finish building Plasma Chamber (currently in the process of rewriting in Rust, see a repo here; https://github.com/cryptoeconomicslab/plasma-rust-framework), a framework to build secure, scalable, and usable dapps on Plasma and deliver a great developer experience.
We believe that there are going to be more L2 application developers involved, hence, more viable applications running on top of Ethereum. In the pursuit of a wide range of applications/use cases, we wanted to deliver essentials for devs such as dev tools, application framework, libraries for frontend, etc. Especially, it would a significant enhancement if we have a standardized client that can support multiple types of L2 applications.
Abstract architecture of second layer solutions: what are we building?
So how does the abstracted architecture of various Layer2 systems look like? As we mentioned in the previous section, our primary goal is to provide a simple and easy way to build various Layer 2 applications and support developers. Through the process of the abstraction, the first thing we did was to apply the concept of Separation of Concerns for a better design, dividing the target developers into two main categories by their interests. First is Predicate developers who want to develop business logic of L2 application. Second is front-end developers who are in charge of developing a user interface. Considering that we need to provide an appropriate tool for each kind of devs, we broke down the L2 system that we want to deliver into three components: Predicate, Client, and Frontend.
As the next image shows, we categorized each element that forms this whole system altogether based on its functionalities rather than using the conventional way of decomposing blockchain applications, e.g. layers. Of course, different types of developer experience need to be considered for each component.
Predicate part is responsible for handling business logic of L2 applications. Predicate include Predicate plugins, through which Client communicate with a specific type of predicate it needs. Developers have to explain how states can be updated or how users can protect their own assets here. By combining basic predicates, developers can build complicated predicates for more creative L2 applications. Additionally, solutions to the old Plasma usability problems, such as fast finality contract, fee contract, defragmentation, and checkpoints, have been absorbed into this part. It will enable Plasma researcher and developers just focus on designing Predicate.
Client consists of what was previously considered as plasma-coreexcept for predicates contracts. Client part is responsible for communicating with other clients (e.g. open a payment channel with another user, and then send a transaction to the operator in plasma chain), communicating with L1 contract (e.g. plasma operator commits Merkle root to L1 contract), or storing state data in the client database.
Frontend includes all different kinds of user interfaces for L2 applications(e.g. game UI, wallet UI).
These 3 main constituents communicate with each other to complete an L2 application as a whole.
What we build for each component
So how are we going to complete the whole system, building each part in what order?
In this section, we’ll describe in detail what we build for each component addressed in the previous section.
Client
First, we are going to focus on to implement a client. It’s because by implementing a client and providing its SDK, it can help developers to make user interfaces smooth. Second layer client is capable of multiple different things; supporting different functionalities, storing and updating states, communicating with other clients or L1 contracts. Additionally, in the context of OVM, second layer client will be able to handle various constructions of L2 solutions such as state channels and plasma. We will first focus on to develop clients for plasma, such as operator client, but in the long run, we will implement additional features to support other L2 designs as well.
Predicates
The only thing predicate developers need to do is to think of data structure and dispute logic in a safe manner. This requires more of a computer science point of view rather than a software development experience.
Although it takes only a few minutes to write simple ownership transfer predicate, once you attempt to write a bit more complicated predicate, it gets far more difficult. You need to make sure that the state transition logic is properly designed. Especially, you need to guarantee that users can protect their assets against malicious clients with a 100% confidence that all the necessary data are available for users to challenge malicious behaviors. It’s not an easy task. It takes pretty long for functional verifications.
Again, stick to the original, our primary interest is to provide more devs with a simpler and easier way to develop predicates. We want to enable ones with no computer science background to write predicates without any hassle. In the current situation, however, there’re not enough resources available to refer out there yet. Here is what we are going to work on!
While researching how to write complex predicates securely, we found several design patterns combining multiple basic predicates, so our next-step goal will be to share that knowledge of design patterns and create a tool for other devs to utilize it. Using that tool, everyone will be able to write and use predicate very easily.
Frontend
It’s not easy to develop frontend applications without the use of great frontend libraries. We will provide a frontend SDK as a well-abstracted interface for Client that can support various kinds of second layer design. We’re currently working on Browser and Android frontend app SDK.
Conclusion
Hopefully, this post gave clarity on our development focus and direction towards our aforementioned goal; deliver blockchain developers much easier, simpler way to build various layer 2 applications!
Co-authors: Yuriko Nishijima, Takamichi Tsutsumi, Shuhei Hiya, CEL research team
Twitter：please tweet us any questions!
Links to Cryptoeconomics Lab’s information:
Github：
