You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HN 1.1 Trendsetter is about providing access to the historic information about the NEO network.
At the moment, none of the tools (blockchain explorers or CoZ Monitor) store historic information about the state of the nodes. Some illustrations of the limitations of existing systems:
How good is a node? Client-side trackers like CoZ's monitor only tells you it's very recent status. When deciding things like Consensus, it's important to look further back. HN 1.0 stores this information but doesn't expose it (it also shows a recent summary).
How is the network growing or shrinking over time? Without a history, you don't know if there were 30 nodes or 10 nodes last year? Looking at the mainnet.json file for example doesn't really help as many of those nodes don't work (and that file is not generated automatically).
How long does it take for a block to propagate? NEO has a different problem to other blockchains. Because NEO has finality, once a block has been decided, that is it. However, it still needs to be communicated from the Consensus nodes through to the other Nodes and then into the wider web. Measuring that and the evolution over time is currently unavailable with existing tools.
The /historic api has a lot of possibilities. It also has access to a lot of data. I think part of the performance requirement is that this will not perform as fast as the main /flash api, queries may take 15-20 seconds to run at a time.
Here is a broad sketch of a proposed API, which we can then evolve:
/historic
/node/stability - individual node stability over time
HN 1.1 Trendsetter is about providing access to the historic information about the NEO network.
At the moment, none of the tools (blockchain explorers or CoZ Monitor) store historic information about the state of the nodes. Some illustrations of the limitations of existing systems:
The /historic api has a lot of possibilities. It also has access to a lot of data. I think part of the performance requirement is that this will not perform as fast as the main /flash api, queries may take 15-20 seconds to run at a time.
Here is a broad sketch of a proposed API, which we can then evolve:
/historic
/node/stability - individual node stability over time
params: start_dt, end_dt, granularity
e.g. start_dt=1/1/18, end_dt=5/1/18, granularity=daily
returns back:
{ data:
[{ts: 1/1/18, stability: 98},...,{ts:5/1/18, stability:100}]
}
/node/blockheight_lag - avg difference between best blockheight and its known blockheight
params: start_dt, end_dt, granularity
e.g. start_dt=1/1/18, end_dt=5/1/18, granularity=daily
returns back:
{ data:
[{ts: 1/1/18, lag: 0.8},...,{ts:5/1/18, lag:0.4}]
}
/node/latency - avg server-side latency in ms
params: start_dt, end_dt, granularity
e.g. start_dt=1/1/18, end_dt=5/1/18, granularity=daily
returns back:
{ data:
[{ts: 1/1/18, latency: 812},...,{ts:5/1/18, latency:411}]
}
/network/size - number of online and offline nodes over time
params: start_dt, end_dt, granularity, options (p2p, json-rpc, both, either)
e.g. start_dt=1/1/18, end_dt=5/1/18, granularity=daily
returns back:
{ data:
[{ts: 1/1/18, online: 33, total: 70},...,{ts:5/1/18, online: 45, total: 79]
}
The text was updated successfully, but these errors were encountered: