Decentralized VPN Protocol Secured by EigenLayer

[prampey]

Hello folks, here’s an idea that I thought was very interesting:

A Decentralized VPN Protocol secured by EigenLayer, focusing on data privacy, performance and cost-effectiveness. The proposed protocol aims to enable users to access a decentralized VPN network using the computational resources available off-chain (provided by Ethereum validator nodes) while ensuring privacy and security.

Protocol workings

The Decentralized VPN Protocol would be implemented in the following stages:

1. Node Initialization: Ethereum restakers that opt into the Decentralized VPN Protocol would run a Docker container on their nodes to offer bandwidth and minimal computational resources to form a decentralized VPN network.
2. Connection Request: Users send connection requests to the Decentralized VPN Protocol smart contract, specifying their desired VPN server location and other preferences.
3. Node Selection: The smart contract selects an appropriate participating node based on the user’s preferences, taking into account factors such as server location, load, and reputation.
4. Secure Connection Establishment: The user establishes an encrypted connection with the selected participating node, ensuring that their internet traffic is securely tunneled through the node.
5. Traffic Routing: The participating node routes the user’s traffic through the decentralized VPN network, allowing the user to access the internet with enhanced privacy and security.
6. Connection Termination: When the user disconnects from the VPN service, the connection with the participating node is terminated.

Protocol Participants

The proposed Decentralized VPN Protocol will consist of the following participants:

• EigenLayer restakers: Ethereum validator nodes responsible for providing bandwidth and computational resources for the decentralized VPN network. Participating nodes are compensated for their resources and contribution to the network.
• Users: Individuals and entities that connect to the decentralized VPN network in exchange for a usage fee.

Compensation for Bandwidth

The Decentralized VPN Protocol restakers would receive ETH compensation for the bandwidth they provide to the protocol. This compensation would incentivize nodes to participate in the Decentralized VPN Protocol and ensure the sustainability of the network. This compensation would come out of the pockets of the users. (hopefully in a very cost efficient manner)

Slashing to maintain Data Privacy and Security

The Decentralized VPN Protocol would impose a slashing penalty for participating nodes that do not demonstrate a strong commitment to preserving user privacy, security and connection quality. This could be achieved through a reputation system that takes into account factors such as node uptime, connection quality, and user feedback. By negatively incentivizing nodes to maintain high privacy, security and performance standards, the protocol ensures a reliable and trustworthy VPN network.

In summary, the Decentralized VPN Protocol secured by EigenLayer aims to provide a secure, private, and affordable VPN solution by leveraging the power of Ethereum validator nodes. Users benefit from enhanced online privacy, security and a wide variety of geographical server locations, while participating nodes are compensated for their bandwidth, as well as their commitment to preserving user privacy and security.

I’m no expert in many of these topics but it seemed like a VPN service fit the bill for a light Actively Validated Service. What do folks think?

[CheCoinMaxi]

That’s a really good idea ! It would be like a Nym Network, but built on top of Eigen Layer.

I must say I’m a big fan of mixnets. The point of a VPN is to hide informations ; therefore, using a single nord, choosed by an Ethereum smart contract wouldn’t be safe enought for our data.

If any entrepreneur is excited by this idea, it might be a good alternative to mainstream centralized VPNs…

[Vorobey]

great idea
hope to see answer from the team about it

[prampey]

Thanks! Mixnets sound very interesting. Some of its features like multi-hops and message shuffling will definitely help to strengthen user and validator node privacy.
I’m looking to build this but would appreciate more feedback from the community!

[CheCoinMaxi]

If I can help you in any way, don’t hesitate

[ParitoR]

its good idea… web3 need this kind of project…

[Elon_Musk]

wow, lets see how it will be look like… :

[whiskey]

This is certainly interesting idea .
I doubt about value that a decentralized VPN network can generate for eth validators to justify risking their ETH for securing and providing service for this network .

[CheCoinMaxi]

It’s all about money. VPN companies print tons of cash everyday. If restaking 32 ETH can earn you $10k a year (for ex) with very low risk, it’s a good deal

[austin_king]

Hey prampey appreciate the post!

Great idea – a lot of room for exploration here.

@prampey

1. Node Initialization: Ethereum restakers that opt into the Decentralized VPN Protocol would run a Docker container on their nodes to offer bandwidth and minimal computational resources to form a decentralized VPN network.

One concern I have here is that the additional bandwidth demands placed on validators could cause them to fail in their other responsibilities. For example, if I was watching a 4k video through this VPN and a node had to relay all of that data, it’s possible that it’s network I/O would become overly congested and it would be unable to handle other messages related to another middleware service or the actual core Ethereum protocol, leading to their stake getting slashed because the node capacity could not keep up with the bandwidth demands. However, one possible solution here is that this could be an ultra-light middleware service that doesn’t even have to run on the same machine as the actual ETH node – it’s possible that this could be designed just so that the stake is available to be slashed in case this participant misbehaves, but they actually could operate the VPN node in an entirely independent machine to prevent congestion. It would be possible to create an offchain series of receipts for services provided with schemes similar to the lightning network to do all accounting independent of the core ETH node.

