near / near-indexer-for-explorer

Watch NEAR network and store all the data from NEAR blockchain to PostgreSQL database
https://near-indexers.io/docs/projects/near-indexer-for-explorer
GNU General Public License v3.0
123 stars 56 forks source link
blockchain hacktoberfest nearprotocol

NEAR Indexer for Explorer

NEAR Indexer for Explorer is built on top of NEAR Lake Framework to watch the network and store all the events in the PostgreSQL database.

Shared Public Access

NEAR runs the indexer and maintains it for NEAR Explorer, NEAR Wallet, and some other internal services. It proved to be a great source of data for various analysis and services, so we decided to give a shared read-only public access to the data:

WARNING: We may evolve the data schemas, so make sure you follow the release notes of this repository.

NOTE: Please, keep in mind that the access to the database is shared across everyone in the world, so it is better to make sure you limit the amount of queries and individual queries are efficient.

Self-hosting

The final setup consists of the following components:

Prepare Development Environment

Before you proceed, make sure you have the following software installed:

Prepare Database

Setup PostgreSQL database, create a database with the regular tools, and note the connection string (database host, credentials, and the database name).

Clone this repository and open the project folder

$ git clone https://github.com/near/near-indexer-for-explorer.git
$ cd near-indexer-for-explorer

You need to provide credentials via .env file for:

Then you need to apply migrations to create necessary database structure. For this you'll need diesel-cli, you can install it like so:

$ cargo install diesel_cli --no-default-features --features "postgres"

And apply migrations

$ cd database && diesel migration run

If you have the DB with some data collected, and you need to apply the next migration, we highly recommend to read the migration contents.
Some migrations have the explanations what should be done, e.g. [1], [2], [3].
General advice is to add CONCURRENTLY option to all indexes creation and apply such changes manually.

Compile NEAR Indexer for Explorer

$ cargo build --release

Run NEAR Indexer for Explorer

Command to run NEAR Indexer for Explorer have to include the chain-id and start options:

You can choose NEAR Indexer for Explorer start options:

Storing genesis file

When starting Indexer for Explorer with from-genesis, the entire genesis file will be loaded in to memory before iterating the stored accounts/access keys. As of writing this, mainnet and betanet both have relatively small genesis files (<1GB), but the testnet file size is around 5GB. Therefore, if you intend to store the testnet genesis records, make sure that your system has sufficient RAM to hande the memory load.

Strict mode

NEAR Indexer for Explorer works in strict mode by default. In strict mode, the Indexer will ensure parent data exists before storing children, infinitely retrying until this condition is met. This is necessary as a parent (i.e. block) may still be processing while a child (i.e. receipt) is ready to be stored. This scenario will likely occur if you have not stored the genesis file or do not have all data prior to the block you start indexing from. In this case, you can disable strict mode to store data prior to the block you are concerned about, and then re-enable it once you have passed this block.

To disable strict mode provide the following command arugment:

--non-strict-mode

Concurrency

By default NEAR Indexer for Explorer processes only a single block at a time. You can adjust this with the --concurrency argument (when the blocks are mostly empty, it is fine to go with as many as 100 blocks of concurrency).

Starting

So final command to run NEAR Indexer for Explorer can look like:

$ ./target/release/indexer-explorer \
  --non-strict-mode \
  --concurrency 1 \
  mainnet \
  from-latest

After the network is synced, you should see logs of every block height currently received by NEAR Indexer for Explorer.

Troubleshoot NEAR Indexer for Explorer

Refer to a separate TROBLESHOOTING.md document.

Database structure

database structure

Creating read-only PostgreSQL user

We highly recommend using a separate read-only user to access the data to avoid unexcepted corruption of the indexed data.

We use public schema for all tables. By default, new users have the possibility to create new tables/views/etc there. If you want to restrict that, you have to revoke these rights:

REVOKE CREATE ON SCHEMA PUBLIC FROM PUBLIC;
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA PUBLIC FROM PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA PUBLIC GRANT SELECT ON TABLES TO PUBLIC;

After that, you could create read-only user in PostgreSQL:

CREATE ROLE readonly;
GRANT USAGE ON SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public to readonly;
-- Put here your limit or just ignore this command
ALTER ROLE readonly SET statement_timeout = '30s';

CREATE USER explorer with login password 'password';
GRANT readonly TO explorer;
$ PGPASSWORD="password" psql -h 127.0.0.1 -U explorer databasename

Deployments

Both indexer-explorer and circulating-supply binaries are run within Docker, their Dockerfiles can be found within their respective directories/workspaces. Docker images are built using Google Cloud Build and then deployed to Google Cloud Run. The following commands can be used to build the Docker images:

$ docker build -f ./indexer/Dockerfile .
$ docker build -f ./circulating-supply/Dockerfile .

Deprecated features

The tables account_changes and/or assets__fungible_token_events can be still enabled by features on the compile stage:

cargo build --release --features "account_changes fungible_token_events"

Note, we no longer support these tables. We highly recommend you to use Enhanced API instead.