fnodata

fnodata is an original Fonero block explorer, with packages and apps for data collection, presentation, and storage. The backend and middleware are written in Go. On the front end, Webpack enables the use of modern javascript features, as well as SCSS for styling.

fnodata

Release Status

Always run the Current release or on the Current stable branch. Do not use master in production.

	Series	Branch	Latest release tag
Current	4.1	`4.1-stable`	`release-v4.1.0`
Legacy	4.0	`4.0-stable`	`v4.0.2`
Development	5.0	`master`	N/A

Repository Overview

../fnodata              The fnodata daemon.
├── api                 Package blockdata implements fnodata's own HTTP API.
│   ├── insight         Package insight implements the Insight API.
│   └── types           Package types includes the exported structures used by
|                         the fnodata and Insight APIs.
├── blockdata           Package blockdata is the primary data collection and
|                         storage hub, and chain monitor.
├── cmd
│   ├── rebuilddb       rebuilddb utility, for SQLite backend. Not required.
│   ├── rebuilddb2      rebuilddb2 utility, for PostgreSQL backend. Not required.
│   └── scanblocks      scanblocks utility. Not required.
├── db
│   ├── agendadb        Package agendadb is a basic PoS voting agenda database.
│   ├── cache           Package cache provides a caching layer that is used by fnopg.
│   ├── dbtypes         Package dbtypes with common data types.
│   ├── fnopg           Package fnopg providing PostgreSQL backend.
│   └── fnosqlite       Package fnosqlite providing SQLite backend.
├── fnorates            Package fnorates defines a gRPC protobuf service for
│   │                     communicating exchange rate data with rateserver.
│   └── rateserver      rateserver app, which runs an exchange bot for collecting
│                         exchange rate data, and a gRPC server for providing this
│                         data to multiple clients like fnodata.
├── dev                 Shell scripts for maintenance and deployment.
├── docs                Extra documentation.
├── exchanges           Package exchanges implements a bot for gathering data
|                       from public exchange APIs.
├── explorer            Package explorer, powering the block explorer.
├── gov
│   ├── rebuilddb       Package agendas defines a consensus deployment/agenda DB.
│   └── politeia        Package politeia defines a Politeia proposal DB.
│       ├── piclient    Package piclient provides functions for retrieving data
|       |                 from the Politeia web API.
│       └── types       Package types provides several JSON-tagged structs for
|                         dealing with Politeia data exchange.
├── mempool             Package mempool for monitoring mempool for transactions,
|                         data collection, distribution, and storage.
├── middleware          Package middleware provides HTTP router middleware.
├── netparams           Package netparams defines the TCP port numbers for the
|                         various networks (mainnet, testnet, simnet).
├── notification        Package notification manages fnod notifications, and
|                         synchronous data collection by a queue of collectors.
├── public              Public resources for block explorer (css, js, etc.).
├── pubsub              Package pubsub implements a websocket-based pub-sub server
|   |                     for blockchain data.
│   ├── democlient      democlient app provides an example for using psclient to
|   |                     register for and receive messages from a pubsub server.
│   ├── psclient        Package psclient is a basic client for a pubsub server.
│   └── types           Package types defines types used by the pubsub client
|                         and server.
├── rpcutils            Package rpcutils contains helper types and functions for
|                         interacting with a chain server via RPC.
├── semver              Package semver.
├── stakedb             Package stakedb, for tracking tickets.
├── testutil
│   └── apiload         apiload is an HTTP API load testing application.
├── txhelpers           Package txhelpers provides many functions and types for
|                         processing blocks, transactions, voting, etc.
├── version             Package version describes the fnodata version.
└── views               HTML templates for block explorer.

Requirements

Go 1.11.6+ or 1.12.1+.
Node.js 10.x or 11.x. Node.js is only used as a build tool, and is not used at runtime.
Running fnod running with --txindex --addrindex, and synchronized to the current best block on the network. On startup, fnodata will verify that the fnod version is compatible. fnodata v3.1.x and later required fnod v1.4.x or a later version with JSON-RPC server version 5.x.y.
(For "full" mode) PostgreSQL 10.5+. Version 11.x is supported and recommended for improved performance with a number of tasks.

