Community Roadmap
No Status
backlogPlanned
ready to be startedIn Progress
Deferred
Planning
Community discussionsstatus: Draft title: Developing Metrics for Nano Representatives author: trashman date created: 2024-03-26
Motivation
To help the average Nano holder select a representative, optimizing for Network performance, reliability, self-sovereignty, and censorship resistance.
Design Principles
- easy/quick to understand by the average Nano holder
- use percentiles scaled from 0-100, with 100 being "good" and 0 being "bad"
- prefer objectivity, avoid subjectivity and preferences of the designers except for in cases where there may be unanimous agreement
Specification
Observations will be aggregated from multiple non-voting nodes.
Defining & measuring performance
A performant representative helps blocks reach quorum (confirmation) quickly and consistently. I propose the following metrics to capture speed and consistency
- Vote Latency : A measure of how quickly a representative votes on a block compared to the first vote observed. The percentile rank of the median vote latency for a representative over a period of time will be used with a lower vote latency being considered "good". Vote latency will be calculated for normal and final votes.
- Slow Final Vote : This tracks how often votes arrive late, after a block has reached quorum. The percentile rank of the percentage of slow votes will be calculated over a period of time with a low percentage being considered "good".
- Fast Vote : A fast vote is a vote received before a round of voting has reached quorum. The percentile rank of the percentage of confirmation votes will be calculated over a period of time with a high percentage being considered "good". Fast votes will be calculated for normal and final votes.
- Participation : Participation is defined as the percentage of blocks a vote has been received for over a period of time. The percentile rank of the percentage will be used with a higher percentage being considered "good". Participation will be calculated for normal and final votes.
These metrics will serve as the basis for calculating composite metrics that will then be used to calculate a representative's score. Further research and observation will be required to develop the composite metrics. Potential composite metrics:
- Percentage of periods with a sub-25 percentile vote latency
- Percentage of periods with a sub-25 percentile slow vote
- Percentage of periods with a sub-25 percentile confirmation vote
- Percentage of periods with a sub-25 percentile participation
Defining bad, abusive, and misconfigured behavior, along with censorship
The following events will be considered bad behavior. Reps observed committing these behaviors should be immutably added to the bad behavior list along with the messages observed
- observing conflicting final votes, two different votes for the same election root
- observing conflicting normal votes, two different votes for the same election root and same timestamp
- receiving a conflicting block
- receiving a block belonging to the burn account
Reps observed to be engaging in censorship should be added to the censorship list, along with information about which blocks they are censoring, until the behavior ceases.
- representative will not respond to vote requests for a given block
The following events will be considered abuse or misconfiguration. Reps observed committing these behaviors should be added to the misconfigured reps list until the behavior ceases.
- observing normal or final votes from multiple IPs over a period of time
- receiving invalid signatures (for a block, vote, handshake)
- receiving malformed message headers or bodies
- receiving a fork for a confirmed block
- receiving a block with an invalid balance, height, or work field
- receiving a high rate of unchecked blocks (missing previous or source)
- receiving a high rate of confirmed blocks
Defining & measuring uptime
Uptime will be measured over 1-minute and 5-minute resolutions with a representative being considered online if it generates a single vote (normal or final) for a block first observed in the period being monitored.
Defining & measuring reputation, commitment, and trustworthiness
Developing objective measures of reputation and trustworthiness are challenging, thus I have chosen to focus on commitment and attentiveness. A committed and attentive representative has been running for longer and applies non-contentious updates promptly.
- Time since first observed : The percentile rank of the UNIX timestamp of the first vote observed, with a lower timestamp being "good".
- Slow Upgrades : A slow upgrade is observed when a node does not apply a minor or major upgrade within 7 days of the version achieving a quorum (67%) of voting weight. A low number of slow upgrades will be considered "good".
- Upgrade Latency : Upgrade latency will be measured as the difference in time between a node applying an upgrade and when the version was first applied by a principal representative. The percentile rank of the median upgrade latency will be used with a lower upgrade latency being considered "good".
Defining & measuring censorship, liveliness, and conflict resolution risks of voting weight concentration
Voting weight concentration increases the risk of censorship, liveliness, and conflict resolution issues. The key thresholds for voting weight concentration are 34% (censorship & liveliness) and 67% (conflict resolution) of the online weight or trended weight, whichever is greater. Being that 34% is less than 67% and liveliness is a more prominent risk that threshold should be the focus when considering how to develop a score for voting weight concentration. With that in mind, a potential voting weight score function could be a sigmoid curve scaled from 100 to 0 for voting weight values from 0 to 5%.
Voting Weight Score Formula
where
xis the voting weight percentage
$$ 100 - \frac{100}{1 + e^{-2.5x + 0.6e^2}} $$
0.1% = 98 0.5% = 96 1.0% = 87 1.5% = 66 2.5% = 14 4.0% = 0.3
Defining the "Outdated" List
Representatives that are running an older version than the current version that has quorum will be added to the "Outdated" list. Representatives will remain on this list until they update to a version that has quorum.
Tasks
- update database schema
- implement a light node for message monitoring
- store normal vote and final vote timestamps
- create a script to calculate vote latency, slow votes, confirmation votes, and participation
- create a script to calculate slow upgrades
- create a script to calculate upgrade latency
I propose the introduction of account tags to enhance the categorization and identification of account activities to help generate more informative metrics. These tags aim to provide clearer insights into account behaviors and facilitate better monitoring and management of accounts and blocks.
Below is a table outlining the proposed tags along with their descriptions.
Note: accounts and blocks can have multiple tags
Account Tags
Type Tags
| Tag | Description |
|---|---|
type/faucet | Identifies accounts used for distributing Nano, typically for free. |
type/exchange | Marks accounts that are operated by exchanges. |
type/spam | Tags accounts that are involved in spamming activities. |
type/deposit | Denotes accounts run by a service used primarily for user deposit. |
type/withdrawal | Indicates accounts run by a service used for withdrawals. |
type/payment | Tags accounts that are used for making payments. |
type/donation | Accounts used to receive donations |
type/burn | Burn address or account without a known private key, reducing the possible circulating supply |
type/custodial | Represents accounts that are managed by a third party, holding funds on behalf of users. |
Exchange Tags
| Tag | Description |
|---|---|
exchange/deposit | Marks accounts specifically used for deposit transactions on an exchange. |
exchange/withdrawal | Indicates accounts used for withdrawal transactions from an exchange. |
Block Tags
Type Tags
| Tag | Description |
|---|---|
type/spam | used in spamming activities. |
type/initial_distribution | part of the initial distribution |
Putting some thoughts down regarding how much energy the network actually uses. I'd like to address the often-repeated talking point that the entire Nano network could run off of a single wind turbine.
Below is a screenshot of a spreadsheet I've been working on. Most of it was taken from taken from the Nano Developer Work Generation Guide: https://docs.nano.org/integration-guides/work-generation/#example-benchmarks. 3090 datapoint added by my own test.
Example, best-case scenario:
- Nvidia Tesla V100 (most efficient GPU) is doing 100% of the work for the network
- Constant, 24hr send block creation is 7.25 * 60 * 60 * 24 * 365 = 228,636,000 send blocks/year
- But, we also need receive blocks.
- There are 31,536,000 seconds in a year,
- There’s some number of seconds, X, where:
- 7.25 * (31,536,000 - X) = 420.33 * X
- multiply the 7.25 out:
- 228,636,000 - 7.25X = 420.33 * X
- divide by 420.33:
- 543,944 - ( ( 7.25 * X ) / 420.33) = X
- simplify 7.25 / 420.33:
- 543,944 - ( 0.0172483525 * X ) = X
- add the X component on the left to the right:
- 543,944 = 1.0172483525 * X
- divide by 1.01724…:
- 534,720.94 = X
- Which means:
- 7.25 * (31,536,000 - 534,720.94) = 224,759,280 send blocks/year
- 420.33 * 534,720.94 = 224,759,252 receive blocks/year
- Looks approximately correct ✅
- That uses 250W * 24 * 365 = 2,190,000Wh, or 2,190kWh
- 2,190kWh / 224,759,252 transactions = 0.0000097438 kWh/transaction
- = 0.0097438 Wh / tx
- = 9.7438 mWh / tx
This is JUST PoW, and not energy used by the rest of the network for confirmation.
Also, again, this is a best case scenario. We need to weight it against whatever distribution real-world PoW generation follows.
This would be an important piece of information we could gather that would legitimize this calculation - what GPUs does the network use? Can we survey the biggest nodes/wallets to see what hardware they use to generate work?
Though it’s interesting to see the cross over from dedicated GPU to CPU - I doubt the real-world number is worse than, like, 10x this best-case number.
- USGS says the average wind turbine in the USA:
- “...At a 42% capacity factor (i.e., the average among recently built wind turbines in the United States, per the 2021 edition of the U.S. Department of Energy’s Land-Based Wind Market Report), that average turbine would generate over 843,000 kWh per month...”
- https://www.usgs.gov/faqs/how-many-homes-can-average-wind-turbine-power
- 843,000 kWh / mo x 12 = 10,116,000 kWh / year
Nano.community currently lists network TDP for the last 24 hours as 40.08 kWh
Assuming holding steady for a year, that’s 14,600 kWh / year (Do I have this right? 40.08 kWh accumulated over the last 24 hours, or 40.08 kWh, per hour, averaged over the last 24 hours?)
Taking that into account, we reduce the 10,116,000 kWh produced by the windmill by 14,600 kWh:
- = 10,101,400 kWh / year
- = 10,101,400,000 Wh / year
- = 10,101,400,000,000 mWh / year
10,101,400,000,000 mWh / year / 9.7438 mWh / tx
= 1,038,198,649,397 tx / year
= 32,873 tx / s (best case PoW generation, and using estimated PR TDP for CPU only)
With a goal to increasing the reach of nano.community's content, I propose to start translating the pages and directories into Portuguese-BR (pt-br), with the possibility of changing the language in the user's navigation.
In this way, we could also get input from a wider community that does not speak fluent English.
A counterpoint to this can be making it difficult to keep pages in different languages synchronized and updated. This will require a greater community effort.
Thoughts?
Representative Alerts
Live Network Stats
Ledger Stats
Exchange Stats
Development Events
Community Posts
Account Tags
Representative
Representative Charts
Representative Owner
Hardware Info
Account Info
Account Charts
Send Summary
Receive Summary
Change Summary
Goals
- provide a concise high-level comparison of properties that impact usability.
- provide a comprehensive detailed comparison of each project design properties and live metrics.
Note: Focus is on the protocol design and properties derived from the design. Things like network effects, development, and community are not covered
Properties
General
- Operation Fees (value lost during use/transfer)
- Fees (24h, 7d, 1m)
- Finality / Settlement Time (Confirmation Latency)
- Finality Type (Probabilistic, Deterministic)
- Throughput limit
- Throughput (24h, 7d, 1m)
- Throughput available (24h, 7d, 1m) (achieved minus current)
- Throughput achieved
- Scalability Type
- Current measure of wealth dispersion / Gini Coefficient (ideally by entities, not addresses)
- Network energy usage (total)
- Per Transaction energy usage
- Fungibility Type
- Divisibility
Privacy
- Balance transparency
- Transaction transparency
- Balance auditability
- Privacy type / support (mixers, multisig, zk Proofs, ring signatures, holomorphic)
- Traceable
- Linkable
Initial Distribution
- Initial distribution type
- Initial measure of wealth dispersion / Gini Coefficient
Monetary
- Available supply %
- Annual Inflation %
- Fixed Supply
Structure
- Ledger structure (blockchain, block-lattice, tangle)
- Ordering / global canonical (topological, linear)
- Consistency (global, partial)
- Transaction model (Acct, UTXO)
Networking
- information propagation (broadcast, gossiping, broadcast among validators, broadcast among committee
Consensus / Decentralization
- Type & unit representation (block-less, block-based, block-based expanding graph, blockless expanding graph)
- Classification (BA, Proof Protocols, etc)
- Security Nakamoto Coefficient
- Censorship Nakamoto Coefficient
- Liveliness Nakamoto Coefficient (Decentralization)
- Consensus Fault Tolerance %
- Cost of compromising consensus
- Cost of running a full node
- Cost of running a "trustless" pruned node
- Storage costs / requirements
- Permissionless transaction processing (Openness)
- Hardware costs / barrier to entry
- Self-sovereign / denationalized
- Membership selection (assign, elect, PoW, PoS, dPoS)
- Extension Rule (Nakamoto, Natural, async-BA, TSA, Sampling, RTA, GA, smpl-PBFT, PBFT)
- Conflict Solving (Weight, TR, Fee, Vote, Score, Witness, Query, Hash, etc)
Ledger Interoperability
- Support (central exchange, multisig, federation, entangled chain, sidechains, drivechain, hybrid models, plasma, lightning / interledger)
Usability Support
- store of value & transfer of value
- data anchoring
- data propagation
- data immutability
- copyrighting / timestamping
- data storage
- data privacy
- scripting
- asset representation (i.e. token support)
Governance
- ??
Summary
- Openness / Decentralization
- Security / Sustainability
- Censorship Resistance
- Flexibility
- Interoperability
- Maintainability
- Turing-complete scripting
- Token support
- Data payload
- Opaqueness
- Traceability
- Transaction content visibility
- User unidentifiability
- Node controller verificiation
- Policy
- Auditability
- Compliance
- Degree of Decentralization
- Liability
- Performance
- Confirmation Latency
- Resource Consumption
- Propagation Delay
- Scalability
- Throughput
- Transaction Validation Latency
- Usability / Practicality
- Transaction Fee
- Ease of Node Setup
- Ease of Use
- Support for Constrained Devices
Features
Filter based on tags Filter based on property values
Quick start guide for setting up and running the nano work server, and sending it requests from various languages (js, python, ruby, golang, etc)
Add a section to the running a node page with instructions on how to get a node up and running from source or binary.
Given that community education is key to keeping Nano decentralized, I propose we create a page dedicated to explaining why holders are strongly encouraged to withdraw from Binance/other exchanges and delegate to a good representative.
It could be another link in the Guides menu, perhaps called Why Withdraw?. Also, another idea was to have a URL redirect to the page: nano.community/withdraw redirecting to nano.community/getting-started-users/withdraw (for consistency). That way, it is easier to link in a reddit comment/Discord/etc.
Please let me know your thoughts!
https://nano.community/faqs
Examples:
- https://bitcoiner.guide/qna/
Reply with potential questions (one per reply so they can be individually discussed).
https://nano.community/introduction/basics
Potential Topics
Example: https://nano.community/tags/privacy
Goals
- limiting effort in regurgitating past comments
- point people to the most pertinent past comments and discussions on a specific topic
- provide a high-level summary, status, and roadmap for the topic.
Potential Process
- any user comments on a thread and their comment contain a distinct command (i.e. !nano.community [topic])
- a bot will then comment on the thread with a summary and status of the topic and link out to the topic page which lists the top past posts on the topic
- people will downvote/upvote the bot comment which will determine whether or not that post will be categorized
Contributing
- Write a summary for a proposed topic
- Identify paste discussions to be linked to the topic (reddit, discord, forum)
Ledger Stats Over Time (10mins, Hour, Day, Month)
Tasks
https://nano.community/getting-started-devs/getting-started