MilleneosDB is a public blockchain snapshot solution and accompanying software that can be seamlessly deployed by anyone with appropriate hardware and serves as the base layer required to launch a MillenEOS-powered FHN.

The major advantage of MilleneosDB over other existing EOS snapshot solutions is that it simultaneously loads both, the copy of Nodeos and the copy of the most recent database with sorted and pre-aggregated blockchain history data.

MilleneosDB is comprised of two parts – the Database Layer and the Application Layer. The Application Layer serves to manage the Database Layer in terms of writing and queries.

DataBase Layer

The Database Layer is the core of the MillenEOS infrastructure. It is comprised of three distinct tables - Actions, Blocks, and RawStates. These three table and the data contained therein are sufficient to effectively reconstruct the entire history of the EOS blockchain. In particular:

  1. The Actions table stores actions and traces data and one can retrieve information about transactions from here. All data in the Actions table is sorted by Block Number and Action Sequence. It allows to quickly retrieve transactions, actions and traces by blocks. This table is used to create materialized view for storing actions sorted by account and time. Through AccountActionsFeed table we can quickly retrieve actions for any account.

    The Actions table is comprised of the following fields (each action and transaction has these fields) - i.e. one can retrieve unique transactions, all actions, and traces.

    Field Datatype
    Time DateTime,
    BlockNum UInt32,
    GlobalSequence UInt64,
    Parent UInt64,
    TrxId FixedString(64),
    CpuUsageUs UInt32,
    NetUsageWords UInt32,
    ReceiptReceiver LowCardinality(String),
    ActionAccount LowCardinality(String),
    ActionName LowCardinality(String),
    DataJson String,
    Nested (
    Actor LowCardinality(String),
    Permission LowCardinality(String)
    Nested (
    Account LowCardinality(String),
    Delta Int32
  2. From the Blocks table one can retrieve the unique block number, the timestamp when the block was created, the block producer that verified the block, the number of the previous block, and the schedule version.

    Field Datatype
    BlockNum UInt32,
    Time DateTime,
    Code LowCardinality(String),
    Scope LowCardinality(String),
    Table LowCardinality(String),
    Payer LowCardinality(String),
    PrimaryKey String,
    Value String
  3. State storage stores all the changes in states from the ESO blockchain. The States table is used to create EOS Balance Log (similarly to the log of RAM changes inside the Actions table) and the Resources Log, which are then used to calculate the state for each.

    Field Datatype
    BlockNum UInt32,
    Time DateTime,
    Producer LowCardinality(String),
    Previous String,
    ScheduleVersion LowCardinality(String)

The Application Layer

This layer is basically a set of abstractions and rules for seamless aggregation of data allowing for fast data reading and insertion. The state-of-art architecture of this exact piece of the infrastructure allows for quick querying of various data dimensions and serves as a basis for MillenEOS API.

  1. Transactions Feed Storage - serves the /livefeed/transactions API, while directly querying the Actions part of the Database Layer.
  2. RAM State - serves the /account/{account} API to provide RAM data for each account by querying the current balance of RAM.
  3. Actions Storage - queries the Actions part of the Database Layer as well as transaction index to serve the /transaction/{trxId} and the /block/{blockNum} APIs.
  4. Accounts Actions Feed View - /account/actions/{account} and /transaction/seq/{blockNum}/{sequence} are utilizing the data from this component which is fed from Date Marks and the Account Actions Feed.
  5. Balance Storage - used for providing data to /balance/{account} and /account/{account} APIs by querying the only the EOS Balance State.
  6. Block Storage - used by /block/{blockNum} by querying directly the Blocks table and the Blocks Feed.
  7. Resources Storage - feed data from Resources Log and Resources State and used in /account/{account} and /resource/{account} API.
  8. Blocks Feed View - queries both, the Last Block Feed and the Blocks Feed to “supply” data to the /livefeed/blocks.
  9. State Storage - queries directly the States table, and currently it is not utilized by any of the APIs.