Ask or search…

Vistara Network

Vistara network needs a consensus mechanism that is crucial for:
  1. 1.
    Validating Transactions: Ensuring that only valid transactions are added to the blockchain or the decentralized ledger.
  2. 2.
    Synchronization: Making sure that all nodes have the same data and are in sync.
  3. 3.
    Network Security: Protecting against malicious attacks by making it computationally challenging for a single entity to control the network.
  4. 4.
    Verify the authenticity of nodes joining the network.
  5. 5.
    Allocate computational tasks to various nodes.
  6. 6.
    Validate the results returned by these computational tasks.
A PoS (Proof of Stake) mechanism is a natural choice for Vistara. Validators (a subset of node operators) would be required to "stake" or lock up a certain amount of Vistara tokens to become validators. These validators would be responsible for:
  • Validating the legitimacy of Vimana Node deployment requests.
  • Validating the computational results returned by node runners.
  • Proposing and finalizing blocks in the blockchain layer.
Deployment approach #1:
  1. 1.
    Deployment Specification: A user, through a Vimana Node, specifies the requirements of the modular component they want to deploy, including computational resources, storage, and desired price range.
  2. 2.
    Open Auction: Inspired by Akash's "open auction" for deployments, Node Runners would bid for the deployment. They would indicate how much they'll charge for the computational resources.
  3. 3.
    Matchmaking: The Vimana Node, after a predetermined time, would select the best-suited Node Runner based on price, past performance, and resource availability.
  4. 4.
    Deployment: Once matched, the Node Runner deploys the modular component on their infrastructure.
  5. 5.
    Periodic Verification: Vimana Nodes, through the staked validators, can periodically check the integrity and performance of the deployed component to ensure it meets the initial specifications.

Disadvantages of Auctions and Matchmaking:

  1. 1.
    Latency: The auction process can introduce delays before the actual deployment starts.
  2. 2.
    Complexity: Continuous bid tracking, matchmaking, and ensuring fair pricing can be complex.
  3. 3.
    Manipulation: Potential for Node Runners to manipulate the system by artificially lowering their bids to win auctions, then underdelivering.
  4. 4.
    Overhead: Matchmaking adds computational overhead, especially as the network grows.
Fixed Pricing with Reputation System:
  • Mechanism: Instead of an auction, have fixed price brackets based on computational resources. Node Runners can choose to offer their services in these brackets.
  • Advantage: This significantly speeds up deployment time and reduces computational overhead.
  • Reputation: Node Runners can be ranked based on performance, uptime, and feedback. High-reputation Node Runners get prioritized for deployments.
  • Challenge: Determining fixed pricing can be challenging and may not always be aligned with market dynamics.
Vistara's approach:

1. Fixed Pricing Tiers:

  • Setup: Define several fixed pricing tiers based on the computational resources provided. For example:
    • Tier 1: Basic compute (suitable for lightweight tasks)
    • Tier 2: Advanced compute (suitable for running modular components)
    • Tier 3: Premium compute (suitable for intensive simulations)

2. Reputation System:

  • Scoring: Assign scores to Node Runners based on:
    • Performance: Did they execute tasks in the promised timeframe?
    • Uptime: How often are they available?
    • Feedback: What do users say about them? Were there any issues with the computation?
  • Ranking: Use scores to rank Node Runners within each pricing tier. Higher scores mean better ranks.

3. Geographical Zoning:

  • Zone Definition: Divide the network into geographical zones, e.g., North America, Europe, Asia, etc.
  • Node Runner Registration: Node Runners, while joining, select their geographical zone.
  • User Selection: Users, when they want to deploy a task, select the desired geographical zone for deployment. This ensures data residency and potentially lower latency.

Deployment Process:

  1. 1.
    User Selection: The user selects the desired pricing tier and geographical zone for their computational task.
  2. 2.
    Fetching Suitable Node Runners: The system fetches a list of Node Runners from the selected zone and tier.
  3. 3.
    Ranking Based on Reputation: The Node Runners from the list are ranked based on their reputation score.
  4. 4.
    • Automatic: The system automatically chooses the top-ranked Node Runner for deployment.
    • Manual Override: Optionally, users can manually select a Node Runner from the ranked list if they have a preference.
  5. 5.
    Execution & Feedback:
    • Once the task is executed, users can provide feedback, impacting the Node Runner's reputation score.
    • Node Runners are incentivized to provide accurate services to maintain or improve their reputation.
  6. 6.
    Periodic Review: Periodically (e.g., every month), the pricing tiers and reputation scoring mechanism can be reviewed to ensure they remain relevant and reflect the market's needs.


  1. 1.
    Predictable Costs: Users know the costs upfront due to fixed pricing.
  2. 2.
    Quality Assurance: The reputation system ensures high-quality computation as Node Runners strive to maintain or enhance their reputation.
  3. 3.
    Geographical Flexibility: Users can optimize latency and adhere to data residency regulations.

Potential Challenges:

  1. 1.
    Dynamic Market Rates: Fixed pricing might not always reflect the current market dynamics.
  2. 2.
    Zonal Imbalance: Some zones might become more popular, leading to resource contention, while others might face underutilization.
To address these challenges, a periodic review of the system, dynamic scaling of resources based on demand, and incentives for Node Runners in less popular zones can be considered.