-
Notifications
You must be signed in to change notification settings - Fork 6
Components
Here, you can find a breakdown of the components of the Read RPC project.
An actix-web HTTP server provides the entry point for JSON-RPC service. For now, it is the only component of the Read RPC exposed to the public.
Despite having a pretty complex logic, from the technical perspective, it is a simple web server providing a couple of endpoints:
- JSON-RPC endpoint on the root
- Prometheus-compatible metrics endpoint on the
/metrics
We aim to keep the rpc-server README up-to-date with the most relevant info. Meanwhile, this doc should describe constant things and give an overall understanding of the component.
It implements the JSON RPC methods (more details on the methods breakdown page).
Includes the runtime from nearcore to serve the view calls (actually, it is included in the first point, but I wanted to highlight it)
Have some tools hidden under the feature flags that allow checking the data correctness, which is necessary to do before hitting production (shadow_data_consistency)
- Connection to the database (ScyllaDB)
- Access to the NEAR Lake S3 bucket(s)
- URL to the NEAR Archival JSON-RPC (to proxy requests not implemented yet, send transactions to, etc.)
An indexer processes the StateChanges and writes to the database in a specific format so the rpc-server can read it.
This indexer watches for StateChanges in each block and stores the data in different tables related to the specific change type in the database.
See the page Database Design
This indexer watches for every transaction on the chain and collects each transaction's related entities into a special structure, TransactionDetails.
It holds:
- Transaction itself
- ExecutionOutcome of the transaction
- All the Receipts related to the transaction
- All the ExecutionOutcomes of the Receipts related to the Transaction
Once the last execution outcome is observed and the TransactionDetails structure is collected, it is stored in the database and serialized with the borsh.
While collecting entities, every Receipt is also stored in the database on the fly.
For more details, see the page Database Design
A crate/library defining the trait to interact with the database.
Currently, the database crate defines a trait ScyllaDBManager used in all the binaries.
We have extracted this trait into a separate crate so we can extend it later. For instance, we can abstract it to the StorageManager instead of ScyllaDBManager, and we can use a variety of databases.
A crate/library defining the common/shared types for the Read RPC project
This is a dedicated crate to provide shared types for the Read RPC project and its components. Currently, it defines the TransactionDetails structure the tx-indexer writes to the database, and the rpc-server reads.