Of course that possibility exists, however I think it may well become much less likely once this infrastructure exists.
But yes it would not be technically any more difficult that it is now.
Another thought here: Can’t we leave the storing of Eth1 state entirely to relayers (which might be specialized Eth1 relayers)? Then we would not have to distinguish between Eth1 capable/non-capable validators, as all of them should be able to process Eth1 blocks once witnesses are added.
I’d probably have to agree here. The ideal outcome would be if we can support Eth1 as is at roughly current gas costs, and the new Eth2 ecosystem will just be way cheaper (due to sharding and PoS) even when factoring state rent in.
Current eth1.x work is putting this approach out of scope right now as it adds significant complexity to the incentives of the system. Remaining Questions on State Providers and Stateless Networks in Eth2 talks about this a little, and another writeup is coming that will state additional challenges (particularly on how the access-list approach has a few caveats). Also, the relayer (instead of state provider) approach can skew towards a number of issues - briefly described in this post and comment. Relayer has typically been used to describe an actor that packages the full block for the block producer vs. prepare witnesses for a user (state provider) which I think you are referring to.
I’m confused here… in order to aggregate BLS signatures don’t all the signers need to sign the same message? In a data-root bounty system, each fee payer wants to get their own unique data-root included in a shard block, so the [data_root, shard, slot, fee] messages would all be different and the fee payments couldn’t be aggregated.
Sorry, I confused a BLS sig with a “multisignature.”
Okay, the fee payers sign BLS sigs… but what accounts do fee payers have? Presumably fee payers are eth1 users and not validators on eth2.
For example, with the “data-root bounty mechanism”, fee payers are eth1 accounts and Block Proposers are eth2 validator accounts, and BPs get paid via eth1 (so an eth2 BP would have both an eth2 validator account and a standard eth1 account).
EDIT: for anyone wondering, the data-root bounty mechanism does not have a post or write-up anywhere. The only written mention of it that I’m aware of is in the first paragraph here:
Okay, the fee payers sign BLS sigs… but what accounts do fee payers have? Presumably fee payers are eth1 users and not validators on eth2.
Arguably, requiring fee payers to be eth2 validators is a totally fine approach by itself. Becoming a validator doesn’t require depositing 32 ETH; you could just deposit 1 ETH and then you’ll remain an inactive validator ID and you could use that to pay fees.
But even there we could mitigate the impact by having a “frequently used contracts” registry on eth1, which would have a few dozen megabytes of code that get accessed really frequently and would be expensive to join but could be accessed cheaply. This registry could then be moved to eth2.
Anyway this could be done “algorithmically”? E.g. up to 10 mb of contracts code are cached where the chosen contracts are the ones that were called the most frequently in the last N days, up to 10mb. Otherwise it feels like we could be adding a lot of politics as to which contract should be added or removed from that registry.
There s currently to 2 way to create contracts on eth1. Either from an existing contract or directly. What I m seeing is contract creation from contracts is used from projects like dai use fixed code lying in an existing smart contract whereas direct contract deployment is used for starting projects or as a way to update a project.
So why not prevent updates and new projects using the old chain by forcing using eth2 while letting old projects like dai to work until they update their codes to a new contract?