We have recently tackled a challenging technical project for Twilight, a privacy layer on Solana blockchain, specifically focusing on securing RPC node access. The problem is that RPC nodes, being centralized, can collect data such as IP addresses, UserAgents, and cookies, which can be used to analyze and track transactions across regions or countries, and this contradicts the essence of Twilight, so they had to be prevented from it.
While VPNs and proxies can offer some privacy, they still reveal traffic direction to the service providers. To avoid this, we have designed a privacy layer to prevent data collection and analysis from individual nodes. Our solution involves creating two types of nodes: one for receiving user traffic and one for sending traffic to the network. We use a protocol that hides the user and requests destination data by encrypting it.
We need to manage encryption so that only the client and the outgoing node have the decryption keys. To ensure anonymity, we have implemented an anonymous key exchange system with a key registry that distributes public keys to clients. This allows clients to encrypt destination information without revealing it to the incoming node.
To enhance security and decentralization, we’ve chosen a distributed DePIN infrastructure which involves various participants running nodes. We have also introduced a validator node to ensure data reliability, manage rewards, and rate node performance. The validator will oversee the stability and availability of services and handle key storage.
We chose the VLESS protocol for node communication due to its minimal blocking by traffic analyzers. However, we’ve modified it to support additional encryption. This protocol, combined with asymmetric encryption between the client and outgoing node, fits well with HTTPS and minimizes tracking markers.
Let’s have a look at what we’ve come up with.
While VPNs and proxies can offer some privacy, they still reveal traffic direction to the service providers. To avoid this, we have designed a privacy layer to prevent data collection and analysis from individual nodes. Our solution involves creating two types of nodes: one for receiving user traffic and one for sending traffic to the network. We use a protocol that hides the user and requests destination data by encrypting it.
We need to manage encryption so that only the client and the outgoing node have the decryption keys. To ensure anonymity, we have implemented an anonymous key exchange system with a key registry that distributes public keys to clients. This allows clients to encrypt destination information without revealing it to the incoming node.
To enhance security and decentralization, we’ve chosen a distributed DePIN infrastructure which involves various participants running nodes. We have also introduced a validator node to ensure data reliability, manage rewards, and rate node performance. The validator will oversee the stability and availability of services and handle key storage.
We chose the VLESS protocol for node communication due to its minimal blocking by traffic analyzers. However, we’ve modified it to support additional encryption. This protocol, combined with asymmetric encryption between the client and outgoing node, fits well with HTTPS and minimizes tracking markers.
Let’s have a look at what we’ve come up with.
Architecture
This is a distributed node system that ensures resource availability while maintaining user anonymity.
To achieve high anonymity, user traffic passes through at least two nodes. The incoming node handles user authentication but does not know which resource the user wants to access. The outgoing node knows the destination of the traffic but does not know the originating user. As a result, analyzing logs or traffic from any node in the network cannot reliably identify which user accessed which resources.
Data Transferring Protocol
To ensure high network speed while preserving anonymity, different data transmission protocols are used at various network levels. Between the client and the incoming node, we use the VLESS protocol with xtls-rprx-vision flow. This introduces additional 150 ms for the handshake but prevents data leaks and provider blockages (see the VLESS protocol specification for details). HTTP/1.1 connections are most affected by this delay, whereas for HTTP/2.0 and other advanced protocols handshake costs are incurred only once, with subsequent traffic using the established connection.
Between the incoming and outgoing nodes, we use VLESS without additional TLS encryption. Proxying adds up only 3-4 ms to an average browser request, which is negligible compared to the handshake and server delays.
The outgoing node connects directly to the resource, resulting in the same time costs as a browser without a proxy. Therefore, no additional time is added for using this technology.
Additionally, there are no other extra costs for requests within the system.
Between the incoming and outgoing nodes, we use VLESS without additional TLS encryption. Proxying adds up only 3-4 ms to an average browser request, which is negligible compared to the handshake and server delays.
The outgoing node connects directly to the resource, resulting in the same time costs as a browser without a proxy. Therefore, no additional time is added for using this technology.
Additionally, there are no other extra costs for requests within the system.
Analytics and Node Selection
To ensure availability and high performance within the VPLL (Virtual Privacy Proxy Layer), we collect anonymous telemetry from each network participant. This data is validated, aggregated, and stored on the Solana blockchain. This decentralized approach helps select the most suitable incoming and outgoing nodes for each client.
Validators review and filter the data from all nodes, discarding any incorrect information, such as size of received or sent data, number of clients, etc.
Validators review and filter the data from all nodes, discarding any incorrect information, such as size of received or sent data, number of clients, etc.
Key Storage
When registering on the network, all outgoing nodes must submit their public keys. These keys are used by clients to encrypt the resource they want to access. This process breaks the link between the outgoing node and the client at the validator level. No outgoing node will know which specific client received a public key. Additionally, clients can obtain all available keys from the validator without using them. This setup protects users from potential log leaks at the validator.
Conclusion
In summary, our approach to enhancing blockchain privacy through a distributed node system ensures both high performance and robust anonymity. By employing multiple protocols and key management strategies, we effectively safeguard user data from potential breaches and unauthorized analysis. Our use of VLESS for secure data transmission, coupled with the decentralized key storage and data validation, provides a comprehensive solution for maintaining privacy and efficiency. As we continue to develop and refine this system, our goal remains to deliver a secure, anonymous, and reliable environment for blockchain interactions.
We are pleased to partner with Twilight on this journey and wish the project team great success.
We are pleased to partner with Twilight on this journey and wish the project team great success.