@prampey

2. Connection Request: Users send connection requests to the Decentralized VPN Protocol smart contract, specifying their desired VPN server location and other preferences.

You could do this, but it also risks a lot of on chain txs making it extremely expensive. What you could do instead is just keep this registry in a smart contract, and allow users to top up balances in the smart contract (just put .1 ETH to last a year) and anytime a user wants to spend their balance they could make requests to VPN servers registered in the list directly over the internet (no need for on chain txs) and just attach a micropayment via a state channel and consistently make micropayments to keep the connection going.

This would also make the “connection termination” part easy as it simply consists of no longer sending micropayments.

@prampey

The Decentralized VPN Protocol would impose a slashing penalty for participating nodes that do not demonstrate a strong commitment to preserving user privacy, security and connection quality. This could be achieved through a reputation system that takes into account factors such as node uptime, connection quality, and user feedback. By negatively incentivizing nodes to maintain high privacy, security and performance standards, the protocol ensures a reliable and trustworthy VPN network.

From a game theoretic perspective this sounds like the hardest part to implement. A few questions:

1. How can you prove somebody leaked your data? Because this would need to be provable on L1 in order to slash people
2. Node uptime – you could have some agent responsible for just probing uptime in the network to ensure that actual end users are consistently connected with high uptime nodes.
3. What if there was a way to do dynamic routing? Maybe you don’t even need to penalize people for having spotty service actually, if you have a way to dynamically just route their traffic to somebody else then it might be possible to incentivize high uptime just through compensation, not disincentivize it through slashing.

Overall great post! Love to see cool ideas posted like this.

[amir55]

For all things ,need high speed internet but who owns the internet,how internet can be decentralized

[CheCoinMaxi]

1. How can you prove somebody leaked your data? Because this would need to be provable on L1 in order to slash people

I’d need to deep dive on Nym, but I’m pretty sure mixnet nodes can’t leak data because it’s encrypted

3. What if there was a way to do dynamic routing? Maybe you don’t even need to penalize people for having spotty service actually, if you have a way to dynamically just route their traffic to somebody else then it might be possible to incentivize high uptime just through compensation, not disincentivize it through slashing.

Yes, no one would put ETH at risk if you can get slashed because of low bandwidth. I strongly agree with this last point

[prampey]

Hi @austin_king, thanks!
Lot of cool ideas here to think about.

@austin_king

anytime a user wants to spend their balance they could make requests to VPN servers registered in the list directly over the internet (no need for on chain txs)

Agreed. State channel micropayments are cheap and efficient. Another added benefit here is in case we need to tier out nodes (because nodes with higher speeds need to earn better rewards), a user can simply send larger micropayments to avail ‘premium’ services.
However, just wondering how to set up prices for bandwidth usage. The goal here is to minimize volatility for end users (Imagine your monthly VPN subscription suddenly going up in price). This is why I’d prefer not to let nodes set their own prices. Instead, charging a base fee per GiB for each tier of nodes (based on speed) seems like a simple and straightforward solution. As to the value of this ‘base fee’, need to dig in more on how to find a free market rate.

@austin_king

• How can you prove somebody leaked your data? Because this would need to be provable on L1 in order to slash people
• Node uptime – you could have some agent responsible for just probing uptime in the network to ensure that actual end users are consistently connected with high uptime nodes.
• What if there was a way to do dynamic routing? Maybe you don’t even need to penalize people for having spotty service actually, if you have a way to dynamically just route their traffic to somebody else then it might be possible to incentivize high uptime just through compensation, not disincentivize it through slashing.

Exciting questions.

1. Like CheCoinMaxi pointed out, we’ll be routing only encrypted traffic through these nodes so they cannot access the data or leak it. However, the starting node in a circuit (which interacts with the user first) can store user-identifiable information like IP address and location. Adding in multihops and shuffling nodes in a circuit (like mixnets) should help mitigate this and prevent the need for slashing.
2. Agreed. We could simply ping nodes and run speed tests with agents to make sure nodes are performing as expected in their SLA. I believe this can be proved on L1 for slashing. Check out Proof of bandwidth from Witness Chain.
3. I’ve been thinking about the same. Seems quite feasible from an algorithmic perspective. However it is important to note if something is not worth slashing stake for, it does not technically belong on EigenLayer.
   The plus side of dynamic routing is that now anyone can participate in the protocol. Millions of mobile and desktop users can share their bandwidth to earn. Dynamic routing will simply find the best performing circuit of nodes.
   However, from an end user UX perspective, a sudden IP switch, say during streaming videos might cause servers to flag suspicious activity. Need to test how big of a problem this could be.

Appreciate your thoughts and feedback! Will keep digging more.

[austin_king]

@prampey

Agreed. State channel micropayments are cheap and efficient. Another added benefit here is in case we need to tier out nodes (because nodes with higher speeds need to earn better rewards), a user can simply send larger micropayments to avail ‘premium’ services.
However, just wondering how to set up prices for bandwidth usage. The goal here is to minimize volatility for end users (Imagine your monthly VPN subscription suddenly going up in price). This is why I’d prefer not to let nodes set their own prices. Instead, charging a base fee per GiB for each tier of nodes (based on speed) seems like a simple and straightforward solution. As to the value of this ‘base fee’, need to dig in more on how to find a free market rate.

