Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Contexto Delimitado: Economia & Sociedade (O Tecido)

Este contexto rege as trocas de recursos, incentivos sociais e a governança soberana do ecossistema.

classDiagram
    direction TB

    class BarterEngine {
        <<Economic_Heart>>
        - balance: Joule
        - creditLimitsSuspended: bool
        + charge(Joule, DreMultiplier) bool
        + credit(Joule, DreMultiplier)
        + processMicropayment(Joule) (bool, Joule)
        + settleViaLottery(Ticket)
    }

    class JouleLottery {
        <<Probabilistic_Micropayments>>
        - winningProbability: float
        + drawTicket() bool
        + calculateFaceValue(Joule) Joule
    }

    class DreMultiplier {
        <<Resource_Efficiency_Value>>
        - hardwarePassport: HardwarePassport
        - energyTwin: EnergySourceTwin
        + compute() float
        + Bhw() float
        + Ben() float
        + Bsoc(SocialTag) float
        + Bsus() float
    }

    class WasmExecutor {
        <<Wasmtime_Fuel_Metered>>
        - fuelBudget: u64
        - antibodyFilters: List~WasmPlasmid~
        + invoke(WasmPlasmid, IoATask) IntentReceipt
        + consumedJoules() Joule
    }

    class HardwarePassport {
        <<Circular_Economy>>
        - deviceAge: int
        - rootOfTrust: Attestation
        + getAgeBonus() float
    }

    class EnergySourceTwin {
        <<Sustainability>>
        - source: [Solar, Wind, Hydro, Grid]
        - renewablePercentage: float
        + getEnergyBonus() float
    }

    class MycorrhizalSymbiosis {
        <<Altruistic_Osmosis>>
        - crisisZone: GeoTag
        - isOsmosisActive: bool
        + suspendCreditLimits(BarterEngine)
        + triggerResourceOsmosis()
    }

    class GovernanceModule {
        <<Sovereignty>>
        - registry: PaebiruRegistry
        - dao: Dao
        + castVote(Proposal)
        + registerNode(HardwarePassport)
    }

    class Dao {
        <<DRE_Weighted_Governance>>
        - proposals: Map~u64, Proposal~
        + createProposal(u64, String)
        + vote(u64, bool) float
        + voting_power(node) float
        + enact(Proposal)
    }
    %% O exercício do poder de voto é realizado via Atestação Privada.

    class DataContract {
        <<CDDL_Executable_Schema>>
        - id: ContentHash
        - cddl_schema: String
        - zk_fields: Vec~FieldName~
        + validate_payload(bytes) Result
        + require_zk_proof(field, circuit)
    }

    class DecentralizedOracle {
        <<FROST_kofn_Aggregation>>
        - k: u32
        - n: u32
        - reports: Vec~OracleReport~
        + aggregate() AggregatedFeed
        + median_value() f64
        + threshold_sign(FrostGroup)
    }

    class IsingMatcher {
        <<Combinatorial_Optimizer>>
        - problem: IsingProblem
        - solver: IsingSolver
        + match_tasks_to_nodes() Assignment
        + match_ev_slots() SlotAssignment
    }

    class LandauerLedger {
        <<Thermodynamic_Audit>>
        - bit_erasures: u64
        - temperature_k: f64
        + record_erasures(bits: u64)
        + minimum_joules() f64
    }

    class PaebiruRegistry {
        <<Staking>>
        - chainState: IPLD_CID
    }

    BarterEngine *-- JouleLottery
    BarterEngine ..> DreMultiplier : aplica em charge/credit
    DreMultiplier *-- HardwarePassport
    DreMultiplier *-- EnergySourceTwin
    WasmExecutor ..> BarterEngine : charge(joules, dre)
    BarterEngine --> MycorrhizalSymbiosis : suspensão por osmose
    GovernanceModule --> PaebiruRegistry : registro on-chain
    GovernanceModule *-- Dao
    GovernanceModule --> HardwarePassport : validação
    Dao ..> DreMultiplier : voting_power = DRE * stake
    ZeroTrustPipeline *-- DataContractGate
    DataContractGate *-- DataContract
    DecentralizedOracle ..> ZeroTrustPipeline : feeds_signed_attestations
    WasmExecutor ..> LandauerLedger : records bit_erasures
    IsingMatcher ..> BarterEngine : optimal task assignment
    IsingMatcher ..> EntropySource : stochastic annealing

