search

EOS-Nation / leap

8 stars 0 forks source link

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

Open chillsauce opened 1 year ago

chillsauce commented 1 year ago

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

Technical roundtable for Antelope Node Operators

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)