ethereum: metropolis #3757
ethereum: metropolis #3757
Conversation
|
@obscuren, thanks for your PR! By analyzing the history of the files in this pull request, we identified @fjl, @karalabe and @Gustav-Simonsson to be potential reviewers. |
|
I browsed the changes a bit, although I know it's still WIP. One question: during the window that the code is released, and the actual fork, the ops will be invalid operations, and throw error like this . However, they'll still be defined with stack requirements and gascost. So, afaict, the operations will verify stack and gas prior to erroring out due to invalidness. Is there any way that this can cause unforseen consequences, e.g. by having an |
|
@holiman it shouldn't matter. The only err check that is performed is done on the |
obscuren
force-pushed
the
metropolis
branch
4 times, most recently
from
0d8df4b
to
706248a
Compare
|
Please submit crypto/bn256 separately. It can go in long before metropolis. |
core/vm, crypto/bn256: added bn256 curve and added precompile core/vm: use crypto/bn256 crypto/bn256: exported P constant core/vm, crypto/bn256: pairing pre-compile core/vm: added pairing test core, crypto, internal/ethapi, params: fixed tests core/vm: fixed nil length input for pairing
The REVERT op codes reverts the state by returning an error from the instruction. The instruction was checked during in the EVM. This error would then determine whether any gas should be consumed or not. If the error was an errRevert, no gas was further reduced and only state was reverted. This solution is error prone as you'll need an err check in multiple locations and removes the no-err check requirement of the evm. This has been solved by passing the snapshot to the interpreter and letting the interpreter do the state reverting if the operation so requires.
The Metropolis PR
This Pull Requests contains all code for the Metropolis PR, which used to be separated in to several smaller PRs.
Please note that this is a Work In Progress: any of the parameters may change at any given time and this PR should not be considered leading. Please refer to the individual EIPs for more information.
EIP #198: Big Integer modexpEIP #140: REVERT opcodeEIP #116: STATIC CALL opcodeEIP #100: Difficulty adjustment including unclesEIP #98: Receipt state root removalEIP #86: Account abstractionEIP #XXX: Pairing pre-compileEIP #197: bn256 scalar mul and add pre-compilesEIP #XXX: RETURNDATA{COPY, SIZE} opcodesAPI Changes
ethash.CalcDifficulty(time, parentTime uint64, parentNumber, parentDifficulty, *big.Int)->ethash.CalcDifficulty(time uint64, parent *types.Header)and all child calls (e.g.calcHomesteadDifficulty) no implementation changes other than using the parent header and added metropolis difficulty calculation function.statedb.StartRecord->statedb.Prepare(no implementation changes)statedb.Finalise: used post metropolis and deletes all suicided objects and cleans up the journal. Called after a transaction has been processed but prior to creating the transaction receipt. Is similar toIntermediateRootwith the exception that it does not calculate the intermediate root.