🥽 | Blue: Hierarchical Consensus

[jsoares]

@jsoares commented on Tue Nov 30 2021

Description

The goal of the blue work area of projects is to design hierarchical and horizontal scaling mechanisms for Filecoin and the broader blockchain ecosystem. In the hierarchical context, blockchain subnets must benefit from the security contexts of their parents, while in the horizontal context, they help scale performance compared to parent subnets. Generic cross-subnet transaction mechanisms need to be in place, along with the automated creation of subnets and their destruction and garbage collection.

Scope

• Features
  • MUST support cross-subnet invocations (moving state between subnets)
    • MUST define provided cross-subnet semantics
    • SHOULD support atomic semantics
    • SHOULD aim for strongest semantics
    • MAY use 2 or 3 phase commit
  • MUST be partition tolerant across subnets (tolerate a number of disconnected epochs)
  • MUST manage subnets (lifecycle) via in-VM smart contracts
  • MUST support the use a power table (weighted membership group)
  • MUST support swappable consensus protocols
    • SHOULD enable subnets to run different consensus protocols (assuming some baseline interfaces)
  • SHOULD support subnets with different gas rules (gas lanes)
  • SHOULD enable message passing / function invocation across subnets
• Scalability Design
  • MUST scale vertically (infinite nested subchaining)
  • MUST scale horizontally (children subnets not limited by parent)
  • MUST achieve datacenter level of throughput and latency in appropriate subnets
  • MUST allow subnets running at different epoch times (faster subnets in smaller geographies)
• Security Design
  • MUST address power table dilution problem in children subnets (from vantage point of the parent subnet)
  • SHOULD anchor checkpoints in a higher security context (e.g., PoW/Bitcoin)
  • SHOULD anchor security of a child into parent subnets
  • SHOULD consider consensus slashing for security (possibly in the parent subnet)
• Correctness
  • MUST produce proofs of correctness
  • SHOULD automatically verify or model-check designs
• Design Principles to keep in mind
  • SHOULD aim for simplicity in protocol design (as simple as possible, but not simpler)
  • SHOULD aim for an easy-to-implement design (tradeoff efficiency for simplicity of implementation)

Projects

• 🚧 | B1: Hierarchical consensus PoC #4
• 🚧 | B2 (Pikachu): Securing membership and state checkpoints of BFT and PoS blockchains by anchoring into the Bitcoin blockchain #5
• 🚧 | B3: Turn B1 into production-ready system for core actors and FVM #6
• 🚧 | B4: Integrate IPC and Mir into a production system #7