parse different versions of genesis config

[winsvega]

parse test genesis format
ethereum/retesteth#4

# Genesis config for running a StateTest via RPC
{
       "version" : "1",
       "params": {
            "miningMethod" : "NoProof",
	    "forkRules" : "Frontier",
            "blockReward" : "0x00"
       },
       "genesis" : {
            "coinbase" : "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba",
            "gasLimit" : "0x0f4240",
            "timestamp" : "0x03e8"
       },
       "state": {
            "0x095e7baea6a6c7c4c2dfeb977efac326af552d87" : {
                "balance" : "0x0de0b6b3a76586a0",
                "code" : "0x6001600101600055",
                "nonce" : "0x00",
                "storage" : {
                    "0x00" : "0x02"
                }
            },
            "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba" : {
                "balance" : "0x29a2241af62ca034",
                "code" : "",
                "nonce" : "0x00",
                "storage" : {
                }
            }
       }
}

[codecov-io]

Codecov Report

Merging #4973 into develop will decrease coverage by 0.03%.
The diff coverage is 2.12%.

@@             Coverage Diff             @@
##           develop    #4973      +/-   ##
===========================================
- Coverage    61.08%   61.05%   -0.04%     
===========================================
  Files          350      350              
  Lines        28303    28359      +56     
  Branches      2889     2885       -4     
===========================================
+ Hits         17290    17315      +25     
- Misses       10049    10091      +42     
+ Partials       964      953      -11

[pirapira]

What is the benefit of having a new format?

[gumb0]

Why do you need this hack?

[winsvega]

without this, Byzantium blockreward is reset to non zero value even if I want to run Byzantium tests with 0 mining reward that I set in chain params.

[gumb0]

You're not running Byzantium rules then. Maybe create another config similar to Byzantium but without block reward?

[winsvega]

well then I do not run any rules then. because I use 0 block reward for all tests with NoProof
the issue is that Byzantium set is overwriting the block reward and I dont have any means to prevent it from config.

[gumb0]

You need to create new EVMSchedule in EVMSchedule.h, add it to ChainOperationParams::scheduleForBlockNumber(), then use new param like "byzantiumTestForkBlock" in actual chain config

[winsvega]

isn't it too much just for the test purpose?

[gumb0]

Well ad-hoc hacking lower-level data structures and mechanisms just for the test purpose seems too much to me

[winsvega]

it is not really a hack. its an option to set mining reward in genesis config

[gumb0]

To make it work you could also try just overriding NoProof::blockReward() and always returning 0 from there.

[gumb0]

Though I wouldn't fully support such change, because it makes NoProof engine further away from real network mechanics and for unit tests I would like it to stay closer. But if you'd made another engine just for your tests like NoProofZeroRewards that would be fine I guess.

[winsvega]

@pirapira this is a minimalistic genesis format for running a test.
besides every client has its own unique genesis format. it would be good to have a common genesis format for test executions via rpc.

[gumb0]

Still not clear what's exactly wrong for you with our regular genesis format.

Provide an example of new format please

[winsvega]

ethereum/retesteth#7

[winsvega]

so basically there should be setGenesis method which allows you to enable/disable or set mining algorythm (PoW, NoProof) and initial state and genesis block header.
Plus it should be possible to set chain rules. (homestead, eip158)

the issue is that currently each client has its own genesis config format

[gumb0]

So is this a special kind of config where instead of fork block numbers you just set which fork it is and it is in effect for the whole chain starting from genesis?

[winsvega]

yes and no. we define Frontier as a test network that has Frontier rules enabled by default and so on for other forks. but we also have FrontierToHomesteadAt5 which has a transition at block 5.

so I see, you mean that chain options like forkBlock number should also be set in this method probably.
thus there will be no need to set Frontier and EIP158 names.

the issue is still that such transition block option names are depend on a client.

[gumb0]

Anyway I don't think it should be merged until format in ethereum/retesteth#4 is finalized

[winsvega]

Looks like the current set_chainParams method. (chain param init function) needs refactoring.
And we could support default values for the fields that are not set in .json