This may be a dumb question but would an EVM chain on Polkadot benefit from a rollup since Polkadot chains do not suffer from rising gas fees like Ethereum? Would the benefit in this case come from being able to process more transactions than what the EVM chain is able to handle?
1 Like
Polakdot is a roll up for parachains.
A zk roll up has worse latency than polkadot in block times, and costs maybe a million times more CPU, but provides a cryptographic threat model. An optimistic roll up has worse latency than polkadot via unbonding times, but could operate cheaper than polkadot if you ignore the opertunity costs. Yeah, some low security parachain ideas make sense, not sure how much they resemble optimistic roll ups though, maybe more state channels? I donno yet…
We want elastic scaling to permit full parachains to buy multiple cores to make multiple blocks per relay chain block. We’ve no idea how many block per relay chain block yet, but likely this depends upon the parachains own infrastructure:
I’d expect a single big EVM collator could make 10s of blocks per relay chain block, but this lacks decentralized liveness, even while polkadot provides decentralized soundness+safety. Alternatively, an EVM parachain with more decentralized liveness could employ elastic scaling alongside other decentralization ideas.
Also, there were 40? maybe 60? different ideas for sharded EVM in the Ethereum world, including restrictions upon EVM itself, but all of which they abandoned in the roll up centric story. And some do not even require elastic scaling.
I think polkadot needs (a) elastic scaling and (b) multiple EVM parachains trying to prove their state sharding model is best, so one step forward is to collect the relevant EVM state sharding proposals from ethresear.ch. I’ve seen a big list somewhere, but not recently…
10 Likes
Let me make sure I understand this correctly:
- A parachain is itself akin to a rollup.
- You are suggesting if the parachain itself has another rollup that helps it progress faster?
In any case, I don’t think the answer is specific to EVM in any way, but rather be about any blockchain application logic.
Also, what hurdle do rising gas fees pose to rollups?
true
That is what I would like to know, specifically a zkRollup.
It is akin to the limitations of the Polkadot/parachain protocol. However, for my particular use case, I am thinking of how I could help scale Moonbeam - I will steer the conversation in that direction.
This is actually I question I have myself specifically to Moonbeam. If the Moonbeam network were to experience increasingly high volume, will rising gas fees be an issue akin to Ethereum? How bad can it get? Are the scalability issues for Moonbeam only rising gas fees or are there other issues?
I do believe a zkRollup for Moonbeam could help.
Do we have somebody from the Moonbeam team here to speak?
You clearly didn’t read what I wrote above…
We’ll do elastic scaling next year, so then polkadot could receive a sequence of parachain blocks for different cores, and check all their state roots line up in inclusion, but pretend they’re unrelated parachain blocks during backing, availability, and approvals. After elastic scaling, parachain throughput should depend upon the collator infrastructure more than upon polkadot itself.
We’ll likely make chains buy multiple cores ahead of time, aka an on-demand parachain cannot buy 20 parallel blocks, but a parachain who owns multiple cores can double or triple their throughput for as long a they can afford to. Or something like that.
You could run one fat collator which makes 10s of blocks per relay chain block, which polkadot then validates using elastic scaling. You’d have only centralized liveness then, but you’d stuff have decentralized soundness and safety.
An established project like Moonbeam likely wants decentralized liveness too, which requires more cleverness. In fact, Moonbeam could buy more cores and do this now without elastic scaling, but this brings even more complexity.
All current zk roll ups costs 1-100 million times the CPU cost of a single verifier, according to Justin Thaler. Polkadot costs around 35-ish verification, so parachains should be 30,000 to 3 million times cheaper.
In concrete terms, a recent RISC-0 example takes 1 hour and $25 of CPU time to make quite small blocks. Ain’t easy to make blocks if you’ve 1 hour of latency before finality, but if you could arrange this then 6 second block times would cost $128 million per year, or maybe closer to half a billion if you fix the block size. That’s crazy expensive.
2 Likes
I get what you are saying now.
So when chains from other ecosystems start having scaling issues, we will have a nice solution for them.
We can think of Polkadot’s approval-checking protocol as an alternative proving system to ZK approaches, one which inherits Polkadot’s threat model via staking as opposed to cryptographic proving. I typically refer to this approach as re-execution proving, because validators re-execute the computation they are proving.
With that in mind, we should separate two things:
- The proving mechanism used to ensure valid computations
- The application interface built on top of (1) used to execute and scale
Rollups are in bucket (2), Parachains are in bucket (2), ZK is in bucket (1), Re-execution proving is in bucket (1).
There are various key differences to ZK proving and re-execution proving which lead to differing Data Availability burdens, proving times, hardware choices, etc., and they aren’t quite possible to be compared directly in price. However, it’s unlikely that ZK proving will ever get as cheap as re-execution proving for the simple reason that modern ZK proving techniques require the computation to be executed, recorded, and then proved rather than just executed. But more to the point…
We should investigate alternative application approaches built on top of re-execution proving which can functionally provide on-demand scaling resources to things like parachains or smart contracts, and furthermore look to decouple re-execution proving and parachains in our mental models to expand the search space for new ideas. Elastic scaling is one such example, but not the only possibility.
4 Likes