Docker Support

Dockerfiles are provided for convenience, but NOT SUPPORTED. See the Docker documentation for more information. The supported fnodata build instructions are described below.

Building

The fnodata build process comprises two general steps:

Bundle the static web page assets with Webpack (via the npm tool).
Build the fnodata executable from the Go source files.

These steps are described in detail in the following sections.

NOTE: The following instructions assume a Unix-like shell (e.g. bash).

Preparation

Install Go
Verify Go installation:
```
go env GOROOT GOPATH
```
Ensure $GOPATH/bin is on your $PATH.
Clone the fnodata repository. It is conventional to put it under GOPATH, but this is no longer necessary with go module. For example:
```
git clone https://github.com/fonero-project/fnodata $HOME/go-work/github/fonero-project/fnodata
```
Install a C compiler. The sqlite driver uses cgo, which requires a C compiler (e.g. gcc) to compile the sources. On Windows this is easily handled with MSYS2 (download and install MinGW-w64 gcc packages).
Install Node.js, which is required to lint and package the static web assets.

Note that none of the above is required at runtime.

Package the Static Web Assets

Webpack, a JavaScript module bundler, is used to compile and package the static assets in the public folder. Node.js' npm tool is used to install the required Node.js dependencies and build the bundled JavaScript distribution for deployment.

First, install the build dependencies:

npm install # creates node_modules folder

Then, for production, build the webpack bundle:

npm run build # creates public/dist folder

Alternatively, for development, npm can be made to watch for and integrate JavaScript source changes:

npm run watch

See Front End Development for more information.

Building fnodata with Go

Go 1.11 introduced modules, a new dependency management approach, that obviates the need for third party tooling such as dep.

Usage is simple and nothing is required except Go 1.11 or later. If building in a folder under GOPATH, it is necessary to explicitly build with modules enabled:

GO111MODULE=on go build

If building outside of GOPATH, modules are automatically enabled, and go build is sufficient.

The go tool will process the source code and automatically download dependencies. If the dependencies are configured correctly, there will be no modifications to the go.mod and go.sum files.

Beware: For the v4 fnodata module, the executable generated by go build may be named "v4" instead of "fnodata". This is a known issue in Go 1.11 that will be resolved in a future Go release.

As a reward for reading this far, you may use the build.sh script to mostly automate the build steps.

Setting build version flags

By default, the version string will be postfixed with "-pre+dev". For example, fnodata version 4.0.0-pre+dev (Go version go1.12.1). However, it may be desirable to set the "pre" and "dev" values to different strings, such as "beta" or the actual commit hash. To set these values, build with the -ldflags switch as follows:

GO111MODULE=on go build -o fnodata -v -ldflags \
    "-X github.com/fonero-project/fnodata/version.appPreRelease=beta \
     -X github.com/fonero-project/fnodata/version.appBuild=`git rev-parse --short HEAD`"

This produces a string like fnodata version 4.0.0-beta+25777e23 (Go version go1.12.1).

Runtime Resources

The config file, logs, and data files are stored in the application data folder, which may be specified via the -A/--appdata and -b/--datadir settings. However, the location of the config file may also be set with -C/--configfile. The default paths for your system are shown in the --help description. If encountering errors involving file system paths, check the permissions on these folders to ensure that the user running fnodata is able to access these paths.

The "public" and "views" folders must be in the same folder as the fnodata executable. Set read-only permissions as appropriate.

Updating

Update the repository (assuming you have master checked out in GOPATH):

cd $HOME/go-work/github/fonero-project/fnodata
git pull origin master

Look carefully for errors with git pull, and reset locally modified files if necessary.

Next, build fnodata and bundle the web assets:

go build
npm install
npm run build # or npm run watch

Note that performing the above commands within $GOPATH may require setting GO111MODULE=on.

Upgrading Instructions

From v3.x or later

