Closed daviddias closed 10 months 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>
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
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: