Alternative proposal for early eth1 <-> eth2 merge

Basically, to make witnesses viable we would need gas cost changes the look something like the following:

  • SLOAD goes up to 1000-2000
  • Any opcodes that access other contracts go up to 1000-3000
  • Calling a contract (and hence running its code) further costs an additional 1-2 gas per byte of code

This would actually be not that punitive to average applications, though many apps would need to rearchitect themselves to use fewer full-sized contracts. There would be some exceptional applications that become considerably less viable. A simple ERC20 transaction (including DAI) would maybe become at most ~5-10% more expensive.

2 Likes

I should have been clearer what exactly I was asking.

For many contracts the repricing you mentioned won’t be a significant issue, but the size limitations may well be. Do you know if it will break the Dai contracts? Redeployment of Dai is an enormous undertaking.

There may be some other such contracts where a redesign and redeployment will have systemic impacts like that too.

From an eth1 perspective, does this proposal not already reduce the requirements to create blocks from eth1 node+ eth1 mining rigs down to just running a eth1_friendly_validator node without needing the miners?

While stateless clients will remove the node requirement, this hybrid removes the biggest burden to creating blocks in eth1, which is the mining: many more people can do stateless than can hold state, but many, many more people can hold state than can mine, and the merge moves a long way down the desired path.

It may also simplify transition significantly as it starts from existing nodes and welcomes in new ones (ie people who can hold state but not mine).

3 Likes

Ah, the size limitations would be implemented through the repricings. No single contract is larger than 24 kB, and there’s no single system of contracts that gets called in a single transaction that’s more than a few times that AFAIK.

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.

2 Likes

So, Maker could move its contracts into that cache through some kind of process during the migration, grandfathering them in if the size were too large?

What would be the process of having contracts added to the cache, and for having them removed?

Using GST2 (GasToken) would be the recommendation for contracts?
Is gasless dai (https://gdai.io) ready for this update?

1 Like

I totally agree with this proposal … saves ton of time and effort

1 Like

Very likely the best thing we can do:

  • Probably accelerates having a solid eth1/eth2 connection by about 2 years
  • Brings the benefits of PoS to Eth1 immediately
  • Actually makes the phase 1 data availability engine usable
  • Solves the Eth2 -> Eth1 bridge conundrum

The cost is that the Eth1 legacy is likely to be carried into Eth1 for the foreseeable future. But I think that’s a price worth paying, and it’s paid off in the past in technology transitions to keep compatibility to the main industry standard (which is currently Eth1 for smart contracts). That’s why x86-64 was successful and IA64 was not.

I see the biggest danger in doing this without solving the state rent problem. This means there might be state arbitrage between the Eth1 and Eth2 subsystems.

3 Likes

I’d be inclined here to not solve the state rent problem, but instead provide a ramp up for transaction costs. Why?

  • state rent on Ethereum 1 is hard. Any attempt to add state rent must consider many assumptions made in the contracts already deployed, and either incorporate them into the model or ignore them and suffer the consequences
  • state rent on Ethereum 1 is not part of the deal. State was paid for according to the model laid down at the time the contracts were created. Forcing a change will result in any number of situations where users can legitimately complain that changing the rules after the fact has caused their contract/app/business pain, and will reduce their desire to either migrate or rearchitect their contracts on Ethereum due to concerns this is just the first of a number of such changes
  • the whole point of a transition is for it to be smooth. If it isn’t smooth it may as well not bother happening at all; forced active migration is the worst of all worlds

So how to merge without causing unnecessary hardship? I’d go for a staged approach:

  1. merge without changing any of the established rules on the Ethereum 1 chain
  2. alter gas costs as required to fit the reality of the costs involved
  3. build the phase 2 EE(s) that will be home for new contracts (this would be a number of completely new EEs that would not necessarily follow Ethereum 1 semantics but would between them have all the functionality that Ethereum 1 smart contracts may need). These could co-exist on shard 0 with the Ethereum 1 chain or live on other shards; the only reason it may matter is if the EEs are allowed to access Ethereum 1 state directly
  4. after a certain amount of time make new contract creation on Ethereum 1 a very expensive operation (would have to consider how pre-existing contracts creating contracts are handled here)
  5. after a certain amount of time to allow for migrations, start to increase the base transaction fee for Ethereum 1 transactions over a long period of time (e.g. doubling every year)

The reason I’d go for something like this is that it gives the users and developers a clear upgrade path that provides them with benefits at each step of the way:

  • after the merge users have higher transaction throughput (which should also translate to lower transaction costs)
  • after the new EEs are in place developers have a higher throughput alternative to the Ethereum 1 chain for their smart contracts
  • once the Ethereum 1 chain becomes functionally obsolete users and developers can migrate to the EEs, resulting in cheaper transactions and avoiding the additional costs of the Ethereum 1 transaction ramp-up

The downside of this is that there is likely to be some sort of “final state” once all this has been done, holding contracts and (effectively) read-only data. Perhaps at this point we can start to think about how to manage the Ethereum 1 state, but anything before I’d worry would be premature.

2 Likes

How so? We can eventually hard-fork in a compilation of everything to WASM, and put it under the same EE system as everything else.

And as for the eth1 state, storing that state would be a voluntary thing, and so if it becomes unsustainable what would happen is that the UX of that EE would get worse over time until we are basically forced into one of two solutions:

  1. People migrate onto a better EE
  2. We add access lists, and block producers are generally only willing to deal with transactions that come with access lists and transaction-sender-provided witnesses

I do think we should start exploring details on both of those options ASAP.

1 Like

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.

in order to aggregate BLS signatures don’t all the signers need to sign the same message?

Nope!

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.

1 Like

My proposal was just “pay 0.01 ETH per byte to be on the registry”. But yeah, we could also do a caching approach.

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?

Hi, I have a question:

Why eth1 full node need to download all blocks on shard 0?