Scaling Solomon part 2
Comparison of Layer 2 solutions
In a previous post, we discussed a few possibilities for scaling Solomon. We reviewed sidechains, state channels and rollups at a high level, in order to explore ways to reduce gas costs without compromising security or functionality. In this post we will dig deeper into a few of these options to get a better understanding of whether they can meet our requirements without extending the development timeline too far. In the first Layer 2 post we called out optimistic rollups as the most promising solution, so include details of our thoughts on state channels and Polygon vs. rollups, and then go into specific rollup implementations.
State Channels vs Optimistic Rollups
We first looked into the possibility of using state channels as part of a hybrid mainnet/layer 2 approach, to reduce gas costs for our more complicated on-chain interactions, particularly the juror voting process. We reviewed a project called statechannels.org (previously known as Counterfactual) which is an open source project working to create a standard for state channels for the Ethereum community. State channels are typically useful for transactions between predetermined parties that need to transact multiple times within a certain duration. At the same time, we did a gas cost analysis of our contracts and found that the most expensive operations were the following:
- Deployment of dispute contracts
- Assigning jurors to initialize the voting process
- Initial and subsequent vote submission
- Staking/unstaking of SLM tokens
- Tracking stakers in the staker pool
The result of the analysis is that we realized state channels might not be the ideal solution for us. State channels provide cost savings for only one of the expensive processes that we need to execute on a routine basis (vote submission). More importantly, substantial efforts would be needed to revise the contracts to allow us to integrate channels alongside the current Solomon ecosystem. It would essentially be replacing part of the SlmJudgement contract functions that pertain to voting and reducing it to solely keep track of state, such as final vote status and juror records. The channel would create and settle the dispute contracts based on the voting result, and process payouts to relevant stakeholders such as the winner of the vote and administrative contracts/wallets that keep track of fees.
On the other hand, optimistic rollups can help provide a more comprehensive solution involving fewer modifications to the contracts. The following table is a high level comparison of the benefits state channels and rollups might provide to the Solomon project.
Polygon vs Optimistic Rollups
Polygon is a project developing a collective development suite of solutions for scaling Ethereum. The project was previously known as Matic, getting its name from the Matic Network that launched in 2017. Polygon is their main product, which is their own implementation of the plasma chain. It operates on a proof of stake model, and the chain is parallel to the Ethereum mainnet. The project has gained a large community around its POS chain, being one of the older and more tested solutions on the market. According to its website, over 7000 dapps currently scale using Polygon.
Although Polygon seems like a comprehensive solution, given the multiple solutions listed in its development suite, most of them are still in development. The main functional solution is the POS sidechain. It’s worth noting that the project acquired Hermez last year, a network that makes use of ZK-rollups for payments and is developing its own optimistic rollup solution. One benefit that ZK-rollups has over optimistic rollups is that they potentially have faster withdrawal times. However, there have been reports about complaints related to long withdrawal periods on Polygon.
Another concern with Polygon, and most other side-chain solutions, is that it has its own consensus model outside of Ethereum which would be considered less secure and less decentralized compared to the mainnet. Although Polygon aims to become more decentralized as time goes forward, the current level of centralization is concerning. It is understandable since Polygon is much smaller and newer and is currently only secured by MATIC staking, whereas Arbitrum relies on miners on the Ethereum mainnet. For this reason, optimistic rollup solutions provide a greater level of security.
Arbitrum vs Optimism
When reviewing optimistic rollups, the main solutions we compared were Arbitrum and Optimism. Although quite similar at surface level, there are some differences in their optimistic rollup implementations. An important point is that Arbitrum supports the use of all EVM languages, including all versions of Solidity, while Optimism currently only supports specific versions of Solidity. The greatest differences reside in the way these two projects handle dispute resolution. Although both use fraud proofs, Arbitrum uses multi-round fraud proofs which more precisely pinpoint the fraudulent transaction. Optimism uses single-round fraud proofs which send all transactions to the EVM to process and identify the issue. The impact of these differences mean that Arbitrum will generate a greater cost savings as a result of it passing less data back to the EVM and therefore will also equate to greater transaction capacity. Optimism, on the other hand, will operate much faster since it will just send all of the transactions to the EVM in one go, though the transactions are limited by mainnet gas maximums.
According to l2beat.com, the total value locked in Arbitrum is much higher than that of Optimism. This is probably due to the fact that Arbitrum has been deployed to the mainnet for a longer period of time (called Arbitrum One), and gathered more support from projects in need of a comprehensive scaling solution. Optimism released later and is currently undergoing updates to its system of handling fraud proofs. Taking into consideration the network effects, greater security and gas savings, Arbitrum seems to be a more attractive option at the moment.
One of the main disadvantages of both projects is the long waiting period for withdrawals due to the challenge period. Projects like Hop Protocol help to reduce this wait period by providing a token bridge that accesses market maker liquidity pools. This allows users to move funds from one rollup to another rollup, sidechain, or Ethereum right away for a fee without having to go through the entire challenge period.
More info on Optimism, Arbitrum, and Hop Protocol:
- Optimism: https://www.optimism.io/
- Arbitrum: https://arbitrum.io/
- Comparison of fraud proof implementation: https://insights.deribit.com/market-research/making-sense-of-rollups-part-2-dispute-resolution-on-arbitrum-and-optimism/
- Hop Protocol: https://docs.hop.exchange/faq
Optimistic Rollups vs ZK-Rollups
On paper, ZK-rollups appear to be a promising solution for solving the Ethereum scaling issues we currently face. However, the technology currently isn’t at a production-ready state for general applications, and there are not yet any solutions we would feel comfortable using in Solomon. Current ZK-rollup solutions are very application-specific and aren’t EVM compatible, so making use of them would require substantial time and development effort. There are projects like zkSync that are in the process of creating a ZK-rollup solution that will be EVM-compatible, but further testing and development is necessary.
ZK-rollups have the potential to be a very effective scaling solution for Ethereum, but are still not ready for general use. Optimistic rollups are available now, and can be used in dapps without needing too many code changes. The question of which one to implement now is difficult, because the timeline of ZK-rollups is not guaranteed, but it would be unfortunate to move forward with optimistic rollups and later need to migrate the project. It is important to note that optimistic rollup solutions, although deployed to the mainnet, are still either in beta (Arbitrum) or going through frequent updates (Optimism), and it might be prudent to take a step back to make further observations and testing.
In the next post, we will finally decide on a scaling strategy, and discuss what it means for the project moving forward.
