void test_setChainParams(string _config)

[winsvega]

The idea is to implement a simple genesis format to use in test rpc method. Each client that would like to run tests via rpc just implement this rpc methods.

The method here is the main test_setChainParams(string _config) method which would tell the client to init a test chain with the given state of accounts and genesis block config. A genesis block is a block and should have the block fields. A state is a list of accounts with it's storage and balances, nonce and code. No precompiled contracts are explicitly defined in the genesis state *(1).

The params section tells the client which mining method to use. "ProofOfWork" is a regular mining that accepts new block according to the hash calculation rules. The "ForkRules" sets which fork changes should be enabled to use on this chain. *(2). The forks are (Frontier, Homestead, ... Byzantium)

# Genesis config for running a StateTest via RPC (current version example)
{
    "sealEngine" : "NoProof",
    "params" : {
        "homesteadForkBlock" : "0x00"
    },
    "genesis" : {
        "author" : "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba",
        "difficulty" : "0x20000",
        "gasLimit" : "0x0f4240",
        "nonce" : "0x00",
        "extraData" : "0x00",
        "timestamp" : "0x00",
        "mixHash" : "0x00"
    },
    "accounts" : {
        "0x095e7baea6a6c7c4c2dfeb977efac326af552d87" : {
            "balance" : "0x0de0b6b3a7640000",
            "code" : "0x6001600101600055",
            "nonce" : "0x00",
            "storage" : {
            }
        },
        "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b" : {
            "balance" : "0x0de0b6b3a7640000",
            "code" : "0x",
            "nonce" : "0x00",
            "storage" : {
            }
        }
    }
}

We should discuss the format with other client developers and perhaps discuss what should be added here. The points *(1) and *(2) require some discussion I think.

[winsvega]

*(2)
"forkRules" : "Frontier",

the idea is to start accepting blocks with the following fork scheme.
I suppose there is no way to configure fork changes via json config because some of the changes are really hard coded into the clients. so we need to come up with consensys on what this fork names mean.
"Frontier" "Homestead" "EIP150" "EIP158" "Byzantium"

Another issue is how do we want at some point to change the fork rules. For examples there are tests that change the fork rules at a given block number. such are https://github.com/ethereum/tests/tree/develop/BlockchainTests/TransitionTests

[axic]

"Frontier" "Homestead" "EIP150" "EIP158" "Byzantium"

It would be nice to use the names Frontier, Homestead, TangerineWhistle, SpuriousDragon, Byzantium. See https://github.com/ethereum/EIPs#past-hard-forks

[winsvega]

Issue about fork names #12

[winsvega]

this genesis is enough for state tests:

"genesis" : {
            "coinbase" : "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba",
            "gasLimit" : "0x0f4240",
            "timestamp" : "0x03e8"
       }

perhaps all timestamp tests could be moved from state tests to blockchain tests. timestamp seems like a blockchain property.

the tests to move from state tests to blockchain tests
TIMESTAMP tests
DIFFICULTY tests
BLOCKHASH tests
.....

you know, I start to feel that we need a general ethereum test format.
the fact that state tests are compiled to blockchain tests telling me that something is wrong )
@pirapira what you think? could we combine blockchain tests and state tests into a general test format ?

[pirapira]

@winsvega open a separate issue for the new test format.

[gumb0]

So you say this format covers also the tests with transition to different fork, how do you set up then at which block which fork starts in this format?

[gumb0]

And could you also clarify why do you need to override fork rules around block reward ?
(In general Ethereum networks can change their block rewards with forks)

[winsvega]

because when NoProof is used a mining reward is 0. no mining happens.
well I could rethink state tests. the way it is now - test sources expect no mining reward. because state tests were not the blockchain tests. now it is kind of are.

if you say that mining reward is hardcoded into fork rules, then why do we need an option for mining reward in genesis config at all. (hardcoded mining reward is used anyway)

the genesis format you mentioned should be able to set fork transition blocks. state tests do not have more then one block. but I will need it in the blockchain tests. the setChainParams method should have a scheme that allows to set fork transition blocks. (and we dont have a standart between clients on this)

I see a solution if we create a test_setChainParams method which any client could implement and it would be a standart for tests.
another way is that we state common chain params like (eip158forkblock) *name is to be decided. and implement support in existing genesis configs for clients.

again the issue is that each client has its own genesis config with its own options. and those options are all different in those client implementations. we cant disable existsing chain options. but we can ask clients to support a general config file format. so that users don't have to google a client specififc genesis config instructions.

this is actually a point for core dev call

[gumb0]

because when NoProof is used a mining reward is 0. no mining happens.

Mining algorithm and rewards are quite separate matters.
Well in cpp-ethereum they seem somewhat entangled, but I don't know how easy it would be for other clients to implement the logic you imagine.

well I could rethink state tests. the way it is now - test sources expect no mining reward. because state tests were not the blockchain tests. now it is kind of are.

You could maybe ignore changes to coinbase when you fill/check test results.

if you say that mining reward is hardcoded into fork rules, then why do we need an option for mining reward in genesis config at all. (hardcoded mining reward is used anyway)

I'd say we should get rid of it and always hard-code block reward, similar to what we do with opcode prices.

[winsvega]

https://github.com/ethereum/retesteth/wiki/RPC-Methods

[zaman10d]

2021 Countdown. Times up. Setup Quick

[zaman10d]

Happy new year everybodys. 2021 moving forward.