final linkchecks
This commit is contained in:
mfahampshire
@@ -4,5 +4,5 @@ TODO new diagram
|
||||
|
||||
Core components:
|
||||
* 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** design](concepts/loopix). This is made up of [Nym nodes](architecture/mixnet/nodes) runnning on servers around the world.
|
||||
* Various [**Nym clients**](architecture/mixnet/clients) which manage sending and receiving Sphinx packets, encrypting/decrypting traffic, and providing [cover traffic](../concepts/cover-traffic) to hide 'real' traffic timing.
|
||||
* Various [**Nym clients**](architecture/mixnet/clients) which manage sending and receiving Sphinx packets, encrypting/decrypting traffic, and providing [cover traffic](./concepts/cover-traffic) to hide 'real' traffic timing.
|
||||
* A CosmWasm-enabled blockchain called [**Nyx**](architecture/nyx), the home of the various smart contracts used by the mixnet.
|
||||
|
||||
@@ -8,9 +8,9 @@ Clients perform the following actions on behalf of users:
|
||||
* Register with a gateway
|
||||
* Authenticate with a gateway
|
||||
* Receive and decrypt messages from the gateway
|
||||
* Create layer-encrypted [Sphinx packets](../cryptography/sphinx)
|
||||
* Create layer-encrypted [Sphinx packets](../../cryptography/sphinx)
|
||||
* Send Sphinx packets with real messages
|
||||
* Send Sphinx packet [cover traffic](../concepts/cover-traffic) when no real messages are being sent
|
||||
* Retransmit [un-acknowledged packet sends](../traffic/acks)
|
||||
* Send Sphinx packet [cover traffic](../../concepts/cover-traffic) when no real messages are being sent
|
||||
* Retransmit [un-acknowledged packet sends](../../traffic/acks)
|
||||
|
||||
> At the moment due to the fact that Nym clients are [message-based](../../../developers/concepts/messages), 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.
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
# Coming Soon!
|
||||
@@ -18,7 +18,7 @@ This contract is a hub for zk-nym related actions, being called by either:
|
||||
- proposing to add an address to the blacklist.
|
||||
- executing an open proposal.
|
||||
|
||||
- The the zk-nym [payment backend](../../../cryptography/zk-nym-overview) can deposit funds with information used to identify the deposit.
|
||||
- The the zk-nym [payment backend](../../../cryptography/zk-nym/zk-nym-overview) can deposit funds with information used to identify the deposit.
|
||||
|
||||
- Finally, nodes running as Gateways can create a proposal to redeem a set of spend zk-nyms.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Multisig Contract
|
||||
|
||||
The multisig contract used by the [NymAPI Quroum]() - a subset of the Nyx Validator set taking on the additional work of generating and validating zk-nyms - to execute certain actions in the [zk-nym](./ecash.md) contract.
|
||||
The multisig contract used by the [NymAPI Quroum](../../../cryptography/zk-nym/zk-nym-overview) - a subset of the Nyx Validator set taking on the additional work of generating and validating zk-nyms - to execute certain actions in the [zk-nym](./ecash.md) contract.
|
||||
|
||||
It is essentially an instance of the [canonical](https://github.com/CosmWasm/cw-plus/tree/main/contracts) `cw3-flex-multisig` using the `cw4-group` contract, with one minor change to restrict the addresses allowed to submit proposals.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ The validator setup and maintenance guide has moved to the [Operator Guides book
|
||||
|
||||
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](./smart-contracts/mixnet-contract), [Vesting](./smart-contracts/vesting-contract) and [zk-nym](./smart-contracts/ecash) smart contracts are deployed.
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# What are zk-nyms?
|
||||
|
||||
The zk-nym scheme enables the creation and use of unlinkable, rerandomisable anonymous access credentials that are 'spent' with Gateways in order to anonymously prove that someone has paid for Mixnet access. This implementation incorporates elements of both the [Coconut Credential](./coconut.md) and [Offline Ecash](https://arxiv.org/pdf/2303.08221) schemes.
|
||||
The zk-nym scheme enables the creation and use of unlinkable, rerandomisable anonymous access credentials that are 'spent' with Gateways in order to anonymously prove that someone has paid for Mixnet access. This implementation incorporates elements of both the [Coconut Credential](https://arxiv.org/pdf/1802.07344) and [Offline Ecash](https://arxiv.org/pdf/2303.08221) schemes.
|
||||
|
||||
As outlined in the [overview](./zk-nym/zk-nym-overview.md) on the next page, zk-nyms allow for users to pay for Mixnet access in a manner that is **unlinkable to their payment account**; even with pseudonymous cryptocurrencies or fiat. This solves one of the fundamental privacy problems with the majority of VPNs and dVPNs in production today: the linkability of a user's session with their payment information, which can in the majority of cases be easily used to deanonymise them, either at the behest of an authority or by the service operators themselves.
|
||||
|
||||
|
||||
@@ -47,7 +47,7 @@ At this point, NYM tokens have been deposited into the smart contract controlled
|
||||
Once the Requester has received over the threshold number of PSCs they can assemble them into a credential signed by the master key. The Requester never learns this master key (it is a private attribute) but the credential can be verified by the Quroum as being valid by checking for a proof that the credential's private attribute - the value of the master key - is valid.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Spend zk-nym to Access Mixnet
|
||||
@@ -55,4 +55,4 @@ Once the Requester has received over the threshold number of PSCs they can assem
|
||||
- This zk-nym credit is later presented to the Quorum by the Gateway that collected it, which is used to calculate reward percentages given to Nym Network infrastructure operators by the Quorum, with payouts triggered by their multisig wallet. Both ingress Gateways and the Quorum use spent zk-nym credits when engaging in [double spending protection](./double-spend-prot.md).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user