Tracking EIPS

[GregTheGreek]

Current research on the EIPS can be found under the ./research directory. To avoid bloating this issue I'll leave those notes there, further discussions should occur here. It should be noted that the research includes code snippets from www.github.com/ethereum/go-ethereum.

It was noted by @Aabell8 that go-ethereum has a different file structure than etc-ethereum, nonetheless the code snippets are still useable.

We should also cross reference ETC upcoming hardfork Atlantis - as pointed out by @soc1c

We will first complete ALL Atlantis EIPs then do the remaining afterwards!

Task	Atlantis	Assigned TO	PR #
EIP 100	YES	@Aabell8
EIP 140	YES	@Aabell8
EIP 161	YES	@steviezhang	#28
EIP 170	YES	@steviezhang	#23
EIP 196	YES	@noot	#24
EIP 197	YES	@noot	#24
EIP 198	YES	@noot	#24
EIP 211	YES	@Aabell8	#13
EIP 214	YES	@Aabell8	#22
EIP 658	YES	@Aabell8
ZK-Snarks	NO	N/A
RSA Signatures	NO	N/A

EIPS:

• EIP 100 Changes to the difficulty adjustment formula to take uncles into account ()
• EIP 140 Addition of 'REVERT' opcode, to permit error handling without consuming all gas
• EIP 196 Elliptic curve addition and scalar multiplication on alt_bn128
• EIP 197 Pairing checks
• EIP 198 Support for big integer modular exponentiation
• EIP 211 Support for variable length return values ()
• EIP 214 Addition of the 'STATICCALL' opcode, permitting non-state-changing calls to other contracts
• EIP 658 Transaction receipts to include a status field to indicate success or failure

Pre-compiles

• ZK-Snarks and other cryptographic mathemagic™

Nice to haves:

• Enabling RSA signature verification and other cryptographic applications

Edit 1 - Update description and added references to Atlantis hard fork
Edit 2 - Organized the EIPS by number
Edit 3 - Added Atlantis EIP's

[GregTheGreek]

From @soc1c:

clients that have this code implemented in go:

• https://github.com/ethereum/go-ethereum
• https://github.com/ethoxy/multi-geth

also, byzantium for classic might include eip 161 and 170

• ECIP-1054: Support for ETH Byzantium EVM and Protocol Upgrades etclabscore/ECIPs#10

[GregTheGreek]

from @GregTheGreek:

Thanks @soc1c :) Update the issue

[GregTheGreek]

from @Aabell8:

Not sure if I should be mentioning stuff like this here so let me know if I should be discussing elsewhere:

Seems like for EIPs [140, 658, 198, 211, 214] (maybe I am missing one) we will have to restructure how the instructions are called and the functions associated with them to achieve the functionality we need.

In etc, the jump table lookup references an object that looks like this:

 type jumpPtr struct {
	fn    instrFn
	valid bool
}

Where for EIP 140 for example it would be called with:

jumpTable[REVERT] = jumpPtr{opRevert, true}

*Edited this paragraph out because it wasn't relevant, check EDIT2

For reference, this is what the jumpPtr equivalent looked like after that commit:

type operation struct {
	// op is the operation function
	execute executionFunc
	// gasCost is the gas function and returns the gas required for execution
	gasCost gasFunc
	// validateStack validates the stack (size) for the operation
	validateStack stackValidationFunc
	// memorySize returns the memory size required for the operation
	memorySize memorySizeFunc
	// halts indicates whether the operation shoult halt further execution
	// and return
	halts bool
	// jumps indicates whether operation made a jump. This prevents the program
	// counter from further incrementing.
	jumps bool
	// valid is used to check whether the retrieved operation is valid and known
	valid bool
	valid bool
}
}

And this is what it looks like on the master branch:

type operation struct {
	// execute is the operation function
	execute     executionFunc
	constantGas uint64
	dynamicGas  gasFunc
	// minStack tells how many stack items are required
	minStack int
	// maxStack specifies the max length the stack can have for this operation
	// to not overflow the stack.
	maxStack int

	// memorySize returns the memory size required for the operation
	memorySize memorySizeFunc

	halts   bool // indicates whether the operation should halt further execution
	jumps   bool // indicates whether the program counter should not increment
	writes  bool // determines whether this a state modifying operation
	valid   bool // indication whether the retrieved operation is valid and known
	reverts bool // determines whether the operation reverts state (implicitly halts)
	returns bool // determines whether the operations sets the return data content
}

Called via:

	instructionSet[REVERT] = operation{
		execute:    opRevert,
		dynamicGas: gasRevert,
		minStack:   minStack(2, 0),
		maxStack:   maxStack(2, 0),
		memorySize: memoryRevert,
		valid:      true,
		reverts:    true,
		returns:    true,
	}

So to implement the EIP functionality changes we will probably have to make similar alterations, but possibly not all of the same as the structure looked different before the commit I referenced previously.

EDIT: Also might be important to note that gas calculations are calculated in the calculateGasAndSize function in core/vm/vm.go line 185 which is very centralized, but it may be beneficial to modularize it and put it with the op code lookup similar to how it is in go-ethereum repository now. (current gas calculation function includes all op code logic and is over 180 lines of code long)

EDIT2: Sorry I linked wrong commit, I meant to reference this commit which is the one where the structure was changed. That other commit was done recently, which separates the gas calculation into static or dynamic which I was also looking into.

[GregTheGreek]

from @Aabell8:

Upon looking more into the functionality of all of this stuff it seems it isn't necessary to make these changes, but it may save time in the long run if we are implementing all of these EIP changes and will definitely make the code more readable and better structured if we do this instead of just increasing the size of the functions that handle every specific case.

[steviezhang]

Hey @GregTheGreek , can I take EIP 170 and EIP 161?

[GregTheGreek]

Hey @GregTheGreek , can I take EIP 170 and EIP 161?

all yours!

[soc1c]

Did you talk with Terry about Constantinople yet? (aka Agharta)

Also, let's split up tracking issues into milestones. #18 #19 etc.

[GregTheGreek]

Also, let's split up tracking issues into milestones. #18 #19 etc.

That's fine.

Constantinople

Yep, we need to do a bit of admin on our end. Once we get state trie clearing tests in then we can proceed with implementing Constantinople on a seperate branch

[soc1c]

done in #18 and #20