Cosmos Ecology-DVPN White Paper (4) Sentinel dVPN Architecture Overview

A centralized VPN architecture consists of multiple intermediate servers that manage user permissions and establish user connections to VPN nodes. This centralized architecture requires a high reliance on these intermediate servers, which poses a risk to network resiliency due to multiple points of failure and multiple points of attack. Downtime in a centralized VPN network can be attributed to one or more of these components not functioning properly and can lead to a decrease in user experience and satisfaction.

Sentinel dVPN framework offers incredible resiliency and security compared to any consumer-grade VPN. The Sentinels architecture minimizes the number of intermediate servers and dependencies. In addition to the account management and creation system, which is entirely on-chain, the process of querying available servers also takes place on-chain. A blockchain hosted as an application will run 24/7 without disruption, and the validator infrastructure for the global community is decentralized (immune to 1, 2 or 3 data center failures) so that application uptime and User experience will be far superior to centralized competing products.

A major contributor to Sentinel's architectural resiliency is the decentralized distribution of computing power, which will be required to run Sentinel Hub and Sentinel Zone. The computing power required for the operation of the Sentinel dVPN ecosystem is not provided by any centralized organization, but is provided by expert "validated" organizations, distributed around the world, with highly redundant systems with significant bandwidth throughput and normal operation hours.

While Sentinel's architecture ensures that the user's anonymity is not compromised by the application itself, the use of Sentinel's upcoming relay network is necessary to ensure that the user is completely anonymous from the point of view of the exit node. The Sentinel Relay Network will allow users to connect to "relay nodes" through a series of tunnels, ensuring that users do not interact directly with exit nodes.

Sentinel's own "Proof of Bandwidth" protocol ensures a transparent and untrusted measure of bandwidth provided by service providers (community-based nodes) to end users. The “Bandwidth Provability” protocol integrated with the Sentinel blockchain provides a clear track record of the quality of bandwidth services provided and creates a certain level of trust among all participants. This data is later used to determine whether the node meets the required service level agreement to avoid penalties.

On-chain query

The implementation of Sentinel's "on-chain" query system is one of Sentinel's most important technical achievements and ensures a highly resilient and decentralized architecture.

With Sentinel's dVPN architecture, connections between users and exit nodes can be established directly without the need to connect to an intermediate server (such as a discovery node's master node) controlled by application developers or third parties. This is achieved by utilizing the blockchain as a ledger of "node queries", with nodes having the ability to interface and store information related to node attributes and connection instructions. The user's Sentinel-based dVPN application will populate the list of available servers by simply querying all available dVPN nodes by reading data from transactions in Sentinel's dedicated dVPN zone. Since authentication and identity management already occurs on-chain, the only point of failure in the Sentinel dVPN dApp structure theoretically (other than cyber sybil attacks) becomes a potential consensus security failure at the chain level. The only way to compromise Sentinel dVPN adoption is to compromise validator-driven consensus.

Mainstream VPN applications usually control the exit node, but also control and utilize intermediate query servers that exist between the exit node and the user, making the purpose of the relay network redundant since the original user's IP is easily visible.

However, the "on-chain query" architecture means that users only need to communicate directly with the chain, not any other centralized server that might record interactions.

relay network

A robust network of relays is an important aspect of any end-to-end dVPN solution, which fully upholds user privacy. While neither the creator of a Sentinel-based dVPN application nor any Sentinel-based participant, the Sentinel blockchain can access any personal information associated with the user (such as IP addresses), without a relay network, hosted on An exit node in the Sentinel ecosystem has access to a user's IP address. While dVPN apps have the ability to provide relevant evidence, without logs user browsing and metadata collection/storage centralized to the app developer, it is currently impossible to prove that logs are not collected by exit nodes or stored locally on the host device.

