[DOCS/operators]: Release changes v2024.13-magura & Tokenomics pages v1.0 (#5128)
* add directory changes to changelog * exit gateway page update * finish general tokenomics page * add new operator toolings * progressing with release notes * add smart contract migration and bonding steps * add new bonding steps * add tokenomics roadmap * added new pages to introduction - ready for review * ready for review * edit callout custom * rm CalloutCustom.tsx * syntax fix * temp build version fix by hardcode * built after review changes * remove redundant point * final commit - let's merge
This commit is contained in:
import this
@@ -0,0 +1,36 @@
|
||||
export const Clt = ({ children, backgroundColor = 'white', borderColor = 'black', pointPosition = 'left', pointOffset = '2rem', pointAlignment = 'end', pointTranslate, pointLength = '2rem', cornerRadius = '0.5rem', borderWidth = '0.2rem', pointWidthMultiplier = 0.5, pointLengthMultiplier = 1, style = {} }) => {
|
||||
|
||||
|
||||
const center = pointAlignment === 'center'
|
||||
const offset = center ? '50%' : pointOffset
|
||||
const translate = center ? (pointPosition === 'left' || pointPosition === 'right') ? 'translateY(-50%)' : 'translateX(-50%)' : pointTranslate
|
||||
const wMult = Math.min(pointWidthMultiplier, 0.99)
|
||||
const lMult = Math.max(pointLengthMultiplier, 1)
|
||||
|
||||
const props = {
|
||||
'--pointLength': pointLength,
|
||||
'--positionOffset': offset,
|
||||
'--bkg-color': backgroundColor,
|
||||
'--bdr-color': borderColor,
|
||||
'--corner-radius': cornerRadius,
|
||||
'--border-width': borderWidth,
|
||||
'--pointWidthMultiplier': wMult,
|
||||
'--pointLengthMultiplier': lMult,
|
||||
...style
|
||||
}
|
||||
|
||||
|
||||
|
||||
return (
|
||||
<div className={`clt ${pointPosition}`} style={props}>
|
||||
<div className={`clt__bubble ${pointPosition}`}>
|
||||
<div className="clt__content">
|
||||
{children}
|
||||
</div>
|
||||
</div>
|
||||
<div className={`clt__point-wrapper ${pointPosition} ${pointAlignment}`} style={{ ...(translate && { transform: translate }) }}>
|
||||
<div className={`clt__point ${pointPosition}`} />
|
||||
</div>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
803_103_234
|
||||
+1
@@ -0,0 +1 @@
|
||||
0.64%
|
||||
+1
@@ -0,0 +1 @@
|
||||
44.811
|
||||
+1
@@ -0,0 +1 @@
|
||||
1_016_987
|
||||
+1
@@ -0,0 +1 @@
|
||||
50.0%
|
||||
+1
@@ -0,0 +1 @@
|
||||
401_551_617
|
||||
@@ -0,0 +1,7 @@
|
||||
| **Item** | **Description** | **Amount in NYM** |
|
||||
|:-------------------|:------------------------------------------------------|--------------------:|
|
||||
| Total Supply | Maximum amount of NYM token in existence | 1_000_000_000 |
|
||||
| Mixmining Reserve | Tokens releasing for operators rewards | 196_896_265 |
|
||||
| Vesting Tokens | Tokens locked outside of cicrulation for future claim | 500 |
|
||||
| Circulating Supply | Amount of unlocked tokens | 803_103_234 |
|
||||
| Stake Saturation | Optimal size of node self-bond + delegation | 1_016_987 |
|
||||
@@ -1 +1 @@
|
||||
Tuesday, October 29th 2024, 09:51:52 UTC
|
||||
Tuesday, November 19th 2024, 11:34:21 UTC
|
||||
|
||||
@@ -1,5 +1,4 @@
|
||||
```sh
|
||||
[2m2024-10-29T09:51:53.363364Z[0m [32m INFO[0m [2mnym-api/src/main.rs[0m[2m:[0m[2m41[0m[2m:[0m Starting nym api...
|
||||
Usage: nym-api [OPTIONS] <COMMAND>
|
||||
|
||||
Commands:
|
||||
@@ -10,9 +9,9 @@ Commands:
|
||||
|
||||
Options:
|
||||
-c, --config-env-file <CONFIG_ENV_FILE>
|
||||
Path pointing to an env file that configures the Nym API [env: NYMAPI_CONFIG_ENV_FILE_ARG=]
|
||||
Path pointing to an env file that configures the Nym API
|
||||
--no-banner
|
||||
A no-op flag included for consistency with other binaries (and compatibility with nymvisor, oops) [env: NYMAPI_NO_BANNER_ARG=]
|
||||
A no-op flag included for consistency with other binaries (and compatibility with nymvisor, oops)
|
||||
-h, --help
|
||||
Print help
|
||||
-V, --version
|
||||
|
||||
@@ -44,8 +44,6 @@ Options:
|
||||
Specify whether detailed system crypto hardware information should be exposed. default: true [env: NYMNODE_HTTP_EXPOSE_CRYPTO_HARDWARE=] [possible values: true, false]
|
||||
--mixnet-bind-address <MIXNET_BIND_ADDRESS>
|
||||
Address this node will bind to for listening for mixnet packets default: `0.0.0.0:1789` [env: NYMNODE_MIXNET_BIND_ADDRESS=]
|
||||
--mixnet-announce-port <MIXNET_ANNOUNCE_PORT>
|
||||
If applicable, custom port announced in the self-described API that other clients and nodes will use. Useful when the node is behind a proxy [env: NYMNODE_MIXNET_ANNOUNCE_PORT=]
|
||||
--nym-api-urls <NYM_API_URLS>
|
||||
Addresses to nym APIs from which the node gets the view of the network [env: NYMNODE_NYM_APIS=]
|
||||
--nyxd-urls <NYXD_URLS>
|
||||
@@ -62,8 +60,6 @@ Options:
|
||||
The prefix denoting the maximum number of the clients that can be connected via Wireguard. The maximum value for IPv4 is 32 and for IPv6 is 128 [env: NYMNODE_WG_PRIVATE_NETWORK_PREFIX=]
|
||||
--verloc-bind-address <VERLOC_BIND_ADDRESS>
|
||||
Socket address this node will use for binding its verloc API. default: `0.0.0.0:1790` [env: NYMNODE_VERLOC_BIND_ADDRESS=]
|
||||
--verloc-announce-port <VERLOC_ANNOUNCE_PORT>
|
||||
If applicable, custom port announced in the self-described API that other clients and nodes will use. Useful when the node is behind a proxy [env: NYMNODE_VERLOC_ANNOUNCE_PORT=]
|
||||
--entry-bind-address <ENTRY_BIND_ADDRESS>
|
||||
Socket address this node will use for binding its client websocket API. default: `0.0.0.0:9000` [env: NYMNODE_ENTRY_BIND_ADDRESS=]
|
||||
--announce-ws-port <ANNOUNCE_WS_PORT>
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
803_103_234
|
||||
@@ -0,0 +1,7 @@
|
||||
| **Item** | **Description** | **Amount in NYM** |
|
||||
|:-------------------|:------------------------------------------------------|--------------------:|
|
||||
| Total Supply | Maximum amount of NYM token in existence | 1_000_000_000 |
|
||||
| Mixmining Reserve | Tokens releasing for operators rewards | 196_896_265 |
|
||||
| Vesting Tokens | Tokens locked outside of cicrulation for future claim | 500 |
|
||||
| Circulating Supply | Amount of unlocked tokens | 803_103_234 |
|
||||
| Stake Saturation | Optimal size of node self-bond + delegation | 1_016_987 |
|
||||
Vendored
+1
-1
@@ -2,4 +2,4 @@
|
||||
/// <reference types="next/image-types/global" />
|
||||
|
||||
// NOTE: This file should not be edited
|
||||
// see https://nextjs.org/docs/basic-features/typescript for more information.
|
||||
// see https://nextjs.org/docs/pages/building-your-application/configuring/typescript for more information.
|
||||
|
||||
@@ -3,6 +3,8 @@ import { Tabs } from 'nextra/components';
|
||||
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
import { Steps } from 'nextra/components';
|
||||
|
||||
|
||||
|
||||
export const TestingSteps = () => (
|
||||
@@ -31,6 +33,523 @@ This page displays a full list of all the changes during our release cycle from
|
||||
|
||||
<VarInfo />
|
||||
|
||||
## `v2024.13-magura`
|
||||
|
||||
Magura release represents a bigger milestone in [project Smoosh](archive/faq/smoosh-faq.mdx) development where `nym-node` is one binary able to perform any function in Nym Mixnet. This release is especially crucial for operators, please pay attention to the section [*Operators Updates & Tooling*](#operators-updates--tooling) below.
|
||||
|
||||
- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.13-magura)
|
||||
- [Release CHANGELOG.md](https://github.com/nymtech/nym/blob/nym-binaries-v2024.13-magura/CHANGELOG.md)
|
||||
- [`nym-node`](nodes/nym-node.mdx) version `1.1.10`
|
||||
|
||||
```sh
|
||||
nym-node
|
||||
Binary Name: nym-node
|
||||
Build Timestamp: 2024-11-18T17:02:50.947941194Z
|
||||
Build Version: 1.1.10
|
||||
Commit SHA: b49ef643df86f0c670672429812c632fbbaf6cf1
|
||||
Commit Date: 2024-11-18T17:56:57.000000000+01:00
|
||||
Commit Branch: HEAD
|
||||
rustc Version: 1.82.0
|
||||
rustc Channel: stable
|
||||
cargo Profile: release
|
||||
```
|
||||
|
||||
- [New smart contracts](https://github.com/nymtech/nym/releases/tag/nym-contracts-magura)
|
||||
|
||||
- **[New wallet version 1.2.15](https://github.com/nymtech/nym/releases/tag/nym-wallet-v1.2.15) is out!** - allowing operators to migrate to `nym-node` in Mixnet smart contract.
|
||||
|
||||
- [New wallet changelog](https://github.com/nymtech/nym/blob/nym-wallet-v1.2.15/nym-wallet/CHANGELOG.md)
|
||||
|
||||
- [New directory services v2.1: API & Mixnet contract changes](#directory-services-v21-api--mixnet-contract-changes)
|
||||
|
||||
### Features
|
||||
|
||||
- [Migrate Legacy Node (Frontend) ](https://github.com/nymtech/nym/pull/4826)
|
||||
|
||||
- [Directory Sevices v2.1](https://github.com/nymtech/nym/pull/4903): Read section [Directory Services v2.1: API & Mixnet Contract Changes ](#directory-services-v21-api--mixnet-contract-changes) below with detailed explanation or the [PR notes](https://github.com/nymtech/nym/pull/4903)
|
||||
|
||||
- [Switch over the last set of jobs to arc runners](https://github.com/nymtech/nym/pull/4938): Switch over the remaining GH jobs using 16-core runners to self-hosted arc runners. Since we can't currently use Docker on the ubuntu-20.04 runners, remove the matrix notification steps
|
||||
|
||||
<AccordionTemplate name={<TestingSteps/>}>
|
||||
Confirm that the deployment workflows work through manual testing
|
||||
- [x] cd-docs
|
||||
- [x] publish-sdk-npm
|
||||
</AccordionTemplate>
|
||||
|
||||
- [V2 performance monitoring feature flag](https://github.com/nymtech/nym/pull/4943): Feature flag to use v2 network monitor results in rewarding
|
||||
|
||||
- [Add `utoipa` feature to nym-node](https://github.com/nymtech/nym/pull/4945): `cargo build -p nym-node` was failing, since its depending on `QueryParams` having `utoipa` traits derived
|
||||
|
||||
- [Ticket type storage](https://github.com/nymtech/nym/pull/4947)
|
||||
|
||||
- [`nym-api` container](https://github.com/nymtech/nym/pull/4948)
|
||||
|
||||
- [Extract packet processing from mixnode-common](https://github.com/nymtech/nym/pull/4949): First step on a journey of making a strong interface around packet processing, and packet processing portability. This one only moves stuff around, so it should be safe to just blindly merge.
|
||||
|
||||
- [expose authenticator address along other address in node-details](https://github.com/nymtech/nym/pull/4953): Expose authenticator address along ip packet router and network requester for easier parsing
|
||||
|
||||
- [Feature/contract state tools](https://github.com/nymtech/nym/pull/4954): Introduced/reimplemented old tools for importing cosmwasm contract states given a kv dump file. This makes it significantly easier to plan and test complex state migrations on actual chains where we risk timing out on expensive operations.
|
||||
|
||||
- [Add env feature to clap and make clap parameters available as env variables](https://github.com/nymtech/nym/pull/4957)
|
||||
|
||||
- [Bump sqlx to 0.7.4](https://github.com/nymtech/nym/pull/4959)
|
||||
|
||||
- [`Product Data` First step in gateway usage data collection](https://github.com/nymtech/nym/pull/4963): This PR is the first step towards collecting data on gateway usage. It builds up on an old code for what was then nym-connect. It exposes unique users count and connection time histogram on the `metrics/sessions` endpoint of the self-described API on entry-gateways. For the time being, data is collected by probing the `ActiveClientStore` every minute and extracting data from this. Data is stored internally and exposed on the next day, i.e. UTC day $d$ exposes data from day $d-1$. The [`statistics`](https://github.com/nymtech/nym/tree/simon/product_data/gateway/src/node/statistics) module will evolve as we add collection for product data and censorship resistance study. The collection will also eventually switch from probing to event-based for more accurate data.
|
||||
|
||||
- [`importer-cli` to correctly handle mixnet/vesting import](https://github.com/nymtech/nym/pull/4966)
|
||||
|
||||
- [Import `nym-vpn-api` crates](https://github.com/nymtech/nym/pull/4967): Keep these crates in a separate workspace for now. The idea is to add them to the main workspace in time, but this appears to might require some changes to how sqlite is used. Alternatively these issues might go away once we upgrade sqlite in the main workspace. Also we intend to rename some of these to something like `nym-credential-facade`, and the wasm lib should be incorporated in one of the existing crates in `common`.
|
||||
|
||||
- [chore: remove unused rocket code](https://github.com/nymtech/nym/pull/4968)
|
||||
|
||||
- [add Dockerfile for nym node](https://github.com/nymtech/nym/pull/4972)
|
||||
|
||||
- [`Product Data` Add session type based on ecash ticket received](https://github.com/nymtech/nym/pull/4974): Fire an `EcashTicket` event for the `GatewayStatisticsCollector`, when an Ecash ticket is being accepted. This allows to mark an active session as being a mixnet session or a vpn session. It also changes the format of the related self-described data, to accommodate that new session type.
|
||||
|
||||
- [Top up bandwidth](https://github.com/nymtech/nym/pull/4975)
|
||||
|
||||
- [feature: require reporting using nym-node binary for rewarded set selection](https://github.com/nymtech/nym/pull/4976)
|
||||
|
||||
- [Re-enable vested delegation migration](https://github.com/nymtech/nym/pull/4977): supersedes [\#4956](https://github.com/nymtech/nym/pull/4956) by removing the contract migration code as it's already been run on mainnet.
|
||||
|
||||
- [Resolve beta clippy issues in contracts](https://github.com/nymtech/nym/pull/4978)
|
||||
|
||||
- [Enable global ecash routes even if api is not a signer](https://github.com/nymtech/nym/pull/4980)
|
||||
|
||||
- [Rename `nym-vpn-api` to `nym-credential-proxy`](https://github.com/nymtech/nym/pull/4981)
|
||||
|
||||
- [Add topup req constructor](https://github.com/nymtech/nym/pull/4983)
|
||||
|
||||
- [Eliminate 0 bandwidth race check](https://github.com/nymtech/nym/pull/4988)
|
||||
|
||||
- [Make accepting t&c a hard requirement for rewarded set selection](https://github.com/nymtech/nym/pull/4993)
|
||||
|
||||
- [chore: update itertools in compact ecash](https://github.com/nymtech/nym/pull/4994): supersedes [\#4916](https://github.com/nymtech/nym/pull/4916)
|
||||
|
||||
- [Push private ip before inserting](https://github.com/nymtech/nym/pull/5008)
|
||||
|
||||
- [Adjusted ticket sizes to the agreed amounts](https://github.com/nymtech/nym/pull/5009)
|
||||
|
||||
- [Consume only positive bandwidth](https://github.com/nymtech/nym/pull/5013)
|
||||
|
||||
- [Reapply fixes to new branch](https://github.com/nymtech/nym/pull/5014)
|
||||
|
||||
- [Added `get_all_described_nodes` to NymApiClient and adjusted return](https://github.com/nymtech/nym/pull/5016)
|
||||
|
||||
- [feature: use axum_client_ip for attempting to extract source ip](https://github.com/nymtech/nym/pull/5031): improves source ip logging by extracting relevant header when nym-api is run behind a proxy
|
||||
|
||||
- [Pass poisson flag ](https://github.com/nymtech/nym/pull/5037)
|
||||
|
||||
- [Added hacky routes to return nymnodes alongside legacy nodes](https://github.com/nymtech/nym/pull/5051)
|
||||
|
||||
- [Use unstable explorer client](https://github.com/nymtech/nym/pull/5058): Clean up stale testruns & better logging:
|
||||
- use new `/unstable` endpoints on explorer for backwards compatibility
|
||||
- log gw identity key
|
||||
- better agent testrun logging
|
||||
- log responses on server side
|
||||
- change response code for agents
|
||||
- update sqlx data
|
||||
- fix agent - probe gw bug
|
||||
|
||||
- [Merge1/release/2024.13 magura](https://github.com/nymtech/nym/pull/5061)
|
||||
|
||||
- [Merge2/release/2024.13 magura](https://github.com/nymtech/nym/pull/5063)
|
||||
|
||||
- [Feature/wallet bonding fixes](https://github.com/nymtech/nym/pull/5064)
|
||||
|
||||
- [Allow nym node config updates](https://github.com/nymtech/nym/pull/5066)
|
||||
|
||||
- [NS API with directory v2 (#5058)](https://github.com/nymtech/nym/pull/5068)
|
||||
|
||||
- [chore: deprecated old nym-api client methods and replaced them when possible](https://github.com/nymtech/nym/pull/5069): this is to that the next time those methods are used outside the monorepo, the relevant calls flag up the CI via clippy
|
||||
|
||||
- [Allow custom http port to be reset](https://github.com/nymtech/nym/pull/5073)
|
||||
|
||||
- [Fix gateway decreasing bandwidth](https://github.com/nymtech/nym/pull/5075): Make sure to update the storage after each decrease with the new values. Also set the storage values to 0 on restart for existing peers, as kernel peers can't have those values set to 0
|
||||
|
||||
- [Fix expiration date as today + 7 days](https://github.com/nymtech/nym/pull/5076)
|
||||
|
||||
- [Don't increase bandwidth two times](https://github.com/nymtech/nym/pull/5081)
|
||||
|
||||
- [Make 250 GB/30 days for free ride mode](https://github.com/nymtech/nym/pull/5083)
|
||||
|
||||
- [Nym node - Fix claim delegator rewards](https://github.com/nymtech/nym/pull/5090)
|
||||
|
||||
- [Add more translations from v2 to v3 authenticator](https://github.com/nymtech/nym/pull/5091)
|
||||
|
||||
- [Graceful agent 1.1.5](https://github.com/nymtech/nym/pull/5093): API improvements:
|
||||
- agent exits gracefully when no testrun available
|
||||
- agent reads content of server's error message in case of 503
|
||||
- API doesn't log every error (to avoid log spam)
|
||||
- update network probe within NS agent image: [CI rebuild](https://github.com/nymtech/nym/blob/release/2024.13-magura/nym-node-status-agent/Dockerfile#L9) of NS agent will pick up updated network probe
|
||||
|
||||
- [Remove old use of 1GB constant](https://github.com/nymtech/nym/pull/5096)
|
||||
|
||||
- [Add NYM_VPN_API to env files](https://github.com/nymtech/nym/pull/5099)
|
||||
|
||||
- [Feature/force refresh node](https://github.com/nymtech/nym/pull/5101): currently if nodes update their role from say mixnode to entry-gateway, it might take quite a while for `nym-api` to pick up the change and thus they might be losing performance. With this change, the node will be force refreshed on its startup
|
||||
|
||||
- [`nym-credential-proxy-requests`: reqwest use rustls-tls](https://github.com/nymtech/nym/pull/5116)
|
||||
|
||||
- [change: dont select mixnodes bonded with vested tokens into the rewarded set](https://github.com/nymtech/nym/pull/5129)
|
||||
|
||||
- [Pain/polyfill deprecated endpoints](https://github.com/nymtech/nym/pull/5131)
|
||||
|
||||
- [Respond to auth messages with same version](https://github.com/nymtech/nym/pull/5140)
|
||||
|
||||
- [Limit race probability](https://github.com/nymtech/nym/pull/5145)
|
||||
|
||||
|
||||
### Bugfix
|
||||
|
||||
- [Fix critical issues SI84 and SI85 from Cure53](https://github.com/nymtech/nym/pull/4758): This pull request fixes the following issues:
|
||||
- NYM-01-009 WP5: BLS12-381 EC signature bypasses in Coconut library (Critical)
|
||||
- NYM-01-014 WP5: Partial signature bypass in offline eCash (Critical)
|
||||
|
||||
- [bugfix: correctly paginate through 'search_tx' endpoint](https://github.com/nymtech/nym/pull/4936): when `results.append(&mut res.txs);` was called, `res.txs` was always empty thus it was impossible to return more than page size number of results
|
||||
|
||||
- [Fix broken build after merge](https://github.com/nymtech/nym/pull/4937)
|
||||
|
||||
- [Bugfix/rewarder post pruning adjustments](https://github.com/nymtech/nym/pull/4942): this PR introduces/fixes the following:
|
||||
- dedicated commands to request specific blocks for processing
|
||||
- decreased websocket failure timeout
|
||||
- ensuring we do actually have sufficient number of blocks to process rewarding for given epoch
|
||||
- additional error logging
|
||||
|
||||
- [bugfix: fix expected return type on /v1/gateways endpoint](https://github.com/nymtech/nym/pull/4965)
|
||||
|
||||
- [Bugfix/additional directory fixes](https://github.com/nymtech/nym/pull/4973): This branch introduces additional fixes to the new directory services
|
||||
|
||||
- [Fix critical issues SI86 and SI87 from Cure53](https://github.com/nymtech/nym/pull/4982): This pull request fixes the following issues:
|
||||
- Faulty aggregation to invalid offline eCash signatures
|
||||
- Signature forgery of Pointcheval-Sanders schema
|
||||
|
||||
- [bugfix: client memory leak](https://github.com/nymtech/nym/pull/4991): This fixes memory leaks in all the clients. however, they were most prominent in `nym-api` during network monitoring due to the sheer amount of packets being pushed
|
||||
|
||||
- [Fix rustfmt in nym-credential-proxy](https://github.com/nymtech/nym/pull/4992)
|
||||
|
||||
- [bugfix: directory v2.1 `get_all_avg_gateway_reliability_in_interval` query](https://github.com/nymtech/nym/pull/5023): fixes query for avg gateway performance (no idea why it makes a difference, but it does...)
|
||||
|
||||
- [bugfix: missing #[serde(default)] for announce port](https://github.com/nymtech/nym/pull/5024)
|
||||
|
||||
- [bugfix: introduce 'LegacyPendingMixNodeChanges' that does not contain 'cost_params_change'](https://github.com/nymtech/nym/pull/5028)
|
||||
|
||||
- [bugfix: verifying signed information of legacy nodes](https://github.com/nymtech/nym/pull/5029)
|
||||
|
||||
- [bugfix: fixed backwards incompatibility for /gateways/described endpoint](https://github.com/nymtech/nym/pull/5030)
|
||||
|
||||
- [bugfix: make sure to use correct highest node id when assigning role](https://github.com/nymtech/nym/pull/5032)
|
||||
|
||||
- [bugfix: use old name for 'epoch_role' in SkimmedNode](https://github.com/nymtech/nym/pull/5034)
|
||||
|
||||
- [bugfix: use human readable roles for annotations](https://github.com/nymtech/nym/pull/5036)
|
||||
|
||||
- [bugfix: make gateways insert themselves into [local] topology](https://github.com/nymtech/nym/pull/5038)
|
||||
|
||||
- [bugfix: use bonded nym-nodes for determining initial network monitor …](https://github.com/nymtech/nym/pull/5039)
|
||||
|
||||
- [bugfix: make sure nym-nodes are also tested by network monitor](https://github.com/nymtech/nym/pull/5040)
|
||||
|
||||
- [bugfix: don't assign exit gateways to standby set](https://github.com/nymtech/nym/pull/5041)
|
||||
|
||||
- [bugfix: fix ecash handlers routes](https://github.com/nymtech/nym/pull/5043)
|
||||
|
||||
- [bugfix: restore default http port for nym-api](https://github.com/nymtech/nym/pull/5045): when it was run under 'rocket' server the port used was 8000. let's restore that value
|
||||
|
||||
- [bugfix: supersede 'cb13be27f8f61d9ae74d924e85d2e6787895eb14' by using…](https://github.com/nymtech/nym/pull/5046)
|
||||
|
||||
- [bugfix: adjust runtime storage migration](https://github.com/nymtech/nym/pull/5047): remove the panic during migration as the gateway count can actually be different if some of them have already migrated to nym-nodes before the code has been run
|
||||
|
||||
- [bugfix: mark migrated gateways as rewarded in the previous epoch in case theyre in the rewarded set](https://github.com/nymtech/nym/pull/5049)
|
||||
|
||||
- [bugfix/feature: added NymApiClient method to get all skimmed nodes](https://github.com/nymtech/nym/pull/5062)
|
||||
|
||||
- [bugfix: use corrext axum extractors for ecash route arguments](https://github.com/nymtech/nym/pull/5065)
|
||||
|
||||
- [bugfix: credential-proxy obtain-async](https://github.com/nymtech/nym/pull/5067)
|
||||
|
||||
- [bugfix: wallet backend fixes](https://github.com/nymtech/nym/pull/5070)
|
||||
|
||||
- [bugfix: additional checks inside credential proxy](https://github.com/nymtech/nym/pull/5072)
|
||||
|
||||
- [bugfix: [wallet] displaying delegations for native nymnodes](https://github.com/nymtech/nym/pull/5087)
|
||||
|
||||
- [bugfix: preserve as much as possible of the rewarded set during migration](https://github.com/nymtech/nym/pull/5103)
|
||||
|
||||
- [bugfix: make sure to assign correct node_id and identity during 'gateway_details' table migration](https://github.com/nymtech/nym/pull/5142)
|
||||
|
||||
- [bugifx: assign 'node_id' when converting from 'GatewayDetails' to 'TestNode'](https://github.com/nymtech/nym/pull/5143)
|
||||
|
||||
### Operators Updates & Tooling
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
**Every operator has to make sure that their nodes [self-described endpoint works](nodes/performance-and-testing/node-api-check#basic-api-usage), otherwise the node will be un-routable and thus won't get any rewards!**
|
||||
</Callout>
|
||||
|
||||
- **New technical documentation:** All Nym documentation starts from a new entry page [nymtech.net/docs](https://nymtech.net/docs/operators/introduction). To run locally or propose collaboration, start in our [repository](https://github.com/nymtech/nym/tree/develop/documentation)
|
||||
|
||||
- **New [Tokenomics chapter](tokenomics.mdx) with [Mixnet Rewards page](tokenomics/mixnet-rewards.mdx)**
|
||||
|
||||
- **[Operators release & rewards roadmap](tokenomics/mixnet-rewards.mdx#roadmap)**
|
||||
|
||||
- **New [Operators landing pag e](https://nymtech.net/operators)
|
||||
|
||||
- [Nym Harbourmaster](https://harbourmaster.nymtech.net) had a new tab `NODE SEARCH` where operators can easily search nodes by identity keys and owner accounts and get all public information listed.
|
||||
|
||||
- Simplified [bonding](nodes/nym-node/bonding.mdx) and [Mixnet smart contract migration](nodes/nym-node/bonding.mdx#migrate-to-nym-node-in-mixnet-smart-contract)
|
||||
|
||||
- Nodes bonded with vesting tokens are [not allowed to join rewarded set](https://github.com/nymtech/nym/pull/5129) - read more on [Nym operators forum](https://forum.nymtech.net/t/vesting-accounts-are-no-longer-supported/827)
|
||||
|
||||
#### Wallet changes
|
||||
|
||||
**[New wallet version 1.2.15](https://github.com/nymtech/nym/releases/tag/nym-wallet-v1.2.15) is out!**
|
||||
|
||||
- [New wallet changelog](https://github.com/nymtech/nym/blob/nym-wallet-v1.2.15/nym-wallet/CHANGELOG.md)
|
||||
|
||||
- This version of wallet allows and prompts operators to migrate their gateway or mixnode to a `nym-node` in the Mixnet smart contract - an important step in [project smoosh](archive/faq/smoosh-faq.mdx). To do so follow these steps:
|
||||
|
||||
<br />
|
||||
<AccordionTemplate name="Steps to use wallet for node migration">
|
||||
<Steps>
|
||||
|
||||
###### 1. Download the wallet from [the release page](https://github.com/nymtech/nym/releases/tag/nym-wallet-v1.2.15)
|
||||
|
||||
###### 2. Verify the binary and extract it if needed
|
||||
|
||||
- Download [`hashes.json`](https://github.com/nymtech/nym/releases/download/nym-wallet-v1.2.15/hashes.json)
|
||||
- Open it with your text editor or print it's content with `cat hashes.json`
|
||||
- Run `sha256sum <WALLET_BINARY>` for example `sha256sum ./nym-wallet_1.2.15_amd64.AppImage`
|
||||
- If your have to extract it (like `.tar.gz`) do it
|
||||
|
||||
###### 3. Open the wallet and sign in
|
||||
|
||||
###### 4. Migrate!
|
||||
|
||||
- Go to Bonding and you will be prompted with such message:
|
||||
|
||||
|
||||
|
||||
- In case you for some reason didn't see the prompt or you closed it - you can click in the upper right corner of the same window on this button:
|
||||
|
||||
|
||||
|
||||
- Confirm the transaction
|
||||
|
||||
###### 5. Welcome to new episode of `nym-node`!
|
||||
|
||||
</ Steps>
|
||||
</AccordionTemplate>
|
||||
|
||||
- **Older versions will not allow bonding new nodes!**
|
||||
|
||||
|
||||
|
||||
#### Selection & Rewarding
|
||||
|
||||
- **Config score is introduced:** In the current version the nodes selection to the active set has a new parameter (which multiplies the existing formula) - `config_score`. Config score looks if the node binary is `nym-node` (not legacy `nym-mixnode` or `nym-gateway`) **AND** if [Terms & Conditions](nodes/nym-node/setup.mdx#terms--conditions) are accepted. Config score has binary values of either 0 or 1, with a following logic:
|
||||
|
||||
| **Run `nym-node` binary** | **T&C's accepted** | **`config_score`** |
|
||||
| :-- | :-- | ---: |
|
||||
| True | False | 0 |
|
||||
| False | True | 0 |
|
||||
| False | False | 0 |
|
||||
| True | True | 1 |
|
||||
|
||||
- The active set selection formula is then:
|
||||
> CONFIG_SCORE \* STAKE_SATURATION \* PERFORMANCE ^ 20
|
||||
|
||||
- Currently in *Native rewarding*, the rewards are split equally across the [rewarded set of nodes](https://validator.nymtech.net/api/v1/epoch/reward_params) (which now = active set and it's size is 240 nodes) for both Mixnet mode and dVPN mode. Every node being assigned 1 / 240 work factor (hence *naive rewarding*).
|
||||
|
||||
#### Directory Services v2.1: API & Mixnet Contract Changes
|
||||
|
||||
Magura release brings [breaking changes on API](https://github.com/nymtech/nym/pull/4903) logic of Nym. New APIs will only communicate with `nym-node` from this release and newer. Also old version of APIs won't be able to communicate with the new version of `nym-node`. We are also moving towards completely removing Nym Explorer API, which now has been only used to report nodes location.
|
||||
|
||||
Any new bonded node will provide only the bare minimum information: host, identity key and optionally custom port of its HTTP api - we highly recommend to set that one up to `8080`. Everything else will be discovered via the self-described API for maximum flexibility. This also includes the sphinx key, meaning if the API is not exposed, the node will be unable to route any traffic. Furthermore, this allows to arbitrary change of `nym-node` from mixnode into a gateway modes (and vice versa) without losing any delegations.
|
||||
|
||||
The contract changes also mean any node functionality can get rewards. Rather than just with assigned mixing roles, gateways now also added into the pool. However, to be eligible for gateway rewarding, one must [migrate into a `nym-node`](#wallet-changes) on a smart contract level (or bond a new node).
|
||||
|
||||
##### API High Level Changes
|
||||
|
||||
###### New/Added
|
||||
|
||||
- All new routes that return multiple nodes/entries/etc now wrap their responses to expect pagination. Currently, however, full data is returned for each of the endpoints since the pagination hasn't been implemented yet. But once we add it, it won't be a breaking API change.
|
||||
|
||||
###### Removed
|
||||
|
||||
- `rocket` support has been completely removed. All routes are now always served via `axum`
|
||||
|
||||
###### Changed
|
||||
|
||||
- Getting anything to do with all nodes (including gateways) requires knowing their `node_id`. For legacy gateway endpoints, we have a helper method that translates identity key to the `node_id`
|
||||
- Rewarded set is no longer populated with just mixnodes. Instead `nym-node`s are assigned to eligible roles (based on stake and performance) in the following order:
|
||||
- entry gateways
|
||||
- exit gateways
|
||||
- mixnodes
|
||||
- standby
|
||||
- A lot of legacy routes got deprecated. while technically they still "work" and return data, they only return data for legacy `nym-mixnode` and `nym-gateway`. What it means is that as operators are migrating their nodes (in the smart contract), those endpoints will start running dry.
|
||||
- Since layers are only assigned during rewarded set assignment, for the purposes of network monitor (v1) and legacy mixnode routes, layerless nodes are put on random layers during annotation
|
||||
- All legacy gateway queries now also include additional field in their respones: `node_id` that indicate the id pre-assigned during contract migration
|
||||
- Nym Node performance is a bit odd. When network monitors (v1 and v2) were made, there was no concept of a Nym Node. The solution taken is checking whther there is any mixnode performance for node with a given id, if so - return it. Otherwise we grab the equivalent gateway performance. In the future it should probably be averaged or maybe split into explicit mixing or gateway routing performance metrics.
|
||||
|
||||
##### `nym-api` Changes
|
||||
|
||||
- Root route `/` now redirects to `/swagger`
|
||||
|
||||
###### `nym-node` Routes
|
||||
|
||||
<br />
|
||||
|
||||
<AccordionTemplate name="Nym Node API routes">
|
||||
- `/v1/nym-nodes/annotation/<NODE_ID>` - get annotation about particular `nym-node`, as gathered by this `nym-api`. Currently this just includes last 24h performance metric and the current node role
|
||||
- `/v1/nym-nodes/bonded` - get bond information about Nym Nodes, as present in the mixnet contract
|
||||
- `/v1/nym-nodes/described` - get described information about Nym Nodes, as present on their self-described API
|
||||
- `/v1/nym-nodes/historical-performance/<NODE_ID>` - return historical performance of this `nym-node` on the provided date
|
||||
- `/v1/nym-nodes/performance-history/<NODE_ID>` - return performance history of this `nym-node` (as a 0 - 1 float)
|
||||
- `/v1/nym-nodes/uptime-history/<NODE_ID>` - return current uptime of this `nym-node` (as a 0 - 100 u8); added for compatibility with existing APIs using that data format
|
||||
- `/v1/nym-nodes/performance/<NODE_ID>` - return current performance of this `nym-node`
|
||||
</ AccordionTemplate>
|
||||
|
||||
<br />
|
||||
|
||||
<AccordionTemplate name="Unstable API routes">
|
||||
- `/v1/unstable/nym-nodes/noise` - returns basic information needed for the noise protocol between nodes
|
||||
- `/v1/unstable/nym-nodes/skimmed/active` - returns all: Nym Nodes and legacy mixnodes and legacy gateways, that are currently in the active set, unless `no-legacy` parameter is used
|
||||
- `/v1/unstable/nym-nodes/skimmed/mixnodes/active` - returns all: Nym Nodes and legacy mixnodes, that are currently in the active set, unless `no-legacy` parameter is used
|
||||
- `/v1/unstable/nym-nodes/skimmed/mixnodes/all` - returns all: Nym Nodes and legacy mixnodes, that are currently bonded and support mixing role, unless `no-legacy` parameter is used
|
||||
- `/v1/unstable/nym-nodes/skimmed/entry-gateways/active` - returns all: Nym Nodes and legacy gateways, that are currently in the active set and are assigned the entry role, unless `no-legacy` parameter is used
|
||||
- `/v1/unstable/nym-nodes/skimmed/exit-gateways/active` - returns all: Nym Nodes and legacy gateways, that are currently in the active set and are assigned the exit role, unless `no-legacy` parameter is used
|
||||
- `/v1/unstable/nym-nodes/skimmed/entry-gateways/all` - returns all: Nym Nodes and legacy gateways, that are currently bonded and support entry gateway role, unless `no-legacy` parameter is used
|
||||
- `/v1/unstable/nym-nodes/skimmed/exit-gateways/all` - returns all: Nym Nodes and legacy gateways, that are currently bonded and support exit gateway role, unless `no-legacy` parameter is used
|
||||
</ AccordionTemplate>
|
||||
|
||||
###### Deprecated (will be removed eventually, so please migrate away from their usage)
|
||||
|
||||
Some endpoints got purposely deprecated without any equivalent reimplemented since they do not belong on `nym-api`. This includes for example `/stake-saturation` (which can be obtained directly from the contract instead) or `/inclusion-probability` (for this run your own Monte Carlo simulation).
|
||||
<br />
|
||||
|
||||
<AccordionTemplate name="Deprecated API routes">
|
||||
- `contract-cache` routes - all of the below got deprecated as they will only return **legacy** `nym-mixnode` and `nym-gateway` data:
|
||||
- `/v1/gateways`
|
||||
- `/v1/gateways/blacklisted`
|
||||
- `/v1/mixnodes`
|
||||
- `/v1/mixnodes/active` - just to restate the obvious, it will only return a small **SUBSET** of the active set that since it will ignore active Nym Nodes
|
||||
- `/v1/mixnodes/active/detailed`
|
||||
- `/v1/mixnodes/blacklisted`
|
||||
- `/v1/mixnodes/detailed`
|
||||
- `/v1/mixnodes/rewarded`
|
||||
- `/v1/mixnodes/rewarded/detailed`
|
||||
- `status` routes - all of the below got deprecated as they will only return **legacy** `nym-mixnode` and `nym-gateway` data:
|
||||
- `/v1/status/gateway/<ID_KEY>/report`
|
||||
- `/v1/status/gateway/<ID_KEY>/history`
|
||||
- `/v1/status/gateway/<ID_KEY>/core-status-count`
|
||||
- `/v1/status/gateway/<ID_KEY>/avg_uptime`
|
||||
- `/v1/status/gateways/detailed`
|
||||
- `/v1/status/gateways/detailed-unfiltered`
|
||||
- `/v1/status/mixnode/<MIX_ID>/report`
|
||||
- `/v1/status/mixnode/<MIX_ID>/history`
|
||||
- `/v1/status/mixnode/<MIX_ID>/core-status-count`
|
||||
- `/v1/status/mixnode/<MIX_ID>/avg_uptime`
|
||||
- `/v1/status/mixnodes/detailed`
|
||||
- `/v1/status/mixnodes/detailed-unfiltered`
|
||||
- `/v1/status/mixnode/<MIX_ID>/status`
|
||||
- `/v1/status/mixnode/<MIX_ID>/reward-estimation`
|
||||
- `/v1/status/mixnode/<MIX_ID>/compute-reward-estimation`
|
||||
- `/v1/status/mixnode/<MIX_ID>/stake-saturation`
|
||||
- `/v1/status/mixnode/<MIX_ID>/inclusion-probability`
|
||||
- `/v1/status/mixnodes/inclusion_probability`
|
||||
- `/v1/status/mixnodes/rewarded/detailed`
|
||||
- `/v1/status/mixnodes/active/detailed`
|
||||
- `nym-node` routes - all of the below got deprecated as they will only return **legacy** `nym-mixnode` and `nym-gateway` data:
|
||||
- `/v1/gateways/described`
|
||||
- `/v1/mixnodes/described`
|
||||
|
||||
|
||||
- `Unstable Nym Nodes Routes`:
|
||||
- `/v1/unstable/nym-nodes/mixnodes/skimmed` - due to inconsistency in behaviour (i.e. active vs all) it is now redirected to `/v1/unstable/nym-nodes/mixnodes/skimmed/active` and unwraps the pagination
|
||||
- `/v1/unstable/nym-nodes/gateways/skimmed` - due to inconsistency in behaviour (i.e. active vs all) it is now redirected to `/v1/unstable/nym-nodes/entry-gateways/skimmed/all` and unwraps the pagination
|
||||
</ AccordionTemplate>
|
||||
|
||||
<br />
|
||||
|
||||
<AccordionTemplate name="Changed API routes">
|
||||
- `Unstable Nym Nodes Routes`:
|
||||
- `/v1/unstable/nym-nodes/skimmed` - now works with `exit` parameter
|
||||
- `/v1/unstable/nym-nodes/skimmed` - introduced `no-legacy` flag to ignore legacy `nym-mixnode` and `nym-gateway` (where applicable)
|
||||
- `/v1/unstable/nym-nodes/skimmed` - will now return all nodes if no query parameter is provided
|
||||
</ AccordionTemplate>
|
||||
|
||||
##### Mixnet Contract
|
||||
|
||||
<Callout type="warning" emoji="">
|
||||
**Every operator has to make sure that their nodes [self-described endpoint works](nodes/performance-and-testing/node-api-check#basic-api-usage), otherwise the node will be un-routable and thus won't get any rewards!**
|
||||
</Callout>
|
||||
|
||||
###### High Level Changes
|
||||
|
||||
**New/Added**
|
||||
|
||||
- All new nodes are now bonded as Nym Nodes, even when using old `BondMixnode` or `BondGateway` messages (messages are getting translated)
|
||||
- Operators only announce nodes identity key (`<ID_KEY>`), host and port to the directory. Everything else is discovered via self-described endpoint
|
||||
- All Nym Nodes in the rewarded set are eligible for rewards and staking. Even if they serve one of the gateway roles. Legacy gateways can't be staked on nor get rewards.
|
||||
- All nodes, including legacy mixnodes and legacy gateways, are now uniquely identified by a monotonically increasing `node_id`
|
||||
- All legacy gateways are preassigned `node_id` during the contract migration
|
||||
|
||||
**Removed**
|
||||
|
||||
> 🔥 all concepts of node families got purged, removed, deleted, thrown into the abyss. they simply no longer exist and the world is all better for it.
|
||||
|
||||
**Changed**
|
||||
|
||||
- Bunch of types got changed/renamed with some fields being added/removed/deprecated. It's be quite a lot of work to list them all here, but whenever possible and feasible, they should be cross-compatible (but not always).
|
||||
- Rewarded set is no longer just a "number". Instead it has an explicit number of all `nym-node` modes: mixnodes, entry and exit gateways as well as standby nodes
|
||||
- Rewarding is now based on two parameters: performance and work factor as opposed to performance and "is active" flag. However, in practice, during this transitional period, it is assumed that the work factor will be equivalent to what would have been calculated using the old "is active" flag
|
||||
|
||||
###### Transaction Messages Changes
|
||||
|
||||
<br />
|
||||
|
||||
<AccordionTemplate name="Added transaction messages">
|
||||
- `BondNymNode` - self-explanatory
|
||||
- `UnbondNymNode` - self-explanatory
|
||||
- `UpdateNodeConfig` - works as `UpdateMixnodeConfig`; it lets you change your announced host or http api port
|
||||
- `MigrateMixnode` - migrate your existing legacy mixnode into a Nym Node
|
||||
- `MigrateGateway` - migrate your exsting legacy gasteway into a Nym Node. enables staking and rewarding
|
||||
- `AssignRoles` - an additional step for epoch transition transactions. think of it as a replacement for `AdvanceCurrentEpoch`. it assigns nodes to particular roles for the given epoch
|
||||
</AccordionTemplate>
|
||||
|
||||
<br />
|
||||
|
||||
<AccordionTemplate name="Removed transaction messages">
|
||||
- As mentioned, all family-related things got killed off, so the following no longer exist: `CreateFamily`, `JoinFamily`, `LeaveFamily`, `KickFamilyMember`, `CreateFamilyOnBehalf`, `JoinFamilyOnBehalf`, `LeaveFamilyOnBehalf`, `KickFamilyMemberOnBehalf`
|
||||
- `UpdateActiveSetSize` - the rewarded/active set are now based on the role distribution
|
||||
- `AssignNodeLayer` - we're no longer explicitly assigning roles to all mixnodes, instead they get assigned mixing roles
|
||||
- `AdvanceCurrentEpoch` - the logic for advancing the epoch/assigning active set has changed so this message was removed
|
||||
</AccordionTemplate>
|
||||
|
||||
|
||||
## `v2024.12.1-aero` - patch
|
||||
|
||||
- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.12.1-aero)
|
||||
- `nym-node` patch only, no other binaries
|
||||
|
||||
```sh
|
||||
nym-node
|
||||
Binary Name: nym-node
|
||||
Build Timestamp: 2024-11-07T08:45:13.162565620Z
|
||||
Build Version: 1.1.9-1
|
||||
Commit SHA: ccdee808303ffcfa8ed77176d3f629512045febb
|
||||
Commit Date: 2024-11-06T16:31:30.000000000+01:00
|
||||
Commit Branch: HEAD
|
||||
rustc Version: 1.82.0
|
||||
rustc Channel: stable
|
||||
cargo Profile: release
|
||||
```
|
||||
|
||||
### Changes
|
||||
|
||||
- Fixed timeout connectivity issues with authenticator
|
||||
- Amended network allowance cap
|
||||
|
||||
## `v2024.12-aero`
|
||||
|
||||
- [Release binaries](https://github.com/nymtech/nym/releases/tag/nym-binaries-v2024.12-aero)
|
||||
|
||||
@@ -6,10 +6,9 @@ import { MyTab } from 'components/generic-tabs.tsx';
|
||||
|
||||
# Community Counsel: Running Exit Gateway
|
||||
|
||||
|
||||
This page is a part of Nym Community Counsel (before Legal Forum) and its content is composed by shared advices in [Node Operators Legal Forum](https://matrix.to/#/!YfoUFsJjsXbWmijbPG:nymtech.chat?via=nymtech.chat&via=matrix.org) (Matrix chat) as well as though pull requests done by the node operators directly to our [repository](https://github.com/nymtech/nym/tree/develop/documentation/docs/pages/operators), reviewed by Nym DevRels.
|
||||
|
||||
This document presents an initiative to further support Nym’s mission of allowing privacy for everyone everywhere. This would be achieved with the support of Nym node operators operating Gateways and opening these to any online service. Such setup needs a **clear policy**, one which will remain the **same for all operators** running Nym nodes. [**Nym exit policy**](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) is a combination of safeguards like (nowadays deprecated) `Tor Null deny list` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy aims to find a healthy compromise between protecting the operators and NymVPN users against attacks while allowing for as wide experience when accessing the internet through Nym Network.
|
||||
This document presents an initiative to further support Nym’s mission of allowing privacy for everyone everywhere. This would be achieved with the support of Nym node operators operating Gateways and opening these to any online service. Such setup needs a **clear policy**, one which will remain the **same for all operators** running Nym nodes. [**Nym exit policy**](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) was inspired by (nowadays deprecated) Tor Null deny list and Tor reduced policy and created to meet the changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy aims to find a healthy compromise between protecting the operators and NymVPN users against attacks while allowing for as wide experience when accessing the internet through Nym Network.
|
||||
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
@@ -19,13 +18,17 @@ The following part is for informational purposes only. Nym core team cannot prov
|
||||
|
||||
## Summary
|
||||
|
||||
* This document outlines a plan to change Nym Gateways from operating with an ‘allow’ to a ‘deny’ list to enable broader uptake and usage of the Nym Mixnet. It provides operators with an overview of the plan, pros and cons, legal as well as technical advice.
|
||||
**Nym supports privacy for everyone, everywhere.**
|
||||
|
||||
To offer a better and more private everyday experience for its users, Nym would like them to use any online services they please, without limiting its access to a few messaging apps or crypto wallets.
|
||||
|
||||
To achieve this, operators running Exit Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays following [Nym exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt).
|
||||
|
||||
* Nym is committed to ensuring privacy for all users, regardless of their location and for the broadest possible range of online services. In order to achieve this aim, the Nym Mixnet needs to increase its usability across a broad range of apps and services.
|
||||
|
||||
* Currently, Nym Gateway nodes only enable access to apps and services that are on an ‘allow’ list that is maintained by the core team.
|
||||
* To decentralise and enable privacy for a broader range of services, Nym transitioned from allow list to a deny list - creating a new [Nym exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt).
|
||||
|
||||
* To decentralise and enable privacy for a broader range of services, this initiative will have to transition from the current ‘allow’ list to a ‘deny’ list - [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt). In accordance with the (nowadays deprecated) `Tor Null deny list` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464))
|
||||
* Future changes of the exit policy is done via an off-chain governance, like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464).
|
||||
|
||||
* This will enhance the usage and appeal of Nym products for end users. As a result, increased usage will ultimately lead to higher revenues for Nym operators.
|
||||
|
||||
@@ -36,35 +39,6 @@ The following part is for informational purposes only. Nym core team cannot prov
|
||||
|
||||
* This document serves as the basis for a consultation with Nym node operators on any concerns or additional support and information you need for this change to be successful and ensure maximum availability, usability and adoption.
|
||||
|
||||
## Goal of the initiative
|
||||
|
||||
**Nym supports privacy for everyone, everywhere.**
|
||||
|
||||
To offer a better and more private everyday experience for its users, Nym would like them to use any online services they please, without limiting its access to a few messaging apps or crypto wallets.
|
||||
|
||||
To achieve this, operators running Exit Gateways would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays following this [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt).
|
||||
|
||||
## Pros and cons of the initiative
|
||||
|
||||
Previous setup: Running nodes supporting strict SOCKS5 app-based traffic
|
||||
|
||||
| **Dimension** | **Pros** | **Cons** |
|
||||
| :--- | :--- | :--- |
|
||||
| Aspirational | | - Very limited use cases, not supportive of the “Privacy for everyone everywhere” aspiration - Limited appeal to users, low competitiveness in the market, thus low usage |
|
||||
| Technical | - No changes required in technical setup | |
|
||||
| Operational | - No impact on operators operations (e.g., relationships with VPS providers) - Low overhead - Can be run as an individual | |
|
||||
| Legal | - Limited legal risks for operators | |
|
||||
| Financial | | - Low revenues for operators due to limited product traction |
|
||||
|
||||
|
||||
The new setup: Running nodes supporting traffic of any online service (with safeguards in the form of a denylist)
|
||||
|
||||
| **Dimension** | **Pros** | **Cons** |
|
||||
| :--- | :--- | :--- |
|
||||
| Aspirational | - Higher market appeal of a fully-fledged product able to answer all users’ use cases - Relevance in the market, driving higher usage | |
|
||||
| Technical | - Very limited changes required in the technical setup (changes in the allow -> denylist) | - Increased monitoring required to detect and prevent abuse (e.g. spam) |
|
||||
| Operational | | - Higher operational overhead, such as dealing with DMCA / abuse complaints, managing the VPS provider questions, or helping the community to maintain the denylist - Administrative overhead if running nodes as a company or an entity |
|
||||
| Legal | | - Ideally requires to check legal environment with local privacy association or lawyer | Financial | - Higher revenue potential for operators due to the increase in network usage | - If not running VPS with an unlimited bandwidth plan, higher costs due to higher network usage |
|
||||
|
||||
## Exit Gateways: New setup
|
||||
|
||||
@@ -74,20 +48,22 @@ This restricts the hosts that the NymConnect app can connect to and has the effe
|
||||
|
||||
The principal change in the new configuration is to make this short allow list more permissive. Nym's [exit policy](https://nymtech.net/.wellknown/network-requester/exit-policy.txt) will restrict the hosts to which Nym Mixnet and Nym VPN users are permitted to connect. This will be done in an effort to protect the operators, as Gateways will act both as SOCKS5 Network Requesters, and exit nodes for IP traffic from Nym Mixnet VPN and VPN clients (both wrapped in the same app).
|
||||
|
||||
As of now we the Gateways will be defaulted to a combination of (nowadays deprecated) `Tor Null deny list` (note: Tornull is not affiliated with Tor Project) - reproduction permitted under Creative Commons Attribution 3.0 United States License which is IP-based, e.g., `ExitPolicy reject 5.188.10.0/23:*` and `Tor reduced policy` together with changes decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy will remain the same for all the nodes, without any option to modify it by Nym node operators individually, to secure stable and reliable service for the end users.
|
||||
As of now the Gateways will be defaulted to a policy decided by Nym operators community through the governance (like in this [vote](https://forum.nymtech.net/t/poll-a-new-nym-exit-policy-for-exit-gateways-and-the-nym-mixnet-is-inbound/464)). This policy will remain the same for all the nodes, without any option to modify it by Nym node operators individually, to secure stable and reliable service for the end users.
|
||||
|
||||
For exit relays on ports 80 and 443, the Gateways will exhibit an HTML page resembling the one proposed by [Tor](https://gitlab.torproject.org/tpo/core/tor/-/raw/HEAD/contrib/operator-tools/tor-exit-notice.html). By doing so, the operator will be able to disclose details regarding their Gateway, including the currently configured exit policy, all without the need for direct correspondence with regulatory or law enforcement agencies. It also makes the behavior of Exit Gateways transparent and even computable (a possible feature would be to offer a machine readable form of the notice in JSON or YAML).
|
||||
The Exit Gateways will exhibit an HTML page (on port `80` and `443`) resembling the one proposed documented [here](landing-pages.mdx
|
||||
). By doing so, the operator will be able to disclose details regarding their Gateway, including the currently configured exit policy, all without the need for direct correspondence with regulatory or law enforcement agencies. It also makes the behavior of Exit Gateways transparent and even computable (a possible feature would be to offer a machine readable form of the notice in JSON or YAML).
|
||||
|
||||
We also recommend operators to check the technical advice from [Tor](https://community.torproject.org/relay/setup/exit/).
|
||||
|
||||
## Community Counsel & Legal environment of Nym Exit Gateway
|
||||
|
||||
The Node Operators Community Counsel pages are divided according [jurisdictions](jurisdictions.mdx). Nym Node operators are invited to add their legal findings or helpful suggestions directly through [pull requests](add-content.mdx). This can be done as a new legal information (or entire new country) to the list of [jurisdictions](jurisdictions.mdx) or in a form of an advice to [Community counsel pages](../community-counsel.mdx), like sharing examples of Exit Gateway [landing pages](landing-pages.md), templates etcetra.
|
||||
The Node Operators Community Counsel pages are divided according [jurisdictions](jurisdictions.mdx). Nym Node operators are invited to add their legal findings or helpful suggestions directly through [pull requests](add-content.mdx). This can be done as a new legal information (or entire new country) to the list of [jurisdictions](jurisdictions.mdx) or in a form of an advice to [Community counsel pages](../community-counsel.mdx), like sharing examples of Exit Gateway [landing pages](landing-pages.mdx), templates etcetra.
|
||||
|
||||
## How to add content
|
||||
|
||||
Our aim is to establish a strong community network, sharing legal findings and other suggestions with each other. We would like to encourage all of the current and future operators to do research about the situation in the jurisdiction they operate in as well as solutions to any challenges when running an Exit Gateway and add those through a pull request (PR). Please check out the [steps to make a pull request](add-content.mdx).
|
||||
|
||||
|
||||
## Tor legal advice
|
||||
|
||||
Giving the legal similarity between Nym Exit Gateways and Tor Exit Relays, it is helpful to have a look in [Tor community Exit Guidelines](https://community.torproject.org/relay/community-resources/tor-exit-guidelines/). This chapter is an exert of tor page.
|
||||
|
||||
@@ -33,6 +33,11 @@ If you want to dive deeper into Nym's architecture, clients, nodes, and SDK exam
|
||||
* [Validators](nodes/validator-setup.mdx)
|
||||
* [Nym API Setup](nodes/validator-setup/nym-api.mdx)
|
||||
|
||||
**Tokenomics, rewards and roadmap**
|
||||
* [General tokenomics page](tokenomics.mdx)
|
||||
* [Nym Node rewards page](tokenomics/mixnet-rewards.mdx)
|
||||
* [Nym operators roadmap](tokenomics/mixnet-rewards.mdx#roadmap)
|
||||
|
||||
**Maintenance, troubleshooting and FAQ**
|
||||
|
||||
* [FAQ](faq/nym-nodes-faq.mdx)
|
||||
|
||||
@@ -25,15 +25,20 @@ You are asked to `sign` a transaction and bond your node to Nyx blockchain so th
|
||||
Do not bond your node to the API if the previous steps weren't finished. Bad connectivity, closed ports, or other poor setup will result in your node getting blacklisted.
|
||||
</Callout>
|
||||
|
||||
|
||||
Any new bonded node will provide only the bare minimum information: host, identity key and optionally custom port of its HTTP API - we highly recommend to set that one up to `8080`. Everything else will be discovered via the self-described API for maximum flexibility. This also includes the sphinx key, meaning if the API is not exposed, the node will be unable to route any traffic.
|
||||
|
||||
**Every operator has to make sure that their nodes [self-described endpoint works](nodes/performance-and-testing/node-api-check#basic-api-usage), otherwise the node will be un-routable and thus won't get any rewards!**
|
||||
|
||||
## Bond via the Desktop wallet (recommended)
|
||||
|
||||
You can bond your `nym-node` via the Desktop wallet.
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Insert bonding information
|
||||
###### 1. Insert bonding information
|
||||
|
||||
- Open your wallet, and head to the `Bond` page, then select the node type `Mixnode` and input your node details. Press `Next`.
|
||||
- Open your wallet, and head to the `Bonding` page and click on `Bond` Button, and input your node details. Press `Next`.
|
||||
- To find out your `nym-node` details, run this command in your VPS:
|
||||
```sh
|
||||
./nym-node bonding-information --id <ID>
|
||||
@@ -43,9 +48,9 @@ You can bond your `nym-node` via the Desktop wallet.
|
||||
echo "$(curl -4 https://ifconfig.me)"
|
||||
```
|
||||
|
||||
###### 2. Bond to correct ports
|
||||
###### 2. Bond to correct HTTP port
|
||||
|
||||
- In your wallet: Open the box called `Show advanced options` and make sure all your ports are set correctly, like the values in this table:
|
||||
- In your wallet: Open the box called `Show advanced options` and make sure that your `Custom HTTP port` is set correctly like in your `config.toml`. **We strongly recommend to keep it on default `8080`.** For reference these are the ports used by `nym-node`:
|
||||
|
||||
| Node type | Port name | Correct port value |
|
||||
| :-- | :-- | :-- |
|
||||
@@ -55,16 +60,15 @@ echo "$(curl -4 https://ifconfig.me)"
|
||||
| Gateway (entry & exit) | Mix port | `1789` |
|
||||
| Gateway (entry & exit) | Client WS API port | `9000` |
|
||||
|
||||
- If you bonding `nym-node --mode mixnode` through *Bond mixnode* desktop wallet menu, change manually *HTTP api port* value from deprecated `8000` to `8080` - a generic `nym-node` HTTP port (for all modes).
|
||||
- Use own `ID_KEY`, and `Host`, which can be either your IPv4 address or hostname:
|
||||
|
||||
|
||||
|
||||
|
||||
###### 3. Enter your values and sign with your node
|
||||
|
||||
- Enter the `Amount`, `Operating cost` and `Profit margin` and press `Next`
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
|
||||
If you are part of [Nym Delegation Program](https://delegations.explorenym.net) or Service Grants Program, make sure your values are within the [rules](https://forum.nymtech.net/t/nym-delegations-program-update/466) of the programs. Operators setting up larger OP or PM than defined in the rules will be excluded from the program without prior warning!
|
||||
</Callout>
|
||||
|
||||
@@ -93,8 +97,56 @@ Your node will now be bonded and ready to receive traffic, latest at the beginni
|
||||
|
||||
If everything worked, you'll see your node running on the either the [Sandbox testnet network explorer](https://sandbox-explorer.nymtech.net) or the [mainnet network explorer](https://explorer.nymtech.net), depending on which environment you're running.
|
||||
|
||||
<Callout type="warning" emoji="">
|
||||
**After migration to `nym-node` in Mixnet smart contract, many explorers, includyng Nym explorers will not pick up value correctly. While we are working on Nym Explorer v2, we would like to invite operators to use [Nym Harbourmaster](https://harbourmaster.nymtech.net) to track their nodes.**
|
||||
</Callout>
|
||||
|
||||
## Change Settings via Desktop Wallet
|
||||
|
||||
In case you decide to change any settings like `custom HTTP port` or your `host` from an IP address to a hostname, don't forget to announce it to the API via changing these values in the desktop wallet.
|
||||
|
||||
- Go back to `Bonding` page, click on `Nym Node Settings` and change the values like in this example:
|
||||
|
||||
|
||||
|
||||
|
||||
## Migrate to `nym-node` in Mixnet Smart Contract
|
||||
|
||||
From `nym-wallet` version `1.2.15` onward the application allows and prompts operators to migrate their gateway or mixnode to a `nym-node` in the Mixnet smart contract - an important step in [project smoosh](../../archive/faq/smoosh-faq.mdx). To do so follow these steps:
|
||||
|
||||
<Steps>
|
||||
|
||||
###### 1. Download the latest wallet from [the release page](https://github.com/nymtech/nym/releases)
|
||||
|
||||
###### 2. Verify the binary and extract it if needed
|
||||
|
||||
- Download [`hashes.json`]https://github.com/nymtech/nym/releases/download/nym-wallet-v1.2.15/hashes.json
|
||||
- Open it with your text editor or print it's content with `cat hashes.json`
|
||||
- Run `sha256sum <WALLET_BINARY>` for example `sha256sum ./nym-wallet_1.2.15_amd64.AppImage`
|
||||
- If your have to extract it (like `.tar.gz`) do it
|
||||
|
||||
###### 3. Open the wallet and sign in
|
||||
|
||||
###### 4. Migrate!
|
||||
|
||||
- Go to Bonding and you will be prompted with such message:
|
||||
|
||||
|
||||
|
||||
- In case you for some reason didn't see the prompt or you closed it - you can click in the upper right corner of the same window on this button:
|
||||
|
||||
|
||||
|
||||
- Confirm the transaction
|
||||
|
||||
###### 5. Welcome to new episode of `nym-node`!
|
||||
|
||||
</ Steps>
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
Versions older than `nym-wallet v 1.2.15` will not allow bonding new nodes.
|
||||
</Callout>
|
||||
|
||||
## Bond via the CLI (power users)
|
||||
|
||||
If you want to bond your Mix Node via the CLI, then check out the [relevant section in the Nym CLI](https://nymtech.net/docs/tools/nym-cli.html#bond-a-mix-node) docs.
|
||||
|
||||
|
||||
@@ -14,7 +14,21 @@ This documentation page provides a guide on how to set up and run a [NYM NODE](.
|
||||
|
||||
## Current version
|
||||
|
||||
```sh
|
||||
nym-node
|
||||
Binary Name: nym-node
|
||||
Build Timestamp: 2024-11-18T17:02:50.947941194Z
|
||||
Build Version: 1.1.10
|
||||
Commit SHA: b49ef643df86f0c670672429812c632fbbaf6cf1
|
||||
Commit Date: 2024-11-18T17:56:57.000000000+01:00
|
||||
Commit Branch: HEAD
|
||||
rustc Version: 1.82.0
|
||||
rustc Channel: stable
|
||||
cargo Profile: release
|
||||
```
|
||||
{/* COMMENTING THIS OUT ASS WE HAVE TO FIGURE OUT HOW TO SHOW THE LATEST VERSION FROM MASTER BRANCH
|
||||
<BuildInfo />
|
||||
*/}
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@@ -0,0 +1,193 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { MigrateTabs } from 'components/operators/nodes/node-migrate-command-tabs';
|
||||
import NyxPercentStake from 'components/outputs/api-scraping-outputs/nyx-outputs/nyx-percent-stake.md';
|
||||
import NyxTotalStake from 'components/outputs/api-scraping-outputs/nyx-outputs/nyx-total-stake.md';
|
||||
import CirculatingSupply from 'components/outputs/api-scraping-outputs/nyx-outputs/circulating-supply.md';
|
||||
import TokenTable from 'components/outputs/api-scraping-outputs/nyx-outputs/token-table.md';
|
||||
import StakingTarget from 'components/outputs/api-scraping-outputs/nyx-outputs/staking-target.md';
|
||||
import StakingScaleFactor from 'components/outputs/api-scraping-outputs/nyx-outputs/staking-scale-factor.md';
|
||||
import StakeSaturation from 'components/outputs/api-scraping-outputs/nyx-outputs/stake-saturation.md';
|
||||
import { TimeNow } from 'components/time-now.tsx';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
|
||||
# Nym Tokenomics
|
||||
|
||||
<TimeNow />
|
||||
|
||||
Nym Network is composed of two main elements, the Mixnet represented by [Nym Nodes](nodes/nym-node/nym-node.mdx) routing and mixing the data packets, and Nyx blockchain distributted accros [validator set](tokenomics/validator-rewards.mdx), using smart contracts (based on [cosmwasm](https://cosmwasm.com/)) to monitor and reward Nym Nodes by querying API endpoints and distributing NYM token to operators according to work done by their nodes. All Nym nodes and validators are run by decentralised community of operators.
|
||||
|
||||
* Nym tokenomics are based on the research paper [*Reward Sharing for Mixnets*](https://nymtech.net/nym-cryptoecon-paper.pdf)
|
||||
* For a more comprehensive overview, token live data and supply graphs, visit [*nymtech.net/about/token*](https://nymtech.net/about/token)
|
||||
* To read about rewards calculation, visit [Nym Node rewards page](tokenomics/mixnet-rewards.mdx)
|
||||
* To understand the implementation and release plan, see [Nym operators roadmap](tokenomics/mixnet-rewards.mdx#roadmap)
|
||||
|
||||
|
||||
{/*
|
||||
**Formulas and Examples Annotation**
|
||||
|
||||
To make it easier for the reader, we use a highlighting line on the left side, with a specific color:
|
||||
|
||||
<Callout borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
|
||||
> **Turquoise with red pin for formulas.**
|
||||
</Callout>
|
||||
|
||||
<Callout borderColor="#966fd6" backgroundColor="#b19cd9" emoji="">
|
||||
<AccordionTemplate name="Example">
|
||||
> Purple collapsible for examples.
|
||||
</AccordionTemplate>
|
||||
</Callout>
|
||||
*/}
|
||||
|
||||
## NYM Token: Incentivise Stability & Secure Reputation
|
||||
|
||||
Besides the Mixnet itself, Nym Network is secured by its own blockchain Nyx (IBC on Cosmos) with a native token NYM.
|
||||
|
||||
**NYM token key features**
|
||||
|
||||
* **Incentives:** Distribute rewards to decentralised nodes based on mixing and routing (work). This dynamic ensures that the network is as robust as possible - the nodes are chosen every hour according to their performance.
|
||||
|
||||
* **Network take over defense:** Another decisive factor for a node to be chosen to the network active set is reputation. Reputation is a size of stake (delegation) where delegators earn proportional percentage of nodes rewards. Nodes without reputation are not chosen to take part in the network active set.
|
||||
|
||||
* **Centralisation defense:** Any node can only have a certain stake (called stake saturation) to earn maximum rewards, increasing stake level per node leads to decreasing rewards for the operator and all delegators. This feature makes it more difficult for whales to over-stake their nodes or to attract more delegators (stakers) as they would become dis-advantaged.
|
||||
|
||||
To learn more about rewards calculation and distribution, read the next page [*Nym Mixnet Rewards*](tokenomics/mixnet-rewards.mdx).
|
||||
|
||||
|
||||
### Utility
|
||||
|
||||
*NYM token is a first and foremost a utility to secure Nym Network.*
|
||||
|
||||
|
||||
|
||||
Nyx blockchain's validators run API to monitor the network and node performance. Based on the live input the operators and stakers of the working nodes get rewarded. The network is adjusted and re-randomized in the beginning of each epoch (60 min) composing the best performing nodes with the highest reputation.
|
||||
|
||||
This creates an incentive for people to operate Nym nodes as quality and reliable service. The reputation system also works as a network defense against a large adversary take over or sybil attacks.
|
||||
|
||||
Node reputation is calculated by delegation. Delegation is a stake done by NYM token holders on top of nodes they want to support to join the network as it compensate the stakers with APR. Therefore there is an incentive for NYM holders to stake their token on top of nodes which they believe will perform well.
|
||||
|
||||
To prevent a whale takeover and centralisation, the revenue grows alongside nodes stake size only until a certain point, after which the rewards per staker start to decrease. We call this mark *node stake saturation*.
|
||||
|
||||
Thanks to Nyx blockchain API monitoring, the flow is dynamic and constantly optimized based on live metrics. Below is a detailed explanation and reckoning of Nym tokenomics logic.
|
||||
|
||||
## Tokenomics
|
||||
|
||||
|
||||
### Summary in Numbers
|
||||
|
||||
Below is a table with token supply distribution.
|
||||
|
||||
<TokenTable />
|
||||
|
||||
To get live data, visit [Nym token page](https://nymtech.net/about/token) or see how to [query API endpoints](#query-tokenomics-api).
|
||||
|
||||
### Calculation & Explanation
|
||||
|
||||
To get a full comprehension of [node operators rewards](tokenomics/mixnet-rewards.mdx) calculation and [delegators APR height](https://nymtech.net/about/token), we need to understand some basic logic behind the numbers presented. This chapter covers some of the most essential variables in Nym tokenomics flow.
|
||||
|
||||
```ascii
|
||||
|
||||
┌───────────┐ staking ┌───────────┐ sum of ┌───────────┐
|
||||
│ │ supply │ │ nym nodes │ │
|
||||
│circulating│ scale │ staking │ in rewarded │ stake │
|
||||
│ supply │ factor │ target │ set │saturation │
|
||||
│ ├────────────►│ ├──────────────►│ │
|
||||
└───────────┘ └───────────┘ └───────────┘
|
||||
|
||||
```
|
||||
|
||||
#### Supply
|
||||
<br />
|
||||
<b>Circulating supply is <span style={{display: 'inline-block'}}><CirculatingSupply /></span> NYM.</b>
|
||||
|
||||
NYM token is capped at 1b. Visit [Nym token page](https://nymtech.net/about/token) to see live data and graphs.
|
||||
|
||||
#### Staking target
|
||||
|
||||
|
||||
A number of aimed NYM tokens to be staked in the network. The staking target a is multiplier of staking supply scale factor and circulating supply.
|
||||
|
||||
<Callout type="info" borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
> **staking_target = staking_supply_scale_factor \* circulating_supply**
|
||||
</Callout>
|
||||
|
||||
Staking supply scale factor is currently it's set to be <span style={{display: 'inline-block'}}><StakingScaleFactor /></span>.
|
||||
|
||||
The value of this variable can be changed to optimize the metrics of the network. With a current circulating supply of <span style={{display: 'inline-block'}}><CirculatingSupply /></span> NYM and staking supply scale factor <span style={{display: 'inline-block'}}><StakingScaleFactor /></span>, <b>the staking target is <span style={{display: 'inline-block'}}><StakingTarget /></span> NYM.</b>
|
||||
|
||||
#### Stake saturation
|
||||
|
||||
Node reputation in a form of self bond or stakers delegation. Stake saturation is calculated as:
|
||||
|
||||
<Callout type="info" borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
> **stake_saturation = staking_target / rewarded_set_size**
|
||||
>
|
||||
> **rewarded_set_size = active_set_size + standby_set_size**
|
||||
</Callout>
|
||||
|
||||
|
||||
With current circulating supply of <span style={{display: 'inline-block'}}><CirculatingSupply /></span> NYM, staking target of <span style={{display: 'inline-block'}}><StakingTarget /></span> NYM, divided by the sum of nodes in the [rewarded set](https://validator.nymtech.net/api/v1/epoch/reward_params), <b>the stake saturation level is <span style={{display: 'inline-block'}}><StakeSaturation /></span> NYM per node.</b>
|
||||
|
||||
|
||||
|
||||
#### Active set
|
||||
|
||||
Nym Network needs an optimised number of nodes to route and mix the packets. This healthy balance lies in between being too congested - which would detriment speed and user experience - on one side, and having too little traffic per node - which would could weaken anonymity - on the other.
|
||||
|
||||
The way how we approach this challenge is different for Mixnet (5-hop) and dVPN (2-hop) mode.
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<strong>Mixnet mode</strong>,
|
||||
<strong>dVPN mode</strong>,
|
||||
]} defaultIndex="0">
|
||||
<MyTab>
|
||||
Nym Mixnet is using an active set of chosen nodes. Currently <b>the [active set size](https://validator.nymtech.net/api/v1/epoch/reward_params) is 240 nodes</b>, 120 with Gateway functionality: 50 entry (1st layer) and 70 exit (5th layer) and 120 as Mixnode (2nd, 3rd and 4th mixing layer). The active set is chosen in the beginning of each epoch (60min). The best performing and reputated (optimal stake saturation) nodes are chosen. Performance is much more ample as you can see in the formula below:
|
||||
|
||||
<Callout type ="info" borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
> **active_set_selection_probability = ( node_performance ^ 20 ) * stake_saturation**
|
||||
</Callout>
|
||||
|
||||
</MyTab>
|
||||
<MyTab>
|
||||
In dVPN (2-hop) mode every node which meets the performance criteria, including wireguard and IPv6 routing tests, becomes eligible to take part in the network. Whether the node is working on not then depends on the end users choise of the location or exact nodes selection.
|
||||
</MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
In both cases, the selection algorithm also looks whether the node runs with [Terms & Conditions](nodes/nym-node/setup.mdx#terms--conditions) accepted **AND** if it's not a legacy binary version. In case either of these criterias are not met, the node will have be excluded from the rewarded set selection.
|
||||
|
||||
To read more about rewards calculation, please see next page [*Nym Operators Rewards*](mixnet-rewards.md).
|
||||
|
||||
## Query Validator API
|
||||
|
||||
We have available API endpoints which can be accessed via [Swagger UI page](https://validator.nymtech.net/api/swagger/index.html). Or by querying the endpoints directly:
|
||||
|
||||
```sh
|
||||
curl -X 'GET' \
|
||||
'https://validator.nymtech.net/api/v1/circulating-supply' \
|
||||
-H 'accept: application/json'sh
|
||||
|
||||
curl -X 'GET' \
|
||||
'https://validator.nymtech.net/api/v1/circulating-supply/total-supply-value' \
|
||||
-H 'accept: application/json'sh
|
||||
|
||||
|
||||
curl -X 'GET' \
|
||||
'https://validator.nymtech.net/api/v1/circulating-supply-value' \
|
||||
-H 'accept: application/json'sh
|
||||
|
||||
curl -X 'GET' \
|
||||
'https://validator.nymtech.net/api/v1/epoch/reward_params' \
|
||||
-H 'accept: application/json'sh
|
||||
```
|
||||
|
||||
> The unit of value is measured in `uNYM`.
|
||||
|
||||
<Callout type="info" borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
> **1 NYM = 1_000_000 uNYM**
|
||||
</Callout>
|
||||
@@ -1,6 +1,3 @@
|
||||
{
|
||||
"validator-rewards": "Nyx Validator Rewards",
|
||||
"mixnet-rewards": {
|
||||
"display": "hidden"
|
||||
}
|
||||
{ "mixnet-rewards": "Nym Mixnet Rewards",
|
||||
"validator-rewards": "Nyx Validator Rewards"
|
||||
}
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
<!-- THIS PAGE IS ALL COMMENTED FROM SUMMARY - NO NEED TO REVIEW YET!!! -->
|
||||
|
||||
<!-- DROPPING THIS FROM THE MAINTENANCE -->
|
||||
|
||||
### Mix Node Reward Estimation API endpoint
|
||||
|
||||
The Reward Estimation API endpoint allows Mix Node operators to estimate the rewards they could earn for running a Nym Mix Node with a specific `MIX_ID`.
|
||||
|
||||
> The `<MIX_ID>` can be found in the "Mix ID" column of the [Network Explorer](https://explorer.nymtech.net/network-components/mixnodes/active).
|
||||
|
||||
The endpoint is a particularly common for Mix Node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the Mix Node, the quality of the Mix Node's performance, and the overall demand for Mix Nodes in the network. This information can be useful for Mix Node operators in deciding whether or not to run a Mix Node and in optimizing its operations for maximum profitability.
|
||||
|
||||
Using this API endpoint returns information about the Reward Estimation:
|
||||
|
||||
```sh
|
||||
/status/mixnode/<MIX_ID>/reward-estimation
|
||||
```
|
||||
|
||||
Query Response:
|
||||
|
||||
```sh
|
||||
"estimation": {
|
||||
"total_node_reward": "942035.916721770541325331",
|
||||
"operator": "161666.263307386408152071",
|
||||
"delegates": "780369.65341438413317326",
|
||||
"operating_cost": "54444.444444444444444443"
|
||||
},
|
||||
```
|
||||
|
||||
> The unit of value is measured in `uNYM`.
|
||||
|
||||
- `estimated_total_node_reward` - An estimate of the total amount of rewards that a particular Mix Node can expect to receive during the current epoch. This value is calculated by the Nym Validator based on a number of factors, including the current state of the network, the number of Mix Nodes currently active in the network, and the amount of network traffic being processed by the Mix Node.
|
||||
|
||||
- `estimated_operator_reward` - An estimate of the amount of rewards that a particular Mix Node operator can expect to receive. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the operator's stake in the network.
|
||||
|
||||
- `estimated_delegators_reward` - An estimate of the amount of rewards that Mix Node delegators can expect to receive individually. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the delegator's stake in the network.
|
||||
|
||||
- `estimated_node_profit` - An estimate of the profit that a particular Mix node operator can expect to earn. This value is calculated by subtracting the Mix Node operator's `operating_costs` from their `estimated_operator_reward` for the current epoch.
|
||||
|
||||
- `estimated_operator_cost` - An estimate of the total cost that a particular Mix Node operator can expect to incur for their participation. This value is calculated by the Nym Validator based on a number of factors, including the cost of running a Mix Node, such as server hosting fees, and other expenses associated with operating the Mix Node.
|
||||
|
||||
### Validator: Installing and configuring nginx for HTTPS
|
||||
#### Setup
|
||||
[Nginx](https://www.nginx.com/resources/glossary/nginx) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security.
|
||||
|
||||
Install `nginx` and allow the 'Nginx Full' rule in your firewall:
|
||||
@@ -0,0 +1,332 @@
|
||||
import { Callout } from 'nextra/components';
|
||||
import { Tabs } from 'nextra/components';
|
||||
import { MyTab } from 'components/generic-tabs.tsx';
|
||||
import { RunTabs } from 'components/operators/nodes/node-run-command-tabs';
|
||||
import { VarInfo } from 'components/variable-info.tsx';
|
||||
import { MigrateTabs } from 'components/operators/nodes/node-migrate-command-tabs';
|
||||
import NyxPercentStake from 'components/outputs/nyx-outputs/nyx-percent-stake.md';
|
||||
import NyxTotalStake from 'components/outputs/nyx-outputs/nyx-total-stake.md';
|
||||
import { TimeNow } from 'components/time-now.tsx';
|
||||
import { AccordionTemplate } from 'components/accordion-template.tsx';
|
||||
import { Clt } from 'components/callout-custom/CalloutCustom.jsx';
|
||||
|
||||
# Nym Operators Rewards
|
||||
|
||||
<TimeNow />
|
||||
|
||||
* Nym tokenomics are based on the research paper [*Reward Sharing for Mixnets*](https://nymtech.net/nym-cryptoecon-paper.pdf)
|
||||
* For a more comprehensive overview, live data and supply graphs, visit [*nymtech.net/about/token*](https://nymtech.net/about/token)
|
||||
|
||||
We are working on the final architecture of [*Fair Mixnet*](#fair-mixnet) tokenomics implementation and its detailed documentation. **The current design is called [*Naive rewarding*](#naive-rewarding).** It is an intermediate step, allowing operators to migrate to `nym-node` in Mixnet smart contract and for the first time recieve delegations and earn rewards for any `nym-node` functionality, in opposite to the past system, where only Mixnodes were able to recieve delegations and rewards.
|
||||
|
||||
**Please read the [roadmap section below](#roadmap) to see the planned development.**
|
||||
|
||||
{/*
|
||||
|
||||
**Formulas and Examples Annotation**
|
||||
|
||||
To make it easier for the reader, we use a highlighting line on the left side, with a specific color:
|
||||
|
||||
<Clt borderColor='#008080' backgroundColor='#20b2aa' pointPosition='right' pointOffset='3rem' pointAlignment='center'>
|
||||
> **Turquoise with red pin for formulas.**
|
||||
</Clt>
|
||||
|
||||
<Callout borderColor="#966fd6" backgroundColor="#b19cd9" emoji="">
|
||||
<AccordionTemplate name="Example">
|
||||
> Purple collapsible for examples.
|
||||
</AccordionTemplate>
|
||||
</Callout>
|
||||
*/}
|
||||
|
||||
<Callout type="info" emoji="ℹ️">
|
||||
Nodes bonded with vesting tokens are [not allowed to join rewarded set](https://github.com/nymtech/nym/pull/5129) - read more on [Nym operators forum](https://forum.nymtech.net/t/vesting-accounts-are-no-longer-supported/827).
|
||||
</Callout>
|
||||
|
||||
## Overview
|
||||
|
||||
This is a quick summary, to understand the full picture, please see detailed [*Rewards Logic & Calculation*](#rewards-logic--calculation) chapter below.
|
||||
|
||||
* The operators of `nym-node` get rewarded from Mixmining pool, which emits around 6000 NYM per hour.
|
||||
* A [rewarded set](../tokenomics.mdx#active-set) of `nym-nodes` selected for Nym network routing and mixing can be is currently 240 nodes in total and it's selected for each new epoch (60 min). The number can be adjusted - look here for the current value: [validator.nymtech.net/api/v1/epoch/reward_params](https://validator.nymtech.net/api/v1/epoch/reward_params)
|
||||
* `nym-nodes` can run in mode `entry-gateway`, `exit-gateway` and `mixnode`, which are positioned into layers
|
||||
* NymVPN users can chose to route through Nym Network in two ways:
|
||||
- Mixnet: 5 layers routing and mixing - full privacy
|
||||
- Wireguard: 2 layers routing, skipping 3 mixing layers - fast mode
|
||||
* **The current reward system is *Native rewarding* - an intermediate step - where each layer get's rewarded the same**
|
||||
* In the final model, nodes will get rewarded based on their layer position and the work they do (collected user tickets), where and the reward distribution per layer will be according to a [decision made by the operators](https://forum.nymtech.net/t/poll-what-should-be-the-split-of-mixmining-rewards-among-the-layers-of-the-nym-mixnet/407) as follows:
|
||||
- 5-hop: 16%-16%-16%-16%-36%
|
||||
- 2-hop: 33%-67%
|
||||
* Currently Gateways earn rewards only from taking a part in the rewarded set. The operators can sign up to a grant program as a substitution for 2-hop routing.
|
||||
* To read more about the final design and future implementation, see [*Roadmap*](#roadmap) chapter for more details.
|
||||
|
||||
## Rewards Logic & Calculation
|
||||
|
||||
**Note that in the current intermediate model we use one active set to reward all nodes and they are asign same (naive) work factor of 1 / 240, whether they work as Mixnode or Gateway of any kind, in both 2-hop and 5-hop mode. In reality it means that all nodes are rewarded within 5-hop reward scheme only.**
|
||||
|
||||
**However NymVPN client can chose any `nym-node --mode entry-gateway` and `--mode exit-gateway` in the network to route through the mixnet and as well as any of those which passed [wireguard probing test](https://harbourmaster.nymtech.net) to route as dVPN nodes.**
|
||||
|
||||
### Nym Network rewarded set distribution
|
||||
|
||||
<div>
|
||||
<Tabs items={[
|
||||
<strong>Mixnet mode (5-hop)</strong>,
|
||||
<strong>dVPN mode (2-hop)</strong>,
|
||||
]} defaultIndex="0">
|
||||
<MyTab>
|
||||
|
||||
```ascii
|
||||
|
||||
Network
|
||||
layer: 1. 2. 3. 4. 5.
|
||||
|
||||
--------
|
||||
┌► mixnode ─┐ mixnode mixnode
|
||||
│ │
|
||||
Node entry │ │ exit
|
||||
type: gateway ──┘ mixnode │ mixnode ┌─► mixnode ───► gateway
|
||||
│ │
|
||||
│ │
|
||||
mixnode └─► mixnode ─┘ mixnode
|
||||
|
||||
```
|
||||
|
||||
| **Network layer** | **1** | **2** | **3** | **4** | **5** |
|
||||
| :-- | :---: | :---: | :---: | :---: | :---: |
|
||||
| Node functionality in layer | Entry Gateway | Mixnode | Mixnode | Mixnode | Exit Gateway |
|
||||
| Nodes in [active set](tokenomics.mdx#active-set) | 50 | 40 | 40 | 40 | 70 |
|
||||
| Naive rewarding: Rewards distribution per node | 1 / 240 | 1 / 240 | 1 / 240 | 1 / 240 | 1 / 240 |
|
||||
| Final model: Rewards distribution per node | 0.16 / 240 | 0.16 / 240 | 0.16 / 240 | 0.16 / 240 | 0.36 / 240 |
|
||||
|
||||
</MyTab>
|
||||
<MyTab>
|
||||
|
||||
|
||||
```ascii
|
||||
|
||||
Network
|
||||
layer: 1. 2.
|
||||
|
||||
--------
|
||||
|
||||
Node entry exit
|
||||
type: gateway ──────────────────────────────────────────► gateway
|
||||
|
||||
```
|
||||
|
||||
| **Network layer** | **1** | **2** |
|
||||
| :-- | :---: | :---: |
|
||||
| Node functionality in layer | Entry Gateway | Exit Gateway |
|
||||
| Naive rewarding: Nodes in [active set](tokenomics.mdx#active-set) | 50 | 70 |
|
||||
| Naive rewarding: Rewards distribution per node | 1 / 240 | 1 / 240 | 1 / 240 | 1 / 240 | 1 / 240 |
|
||||
| Final model: Active nodes | All following criteria for eligibility | All following criteria for eligibility |
|
||||
| Final model: Rewards distribution per node | 0.33 \* collected_user_tickets | 0.67 \* collected_user_tickets |
|
||||
|
||||
</MyTab>
|
||||
</Tabs>
|
||||
</div>
|
||||
|
||||
|
||||
### Active Set Selection
|
||||
|
||||
*Performance matters!*
|
||||
|
||||
For a node to be rewarded, the node must be part of a [Rewarded set](https://validator.nymtech.net/api/v1/epoch/reward_params) (which currently = active set) in the first place. The active set is selected in the beginning of each epoch (every 60min) where total of 240 Nym nodes - represented by 120 mixnodes and 120 gateways, are randomly allocated across the layers.
|
||||
|
||||
The algorithm choosing nodes into the active set takes into account node's performance and [stake saturation](../tolkenomics.mdx#stake-saturation), both values being between 0 and 1 and config score which is either 0 or 1.
|
||||
|
||||
**Config score is introduced:** The nodes selection to the active set has a new parameter - `config_score`. Config score currently looks if the node binary is `nym-node` (not legacy `nym-mixnode` or `nym-gateway`) **AND** if [Terms & Conditions](nodes/nym-node/setup.mdx#terms--conditions) are accepted. Config score has binary values of either 0 or 1, with a following logic:
|
||||
|
||||
| **Run `nym-node` binary** | **T&C's accepted** | **`config_score`** |
|
||||
| :-- | :-- | ---: |
|
||||
| True | False | 0 |
|
||||
| False | True | 0 |
|
||||
| False | False | 0 |
|
||||
| True | True | 1 |
|
||||
|
||||
|
||||
The entire active set selection probablity:
|
||||
|
||||
<Callout type="info" emoji="📌">
|
||||
> **active_set_selection_probability = config_score \* stake_saturation \* node_performance ^ 20**
|
||||
</Callout>
|
||||
|
||||
For a comparison we made an example with 5 nodes, where first number is node performance and second stake saturation (assuming all of them `config_score` = 1 and not 0):
|
||||
|
||||
<br />
|
||||
<AccordionTemplate name="✏️ Example: Reward set selection">
|
||||
> node_1 = 1.00 ^ 20 \* 1.0 = 1 <br />
|
||||
> node_2 = 1.00 ^ 20 \* 0.5 = 0.5 <br />
|
||||
> node_3 = 0.99 ^ 20 \* 1.0 = 0.818 <br />
|
||||
> node_4 = 0.95 ^ 20 \* 1.0 = 0.358 <br />
|
||||
> node_5 = 0.90 ^ 20 \* 1.0 = 0.122 <br />
|
||||
</AccordionTemplate>
|
||||
|
||||
As you can see the performance (also known as *Routing score*) is much more important during the active set selection. A node with 100% performance but only 50% stake saturation has much bigger chance to be chosen than a node with 95% performance but full stake saturation and incomparably bigger chance than 90% performing node with 100% stake saturation.
|
||||
|
||||
|
||||
### Layer Distribution
|
||||
|
||||
Once the rewarded set (currently 120 Mixnodes and 120 Gateways) is selected, the nodes can start to route and mix packets in the Nym Network. Each hour a total of 6000 NYM is distributed between the layers from Mixmining pool. Currently in our *Naive rewarding* intermediate design, all layers get a same portion, therefore each node is *naively* assigned same working factor and therefore earns 1/240 of the rewards per epoch.
|
||||
|
||||
We are working on the final design with the ratio implementing a [decision made by the operators](https://forum.nymtech.net/t/poll-what-should-be-the-split-of-mixmining-rewards-among-the-layers-of-the-nym-mixnet/407) as follows:
|
||||
|
||||
<Callout type="info" borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
>5-hop mixnet mode: <br />
|
||||
> 16%; 16%; 16%; 16%; 36% <br/>
|
||||
> <br/>
|
||||
> 2-hop dVPN mode: <br />
|
||||
> 33%; 67%
|
||||
</Callout>
|
||||
|
||||
{/*
|
||||
In real numbers: If hourly revenue to all 240 nodes is 6000 NYM, the layer compartmentalisation is 960 NYM for Entry Gateway layer and each Mixnode layer and 2160 NYM for Exit Gateway layer. The calculation is in the example below:
|
||||
|
||||
<Callout borderColor="#966fd6" backgroundColor="#b19cd9" emoji="">
|
||||
<AccordionTemplate name="Example">
|
||||
> Purple collapsible for examples.
|
||||
5-hop mixnet mode:
|
||||
$0.16 * 6000 = 960; 0.16 * 6000 = 960; 0.16 * 6000 = 960; 0.16 * 6000 = 960; 0.36 * 6000 2160$
|
||||
2-hop wireguard mode:
|
||||
$33\% - 67\%$
|
||||
</AccordionTemplate>
|
||||
</Callout>
|
||||
|
||||
### Node Rewards within Same Layer
|
||||
|
||||
|
||||
### Operation Cost, Profit Margin & Delegation
|
||||
|
||||
### APR Calculation
|
||||
*/}
|
||||
|
||||
## Roadmap
|
||||
|
||||
We are working on the final architecture of [*Fair Mixnet*](#fair-mixnet) tokenomics implementation. The current design is called [*Naive rewarding*](#naive-rewarding). This is an intermediate step, allowing operators to migrate to `nym-node` in Mixnet smart contract and for the first time recieve delegations and earn rewards for any `nym-node` functionality, in opposite to the past system, where only Mixnodes were able to recieve delegations and rewards.
|
||||
|
||||
On November 5th, we presented a release roadmap in live [Operators Townhall](https://www.youtube.com/watch?v=3G1pJqvO2VM) where we explained in detail the steps of Nym node and tokenomics development and the effect it will have on node operators and put it into a rough timeline.
|
||||
|
||||
|
||||
|
||||
### Naive Rewarding
|
||||
|
||||
***Naive rewarding* is the current tokenomics design.** The table below lists features and logic of this design.
|
||||
|
||||
|
||||
|
||||
### Fair Mixnet
|
||||
|
||||
***Fair Mixnet* is the final architecture model that we work towards.** The table below lists features and logic of the design once implemented.
|
||||
|
||||
|
||||
|
||||
|
||||
{/*
|
||||
## Stats
|
||||
|
||||
NYM token is capped at 1b. Below is a table with actual\* token supply distribution.
|
||||
|
||||
mdrun cd ../../../scripts/cdmrun && ./api_targets.py s --api mainnet --endpoint circulating-supply --format
|
||||
|
||||
|
||||
ADD MIXNET STATS GRAPHS
|
||||
|
||||
|
||||
DROPPING THIS FROM THE MAINTENANCE PAGE - NEEDS REWORK
|
||||
|
||||
## Mix Node Reward Estimation API endpoint
|
||||
|
||||
THIS NEEDS REDO
|
||||
|
||||
The Reward Estimation API endpoint allows Mix Node operators to estimate the rewards they could earn for running a Nym Mix Node with a specific `MIX_ID`.
|
||||
|
||||
> The `<MIX_ID>` can be found in the "Mix ID" column of the [Harbourmaster](https://harbourmaster/nymtech.net).
|
||||
|
||||
The endpoint is a particularly common for Mix Node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the Mix Node, the quality of the Mix Node's performance, and the overall demand for Mix Nodes in the network. This information can be useful for Mix Node operators in deciding whether or not to run a Mix Node and in optimizing its operations for maximum profitability.
|
||||
|
||||
|
||||
|
||||
We have available API endpoints which can be accessed via [Swagger UI page](https://validator.nymtech.net/api/swagger/index.html). Or by querying the endpoints directly:
|
||||
|
||||
```sh
|
||||
curl -X 'GET' \
|
||||
'https://validator.nymtech.net/api/v1/status/mixnode/<MIX_ID>/reward-estimation' \
|
||||
-H 'accept: application/json'sh
|
||||
```
|
||||
|
||||
Query response will look like this:
|
||||
|
||||
```sh
|
||||
"estimation": {
|
||||
"total_node_reward": "942035.916721770541325331",
|
||||
"operator": "161666.263307386408152071",
|
||||
"delegates": "780369.65341438413317326",
|
||||
"operating_cost": "54444.444444444444444443"
|
||||
},
|
||||
```
|
||||
|
||||
> The unit of value is measured in `uNYM`.
|
||||
|
||||
<Callout borderColor="#008080" backgroundColor="#20b2aa" emoji="📌">
|
||||
$1 \ NYM = 1 \_ 000 \_ 000 \ uNYM$
|
||||
</Callout>
|
||||
|
||||
- `estimated_total_node_reward` - An estimate of the total amount of rewards that a particular Mix Node can expect to receive during the current epoch. This value is calculated by the Nym Validator based on a number of factors, including the current state of the network, the number of Mix Nodes currently active in the network, and the amount of network traffic being processed by the Mix Node.
|
||||
|
||||
- `estimated_operator_reward` - An estimate of the amount of rewards that a particular Mix Node operator can expect to receive. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the operator's stake in the network.
|
||||
|
||||
- `estimated_delegators_reward` - An estimate of the amount of rewards that Mix Node delegators can expect to receive individually. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the delegator's stake in the network.
|
||||
|
||||
- `estimated_node_profit` - An estimate of the profit that a particular Mix node operator can expect to earn. This value is calculated by subtracting the Mix Node operator's `operating_costs` from their `estimated_operator_reward` for the current epoch.
|
||||
|
||||
- `estimated_operator_cost` - An estimate of the total cost that a particular Mix Node operator can expect to incur for their participation. This value is calculated by the Nym Validator based on a number of factors, including the cost of running a Mix Node, such as server hosting fees, and other expenses associated with operating the Mix Node.
|
||||
*/}
|
||||
|
||||
|
||||
|
||||
{/*
|
||||
?DROPPING THIS FROM THE OLD MAINTENANCE PAGE
|
||||
|
||||
### Mix Node Reward Estimation API endpoint
|
||||
|
||||
The Reward Estimation API endpoint allows Mix Node operators to estimate the rewards they could earn for running a Nym Mix Node with a specific `MIX_ID`.
|
||||
|
||||
> The `<MIX_ID>` can be found in the "Mix ID" column of the [Network Explorer](https://explorer.nymtech.net/network-components/mixnodes/active).
|
||||
|
||||
The endpoint is a particularly common for Mix Node operators as it can provide an estimate of potential earnings based on factors such as the amount of traffic routed through the Mix Node, the quality of the Mix Node's performance, and the overall demand for Mix Nodes in the network. This information can be useful for Mix Node operators in deciding whether or not to run a Mix Node and in optimizing its operations for maximum profitability.
|
||||
|
||||
Using this API endpoint returns information about the Reward Estimation:
|
||||
|
||||
```sh
|
||||
/status/mixnode/<MIX_ID>/reward-estimation
|
||||
```
|
||||
|
||||
Query Response:
|
||||
|
||||
```sh
|
||||
"estimation": {
|
||||
"total_node_reward": "942035.916721770541325331",
|
||||
"operator": "161666.263307386408152071",
|
||||
"delegates": "780369.65341438413317326",
|
||||
"operating_cost": "54444.444444444444444443"
|
||||
},
|
||||
```
|
||||
|
||||
> The unit of value is measured in `uNYM`.
|
||||
|
||||
- `estimated_total_node_reward` - An estimate of the total amount of rewards that a particular Mix Node can expect to receive during the current epoch. This value is calculated by the Nym Validator based on a number of factors, including the current state of the network, the number of Mix Nodes currently active in the network, and the amount of network traffic being processed by the Mix Node.
|
||||
|
||||
- `estimated_operator_reward` - An estimate of the amount of rewards that a particular Mix Node operator can expect to receive. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the operator's stake in the network.
|
||||
|
||||
- `estimated_delegators_reward` - An estimate of the amount of rewards that Mix Node delegators can expect to receive individually. This value is calculated by the Nym Validator based on a number of factors, including the amount of traffic being processed by the Mix Node, the quality of service provided by the Mix Node, and the delegator's stake in the network.
|
||||
|
||||
- `estimated_node_profit` - An estimate of the profit that a particular Mix node operator can expect to earn. This value is calculated by subtracting the Mix Node operator's `operating_costs` from their `estimated_operator_reward` for the current epoch.
|
||||
|
||||
- `estimated_operator_cost` - An estimate of the total cost that a particular Mix Node operator can expect to incur for their participation. This value is calculated by the Nym Validator based on a number of factors, including the cost of running a Mix Node, such as server hosting fees, and other expenses associated with operating the Mix Node.
|
||||
|
||||
### Validator: Installing and configuring nginx for HTTPS
|
||||
#### Setup
|
||||
[Nginx](https://www.nginx.com/resources/glossary/nginx) is an open source software used for operating high-performance web servers. It allows us to set up reverse proxying on our validator server to improve performance and security.
|
||||
|
||||
Install `nginx` and allow the 'Nginx Full' rule in your firewall:
|
||||
|
||||
*/}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 396 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 260 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 479 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 357 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Regular → Executable
@@ -7,28 +7,46 @@ set -o pipefail
|
||||
cd ../scripts &&
|
||||
python csv2md.py -s 1 ../docs/data/csv/variables.csv > ../docs/components/outputs/csv2md-outputs/variables.md &&
|
||||
python csv2md.py -s 0 ../docs/data/csv/isp-sheet.csv > ../docs/components/outputs/csv2md-outputs/isp-sheet.md &&
|
||||
|
||||
cd cmdrun &&
|
||||
./nyx-percent-stake.sh > ../../docs/components/outputs/nyx-outputs/nyx-percent-stake.md &&
|
||||
./nyx-total-stake.sh > ../../docs/components/outputs/nyx-outputs/nyx-total-stake.md &&
|
||||
./nyx-percent-stake.sh > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/nyx-percent-stake.md &&
|
||||
./nyx-total-stake.sh > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/nyx-total-stake.md &&
|
||||
|
||||
cd ../api-scraping &&
|
||||
python api_targets.py v --api mainnet --endpoint circulating-supply --value circulating_supply amount --separator _ > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/circulating-supply.md &&
|
||||
|
||||
python api_targets.py v --api mainnet --endpoint circulating-supply --format markdown --separator _ > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/token-table.md &&
|
||||
|
||||
python api_targets.py v --api mainnet --endpoint epoch/reward_params --value interval staking_supply_scale_factor --format percent > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/staking-scale-factor.md &&
|
||||
|
||||
python api_targets.py v --api mainnet --endpoint epoch/reward_params --value interval stake_saturation_point --separator _ > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/stake-saturation.md &&
|
||||
|
||||
python api_targets.py time_now > ../../docs/components/outputs/api-scraping-outputs/time-now.md &&
|
||||
|
||||
python api_targets.py c --staking_target --separator _ > ../../docs/components/outputs/api-scraping-outputs/nyx-outputs/staking-target.md &&
|
||||
|
||||
cd ../../../scripts &&
|
||||
echo '```python' > ../documentation/docs/components/outputs/command-outputs/node-api-check-query-help.md &&
|
||||
python node_api_check.py query_stats --help >> ../documentation/docs/components/outputs/command-outputs/node-api-check-query-help.md &&
|
||||
echo '```' >> ../documentation/docs/components/outputs/command-outputs/node-api-check-query-help.md &&
|
||||
|
||||
echo '```python' > ../documentation/docs/components/outputs/command-outputs/node-api-check-help.md &&
|
||||
python node_api_check.py --help >> ../documentation/docs/components/outputs/command-outputs/node-api-check-help.md &&
|
||||
echo '```' >> ../documentation/docs/components/outputs/command-outputs/node-api-check-help.md &&
|
||||
|
||||
cd ../target/release/ &&
|
||||
echo '```sh' > ../../documentation/docs/components/outputs/command-outputs/nym-node-help.md &&
|
||||
./nym-node --help >> ../../documentation/docs/components/outputs/command-outputs/nym-node-help.md &&
|
||||
echo '```' >> ../../documentation/docs/components/outputs/command-outputs/nym-node-help.md &&
|
||||
|
||||
echo '```sh' > ../../documentation/docs/components/outputs/command-outputs/nym-node-run-help.md &&
|
||||
./nym-node run --help >> ../../documentation/docs/components/outputs/command-outputs/nym-node-run-help.md &&
|
||||
echo '```' >> ../../documentation/docs/components/outputs/command-outputs/nym-node-run-help.md &&
|
||||
|
||||
echo '```sh' > ../../documentation/docs/components/outputs/command-outputs/nymvisor-help.md &&
|
||||
./nymvisor --help >> ../../documentation/docs/components/outputs/command-outputs/nymvisor-help.md &&
|
||||
echo '```' >> ../../documentation/docs/components/outputs/command-outputs/nymvisor-help.md &&
|
||||
|
||||
echo '```sh' > ../../documentation/docs/components/outputs/command-outputs/nym-api-help.md &&
|
||||
./nym-api --help >> ../../documentation/docs/components/outputs/command-outputs/nym-api-help.md &&
|
||||
echo '```' >> ../../documentation/docs/components/outputs/command-outputs/nym-api-help.md &&
|
||||
|
||||
Reference in New Issue
Block a user