Final Call: ECIP-1054 Atlantis Upgrade

[soc1c]

ETC Core Devs Call - Atlantis Finalization

When: Thursday, May 30, 2019, 3pm UTC, 60 minutes max.

Where: Ethereum Classic Discord https://discord.gg/dwxb6nf #ecips channel. Will use/create a voice channel ad hoc.

Agenda

• Quick client teams check-in
  • Geth / Multi-Geth
  • Parity Ethereum
  • IOHK Mantis
• Atlantis (ECIP-1054) is in "last call" state
  • ECIP-1054 needs to be either accepted or updated (or rejected)
  • discuss whether EIP-161 should be included or not @meowsbits @sorpaas
  • discuss any other EIP that might cause uncertainty
  • discuss timeline for the protocol upgrade
    • Morden Classic and Kotti Classic testnet (August?)
    • Ethereum Classic mainnet (September?)
• Anything else related to Atlantis
• Outlook: Agharta (ECIP-1056) if time permits
• Outlook: Astor SHA3 testnet if time permits

Please comment to add items to the agenda

[antsankov]

Would like to share progress on Astor SHA3 testnet

• What has been done so far,
• What are the next steps,
• Community feedback

https://astor.host - home page
https://stats.astor.host - stats page
https://explore.astor.host - block explorer

[meowsbits]

Sorry @antsankov, although I think it's great you're making progress in that space, I must say I motion against any topics that aren't directly related to the Atlantis fork in question for this particular meeting.

[meowsbits]

Related to EIP161:

• EIP168 "Killing dust accounts" will be useful background reference.
• EIP169 "Dust account replay security"
• Parity PR 4757 "EIP-168, 169: Dust protection"

• "A bunch of transactions were subsequently fired which cleared these spam accounts from the state."

• "... the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes."

• ... ...: anyone know exactly where these contracts are?

[soc1c]

@antsankov added it to the agenda (if time permits)

Note, this is tomorrow!

[realcodywburns]

the dust clean up isn't a contract, iirc. it is a change in transaction logic where by if a transaction is sent to an account the results in it being empty, the account is pruned. logistically, sending an transfer of zero value to all the empty accounts killed them.

[stevanlohja]

Does EIP-170 cause issues with existing large contracts on ETC?

if contract creation initialization returns data with length of more than 0x6000 (214 + 213) bytes, contract creation fails with an out of gas error.
Src: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-170.md

[meowsbits]

Introducing EIP170 as a feature that enables at and beyond a given block transition value (ie some block height n (the value for the proposed fork)) would not impact contracts deployed in blocks below that value. This is how go-ethereum and multi-geth handle this logic (below).

ret, err := run(evm, contract, nil, false)

	// check whether the max code size has been exceeded
	maxCodeSizeExceeded := evm.ChainConfig().IsEIP170F(evm.BlockNumber) && len(ret) > params.MaxCodeSize
	// if the contract creation ran successfully and no errors were returned
	// calculate the gas required to store the code. If the code could not
	// be stored due to not enough gas set an error and let it be handled
	// by the error checking condition below.
	if err == nil && !maxCodeSizeExceeded {
		createDataGas := uint64(len(ret)) * params.CreateDataGas
		if contract.UseGas(createDataGas) {
			evm.StateDB.SetCode(address, ret)
		} else {
			err = ErrCodeStoreOutOfGas
		}
	}

	// When an error was returned by the EVM or when setting the creation code
	// above we revert to the snapshot and consume any gas remaining. Additionally
	// when we're in homestead this also counts for code storage gas errors.
	if maxCodeSizeExceeded || (err != nil && (evm.ChainConfig().IsEIP2F(evm.BlockNumber) || err != ErrCodeStoreOutOfGas)) {
		evm.StateDB.RevertToSnapshot(snapshot)
		if err != errExecutionReverted {
			contract.UseGas(contract.Gas)
		}
	}
	// Assign err if contract code size exceeds the max while the err is still empty.
	if maxCodeSizeExceeded && err == nil {
		err = errMaxCodeSizeExceeded
	}
	if evm.vmConfig.Debug && evm.depth == 0 {
		evm.vmConfig.Tracer.CaptureEnd(ret, gas-contract.Gas, time.Since(start), err)
	}
return ret, address, contract.Gas, err

https://github.com/multi-geth/multi-geth/blob/master/core/vm/evm.go#L408

Parity:

	/// See main EthashParams docs.
	pub max_code_size: Option<Uint>,
	/// Maximum size of transaction RLP payload.
	pub max_transaction_size: Option<Uint>,
	/// See main EthashParams docs.
	pub max_code_size_transition: Option<Uint>,
/// Transaction permission contract address.

https://github.com/paritytech/parity-ethereum/blob/master/json/src/spec/params.rs#L111-L116

[meowsbits]

@realcodywburns gotcha... is there a list of dead accounts that need to receive a killer transaction? is there a record anywhere of who handled this cleanup and how on the foundation chain?

or just

for (a in allTheAccounts) {
 eth.sendTransaction({from: me, to: a, value: 0});
}

?