Hello. I’m a long-time Ethereum maxi application-layer engineer. I’m new to the Scroll community. I just want to start off by saying that I have been incredibly excited to start using Scroll since talking to the team at their ETH Denver 2023 booth.
I was skeptical of rollup-based scaling for a long time. I existed in application-layer hell doing silly NFT work during the bull run. Every scaling project was being misleading about the state of L2s and I had many discussions and debates as an ideologically-decentralized security maxi:
- sidechains like Polygon and Gnosis that are not proper rollups.
- alt-L1s with intolerable security models.
- Optimism launched without fraud proofs in “trust me bro” mode.
- optimistic mechanisms with fraud-proof-based slashing writ-large are unappealing to me.
I was without satisfactory scalability options. This ultimately led me to go down the ZK rabbithole; I believe only ZK rollups are able to perfectly preserve the security model of Ethereum L1. I believe they are the only mechanism whose only downside is increased latency if cross-rollup or to-L1 communication is needed. Henceforth being a ZK rollup maxi, I found myself disappointed with the offerings of Polygon, zkSync, etc. because they were type-4 or type-3 zkEVMs. I was also disappointed with their lack of total committment to Ethereum alignment. Then I finally found Scroll.
I have done extensive research and Scroll is the first rollup that I actually want to use because it feels like the first rollup actually designed for Ethereum maxis very concerned with maintaining the same security guarantees as L1. I adore everything from alignment with the Ethereum foundation to even the branding, and I cannot wait to build on Scroll. All of that being said, I have some decentralization concerns based on the L2 Beat criteria Scroll – L2BEAT. Namely, the three (out of five) areas where Scroll remains fully-centralized:
- Upgradeability: The code that secures the system can be changed arbitrarily and without notice.
- Sequencer Failure: There is no mechanism to have transactions be included if the sequencer is down or censoring.
- Proposer Failure: Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
I’ve done my own sleuthing on these issues looking at the Scroll contracts and reading the architecture docs and they seem like accurate concerns.
I’d like to ask if there’s a public roadmap that has been shared anywhere? Or any timelines that Scroll has committed to for trying to fix these issues? It’s heartbreaking when I did this last bit of research because Scroll is so close to being perfect in my mind and I badly want to see it get there. In my mind it would be enough to put the upgrade mechanism behind a timelock and supply any sort of escape hatch where users could rescue their assets by acting as their own sequencer/proposer in the event that the sequencer or proposer does die.
Thank you, hoping to get some answers from the Scroll team.