Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 21 2017 21:24
    @jpitts banned @Musk55
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Dimitry (tests)> Invalid blocks should be rejected hy the client. Post state must match.
<Dimitry (tests)> bcHomesteadToDao start the dao fork from block 5
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> I see. So in this test: https://github.com/ethereum/tests/blob/develop/BlockchainTests/TransitionTests/bcHomesteadToDao/DaoTransactions.json the chain should run and throw on block 5 (extra data incorrect). It should then verify that the post state is correct. (postStateHash, so should be the state root of block 4). It should thus not verify that it also throws on these other blocks? Of course block 6 cannot be ran (as block 5 is incorrect), but a client could throw when it tries to validate the block header.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Dimitry (tests)> postStateHash is verified after all blocks been imported
<Dimitry (tests)> In the test it is. 1 2 3 4 5ex 1 2 3 4 5h 5val 6ex 6val and so on
<Dimitry (tests)> 5ex fails because extradata rule invalid
<Dimitry (tests)> Then 5h fails because its on homestead rules
<Dimitry (tests)> The 5val is valid because extradata and dao fork is proper
<Dimitry (tests)> 6 ex fails because wrong extradata on dao
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Yup, I got it now, thanks! 😄
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> The VMTests, do they include any HF, or should they all be ran on Frontier?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Could you also explain why tests like Homestead are (mostly) in the LegacyTests (~8000 tests in LegacyTests/BlockchainTests/ and ~500 in BlockchainTests/)? What does LegacyTests signal? Never mind, found it: https://github.com/ethereum/tests/releases/tag/v7.0.0-beta.1
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Dimitry (tests)> > The VMTests, do they include any HF, or should they all be ran on Frontier?
@Jochem

Yes. Its on frontier.
There are Istanbul blockchain tests corresponding to vmTests

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Thank you!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> I am assuming that ByzantiumToConstantinopleFixAt5 includes that both Constantinople and Petersburg get activated at block 5?
Martin Holst Swende
@holiman
That's a correct assumption
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> 👍
David Mechler
@davemec
Can I get a review of this PR that fixes besu sync tests and allows graphql tests to run again, ethereum/hive#318
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Hey @Dimitry, would it make sense to create network names like "BerlinPreliminary" or something similiar? Right now the BLS tests run on the "Berlin" network, but the current state of BLS seems to be that it is not ~95% likely that it will be included in the Berlin due to the ongoing discussions about the complexity of this EIP. It could also make sense to make explicit EIP networks (so you can test the BLS EIP, EIP2537, individually) where a genesis block needs to be included so we do know what other forks are activated (i.e. in the BLS tests there is a CALL opcode, it depends on the activated HFs what gas should be charged here)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Dimitry (tests)> It is now possible to develop test for any individual eip you would like.
like Berlin + EIP2537
<Dimitry (tests)> if the client does not support it, it will just skip the test with a warning
<Dimitry (tests)> also those tests can now resubmit in .yml format with solidity sources as retesteth now support solc
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Ah, cool! How would that network then be called? "Berlin+EIP2537"?
<Dimitry (tests)> btw check the recent tutorials we have: https://ethereum-tests.readthedocs.io/en/latest/retesteth-tutorial.html
<Dimitry (tests)> yes. similar to what we have with FrontierToHomeasteadAt5, we can have "Berlin+EIP2537"
<Dimitry (tests)> but that requires it to be set in config files
<Dimitry (tests)> like currently Berlin is translated to yolov1 in geth
<Jochem Brouwer> Great! Thanks! 😄
<Dimitry (tests)> I can adjust the config files
Martin Holst Swende
@holiman
No not Berlin+EIP2537 -- use an existing chain. E.g Constantinople+2537
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Hey @Dimitry, is it true that there are no MuirGlacier tests?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Dimitry (tests)> There are:
https://github.com/ethereum/tests/tree/develop/BasicTests

Difficulty EIP2384

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Ah, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Jochem Brouwer> Another question @Dimitry , how should I interpret these kind of tests: https://github.com/ethereum/tests/blob/86098807850c6211042f6a35ad8a48fc6072e856/BlockchainTests/TransitionTests/bcFrontierToHomestead/blockChainFrontierWithLargerTDvsHomesteadBlockchain.json

They have multiple blocks with the same block number which appears to be valid; but they seem to run on another "chainname". How should I interpret this?

<Dimitry (tests)> The network change rules from frontier to homestead at block 5
<Dimitry (tests)> You just import rlps and see if its valid or not the block
<Dimitry (tests)> In this test its 2 chains. One change to homestead and another one continue to be frontier thats why invalid at block 5 and 6
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> I see, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Jochem Brouwer> Hi @Dimitry , this test: https://github.com/ethereum/tests/blob/86098807850c6211042f6a35ad8a48fc6072e856/BlockchainTests/TransitionTests/bcFrontierToHomestead/blockChainFrontierWithLargerTDvsHomesteadBlockchain2.json

This test assumes an error on the second chain at block 5. But, the TD and the number of transactions are the same for both chains. Why should any client try to run the second chain (and thus encounter this error?). I would assume that clients only try to run a new sidechain iff the reported TD of this chain is higher, or if TD is the same and the number of transactions of this sidechain is higher?

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Dimitry (tests)> In this test the error indicate block as invalid because of a hardfork at block 5 that makes all blocks on old rules as invalid
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Is it mandatory in the test suite to thus run this block? If this chain would have a higher reported TD (but it is an invalid block) then that would make sense, but since the TD is the same as the original chain and the block does also not have more transactions, I do not see why the client should execute this block and thus throw an error?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Dimitry (tests)> Because after hardfork this block become incorrect. The test is to confirm that clients switch to the fork.

If you wish to support both forks and stay on one with total difficulty then you can disable this test

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Thank you!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Hi @Dimitry , is there an explicit check for gas used in StateTests? It seems that most state tests use a gas price of 1 for the transactions, so this would be reflected in the state root, but I think there are also some tests which have gas price set to 0. Is there any data to check that the transaction(s) use the correct gas amount?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Dimitry (tests)> Each test include mining address/coinbase/beneficiary
That balance is increased by tx.gasSpent * tx.gasprice
<Dimitry (tests)> The tests with gasprice 0 are designed to test that it still works with gasprice 0
<Dimitry (tests)> Like an interesting case with address that is not in blockchain db, has 0 balance, but sens a tx which is valid with gasprice 0
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Jochem Brouwer> Aha, I see, thanks!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Dimitry (tests)> Also if you use retesteth try out --vmtrace / --vmtraceraw