Vistara network needs a consensus mechanism that is crucial for:
- 1.Validating Transactions: Ensuring that only valid transactions are added to the blockchain or the decentralized ledger.
- 2.Synchronization: Making sure that all nodes have the same data and are in sync.
- 3.Network Security: Protecting against malicious attacks by making it computationally challenging for a single entity to control the network.
- 4.Verify the authenticity of nodes joining the network.
- 5.Allocate computational tasks to various nodes.
- 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.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.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.Matchmaking: The Vimana Node, after a predetermined time, would select the best-suited Node Runner based on price, past performance, and resource availability.
- 4.Deployment: Once matched, the Node Runner deploys the modular component on their infrastructure.
- 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.
- 1.Latency: The auction process can introduce delays before the actual deployment starts.
- 2.Complexity: Continuous bid tracking, matchmaking, and ensuring fair pricing can be complex.
- 3.Manipulation: Potential for Node Runners to manipulate the system by artificially lowering their bids to win auctions, then underdelivering.
- 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.
- 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)
- 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.
- 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.
- 1.User Selection: The user selects the desired pricing tier and geographical zone for their computational task.
- 2.Fetching Suitable Node Runners: The system fetches a list of Node Runners from the selected zone and tier.
- 3.Ranking Based on Reputation: The Node Runners from the list are ranked based on their reputation score.
- 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.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.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.Predictable Costs: Users know the costs upfront due to fixed pricing.
- 2.Quality Assurance: The reputation system ensures high-quality computation as Node Runners strive to maintain or enhance their reputation.
- 3.Geographical Flexibility: Users can optimize latency and adhere to data residency regulations.
- 1.Dynamic Market Rates: Fixed pricing might not always reflect the current market dynamics.
- 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.