Disclaimer: the stories shared on this blog are mine, they aren’t financial advice, endorsement, counseling of any kind. Cryptocurrencies are highly volatile and speculative assets plagued by gambling addiction and fraud. Do your own research, never EVER take loans to acquire crypto, never communicate your private keys or mnemonic seed words to anyone, and never invest what you can’t afford to loose.

Note: this post dives into technical considerations of mine after reading the Sentinel whitepaper and testing out the available software to date, the project itself is still in it's infancy, many aspects of the project might evolve over time or I might be totally mistaken on key principles. Please feel free to correct me and contribute in comments or Twitter!

What is it?

One of the most exciting cryptocurrency ecosystems out there is the CosmosHub, the internet of blockchains, which keeps gaining much deserved attention. And one of those blockchains (which is already IBC-active allowing it's token to be swapped on AMMs like Osmosis and Emeris), is Sentinel.
It's mere presence in the ecosystem caught my attention, and it's purpose caught my further investigation. The DVPN token serves as governance and utility token on the Sentinel blockchain. And this blockchain serves as intermediary for transactions between users and nodes of a decentralized communication network for data transfer in a Virtual Private Network context. In short: the dVPN.

VPN for privacy: the principles

One often sees ads and sponsors for VPN services, promising privacy protection in internet communications. It works like this:

• A client software or the system's included tool encapsulates ALL internet connections inside an encrypted channel
• This channel is linked to a server, the "bridge"
• The server forwards the connections to public internet under it's own IP address
  Traditionally (and quite often during a pandemic), VPN services are put in place by companies to allow external connections (say, a sales representative on a Starbuck's WiFi) to securely access internal resources (say, the network printer in the secretary office, or the file server handling the work documents).
  But a VPN can work the other way around: instead of forwarding to a local network, a VPN server can forward to the global network (internet). This property makes it useful to circumvent a geoblocking for example: your computer could be located in India connected on a landline, establishing a VPN channel to a server located in USA, and from Netflix' point of view you'd be accessing the streaming service from USA (thus opening you access to a much wider content selection than what's normally available for India).
  From a privacy point of view, this is only a risk shift tho: with a VPN channel your connection would be (more) secure against your ISP (public WiFi or other), but the VPN server still sees all connections flowing through it. As long you visit websites using TLS (https://) and the presented certificate is the genuine one, then the VPN server can't decrypt the content of the connection (nor manipulate the content). But it could still tell which websites you visit (domain name by sniffing at DNS requests, or IP addresses your computer wants to reach).
  Also: some VPN service providers claim that they keep no logs. This is fundamentally wrong: they at least keep account records (login + password), and payment info. Users need authenticate and pay for the service, right? With this comes authenticated session identifier, and the assigned port(s) by the server (yes, the server needs that to know to which user to route that Netflix stream). That's plenty enough for authorities, lawful or not, to identify which VPN user accessed a certain website at a certain date and time. Again: VPN providers can claim they don't keep logs, but in truth you don't know and you can't know whether this is true.

How the dVPN differs

The technical approach of Sentinel has some common principles with TOR: instead of a direct connection between the client computer and the VPN server, dVPN routes connections through several dVPN nodes (or relays). Those nodes ensure that the exit node does not know which computer initially established the connection. All it knows is which node to forward public internet packets to. And if dVPN takes the same levels than TOR, then the intermediary node (or "shield node") and the first node (or "entry node") ensure it's impossible to tell which computer used which exit node.
This architecture makes connection logging not impossible, but useless. One would need to seize potential logs from many / all dVPN nodes to hope reconstructing how a connection was established from a computer to an internet service.
With dVPN, like with TOR, people can operate relay nodes. Or even exit nodes. But while on TOR it's a free-for-all, on dVPN it's possible to set a price on the bandwidth provided. And how do trustless, immutable pseudo-anonymous transactions happen? Yes correctly: through the Sentinel blockchain!
The opened possibilities:

• people with lots of unused bandwidth can provide it to the Sentinel dVPN network (as relay nodes or exit nodes) and earn DVPN tokens in return
• people who want faster dVPN connectivity (or any connectivity?) can spend some DVPN tokens on the network, who redistributes it to the participating nodes
  (note: it's unclear to me if a per-use redistribution happens, and if yes this could be a security weakness: it could make it easier to reconstruct which dVPN nodes were implicated in a specific connection; but maybe the entry node would serve as payment proxy, or pre-crediting bandwidth from other nodes, shielding the user from payment-retracement)

Challenge: client software

Sentinel dVPN is just an infrastructure protocol. To use it, users will need client software. (think: to use the World Wide Web, users need a web browser like Chrome or Firefox)
At time of writing, there are two Sentinel-certified client software available for download, built by Exidio: an app for Android, and an app for iOS. More tech-savvy people might look on Sentinel's Github for a CLI client but that's probably just for tests.
So yes right now there aren't any client for Windows. But that might come soon: after all a centralized VPN provider can reuse their existing software but instead make it connect to the dVPN network. But if a client needs to be developed from scratch, utmost fine-tuning of the UI is necessary so the user understands the basic principles of paying with DVPN tokens, and why it's beneficial.
In the whitepaper, Sentinel mentions that, for wide public adoption, client software should make fiat-onboarding possible (say: use a debit card to buy DVPN tokens to spend for dVPN bandwidth). But that's bringing back a core issue of centralized VPN providers: fiat payment means accounting, thus traceability, and KYC+AML requirements. The company managing the client software could handle this on it's side, but there would be a transaction traceability when the DVPN tokens get credited, and thus, at very least, the possibility to link a personal identity to an usage pattern of those DVPN tokens. So, ideally, people should acquire DVPN tokens by other means.
And ummm, one more thing: the ability to have dVPN-compatible client apps on GooglePlay and App Store is totally up to Google and Apple. If they think this might attract negative scrutiny even by authoritarian regimes, they would pull the plug.

Challenge: relay nodes

Bringing more relay nodes to the dVPN network is basically as easy as the node software installation is. Good news: the technical requirements are reasonable and Docker makes it quick. Heck: aside from the storage space, this seems like a possible job for Akash deployments.
Easier yet: several router vendors announced partnering up with Sentinel to build all-in-one dVPN nodes for home users. Plug it to your internet line, enable dVPN node functions, set your DVPN wallet address, and get paid for the bandwidth your router relays!

Challenge: exit nodes

While providing a relay node for dVPN shouldn't be a headache, it gets significantly trickier if your intention is to operate an exit node (and that's why I expect such exit nodes to get better paid in DVPN tokens than simple relay nodes).
See: if you provide an exit node, then dVPN connections will use your public IP address when reaching the global internet.
It's something TOR exit node operators also face: their public IP address is what is visible to outside parties. So for example, operators might receive DMCA takedown notices, litigation threats for copyright infringement downloads, blacklisting by mail servers for spam distribution, and uncomfortable times in police offices if the exit node happens to have been abused to intrude sensitive infrastructures, posting threatening messages on social media, command botnets, or even send child abuse material.
That's why I'd advise AGAINST providing exit nodes from a home internet access. Instead, exit node operators should have a dedicated internet access, under a NGO or company, and ideally using one IPv6 address dedicated to the dVPN exit node only, no IPv4, to absolutely ensure abusive behavior came from the dVPN network and not, say, an employee of the operator company. Also: transparency is key. Operators should ensure it's very easy to find out that such IP address is a dVPN exit node, and thus prone to potential abuse outside the will and knowledge of the operator. This might be enough to grant operators Safe Harbor protection of liability for wrongdoings under "their" public IP address.

Challenge: competing with centralized VPN services

To reap the attention of the general public Sentinel and dVPN-compatible client software will go a long way: their marketing capacities would need to be immense to hope existing in an already crowded marketplace of VPN services. Instead, the focus should be on education, the risks of centralized VPN services, and maybe a few scandals of VPN services forced to hand over logs despite their claims of "not storing any logs".
But a strong catalyst could be the costs: paying for VPN service on dVPN could be much much cheaper than on centralized VPN (since dVPN is fueled by already-existing unused bandwidth on plenty internet lines, no need to build additional internet lines and operate dedicated VPN servers in datacenters, and even then it can sit on the very cost-effective Akash Network).
Better yet: the Sentinel blockchain uses delegated Proof of Stake, people can stake DVPN tokens to earn rewards (basically get "free VPN service" by contributing to blockchain security). And DVPN staking is quite juicy currently, with a 61% APY.

Challenge: competing with more advanced anonymization networks

dVPN doesn't seem like a direct competitor to TOR, since it has a slightly lesser privacy principle: the DVPN payment is traceable on the blockchain, and might be linked back to a personal identity in some cases (KYC+AML with debit card)..
But even TOR falls short for extreme privacy needs. Instead, dVPN is relevant for legitimate use of higher bandwidth, for example geo-restricted streaming services. And since bandwidth gets paid for per-use, this has as effect:

• for relay and exit nodes to allocate more bandwidth to get more DVPN token fees
• for users to select optimal nodes for their needs
• deters spammers and other bandwidth abusers
  dVPN sits at the crossroads between centralized proprietary VPN services, and anonymization networks.

Challenge: scaling of the blockchain
The Sentinel blockchain is built with the Cosmos-SDK, using Tendermint-BFT consensus, IBC-enabled. It can handle tens/hundreds of transactions per block without much issue, and there's a new block every 7 seconds. Not bad, but is it enough if millions of people rely on the blockchain for their dVPN use? Remains to be seen.
But then again, it's CosmosHub: interconnecting more Sentinel blockchains is doable if the need arises.
We'll see how it goes!