Author: Marco Gonzàlez
Editor: Randall Roland
Node operators, Antelope core developers, and community members get together each week to discuss the captivating questions of the day. The primary objective of each Node Operator Roundtable is:
“...to improve the Antelope protocol (specifically) for node operators”.
Meetings occur every Wednesday from 14 UTC to 15 UTC.
Beginning February 1, the Node Operator Roundtable discussions focused on configuration parameters for Leap v3.2 and beyond. Special Purpose nodes found inclusion on February 8. Nodes dedicated for special purposes consumed the February 15 and 22 meetings. The group continued to advance the ‘draft taxonomy of the roles that different antelope nodes play’ document.
February 15: Special Purpose Nodes (continued) - API Nodes
Watch the February 15 roundtable discussion on the ENF’s YouTube. Read the notes on EOS Nation (Leap) GitHub.
UPDATE:
As previously discussed, Leap v4.0.0 expects to begin testing on Jungle in March. A consensus upgrade probably won't occur until September. Also, expect a code freeze ahead of the early testing in the coming weeks.
KEY TOPICS DISCUSSED
The last meeting left off with API nodes. The February 15 meeting revisited fundamental definitions for node types. A couple of node types were introduced this week, along with a transaction estimator. See the (draft) antelope node taxonomy for details.
About Node Types
Node type classifications were first defined last week. The focus was on primary purposes.
Previously Discussed Node Types
Block Producer Node, primary goals, and best practices configuration
Blocks-only Relay Node and best practices configuration
Blocks & Transactions Relay Node
Beginning the Focus on API Nodes
Two primary API node types identified were:
Push API Node: “Accepts transactions via HTTP clients, and acts as an outgoing Transaction Relay.”
“Does not accept incoming p2p transactions, unless also acting as a Blocks & Transactions Relay Node.”
Chain API Node: “Provides access to read blockchain primitives… and state data…”
History node types have very different requirements than a chain API node can provide.
See the draft taxonomy document for detailed notes and a potential dedicated discussion.
Closing out the node type classifications this week were the following broad utilities:
Developer Node: for testing, fulfills all node roles on a local device within a single node network
See the draft document for a few more details.
Transaction Estimator: accepts, validates, and applies transactions without relaying to the network
See the draft document for use cases.
Two other node types (classified as “feeders” during next week’s discussion) were:
Snapshotting Node: periodically takes a snapshot and publishes a file to an internal/external host
See the draft document for a more detailed definition.
Trace API Node: records transactional trace information to a client’s local disk to access via API.
Layer-2 Solutions
A Resource Provider Node was among the first identified layer-2 solutions:
Resource Provider Node: accepts, interprets, validates, and performs business logic on client transactions to determine if a cosign is warranted to cover CPU/NET/RAM costs
A note was included about the resource provider node service that may evolve into a turnkey, plugin solution.
OUTLOOK
Several topics coincide with the discussion on node types and potential layer-2 solutions. They include drafting best practices across node types, possibly exploring special node packages, and built-in flags for configuration defaults.
February 22: Special Purpose Nodes (continued) - Feeders and Layer-2
Watch the February 22 roundtable discussion on the ENF’s YouTube. Read the notes on EOS Nation (Leap) GitHub.
UPDATE:
The ENF expects to overview Leap v4.0.0 features ahead of the previously mentioned code freeze. Check back for the date of the roundtable call that overviews new features.
KEY TOPICS DISCUSSED
The special purpose nodes discussion continued with feedback on the (draft) antelope node taxonomy document. Detailed meeting notes can be found there. Introduced were a DeepMind Logger Node and State History Node in advancing a layer-2 solution. History services are of particular interest here.
Note that the idea of 'priority loading' was touched upon. The idea is to institute a 3-strikes rule to solve a longstanding (bot) problem. Priority loading seems effective even when dealing with WAX’s challenging transaction issues. Extending times from half a second to just a few seconds would 'clean out' a node. The solution wouldn’t significantly change existing operations (for most). Extending priority loading to a minute or two would be overkill. A cut-and-dry, efficient solution even if the topic didn't occur on the recording.
Conceptualizing Feeder Nodes
See the previous section for a word about node types. Both feeder node types discussed work by receiving blocks from configured peers. Both also help enable layer-2 history solutions:
DeepMind Logger Node: “continuously serializes current block, traces, etc and streams them into stdout for further processing…”
State History Node: “stores blocks/traces in a state history file…”
Layer-2 Solutions
Following last week’s thoughts on layer-2 solutions were a couple more services. Formatting was key to the discussion.
Event Capture Service: Tackles the job of processing feeder node outputs into special purpose formats to ensure intended purposes. A history provider service was used as an example.
History Provider Service: a basic service available in any format that provides historical data upon a client’s request through an API
Note that the event capture service must handle fork resolution.
OUTLOOK
In addition to the outlook items listed for February 15, several other items were listed under Next Steps- see the (draft) antelope node taxonomy for details. Layer-2 solutions expect to continue next week. Also, a feature matrix for feeders needs to be defined.