A Technical Exploration of Optimistic Rollups in the context of Collaboration

Optimistic Rollups (ORU) is a type of layer two constructs that aims to provide low gas and high TPS simultaneously. Readers can read more about the details of ORU here. Earlier, Optimism has already released an alpha version of the OVM and a gamified demo partnering with Uniswap. Things look very promising.

However, when people look at ORU, most of the use cases focus on payments. An article from Kevin briefly studied how ORU can be used to improve collaborations on Ethereum.

This article aims to explore technically about the feasibility, discuss the limitations, and outline improvements we proposed to a specialized ORU construct for collaboration.

A Walkthrough of the Simplest Collaboration

Compared to payment scenarios, a collaboration is quite different because collaboration is never a single transaction. At the minimum, a collaboration involves two parties. The simplest collaboration consists of the following steps:

1. Initiate
2. Acknowledge
3. Pay

Let’s expand it one step at a time in the context of ORU.

Initiate

Collaboration must have an initiator responsible for setting the expectations, including the terms, rewards, and conditions. This step involves deploying, on the L2 chain, a Meta Staking Contract (MSC), as illustrated in Kevin’s article.

But at the same time, MSC will require a deposit of some tokens from L1. The process flow will look like this:

1. Stake the required tokens.
2. Pay a bonded aggregator in L2 the required gas
3. Deploy MSC on L2 by sending the transaction off-chain to the aggregator.
4. Notify the Collaboration listing on L2 that a new Collaboration request is posted.

Stake

The first step involves a token deposit from L1 to L2. Here comes our first limitation. Currently, token deposit from L1 to L2 or withdraw from L2 to L1 is not yet fully supported as of the day this article is written. It means the “staking” required by the MSC contract is not true staking.

The initiator can use the tokens that already exist on L2 to deposit. But tokens on L2 has no actual value without a proper connection to the tokens on L1. It is a deal-breaker not only to the collaboration applications but also to the payment use cases.

Understandably, this area is the focus of ORU community. Active development is going on as we speak, such as this PR, which looks very promising. I believe within six months, the intercommunication between L1 and L2 will be greatly enhanced.

Aggregator

The second step is optional, as the aggregator itself determines the fee charged by the aggregator. As part of the project, Metis will provide an aggregator that comes with zero gas cost, i.e. all users of the Metis platform do not have to pay anything to submit the transactions.

Here is the second area that we need to enhance the construct with. The aggregator in ORU, by default, is permissionless. However, we do not want to open a free aggregator to anyone.

The aggregator can be free to use because users of the platform will generate activities that will cover the aggregator’s cost. Note that the aggregator needs to pay gas whenever a block is submitted to the L1 mainnet.

Thus, an enhancement we need to make to the aggregator is to add a permission layer. The permission layer reads the live state on L1 from a permission contract to determine the initiator’s privilege and decide whether to honour the transaction. However, the permission will not just be whether a user can interact with the aggregator or not. It requires more granularity on the collaboration level. We will discuss a bit more about this topic in the later section related to security and privacy.

Deployment

This step is the most straightforward. The user will submit the transaction to the aggregator. The aggregator takes the calldata that contains the encoded JSON string representing the contract opcodes and computes a local state by executing the opcodes in the OVM.

The current limitation, such as block number and timestamp, will not be a problem with MSC. The timestamp used in MSC, such as during the project or, in a more complicated situation, a dispute are all relative timestamps are fine because we only care about the duration passed since the last operation.

The contract can quickly work around the limitation by referencing the execution Manager’s timestamp construct.

Notification

This step involves a new operation that we haven’t discussed in this article yet. The user will need to notify others that a new collaboration is available by inserting the new MSC contract’s address to the collaboration listing contract.

The collaboration listing contract was deployed on L2 already. The user needs to submit a transaction to the aggregator and the call data that contains the address of the newly deployed MSC contract to finish the notification. The aggregator will then compute the local state, which will be available for others to query later.

Acknowledge

The other party involved in our simplest collaboration needs to answer to the request put by the initiator. An acknowledgment, in this case, means the acceptance of the terms and the delivery of the service. This phase involves the following steps:

1. Read the current state of the Collaboration listings and notice a new collaboration is available
2. Accept the request
3. Deliver the requirements

All three steps involve similar operations, as we discussed in the previous section. First, the participant will query the aggregator to get the current state of the collaboration listing.

Noticing there is a new Collaboration, the participant will query the aggregator for the corresponding MSC contract’s current state. Knowing that the collaboration is exciting and profitable, the participant will submit the transaction to the aggregator to accept the request. The delivery of the requirement is also a transaction, which will insert the deliverable URL itself.

