Master (#3888)
* removed old wallet address flag again * Add updates to community list projects * Update cd-docs.yml * Update cd-docs.yml * [hotfix]: don't assign invalid fields when crossing the JS boundary (#3805) * [hotfix]: don't assign invalid fields when crossing the JS boundary * eslint * changelog update and version bump * changed last vers. checkout to master * corrected path of config * make binaries executable * docs: typescript.md - changing variables * docs: rust.md - changing variables * docs: vesting-contract.md - changing variables * docs: mixnet-contract.md - changing variables * docs: all variables changed * operators: all variables finished * dev-portal: mixnet-integration.md - variable changed * dev-portal: faq.md - variable changed * dev-portal: moredo.md up to date w NC default * dev-portal: telegram.md - added banner & minor fix * dev-portal: matrix.md - added banner * PR finished - ready for review and merge * removed all instances of platform_release_version var * removed all instances of platform_release_version var * changed version bumper script: removed platform_release_version references * changed comment * updating changelog and bumping versions * Docs: new post-processing for books so that assets stay relative This commit has the same content as https://github.com/nymtech/nym/pull/3842 * Docs: add prod deploy settings * fixed ChangeMixCostParams event deserialization (#3873) * Merge pull request #3892 from nymtech/feature/operators/smoosh-faq Create smoosh FAQ section & re-organize operators/faq accordingly * corrected faq dir path * added integrations-faq page --------- Co-authored-by: mfahampshire <maxhampshire@pm.me> Co-authored-by: Lorexia <alexia.lorenza.martinel@protonmail.com> Co-authored-by: Tommy Verrall <tommy@nymtech.net> Co-authored-by: Tommy Verrall <60836166+tommyv1987@users.noreply.github.com> Co-authored-by: Mark Sinclair <14054343+mmsinclair@users.noreply.github.com> Co-authored-by: Jędrzej Stuczyński <jedrzej.stuczynski@gmail.com> Co-authored-by: serinko <97586125+serinko@users.noreply.github.com> Co-authored-by: mx <33262279+mfahampshire@users.noreply.github.com> Co-authored-by: Mark Sinclair <mmsinclair@users.noreply.github.com> Co-authored-by: Tommy Verrall <tommyvez@protonmail.com>
This commit is contained in:
benedetta davico
@@ -199,3 +199,4 @@ No, although we do recommend that apps that wish to integrate look into running
|
||||
|
||||
### How can I find out if an application is already supported by network requester services?
|
||||
You can check the [default allowed list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) file to see which application traffic is whitelisted by default. If the domain is present on that list, it means that existing [network requesters](https://nymtech.net/docs/nodes/network-requester.html) can be used to privacy-protect your application traffic. Simply use [NymConnect](../quickstart/nymconnect-gui.md) to connect to this service through the mixnet.
|
||||
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
## Mixnet nodes
|
||||
|
||||
### What determines the rewards when running a mix node?
|
||||
|
||||
The stake required for a mix node to achieve maximum rewards is called mix node saturation point. This is calculated from the staking supply (all circulating supply + part of unlocked tokens). The target level of staking is to have 50% of the staking supply locked in mix nodes.
|
||||
|
||||
The node stake saturation point, which we denote by Nsat, is given by the stake supply, target level of staking divided by the number of rewarded (active) nodes.
|
||||
|
||||
This design ensures the nodes aim to have a same size of stake (reputation) which can be done by delegation staking, as well as it ensures that there is a decentralization of staking as any higher level of staked tokens per node results in worse rewards. On the contrary, the more mix nodes are active, the lower is Nsat. The equilibrium is reached when the staked tokens are delegated equally across the active mix-nodes and that's our basis for this incentive system.
|
||||
|
||||
For more detailed calculation, read our blog post [Nym Token Economics update](https://blog.nymtech.net/nym-token-economics-update-fedff0ed5267). More info on staking can be found [here](https://blog.nymtech.net/staking-in-nym-introducing-mainnet-mixmining-f9bb1cbc7c36). And [here](https://blog.nymtech.net/want-to-stake-in-nym-here-is-how-to-choose-a-mix-node-to-delegate-nym-to-c3b862add165) is more info on how to choose a mix node for delegation. And finally an [update](https://blog.nymtech.net/quarterly-token-economic-parameter-update-b2862948710f) on token economics from July 2023.
|
||||
|
||||
### Which VPS providers would you recommend?
|
||||
|
||||
Consider in which jurisdiction you reside and where do you want to run a mix node. Do you want to pay by crypto or not and what are the other important particularities for your case? We always recommend operators to try to chose smaller and decentralized VPS providers over the most known ones controlling a majority of the internet. We receive some good feedback on these: Hertzner, DigitalOcean, Linode, Ghandi and Exoscale. Do your own research and share with the community.
|
||||
|
||||
<!---### Why is a mix node setup on a self-hosted machine so tricky?--->
|
||||
|
||||
### What's the Sphinx packet size?
|
||||
|
||||
The sizes are shown in the configs [here](https://github.com/nymtech/nym/blob/1ba6444e722e7757f1175a296bed6e31e25b8db8/common/nymsphinx/params/src/packet_sizes.rs#L12) (default is the one clients use, the others are for research purposes, not to be used in production as this would fragment the anonymity set). More info can be found [here](https://github.com/nymtech/nym/blob/4844ac953a12b29fa27688609ec193f1d560c996/common/nymsphinx/anonymous-replies/src/reply_surb.rs#L80).
|
||||
|
||||
### Why a mix node and a gateway cannot be bond to the same wallet?
|
||||
|
||||
Becauase of the way the smart contract works we keep it one-node one-address at the moment.
|
||||
|
||||
### Which nodes are the most needed to be setup to strengthen Nym infrastructure and which ones bring rewards?
|
||||
|
||||
Right now only mix nodes are rewarded. We're working on gateway and service payments. Gateways are the weak link right now due mostly to lack of incentivisation. Services like Network Requesters are obviously the most necessary for people to start using the platform, and we're working on smart contracts to allow for people to start advertising them the same way they do mix nodes.
|
||||
|
||||
### Are mixnodes whitelisted?
|
||||
|
||||
Nope, anyone can run a mix node. Purely reliant on the node's reputation (self stake + delegations) & routing score.
|
||||
|
||||
## Validators and tokens
|
||||
|
||||
### What's the difference between NYM and uNYM?
|
||||
|
||||
1 NYM = 1 000 000 uNYM
|
||||
|
||||
<!--- Commenting for now as NYX is not publicly out yet
|
||||
### What's the difference between NYM and NYX?
|
||||
--->
|
||||
|
||||
### Can I run a validator?
|
||||
|
||||
We are currently working towards building up a closed set of reputable validators. You can ask us for coins to get in, but please don't be offended if we say no - validators are part of our system's core security and we are starting out with people we already know or who have a solid reputation.
|
||||
|
||||
### Why is validator set entry whitelisted?
|
||||
|
||||
We understand that the early days of the Nyx blockchain will face possible vulnerabilities in terms of size - easy to disrupt or halt the chain if a malicious party entered with a large portion of stake. Besides that, there are some legal issues we need to address before we can distribute the validator set in a fully permissions fashion.
|
||||
|
||||
### Why does Nym do many airdrops?
|
||||
|
||||
It is part of ensuring decentralisation - we need to avoid a handful of people having too much control over the token and market. Of course ideally people will stake the tokens and contribute to the project at this stage. We run surveys to better understand what people are doing with their tokens and what usability issues there are for staking. Any feedback is appreciated as it helps us improve all aspects of using the token and participating in the ecosystem.
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
# Project Smoosh - FAQ
|
||||
|
||||
> We aim on purpose to make minimal changes to reward scheme and software. We're just 'smooshing' together stuff we already debugged and know works.
|
||||
> -- Harry Halpin, Nym CEO
|
||||
This page refer to the changes which are planned to take place over Q3 and Q4 2023. As this is a transition period in the beginning (Q3 2023) the [Mix Nodes FAQ page](./mixnodes-faq.md) holds more answers to the current setup as project Smoosh refers to the eventual setup. As project Smoosh gets progressively implemented the answers on this page will become to be more relevant to the current state and eventually this FAQ page will be merged with the still relevant parts of the main Mix Nodes FAQ page.
|
||||
|
||||
If any questions are not answered or it's not clear for you in which stage project Smoosh is right now, please reach out in Node Operators [Matrix room](https://matrix.to/#/#operators:nymtech.chat).
|
||||
|
||||
## Overview
|
||||
|
||||
### What is project Smoosh?
|
||||
|
||||
As we shared in our blog post article [*What does it take to build the wolds most powerful VPN*](https://blog.nymtech.net/what-does-it-take-to-build-the-worlds-most-powerful-vpn-d351a76ec4e6), project Smoosh is:
|
||||
|
||||
> A nick-name by CTO Dave Hrycyszyn and Chief Scientist Claudia Diaz for the work they are currently doing to “smoosh” Nym nodes so that the same operator can serve alternately as mix node, gateway or VPN node. This requires careful calibration of the Nym token economics, for example, only nodes with the highest reputation for good quality service will be in the VPN set and have the chance to earn higher rewards.
|
||||
> By simplifying the components, adding VPN features and supporting new node operators, the aim is to widen the geographical coverage of nodes and have significant redundancy, meaning plenty of operators to be able to meet demand. This requires strong token economic incentives as well as training and support for new node operators.
|
||||
## Technical Questions
|
||||
|
||||
### What are the changes?
|
||||
|
||||
Project smoosh will have three steps:
|
||||
|
||||
1. Combine the `gateway` and `network-requester`.
|
||||
2. Combine all the nodes in the Nym Mixnet into one binary, that is `mixnode`, `gateway` (entry and exit) and `network-requester`.
|
||||
3. Make a selection button (command/argument/flag) for operators to choose whether they want their node to provide all or just some of the functions nodes have in the Nym Mixnet. Not everyone will be able/want to run an exit `gateway` for example.
|
||||
|
||||
These three steps will be staggered over time - period of several months, and will be implemented one by one with enough time to take in feedback and fix bugs in between.
|
||||
Generally, the software will be the same, just instead of multiple binaries, there will be one Nym Mixnet node binary. Delegations will remain on as they are now, per our token economics (staking, saturation etc)
|
||||
|
||||
### What is the change from allow list to deny list?
|
||||
|
||||
The operators running `gateways` would have to “open” their nodes to a wider range of online services, in a similar fashion to Tor exit relays. The main change will be to expand the original short allow list to a more permissive setup. An exit policy will constrain the hosts that the users of the Nym VPN and Mixnet can connect to. 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 VPN and Mixnet clients.
|
||||
|
||||
### Can I run a mix node only?
|
||||
|
||||
Yes, to run a mix node only is an option. However it will be less rewarded as nodes providing option for `gateway` - meaning the *new smooshed gateway* (previously `gateway` and `network requester`)- due to the work and risk the operators have in comparison to running a `mixnode` only.
|
||||
|
||||
## Token Economics & Rewards
|
||||
|
||||
### What are the incentives for the node operator?
|
||||
|
||||
In the original setup there were no incentives to run a `network-requester`. After the transition all the users will buy multiple tickets of zkNyms credentials and use those as [anonymous e-cash](https://arxiv.org/abs/2303.08221) to pay for their data traffic (`[Nym API](https://github.com/nymtech/nym/tree/master/nym-api)` will do the do cryptographical checks to prevent double-spending). All collected fees get distributed to all active nodes proportionally to their work by the end of each epoch.
|
||||
|
||||
### How does this change the token economics?
|
||||
|
||||
The token economics will stay the same as they are, same goes for the reward algorithm. In practice the distribution of rewards will benefit more the operators who run open gateways.
|
||||
|
||||
### How are the rewards distributed?
|
||||
|
||||
As each operator can choose what roles their nodes provide, the nodes which work as open gateways will have higher rewards because they are the most important to keep up and stable. Besides that the operators of gateways may be exposed to more complication and possible legal risks.
|
||||
|
||||
The nodes which are initialized to run as mix nodes and gateways will be chosen to be on top of the active set before the ones working only as a mix node.
|
||||
|
||||
We are considering to turn off the rewards for non-open gateways to incentivize operators to run the open ones. Mix nodes on 'standby' will not be rewarded (as they are not being used).
|
||||
|
||||
The more roles an operator will allow their node to provide the bigger reward ratio which will have huge performance benefits for the end-users.
|
||||
|
||||
|
||||
### How will be the staking and inflation after project Smoosh?
|
||||
|
||||
We must run tests to see how many users pay. We may need to keep inflation on if not enough people pay to keep high quality gateways on in the early stage of the transition. That would mean keeping staking on for gateways. Staking will always be on for mix nodes.
|
||||
|
||||
### When project smooth will be launched, it would be the mixmining pool that will pay for the gateway rewards based on amount of traffic routed ?
|
||||
|
||||
Yes, the same pool. Nym's aim is to do minimal modifications. The only real modification on the smart contract side will be to get into top X of 'active set' operators will need to have open gateway function enabled.
|
||||
|
||||
### What does this mean for the current delegators?
|
||||
|
||||
From an operator standpoint, it shall just be a standard Nym upgrade, a new option to run the gateway software on your node. Delegators should not have to re-delegate.
|
||||
|
||||
## Legal Questions
|
||||
|
||||
### Are there any legal concerns for the operators?
|
||||
|
||||
So far the general line is running a gateway is not illegal (unless you are in Iran, China, and a few other places) and due to encryption/mixing less risky than running a normal VPN node. For mix nodes, its very safe as they have no idea what packets they are mixing.
|
||||
|
||||
There are several legal questions regarding to this and we would like to ask you to fill this [short survey](https://nymtech.typeform.com/exitnode).
|
||||
|
||||
We'll have a thorough legal analysis out before hand and various resources from and for the community. <!-- which we started to gather in the [Community Legal Forum](../legal/legal-forum.md). Uncomment when the legal forum get's merged -->
|
||||
|
||||
@@ -2,6 +2,12 @@
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
## [v1.2.8] (2023-08-23)
|
||||
|
||||
- [hotfix]: don't assign invalid fields when crossing the JS boundary ([#3805])
|
||||
|
||||
[#3805]: https://github.com/nymtech/nym/pull/3805
|
||||
|
||||
## [1.2.7] (2023-08-17)
|
||||
- release due to schema changes in the contract
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@nymproject/nym-wallet-app",
|
||||
"version": "1.2.7",
|
||||
"version": "1.2.8",
|
||||
"main": "index.js",
|
||||
"license": "MIT",
|
||||
"scripts": {
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
[package]
|
||||
name = "nym_wallet"
|
||||
version = "1.2.7"
|
||||
version = "1.2.8"
|
||||
description = "Nym Native Wallet"
|
||||
authors = ["Nym Technologies SA"]
|
||||
license = ""
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"package": {
|
||||
"productName": "nym-wallet",
|
||||
"version": "1.2.7"
|
||||
"version": "1.2.8"
|
||||
},
|
||||
"build": {
|
||||
"distDir": "../dist",
|
||||
|
||||
Reference in New Issue
Block a user