Week 16 - January 18 - Antelope resource model recap, future topics, special-purpose nodes

[chillsauce]

Antelope Node Operator Roundtable

Antelope Node Operators, community members and Antelope core developers meet every Wednesday at 14:00 UTC to discuss opportunities to improve the Antelope protocol for node operators.

💬 Join us in Telegram
🗂 See all meeting summaries

🗓 January 18 - 14:00 UTC

🎥 Watch the recording
Passcode: 490xi*Av

Summary

🟢 Leap Software Status

• Antelope software updates coming soon:
  • Patch releases for 3.1 and 3.2 to address Ship instability issues
  • New release of DUNE

Technical roundtable for Antelope Node Operators

• Brian from ENF provided a resource model status update and lead a discussion to solicit feedback on future roundtable topics, as well as some more specific discussion around special-purpose nodes.

Quick Status Update on Resource Model

- Not yet committing to doing these things
- Pain Points Discussion
    - RAM scalability limits
    - Ease of use challenges
    - Impact to Service Nodes
- Potential Scope Identified
    - Bill for failed transactions
    - Enable off-chain service node abuse prevention at proxy layer
    - State scaling strategy
    - Ability to lower RAM cost reduction rate
    - Contract access to account resource usage
- Next steps
    - Determine how these changes play with other related changes being made by ENF, Grant Recipients, RFP winners
    - Select initiatives
    - Prioritize against other initiatives
    - Organize into target releases
    - Technical design
    - Work breakdown

Future Roundtable Topic Brainstorm

- Ross: Challenges with Peering
    - Rotation of Peers
    - State of Peer latency status
    - Ross: First stop is Matthew’s EOS nation tool
    - Daniel: EOS Nation has someone who’s full time job is dealing with Peering.
    - Kevin: Default of 100 blocks at a time is not good
- Denis: Single Resource Model
    - Get into detail on merging NET and CPU
- Denis: What the chain has used with Anchor and PowerUp to address usability.
    - What NATIVE solutions could we implement?
    - BOID PowerUp tool
    - Opportunity right now as Aaron/Greymass is implementing WharfKit
    - When PowerUp goes down, the most frequent reason is because it needs a PowerUp
    - BOID - potential “easy win” solution listen to transactions on an endpoint and trigger a PowerUp - “Auto PowerUp”.
    - New client SDKs would likely be ready before a server implementation would be possible.
- Aaron: Resource Payer in 2.1 but not in LEAP
    - This would be nice to have
    - Don’t append no-op actions
    - A protocol feature that could be enabled to override first-action is payer
- Aaron: A method to guarantee connectivity between peers
    - Like a peer key, but with a priority
    - Operator is running public nodes, it can get full because of non-preferred peers.
- Denis: Contract error handling on other contracts
    - They interact with other smart contracts
    - When there is an error it is non-explicit
    - They don’t even know what contract the error is coming from.
    - Matt Witherspoon has an idea of a Backtrace

Nodes that are dedicated to a specific purpose

- Aaron: Read-only nodeos instances
    - On Steem there was a flag you could set when launching a node so that it would be read-only
    - Read-only to the state
    - Prevents syncing and push transactions
    - The read only nodeos instance would read from the state file of another nodeos instance
    - Greymass has servers that run many nodes instances and each needs it’s own state file
    - This would alleviate pressure off of nodes that are syncing/writing
    - More radical alternatives
        - Could the state itself be streamed into some other solution? DFuse, The Graph
    - Matthew and Thiago adds me too
- Matthew: Relay only nodes don’t need any state
    - We’ve discussed this idea some before
    - Would allow for more efficient block propagation
    - Kevin: Relevant PRs
        - [Propagate block after header validation #590](https://github.com/AntelopeIO/leap/pull/590)
        - [Parallelize Read-only Transaction Execution Design Document #130](https://github.com/eosnetworkfoundation/product/pull/130/files)

Participants (19)

• Kevin Heifner
• Marco Gonzalez (MachnBird Sparo)
• Brian Hazzard
• '@I_Seth |Boid|Animus BlockBase
• Patrick | Aloha EOS (Patrick)
• Daniel Keyes | EOS Nation
• Stephen Diesel
• Denis 🚀
• Max_Cho :: KOREOS Owner-South Korea
• Jeff Werner
• '@Boidcom
• Rakeden | WAX (Giiaaannis)
• Thiago Canellas_EOS Rio
• Matthew Darwin
• Ross (EOSphere)
• Aaron Cox
• Dario | EOSsupport.io
• junhank | NodeONE
• Ted Cahall