Launch of the Sentinel Hub v12 testnet, Sentinel Biggest Chain Upgrade Till Date
There will be follow-up blogs covering various aspects of this upgrade in detail.
The Sentinel Hub v12 Testnet is launching in the coming days. This announcement covers the key changes to the Sentinel blockchain with this upgrade.
dVPN Explorer — https://www.mintscan.io/sentinel
dVPN Github — https://github.com/sentinel-official
dVPN Stats — https://stats.sentinel.co
dVPN Docs — https://docs.sentinel.co
Sentinel runs on its own blockchain built on the Cosmos SDK, and is powered by over 70 validators. The Sentinel blockchain has processed over 130 million transactions over the past 3 years, with the chain acting as the backbone for p2p dVPN infrastructure by providing an on-chain DHT structure for the communication between dVPN users and dVPN nodes in addition to other critical functions.
It is the goal of the Sentinel ecosystem to consistently innovate on the back-end in order to improve user experience.
One of the key features of this upgrade is Sentinel’s integration with dVPN/USD Osmosis price-feeds via the Cosmos IBC protocol in order to allow for dVPN nodes to denominate their bandwidth pricing in terms of $/unit of time. In Sentinel’s last major protocol upgrade, pricing in terms of $DVPN/unit of time was introduced and now further work has been done to create one of the first-ever implementations of a secure pricing oracle that uses an interoperability protocol.
The upgrade to Sentinel Hub v12 is Sentinel’s biggest upgrade yet and includes several new features and upgrades that will make a significant impact for dVPN users, dVPN node hosts, and dVPN application creators.
Sentinel’s blockchain has provided secure dVPN connection to over 600k unique users and through over 6 dVPN applications built on Sentinel. The usage graph is trending upwards and Sentinel is set to cross 1 million unique users in 2025. Sentinel has custom modules for its p2p dVPN protocol written in GO at the chain consensus level, and changes to the dVPN protocol requires a complete chain upgrade.
This testnet is critical for dVPN application developers and node hosts to ensure that dVPN functionality is not disrupted once the upgrade is done and the dVPN bandwidth protocol is updated.
Checkout an article on the last significant chain upgrade:
https://medium.com/sentinel/introduction-of-on-chain-subscriptions-and-time-based-payments-sentinels-biggest-dvpn-protocol-a2b240199f18
Highlights of the Chain Upgrade’s Impact:
dVPN Users:
- Improved user experience with block time reducing to 3 seconds, potentially decreasing the time to connect to a node by 30% or more.
- Ability to choose a dollar denominated payment structure when subscribing directly to dVPN nodes
- Better user experience with the elimination of needing to initiate a subscription transaction before being able to connect to a node when directly subscribing to a node (not through a subscription plan created by a dVPN application creator)
dVPN Node Hosts:
Ability to set pricing in-terms of $/unit of time, where the price of dVPN/USD from Osmosis is queried via IBC to determine the # of dVPN for payment required based on a $ rate
- Completely new dVPN node health check system with an in-built queue system to re-check failed nodes to reduce the occurrence of errors.
- Completely new dVPN node architecture that does not require a docker image and can potentially be deployed on Windows and Mac as well
dVPN Application Developers:
- Ability to add dVPN nodes to a subscription contract based on their pricing in terms of $/unit of time — as compared to paying dVPN nodes in $DVPN denominated rates
- Ability to automatically renew subscription contracts with dVPN node hosts after the time period for the previous subscription has elapsed
- Ability to directly provide ‘free’ dVPN access without a payment making it easier for dVPN applications to provide free trial periods by integrating this logic
Cosmos SDK related updates for the Sentinel Hub
- Cosmos SDK Upgrade: Upgraded the Cosmos SDK version to
v0.47.Xfor improved stability, performance, and compatibility with the latest ecosystem standards. - CometBFT Upgrade: Updated the CometBFT version to the release (
v0.37.X), ensuring enhanced consensus mechanisms and reliability. - CosmWasm Upgrade: Updated the CosmWasm version to the release (
v0.46.X), providing improved smart contract capabilities and better developer experience. - IBC Upgrade: Upgraded the IBC protocol version to (
v7.8.X) enhance interchain communication, ensuring compatibility with the latest standards and improving cross-chain interactions. - Optimized Queries: Improved the efficiency of various queries across modules, reducing response times and enhancing overall performance.
Introduction of the Oracle Module
Oracle Module: Introduced a new module to manage asset price information, enabling seamless integration with other modules. Key features include:
- Asset Management: Each asset is defined by parameters such as: Base Denomination, Quote Denomination, and Pool ID: These fields are used for acquiring the spot price information from the Osmosis blockchain. The Pool ID information is also updated using the AsyncICQ module.
- Governance Control: Both asset information and the frequency of query requests can be updated through governance proposals by the community.
- IBC-Based Price Queries: The Sentinel blockchain uses Inter-Blockchain Communication (IBC) with the AsyncICQ module to query price information from the Osmosis blockchain:
- Sentinel sends query requests for asset prices to the Osmosis blockchain every N blocks.
- Relayers deliver query packets to Osmosis, which processes the request and sends a response as an acknowledgment.
- Sentinel processes the responses and updates the price information for specific assets in its state.
Real-Time Price Updates: The module ensures that market price fluctuations are reflected on Sentinel. For example:
- A node setting a price in USD (e.g., $1) can use Oracle to convert this to the settling denomination (e.g., $DVPN or $ATOM) based on real-time prices.
Changes for Users in the Protocol
- Subscription without locking — Previously, users were required to subscribe to a node by locking tokens or coins before creating hourly or gigabyte-based sessions (e.g., pay-as-you-go sessions). In the new version, this subscription step has been eliminated. Users can now start sessions directly with a node without prior subscription.
- Multiple Sessions: Users can create multiple sessions for a node at any time. During session creation, users specify the number of hours or gigabytes they wish to use, and the corresponding amount is locked as a deposit. At the end of the session, the deposit is used to pay the node, with any refunds for unused time or data automatically returned to the user.
- Single Transaction Efficiency: The new process reduces the previous two-step requirement to a single transaction, significantly decreasing session creation time. Users can now create an on-chain session within just one transaction, improving overall efficiency and user experience. Previously, users were limited to one active session at a time for a specific node (user-node pairs were unique). In the new version, users can create and maintain multiple active sessions simultaneously for the same node, offering greater flexibility in usage.
- Automatic subscription plan renewal for the user — Users can enable the renewal process by making a transaction. During renewal, the price information for the subscription plan is fetched from the Oracle module, ensuring real-time pricing. The corresponding amount is deducted from the user’s account and paid to the provider.
Changes for dVPN Nodes in the Protocol
- USD-Based Pricing: Nodes can now set pricing details exclusively in USD format (e.g., $1 per hour or per gigabyte). The settlement will be conducted in a specified cryptocurrency such as $DVPN, $ATOM, or other denominations, with conversion handled using Oracle module data.
- Free Pricing Option: Node operators can now opt to provide their services free of charge by not setting any pricing information.
- Removed Maximum Price Validation: The maximum price validation for node pricing has been removed, allowing greater flexibility for node operators to set their desired pricing.
Changes for dVPN Application Developers in the Protocol
- USD-Based Pricing: Providers can now create subscription plans where the pricing information is set exclusively in USD format (e.g., $5 per month).
- Free Subscription Plans: Providers now have the option to set the subscription plan price as free, allowing users to subscribe without any payment.
- Revenue Distribution: Upon a user’s subscription: A portion of the payment (e.g., 20%) is sent to the community pool. The remaining percentage is transferred to the provider’s address.
- New ‘Lease Module’: Providers can lease nodes for a specified number of hours (minimum 1 hour). The maximum duration is governed by a governance proposal, with a default of 720 hours. At any given time, only one active lease is allowed between a provider and a node pair. New leases cannot be created for a provider-node pair with an existing active lease. Leases are automatically marked as ended and removed from the blockchain state after the lease duration.
- Renewable Leases: Providers can opt for renewable leases. Upon renewal, if the hourly rate changes (e.g., from 10 $DVPN to 12 $DVPN), the updated rate is applied, and the required deposit is recalculated. Providers can end leases at any time, with refunds issued for unused hours. Providers can also toggle leases between renewable and non-renewable states.
- Automatic End-Conditions: Leases are automatically terminated if the node becomes inactive, ensuring providers are not charged unnecessarily. When a node associated with an active lease becomes inactive, that particular node is removed from all subscription plans created by the provider.
Introduction of the Session Module:
Separate Session Types: In the new version, sessions are categorized into two distinct types:
- Node-Based Sessions: Specifically for sessions created for nodes. At the end of these sessions, payments are made directly to the node based on the usage (e.g., hourly or gigabyte-based pricing).
- Subscription-Based Sessions: Specifically for sessions created as part of a subscription. These sessions do not involve any direct payments. Instead, they update the allocation of data or bandwidth as part of the subscription.
Previously, a single session type was used for both node-based and subscription-based sessions. This new categorization provides clarity and separates the handling logic for each type.
Automatic Session Inactivation:
Sessions will now become inactive under the following conditions:
- The node associated with the session becomes inactive.
- The subscription associated with the session becomes inactive.
- The node is removed from the subscription plan.