Every transaction here happens on L2 with zero cost (if permissioned) and high responsiveness. It is the true beauty of ORU in the context of collaboration. In a more complex scenario, the two parties will go back and forth about requirement changes and status updates.

Without ORU, a collaboration on-chain is too cost-prohibitive and extremely unproductive.

Pay

This step is the same as other payment solutions on L2. We will not expand in this article. But as we have discussed in the Stake section, without L1<>L2 communication fully implemented, it is hard to get serious about ORU application. But token deposit and withdrawal will be available very soon.

Another point I want to make here is that, though the operation involved to complete the payment is straightforward, i.e. call an ERC20 contract method such as transfer(), the logistic of the payment in collaboration is not! And I will expand this in the next section.

A Chicken-and-Egg situation

Imagine you are a UX designer. You want to make some income by helping design for others. One day you noticed a collaboration asking for help with some design is available.

Happily, you accepted the task and provided the design. Naturally, you received the tokens as a reward. All good and happy, right?

Now comes the catch. A watchtower found that the block that deployed the MSC contract is invalid, the transaction got reverted because the initiator didn’t have enough stake from L1.

All the associated transactions will be reverted as part of the fraud challenge. The rewards no longer belong to you. However, the initiator already got the design for free! This is bad.

Will enforcing that the payment has to be confirmed, i.e. passed fraud challenging period before a deliverable help? Not really, the initiator may lose the money without getting any deliverables delivered. It is a classic chicken-and-egg situation.

So how will we ever get into this situation in the context ORU? It must involve collusion between a participant and an aggregator. A dishonest aggregator may temper the local state and eventually trigger a revert of transactions.

During this process, the aggregator will lose a portion of the bond. However, the colluder may compensate the aggregator accordingly to incentivize the tempering.

To remedy the situation, we propose the following enhancement to the construct:

1. The bond lost due to invalid blocker increase exponentially with the number of offences. It is to discourage repeatedly dishonest aggregators.
2. The reward of the collaboration involved cannot exceed the potential loss of the bond. It is to discourage aggregators from colluding with participants of the collaboration.

With these two measures put into our specialized ORU construct for collaboration, the collaborators will be pleased to know that the work and the investment will always have corresponding rewards.

Security and Privacy

The last thing I want to discuss in this article is some unique privacy requirements related to collaborations. Often, a collaboration requires confidential information, including contact info, the project requirements and the deliverable itself.

Some participants may not want to make all info public. Thus, encryption of calldata is always desired. But to add another layer of protection, the permission layer can be extended to be on the collaboration level. It involves a permission management contract on L1 to keep track of the participants’ status, which is readable to the aggregator.

In this way, only the participants of the collaboration can read and modify the collaboration state. In the case where an encryption key is compromised, the collaborator will still be able to keep the information safe on L2.

However, the story is not the same on L1. Because the aggregator will publish the states and transactions to the ROLLUP_CHAIN contract on the mainnet, an observer on L1 will be able to read the states.

Thus, in our specialized construct, we propose to add another special data scramble layer to the published state and the transactions by the aggregators. The data anonymization layer does not change the transaction logic and is per collaboration based. Here is a quick example to illustrate how it works.

Assume the transaction contains the following pseudocode:

function foo(address user1, string calldata url) external {
balance[user1] += 10;
if (balance[user1] > 100) {
user1.transfer(100);
}
deliverable = url;
}

There we have three types of operations.

1. Modify the values such as balance[user1]+=10 and deliverable = url
2. Test the value such as if(balance[user1>100])
3. Call a method of another contract such as user1.transfer(100)

To ensure the logic of the transaction is still valid after the anonymization. We will only anonymize the first type of operation as long as the value is not involved in the second type of operation in the current contract AND other contract methods that use the value as the input.

The anonymization proposed we proposed will utilize a hash table mapping per collaboration to ensure local consistency. Plus, the anonymization only applies when the aggregator publishes the transactions to the ROLLUP_CHAIN contract.

On L2, the collaborator will be able to access the unscrambled data. It does require the aggregator to maintain a separate state and transaction data for local access. But we believe it is a price worth paying for the optimal security and privacy coupled with low cost and high efficiency.

Conclusion

We have explored the simplest collaboration scenario and identified may current limitations. We have discussed the proposed enhancement to the construct in the context of collaboration.

The welcoming flexibility of the ORU construct allows us to build a specialized construct for collaborations. Here I would like to thank the Optimism team for their ideas and support. The expanded use of blockchain is coming soon. 2021 will be an exciting year for collaboration.

Contributed by Yuan Su