Studying Pyethereum/Pyethapp

Probably anyone who is involved in the "core" project will have to study Ethereum implementations. While the Ethereum Yellow Paper ( is probably the first source you want to look at, it doesn't cover specific implementation details such as how block reorganizations are handled. Unless you are already an expert in Rust or Go, Pyethereum is probably the easiest Ethereum codebase to study. Unfortunately it seems like Pyethapp isn't the most up to date implementation and for whatever reasons I wasn't able to immediately peer with other nodes.

Workaround to import blocks to study

The following is a workaround to import blocks from parity to get around peering issues.

  1. Install and run parity to sync up the needed number of blocks
  2. Export blocks from parity with $ ./target/release/parity export blocks ~/path/to/directory/chain.rlp
  3. Import blocks into pyethapp with $ pyethapp import ~/path/to/directory/chain.rlp

Looking into chain data from the command line

After executing

pyethapp run

you can hit CTRL-C to enter console mode.

Looking up the details of a transaction

Let us examine the following transaction through pyethapp.

  1. Fetch the relevant block with block = eth.chain.get_block_by_number(53989)
  2. Grab the relevant transaction with transaction = block.transactions[1]
    1. You can double check you got the right transaction by comparing the txhash

      In: transaction.hash.hex()

      Out: '423a89ae3fa471502c03e1d79e5fad8fa3637aea0e9687396315fe1a60687143'

  3. You can look at the pyethapp README to see a list of attributes you can fetch from the transaction. I personally just type transaction. and hit the TAB key to see the list of possible options.
    1. For example gas price can be queried as follows

      In [54]: transaction.gasprice

      Out[54]: 57036234360

    2. Or you can just see all the attributes with .to_dict()

      In [58]: transaction.to_dict()


      {'data': '0x',

      'gasprice': 57036234360,

      'hash': '0x423a89ae3fa471502c03e1d79e5fad8fa3637aea0e9687396315fe1a60687143',

      'nonce': 0,

      'r': 100109914899522740072820940032964549000152372784597782163962964272918287896235,

      's': 34504076207637428225392040647648060942376898176377071704915726387968418661732,

      'sender': '0x4f68024b7ceb5ca92e7308bd08e523c632c0c739',

      'startgas': 90000,

      'to': '0x',

      'v': 28,

      'value': 50000000000000000}

  4. Note the 'to': '0x' means that this transaction creates a contract. This contract is created at address

    In [61]: transaction.creates.hex()

    Out[61]: '9b4364943c18c594d11e7a4484c40f41fce7c9be'

    with contract code 'data': '0x'. Basically someone created a useless contract!

Viewing block reorganization in real time on local test networks

The following are some potential pitfalls that I encountered. I was working with around ~6 nodes on separate docker containers all on one machine.

  1. Make sure you set up unique node public keys or else syncing will not start due to "got a ping from self?"
  2. Pyethereum encodes the genesis block in a different way from the rest of the blocks. To avoid related errors, just kick start the network with a few imported blocks.
  3. The kademlia protocol can be quite time consuming. I've had better luck getting a connection among nodes with my wifi off so all requests that go to external ip addresses immediately fail. I'll probably shortly write a patch that makes requests to external ip addresses fail from the python code.
  4. I've had better luck with a high max_retries value (I'm currently working with 128 as opposed to the default 3) when connecting with other nodes. This is probably related to me using a really low difficulty. This number will probably need to get balanced (lowered) to deal with malicious nodes.