diff --git a/EQBSL_Report.md b/EQBSL_Report.md index df15ca7..19a4b2f 100644 --- a/EQBSL_Report.md +++ b/EQBSL_Report.md @@ -1,7 +1,7 @@ # EQBSL: Potential Uses and Applications Report **Date:** February 21, 2026 -**Project:** EQBSL (Evidence-Based Quantum-resistant Belief State Logic) +**Project:** EQBSL (Evidence-Qualified Subjective Logic) --- @@ -12,7 +12,7 @@ EQBSL represents a paradigm shift in how digital systems model trust. Unlike tra By combining **Subjective Logic** (which explicitly models uncertainty), **Zero-Knowledge Proofs** (which ensure privacy), and **Vectorized Evidence** (which captures context), EQBSL enables decentralized systems to reason about trust in a way that is: * **Expressive:** Distinguishing between "trusted", "distrusted", and "unknown". * **Private:** Proving reputation without revealing sensitive interaction history. -* **Resilient:** Resistant to Sybil attacks and quantum decryption threats. +* **Resilient:** Better able to separate established evidence from uncertainty about new or weakly observed actors. --- @@ -29,7 +29,7 @@ This mapping allows systems to calculate trust dynamically: $$b = \frac{r}{r+s+K}, \quad d = \frac{s}{r+s+K}, \quad u = \frac{K}{r+s+K}$$ *(Where $r$ is positive evidence, $s$ is negative evidence, and $K$ is a protocol constant)* -### 2.2 Proof-Carrying Trust (ZK-EBSL) +### 2.2 Proof-Carrying Trust Trust updates are not just computed; they are **proven**. Using Zero-Knowledge Machine Learning (ZKML) techniques, an entity can prove that their new reputation score was correctly calculated from valid evidence without revealing *what* that evidence was (e.g., who they traded with or the specific transaction details). ### 2.3 Vectorized & Hypergraph Trust @@ -143,7 +143,7 @@ sequenceDiagram | **Transitivity** | Centralized Algorithm | Manual / Short paths | **Mathematical Discounting Operators** | | **Privacy** | Low (Centralized DB) | Low (Public Graph) | **High (Zero-Knowledge Proofs)** | | **Sybil Resistance**| ID Verification (KYC) | Reliance on Introducers | **Epistemic Uncertainty (High 'u')** | -| **Quantum Safety** | Low (RSA/ECC) | Low (RSA/ECC) | **High (PQ-Commitments)** | +| **Cryptographic Verifiability** | Low | Low | **High (via optional proof-carrying constructions)** | | **Granularity** | Coarse (Global Score) | Binary | **Context-Aware (Multi-dimensional)** | --- diff --git a/README.md b/README.md index 0b3021f..072e471 100644 --- a/README.md +++ b/README.md @@ -15,12 +15,12 @@ https://eqbsl-demo.netlify.app/ -- **Evidence-Based Subjective Logic (EBSL)** – Move beyond binary trust scores to model uncertainty using evidence tuples (r, s, u) -- **Zero-Knowledge EBSL (ZK-EBSL)** – Privacy-preserving trust computations using zero-knowledge proofs -- **EQBSL** – Quantum-resistant extensions for distributed identity and reputation systems +- **Evidence-Based Subjective Logic (EBSL)** – Map evidence counts `(r, s)` into opinion tuples `(b, d, u, a)` with explicit uncertainty +- **Proof-carrying trust / ZK demos** – Explore how EQBSL state updates could be constrained or attested with zero-knowledge proofs +- **EQBSL (Evidence-Qualified Subjective Logic)** – Extend EBSL with vectorized evidence, operator-defined state evolution, hypergraph support, and embedding-oriented outputs - **Cathexis** – Emotional/motivational trust dynamics -Built with Angular 21 and TypeScript, this tool transforms complex cryptographic and epistemic concepts into intuitive, visual experiences. +Built with Angular 21 and TypeScript, this tool turns the papers' trust operators and research ideas into interactive visual experiences. The web app is primarily an exploration/demo environment; the Rust crate in [rust/](rust/) is the concrete library implementation of the EQBSL pipeline. > **Repository:** [`Steake/EQBSL`](https://github.com/Steake/EQBSL) > **App metadata:** [`metadata.json`](./metadata.json) @@ -36,49 +36,48 @@ Watch this comprehensive introduction to understand how EQBSL revolutionizes tru This video covers: - The fundamental limitations of traditional trust scores - How Evidence-Based Subjective Logic (EBSL) models uncertainty -- Zero-knowledge proofs for privacy-preserving trust verification -- Quantum-resistant extensions for future-proof security +- How proof-carrying / zero-knowledge trust updates fit into the research direction - Real-world applications in decentralized identity and reputation systems --- ## 📖 What is EQBSL? -**EQBSL (Evidence-based Quantum-resistant Belief State Logic)** is a mathematical framework for reasoning about trust, reputation, and epistemic uncertainty in distributed systems. Unlike traditional trust scores (e.g., "85% trusted"), EQBSL models the full epistemic state: +**EQBSL (Evidence-Qualified Subjective Logic)** is a mathematical framework for reasoning about trust, reputation, and epistemic uncertainty in distributed systems. In the terminology used by the papers and primer, EQBSL is **EBSL lifted into vector/tensor evidence, explicit operator-defined state evolution over time, hypergraph-native interactions, and embedding-first outputs, with optional proof-carrying updates**. Unlike traditional trust scores (e.g., "85% trusted"), EQBSL models the full epistemic state: - **Belief (b)** – Evidence supporting a proposition - **Disbelief (d)** – Evidence against a proposition -- **Uncertainty (u)** – Absence of evidence (where b + d + u = 1) +- **Uncertainty (u)** – Absence of evidence (where `b + d + u = 1`) +- **Base rate (a)** – Prior probability when evidence is absent ### Why EQBSL Matters Traditional reputation systems collapse complex trust relationships into a single number, losing critical information about: - **How much evidence** supports the rating (2 reviews vs. 2000 reviews) - **Uncertainty** when data is sparse or conflicting -- **Privacy** when revealing trust judgments -- **Quantum resistance** for future-proof cryptographic security +- **Typed evidence** across different channels or contexts +- **Time and structure** when trust evolves over graphs, hypergraphs, and repeated interactions +- **Privacy** when systems want to attest to trust updates without revealing raw evidence ### Key Innovations 1. **Evidence-Based Reasoning (EBSL)** - Trust opinions are computed from evidence tuples (r, s) representing positive and negative observations. This enables mathematically rigorous: + Trust opinions are computed from evidence counts `(r, s)` representing positive and negative observations, then lifted into opinions `ω = (b, d, u, a)`. This enables mathematically rigorous: - Trust transitivity (A trusts B, B trusts C → A's opinion of C) - Opinion fusion from multiple sources - Uncertainty quantification -2. **Zero-Knowledge Proofs (ZK-EBSL)** - Prove trust properties without revealing: - - The exact trust values - - The evidence supporting them - - The identities involved - - Example: "I can prove this vendor has >80% trust from 50+ verified buyers, without revealing who those buyers are." +2. **EQBSL State & Operators** + EQBSL extends basic EBSL by making the update pipeline explicit: + - Vectorized / tensor evidence per relationship + - Temporal decay and deterministic state evolution + - Hyperedge attribution for multi-party interactions + - Embedding-oriented outputs for downstream ML or policy systems -3. **Quantum Resistance (EQBSL)** - Built on post-quantum cryptographic primitives to ensure trust systems remain secure against quantum computers, protecting: - - Long-term reputation data - - Privacy-preserving proofs - - Identity attestations +3. **Proof-Carrying Trust (optional)** + The papers describe how EQBSL updates can be accompanied by zero-knowledge proofs or commitments so a system can attest that it followed the declared operator without revealing the underlying evidence. + + Example: "I can prove this published trust update respects the EQBSL transition rules without revealing the private interaction log behind it." 4. **Cathexis Integration** Models emotional/motivational dimensions of trust: @@ -90,9 +89,9 @@ Traditional reputation systems collapse complex trust relationships into a singl - **Decentralized Identity**: Web-of-trust without centralized authorities - **Reputation Systems**: Marketplaces, social networks, peer review -- **Secure Voting**: Verifiable ballot privacy with trust in validators +- **Secure Voting / Governance**: Reputation-weighted participation and validator selection - **Supply Chain**: Track product authenticity with uncertainty modeling -- **AI Safety**: Quantify and verify trust in AI agent behaviors +- **AI Safety**: Quantify trust in AI agent behaviors and preserve evidence lineage for downstream verification --- @@ -100,29 +99,78 @@ Traditional reputation systems collapse complex trust relationships into a singl - **EBSL Logic Calculator** – Experiment with belief/disbelief/uncertainty operations - **EQBSL Graph Visualizer** – Model trust networks with AI-assisted node identity generation -- **Zero-Knowledge Demos** – Explore privacy-preserving trust proofs +- **Proof-Carrying Trust Demo** – Explore how private trust updates can be attested - **Cathexis Simulator** – Understand emotional dynamics in trust relationships +- **Reputation-Gated Airdrop Example** – See how reputation scores drive eligibility and payout curves in an applied token distribution flow --- ## 🔬 Research Papers -This implementation is grounded in rigorous academic research. The `Papers/` directory contains: +This implementation is grounded in ongoing academic/research work. The `Papers/` directory contains: -- **EBSL in ZK Reputation Systems** – Foundations of zero-knowledge trust proofs -- **EQBSL+ZK** – Quantum-resistant extensions to EBSL -- **Proof-Carrying-Trust** – Verifiable trust computations +- **EBSL in ZK Reputation Systems** – EBSL integrated into privacy-preserving identity / reputation settings +- **EQBSL+ZK** – The systems-oriented EQBSL extension: vectorized evidence, explicit operators, embeddings, and the bridge to proof-carrying updates +- **Proof-Carrying-Trust** – Zero-knowledge constraints for EQBSL state transitions and verifiable trust computation For formal definitions, proofs, and protocol specifications, explore these papers and the broader [`EQBSL`](https://github.com/Steake/EQBSL) repository. --- +## 🦀 Rust Crate + +A native Rust implementation of the EQBSL library is available in the [rust/](rust/) directory. It provides the EQBSL computational pipeline — from raw evidence to trust embeddings — as a standalone crate suitable for backend services, CLI tools, or embedding in other Rust projects. The current crate focuses on the trust/evidence calculus itself; proof-carrying updates are described in the papers rather than implemented as a proving system here. + +### Features + +- **Opinion Tuple** `(b, d, u, a)` with Consensus `⊕` and Discounting `⊗` operators +- **Evidence-to-Opinion mapping** via `calculate_opinion(r, s, k, a)` +- **m-dimensional evidence tensors** per relationship +- **Temporal decay** (`β^Δt` per channel), **hyperedge attribution**, and **transitive propagation** +- **Node trust embeddings** for downstream ML tasks +- **Full `serde` support** for JSON serialization + +### Installation + +Add to your `Cargo.toml`: + +```toml +[dependencies] +eqbsl = { path = "rust" } +ndarray = "0.15" +``` + +### Quick Start + +```rust +use eqbsl::*; + +// Map evidence to an opinion (10 positive, 0 negative, K=2, base rate=0.5) +let op = calculate_opinion(10.0, 0.0, DEFAULT_K, 0.5); +println!("b={:.3}, u={:.3}, E={:.3}", op.b, op.u, op.expectation()); +// → b=0.833, u=0.167, E=0.917 + +// Transitive trust: A trusts C via B +let op_ab = calculate_opinion(10.0, 0.0, DEFAULT_K, 0.5); +let op_bc = calculate_opinion(5.0, 0.0, DEFAULT_K, 0.5); +let op_ac = op_ab.discount(&op_bc); + +// Fuse two independent witnesses +let op_w = calculate_opinion(8.0, 1.0, DEFAULT_K, 0.5); +let fused = op_ac.fuse(&op_w); +println!("Fused E={:.3}", fused.expectation()); +``` + +For complete documentation, architecture diagrams, and real-world examples (supply chain provenance, DAO voting, AI agent swarm trust, P2P lending), see [`rust/README.md`](./rust/README.md). + +--- + ## 🛠️ Technology Stack - **Angular 21** – Modern reactive framework with zoneless change detection - **TypeScript 5.8** – Type-safe development - **RxJS** – Reactive data flows and state management -- **Tailwind CSS** – Utility-first styling for responsive UI +- **Tailwind CSS** – Utility-first styling for the UI - **Google Generative AI** – AI-assisted trust model exploration - **Angular CLI** – Build tooling and development server @@ -208,6 +256,12 @@ This serves the app using production configuration (equivalent to `ng serve --co ``` EQBSL/ +├── rust/ # Rust crate — native EQBSL library +│ ├── src/ # Library source (opinion, ebsl, model, embedding) +│ ├── examples/ # Runnable examples +│ ├── tests/ # Integration & BDD tests +│ ├── Cargo.toml +│ └── README.md # Full Rust crate documentation ├── Papers/ # Research papers (PDFs) ├── src/ │ ├── app.component.ts # Main Angular app component @@ -288,12 +342,12 @@ Visualize trust networks: - AI-generated identity profiles for realistic scenarios - Real-time trust propagation calculations -### ZK Demo +### Proof-Carrying Trust Demo -Explore zero-knowledge proofs: -- Privacy-preserving trust verification -- Commitment schemes for EBSL opinions -- Proof generation and verification +Explore the proof-carrying trust idea at a conceptual level: +- Privacy-preserving trust verification workflows +- Commitment / proof flow for EQBSL-style state updates +- Simulated proof generation and verification in the UI ### Cathexis @@ -345,6 +399,7 @@ EQBSL is part of a growing ecosystem of Subjective Logic implementations: | Project | Language | Description | |---------|----------|-------------| +| **[rust/ (this repo)](./rust/)** | **Rust** | **Native EQBSL crate — opinions, decay, propagation, embeddings** | | [liamzebedee/retrust](https://github.com/liamzebedee/retrust) | JS/Python | Subjective consensus algorithm with EBSL and sybil control | | [waleedqk/subjective-logic](https://github.com/waleedqk/subjective-logic) | Python | Pure subjective logic library with binomial opinions and fusion | | [atenearesearchgroup/uncertainty-datatypes-python](https://github.com/atenearesearchgroup/uncertainty-datatypes-python) | Python | Academic SL implementation from University of Málaga | @@ -358,13 +413,13 @@ See also: [Subjective Logic on GitHub](https://github.com/topics/subjective-logi ## 📄 License -This project is part of ongoing research by O. C. Hirst [Steake] & Shadowgraph Labs (2025). See the repository for license details. +MIT. See [LICENSE](LICENSE). --- ## 🙏 Acknowledgments -- Based on research in subjective logic, zero-knowledge proofs, and quantum-resistant cryptography +- Based on research in subjective logic, evidence-based trust, and zero-knowledge / proof-carrying verification - Built with modern web technologies for accessible epistemic reasoning - Special thanks to the Angular, TypeScript, and open-source communities diff --git a/angular.json b/angular.json index c102c5e..2d35f74 100644 --- a/angular.json +++ b/angular.json @@ -51,5 +51,8 @@ } } } + }, + "cli": { + "analytics": false } } \ No newline at end of file diff --git a/metadata.json b/metadata.json index 7c6d770..252822d 100644 --- a/metadata.json +++ b/metadata.json @@ -1,5 +1,5 @@ { "name": "EQBSL Explorer", - "description": "Interactive playground for Evidence-Based Subjective Logic, ZK-EBSL, and EQBSL trust systems.", + "description": "Interactive playground for Evidence-Based Subjective Logic, proof-carrying trust, and EQBSL trust systems.", "requestFramePermissions": [] } \ No newline at end of file diff --git a/rust/README.md b/rust/README.md index 7fff2c1..066f5f4 100644 --- a/rust/README.md +++ b/rust/README.md @@ -1,19 +1,153 @@ # EQBSL (Rust Crate) -A Rust implementation of the Evidence-Based Quantum-resistant Belief State Logic (EQBSL) framework. +A Rust implementation of the **Evidence-Qualified Subjective Logic (EQBSL)** framework — a mathematically rigorous system for reasoning about trust, reputation, and epistemic uncertainty in distributed systems. -EQBSL is a mathematical framework for reasoning about trust, reputation, and epistemic uncertainty in distributed systems. It extends Subjective Logic by explicitly modeling trust as a function of observed evidence and providing structured operators for state evolution, temporal decay, and transitive propagation. +Unlike traditional scalar trust scores (e.g., a 5-star rating or a credit score), EQBSL represents trust as a rich **Opinion Tuple** `ω = (b, d, u, a)` that captures not just *how much* you trust something, but *how confident* you are in that assessment. + +--- + +## Table of Contents + +- [Core Concepts](#core-concepts) +- [Architecture](#architecture) +- [Features](#features) +- [Installation](#installation) +- [Quick Start](#quick-start) +- [API Reference](#api-reference) +- [Real-World Examples](#real-world-examples) + - [Supply Chain Provenance](#example-1-supply-chain-provenance) + - [DAO Reputation-Weighted Voting](#example-2-dao-reputation-weighted-voting) + - [AI Agent Swarm Trust](#example-3-ai-agent-swarm-trust) + - [Peer-to-Peer Lending](#example-4-peer-to-peer-lending) +- [Running Tests](#running-tests) +- [License](#license) + +--- + +## Core Concepts + +### The Opinion Tuple `ω = (b, d, u, a)` + +Every trust relationship is represented as a four-component opinion: + +| Component | Symbol | Meaning | +|-----------|--------|---------| +| Belief | `b` | Weight of positive evidence supporting the proposition | +| Disbelief | `d` | Weight of negative evidence against the proposition | +| Uncertainty | `u` | Lack of evidence; starts at 1.0, shrinks as evidence accumulates | +| Base Rate | `a` | Prior probability in the absence of any evidence | + +**Invariant:** `b + d + u = 1.0` always holds. + +### Evidence-to-Opinion Mapping + +Raw evidence counts `(r, s)` map directly to an opinion using the EBSL formula: + +``` +b = r / (r + s + K) +d = s / (r + s + K) +u = K / (r + s + K) +``` + +where `K` is a protocol constant (default `K = 2`) representing the prior weight. As evidence accumulates, `u → 0` and `b` or `d` approaches 1. + +### Expected Probability + +The **expectation** `E(ω) = b + a·u` gives a single scalar summary: your best estimate of the probability that the proposition is true, accounting for both evidence and the prior. + +--- + +## Architecture + +### Evidence-to-Trust Pipeline + +```mermaid +graph TD + subgraph Input["Input Layer"] + RE[Raw Events / Interactions] + HE[Group / Hyperedge Events] + end + + subgraph Evidence["Evidence Layer"] + RE -->|Pairwise extraction| PE["Pairwise Evidence Tensors
e_ij ∈ ℝᵐ"] + HE -->|Hyperedge attribution α| PE + end + + subgraph Decay["Temporal Decay"] + PE -->|"e_ij(t) = β^Δt ⊙ e_ij(t-1)"| DE["Decayed Evidence Tensors"] + end + + subgraph Opinion["Opinion Lifting"] + DE -->|"w_pos · e_ij → r
w_neg · e_ij → s"| RS["Scalar (r, s) pairs"] + RS -->|"EBSL: b=r/(r+s+K)"| OP["Opinion Tuples
ω = (b, d, u, a)"] + end + + subgraph Propagation["Trust Propagation"] + OP -->|"Discounting ⊗"| TR["Transitive Trust
A→C via B"] + OP -->|"Fusion ⊕"| FU["Fused Opinions
(multiple witnesses)"] + end + + subgraph Output["Output Layer"] + TR --> EMB["Node Embeddings
[in_expect, out_expect, ...]"] + FU --> EMB + EMB --> APP["Downstream Applications
Access Control · ML · Governance"] + end + + style Input stroke:#6699cc + style Evidence stroke:#cc9900 + style Decay stroke:#cc6666 + style Opinion stroke:#66cc66 + style Propagation stroke:#9966cc + style Output stroke:#3399cc +``` + +### Transitive Trust (Discounting) + +When A trusts B, and B has an opinion about C, A can derive an *indirect* opinion about C: + +```mermaid +graph LR + A -->|"ω_AB
b=0.83, u=0.17"| B + B -->|"ω_BC
b=0.71, u=0.29"| C + A -.->|"ω_AC = ω_AB ⊗ ω_BC
b=0.59, u=0.41"| C + + style A fill:#d4edda,stroke:#28a745,color:#000000 + style B fill:#fff3cd,stroke:#ffc107,color:#000000 + style C fill:#d1ecf1,stroke:#17a2b8,color:#000000 +``` + +*Note:* Uncertainty increases through each hop — a natural property of transitive inference. + +### Opinion Fusion (Consensus) + +Multiple independent witnesses can be combined via the **Consensus operator ⊕**: + +```mermaid +graph TD + W1["Witness 1
ω₁ = (0.71, 0.0, 0.29, 0.5)"] --> F["Fusion ⊕
ω_fused = (0.83, 0.0, 0.17, 0.5)"] + W2["Witness 2
ω₂ = (0.75, 0.0, 0.25, 0.5)"] --> F + W3["Witness 3
ω₃ = (0.63, 0.08, 0.29, 0.5)"] --> F + F --> R["High-confidence result
E(ω) = 0.91, u = 0.17"] + + style F fill:#d4edda,stroke:#28a745,color:#000000 + style R fill:#d1ecf1,stroke:#17a2b8,color:#000000 +``` + +--- ## Features -- **Subjective Logic Core**: Full implementation of the Opinion tuple (b, d, u, a) with Consensus and Discounting operators. -- **Evidence-Based Mapping**: Direct mapping from evidence counts (r, s) to probabilistic opinions. -- **Vectorized Evidence (Tensors)**: Support for m-dimensional evidence vectors per relationship. +- **Subjective Logic Core**: Full `Opinion` type `(b, d, u, a)` with algebraically correct Consensus `⊕` and Discounting `⊗` operators. +- **Evidence-Based Mapping**: Direct mapping from evidence counts `(r, s)` to probabilistic opinions via `calculate_opinion`. +- **Vectorized Evidence (Tensors)**: `m`-dimensional evidence vectors per relationship — distinguish "late delivery" from "broken item" in a single tensor. - **EQBSL Pipeline**: - - **Temporal Decay**: Exponential decay of evidence over time. - - **Hyperedge Attribution**: Allocation of group interaction evidence to pairwise relationships. - - **Transitive Propagation**: Indirect evidence aggregation across trust networks. -- **Trust Embeddings**: Deterministic node-level embeddings for downstream ML tasks. + - **Temporal Decay**: Exponential decay `β^Δt` per evidence channel. + - **Hyperedge Attribution**: Equal-weight distribution of group interaction evidence to all ordered pairs in the group. + - **Transitive Propagation**: Depth-1 indirect evidence aggregation with top-K witness selection. +- **Trust Embeddings**: Deterministic 6-dimensional node embeddings for downstream ML tasks. +- **Serialization**: Full `serde` support for JSON / any serde-compatible format. + +--- ## Installation @@ -25,43 +159,409 @@ eqbsl = { path = "path/to/eqbsl" } ndarray = "0.15" ``` +--- + ## Quick Start ```rust use eqbsl::*; fn main() { - // 1. Create an opinion from evidence + // 1. Map evidence to an opinion // 10 positive observations, 0 negative, K=2, base rate=0.5 let op_ab = calculate_opinion(10.0, 0.0, 2.0, 0.5); - println!("Opinion A -> B: {:?}", op_ab); + println!("Opinion A→B: {:?}", op_ab); + // Opinion { b: 0.833, d: 0.0, u: 0.167, a: 0.5 } + println!("Expectation: {:.3}", op_ab.expectation()); // 0.917 - // 2. Transitive Trust (Discounting) + // 2. Transitive Trust via Discounting (A trusts C through B) let op_bc = calculate_opinion(5.0, 0.0, 2.0, 0.5); let op_ac = op_ab.discount(&op_bc); - println!("Opinion A -> C: {:?}", op_ac); + println!("Opinion A→C (via B): {:?}", op_ac); - // 3. Opinion Fusion (Consensus) + // 3. Opinion Fusion: combine two independent witnesses let op_witness = calculate_opinion(8.0, 1.0, 2.0, 0.5); let op_fused = op_ac.fuse(&op_witness); println!("Fused Opinion: {:?}", op_fused); + println!("Fused Expectation: {:.3}", op_fused.expectation()); } ``` -## Running Tests +--- -```bash -cargo test +## API Reference + +### `Opinion` + +```rust +pub struct Opinion { pub b: f64, pub d: f64, pub u: f64, pub a: f64 } +``` + +| Method | Description | +|--------|-------------| +| `Opinion::new(b, d, u, a)` | Construct and auto-normalize so `b+d+u=1` | +| `opinion.expectation()` | Returns `b + a·u` — best scalar estimate | +| `op1.fuse(&op2)` | Consensus operator `⊕`: combine two independent opinions | +| `op1.discount(&op2)` | Discounting operator `⊗`: propagate trust transitively | + +### `calculate_opinion(r, s, k, a) -> Opinion` + +Maps raw evidence counts to an opinion. Pass `DEFAULT_K` (= 2.0) for the standard EBSL prior weight. + +### `Params` + +Global system configuration. Call `params.validate()` before use. + +```rust +Params { + k: 2.0, // Prior weight (EBSL constant K) + w_pos: array![1.0, 0.5], // Positive evidence channel weights + w_neg: array![0.0, 0.5], // Negative evidence channel weights + decay_beta: array![0.9, 0.9], // Per-channel decay factor β ∈ (0,1] + damping_lambda: 0.5, // Transitive propagation damping + witness_top_k: 10, // Max witnesses per node for propagation +} +``` + +### Pipeline Functions + +| Function | Description | +|----------|-------------| +| `State::new(t)` | Create an empty state at time `t` | +| `decay_state(&mut state, params, dt_steps)` | Apply `β^Δt` decay to all evidence | +| `attribute_hyperedges_to_pairs(&mut state)` | Distribute hyperedge evidence to pairwise edges | +| `compute_opinions(&state, params, base_rate)` | Lift all edges to `Opinion` tuples | +| `depth1_propagation_rs(nodes, opinions, edges, params)` | Add transitive evidence contributions | +| `embed_nodes_basic(nodes, opinions)` | Compute 6-dim trust embeddings per node | + +--- + +## Real-World Examples + +### Example 1: Supply Chain Provenance + +A buyer wants to know whether a product is authentic. Each step in the supply chain (manufacturer → distributor → retailer) adds evidence. Evidence decays over time. + +```mermaid +sequenceDiagram + participant M as Manufacturer + participant D as Distributor + participant R as Retailer + participant B as Buyer + + M->>D: Ships batch (adds positive evidence r=5) + Note over D: ω(M→D) = (0.71, 0.0, 0.29, 0.5) + + D->>R: Delivers on time (r=3, s=0) + Note over R: ω(D→R) = (0.60, 0.0, 0.40, 0.5) + + R->>B: Sells item + B->>B: Derives transitive trust
ω(M→B) via D and R + Note over B: E(ω) = 0.72, u = 0.49
Authentic but uncertain path +``` + +```rust +use eqbsl::*; + +fn supply_chain_example() { + // Multi-channel evidence: [quality_checks, on_time_deliveries] + let params = Params { + k: 2.0, + w_pos: array![0.7, 0.3], // quality matters more + w_neg: array![0.5, 0.5], + decay_beta: array![0.95, 0.90], // quality decays slower than timeliness + damping_lambda: 0.7, + witness_top_k: 5, + }; + + params.validate().expect("Invalid params"); + + let mut state = State::new(0); + state.edges.insert( + ("manufacturer".into(), "distributor".into()), + array![5.0, 2.0], + ); + // Distributor → Retailer: 3 quality checks, 4 on-time deliveries + state.edges.insert( + ("distributor".into(), "retailer".into()), + array![3.0, 4.0], + ); + + // Simulate 10 days of decay + decay_state(&mut state, ¶ms, 10); + + // Lift to opinions + let opinions = compute_opinions(&state, ¶ms, 0.5); + + // Direct trust: manufacturer → distributor + let op_md = opinions[&("manufacturer".into(), "distributor".into())]; + println!("Manufacturer→Distributor: b={:.3}, u={:.3}, E={:.3}", + op_md.b, op_md.u, op_md.expectation()); + + // Transitive trust: manufacturer → retailer via distributor + let nodes = vec!["manufacturer".to_string(), "distributor".to_string(), "retailer".to_string()]; + let propagated = depth1_propagation_rs(&nodes, &opinions, &state.edges, ¶ms); + let &(r, s) = propagated.get(&("manufacturer".into(), "retailer".into())).unwrap(); + let op_mr = calculate_opinion(r, s, params.k, 0.5); + println!("Manufacturer→Retailer (transitive): b={:.3}, u={:.3}, E={:.3}", + op_mr.b, op_mr.u, op_mr.expectation()); +} +``` + +--- + +### Example 2: DAO Reputation-Weighted Voting + +In a decentralized autonomous organization, members vote on proposals. Rather than "one token one vote" (plutocracy) or "one person one vote" (Sybil-vulnerable), EQBSL weights votes by each member's *certainty-adjusted reputation*. + +```mermaid +graph LR + subgraph Members + A["Alice
b=0.91, u=0.09
(veteran, high trust)"] + B["Bob
b=0.62, u=0.25
(active, moderate trust)"] + C["Carol
b=0.33, u=0.67
(new member, high uncertainty)"] + end + + subgraph Proposal["Proposal: Upgrade Protocol"] + V["Reputation-Weighted Vote
weight = b × (1 - u)"] + end + + A -->|"weight = 0.83"| V + B -->|"weight = 0.47"| V + C -->|"weight = 0.11"| V + + V --> R["Result: Passed
(all members favor)"] + + style A fill:#d4edda,stroke:#28a745,color:#000000 + style C fill:#fff3cd,stroke:#ffc107,color:#000000 + style R fill:#d1ecf1,stroke:#17a2b8,color:#000000 +``` + +```rust +use eqbsl::*; + +struct Member { name: String, opinion: Opinion } + +fn dao_voting_example() { + // Opinions derived from on-chain interaction history + let members = vec![ + Member { name: "alice".into(), opinion: calculate_opinion(20.0, 0.0, 2.0, 0.5) }, + Member { name: "bob".into(), opinion: calculate_opinion(5.0, 1.0, 2.0, 0.5) }, + Member { name: "carol".into(), opinion: calculate_opinion(1.0, 0.0, 2.0, 0.5) }, + ]; + + // Vote weight: belief × certainty (1 - uncertainty) + let total_weight: f64 = members.iter() + .map(|m| m.opinion.b * (1.0 - m.opinion.u)) + .sum(); + + println!("=== DAO Vote: Protocol Upgrade ==="); + for m in &members { + let weight = m.opinion.b * (1.0 - m.opinion.u); + println!(" {}: E={:.3}, weight={:.3} ({:.1}%)", + m.name, + m.opinion.expectation(), + weight, + 100.0 * weight / total_weight); + } + + // Fuse all member opinions to get the DAO's collective reputation state. + // This consensus opinion represents how much the group as a whole is trusted + // by an outside observer, not the vote outcome itself. + let consensus = members.iter().skip(1).fold(members[0].opinion, |acc, m| acc.fuse(&m.opinion)); + println!("DAO collective reputation: b={:.3}, u={:.3}, E={:.3}", + consensus.b, consensus.u, consensus.expectation()); +} +``` + +--- + +### Example 3: AI Agent Swarm Trust + +In a swarm of AI agents performing distributed inference tasks, agents accumulate positive evidence for peers that produce correct outputs and negative evidence for peers that hallucinate or behave maliciously. + +```mermaid +graph TD + subgraph Swarm["Agent Swarm (t=0)"] + A1["Agent-1
Coordinator"] + A2["Agent-2
Reliable"] + A3["Agent-3
Unreliable"] + A4["Agent-4
New Agent"] + end + + A1 -->|"r=12, s=1
b=0.80"| A2 + A1 -->|"r=2, s=8
d=0.67"| A3 + A1 -->|"r=0, s=0
u=1.0"| A4 + + subgraph Decision + D["Trust-Gated Task Assignment
Only agents with E > 0.7
and u < 0.3 receive critical tasks"] + end + + A2 -->|"E=0.90 ✓"| D + A3 -->|"E=0.19 ✗
Quarantined"| D + A4 -->|"E=0.50 ?
Probation"| D + + style A3 fill:#f8d7da,stroke:#dc3545,color:#000000 + style A2 fill:#d4edda,stroke:#28a745,color:#000000 + style A4 fill:#fff3cd,stroke:#ffc107,color:#000000 +``` + +```rust +use eqbsl::*; + +fn ai_swarm_trust_example() { + // Evidence channels: [task_correctness, response_latency_ok, format_compliance] + let params = Params { + k: 2.0, + w_pos: array![0.6, 0.2, 0.2], + w_neg: array![0.7, 0.1, 0.2], + decay_beta: array![0.98, 0.95, 0.99], // correctness decays slowly + damping_lambda: 0.6, + witness_top_k: 3, + }; + + let mut state = State::new(100); // t=100 (current step) + + // Coordinator's evidence about peers. + // NOTE: The diagram above uses simplified scalar (r, s) counts for illustration. + // The actual computation uses 3-channel weighted evidence vectors, so the + // numeric opinion values produced by the code will differ from the diagram labels. + state.edges.insert(("coord".into(), "agent_2".into()), array![12.0, 8.0, 10.0]); + state.edges.insert(("coord".into(), "agent_3".into()), array![2.0, 9.0, 1.0]); + state.edges.insert(("coord".into(), "agent_4".into()), array![0.0, 0.0, 0.0]); + + // Group task: agents 2 and 3 collaborated on a task + let mut h = std::collections::HashMap::new(); + h.insert("agent_2".to_string(), "executor".to_string()); + h.insert("agent_3".to_string(), "executor".to_string()); + state.hypers.insert("task_42".into(), Hyperedge { + hid: "task_42".into(), + nodes: vec!["agent_2".into(), "agent_3".into()], + roles: h, + e: array![1.0, 0.5, 1.0], // positive group evidence + }); + attribute_hyperedges_to_pairs(&mut state); + + let opinions = compute_opinions(&state, ¶ms, 0.5); + + println!("=== AI Swarm Trust Assessment ==="); + let agents = ["agent_2", "agent_3", "agent_4"]; + for agent in &agents { + let key = ("coord".to_string(), agent.to_string()); + if let Some(op) = opinions.get(&key) { + let status = if op.expectation() > 0.7 && op.u < 0.3 { + "✓ TRUSTED - eligible for critical tasks" + } else if op.expectation() < 0.4 { + "✗ QUARANTINED" + } else { + "? PROBATION - monitoring" + }; + println!(" {}: b={:.3}, d={:.3}, u={:.3}, E={:.3} => {}", + agent, op.b, op.d, op.u, op.expectation(), status); + } else { + println!(" {}: no evidence => u=1.0, E=0.5 => ? PROBATION", agent); + } + } +} ``` -## Examples +--- + +### Example 4: Peer-to-Peer Lending + +A decentralized lending protocol needs creditworthiness scores. EQBSL models credit as a belief state that accumulates over repayment history and decays over time. -Check the `examples/` directory for more detailed usage patterns, including the full EQBSL pipeline with evidence tensors and decay. +```mermaid +sequenceDiagram + participant B as Borrower + participant P as Protocol + participant L1 as Lender 1 + participant L2 as Lender 2 + + Note over B, P: Borrower has 8 successful repayments, 1 late payment + B->>P: Request loan (collateral = f(u)) + P->>P: Compute ω_credit = calculate_opinion(r=8, s=1, k=2, a=0.5) + Note over P: b=0.73, d=0.09, u=0.18, E=0.82 + + P->>L1: Publish anonymized opinion commitment + P->>L2: Publish anonymized opinion commitment + + L1->>L1: Direct evidence: r=5, s=0 → ω₁=(0.71,0,0.29,0.5) + L2->>L2: Direct evidence: r=3, s=1 → ω₂=(0.50,0.17,0.33,0.5) + + L1->>P: Submit fused opinion + L2->>P: Submit fused opinion + P->>P: Fuse all opinions → ω_final + Note over P: E(ω_final) = 0.88, u = 0.09
High confidence → low collateral required + + P-->>B: Loan approved (collateral = 1 - E = 12%) +``` + +```rust +use eqbsl::*; + +fn p2p_lending_example() { + // Borrower's direct repayment history: 8 on-time, 1 late + let direct = calculate_opinion(8.0, 1.0, 2.0, 0.5); + println!("Borrower credit (direct): b={:.3}, d={:.3}, u={:.3}, E={:.3}", + direct.b, direct.d, direct.u, direct.expectation()); + + // Two lenders have independent evidence + let lender1 = calculate_opinion(5.0, 0.0, 2.0, 0.5); + let lender2 = calculate_opinion(3.0, 1.0, 2.0, 0.5); + + // Fuse all three independent opinions + let fused = direct.fuse(&lender1).fuse(&lender2); + println!("Fused credit opinion: b={:.3}, d={:.3}, u={:.3}, E={:.3}", + fused.b, fused.d, fused.u, fused.expectation()); + + // Required collateral inversely proportional to trust certainty + let collateral_rate = 1.0 - fused.expectation(); + println!("Required collateral rate: {:.1}%", collateral_rate * 100.0); + // → 12.3% collateral (high trust, low uncertainty) + + // Compare: new borrower (no history) requires much more collateral + let new_borrower = calculate_opinion(0.0, 0.0, 2.0, 0.5); + let new_collateral = 1.0 - new_borrower.expectation(); + println!("New borrower collateral rate: {:.1}%", new_collateral * 100.0); + // → 50.0% collateral (maximum uncertainty) +} +``` + +--- + +## Running Tests ```bash +# Run all tests +cargo test + +# Run a specific example cargo run --example basic_usage + +# Run with output visible +cargo test -- --nocapture ``` +--- + +## Comparison: EQBSL vs. EBSL and Traditional Trust Systems + +| Feature | Traditional Score | Web-of-Trust | EBSL | EQBSL | +|:--------|:-----------------|:-------------|:-----|:------| +| Representation | Scalar (e.g., 4.2 ★) | Boolean | Opinion tuple `(b, d, u, a)` | **Tuple (b, d, u, a)** | +| Uncertainty modeling | ✗ | ✗ | ✓ Explicit via `u` | **✓ Explicit via `u`** | +| Evidence dimensionality | Scalar | None | Scalar evidence counts `(r, s)` | **m-dimensional tensors** | +| Transitivity | Proprietary | Manual chains | Discounting `⊗` | **Formal Discounting ⊗** | +| Multi-witness fusion | Weighted avg | None | Consensus `⊕` | **Algebraic Consensus ⊕** | +| Temporal decay | Ad-hoc | None | Not built-in | **Per-channel β^Δt** | +| Sybil resistance | KYC | Introducer trust | Partial† (via uncertainty) | **Partial† (via uncertainty)** | +| Serializable / portable | Partial | ✗ | Varies by implementation | **✓ Full serde support** | + +† EQBSL does not itself provide Sybil resistance; it computes trust (opinions) over observed events. Its explicit modeling of epistemic uncertainty about new or unknown identities can inform downstream Sybil-resistance policies, but it is not a Sybil-resistance mechanism on its own. + +--- + ## License MIT diff --git a/src/app.component.ts b/src/app.component.ts index e0b5418..7061ea8 100644 --- a/src/app.component.ts +++ b/src/app.component.ts @@ -5,6 +5,7 @@ import { EbslPlaygroundComponent } from './components/ebsl-playground.component' import { EqbslGraphComponent } from './components/eqbsl-graph.component'; import { ZkDemoComponent } from './components/zk-demo.component'; import { CathexisComponent } from './components/cathexis.component'; +import { AirdropExampleComponent } from './components/airdrop-example.component'; import { PapersComponent } from './components/papers.component'; import { PaperDetailComponent } from './components/paper-detail.component'; @@ -18,6 +19,7 @@ import { PaperDetailComponent } from './components/paper-detail.component'; EqbslGraphComponent, ZkDemoComponent, CathexisComponent, + AirdropExampleComponent, PapersComponent, PaperDetailComponent ], @@ -37,6 +39,7 @@ import { PaperDetailComponent } from './components/paper-detail.component'; @case ('eqbsl') { } @case ('zk') { } @case ('cathexis') { } + @case ('airdrop') { } @case ('papers') { } @case ('paper-detail') { +
+
+ Applied Example +
+

Reputation-Gated Airdrops

+

+ This example adapts the flow from the Shadowgraph Reputation-Gated Airdrop project into the EQBSL Explorer. + It shows how evidence becomes an opinion, how that opinion becomes a scaled reputation score, and how that score gates an airdrop claim. +

+ + View reference implementation + + + + + +
+ +
+
+
Expectation
+
{{ expectation().toFixed(3) }}
+
Expected trust probability from the current opinion.
+
+
+
Scaled score
+
{{ scaledScore() | number:'1.0-0' }}
+
Mapped into the airdrop’s 0..1,000,000 score range.
+
+
+
Eligibility
+
+ {{ eligible() ? 'Pass' : 'Fail' }} +
+
Threshold is {{ floorScore | number:'1.0-0' }} for this campaign.
+
+
+
Quoted payout
+
{{ payoutTokens().toFixed(2) }}
+
Current payout result using the selected claim path and curve.
+
+
+ +
+
+
+

1. Claimant evidence

+

+ Think of this as a simple reputation record. Positive evidence means "things this wallet did well." Negative evidence means "things that count against trust." +

+
+ +
+
+
Good history
+
{{ r() }}
+
Derived trust-supporting evidence total
+
+
+
Bad history
+
{{ s() }}
+
Derived trust-reducing evidence total
+
+
+ +
+
+ + {{ positiveAttestations() }} +
+ +

How many credible attestations or endorsements the claimant received from other parties.

+
+ +
+
+ + {{ successfulActions() }} +
+ +

Completed deliveries, valid prior claims, or other successful on-chain / off-chain outcomes.

+
+ +
+
+ + {{ negativeReports() }} +
+ +

Complaints, bad attestations, disputes, or moderation-relevant negative outcomes.

+
+ +
+
+ + {{ fraudFlags() }} +
+ +

Heavier-weight negative signals such as sybil detection, fraud markers, or severe policy violations.

+
+ +
+
+ +
+ + +
+

Switch between signed claims and proof-based claims.

+
+ +
+ + +

Controls how quickly higher reputation reaches maximum payout.

+
+
+ +
+
+ + {{ reputationAgeDays() }} +
+ +

The reference ZK path uses a freshness window; the example defaults to 7 days.

+
+
+ +
+
+

2. Derived reputation + claim outcome

+

+ Parameters below mirror the reference project: score scale 0..1,000,000, floor 600,000, cap 1,000,000, payout range 100..1000 tokens. +

+
+ +
+
+
Opinion
+
+
b{{ opinion().b.toFixed(3) }}
+
d{{ opinion().d.toFixed(3) }}
+
u{{ opinion().u.toFixed(3) }}
+
E(ω){{ expectation().toFixed(3) }}
+
+
+ +
+
Scaled score
+
{{ scaledScore() | number:'1.0-0' }}
+
Eligibility threshold: {{ floorScore | number:'1.0-0' }}
+
Cap for max payout: {{ capScore | number:'1.0-0' }}
+
+
+ +
+
+
+

Score ramp

+

Where the current score sits relative to floor and cap.

+
+
+ Below floor + Eligible ramp + Max payout zone +
+
+ +
+
+
+
+
+
+
+
+
+ {{ scaledScore() | number:'1.0-0' }} +
+
Floor {{ floorScore | number:'1.0-0' }}
+
Cap {{ capScore | number:'1.0-0' }}
+
+
+
+ +
+
+
Eligibility
+
+ {{ eligible() ? 'Eligible to claim' : 'Below claim threshold' }} +
+

+ {{ eligibilityMessage() }} +

+
+ +
+
Freshness
+
+ {{ freshEnough() ? 'Reputation window valid' : 'Reputation is stale' }} +
+

+ {{ freshnessMessage() }} +

+
+
+ +
+
+

Quoted payout

+ + {{ claimPath() === 'zk' ? 'ZK path' : 'ECDSA path' }} + +
+
+
+
{{ payoutTokens().toFixed(2) }}
+
Tokens
+
+

+ {{ claimPathDescription() }} +

+
+
+ +
+
+

How the score is assembled

+

+ In a real system, these values would come from attestations, claim history, dispute data, fraud heuristics, and timestamps. This demo compresses that into a few believable source counts. +

+
+ +
+
+
Source inputs
+
+
Positive attestations{{ positiveAttestations() }}
+
Successful prior actions{{ successfulActions() }}
+
Negative reports{{ negativeReports() }}
+
Fraud / sybil flags{{ fraudFlags() }}
+
+
+ +
+
Aggregation rule
+
+
+
r (supporting evidence)
+
{{ positiveAttestations() }} + {{ successfulActions() }} = {{ r() }}
+
+
+
s (negative evidence)
+
{{ negativeReports() }} + 2 × {{ fraudFlags() }} = {{ s() }}
+
+
+
+
+ +
+
+
Opinion
+
({{ opinion().b.toFixed(2) }}, {{ opinion().d.toFixed(2) }}, {{ opinion().u.toFixed(2) }})
+
Belief, disbelief, uncertainty
+
+
+
Expectation
+
{{ expectation().toFixed(3) }}
+
Scalar trust estimate
+
+
+
Scaled airdrop score
+
{{ scaledScore() | number:'1.0-0' }}
+
Mapped into campaign thresholds
+
+
+
+
+
+ +
+
+
+
+

3. End-to-end flow

+

+ The airdrop pipeline is easier to read as a sequence: reputation input, trust computation, proof or signature preparation, eligibility checks, then payout. +

+
+
+ +
+ @for (step of steps; track step.title) { +
+
+
+
+ {{ step.step.replace('Step ', '') }} +
+ @if (step.step !== 'Step 5') { +
+ } +
+ +
+
{{ step.step }}
+
{{ step.title }}
+

{{ step.body }}

+
+
+
+ } +
+
+ +
+

Reference parameters

+
+
Score scale0 to 1,000,000
+
Floor score600,000
+
Cap score1,000,000
+
Min payout100 tokens
+
Max payout1000 tokens
+
Default curveSQRT
+
ZK freshness window7 days
+
+ +
+ The explorer example stays focused on the trust and eligibility logic. The full reference project adds the SvelteKit frontend, + proof worker pipeline, on-chain verifier, and claim contracts. +
+
+
+ + ` +}) +export class AirdropExampleComponent { + private readonly ebsl = inject(EbslService); + + readonly floorScore = 600_000; + readonly capScore = 1_000_000; + readonly minPayout = 100; + readonly maxPayout = 1000; + readonly maxReputationAgeDays = 7; + readonly floorPercent = (this.floorScore / 1_000_000) * 100; + readonly capPercent = (this.capScore / 1_000_000) * 100; + readonly activeButtonClass = 'rounded-lg border border-indigo-500/40 bg-indigo-500/15 text-indigo-300 px-3 py-2 text-sm font-medium transition-colors'; + readonly inactiveButtonClass = 'rounded-lg border border-slate-700 bg-slate-900 text-slate-400 px-3 py-2 text-sm font-medium hover:text-white hover:bg-slate-800 transition-colors'; + + readonly positiveAttestations = signal(4); + readonly successfulActions = signal(4); + readonly negativeReports = signal(1); + readonly fraudFlags = signal(0); + readonly claimPath = signal('zk'); + readonly curve = signal('SQRT'); + readonly reputationAgeDays = signal(3); + + readonly r = computed(() => this.positiveAttestations() + this.successfulActions()); + readonly s = computed(() => this.negativeReports() + (2 * this.fraudFlags())); + + readonly opinion = computed(() => this.ebsl.calculateOpinion(this.r(), this.s(), 0.5)); + readonly expectation = computed(() => this.ebsl.expectedProbability(this.opinion())); + readonly scaledScore = computed(() => Math.round(this.expectation() * 1_000_000)); + readonly scorePercent = computed(() => Math.max(0, Math.min(100, this.scaledScore() / 10_000))); + readonly eligible = computed(() => this.scaledScore() >= this.floorScore); + readonly freshEnough = computed(() => this.reputationAgeDays() <= this.maxReputationAgeDays); + readonly payoutTokens = computed(() => { + if (!this.eligible()) { + return 0; + } + + const score = this.scaledScore(); + const normalized = Math.max(0, Math.min(1, (score - this.floorScore) / (this.capScore - this.floorScore))); + + let curveValue = normalized; + switch (this.curve()) { + case 'SQRT': + curveValue = Math.sqrt(normalized); + break; + case 'QUADRATIC': + curveValue = normalized * normalized; + break; + default: + curveValue = normalized; + } + + return this.minPayout + (this.maxPayout - this.minPayout) * curveValue; + }); + readonly claimPathDescription = computed(() => this.claimPath() === 'zk' + ? 'The claimant first proves reputation to the verifier contract, then claims through the ZK airdrop path if the score is fresh enough.' + : 'The claimant submits a signed artifact authorizing a payout derived from the same reputation score and payout curve.' + ); + readonly eligibilityMessage = computed(() => this.eligible() + ? `Score ${this.scaledScore().toLocaleString()} clears the campaign floor of ${this.floorScore.toLocaleString()}.` + : `Score ${this.scaledScore().toLocaleString()} is below the campaign floor of ${this.floorScore.toLocaleString()}.` + ); + readonly freshnessMessage = computed(() => this.claimPath() === 'zk' + ? (this.freshEnough() + ? `Age ${this.reputationAgeDays()}d is within the ${this.maxReputationAgeDays}-day freshness window.` + : `Age ${this.reputationAgeDays()}d exceeds the ${this.maxReputationAgeDays}-day freshness window used by the ZK claim path.`) + : 'The ECDSA path does not require the same freshness check in this simplified example.' + ); + + readonly steps = [ + { + step: 'Step 1', + title: 'Load attestations', + body: 'Trust evidence is gathered from the network and organized into the claimant’s local reputation inputs.' + }, + { + step: 'Step 2', + title: 'Compute EBSL opinion', + body: 'Evidence is fused into an opinion tuple and converted into an expectation score for gating decisions.' + }, + { + step: 'Step 3', + title: 'Prepare proof or signature', + body: 'The ECDSA path signs an authorization artifact; the ZK path prepares a privacy-preserving proof of the reputation result.' + }, + { + step: 'Step 4', + title: 'Verify eligibility', + body: 'The campaign checks threshold, payout curve, and, for the ZK path, whether the verified reputation is still fresh.' + }, + { + step: 'Step 5', + title: 'Claim payout', + body: 'Eligible users receive a payout between the configured minimum and maximum based on the scaled reputation score.' + } + ]; + + toNumber(event: Event): number { + return Number((event.target as HTMLInputElement).value); + } + + toCurve(event: Event): PayoutCurve { + return (event.target as HTMLSelectElement).value as PayoutCurve; + } +} diff --git a/src/components/intro.component.ts b/src/components/intro.component.ts index da3d8d1..3da2ecf 100644 --- a/src/components/intro.component.ts +++ b/src/components/intro.component.ts @@ -33,11 +33,11 @@ import { Component, ChangeDetectionStrategy, output } from '@angular/core';

- This video covers the fundamental limitations of traditional trust scores, EBSL's uncertainty modeling, zero-knowledge proofs, quantum-resistant extensions, and real-world applications. + This video covers the limitations of traditional trust scores, EBSL uncertainty modeling, proof-carrying trust, and applied reputation use cases.

-
+

1. EBSL Logic

@@ -81,6 +81,17 @@ import { Component, ChangeDetectionStrategy, output } from '@angular/core'; Generate Handles →
+ +
+
+

5. Reputation-Gated Airdrops

+

+ Applied use case. See how EBSL/EQBSL reputation becomes an eligibility score, a payout curve, and either an ECDSA or ZK claim path. +

+
+ Explore Airdrop Example → +
+
diff --git a/src/components/nav.component.ts b/src/components/nav.component.ts index 682d27d..f98669e 100644 --- a/src/components/nav.component.ts +++ b/src/components/nav.component.ts @@ -64,6 +64,7 @@ import { CommonModule } from '@angular/common'; .menu-item:nth-child(4) { animation-delay: 0.2s; } .menu-item:nth-child(5) { animation-delay: 0.25s; } .menu-item:nth-child(6) { animation-delay: 0.3s; } + .menu-item:nth-child(7) { animation-delay: 0.35s; } `], template: `
diff --git a/src/components/paper-detail.component.ts b/src/components/paper-detail.component.ts index 9ba8d31..dc080d8 100644 --- a/src/components/paper-detail.component.ts +++ b/src/components/paper-detail.component.ts @@ -307,8 +307,8 @@ export class PaperDetailComponent { }, ] }, - 'eqbsl-quantum': { - id: 'eqbsl-quantum', + 'eqbsl-against-trust-scores': { + id: 'eqbsl-against-trust-scores', title: 'EQBSL: Against Trust Scores', authors: 'Oliver C. Hirst, Independent Researcher (December 2025)', abstract: 'Most "trust scores" are numerology with a user interface: confident decimals that conceal their own provenance. Evidence-Based Subjective Logic (EBSL) is a corrective, because it refuses to treat trust as a mystical scalar and instead anchors it in manipulable, auditable evidence. This paper presents EQBSL, a systems-oriented extension that lifts evidence-based trust into a structured, vectorised, operator-defined form suitable for dynamic graphs and hypergraphs, and for downstream machine learning via stable trust embeddings.', diff --git a/src/components/papers.component.ts b/src/components/papers.component.ts index 55b14d4..1362b0b 100644 --- a/src/components/papers.component.ts +++ b/src/components/papers.component.ts @@ -59,8 +59,8 @@ import { CommonModule } from '@angular/common';

Additional Resources

- These papers represent ongoing research into EQBSL (Extended Quantum Belief State Logic), - zero-knowledge proofs, and trust-based systems. For the latest updates and source code, + These papers represent ongoing research into EQBSL, proof-carrying trust, + and evidence-based trust systems. For the latest updates and source code, visit our GitHub repository.