To describe the relay network in simpler terms, the connection between a user and an exit node can be likened to a user making a cellular phone call to a third party. If the user's intent is to prevent third parties from seeing the user's number in Caller ID, the user will have to use their friend's device as a relay to block the user's phone number. The user would then have to call the friend who kept the user waiting and dial the third party's number before merging the two calls, thus connecting to the third party without exposing the user's data.

Similar to the cell phone intermediate caller example, the relay network consists of "relay nodes". A relay node is operationally different from an exit node because the exit node communicates directly with the user (in the absence of a relay network) and also communicates with the web-server on the internet. Relay nodes, on the other hand, only communicate with users, other relay nodes, or exit nodes.

A strong relay network includes:

• large number of participants
• strong governance
• Multiple network integration

The use of Sentinel-based relay systems will primarily target more privacy-conscious users who are willing to sacrifice internet speed to improve privacy.

The benefits of a relay network can only be realized when a large number of unique participants start hosting relay or exit nodes on the network. If, at any point in time, an entity controls a significant portion of the network, it becomes possible for that entity to de-anonymize users through a simple but effective "man in the middle" (MITM). One of the main goals of relay networks is to ensure that relay nodes cannot identify whether they are tunneling to a user or another relay node. If a user occurs routing traffic through the attacker's relay node as well as the exit node, the attacker is able to correlate the user's IP address and in turn determine the user's original request for information flow that is not simply another relay participant.

The importance of having a distributed network in the relay network to prevent man-in-the-middle attacks is shared by the Bitcoin ecosystem, mining is designed to prevent 51% attacks. If an entity controls 51% of the Bitcoin network mining hash rate, then that entity has the ability to disrupt the network, attacking the integrity of the network by performing a double spend. Bitcoin attempts to combat these monopoly risks in the mining ecosystem through its incentives. This incentive mechanism rewards miners based on their participation in helping discover and validate newly created blocks on the network. If Bitcoin is a voluntary network with no economic design, its security is likely to be compromised. A powerful entity with access to important hardware infrastructure can easily gain majority control of a mining network, an example of a volunteer-driven network is the TOR network. In the TOR network, the participation of relay nodes and exit nodes is not incentivized. Instead, they are encouraged to serve simply out of mutual respect for the spirit behind decentralization. Industry experts are concerned that the TOR network has been compromised by entities that control a large number of TOR relays and exit nodes. At this time, there are approximately 6,000 TOR relay nodes on the network, with an average of 6 million daily active users. This clearly shows the limitations and risks of volunteer-based networks.

The success of the Sentinel relay network is entirely dependent on the number of unique participants. Attracting these participants requires some level of incentive through mechanisms on the network.

Bandwidth-Based Proof

In a truly decentralized network, the allocation of bandwidth shares a common problem with hash generation by miners in a proof-of-work (PoW) network. The issue revolves around the ability of service providers (or miners in PoW cases) to abuse or falsify actual workloads. One of the main responsibilities of miners on the Bitcoin blockchain is to confirm the actual work (or hashes generated) of other miners and ensure that no one is blocking rewards by exploiting the system. Likewise, in the case of bandwidth allocation on a decentralized P2P network, a robust architecture is needed to prevent bad actors who intend to "spoof" the amount of bandwidth provided.

The need for a provable solution for bandwidth allocation networks can be illustrated by an analogy, the frustrating experience that many mobile phone users have with their network operators regarding their international roaming charges. Most roaming plans offered by network operators have limits on the amount of bandwidth that can be used, and sometimes even bill the user for the total amount of bandwidth used. It's common to hear people say they don't trust their carrier at all because they think they've been overcharged and don't understand how bandwidth consumption for roaming charges is calculated.

Provability of bandwidth distribution is important not only for network-centric use cases, but also for storage and compute-centric use cases, as there is a lot of bandwidth utilization involved. One of the key goals of the Sentinel ecosystem is to develop and implement the first bandwidth provable protocol, or "Proof of Bandwidth," to allow trustless bandwidth sharing. A blockchain framework for building decentralized VPN applications, the scope of the protocol goes beyond decentralized VPN applications built on Sentinel, with the ability to integrate with other distributed p2p resource sharing networks and even mainstream applications.