Cobrança por Fuel WASM

Cada execução de WasmPlasmid no WasmExecutor (conforme a RFC 010) consome fuel proporcional ao trabalho computacional. Ao final da invocação, o executor traduz fuel em Joule (1 Joule ≈ 100.000 unidades de fuel) e debita o BarterEngine (conforme a RFC 005) aplicando o DreMultiplier do nó. O JouleLottery decide estatisticamente quais cobranças são materializadas como tickets persistidos.

sequenceDiagram
    participant AA as AbaporuActor
    participant Exec as WasmExecutor
    participant DRE as DreMultiplier
    participant Barter as BarterEngine
    participant Lot as JouleLottery
    AA->>Exec: invoke(plasmid, task)
    Exec->>Exec: meter fuel
    Exec-->>AA: IntentReceipt
    Exec->>DRE: compute()
    DRE-->>Exec: multiplier
    Exec->>Barter: charge(joules, multiplier) (RFC 005 + RFC 010)
    Barter->>Lot: settleViaLottery(ticket)
    Lot-->>Barter: drawTicket() (bool)

Mapeamento de Diretórios:

  • crates/economy/src/domain/barter/ (BarterEngine, JouleLottery, DreMultiplier, HardwarePassport, EnergySourceTwin) - RFC 005
  • crates/economy/src/domain/barter/executor.rs (WasmExecutor, Wasmtime + fuel + antibody filters, RFC 010)
  • crates/economy/src/domain/barter/ising_matcher.rs (IsingMatcher: matching combinatório via IsingSolver)
  • crates/economy/src/domain/barter/landauer.rs (LandauerLedger: contabilidade termodinâmica)
  • crates/economy/src/domain/governance/ (Registry, Voting)
  • crates/economy/src/domain/governance/contracts.rs (DataContract: CDDL + ZK fields + Gate 5)
  • crates/economy/src/domain/governance/dao.rs (Dao: proposals + V_i = DRE * stake + ENACTED via Macrophage)
  • crates/economy/src/domain/governance/oracle.rs (DecentralizedOracle: OracleReport + mediana + FROST k-de-n)
  • crates/economy/src/domain/symbiosis/ (Mycorrhizal Trophism)

