Vistara
Ask or search…
K

Design Principles

A superlight chain
A superlight chain can be designed with the primary objective of reducing the overhead associated with maintaining, verifying, and propagating the blockchain, making it quicker and easier for nodes to participate.

What can a Superlight Chain provide:

  1. 1.
    Fast Syncing: Reduces the time it takes for a new node (like a Vimana) to become operational.
  2. 2.
    Low Storage Requirements: Helps in retaining more full nodes in the network as the cost of storage would be reduced. This is crucial for decentralization.
  3. 3.
    Network Scalability: Lighter chains mean less data to transfer, leading to faster propagation times and reduced chances of network congestion.
  4. 4.
    Accessibility: Enables devices with limited resources, such as IoT devices or personal smartphones, to participate as full or near-full nodes.

Addressing Verification in a Superlight Chain:

Even if a chain is superlight, it must retain its integrity and the ability to validate transactions. Here's how:
  1. 1.
    Merkle Proofs & State Commitments: Instead of storing every transaction, store only commitments (hashes) and use Merkle proofs to verify individual transactions. This provides a cryptographic assurance that a specific transaction is part of a block without needing the entire block data.
  2. 2.
    Zero-Knowledge Proofs: Techniques like zk-SNARKs or zk-STARKs can be used to provide evidence of the truth of a statement without revealing the data behind that statement. This can significantly reduce the size of transaction proofs.
  3. 3.
    Checkpoints: Regularly capture the state of the blockchain. New nodes can start from the most recent checkpoint and only validate blocks after that point.
  4. 4.
    Pruning: Older transaction data that isn't necessary for current operations can be pruned away, retaining only essential state information.
Consensus approaches
For the Vistara network, a decentralized web of interconnected Vimana spacecores, we require a consensus mechanism that ensures speed, security, and scalability. Tendermint is an option that can be used for its robustness, scalability, and security attributes:
  • Scalability: Tendermint can handle a larger number of validators than traditional PBFT, making it more suitable for Vistara's expansive vision.
  • Strong Finality: Transactions in Tendermint are finalized quickly and irreversibly, ensuring consistent state across all Vimanas.
  • Economic Incentives: Validators in Tendermint are not only chosen based on their stakes but can also be penalized for malicious behavior, ensuring a high degree of network security.
  • Modularity: Tendermint's separation of the application and consensus layers offers Vistara the flexibility it needs for future growth and adaptability.
With these attributes, using Tendermint aligns well with Vistara's mission to provide a decentralized, efficient, and trustworthy network for all its participants.
Vimana Consensus Spacecore
The consensus algorithm can reside within a singular spacecore in Vimana. Vimana spacecores are designed in a recursive manner where each spacecore can host other spacecores. Additionally, these can be upgraded or replaced when needed
  1. 1.
    Initialization: When a Vimana operator starts their node, the consensus component is initialized, establishing connections with other nodes if necessary.
  2. 2.
    Dynamic Loading: a component related to consensus is loaded. If using recursive components, child components are initialized within parent components.
  3. 3.
    Network Communication: The consensus component can handle communication with other nodes in the Vistara network, validating transactions, and confirming blocks.
  4. 4.
    Upgradability: In the event of a network upgrade or a consensus algorithm change, the consensus component can either be hot-swapped (if designed for such functionality) or require a restart of the Vimana node. Recursive components can allow for parts of the consensus to be upgraded without affecting the whole system.
  5. 5.
    Decentralized Operation: As Vistara aims for decentralization, each Vimana's consensus component would work in tandem with others, ensuring no single point of control or failure.
  6. 6.
    Auditing and Monitoring: Within the Vimana CLI, operators can monitor the performance of their consensus component, ensuring they are functioning optimally and maintaining network integrity.
KV store systems
DHTs can have a multitude of purposes beyond aiding in consensus. We can have an event-driven model where components can listen for specific keys or patterns in the KV store. When an event occurs, it can trigger a specific action in the component. KV stores can also be used for:
  1. 1.
    Configuration Management: Nodes can use the KV store to maintain and update configuration data.
  2. 2.
    Service Discovery: Nodes or services can register their existence and capabilities in the KV store, allowing others to discover and communicate with them.
  3. 3.
    Load Balancing: The KV store can maintain information about the load or capacity of nodes, helping in the efficient distribution of tasks.
  4. 4.
    Caching: For frequently accessed data or to reduce the redundancy of operations, the KV store can act as a cache.
  5. 5.
    State Management: The state of various applications or processes can be saved and retrieved from the KV store.
Node management
Adding a new node:
  1. 1.
    A permissionless system where any node with enough resources can join the network.
  2. 2.
    Nodes need to stake a certain amount of assets as collateral to ensure honest behavior.
  3. 3.
    Voting can be based on stake, reputation, or be one-node-one-vote.
  4. 4.
    Implement automated metrics to make sure nodes validate correctly.
Handling dishonest behavior:
  1. 1.
    A protocol is to be established so existing nodes can vote out a suspected malicious node.
  2. 2.
    Malicious nodes can lose their staked assets or slashed as a penalty.
  3. 3.
    Nodes can also lose it's reputation that results in reduced influence over the network.
  4. 4.
    Nodes should be able to recover from unintentional failures in the system.