The first prototype implementation of Sentinel’s proof-of-bandwidth protocol took place on the Ethereum chain, backed by an external network of distributed masternodes. These masternodes will observe and measure the allocation of bandwidth between service providers and users, and then write certain properties of the session, such as duration and bandwidth consumed, to the Ethereum blockchain. This data is then retrieved by the dVPN app's billing mechanism to generate an invoice that the user must pay. This prototype architecture works as planned, but cannot be called truly decentralized due to the need for an additional network of masternodes.

The implementation of the bandwidth provable protocol currently being built on Sentinel is based on the Cosmos/tendermint network and involves generating "bandwidth signatures" from both the service provider and the user. These bandwidth signatures are essentially messages consisting of the bandwidth transmitted by the P2P connection over a preconfigured period of time. Service providers and users each generate their own signatures, each signed with their own private key, and these signatures are then stored on-chain for retrospective use. If there is a discrepancy (within a preconfigured time) between bandwidth exchange requests from the user and the service provider, the connection will be terminated due to the presence of at least one malicious actor in the exchange.

Bandwidth signature variables determined by dVPN application developers:

• The time period during which each bandwidth signature was generated
• Threshold Percentage for User and Service Provider Signature Differences

Example: Sentinel "Proof of Bandwidth" protocol integrated with "XYZ" dVPN built on Sentinel framework. The time frame for signature generation is 10 minutes, and the difference threshold is 10%. During the first 10 minutes of dVPN usage, the service provider enters an on-chain signature representing 1.05 GB of bandwidth provided, and the user enters a signature representing 1 GB of bandwidth used. The difference between the two signatures falls within the 10% threshold, allowing established connections to continue without interruption.

In the next session, the service provider's signature represents the 2 GB provided and the user's signature represents the 1.5 GB used, and the major difference between the two signatures exceeds a threshold, causing the connection to be terminated.

Payment Models and Escrow

The monetization of peer-to-peer bandwidth allocation allows for the use of a more dynamic payment model than is typically seen in the traditional VPN industry. In addition to the usual "prepaid" systems (where users buy subscription services for a fixed period of time), bandwidth providers (node hosts) also have the ability to set their own pricing per unit (GB) of bandwidth consumed.

dvpns running on the Sentinel ecosystem will be able to pay cosmos IBC through traditional fiat-based options such as credit cards as well as a number of cryptocurrencies supported by Sentinel. However, bandwidth pricing through both models will be primarily denominated in fiat.

It is important to note that while payment for bandwidth can be made in cryptocurrencies or fiat, the fees paid by the bandwidth provider (node host) for the infrastructure hosting the node are almost always denominated in fiat. Infrastructure-related costs include cloud computing costs as well as power costs (if node hosts use a self-hosted physical setup) and hardware costs.

Two key payment models available to dVPN users in the Sentinel ecosystem include:

• Live - dVPN Node Hosting on Sentinel uses a live payment model that allows users to pay per GB of bandwidth consumed. In this payment model, node hosts also have the ability to set their own prices for their services.
• Prepaid - The prepaid model is a more traditional payment model, similar to the one common in the mainstream VPN industry, where users buy access for a specific period of time. In prepaid mode there is no limit on bandwidth consumption and usage is usually unlimited.

Sentinel dVPN hosting system

An escrow system is used in a real-time payment model between users and service providers to ensure that neither party can fraudulently influence transactions. Before a connection can be established, the user is required to lock a certain amount of tokens in escrow, and the tokens will be deducted from this locked amount periodically based on the bandwidth consumed by the user. The precise measurement of bandwidth provided to users is made through the Sentinel "Proof of Bandwidth" protocol, which communicates with escrow agencies to establish a fully decentralized method for releasing tokens from custodians.

Whitepaper: https://sentinel.co/whitepaper