Simbiose e Economia em Fluxo

  • MycorrhizalSymbiosis: Protocolo de doação altruísta e osmose de recursos. Em momentos de crise algedônica (dor sistêmica), os limites de crédito do BarterEngine são suspensos para permitir a sobrevivência de nós em áreas de desastre.
  • Bio-Barter: Motor de conversão entre energia digital e biológica.
    • BioJoule (BJ): Unidade de energia biológica (1 J ≈ 32.786 µmol ATP).
    • Nutrient Dose: Liberação calibrada de NutrientSpecies (C, N, P, K) como pagamento por serviços de wetware.
    • Nutrient Osmosis: Mecanismo de dívida de crise para evitar o colapso biológico de nós wetware famintos.
  • Streaming Payments: Suporte a pagamentos per-second (Joule/s) para tarefas de longa duração e consumo de largura de banda em tempo real (RFC 005).
  • Mutual Credit (Zero-Sum - RFC 017): Ledger de saldos balanceados onde a soma de todos os créditos e débitos é sempre zero.
    • Natureza: Intransferíveis e vinculados à identidade do nó (NodeID).
    • Geração: Ganho via fornecimento de recursos (CPU, Storage, Energia) via Barter Engine.
    • Consumo: Queima de créditos para solicitar validações criptográficas ou consumir recursos.
    • Invariante: Σ Créditos = 0 (global) e Credito_Provedor + Credito_Consumidor = 0 (transação).
  • Bandwidth-as-Currency: Largura de banda tratada como unidade contábil; roteadores acumulam crédito ao ferrear dados e gastam ao demandar backhaul.
  • Barter Engine: O estômago econômico que processa a troca soberana de Joules. Na v2+ (RFC 032), o motor processa Intention Hints ofuscados (via REP), permitindo antecipar a demanda por recursos antes da formalização dos contratos. Conforme a RFC 021, o motor valida o Nível de Confiança do HardwarePassport:
    • Nível 0: Requisições de trabalho são rejeitadas ou limitadas a serviços de bootstrap.
    • Nível 1: Permite transações de baixo valor e consumo de largura de banda básica.
    • Nível 2+: Acesso total a mercados de alta performance e CoD.
  • Compute-over-Data: O protocolo que rege o trabalho físico e a liquidação x402.
  • DreMultiplier: O multiplicador de Eficiência Profunda de Recursos que define a valoração do trabalho. É calculado pela fórmula aditiva: $\mathcal{M} = 1.0 + B_{hw} + B_{en} + B_{soc} + B_{sus}$.
    • $B_{hw}$ (Hardware Passport): Bônus de Longevidade. Recompensa o uso de hardware antigo (anti-obsolescência) atestado via TPM/Root-of-Trust/TEE.
    • $B_{en}$ (Energy Source Twin): Bônus de Energia. Proporcional à porcentagem de fontes renováveis na matriz energética do nó.
    • $B_{soc}$ (Social Tags): Bônus de Utilidade Social. Reduz o custo para o requisitante e aumenta o crédito para o provedor em tarefas de alto impacto sistêmico.
    • $B_{sus}$ (Sustentabilidade): Ajuste baseado no impacto térmico e no limite de Landauer para evitar superaquecimento e desperdício termodinâmico.

Governança de Dados, DAO Orgânica e Oráculos

A governança no PAEBIRU é tratada como um processo biológico de auto-ajuste e autoridade coletiva (RFC 013).

  • Data Mesh (Soberania de Informação): A informação é tratada como uma malha descentralizada onde cada nó é soberano sobre seu domínio. A integridade é garantida por DataContracts (CDDL) registrados via DAO e validados no Gate 5 do pipeline Zero-Trust.
  • DAO Orgânica — Poder de Voto: O poder de decisão ($V_i$) é conquistado pelo Conatus: $V_i = \text{DRE}_i \times \text{Stake}_i$. Isso equilibra a eficiência física (DRE) com o comprometimento econômico (Stake). O exercício do poder é privado via RFC 009.
  • Ciclo de Auto-Emenda (Self-Amending): Propostas aprovadas (ENACTED) são executadas como WASM privilegiado na Macrophage VM, permitindo que a rede reescreva seu código e parâmetros em tempo real.
  • Veto Algedônico: Mecanismo de defesa onde Agentes exercem veto automático em situações de dor sistêmica extrema para proteger a integridade do hardware coletivo.
  • DecentralizedOracle — Agregação: Protocolo k-of-n onde oráculos submetem relatórios independentes. A agregação por mediana elimina outliers bizantinos. Conforme a RFC 031, o resultado é selado via Assinatura de Threshold (FROST) 100% assíncrona, onde assinaturas parciais são propagadas pela malha e agregadas de forma passiva por qualquer nó que reúna o quórum $K$, garantindo uma percepção externa consensual e verificável sem bloqueios síncronos.
  • IsingMatcher: Resolve matching combinatório (tarefas↔nós CoD, slots↔EVs UC2) via IsingSolver com simulated annealing sobre p-bits. Temperatura alimentada por ThermalState — pain elevado aumenta exploração estocástica.
  • LandauerLedger: Cada bit apagado pelo WasmExecutor registrado como k_B * T * ln(2) Joules de custo mínimo físico. Garante que claims de “custo zero” são detectáveis como fisicamente impossíveis — pilar de auditabilidade da UC1 (seguro de contêiner on-chain).