No special actions are required. Simply start the new fnodata and automatic database schema upgrades and table data patches will begin.

From v2.x or earlier

The database scheme change from fnodata v2.x to v3.x does not permit an automatic migration. The tables must be rebuilt from scratch:

Drop the old fnodata database, and create a new empty fnodata database.

-- Drop the old database.
DROP DATABASE fnodata;

-- Create a new database with the same "pguser" set in the fnodata.conf.
CREATE DATABASE fnodata OWNER fnodata;

Delete the fnodata data folder (i.e. corresponding to the datadir setting). By default, datadir is in {appdata}/data:
- Linux: ~/.fnodata/data
- Mac: ~/Library/Application Support/Fnodata/data
- Windows: C:\Users\<your-username>\AppData\Local\Fnodata\data (%localappdata%\Fnodata\data)
With fnod synchronized to the network's best block, start fnodata to begin the initial block data sync.

Getting Started

Configuring PostgreSQL (IMPORTANT! Seriously, read this.)

If you intend to run fnodata in "full" mode (i.e. with the --pg switch), which uses a PostgreSQL database backend, it is crucial that you configure your PostgreSQL server for your hardware and the fnodata workload.

Read postgresql-tuning.conf carefully for details on how to make the necessary changes to your system. A helpful online tool for determining good settings for your system is called PGTune. Note that when using this tool to subtract 1.5-2GB from your system RAM so fnodata itself will have plenty of memory. DO NOT simply use this file in place of your existing postgresql.conf. DO NOT simply copy and paste these settings into the existing postgresql.conf. It is necessary to edit the existing postgresql.conf, reviewing all the settings to ensure the same configuration parameters are not set in two different places in the file (postgres will not complain).

On Linux, you may wish to use a unix domain socket instead of a TCP connection. The path to the socket depends on the system, but it is commonly /var/run/postgresql. Just set this path in pghost.

Creating the fnodata Configuration File

Begin with the sample configuration file. With the default appdata directory for the current user on Linux:

cp sample-fnodata.conf ~/.fnodata/fnodata.conf

Then edit fnodata.conf with your fnod RPC settings. See the output of fnodata --help for a list of all options and their default values.

Using Environment Variables for Configuration

Almost all configuration items are available to set via environment variables. See the config.go file and the config struct for a complete list of which settings may be set via environment variables. Each setting uses the env struct field tag to specify the name of the environment variable (i.e. env:"FNODATA_USE_TESTNET").

Setting precedence:

Command line flags
Config file settings
Environment variables
Defaults defined in config.go

In general, boolean-typed variables will contain USE, ENABLE, or DISABLE in the name.

For a list of the recognized environment variables, run fnodata --help.

Indexing the Blockchain

If fnodata has not previously been run with the PostgreSQL database backend, it is necessary to perform a bulk import of blockchain data and generate table indexes. This will be done automatically by fnodata on a fresh startup.

Note that fnodata requires that fnod is running with some optional indexes enabled. By default, these indexes are not turned on when fnod is installed. To enable them, set the following in fnod.conf:

txindex=1
addrindex=1

If these parameters are not set, fnodata will be unable to retrieve transaction details and perform address searches, and will exit with an error mentioning these indexes.

Starting fnodata

Launch the fnodata daemon and allow the databases to process new blocks. Concurrent synchronization of both SQLite and PostgreSQL databases is performed, typically requiring between 1.5 to 8 hours. See System Hardware Requirements for more information. Please reread Configuring PostgreSQL (IMPORTANT! Seriously, read this.) of you have performance issues.

On subsequent launches, only blocks new to fnodata are processed.

./fnodata    # don't forget to configure fnodata.conf in the appdata folder!

Unlike fnodata.conf, which must be placed in the appdata folder or explicitly set with -C, the "public" and "views" folders must be in the same folder as the fnodata executable.

Hiding the PostgreSQL db Configuration settings.

By default postgres configuration settings are logged on system start up. --hidepgconfig flag blocks the logging on fnodata start up.

