libp2p / research-pubsub

Research on PubSub algorithms for libp2p
https://github.com/libp2p/specs/tree/master/pubsub
MIT License
76 stars 6 forks source link

Request Ethereum PubSub notes #3

Closed daviddias closed 7 months ago

daviddias commented 8 years ago

As it was mentioned during last PubSub call, it will be important to learn from the Ethereum dev team their experiences with PubSub. Does anyone has a reference to a blog post or maybe an email thread of where we can learn more from it? We can probably ask if there is some availability o chat about it, take some notes and invite the Ethereum community to join our exploration. @jbenet ?

Links that come up in search:

wanderer commented 8 years ago

Hey @jbenet @diasdavid So I think the two biggest usecases for pubsub within Ethereum clients are 1) Publishing Blocks 2) Publishing Tx's

The way Ethereum currently implements pubsub is by a simple broadcast network. The wire protocol has get_block and blocks as well as get_txs and tx messages. Connections are formed via peer discover using kademlia .

Also Light clients are intersted when a subset for the global state is updated. A bigger question to me, is how to tie this into IPNS and IPFS. It would be cool if we could do something like this

/ipns/eth/0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa/
           |     |
           | - ethereum  
                 | - this is the hash of the genesis block, instead of identifying a pub source via pubkey

The above would return the latest state root from the last valid block that the client know about.

/ipns/eth/<genesis_hash>/0xbf4ed7b27f1d666546e30d74d50d173d20bca754
                                             |- this is an address to a contract

The above would return the code of a contract. If this was mounted in UNIX system you should be able to run it.

/ipns/eth/<genesis_hash>/<contract_address>/storage/<storage_key>

given the genesis block, the contract address, and storage key, this would return the value of a contracts storage.

/ipns/eth/<genesis_hash>/<contract_address>/balance

this would retrieve that contract's balance in ether

/ipns/eth/<genesis_hash>/<contract_address>/nonce

Lastly this would retrieve that contract's nonce.

In all of these cases a client implementing this would need sub/pub to blocks, txs, or stateRoots of a given path.

Also all the above should be available via ipfs so that historical states can be queried. The entry point here would be a block hash of a historical block.

/ipfs/eth/<block_hash>/state/<contract_address>/<storage|balance|nonce>/<storage_key>
wanderer commented 8 years ago

here complete mapping of ethereum's state to folders (sorry a bit off topic) eth == https://github.com/ipld/cid


  eth\-block hash-\
                   \-previous block
                   |
                   |-txs-\
                   |     |-tx 0
                   |     |-tx 1
                   |     \-tx N
                   |
                   |-uncles-\
                   |        |- uncle 0
                   |        |- uncle 1
                   |        \ -uncle N
                   |
                   |-header-\
                   |        |-number
                   |        |-mix
                   |        |-nonce
                   |        |-difficulty
                   |        |-bloom
                   |        |-coinbase
                   |        |-gasLimit
                   |        |-timestamp
                   |        \-extraData
                   |
                   \--accounts-\
                                \--address N--\
                                               \--balance
                                               |--nonce
                                               |--code
                                               \--storage--\
                                                            \-key 0
                                                            |-key 1
                                                            |-key N

EDIT moved to here https://github.com/ipld/specs/issues/27