diff --git a/documentation/docs/pages/network/architecture/_meta.json b/documentation/docs/pages/network/architecture/_meta.json index 332816a920..e1594536e2 100644 --- a/documentation/docs/pages/network/architecture/_meta.json +++ b/documentation/docs/pages/network/architecture/_meta.json @@ -1,5 +1,4 @@ { - "overview": "Overview", "mixnet": "Mixnet", "nyx": "Nyx Blockchain", "nym-vs-others": "Nym vs Other Platforms", diff --git a/documentation/docs/pages/network/architecture/mixnet.mdx b/documentation/docs/pages/network/architecture/mixnet.mdx index b64ea2d1af..f6ea39168e 100644 --- a/documentation/docs/pages/network/architecture/mixnet.mdx +++ b/documentation/docs/pages/network/architecture/mixnet.mdx @@ -1,16 +1,18 @@ # Mixnet Components The mixnet is made up of nodes running in several different roles: * **Mix Nodes** provide network security for network content _and_ metadata by performing packet-mixing on traffic travelling through the network. -* **Gateways** REWRITE act as message storage for clients which may go offline and come back online again, and defend against denial of service attacks. The default gateway implementation included in the Nym platform code holds packets for later retrieval. For many applications (such as simple chat), this is usable out of the box, as it provides a place that potentially offline clients can retrieve packets from. The access token allows clients to pull messages from the gateway node. +* **Gateways** act as message storage for clients which may go offline and come back online again, and (once zk-nyms are enabled) check for anonymous proof of access credentials. They represent the first and last hop Mixnet packets travel through when travelling between clients. * **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the Network Requester. > You can find the old pages for the individual nodes in the archive TODO LINK subsection. +* **Clients** are used to connect to and send messages through the Mixnet to other clients, utilising Gateways for ingress and egress. + ## Smoosh Status -These were originally completely separate binaries. They are in the process of being 'smooshed' together into a single `nym-node` binary which runs in different modes. +The various Mixnet components were originally completely separate binaries. They are in the process of being 'smooshed' together into a single `nym-node` binary which runs in different modes for ease of use, as well as to allow for a more developed and responsive Mixnet design, where the role of a node in a given time period is decided and changed automatically based on network conditions (more on this in the future). Completed: * The `nym-network-requester` is now part of a `nym-node` running in as an Exit Gateway. Upcoming: -* Whether a `nym-node` is running as a Gateway or Mix Node will be set based on network conditions, and change epoch to epoch. Currently the role is set manually by the operator and does not change automatically over time. +* Whether a `nym-node` is running as a Gateway or Mix Node will be set based on network conditions, and change epoch to epoch. Currently the role is set manually by the operator and does not change automatically over time. A node will be able to be running in the role of a Mix Node, an Entry Gateway, or an Exit Gateway. diff --git a/documentation/docs/pages/network/architecture/mixnet/_meta.json b/documentation/docs/pages/network/architecture/mixnet/_meta.json index 293c7bac4d..ea69b6b47f 100644 --- a/documentation/docs/pages/network/architecture/mixnet/_meta.json +++ b/documentation/docs/pages/network/architecture/mixnet/_meta.json @@ -1,5 +1,4 @@ { "nodes": "Nodes", - "clients": "Clients", - "archive": "Archive" + "clients": "Clients" } diff --git a/documentation/docs/pages/network/architecture/mixnet/archive/gateway.md b/documentation/docs/pages/network/architecture/mixnet/archive/gateway.md deleted file mode 100644 index 45ffbbda5c..0000000000 --- a/documentation/docs/pages/network/architecture/mixnet/archive/gateway.md +++ /dev/null @@ -1,13 +0,0 @@ -# Gateways - -> The gateway setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/gateway-setup.html). - -REWRITE AND INCLUDE ALL THE STUFF ABOUT INGRESS AND EXIT GATEWAYS - -Gateways are key to both the usability of the mixnet, and the operation of the mixnet's tokenomics. They serve two main functions: -* In the future (when the mixnet is no longer running in 'free to use' mode), to check for zkNym credentials (previously referred to as [Coconut Credentials](../bandwidth-credentials.md)) with which users can anonymously prove they have paid to send traffic through the mixnet. A % of the worth of these credentials will be distributed to the operator of the gateway periodically as payment for providing their service. The more credentials user clients 'spend' with them, the higher the rewards for the gateway operator and their delegators will be. The rest of this value will be sent to the Mixmining Pool, a pool of tokens from which `NYM` rewards are distributed to mix node operators. -* Act as a mailbox for connected clients. Clients create a lasting relationship with a gateway on initialisation, binding themselves to always use a particular gateway as their ingress point for mixnet traffic (this also means that this gateway is the egress point for any traffic sent _to_ this client - see the [mixnet traffic flow page](../architecture/traffic-flow.md) and the [addressing scheme](../architecture/addressing-system.md) for further details). If a client is offline and the Gateway can't deliver packets addressed to it, they will hold these packets until the client comes back online. - -## Further Reading -* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4.2 -* [Nym Blog: Gateways to Privacy](https://blog.nymtech.net/gateways-to-privacy-51196005bf5) diff --git a/documentation/docs/pages/network/architecture/mixnet/archive/mixnode.md b/documentation/docs/pages/network/architecture/mixnet/archive/mixnode.md deleted file mode 100644 index 8565f7be0a..0000000000 --- a/documentation/docs/pages/network/architecture/mixnet/archive/mixnode.md +++ /dev/null @@ -1,17 +0,0 @@ -# Mix Nodes - -> The mix node setup and maintenance guide has migrated to the [Operator Guides book](https://nymtech.net/operators/nodes/mix-node-setup.html). - -Mix nodes are the backbone of the mixnet. These are the nodes that perform 'mix mining', otherwise known simply as 'mixing'. - -Mix nodes, after receiving a packet, decrypt its outer 'layer' and hold it for a variable amount of time before passing it to its next destination - either another mix node, or a gateway. In doing so, they 'mix' packets by sending them to their next destination in a different order than they were received. - -Mix nodes are rewarded according to their quality of service, and the probability of their inclusion in the active set (i.e. the nodes that mix traffic for the next epoch) is also affected by this (as well as their delegation-based reputation - see the [Mix node deepdive](#further-reading) below for more on this). - -## (Coming soon) Mixing: a Step-by-Step Breakdown - -## Further reading -* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 4 -* [Nym Blog: Mix node deepdive](https://blog.nymtech.net/nym-mixnodes-deep-dive-d2b91917f097) -* [Mixnet Traffic Flow overview](../architecture/traffic-flow.md) -* [Reward Sharing for Mixnets](https://nymtech.net/nym-cryptoecon-paper.pdf) diff --git a/documentation/docs/pages/network/architecture/mixnet/archive/network-requester.md b/documentation/docs/pages/network/architecture/mixnet/archive/network-requester.md deleted file mode 100644 index da9fff6a64..0000000000 --- a/documentation/docs/pages/network/architecture/mixnet/archive/network-requester.md +++ /dev/null @@ -1,22 +0,0 @@ -# Network Requester - -> The network requester setup and maintenance guide has moved to the [Operator Guides book](https://nymtech.net/operators/nodes/network-requester-setup.html). - -Network requesters are the first instance of the catch-all term 'service', or 'service providers'. In essence, think of services as being the part of the mixnet infrastructure that let you _do_ something, such as access emails, messaging service backends, or blockchains via the mixnet. - -## Domain filtering -Network requesters, in essence, act as a form of proxy (somewhat analagous to a Tor exit node). If you have access to a server, you can run the network requester, which allows Nym users to send outbound requests from their local machine through the mixnet to a server, which then makes the request on their behalf, shielding them (and their metadata) from clearnet, untrusted and unknown infrastructure, such as email or message client servers. - -By default the network requester is **not** an open proxy (although it can be used as one). It uses a whitelist for outbound requests. - -Any request to a URL which is not on this local list (modified by the node operator) or [Nym's default list](https://nymtech.net/.wellknown/network-requester/standard-allowed-list.txt) will be blocked. - -This default whitelist is useful for knowing that the majority of Network requesters are able to support certain apps 'out of the box', and the local whitelist allows operators to include their own whitelisted domains. - -> Substantial changes are on the horizon concerning how Network Requesters manage incoming requests - if you are an operator and have experience running software such as Tor exit nodes or p2p nodes get in touch via our [Matrix server](https://matrix.to/#/#dev:nymtech.chat). - -## (Coming soon) Consuming credentials for anonymous service payment - -## Further reading -* [Nym Blog: Network Requester deepdive](https://blog.nymtech.net/tech-deepdive-network-requesters-e5359a6cc31c) -* [Nym Blog: Choose Your Character](https://blog.nymtech.net/choose-your-character-an-overview-of-nym-network-actors-19e6a9808540) diff --git a/documentation/docs/pages/network/architecture/mixnet/clients.mdx b/documentation/docs/pages/network/architecture/mixnet/clients.mdx index 50c64a434b..8ad06023ad 100644 --- a/documentation/docs/pages/network/architecture/mixnet/clients.mdx +++ b/documentation/docs/pages/network/architecture/mixnet/clients.mdx @@ -4,20 +4,21 @@ A large proportion of the Nym mixnet's functionality is implemented client-side. Clients perform the following actions on behalf of users: -* determine network topology - what nodes exist, their public encryption keys, etc. -* register with a gateway -* authenticate with a gateway -* receive and decrypt messages from the gateway -* create layer-encrypted Sphinx packets LINK -* send Sphinx packets with real messages -* send Sphinx packet _cover traffic_ when no real messages are being sent LINK -* retransmit un-acknowledged packet sends - if a client sends 100 packets to a gateway, but only receives an acknowledgement ('ack') for 95 of them, it will resend those 5 packets to the gateway again, to make sure that all packets are received. +* Determine network topology - what nodes exist, their public encryption keys, etc. +* Register with a gateway +* Authenticate with a gateway +* Receive and decrypt messages from the gateway +* Create layer-encrypted Sphinx packets TODO LINK +* Send Sphinx packets with real messages +* Send Sphinx packet _cover traffic_ when no real messages are being sent TODO LINK +* Retransmit un-acknowledged packet sends TODO LINK > At the moment due to the fact that Nym clients are message-based LINK, using the Mixnet requires another client on the 'other side' of the mixet to send packets to, unless you're using the `nymvpn` client (part of the NymVPN app) or the `socks5` client, which operates as a SOCKS4,4a, or 5 proxy and is able to utilise the client embedded within the `nym-node`'s Exit Gateway functionality (prev. this functionality was a standalone service, the Network Requester). In the future we wish to remove this point of friction and have all Nym clients construct IP packets instead, easing the integration burden and abstracting away the message-based nature of client communication. -TODO breakdown of client: +TODO breakdown of client path: - startup - gateway connection + - what keys what auth format etc - auth - message sending - poisson process diff --git a/documentation/docs/pages/network/architecture/mixnet/nodes.mdx b/documentation/docs/pages/network/architecture/mixnet/nodes.mdx index dd1cba15c2..08704a2c84 100644 --- a/documentation/docs/pages/network/architecture/mixnet/nodes.mdx +++ b/documentation/docs/pages/network/architecture/mixnet/nodes.mdx @@ -10,11 +10,4 @@ As outlined on the previous page, the various types of Mixnet nodes - Mix Nodes, - Accepting incoming Sphinx packets from other Nym nodes and, using a variable delay, 'mixing' them with other packets (not forwarding on received packets according to FIFO but instead relying on a randomised delay function) - a role currently fulfilled by Mix Nodes. - Forwarding packets on to their final destination: the 'receiving' Nym client. -Traffic moving through the mixnet will always move between a sending and receiving client, with 5 'hops' between them: -- Start. sender -> Ingress Gateway -- Hop 1. Ingress Gateway -> Mix Node 1 -- Hops 2..4 Mix Node 1 -> Mix Node 2 -> Mix Node 3 -- Hop 5. Mix Node 3 -> Exit Gateway -- Fin. Exit Gateway -> receiving client. - -See the [traffic flow]() TODO LINK page for detailed information on how traffic moves through the Mixnet. +See the [traffic flow]() TODO LINK page for detailed information on how traffic moves through the Mixnet as well as the [Loopix](https://arxiv.org/pdf/1703.00536) design paper for overview of the stratified nature of the Mixnet. diff --git a/documentation/docs/pages/network/architecture/nym-vs-others.md b/documentation/docs/pages/network/architecture/nym-vs-others.md index 8ec48956b9..037234cd76 100644 --- a/documentation/docs/pages/network/architecture/nym-vs-others.md +++ b/documentation/docs/pages/network/architecture/nym-vs-others.md @@ -2,11 +2,6 @@ The diagram and brief explainer texts below give a high level overview of the difference between Nym and other comparable systems. -> If you want to dig more deeply into the way traffic is packetised and moved through the mixnet, check out the [Mixnet Traffic Flow](https://nymtech.net/docs/architecture/traffic-flow.html) page of the docs. - - ### Nym vs VPNs The most popular network-level privacy solution currently is the VPN (virtual private network), which provides network-level protection via an encrypted tunnel between a user’s computer and one run by a VPN provider. VPNs are often misconfigured, however, and even when configured correctly, don’t offer real privacy or adequate resistance to censorship. diff --git a/documentation/docs/pages/network/architecture/nyx.mdx b/documentation/docs/pages/network/architecture/nyx.mdx new file mode 100644 index 0000000000..2d7bcc8261 --- /dev/null +++ b/documentation/docs/pages/network/architecture/nyx.mdx @@ -0,0 +1,5 @@ +# Nyx Blockchain + +Nyx is a Cosmos SDK blockchain. It records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. + +The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain (the other being `NYX`, used for Blockchain consensus), and the chain is where the Mixnet, Vesting, and zk-nym-related smart contracts are deployed. diff --git a/documentation/docs/pages/network/architecture/nyx/_meta.json b/documentation/docs/pages/network/architecture/nyx/_meta.json new file mode 100644 index 0000000000..be7216db7f --- /dev/null +++ b/documentation/docs/pages/network/architecture/nyx/_meta.json @@ -0,0 +1,4 @@ +{ + "validator": "Validators", + "smart-contracts": "Smart Contracts" +} diff --git a/documentation/docs/pages/network/architecture/nyx/interacting-with-chain.md b/documentation/docs/pages/network/architecture/nyx/interacting-with-chain.md deleted file mode 100644 index 5ebd5484bd..0000000000 --- a/documentation/docs/pages/network/architecture/nyx/interacting-with-chain.md +++ /dev/null @@ -1,17 +0,0 @@ -# Interacting with Nyx Chain and Smart Contracts - -There are two options for interacting with the blockchain to send tokens or interact with deployed smart contracts: -* [`Nym-CLI`](../tools/nym-cli.md) tool -* `nyxd` binary - -## Nym-CLI tool (recommended in most cases) -The `nym-cli` tool is a binary offering a simple interface for interacting with deployed smart contract (for instance, bonding and unbonding a mix node from the CLI), as well as creating and managing accounts and keypairs, sending tokens, and querying the blockchain. - -Instructions on how to do so can be found on the [`nym-cli` docs page](../tools/nym-cli.md), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html). - -## Nyxd binary -The `nyxd` binary, although more complex to compile and use, offers the full range of commands availiable to users of CosmosSDK chains. Use this if you are (e.g.) wanting to perform more granular queries about transactions from the CLI. - -You can use the instructions on how to do this on from the [`gaiad` docs page](https://hub.cosmos.network/main/delegators/delegator-guide-cli.html#querying-the-state), and there are example commands in the [integrations FAQ](https://nymtech.net/developers/faq/integrations-faq.html). - - diff --git a/documentation/docs/pages/network/architecture/nyx/ledger-live.md b/documentation/docs/pages/network/architecture/nyx/ledger-live.md deleted file mode 100644 index 968dd2e25b..0000000000 --- a/documentation/docs/pages/network/architecture/nyx/ledger-live.md +++ /dev/null @@ -1,79 +0,0 @@ -# Ledger Live Support - -Use the following instructions to interact with the Nyx blockchain - either with deployed smart contracts, or just to send tokens - using your Ledger device to sign transactions. - -## Prerequisites -* Download and install [Ledger Live](https://www.ledger.com/ledger-live). -* Compile the `nyxd` binary as per the instructions [here](https://nymtech.net/operators/nodes/validator-setup.html#building-the-nym-validator). Stop after you can successfully run `nyxd` and get the helptext in your console output. - -## Prepare your Ledger App -* Plug in your Ledger device -* Install the `Cosmos (ATOM)` app by following the instructions [here](https://hub.cosmos.network/main/resources/ledger.html). This app allows you to interact with **any** Cosmos SDK chain - you can manage your ATOM, OSMOSIS, NYM tokens, etc. -* On the device, navigate to the Cosmos app and open it - -## Create a keypair -Add a reference to the ledger device on your local machine by running the following command in the same directory as your `nyxd` binary: - -``` -nyxd keys add ledger_account --ledger -``` - -## Command help with `nyxd` -More information about each command is available by consulting the help section (`--help`) at each layer of `nyxd`'s commands: - -``` -# logging top level command help -nyxd --help - -# logging top level command help for transaction commands -nyxd tx --help - -# logging top level command help for transaction commands utilising the 'bank' module -nyxd tx bank --help -``` - -## Sending tokens between addresses -Perform a transaction from the CLI with `nyxd`, appending the `--ledger` option to the command. - -As an example, the below command will send 1 `NYM` from the ledger account to the `$DESTINATION_ACCOUNT`: - -``` -nyxd tx bank send ledger_account $DESTINATION_ACCOOUNT 1000000unym --ledger --node https://rpc.dev.nymte.ch:443 -``` - -> When a command is run, the transaction will appear on the Ledger device and will require physical confirmation from the device before being signed. - -## Nym-specific transactions -Nym-specific commands and queries, like bonding a mix node or delegating unvested tokens, are available in the `wasm` module, and follow the following pattern: - -``` -# Executing commands -nyxd tx wasm execute $CONTRACT_ADDRESS $JSON_MSG - -# Querying the state of a smart contract -nyxd query wasm contract-state smart $CONTRACT_ADDRESS $JSON_MSG -``` - -You can find the value of `$CONTRACT_ADDRESS` in the [`network defaults`](https://github.com/nymtech/nym/blob/release/v1.1.7/common/network-defaults/src/mainnet.rs) file. - -The value of `$JSON_MSG` will be a blog of `json` formatted as defined for each command and query. You can find these definitions for the mixnet smart contract [here](https://github.com/nymtech/nym/blob/develop/common/cosmwasm-smart-contracts/mixnet-contract/src/msg.rs) and for the vesting contract [here](https://github.com/nymtech/nym/blob/develop/common/cosmwasm-smart-contracts/vesting-contract/src/messages.rs) under `ExecuteMsg` and `QueryMsg`. - -### Example command execution: -#### Delegate to a mix node -You can delegate to a mix node from the CLI using `nyxd` and signing the transaction with your ledger by filling in the values of this example: -``` -CONTRACT_ADDRESS=mixnet_contract_address - -./nyxd tx wasm execute $CONTRACT_ADDRESS '{"delegate_to_mixnode":{"mix_identity":"MIX_NODE_IDENTITY","amount":{"amount":"100000000000","denom":"unym"}}}' --ledger --from admin --node https://rpc.dev.nymte.ch:443 --gas-prices 0.025unymt --gas auto -b block -``` - -> By replacing the value of `CONTRACT_ADDRESS` with the address of the vesting contract, you could use the above command to use tokens held in the vesting contract. - -#### Query a vesting schedule -You can query for (e.g.) seeing the current vesting period of an address by filling in the values of the following: -``` -CONTRACT_ADDRESS=vesting_contract_address - -nyxd query wasm contract-state smart $CONTRACT_ADDRESS '{"get_current_vesting_period"}:{"address": "address_to_query_for"}' --ledger --from admin --node https://rpc.dev.nymte.ch:443 --chain-id qa-net --gas-prices 0.025unymt --gas auto -b block -``` - diff --git a/documentation/docs/pages/network/architecture/nyx/mixnet-contract.md b/documentation/docs/pages/network/architecture/nyx/mixnet-contract.md deleted file mode 100644 index 48b63281fc..0000000000 --- a/documentation/docs/pages/network/architecture/nyx/mixnet-contract.md +++ /dev/null @@ -1,13 +0,0 @@ -# Mixnet Contract - -The Mixnet smart contract is a core piece of the Nym system, functioning as the mixnet directory and keeping track of delegations and rewards: the core functionality required by an incentivised mixnet. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/mixnet). - -### Functionality -The Mixnet contract has multiple functions: -* storing bonded mix node and gateway information (and removing this on unbonding). -* providing the network-topology to the (cached) validator API endpoint used by clients on startup for routing information. -* storing delegation and bond amounts. -* storing reward amounts. - -The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values. - diff --git a/documentation/docs/pages/network/architecture/nyx/rpc-node.md b/documentation/docs/pages/network/architecture/nyx/rpc-node.md deleted file mode 100644 index 352b689bed..0000000000 --- a/documentation/docs/pages/network/architecture/nyx/rpc-node.md +++ /dev/null @@ -1,9 +0,0 @@ -# RPC Nodes - -RPC Nodes (which might otherwise be referred to as 'Lite Nodes' or just 'Full Nodes') differ from Validators in that they hold a copy of the Nyx blockchain, but do **not** participate in consensus / block-production. - -You may want to set up an RPC Node for querying the blockchain, or in order to have an endpoint that your app can use to send transactions. - -In order to set up an RPC Node, simply follow the instructions to set up a [Validator](https://nymtech.net/operators/nodes/validator-setup.html), but **exclude the `nyxd tx staking create-validator` command**. - -If you want to fast-sync your node, check out the Polkachu snapshot and their other [resources](https://polkachu.com/seeds/nym). diff --git a/documentation/docs/pages/network/architecture/nyx/smart-contracts.md b/documentation/docs/pages/network/architecture/nyx/smart-contracts.md index 7c1182e79a..a52039cc37 100644 --- a/documentation/docs/pages/network/architecture/nyx/smart-contracts.md +++ b/documentation/docs/pages/network/architecture/nyx/smart-contracts.md @@ -1,9 +1,8 @@ # Smart Contracts -The Nyx blockchain is based on [CosmWasm](https://cosmwasm.com/). It allows users to code smart contracts in a safe subset of the Rust programming language, easily export them to WebAssembly, and upload them to the blockchain. Information about the chain can be found on the [Nyx blockchain explorer](https://nym.explorers.guru/). +The Nyx blockchain is based on [CosmWasm](https://cosmwasm.com/). -There are currently two smart contracts on the Nyx chain: -* the [Mixnet contract](./mixnet-contract.md) which manages the network topology of the mixnet, tracking delegations and rewarding. -* the [Vesting contract](./vesting-contract.md) which manages `NYM` token vesting functionality. - -> Users will soon be able to create and upload their own CosmWasm smart contracts to Nyx and take advantage of applications such as the Coconut Credential Scheme - more to be announced regarding this very soon. +TODO ADD ECASH CONTRACT INFO +There are currently two smart contracts on the Nyx chain: +* the [Mixnet contract](./mixnet-contract.md) which manages the network topology of the mixnet, tracking delegations and rewarding. +* the [Vesting contract](./vesting-contract.md) which manages `NYM` token vesting functionality. diff --git a/documentation/docs/pages/network/architecture/nyx/smart-contracts/mixnet-contract.md b/documentation/docs/pages/network/architecture/nyx/smart-contracts/mixnet-contract.md new file mode 100644 index 0000000000..f3b2f46f9f --- /dev/null +++ b/documentation/docs/pages/network/architecture/nyx/smart-contracts/mixnet-contract.md @@ -0,0 +1,14 @@ +# Mixnet Contract + +The Mixnet smart contract is a core piece of the Nym system, functioning as the mixnet directory and keeping track of delegations and rewards: the core functionality required by an incentivised mixnet. You can find the code and build instructions [here](https://github.com/nymtech/nym/tree/master/contracts/mixnet). + +> Having a smart contract act as a decentralised topology directory for clients connecting to the Mixnet allows us to mitigate several possible attacks which systems relying on P2P networking are susceptible to TODO LINK TO WHY NOT P2P PAGE + +Functionality +The Mixnet contract has multiple functions: +* storing bonded mix node and gateway information (and removing this on unbonding). +* **providing the network-topology to the (cached) validator API endpoint used by clients on startup for routing information.** +* storing delegation and bond amounts. +* storing reward amounts. + +The addresses of deployed smart contracts can be found in the [`network-defaults`](https://github.com/nymtech/nym/blob/master/common/network-defaults/src/mainnet.rs) directory of the codebase alongside other network default values. diff --git a/documentation/docs/pages/network/architecture/nyx/vesting-contract.md b/documentation/docs/pages/network/architecture/nyx/smart-contracts/vesting-contract.md similarity index 100% rename from documentation/docs/pages/network/architecture/nyx/vesting-contract.md rename to documentation/docs/pages/network/architecture/nyx/smart-contracts/vesting-contract.md diff --git a/documentation/docs/pages/network/architecture/nyx/validator.md b/documentation/docs/pages/network/architecture/nyx/validator.md index 855cf21700..0ac0270bc3 100644 --- a/documentation/docs/pages/network/architecture/nyx/validator.md +++ b/documentation/docs/pages/network/architecture/nyx/validator.md @@ -2,11 +2,10 @@ > The validator setup and maintenance guide has moved to the [Operator Guides book](https://nymtech.net/operators/nodes/validator-setup.html). -Validators secure the Nyx blockchain via Proof of Stake consensus. The Nyx blockchain records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. The Nyx validators are run via the `nyxd` binary ([codebase](https://github.com/nymtech/nyxd)), maintaining a CosmWasm- and IBC-enabled blockchain. +Validators secure the Nyx blockchain via Proof of Stake consensus. The Nyx blockchain records the ledger of `NYM` transactions and executes the smart contracts for distributing `NYM` rewards. The Nyx validators are run via the `nyxd` binary ([codebase](https://github.com/nymtech/nyxd)), maintaining a CosmWasm- and IBC-enabled blockchain. -The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet](../nyx/mixnet-contract.md) and [Vesting](../nyx/vesting-contract.md) smart contracts are deployed. +The blockchain plays a supporting but fundamental role in the mixnet: the `NYM` token used to incentivise node operators is one of two native tokens of the chain, and the chain is where the [Mixnet](../nyx/mixnet-contract.md) and [Vesting](../nyx/vesting-contract.md) smart contracts are deployed. -## Further Reading +## Further Reading * Detailed info on Nyx Validators and token flow can be found in [Nym Reward Sharing for Mixnets document](https://nymtech.net/nym-cryptoecon-paper.pdf) in section 2.3 and 2.4. -* Our [quarterly update](https://blog.nymtech.net/quarterly-token-economic-parameter-update-b2862948710f) on token economics from July 2023. -* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 3.1 \ No newline at end of file +* [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) section 3.1 diff --git a/documentation/docs/pages/network/architecture/overview.md b/documentation/docs/pages/network/architecture/overview.md deleted file mode 100644 index c5a00c5e0f..0000000000 --- a/documentation/docs/pages/network/architecture/overview.md +++ /dev/null @@ -1,16 +0,0 @@ -# Network Components - -The Nym platform knits together several privacy technologies, integrating them into a system of cooperating networked nodes in order to provide network-level privacy and metadata anonymity. - -The core components are: -* a **mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the **Loopix TODO LINK** design. -* **Sphinx**, a way of transmitting armoured, layer-encrypted information packets which are indistinguishable from each other at a binary level. -* various **Nym clients** LINK which manage sending and receiving Sphinx packets, encrypting/decrypting traffic, and providing cover traffic TODO LINK to hide 'real' traffic timing. -* a privacy enhancing signature scheme called **zk-nym**, based on the Coconut and Ecash schemes. This allows a shift in thinking about resource access control, from an identity-based paradigm based on _who you are_ to a privacy-preserving paradigm based on _right to use_. -* A CosmWasm-enabled blockchain called **Nyx**, the home of the various smart contracts used by the mixnet. - -TODO REDO DIAGRAM -![Nym Platform](../images/nym-platform-dark.png) - - -