update readme

This commit is contained in:
Roy Crihfield 2023-06-24 13:00:21 +08:00
parent 007cb8afb8
commit 60472965df

View File

@ -148,7 +148,7 @@ type Params struct {
IncludeReceipts bool
IncludeTD bool
IncludeCode bool
WatchedAddresses []core.Address
WatchedAddresses []common.Address
}
```
@ -216,7 +216,7 @@ The service also exposes unary RPC endpoints for retrieving the state diff `Stat
StateDiffAt(ctx context.Context, blockNumber uint64, params Params) (*Payload, error)
// StateDiffFor returns a state diff payload for the specific blockhash
StateDiffFor(ctx context.Context, blockHash core.Hash, params Params) (*Payload, error)
StateDiffFor(ctx context.Context, blockHash common.Hash, params Params) (*Payload, error)
```
To expose this endpoint the node needs to have the HTTP server turned on (`--http`),
@ -256,22 +256,20 @@ and `data` contains the bytes for the IPLD block (in the case of all Ethereum IP
byte encoding of the Ethereum object).
The IPLD objects in this table can be traversed using an IPLD DAG interface, but since this table
only maps multihash to raw IPLD object it is not particularly useful for searching through the data
by looking up Ethereum objects by their constituent fields (e.g. by block number, tx
source/recipient, state/storage trie node path). To improve the accessibility of these objects we
create an Ethereum [advanced data
only maps CID to raw IPLD object it is not very suitable for looking up Ethereum objects by their
constituent fields (e.g. by tx source/recipient, state/storage trie path). To improve the
accessibility of these objects we create an Ethereum [advanced data
layout](https://github.com/ipld/specs#schemas-and-advanced-data-layouts) (ADL) by generating
secondary indexes on top of the raw IPLDs in other Postgres tables.
These secondary index tables fall under the `eth` schema and follow an `{objectType}_cids` naming
convention. These tables provide a view into individual fields of the underlying Ethereum IPLD
objects, allowing lookups on these fields, and reference the raw IPLD objects stored in
`ipld.blocks` by foreign keys to their multihash keys. Additionally, these tables maintain the
hash-linked nature of Ethereum objects to one another. E.g. a storage trie node entry in the
`storage_cids` table contains a `state_id` foreign key which references the `id` for the
`state_cids` entry that contains the state leaf node for the contract that storage node belongs to,
and in turn that `state_cids` entry contains a `header_id` foreign key which references the `id` of
the `header_cids` entry that contains the header for the block these state and storage nodes were
`ipld.blocks` by CID. Additionally, these tables maintain the hash-linked nature of Ethereum
objects to one another, e.g. a storage trie node entry in the `storage_cids` table contains a
`state_leaf_key` field referencing the `state_cids` entry for the state trie node of its owning
contract, and that `state_cids` entry in turn contains a `header_id` field referencing the
`block_hash` of the `header_cids` entry for the block in which these state and storage nodes were
updated (diffed).
### Optimization