Running the Web Interface During Synchronization

By default, on fnodata startup, a syncing status page is the only page available until sync is completed.

However, most of the explorer pages can be made available via the sync-status-limit setting, which indicates a threshold on the number of blocks yet to sync, below which the entire explorer will be made available. When set with a value on the range [2,5000], all fnodata pages will be active on startup if the number of remaining blocks to process are less than the specified value.

For example, if sync-status-limit is set to 1000, all fnodata pages will be active when fewer than 1000 blocks remain to be processed, otherwise only the sync status page will be accessible until synchronization is complete.

If sync-status-limit is not set (the default), only the sync status page will be available (recommended).

sync-status-limit=1000

It is recommended that you avoid setting sync-status-limit as a value larger than 1000 especially if your machine struggles handling fnodata normal load. Setting a larger value might worsen your situation especially when you try to load processor intensive pages like ticketpool.

System Hardware Requirements

The time required to sync varies greatly with system hardware and software configuration. The most important factor is the storage medium on the database machine. An SSD (preferably NVMe, not SATA) is strongly recommended if you value your time and system performance.

fnodata only (PostgreSQL on other host)

Minimum:

1 CPU core
2 GB RAM
HDD with 4GB free space

fnodata and PostgreSQL on same host

These specifications assume fnodata and postgres are running on the same machine.

Minimum:

2 CPU core
6 GB RAM
HDD with 60GB free space

Recommend:

2+ CPU cores
8+ GB RAM
SSD (NVMe preferred) with 60 GB free space

fnodata Daemon

The root of the repository is the main package for the fnodata app, which has several components including:

Block explorer (web interface).
Blockchain monitoring and data collection.
Mempool monitoring and reporting.
Database backend interfaces.
RESTful JSON API (custom and Insight) over HTTP(S).
Websocket-based pub-sub server.
Exchange rate bot and gRPC server.

Block Explorer

After fnodata syncs with the blockchain server via RPC, by default it will begin listening for HTTP connections on http://127.0.0.1:7777/. This means it starts a web server listening on IPv4 localhost, port 7777. Both the interface and port are configurable. The block explorer and the JSON APIs are both provided by the server on this port.

Note that while fnodata can be started with HTTPS support, it is recommended to employ a reverse proxy such as Nginx ("engine x"). See sample-nginx.conf for an example Nginx configuration.

APIs

The fnodata block explorer is exposed by two APIs: a Fonero implementation of the Insight API, and its own JSON HTTP API. The Insight API uses the path prefix /insight/api. The fnodata API uses the path prefix /api. File downloads are served from the /download path.

Insight API

The Insight API is accessible via HTTP via REST or WebSocket.

See the Insight API documentation for further details.

fnodata API

The fnodata API is a REST API accessible via HTTP. To call the fnodata API, use the /api path prefix.

Endpoint List

Best block	Path	Type
Summary	`/block/best?txtotals=[true	false]`
Stake info	`/block/best/pos`	`types.StakeInfoExtended`
Header	`/block/best/header`	`fnojson.GetBlockHeaderVerboseResult`
Raw Header (hex)	`/block/best/header/raw`	`string`
Hash	`/block/best/hash`	`string`
Height	`/block/best/height`	`int`
Raw Block (hex)	`/block/best/raw`	`string`
Size	`/block/best/size`	`int32`
Subsidy	`/block/best/subsidy`	`types.BlockSubsidies`
Transactions	`/block/best/tx`	`types.BlockTransactions`
Transactions Count	`/block/best/tx/count`	`types.BlockTransactionCounts`
Verbose block result	`/block/best/verbose`	`fnojson.GetBlockVerboseResult`

