###### tags: `Algorand` `Relay Node Program` `Validator` ap@algorand.foundation Put usdca or algorand address and send to email address (Invoicing). Impetus for Meeting: tl;dr - they want input from node runners re: performance and node runner experience). # Community Relay Node Program Motivation: * What information is meaningful? * Is this community node runing useful? * Is the relay node important to the network? * How do we add long-term to the ecosystem to compensate relay node runners? * What do you see from your node? (discrepancies of views of other nodes from nodes re: performance | network inconsistences) They are grateful for any input/feedback at all. They want to learn from this experience. They want decentralized nodes. They want things you measure (yourself on your node). (They have done early invester nodes and have run high-performance nodes by the Foundation and Inc., they want to see the quality of life from the perspective of community decentralized nodes now.) # Meeting Minutes: > > *NRC stands for Node Runner Comment > *FC stands for Foundation Comment > *Q stands for Question. All questions are formatted as Node Runners question then Foundation response. NRC - Provide snapshots of the chain or some start jump point. NRC - Prometheus/Datadog - No utilization of CPU to justify current specs. General low CPU usage by node runners. Q - Are we being throttled and are we going to get more traffic later? | Response vague. Node runners are running over-provisioned right now just in case network usage spikes it seems. Q - We are seeing 280 connections inbound at peak 120 on average - What is normal? | Shai Response: Not sure, we want that input. Network is built such that nodes connecting to each other drop unreliable ones and maintain reliable ones. Q - Will the smart contracts make big performance differences? | You can engineer transactions to be space inefficient (would have to write down all the public keys) but it is not expected to impact node utilization significantly in high load. NRC - Mismatch in names - "round"/"block" between rest API | Fabrice acknowledged mismatch and says to document. Q - Do we need to engineer redundancy or is the network redundant enough w/ the series of relays that it has? Q - Is there any work on srv record? Will there be a way to onboard themselves? - They want two list of relays. One new community-based one. Core relay list and community one. | They have centralization at foundation level. Single DNS provider/cloud provider for everything. FC - They'd like to develop a sensible reputation list for nodes in the long-run. They want ideas of how to develop one. FC: Nodes all have the same weight right now. Node runners might want differently weighted nodes based on performance (not limited by CPU, RAM, egress, etc.). Q - Can you have two nodes that share same telemetry configuration? - Using different telemetry IDs so they don't show as being down. | Fabrice: Each have a different telemetry ID by load balancer. No automated removal of poor perfoming nodes, done manually by Foundation. Q - Node runners would like updating of documentation re: Prometheus Collectors. Opening too many TCP sockets and leaving them hanging. They had to turn off hardware monitoring by default. How much metrics do you want us to collect via Prometheus? | (Fabrice: Document issues and report. All metrics appreciated to whatever extent you can provide.) NRC - Maybe Telegram to communicate between operators. Some method of communication that is better than email. | They'll be creating a private Discord channel for server operators. Q - Will there be a requirement to "rip out all the guts" and redo the specs of the nodes? | No. They don't see this happening. Q - Is there a way to control how big the chain grows? Are relay node runners supposed to maintain 5TB storages next year, etc.? | Relay nodes provide gossiping and blocks for catchup. There is work to provide these two in separate. The blockchain grows infinitely and there is nothing removing that. Q - Are you looking into sharding? | No plan into sharding. There will be performance impact and they don't see that. Slower old data accessing is going to be expected in coming decades. Q - When will invoices be paid out? | Jack Zhang, Shai and Fabrice will review invoice/node performance and payout. Q - What will need to be measured for invoice? | They don't have many tools to measure beyond telemetry info. They just want raw performance info. for now. Maintain synchronization and serves the last block and relay is ON and does telemetry properly. Basic stuff. Don't want it to take beyond 1ms latency 4ms is too long. Q - Do we ICNP? | No they will check report manually. Q - Do we need post-mortems just in general from technical issue? Network/cloud provider issues, data center on fire, etc. lol | We will need to know what happened. Basic documentation nothing crazy formal. They'll ask you what they need. They'll work with you. Informal process. Q - Are you routing all traffic through Cloudflare? | No only 4. Everything else is through TC/IP. Q - They see massive spikes in DNS queries, but no between node queries. Why is this happening? The query is for our relay node's DNS record. | Fabrice: No idea. Interesting. Can you send logs? If you have any other questions/comments/concerns please attend the second meeting for follow-up.