1104 - Mystique EVM and Protocol Upgrades

[realcodywburns]

Enable the outstanding Ethereum Foundation London network protocol upgrades on
the Ethereum Classic network in a hard-fork code-named Mystique to enable
maximum compatibility across these networks.

Abstract

Add support for a subset of protocol-impacting changes introduced in the
Ethereum Foundation (ETH) network via the London hardforks. The proposed
changes for Ethereum Classic's London upgrade include:

EIP	Eth PR	omit or include
3198 (BASEFEE opcode)	#22837	Include
3529 (Alternative refund reduction)	#22733	Include
3541 (Reject new contracts starting with the 0xEF byte)	#22809	Include
1559 (Fee market change)	#22837 #22896	Omit
3228 (💣 delay)	#22840 and #22870	Omit

Specification

Technical specifications for each EIP can be found at those documents
respectively:

• EIP-3198: BASEFEE opcode
• EIP-3529: Alternative refund reduction
• EIP-3541: Reject new contracts starting with the 0xEF byte
• EIP-1559: Fee market change
• EIP-3228: 💣 delay

[stevanlohja]

📅 Save the date, Aug 20, 2021, Mystique is part of the meeting agenda. #434 (comment)

[tvinhas]

Can we file a new EIP to ban Donald McIntyre from ETC?

[OmniEdge]

Good poke :-) Of course anyone can file a new EIP. Banning historically only happens in EIP. On ECIP it wont find rough consensus. Keeping that culture in ETC alive is what makes that fine but crucial difference.

[DonaldMcIntyre]

Can we file a new EIP to ban Donald McIntyre from ETC?

[realcodywburns]

further context around eip-3541:

The evm object format eip-3540 is the intended future state of the evm for blockchain in the future.

The EOF format requires having unique prefix bytes not previously deployed to the blockchain. To freeze the search space,
EIP 3541 (https://eips.ethereum.org/EIPS/eip-3541) has been activated in the Ethereum London upgrade this August.
If we consider using EOF in future, and be wish to compatible with the EOF prefix, we should activate EIP-3541 as soon as possible.

[iquidus]

I propose aiming for mainnet activation at block 14,308,403, this will land mid January after the holiday season.

[bobsummerwill]

That makes sense to me. Would you agree, @diega?

[diega]

I totally agree

[realcodywburns]

Are the clients ready for mordor activation next week?

[diega]

Tomorrow we'll perform an internal test with @ziogaschr to define

[diega]

update: we attempted a private fork activation and it failed, probably regarding some issue on the mining module

[diega]

After our testing session we may need to revisit some of the decisions made for Mystique around adding EIP-3198.

EIP-3198 requires EIP-1559 and, as such, its behavior when there is no baseFee block header is undetermined. E.g. Besu implements it halting the EVM with an INVALID_OPERATION but at the same time consumes 2 units of gas.

I think our options can be summarized as follow:

1. not implement EIP-1559, not implement EIP-3198
2. not implement EIP-1559 and make BASEFEE to return 0
3. partially implement EIP-1559 adding the baseFee header always equal to 0 and implement EIP-3198

I would personally advocate for 1. because if ETC is not implementing EIP-1559, any behavior we decide for EIP-3198 won't keep compatibility

In any case, I would propose to postpone every date mentioned in ECIP-1104 by one or two weeks.

cc: @ziogaschr

[bobsummerwill]

I agree that (1) is probably the best choice. Better to omit both EIPs.

1559-style transactions aren't possible in ETC, so use of BASEFEE does not make sense for ETC either.

I am also supportive of a deferral of Mordor/Kotti activation for Mystique while we work through this specification discussion and until we have working client software for that specification.

[ziogaschr]

Based on the partially implementation of (3), I think I prefer it, as if it's not that much code, then it worths keeping ETH backward compatibility as long as possible. On the other hand, I don't think many contracts are using the BASEFEE opcode already.

[q9f]

I'm leaning towards 3 and agree to postpone the activation a bit. It seems we need more insights first.

[DonaldMcIntyre]

Seems the choice that maximizes EVM compatibility in the present and going forward without changing the monetary policy (e.g. no changes in fee model nor fee burning) would be most appropriate.

[diega]

I'm not quite sure that we can say we are EIP-3198 compatible if we don't fully implement EIP-1559. I don't think the value returned would have any valid semantic in the terms of the spec of EIP-3198.
Regarding (3), I'm not convinced that changing the block format in order to hardcode a value is a good idea.

[realcodywburns]

Watched the dev call, all seems good. I think it is good to move forward with the fork even if it is only two seemingly minor changes. omitting eips is as important as including them sometimes.

[diega]

FYI, I just updated #452 with the agreements of the call, it's up to review

[stevanlohja]

Should the proposal be updated to Accepted status?

[diega]

You're correct. This is the corresponding PR