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 IncludeReceipts bool
IncludeTD bool IncludeTD bool
IncludeCode 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) StateDiffAt(ctx context.Context, blockNumber uint64, params Params) (*Payload, error)
// StateDiffFor returns a state diff payload for the specific blockhash // 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`), 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). byte encoding of the Ethereum object).
The IPLD objects in this table can be traversed using an IPLD DAG interface, but since this table 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 only maps CID to raw IPLD object it is not very suitable for looking up Ethereum objects by their
by looking up Ethereum objects by their constituent fields (e.g. by block number, tx constituent fields (e.g. by tx source/recipient, state/storage trie path). To improve the
source/recipient, state/storage trie node path). To improve the accessibility of these objects we accessibility of these objects we create an Ethereum [advanced data
create an Ethereum [advanced data
layout](https://github.com/ipld/specs#schemas-and-advanced-data-layouts) (ADL) by generating 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. 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 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 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 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 `ipld.blocks` by CID. Additionally, these tables maintain the hash-linked nature of Ethereum
hash-linked nature of Ethereum objects to one another. E.g. a storage trie node entry in the objects to one another, e.g. a storage trie node entry in the `storage_cids` table contains a
`storage_cids` table contains a `state_id` foreign key which references the `id` for the `state_leaf_key` field referencing the `state_cids` entry for the state trie node of its owning
`state_cids` entry that contains the state leaf node for the contract that storage node belongs to, contract, and that `state_cids` entry in turn contains a `header_id` field referencing the
and in turn that `state_cids` entry contains a `header_id` foreign key which references the `id` of `block_hash` of the `header_cids` entry for the block in which these state and storage nodes were
the `header_cids` entry that contains the header for the block these state and storage nodes were
updated (diffed). updated (diffed).
### Optimization ### Optimization