When Cross-Domain Collaboration Meets Optimistic Rollup

In my last article 'Finance is not the future of blockchain, cross-domain collaboration is', I elaborated that cross-domain collaboration is the fundamental layer to backbone value creation.The future of blockchain depends on how to build up the governance and business implementation framework for cross-domain collaboration, other than putting all the fortunes into the uncontrollable decentralized financial applications. And DAC, which is a cluster for cross-domain collaborations, is the key to the whole framework.

When we focus on the study and architecture of the DAC, the methodology for launching various DApps becomes clear.

When you are going to incorporate a traditional style company, you will have to register with a government office, and a set of legal and financial policies will be issued to protect the interests of all the shareholders. A DAC should have a similar kind of governance structure for decentralized registration and for regulating the relationship among various distributed collaborators.

Just as a traditional company has the KPI management, project management, and other management systems to manage the business, a DAC also should have a similar framework to manage the business implementation, or it will become a total mess when distributed collaborators just act based on their own understanding and timeline. Since the actual business operation is a complicated procedure, voting function, which most DAOs have used, is far more than enough.

When the governance and business implementation framework for a DAC is well-established, you will find it pretty simple to establish a DAC and to collaborate within the DAC. Since DAC lives on the internet and blockchain, all the collaboration activities are programmable, recordable, and traceable, which provides the convenience for governance and management.

A DAC is set to accomplish some business goals, so it is the same concept as a DApp, and the incentives mechanism will flow naturally as the results of collaborations.

Why connect the DAC with the Optimistic Rollup?

You can find the detailed introduction of the Optimistic Rollup (OR) here, which is a Layer 2 scaling construction on Ethereum.

Just as the name of Optimistic Rollup, 'Optimistic' is used because aggregators publish only the bare minimum information needed with no proofs, assuming the aggregators run without committing frauds, and only providing proofs in case of fraud. 'Rollup' is used because transactions are submitted to the main chain in bundles (that is, they are rolled-up).

We found it a super match to combine the OR concept with the DAC (cross-domain collaborations) governance and business implementation.

First, the establishment of a collaboration relationship among distributed collaborators should be as simple as possible. Most distributed collaborators may span in different time zones and have no trust foundation from the beginning, if the collaboration relationship is hard to buildup and confirm, the collaboration will be impossible to implement, and the DAC couldn’t be established either.

Inspired by the Optimistic feature of the OR, we can design an Optimistic mechanism to enroll these distributed collaborators without any threshold, simply by assuming that each collaborator is honest and will act coordinately as his promise. However, if some collaborators committed fraud, an arbitration and punishment system should be activated to protect the interests of the ‘good’ collaborators.

Second, OR moves transactions off-chain onto a layer 2 sidechain, which is secured by the main chain. Since the sidechain provides the scalability, improves the privacy, and lowers the transaction cost, it gives us a clue that actually collaboration(transaction) practices (might happen anytime, anywhere, in an irregular frequency) can be placed onto the sidechain, while not the main chain.

Enough lessons have been learned if you rely too much on smart contracts for on-chain management, such as the MakerDAO liquidation crisis and other hacked DeFi projects.

In practice, it is reasonable to conclude that you don’t have to put all the transaction onto the chain, because the transaction details only need to be confirmed among those distributed collaborators, such as what these collaborators want to execute and what results they hope to achieve. There is no need to obtain a global consensus, which is time-consuming, costly, and without any privacy.

When we place the transaction on the sidechain and leave the freedom to those distributed collaborators to discuss and determine the details, Rollup mechanism will synchronize the state of every transaction on the main chain, to act as the witness to avoid potential default risks and to initiate the incentives or punishment. For example, if both the collaborators have reached the consensus on the sidechain, the state will be upload onto the main chain, but if some collaborators didn't admit the transaction results afterward, the state of the disagreement would be compared with the previous state of the consensus. Punishment will be executed to those who default.

Of course, there should be some tools on the sidechain to record the transaction details, to implement specific activities, and to do the management.

How to leverage the OR mechanism?

Since the OR is still under development, we can refer to the concept of OR and optimize it to work for the DAC. Let’s discuss how to leverage OR in two layers.

The DAC governance layer

The governance layer is specially designed for the establishment and maintenance of a collaboration relationship. Since most distributed collaborators are not familiar with each other, how to set up a simple but protectable mechanism for all these distributed collaborators would be crucial.