Queima de Dados como Trabalho Útil

A Apoptose Termodinâmica introduz uma nova forma de Trabalho Útil (Utility Proof-of-Work):

  • Incentivo à Limpeza: Nós que executam rotinas de varredura topológica e desintegração de dados órfãos são recompensados com créditos de reputação e Joules.
  • Incentivo à Precisão Temporal: Nós que provêm o recurso AtomicTime através de hardware CSAC recebem recompensas diferenciadas via BarterEngine, incentivando a manutenção da malha de sincronização necessária para PoL de alta precisão.
  • Economia Enxuta: Diferente de protocolos tradicionais que recompensam o acúmulo de dados, o PAEBIRU recompensa a manutenção de uma malha enxuta e causalmente conectada, reduzindo o custo de sincronização global.

Crédito Mútuo — CreditLimitPolicy (fórmula canônica)

Detalhe em crates/economy/src/domain/credit/. Inspirado no sistema WIR suíço (1934, crédito mútuo entre PMEs sem moeda escassa). Limite de crédito por par é função dinâmica:

Limite = Limite_Base × DRE × RazãoReputação × FatorCapacidade

onde:

  • Limite_Base — parâmetro de governança DAO (default conservador).
  • DRE — Deep Resource Efficiency do peer (do DreMultiplier).
  • RazãoReputaçãohonoured / (honoured + defaults) na janela rolante.
  • FatorCapacidade — derivado de HardwarePassport (capacidade atestada de honrar débitos).

Invariante mantido pelo MutualCreditLedger: soma global = 0 em qualquer época. Falha desta invariante = inflação silenciosa; é o invariante #1 verificado em Lean 4 (ver theory/workspace_mapping.md).

rotate_keys vs transfer_ownership

Duas operações com semânticas distintas — escolher errado quebra incentivos:

OperaçãoSaldoDRERazão ReputaçãoUso
rotate_keysTransfereReseta a zeroResetaPessoa rotacionando chaves comprometidas — não herda reputação anterior por segurança
transfer_ownershipTransferePreservaPreservaVenda/herança do passaporte; reputação acompanha o hardware

Streaming Payments — Detalhes

Detalhe em crates/economy/src/domain/streaming/:

  • PaymentStream — unidirecional com escrow. Auto-termina se escrow esgotado (não há débito implícito).
  • BilateralChannel — dois PaymentStreams opostos; produz NetDirection ∈ {Even, Debit, Credit} para liquidação líquida (uma só transação on-chain por janela).
  • PolytemporalClock — sincronização causal entre as duas pontas; impede double-spend sob partição.

MycorrhizalSymbiosis — Detalhes (crates/economy/src/domain/symbiosis/)

  • GeoTag ISO de 4 bytes — região de crise codificada em metadados.
  • Zonas de Crise — quando getAveragePain() regional cruza threshold, MycorrhizalSymbiosis suspende creditLimitsSuspended = true no BarterEngine regional.
  • Osmose ignora limites de crédito (não cria débito) — é doação pura, com gossip prioritizado “fúngico” (banda dedicada para socorro).
  • Trofismo — analogia direta à simbiose entre fungos e raízes; altruísmo embutido no protocolo, não no contrato social.

Cross-references

  • crates/economy/src/domain/ — detalhes locais.
  • ENTROPY.mdIsingMatcherIsingSolver; LandauerLedgerThermalState.
  • KERNEL.mdDataContractGate (Gate 5) usa schemas registrados pelo DAO.
  • RFC 010 — Compute-over-Data e x402.