Block X (block index)	Path	Type
Summary	`/block/X`	`types.BlockDataBasic`
Stake info	`/block/X/pos`	`types.StakeInfoExtended`
Header	`/block/X/header`	`fnojson.GetBlockHeaderVerboseResult`
Raw Header (hex)	`/block/X/header/raw`	`string`
Hash	`/block/X/hash`	`string`
Raw Block (hex)	`/block/X/raw`	`string`
Size	`/block/X/size`	`int32`
Subsidy	`/block/best/subsidy`	`types.BlockSubsidies`
Transactions	`/block/X/tx`	`types.BlockTransactions`
Transactions Count	`/block/X/tx/count`	`types.BlockTransactionCounts`
Verbose block result	`/block/X/verbose`	`fnojson.GetBlockVerboseResult`

Block H (block hash)	Path	Type
Summary	`/block/hash/H`	`types.BlockDataBasic`
Stake info	`/block/hash/H/pos`	`types.StakeInfoExtended`
Header	`/block/hash/H/header`	`fnojson.GetBlockHeaderVerboseResult`
Raw Header (hex)	`/block/hash/H/header/raw`	`string`
Height	`/block/hash/H/height`	`int`
Raw Block (hex)	`/block/hash/H/raw`	`string`
Size	`/block/hash/H/size`	`int32`
Subsidy	`/block/best/subsidy`	`types.BlockSubsidies`
Transactions	`/block/hash/H/tx`	`types.BlockTransactions`
Transactions count	`/block/hash/H/tx/count`	`types.BlockTransactionCounts`
Verbose block result	`/block/hash/H/verbose`	`fnojson.GetBlockVerboseResult`

Block range (X < Y)	Path	Type
Summary array for blocks on `[X,Y]`	`/block/range/X/Y`	`[]types.BlockDataBasic`
Summary array with block index step `S`	`/block/range/X/Y/S`	`[]types.BlockDataBasic`
Size (bytes) array	`/block/range/X/Y/size`	`[]int32`
Size array with step `S`	`/block/range/X/Y/S/size`	`[]int32`

Transaction T (transaction id)	Path	Type
Transaction details	`/tx/T?spends=[true\|false]`	`types.Tx`
Transaction details w/o block info	`/tx/trimmed/T`	`types.TrimmedTx`
Inputs	`/tx/T/in`	`[]types.TxIn`
Details for input at index `X`	`/tx/T/in/X`	`types.TxIn`
Outputs	`/tx/T/out`	`[]types.TxOut`
Details for output at index `X`	`/tx/T/out/X`	`types.TxOut`
Vote info (ssgen transactions only)	`/tx/T/vinfo`	`types.VoteInfo`
Ticket info (sstx transactions only)	`/tx/T/tinfo`	`types.TicketInfo`
Serialized bytes of the transaction	`/tx/hex/T`	`string`
Same as `/tx/trimmed/T`	`/tx/decoded/T`	`types.TrimmedTx`

Transactions (batch)	Path	Type
Transaction details (POST body is JSON of `types.Txns`)	`/txs?spends=[true\|false]`	`[]types.Tx`
Transaction details w/o block info	`/txs/trimmed`	`[]types.TrimmedTx`

Address A	Path	Type
Summary of last 10 transactions	`/address/A`	`types.Address`
Number and value of spent and unspent outputs	`/address/A/totals`	`types.AddressTotals`
Verbose transaction result for last 10 transactions	`/address/A/raw`	`types.AddressTxRaw`
Summary of last `N` transactions	`/address/A/count/N`	`types.Address`
Verbose transaction result for last `N` transactions	`/address/A/count/N/raw`	`types.AddressTxRaw`
Summary of last `N` transactions, skipping `M`	`/address/A/count/N/skip/M`	`types.Address`
Verbose transaction result for last `N` transactions, skipping `M`	`/address/A/count/N/skip/M/raw`	`types.AddressTxRaw`
Transaction inputs and outputs as a CSV formatted file.	`/download/address/io/A`	CSV file

Stake Difficulty (Ticket Price)	Path	Type
Current sdiff and estimates	`/stake/diff`	`types.StakeDiff`
Sdiff for block `X`	`/stake/diff/b/X`	`[]float64`
Sdiff for block range `[X,Y] (X <= Y)`	`/stake/diff/r/X/Y`	`[]float64`
Current sdiff separately	`/stake/diff/current`	`fnojson.GetStakeDifficultyResult`
Estimates separately	`/stake/diff/estimates`	`fnojson.EstimateStakeDiffResult`

