Max/zknym docs #4780
Open
Max/zknym docs #4780
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 2 Skipped Deployments
|
serinko
approved these changes
Sep 5, 2024
| @@ -0,0 +1,45 @@ | |||
| # 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. | |||
There was a problem hiding this comment.
Based on some recent talks, I started to default to Nym Network over Mixnet as a generic name for the network. Mixnet to be onbe part of that, WG another.
I did not rewrite all docs accordingly, but any time I compose something new, I use Nym Network.
|
|
||
| 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. | ||
|
|
||
| As outlined in the [overview](./zknym-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. |
There was a problem hiding this comment.
ditto, consider Mixnet -> Nym Network
|
|
||
| As outlined in the [overview](./zknym-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. | ||
|
|
||
| > The current zk-nym scheme is non-generic in that it is only used for gating Mixnet access. A generic scheme based on zk-nyms is being actively researched in order to facilitate more generic and customisable anonymous credentials for other applications and services. |
Comment on lines
+4
to
+6
| The first use-case of zk-nyms is for anonymously proving the right to use the Nym mixnet for privacy. | ||
|
|
||
| The Nym mixnet is - at the time of publication - free for everyone. However, soon™ it will be required for each connecting client to present a valid credential - a zk-nym - to their ingress Gateway to access the Mixnet. |
There was a problem hiding this comment.
ditto, consider Mixnet -> Nym Network
Comment on lines
+4
to
+6
| The first use-case of zk-nyms is for anonymously proving the right to use the Nym mixnet for privacy. | ||
|
|
||
| The Nym mixnet is - at the time of publication - free for everyone. However, soon™ it will be required for each connecting client to present a valid credential - a zk-nym - to their ingress Gateway to access the Mixnet. |
There was a problem hiding this comment.
Wonder if to stick to ingress Gateway (generic term) or to Nym convention - Entry Gateway
| - A malicious user purchases bandwidth and aggregates a valid zk-nym credential in the standard way, worth $10 of crypto/fiat. Subsequently, the malicious user proceeds to sell the credential to 100 users for $1 each, allowing each user to generate zk-nym credits of 100MB from this **valid** credential. Under the offline approach, entry nodes forego double-spending checks; so long as the clients all used different ingress Gateways, all 100 users could access the network without obtaining a subscription. As bandwidth consumption is tracked locally between client and ingress node, and each zk-nym credit is rerandomised, there is no way that ingress Gateways would know that the zk-credential used by the client has been shared with other parties. This loophole highlights the need for stringent measures to counter such potential abuses within the system, without creating either speed bottlenecks (in the case of the Online model) or impacting the anonymity of the system. We can, however, mitigate this problem without doing either of these things. | ||
|
|
||
| ## Solution to Offline Double Spending | ||
| To efficiently prevent the fraudulent use of tickets within the Nym network, a two-tiered solution is in place that combines (1) the immediate detection of double-spending attempts at the level of individuals ingress Gateways and (2) subsequent identification and blacklisting of offending clients at the Quorum level. |
| To efficiently prevent the fraudulent use of tickets within the Nym network, a two-tiered solution is in place that combines (1) the immediate detection of double-spending attempts at the level of individuals ingress Gateways and (2) subsequent identification and blacklisting of offending clients at the Quorum level. | ||
|
|
||
| ### Entry Node Implementation: Real-Time Ticket Unspending Validation | ||
| Each spent zk-nym credit contains as an attribute a unique serial number, which is revealed in plaintext to the respective ingress Gateway. Each Gateway has a copy of a [Bloom Filter](https://www.geeksforgeeks.org/bloom-filters-introduction-and-python-implementation/) - on receiving a credit, it will check against its copy of a local database to check whether this serial number has already been seen. If so, it rejects the credit as being double-spent and the client's connection request is rejected. If not, it will add the serial number to its local DB. |
|
|
||
| > Since each time a zk-nym credential is rerandomised its serial number is changed, the serial number being shared in no way identifies a client or user. | ||
|
|
||
| Each Gateway will periodically share their serial numbers with the Quorum and refresh their copy of the Bloom Filters from the Quorum, in order to refresh the global list shared by all ingress Gateways and the Quorum. See the step below for more on this. |
| ``` | ||
|
|
||
| ## Why not spend the entire credential at once? | ||
| This is to account for the need for a client to change their ingress Gateway, either because the Gateway itself has gone down / is not offering the required bandwidth, or because a user might simply want to split their traffic across multiple Gateways for extra privacy. |
There was a problem hiding this comment.
the ingress Gateway vs Entry Gateway question
| ## Why not spend the entire credential at once? | ||
| This is to account for the need for a client to change their ingress Gateway, either because the Gateway itself has gone down / is not offering the required bandwidth, or because a user might simply want to split their traffic across multiple Gateways for extra privacy. | ||
|
|
||
| This means that clients are not tied to particular Gateways they have 'spent' their entire subscription amount with; if the ingress Gateway goes down, or the client simply wishes to use another ingress Gateway, the user has multiple other zk-nym credits they can use that account for their remaining purchased bandwidth. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial docs for zknyms
(once decided upon naming) change 'tickets' and 'ticketbook' insplit it out and in here: https://github.com/nymtech/nym/tree/max/update-nym-cli-terminologynym-clicommands <== checking into how much this needs to touch as we use 'tickets' all over, checking if I can just change stuff incommands/andtools/nym-cliand whether that pulls in e.g. logging from elsewhere.. NBgenerate-ticket()is incarmellobranch, would need to pull in from here. Other changes are currently uncommited in theecash-docsbranch. NBB there is more to pull in as well in this bracnh https://github.com/nymtech/nym/pull/4827/files#diff-397393b23836f0071b8f52282ce73342a8812a55704dae034a06f93bb37cd53freplace command output in docs with newrebaseThis change is