First, we could decompose the complex collaborations among many distributed parties into multiple peer-to-peer collaborations, which is called Meta Collaboration. Meta Collaboration is the smallest unit in a DAC.

Then, integrating the Staking Economy, the algorithm of Optimistic Rollup, Game Theory, Smart Contract, etc., we could define a contract to regulate Meta Collaboration, let’s call it Meta Staking Contract (MSC). MSC leverages the staking deposit as the guarantee for each Meta Collaborator to act as their promise. When both Meta Collaborators have staked deposit into the escrow account of the Meta Staking Contract, the Meta Collaboration is established. Super easy!

But how does Meta Staking Contract protect the benefits for all the collaborators?

In the collaboration process, by default, both Meta Collaborators are deemed to act coordinately and as their promise. So, when the Meta Collaboration is finished, the status of the staked deposits will be changed to to-be-allocated, and these deposits will be automatically returned after 2 weeks of Challenging Period.

However, if any collaborator (aka "Bad Party") broke its promise, the other collaborator (Good Party) can apply for Arbitration service right away, the to-be-allocated deposits will be revoked, the Meta Staking Contract will be suspended. According to the arbitration result, the Bad Party will be punished.

The revoking and Arbitration mechanism of the Meta Staking Contract enables every distributed collaborator to build up a DAC to establish and maintain a collaborative relationship with another collaborator quickly, protectively, and without any permission. With Meta Staking Contract, it is very convenient to govern the distributed collaboration and highly efficient to scale.

The DAC business implementation layer

Managing the business implementation of distributed collaborations is the hardest part. Referring to the OR mechanism, we can place each Meta Collaboration onto a sidechain so that Meta Collaborators can discuss, negotiate and confirm the collaboration details off the chain by themselves, which helps to reduce the pressure for the main chain.

However, this is far more than enough for these collaborators to manage the detailed business implementation. A systematic framework should be provided for them to facilitate the collaborations, which includes two complementary components, Transactions Statement Contract (TSC) and Microservice Tools Pool (MTP).

So, how does this framework help with collaboration management?

Transactions Statement Contract will be deployed on the sidechain, and it converts the milestones information of a transaction that both Meta Collaborators agreed into a standard contract template, which includes seven factors, Context, Boundaries, Goals, Measurable Results, Input, Activities, and Output. The template enables all the Meta Collaborators to coordinate on the same page, which is very easy to record, validate, and propagate.

In Meta Collaboration, all the Input and Output are data-lized, so Microservice Tools Pool should be set to provide microservice tools/APIs for implementing specific Activities to accomplish the conversion between data and value. Based on the consensus defined in the Transactions Statement Contract, microservice tools/APIs are leveraged to execute various Activities to achieve Measurable Results. The Output of the microservice tools will be recorded on Wiki, and the Wiki linkages will be recorded onto the side chain.

The deliverables will be audited off the chain by the related party and uploaded on the main chain regularly. If the result complies with the requirements, the framework will call Meta Staking Contract to do the incentive allocation. If there are any disputes in the collaboration process, the framework will call Meta Staking Contract to do the governance job.

Values and Use Scenarios

Collaboration is the most basic layer for value creation. With the framework and practice I described in this article, you will find it very easy to build up a DAC, to govern the collaboration relationship with other collaborators, and to manage the whole business implementation.

The framework is highly scalable with support from sidechain, and we could add more microservice tools, such as communication, payment, knowledge management, events, etc., to support more use scenarios.

The framework will also disrupt the traditional way to launch DApps. Developers can refer to the Meta Staking Contract, the management framework, and the microservice tools pool to launch a DApp very quickly.

If a developer calls the Meta Staking Contract, the management framework, and the Wiki microservice, a distributed Wikipedia or Quora style application will be created. If another developer adds the chatroom microservice, a distributed and private community application will emerge.

This framework and practice will have considerable value and applications in the sharing economy, gig economy, crowdsourcing, crowdfunding, social community economy, volunteers, etc.

Last but not least, cross-domain collaboration is an excellent match for Optimistic Rollup. The practice I introduced above will become one of the cornerstones to support the development of Web 3.0.

Contributed by Kevin Liu and Steven Guo.

Related Articles