Ticket Pool	Path	Type
Current pool info (size, total value, and average price)	`/stake/pool`	`types.TicketPoolInfo`
Current ticket pool, in a JSON object with a `"tickets"` key holding an array of ticket hashes	`/stake/pool/full`	`[]string`
Pool info for block `X`	`/stake/pool/b/X`	`types.TicketPoolInfo`
Full ticket pool at block height or hash `H`	`/stake/pool/b/H/full`	`[]string`
Pool info for block range `[X,Y] (X <= Y)`	`/stake/pool/r/X/Y?arrays=[true\|false]`^*	`[]apitypes.TicketPoolInfo`

The full ticket pool endpoints accept the URL query ?sort=[true\|false] for requesting the tickets array in lexicographical order. If a sorted list or list with deterministic order is not required, using sort=false will reduce server load and latency. However, be aware that the ticket order will be random, and will change each time the tickets are requested.

^*For the pool info block range endpoint that accepts the arrays url query, a value of true will put all pool values and pool sizes into separate arrays, rather than having a single array of pool info JSON objects. This may make parsing more efficient for the client.

Votes and Agendas Info	Path	Type
The current agenda and its status	`/stake/vote/info`	`fnojson.GetVoteInfoResult`
All agendas high level details	`/agendas`	`[]types.AgendasInfo`
Details for agenda {agendaid}	`/agendas/{agendaid}`	`types.AgendaAPIResponse`

Mempool	Path	Type
Ticket fee rate summary	`/mempool/sstx`	`apitypes.MempoolTicketFeeInfo`
Ticket fee rate list (all)	`/mempool/sstx/fees`	`apitypes.MempoolTicketFees`
Ticket fee rate list (N highest)	`/mempool/sstx/fees/N`	`apitypes.MempoolTicketFees`
Detailed ticket list (fee, hash, size, age, etc.)	`/mempool/sstx/details`	`apitypes.MempoolTicketDetails`
Detailed ticket list (N highest fee rates)	`/mempool/sstx/details/N`	`apitypes.MempoolTicketDetails`

Exchanges	Path	Type
Exchange data summary	`/exchanges`	`exchanges.ExchangeBotState`
List of available currency codes	`/exchanges/codes`	[]string

Exchange monitoring is off by default. Server must be started with --exchange-monitor to enable exchange data. The server will set a default currency code. To use a different code, pass URL parameter ?code=[code]. For example, /exchanges?code=EUR.

Other	Path	Type
Status	`/status`	`types.Status`
Coin Supply	`/supply`	`types.CoinSupply`
Endpoint list (always indented)	`/list`	`[]string`

All JSON endpoints accept the URL query indent=[true|false]. For example, /stake/diff?indent=true. By default, indentation is off. The characters to use for indentation may be specified with the indentjson string configuration option.

Important Note About Mempool

Although there is mempool data collection and serving, it is very important to keep in mind that the mempool in your node (fnod) is not likely to be exactly the same as other nodes' mempool. Also, your mempool is cleared out when you shutdown fnod. So, if you have recently (e.g. after the start of the current ticket price window) started fnod, your mempool will be missing transactions that other nodes have.

Command Line Utilities

rebuilddb

rebuilddb is a CLI app that performs a full blockchain scan that fills past block data into a SQLite database. This functionality is included in the startup of the fnodata daemon, but may be called alone with rebuilddb.

rebuilddb2

rebuilddb2 is a CLI app used for maintenance of fnodata's fnopg database (a.k.a. DB v2) that uses PostgreSQL to store a nearly complete record of the Fonero blockchain data. This functionality is included in the startup of the fnodata daemon, but may be called alone with rebuilddb2. See the README.md for rebuilddb2 for important usage information.

scanblocks

