network-stories/pages/Helper Document.md

Understanding the Logos Blockchain Whitepaper

Title: Understanding the Logos Blockchain Whitepaper | A High-Level Conceptual Overview/Review of the Logos Blockchain

Purpose: This document reflects an approach of whitepaper review that combines a rough-draft whitepaper review containing comments/reflections/concerns with a further simplification of concepts to make everything more digestible to more people outside of the internal Status infra team for communication purposes. In addition, this review will provide a gauge of difficulty of understanding involved with various different terms/concepts.

Tags: #learning #whitepaper #Logos

---

**"We build everything on top of consensus." ** Dr. Corey Petty

---

How-To (Get Cookin')

There are some descriptions below which detail the usage of visual guidance metrics available in the form of "cookbook-like" instructions for how to consume this document:

Gauges	Description	Visualization
Difficulty	1-10 (Ticks/Pips)	[||||||||||]
Time	In Minutes	X Minutes
Resources	Article/Video Links w/ Visual Content	Conceptual & Pictoral "Ingredients List" of Links

See below 'Recipe' and modify accordingly to above in Figma.

---

Operating Definitions: Easiness/Difficulty is defined as the ease of which the concepts can be generally understood.

Time/Scope is in reference to the size of information necessary to learn to gain a decent level of comprehension.

Resources is for links relevant to helping people understand the concepts.

---

Necessary Terminology by Layer

---

The Six (6) Technology Layers of Logos as a Blockchain

• Terminology Template: here

Consensus

• BBA
• Leaderless
• DAGs
• CIC
• Messaging
• Permissionless
• Scalability
• Decentralization
• Security
• Communication Costs
• Stream or Subgraph
• Staking
• Sybil Resistance
• CFT (Crash Fault Tolerant)
• BFT (Byzantine Fault Tolerant)
• Finality
• Social Applications
• Bootstrapping
• Rounds
• Round-less
• PBFT
• DAG-Based Consensus (Avalanche-like)
• Liveness
• Asynchronous (P2P)
• Execution-Layer Decoupling
• Interchangeability
• Liveness
• Extensibility
• Highly-Partitioned Blockchains with Local Views
• Ordering
• Reputation
• Confidence
• Network Congestion
• Topology
• Resilience (Consensus context)
• Verifiability
• Non-Repudiation
• Snowball
• Lachesis
• Glacier

Node Reputation

• Ikingut (Reputation Algorithm)
  • Important Conceptual Goals
    • Simple
    • Lightweight
    • Pluggable
    • Adaptive
    • Dynamic
    • Robust
    • No Transitive Trust
    • Reasonable Bootstrap Time
  • Reputation Polling (Polling Dynamics)
    • Indirect Request
    • Direct Request
      • Unirep (an example)
      • Qualities Necessary
        • Requires Verifiability
        • Requires Non-Repudiation
        • Privacy Preserving (preserve origins of score, emit opinions without a way to trace back the origins - MPC)
    • Local Heuristic
  • Algorithm
    • Each Iteration
      1. Voting
      2. Agent Action (Post-Consensus Decision Finality)
    • Min-Multiplicative Reputation Punishment
      • Multiplicative
      • Linear
  • Experimental Research
    • Starting Point
      • Trust Wisdom per Node (requires further elaboration)
      • Adversary Types and Effects (requires further elaboration)
    • Current Stage of Testing/Challenges
      • Silent-Omniscient Adversaries
      • Modulating Punishment/No Punishment Impacts to Conditions
      • Adding Multiplicative-min Punishment
      • Attacks
        • Con-Artist Attack
        • The On-Off Attack
      • Effects on Glacier Consensus
      • Limitations
        • No immediate defense against coordinated attacks
        • Reputation does not add to security
    • Future Work
      • Circumstantial Impact of Reputation on Consensus
      • Long-running Simulation
      • Sudden changes in Collective Byzantine Behavior
      • Pending Questions
        1. Interaction of Stake-based and Reputation-based selection
           • Stake simulations are necessary for exploring options
           • Relevant in the incentives discussion?
        2. How much (and if) does reputation really help in a coordinated attack? (Assuming patient con-artist attack)
           • Complex interactions here, this model would particularly benefit having a prototype/PoC
• Node Challenges
  1. Intermittence Flexibility
  2. Sudden Changing Behavior
  3. Bootstrapping Quickly
  4. Resilience to Dynamic Unpredictable Network Changes (Can Handle Membership Volatility)
• Design
  1. Local reputation view
  2. Adaptive and Dynamic
  3. Required Bootstrapping
     • Network View Not Required
     • Individual Node Reputation Not Required
• Eigentrust
  • Transitive Trust
  • Understanding the Math
  • Trust Decay
    • Malicious Clusters (describe nuances better | trusted nodes cannot overlap the malicious collective)
  • Trust for Consensus
  • Separation of Reputation
  • Confidant
  • XRep
  • P-Grid
  • R2Trust
• Generic Taxonomy
  • Dimensions
    • #Single
    • Multiple
  • Time computation
  • Aggregation
    • Deterministic sum of positive and negative ratings
    • Probabilistic
  • Logic
    • Local vs gathered data
    • Age of data
    • Frequency of data
    • Weight of multiple dimensions
  • Value Control
    • External
    • Internal
  • Data Aging
    • None
    • Decay
    • Death of old/selected
  • Selection
    • Ranking-based
    • Threshold (trusted/untrusted)
    • Probabilistic selection

Network Layer and Mempool

Staking and Multi-DAG

Data Model and Concurrency

Tokenomics