One possible model here is to simply start a SaaS company on top of the network that charges simple flat rates for users. The network itself could have dynamic pricing at the raw protocol level and the SaaS company could just charge a flat rate, improving UX and earning profit from the spread between (flat rate - actual network fees). This could also accelerate adoption of the network through providing nice access utilities like an iPhone app because the SaaS company could build all of that.

@prampey

Exciting questions.

1. Like CheCoinMaxi pointed out, we’ll be routing only encrypted traffic through these nodes so they cannot access the data or leak it. However, the starting node in a circuit (which interacts with the user first) can store user-identifiable information like IP address and location. Adding in multihops and shuffling nodes in a circuit (like mixnets) should help mitigate this and prevent the need for slashing.
2. Agreed. We could simply ping nodes and run speed tests with agents to make sure nodes are performing as expected in their SLA. I believe this can be proved on L1 for slashing. Check out Proof of bandwidth from Witness Chain.
3. I’ve been thinking about the same. Seems quite feasible from an algorithmic perspective. However it is important to note if something is not worth slashing stake for, it does not technically belong on EigenLayer.
   The plus side of dynamic routing is that now anyone can participate in the protocol. Millions of mobile and desktop users can share their bandwidth to earn. Dynamic routing will simply find the best performing circuit of nodes.
   However, from an end user UX perspective, a sudden IP switch, say during streaming videos might cause servers to flag suspicious activity. Need to test how big of a problem this could be.

1. Wouldn’t you ultimately need to reveal the final request though so that the exit node can actually make the request? Also great to thinking about second order data leaks though like where the request even originated and the user’s IP. I support the mixnet idea.
2. Ya I first heard about Witness Chain in the EigenLayer kickoff community call! Very cool, and possibly a great tool for a system like this.
3. Yup totally true in regards to all of your comments here.

@prampey

Appreciate your thoughts and feedback! Will keep digging more.

100% – if you end up building this out further please post any additional resources as an update on this thread as I would be curious to stay in the loop.

best of luck!

[CheCoinMaxi]

However, from an end user UX perspective, a sudden IP switch, say during streaming videos might cause servers to flag suspicious activity. Need to test how big of a problem this could be.

That’s why Nym mixnet is using gateways. The data you send to the mixnet, and the data your receive from the mixnet both go throught the gateway. Data are encrypted, so the gateway can’t do anything with it.

You can theorically change your gateway as you want, but most of people will keep using the same gateway. At least, they won’t change during their session. As you said, this feature can be interesting to not be flagged by servers (hello Facebook…)

Can we follow you somewhere ?

[rsproule]

@prampey

The Decentralized VPN Protocol would impose a slashing penalty for participating nodes that do not demonstrate a strong commitment to preserving user privacy, security and connection quality. This could be achieved through a reputation system that takes into account factors such as node uptime, connection quality, and user feedback. By negatively incentivizing nodes to maintain high privacy, security and performance standards, the protocol ensures a reliable and trustworthy VPN network.

One key consideration for any Eigenlayer Service is that individual “tasks” should be objectively attributable on chain.

@https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/AVS-Guide.md#key-design-considerations

Services Slash Only Objectively Attributable Behavior:
EigenLayer is built to support slashing as a result of an on-chain-checkable, objectively attributable action. An AVS SHOULD slash in EigenLayer only for such provable and attributable behavior. It is expected that operators will be very hesitant to opt-in to services that slash for other types of behavior, and other services may even choose to exclude operators who have opted-into serving one or more AVSs with such “subjective slashing conditions”, as these slashing conditions present a significant challenge for risk modeling, and may be perceived as more dangerous in general. Some examples of on-chain-checkable, objectively attributable behavior:

• double-signing a block in Ethereum, but NOT inactivity leak;
• proofs-of-custody in EigenDA, but NOT a node ceasing to serve data;
• a node in a light-node-bridge AVS signing an invalid block from another chain.

While it is not disallowed (open innovation!) to have non-objective slashing conditions, like the reputation system, or an inactivity leak, or a speed test/ping style strategy. I imagine it would be difficult to get stakers to opt into such strategies because of their inability to model the slashing risk.

Overall, very cool idea since you can leverage the global distribution of the Eth validator set which is great for a VPN, but there are def some open questions around what behavior you would slash in this system.

[wilson17]

Lets see how it will work,hoping to be successful project

[capkaidiyer8]

It has to be built on Eigen!

[qianya]

• Traffic Routing: The participating node routes the user’s traffic through the decentralized VPN network, allowing the user to access the internet with enhanced privacy and security.

[Dimitry]

That’s exciting. VPNs are definitely a big market, and often operate in a very opaque way.

To me, the main challenges will be 1. bandwidth and 2. If slashing is implemented on chain, there must be a way to prove that some nodes do not follow the rules. This would require a system like ethereum’s consensus, but that allows to prove one’s lack of commitment or liveliness.

If anyone has ideas as to how to implement that I’d love to help.