scanblocks is a CLI app to scan the blockchain and save data into a JSON file. More details are in its own README. The repository also includes a shell script, jsonarray2csv.sh, to convert the result into a comma-separated value (CSV) file. This app is not actively maintained.

Front End Development

Make sure you have a recent version of node and npm installed. You may want to use the node version manager (nvm) for managing your node download and installation.

From the fnodata root directory, run the following command to install the node modules.

npm install

This will create and install into a directory named node_modules.

You'll also want to run npm install after merging changes from upstream. It is run for you when you use the build script (./dev/build.sh).

For development, there's a webpack script that watches for file changes and automatically bundles. To use it, run the following command in a separate terminal and leave it running while you work. You'll only use this command if you are editing javascript files.

npm run watch

For production, bundle assets via:

npm run build

Both the watch and build scripts create a single output file at /public/js/dist/app.bundle.js. You will need to at least build if changes have been made. watch essentially runs build after file changes, but also performs some additional checks.

CSS Guidelines

Webpack compiles SCSS to CSS while bundling. The watch script described above also watches for changes in these files and performs linting to ensure syntax compliance.

Before you write any CSS, see if you can achieve your goal by using existing classes available in Bootstrap 4. This helps prevent our stylesheets from getting bloated and makes it easier for things to work well across a wide range browsers & devices. Please take the time to Read the docs

Note there is a dark mode, so make sure things look good with the dark background as well.

HTML

The core functionality of fnodata is server-side rendered in Go and designed to work well with javascript disabled. For users with javascript enabled, Turbolinks creates a persistent single page application that handles all HTML rendering.

.tmpl files are cached by the backend, and can be reloaded via running killall -USR1 v4 from the command line.

Javascript

To encourage code that is idiomatic to Turbolinks based execution environment, javascript based enhancements should use Stimulus controllers with corresponding actions and targets. Keeping things tightly scoped with controllers and modules helps to localize complexity and maintain a clean application lifecycle. When using events handlers, bind and unbind them in the connect and disconnect function of controllers which executes when they get removed from the DOM.

Web Performance

The core functionality of fnodata should perform well in low power device / high latency scenarios (eg. a cheap smart phone with poor reception). This means that heavy assets should be lazy loaded when they are actually needed. Simple tasks like checking a transaction or address should have a very fast initial page load.

Helper Packages

package dbtypes defines the data types used by the DB backends to model the block, transaction, and related blockchain data structures. Functions for converting from standard Fonero data types (e.g. wire.MsgBlock) are also provided.

package rpcutils includes helper functions for interacting with a rpcclient.Client.

package stakedb defines the StakeDatabase and ChainMonitor types for efficiently tracking live tickets, with the primary purpose of computing ticket pool value quickly. It uses the database.DB type from github.com/fonero-project/fnod/database with an ffldb storage backend from github.com/fonero-project/fnod/database/ffldb. It also makes use of the stake.Node type from github.com/fonero-project/fnod/blockchain/stake. The ChainMonitor type handles connecting new blocks and chain reorganization in response to notifications from fnod.

package txhelpers includes helper functions for working with the common types fnoutil.Tx, fnoutil.Block, chainhash.Hash, and others.

Internal-use Packages

Some packages are currently designed only for internal use by other fnodata packages, but may be of general value in the future.

blockdata defines:

The chainMonitor type and its BlockConnectedHandler() method that handles block-connected notifications and triggers data collection and storage.
The BlockData type and methods for converting to API types.
The blockDataCollector type and its Collect() and CollectHash() methods that are called by the chain monitor when a new block is detected.
The BlockDataSaver interface required by chainMonitor for storage of collected data.

fnopg defines:

The ChainDB type, which is the primary exported type from fnopg, providing an interface for a PostgreSQL database.
A large set of lower-level functions to perform a range of queries given a *sql.DB instance and various parameters.
The internal package contains the raw SQL statements.

fnosqlite defines:

A sql.DB wrapper type (DB) with the necessary SQLite queries for storage and retrieval of block and stake data.
The WiredDB type, intended to satisfy the DataSourceLite interface used by the fnodata app's API. The block header is not stored in the DB, so a RPC client is used by WiredDB to get it on demand. WiredDB also includes methods to resync the database file.

