This release contains the first release of EOSIO History-Tools
fill-pg v1.0.0 and is compatible with EOSIO v2.1.0. All other tools included in the prior alpha releases of History-Tools are now deprecated.
fill-pg fills postgresql with data from nodeos's State History Plugin. It provides nearly all
data that applications which monitor the chain need. It provides the following:
- Header information from each block
- Transaction and action traces, including inline actions and deferred transactions
- Contract table history, at the block level
- Tables which track the history of chain state, including
- Accounts, including permissions and linkauths
- Account resource limits and usage
- Contract code
- Contract ABIs
- Consensus parameters
- Activated consensus upgrades
PostgreSQL table schema changes
This release completely rewrites the SHiP protocol to SQL conversion code so that the database tables would directly align with the data structures defined in the SHiP protocol. This also changes the table schema used by previous releases.
Here are the basic rules for the conversion:
- Nested SHiP
structtypes with more than one field are mapped to SQL custom types.
- Nested SHiP
vectortypes are mapped to SQL arrays.
varianttypes are mapped to a SQL type or table containing the union fields of their constituent types.
Consequently, instead of having their own tables in previous releases,
action_trace_authorization are arrays nested inside
transaction_trace table or
action_trace type. The SQL
UNNEST operator can be used to flatten arrays into tables for query.
The current list of tables created by
Data migration from prior releases
This release upgrades
fill-pg to support
nodeos v2.1.0. The remaining tools are still disabled and have not been upgraded. The schema used by
fill-pg has changed. At present no data migration tool is available, so data may be manually migrated, regenerated by replaying
from the desired block number, or exist side by side in two schemas, with older blocks in the v0.3.0 schema and newer blocks in the new schema. Use of the
--pg-schema option will facilitate the transition.
Full details of the differences can be found via diff of plain text backups of each schema using
pg_dump, not included here
fill-pg keeps action data and contract table data in its original binary form. Future versions
may optionally support converting this to JSON.
To conserve space,
fill-pg doesn't store blocks in postgresql. The majority of apps
don't need the blocks since:
- Blocks don't include inline actions and only include some deferred transactions. Most applications need to handle these, so they should examine the traces instead. e.g. many transfers live in the inline actions and deferred transactions that blocks exclude.
- Most apps don't verify block signatures. If they do, then they should connect directly to
nodeos's State History Plugin to get the necessary data. Note that contrary to
popular belief, the data returned by the
/v1/get_blockRPC API is insufficient for signature verification since it uses a lossy JSON conversion.
- Most apps which currently use the
/v1/get_blockRPC API (e.g.
eosjs) only need a tiny subset of the data within each block;
fill-pgstores this data. There are apps which use
/v1/get_blockincorrectly since their authors didn't realize the blocks miss critical data that their applications need.
fill-pg supports both full history and partial history (
trim option). This allows users
to make their own tradeoffs. They can choose between supporting queries covering the entire
history of the chain, or save space by only covering recent history.
SHiP protocol has been changed to allow a client to request the block_header only instead of the entire block.
fill-pg has been updated to utilize this feature when the
nodeos it connects to supports it.
Deprecation and Removal Notices
history-tools have been deprecated and disabled as of this v1.0.0 release.
You can use the docker-compose file to see how fill-pg interacts with nodeos and postgresql. For example, if you want to run fill-pg with some snapshot and setup one peer address, create a .env file such as:
Then execute the command:
And you will start seeing logs from the 3 containers, showing how they interact between each other.
Further customization can be achieved with other environment variables for example to set an specific branch/commit for nodeos or history-tools, such as:
You can also modify the provided docker-compose.yaml so that, for example, it takes more p2p peer addresses, for example:
... - --p2p-peer-address=peer.main.alohaeos.com:9876 - --p2p-peer-address=p2p.eosflare.io:9876 - --p2p-peer-address=p2p.eosargentina.io:5222 - --p2p-peer-address=eos-bp.index.pro:9876 - --p2p-peer-address=eosbp-0.atticlab.net:9876 - --p2p-peer-address=mainnet.eosarabia.net:3571 ...
See LICENSE for copyright and license terms.
All repositories and other materials are provided subject to the terms of this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.