Table of content

Introduction

Flow’s Architecture:

• massively scalable, decentralized, and autonomously-operating computing platform

Implementation:

• to operate completely autonomously without human intervention, network needs lots of logic that is never executed on the happy path
• evolutionary development approach
  • initially prioritize happy-path functionality
  • human involvement to prevent and/or respond to unfavourable scenarios
  • progressively decentralize human involvement via on-chain governance mechanisms
  • progressively extend implementation to autonomously handle unfavourable scenarios

Current state:

<aside> 💡 Flow is fully decentralized:

The Flow network will continue to run despite any individual party ceasing to participate.

</aside>

Final Goal: Full Network Autonomy

<aside> 🔎 Goals:

Liveness under adversarial conditions:

• Flow continues to operate (potentially with degraded performance) during periods of severe attacks by a colluding group of Byzantine nodes controlling up to 1/3 of stake (per node role).

Autonomously suppress lazy and punish adversarial behaviour:

Performance-dependent rewards

• nodes are rewarded for helping to extend the chain
• Incentivize speed
• Disincentivize freeloaders

Slashing Stake

• Honest nodes can automatically attribute the protocol violations and raise slashing challenges. Slashing challenges are automatically adjudicated and the weight of offending nodes is automatically reduced, including potential revocation of the node’s participation rights (ejection). </aside>

<aside> ❗ We can accept liveness risks but not safety risks.

</aside>

Required For Network Autonomy

1. Byzantine-Fault Tolerance [BFT]

   • BFT protocol (formal protocol feature) • resilient node software (implementation feature)

2. Trustless Access

   • data verifiability (formal protocol feature) • resilient client software (implementation feature)

   👉 Flow’s Data Egress: A Long-Term Vision