package mempool defines a MempoolMonitor type that can monitor a node's mempool using the OnTxAccepted notification handler to send newly received transaction hashes via a designated channel. Ticket purchases (SSTx) are triggers for mempool data collection, which is handled by the MempoolDataCollector class, and data storage, which is handled by any number of objects implementing the MempoolDataSaver interface.

Plans

See the GitHub issue trackers and the project milestones.

Contributing

Yes, please! See CONTRIBUTING.md for details, but here's the gist of it:

Fork the repo.
Create a branch for your work (git checkout -b cool-stuff).
Code something great.
Commit and push to your repo.
Create a pull request.

DO NOT merge from master to your feature branch; rebase.

Note that all fnodata.org community and team members are expected to adhere to the code of conduct, described in the CODE_OF_CONDUCT file. These guidelines are generally not a challenge for decent humans.

Also, come chat with us on Matrix in the fnodata channel!

License

This project is licensed under the ISC License. See the LICENSE file for details.

Name		Name	Last commit message	Last commit date
Latest commit History 24 Commits
api		api
blockdata		blockdata
cmd		cmd
db		db
dev		dev
dockerfiles		dockerfiles
docs		docs
exchanges		exchanges
explorer		explorer
fnorates		fnorates
gov		gov
mempool		mempool
middleware		middleware
netparams		netparams
notification		notification
public		public
pubsub		pubsub
rpcutils		rpcutils
semver		semver
stakedb		stakedb
systemstesting		systemstesting
testutil		testutil
txhelpers		txhelpers
version		version
views		views
.babelrc		.babelrc
.dockerignore		.dockerignore
.eslintignore		.eslintignore
.eslintrc.json		.eslintrc.json
.gitignore		.gitignore
.stylelintignore		.stylelintignore
.stylelintrc		.stylelintrc
.travis.yml		.travis.yml
Dockerfile		Dockerfile
LICENSE		LICENSE
README.md		README.md
config.go		config.go
config_test.go		config_test.go
go.mod		go.mod
lint.sh		lint.sh
log.go		log.go
main.go		main.go
package.json		package.json
run_tests.sh		run_tests.sh
run_tests_with_chartests.sh		run_tests_with_chartests.sh
sample-fnodata.conf		sample-fnodata.conf
sample-nginx.conf		sample-nginx.conf
sample-rate_limiting.html		sample-rate_limiting.html
signal.go		signal.go
signal_unix.go		signal_unix.go
webpack.analyze.js		webpack.analyze.js
webpack.common.js		webpack.common.js
webpack.dev.js		webpack.dev.js
webpack.prod.js		webpack.prod.js

License

fonero-project/fnodata

Folders and files

Latest commit

History

Repository files navigation

fnodata

Release Status

Repository Overview

Requirements

Docker Support

Building

Preparation

Package the Static Web Assets

Building fnodata with Go

Setting build version flags

Runtime Resources

Updating

Upgrading Instructions

From v3.x or later

From v2.x or earlier

Getting Started

Configuring PostgreSQL (IMPORTANT! Seriously, read this.)

Creating the fnodata Configuration File

Using Environment Variables for Configuration

Indexing the Blockchain

Starting fnodata

Hiding the PostgreSQL db Configuration settings.

Running the Web Interface During Synchronization

System Hardware Requirements

fnodata only (PostgreSQL on other host)

fnodata and PostgreSQL on same host

fnodata Daemon

Block Explorer

APIs

Insight API

fnodata API

Endpoint List

Important Note About Mempool

Command Line Utilities

rebuilddb

rebuilddb2

scanblocks

Front End Development

CSS Guidelines

HTML

Javascript

Web Performance

Helper Packages

Internal-use Packages

Plans

Contributing

License

About

Resources

License

Code of conduct

Stars

Watchers

Forks

Releases

Packages 0

Contributors 2

Languages

Packages