Vexanium Docs
  • Welcome!
  • Overview
    • Vexanium Toolchain
    • Core Concepts
    • Technical Features
  • Getting Started
    • Development Environment
      • Prerequisites
      • Before You Begin
      • Install VEX.CDT
      • Create Development Wallet
      • Start keosd and nodeos
      • Create Development Accounts
    • Smart Contract Development
      • Hello World Contract
      • Deploy, Issue and Transfer Tokens
      • Understanding ABI Files
      • Data Persistence
      • Secondary Indices
      • Adding Inline Actions
      • Inline Actions to External Contracts
      • Payable actions
      • Creating and Linking Custom Permissions
  • Vexanium Protocol
    • Consensus Protocol
    • Transaction Protocol
    • Network Peer Protocol
    • Accounts and Permissions
  • Vexanium DAO - Governance
    • DPOS Governance
    • Active Block Producers
  • Reference
    • API Reference
      • API V2 Migrations
    • Smart Contract
      • C++ Smart Contract
        • Hello World Contract
        • Simple Token Farming Contract
        • Employee Attendance Contract
      • Solidity ( EVM )
        • Setup Metamask
        • To Do List Contract
  • Resources
Powered by GitBook
On this page
  • V1 History Alternatives
  • Production Ready Alternatives​
  • Roborovski History API
  • Overview​
  • Who Runs Roborovski History API​
  • What makes the Roborovski History API safe​
  • Understanding the risks associated with hosted solutions​
  • Roborovski History API and V1 History Standard​
  • API Reference​
  • Hyperion History Solution
  • Overview​
  • What makes the Hyperion safe​
  • Requirements​
  • Installation​
  • Set Up​
  • V1 History Support​
  • Endpoint List​
  1. Reference
  2. API Reference

API V2 Migrations

PreviousAPI ReferenceNextSmart Contract

Last updated 1 year ago

V1 History Alternatives

The latest VEXANIUM V2 , release officially ends support for the legacy V1 History plugin. Therefore, block producers and node operators who have integrations that rely on V1 History must seek alternative solutions.

Production Ready Alternatives

The following battle tested and V1 compliant history solutions are available:

  • Hyperion History Solution

  • Roborovski History API

Roborovski History API

Overview

Roborovski History API is designed as a drop-in replacement for the V1 history API. It relies on the Trace API Plugin to extract the history data and then packs it in V1 format before it gives it back to the client request.

Who Runs Roborovski History API

Roborovski History API is implemented and ran by Greymass Inc.

What makes the Roborovski History API safe

Roborovski History API has a high degree of safety because it is created by Greymass Inc. which has been a credible and stable block producer and wallet developer (Anchor) company for EOS, WAX, TELOS, PROTON, FIO and other EOS based chains.

If you rely on a hosted solution, you are reliant on the correctness of data and processes that you do not control. Therefore, if your application critically relies on on-chain data, it is highly recommended that you host your own history solution. However, since Roborovsky is currently closed source, if you want to run your own node you will need to see Hyperion below.

Roborovski History API is compliant with the V1 history API standard. It also adds two more functions on top of the standard ones.

Existing V1 History Plugin integrators can simply replace their current API url with Greymass' one and it will work flawlessly.

The Roborovski History API connection endpoint is https://eos.greymass.com

  • Get Actions (V1 compatible)

    • POST https://eos.greymass.com/v1/history/get_actions

  • Get Transaction (V1 compatible)

    • POST https://eos.greymass.com/v1/history/get_transaction

  • Get Transaction (new method, not in V1)

    • GET https://eos.greymass.com/v1/history/get_transaction?id=<TXID>

  • Get Actions (new method, not in V1)

    • GET https://eos.greymass.com/v1/history/get_actions?account_name=<NAME>

As it was observed and measured so far the Roborovski History API supports at least 50 requests per second; this limit is defined as a low load, the solution is capable of handling more, but no higher specific limits are known at the moment.

Hyperion History Solution

Hyperion History Solution

Hyperion History is a full history solution for indexing, storing and retrieving EOS-based blockchain historical data. It can be deployed by node operators to provide data querying support for actions, transactions, and blocks stored on the blockchain.

Hyperion History API provides both V2 and V1 (legacy history plugin) endpoints. Therefore, it is fully compliant with V1 history.

Hyperion History requires the following components for a fully functional Hyperion API deployment:

  • Elasticsearch Cluster - stores all indexed data

  • RabbitMQ - message/data transport/queue for indexer stages

  • Redis - used as predictive temporary database

  • EOS State History plugin - feeds action traces and state deltas to indexer via websocket

  • Hyperion Indexer - indexes State History data (launched from PM2 Node.js manager)

  • Hyperion API - API server that listens to V1/V2 requests

Providers have the following options to install Hyperion History solution:

To set up Hyperion History solution after a successful installation:

  • Configuration:

  • Connection Configuration:

  • Chain Configuration:

Hyperion History is compliant with the V1 history API standard.

For a full description of the V1 History API endpoints supported by Hyperion History, please visit:

  • /v1/history/get_transaction

    Get transaction by id

    • method: POST

    • schema: variable | type | description -|-|- id | string | transaction id

  • /v1/history/get_actions

    Legacy get actions query

    • method: POST

    • schema: variable | type | description -|-|- account_name | type | description pos | integer | action position (pagination) offset | integer | limit of [n] actions per page filter | string (minLength: 3) | code:name filter sort | string | sort direction (Enum: [desc, asc, 1, -1]) after | string($date-time) | filter after specified date (ISO8601) before | string($date-time) | filter before specified date (ISO8601) parent | integer (min: 0) | filter by parent global sequence

Once Hyperion History is deployed on a server or cluster, existing V1 History Plugin clients can simply replace their current API domain URL with the one provided by the listening server or cluster.

Some examples to illustrate usage of V1 History endpoints:

  • Get all actions from given transaction:

    curl -X POST https://eos.hyperion.eosrio.io/v1/history/get_transaction -d '{
      "id": "<TXID>"
    }'
  • Get all actions from last 10 transactions for given account:

    curl -X POST https://eos.hyperion.eosrio.io/v1/history/get_transaction -d '{
      "account_name": "<NAME>",
      "pos": -1
    }'

For a list of endpoint servers using Hyperion, check:

Understanding the risks associated with hosted solutions

Roborovski History API and V1 History Standard

API Reference

How To Connect

Functions List

Performance Numbers

Overview

What makes the Hyperion safe

Hyperion is developed and maintained by EOS Rio: and has been battle tested on every Antelope public network (EOS, WAX, TELOS, PROTON, FIO, etc).

Github:

Requirements

Installation

Manual installation:

Set Up

V1 History Support

V1 History API reference

Usage

Examples

Endpoint List

​
​
​
​
​
​
​
​
​
​
​
​
https://eosrio.io/hyperion/
https://github.com/vexanium/hyperion-history-api
​
​
https://github.com/vexanium/hyperion-history-api
​
​
​
​
​
​