Iniva: Inclusive and Incentive-compatible Vote Aggregation

TL;DR

Iniva tackles vote omission attacks in committee-based blockchains by combining indivisible multi-signatures with a two-level tree and fallback paths to ensure vote inclusiveness without costly reconfiguration. The paper integrates Iniva with HotStuff and adds a reward mechanism to deter free riding, supported by game-theoretic analysis and extensive simulations that quantify reduced targeted omission probability and increased cost for large omissions. Empirical results demonstrate robustness, scalability, and reasonable throughput under faults, while maintaining strict inclusiveness and liveness guarantees. The work offers a practical, incentive-aligned approach to secure, scalable PoS-style committee protocols with improved resilience to adversarial behavior.

Abstract

Many blockchain platforms use committee-based consensus for scalability, finality, and security. In this consensus scheme, a committee decides which blocks get appended to the chain, typically through several voting phases. Platforms typically leverage the committee members' recorded votes to reward, punish, or detect failures. A common approach is to let the block proposer decide which votes to include, opening the door to possible attacks. For example, a malicious proposer can omit votes from targeted committee members, resulting in lost profits and, ultimately, their departure from the system. This paper presents Iniva, an inclusive and incentive-compatible vote aggregation scheme that prevents such vote omission attacks. Iniva relies on a tree overlay with carefully selected fallback paths, making it robust against process failures without needing reconfiguration or additional redundancy. Our analysis shows that Iniva significantly reduces the chance to omit individual votes while ensuring that omitting many votes incurs a significant cost. In addition, our experimental results show that Iniva enjoys robustness, scalability, and reasonable throughput.

Figures (3)

• Figure 1: An overview of Iniva. A)$L_{v}$ commits $B_{h}$. It creates and forwards $B_{h+1}$ to $L_{v+1}$ and $L_{v+1}$ children. B)$L_{v+1}$ receives $B_{h+1}$ and starts the view by sharing the proposal with its children. C) Internal nodes forward $B_{h+1}$ to their children, and wait for their response. D) Leaf nodes verify and sign $B_{h+1}$, and share their signature with their parent. E) Internal nodes aggregate their children signatures, and share it with their parent. F)$L_{v+1}$ commits $B_{h+1}$. It creates and forwards $B_{h+2}$ to $L_{v+2}$ and $L_{v+2}$ children.
• Figure 2: Simulation results. In each simulation, there are $111$ processes in each committee for Iniva (a full 2-level tree with a fan-out of 10). In (a) and (b) there are $100$ processes in the committee for Gosig. In (d), there are $109$ processes when having 4 internal nodes.
• Figure :

Theorems & Definitions (16)

• Definition 1
• Definition 2: Reliable Dissemination
• Definition 3: Fulfillment
• Definition 4: Inclusiveness
• Definition 5: $c$-omission probability
• Definition 6: Incentive compatibility
• Theorem 1
• proof
• Theorem 2
• proof