System Constraints and Design Trade-offs

Explore the known Via system constrains and design trade-offs.

PreviousConnect to VIA Network NextTrust-minimized BTC Bridge

Last updated 1 month ago

System Constraints and Design Trade-offs

Explore the known Via system constrains and design trade-offs.

The current (Alpha) version of the VIA Testnet is a MVP designed to achieve compatibility between ZK Stack and Bitcoin. In order to accelerate development and enable fast iterations, we have made several design choices that introduce certain limitations. While these trade-offs serve our immediate goal of rapid deployment, we are committed to addressing them in future phases.

Verifier Network Architecture: Current Verifier Network does not fully embody the ideals of a fully decentralized and trustless system. It operates with a fixed Coordinator role—held by one of the Verifiers—and utilizes a n-of-n Schnorr signature scheme via MuSig2 algorithm.
Trust Assumptions in the Bridge Mechanism: Under the existing design, users must rely on the Verifier Network to process their withdrawals. In other words, if any single Verifier becomes unresponsive, the entire network will face difficulties processing withdrawals (n-of-n verifiers required to guarantee liveness). On the other hand, only one honest Verifier is enough to make sure the funds can not be stolen (1-of-n trust assumption to guarantee safety). Moreover, the present architecture does not support dynamic addition or removal of Verifiers, which limits flexibility. This reliance is a temporary measure, and we plan to transition to more —potentially incorporating solutions like BitVM-based bridges and a more open Verifier Network—in subsequent phases.
Absence of Slashing Mechanisms: At this stage, there is no slashing mechanism in place to penalize malicious behavior by either the Verifier or the Sequencer. This decision was made to simplify the design, but we recognize the importance of robust incentive models and intend to introduce appropriate measures in future iterations.
Fee Model Limitation: Our current fee model doesn’t consider the costs of Sequencer publishing data to the DA layer.

These design trade-offs reflect our focus on rapid iteration and early validation of the core concept. We are fully aware of these limitations and are committed to evolving the protocol with more robust, trustless, and decentralized solutions as we move beyond the MVP phase.

PreviousConnect to VIA Network NextTrust-minimized BTC Bridge

Last updated 1 month ago

Verifier Network Architecture: Current Verifier Network does not fully embody the ideals of a fully decentralized and trustless system. It operates with a fixed Coordinator role—held by one of the Verifiers—and utilizes a n-of-n Schnorr signature scheme via MuSig2 algorithm.
Trust Assumptions in the Bridge Mechanism: Under the existing design, users must rely on the Verifier Network to process their withdrawals. In other words, if any single Verifier becomes unresponsive, the entire network will face difficulties processing withdrawals (n-of-n verifiers required to guarantee liveness). On the other hand, only one honest Verifier is enough to make sure the funds can not be stolen (1-of-n trust assumption to guarantee safety). Moreover, the present architecture does not support dynamic addition or removal of Verifiers, which limits flexibility. This reliance is a temporary measure, and we plan to transition to more —potentially incorporating solutions like BitVM-based bridges and a more open Verifier Network—in subsequent phases.
Absence of Slashing Mechanisms: At this stage, there is no slashing mechanism in place to penalize malicious behavior by either the Verifier or the Sequencer. This decision was made to simplify the design, but we recognize the importance of robust incentive models and intend to introduce appropriate measures in future iterations.
Fee Model Limitation: Our current fee model doesn’t consider the costs of Sequencer publishing data to the DA layer.