-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixnet PoC #273
Comments
Before plugging mixnet into our simulation or our node implementation, we need to decide the strategy how to use mixnet in gossipsub. During our off-site, we had considered using mixnet only for the first hop of gossipsub. A good news is that Lighthouse (Ethereum Rust implementation) also uses the same strategy, if this slide is true: https://github.com/ChainSafe/lighthouse/blob/nym/libp2p-nym-integration-demo.pdf
|
The simplest approach would be:
Basically, we can implement a libp2p-mixnet transport, as ChainSafe did: https://github.com/ChainSafe/rust-libp2p-nym. But, for our sim app, it seems that we need to implement another |
In case of using simulation, you are right about the network interface. This could be achieved by introducing new
|
Are we sure we want to introduce this simulation wise? TLDR: Why should we actually implement mixnet delivery in the simulation app? |
I agree. Last Monday, I thought that we need a certain tool to measure the latency/bandwidth amplifications in various environments because we don't have a specific strategy how to adopt mixnet to our architecture yet. I thought the simulation could be a great tool for this purpose. However, after studying about simulation last week, I now guess that it may also take some time to extend our simulation for this purpose, because our simulation is currently for analyzing Carnot consensus, not for measuring performance according to the internal tech stack or architecture. In order to analyze the behaviour of Carnot under mixnet, it would be enough to add a Instead, in the perspective of evaluating mixnet, now I think it would be quite straightforward to quickly implement a mixnet transport (PoC) for libp2p. With it, we may be able to simply run multiple nodes (even on a local machine) and measure performance comparing with the regular libp2p. |
Indeed, also the mixnet protocol would probably have to be implemented as a transport itself anyway. So to me it sounds about right. |
I remember seeing that nym mixnet uses a nym identifier for nodes. If it is not a security/privacy breach. Open questions:
|
I'm just sharing the Nym architecture that I've studied so far from their source code. Please note that some informations may be incorrect. This diagrams can answer some of my questions: Q1: How do senders get information about mixnodes to construct Sphinx packets?
Q2: Why does Nym introduce the layered mixnet topology?
Q3: Isn't exposing the topology on the Nyx blockchain a security flaw?
Q4: Any mechasim to resolve a IP address from a Nym address?
Q5: How do mixnodes communicate with each other?
From this, we have some topics that we need to thinking about, when desiging our architecture: T1. Constructing mix routes (for now, not considering the layered topology, for simplicity).
T2. Associating
T1 has a higher priority, compared to T2, in my opinion. |
Amazing diagram and explanation! @youngjoon-lee 👍 |
Although these topics aren't resolved yet, I just published a draft design of mixnet integration, which uses mixnet only for the first hop of gossipsub: #288. |
Although I didn't read the full source code of paritytech/mixnet and paritytech/substrate#14207 yet, they store the topology (IP addr and pubkey) of mixnodes on the blockchain, so that mixnet clients can construct packet routes using that information, as Nym mixnet does. The difference with Nym is that they don't have the "layered" topology. They choose |
So yeah, having just the mixnodes addresses onchain should be no problem. Issues will be coming when mixing them out with the nomos nodes. We really need to think about this. |
Exactly. First of all, the issue is that we don't have a shared storage (like blockchain) to store the topology, even if we don't think about privacy. Instead, I'm thinking about using DHT for advertising mixnode informations: #288 (comment). |
Why not? If necessary can't we require that information to be available like we assume the stake distribution is?
Nodes have to communicate their address to be able to be contacted, I don't think there's any way around this. If the address is shared with part of the network or the whole network I don't think makes any difference (once the information is out you can probably do little to restrain who has access to it). What we might be interested in doing is avoid node id - ip address linkability |
True, but I think it depends on which layer we're going to implement the mixnet in, because the state (synced by consensus) will be in upper layers of the networking. Nevertheless, we can also have the shared topology to be injected from the upper layer to the networking layer (mixnet). As you said, if we really need the shared topology, I believe we can design any way possible.
I now have the same thought. As long as we avoid |
Yes, I think that's the key. NodeId <> IP unlinkability. The IPs in the system are known to everyone. What are your thoughts on NodeID-IP unlinkability? |
@alvatar Thank you. I'm pretty sure that we can unlink NodeId with IP that is needed for mixnet. In perspective of mixnet, NodeId is not necessary. What we need for mixnet is IP and public keys (so that we can encrypt Sphinx packets for next hops). Here, we should use public keys that aren't associated with NodeId (or staking accounts). |
This is the main question. If we can leverage to make the network resolve the Ip without the protocol knowing the exact address but the networkId (related to the nodeId) in a decoupled way. Then we could use the mixnet to send packages directly to nodes instead of broadcasting (this is something to consider for the future but it is not the main concern atm). But it is difficult and we have no answer atm. Correct me if I'm wrong @youngjoon-lee ! Side note: I'm refering to have a distributed network layout where nodes do not really know how to reach other node directly but they can route the packages through the mixnet with a clear destination using network identifiers instead of Ip addresses. We had some conversations about this. But again, do not even know if its possible, neither is the focus now. Just leaving this here for future review. |
Yes. So far, I haven't found any solution for this. Even without thinking about the mixnet, I think it's not easy. Let's say we derive The scenario that we're talking about is sending a But then, the node operator can aware that Even if we adopt mixnet, I think this doesn't change, as long as we associate But yeah, this is not the main topic for now, as you said. |
@danielSanchezQ @zeegomo @al8n @bacv I'm trying to measure the latency (block time) amplification of the mixnet integration. Also, thinking of having a call with you guys about these PRs if necessary. |
I think we should rebranch from master and have a branch just for this feature were we can add any other mixnet related PR. We would have to rebase that branch from master to keep it updated but it is better than falling behind too much. |
Yeah. I just created the |
The idea of rebasing was for keeping it up to date with master. The PRs should be squash-merged on it instead of main 😅 |
NOTE: This topic is being developed in the
mixnet
branch.What needs to be done
Expecting that the mixnet (potentially Nym mixnet) achieves most of network privacy requirements that we want,
Expected outputs
Resources
Protocols
The text was updated successfully, but these errors were encountered: