LAMA लामा

Locally Attested Multi-Agreement

Distributed consensus through independent wisdom.

v2.5.0

The Wise Council

In Tibetan Buddhism, a lama is a wise teacher who guides seekers toward enlightenment through accumulated wisdom. Multiple lamas in a monastery reach consensus on dharmic truths through deep contemplation—each independently arriving at the same understanding.

The LAMA protocol embodies this principle: each node is a lama, contemplating independently. Truth emerges through mathematical inevitability, not political voting. Many lamas, one truth.

Overview

LAMA (Locally Attested Multi-Agreement) provides distributed consensus for the Yakmesh network. Unlike traditional blockchain consensus that relies on voting or stake-weighted selection, LAMA achieves agreement through deterministic validation where all nodes independently arrive at the same conclusion.

Protocol Family

Protocol	Himalayan Name	Purpose
Gossip	MANTRA	Epidemic message propagation
Broadcast	STUPA	Priority-based broadcasting
Consensus	LAMA	Distributed agreement
Time	MANI	Temporal synchronization
Trust	KARMA	Reputation management
Mesh	MANDALA	Network topology

Dharmic States

Content in the LAMA system progresses through states, like a teaching moving through stages of acceptance in a monastery:

PENDING

Teaching received, awaiting contemplation. Content has arrived but not yet validated locally.

VALIDATED

Accepted by one lama. Local node has verified the content's validity.

CONSENSUS

All lamas agree on truth. Multiple nodes have independently verified.

REJECTED

Teaching rejected. Failed validation or consensus requirements.

CONFLICT

Multiple versions exist. Will be resolved through deterministic wisdom.

Core Components

LamaConsensus

The main consensus engine managing distributed agreement:

import { LamaConsensus, DharmicState } from 'yakmesh/oracle/consensus-engine';

// Initialize the consensus engine
const lama = new LamaConsensus(nodeIdentity, {
  minAttestations: 3,            // Minimum nodes to confirm
  conflictResolutionDelay: 5000, // Time before resolving conflicts
  networkFingerprint: fingerprint
});

// Submit content for consensus
const result = lama.submitContent('listing', {
  title: 'Quantum-Safe Widget',
  price: 100,
  seller: userId
}, {
  signature: userSignature,
  publicKey: userPubKey
});

console.log(result.status);      // 'VALIDATED', 'DUPLICATE', 'CONFLICT_DETECTED'
console.log(result.contentHash); // Content's unique identity

Receiving Attestations

When other nodes validate the same content, they provide attestations:

// Receive attestation from another node
lama.receiveAttestation(contentHash, attestingNodeId);

// Listen for consensus events
lama.on('consensus', ({ contentHash, attestations }) => {
  console.log(`Consensus reached with ${attestations.size} attestations`);
});

// Listen for conflict resolution
lama.on('conflictResolved', ({ primaryKey, winner, loser }) => {
  console.log(`Conflict resolved: ${winner} chosen over ${loser}`);
});

Conflict Resolution

When multiple versions of content share the same primary key (e.g., same listing ID), LAMA resolves conflicts deterministically using content hashes:

1. Detection

Two nodes submit different content with the same primary key

→

2. Collection

Both versions are stored, marked as CONFLICT

→

3. Resolution

After delay, deterministic comparison (hash ordering) selects winner

→

4. Consensus

Winner promoted to CONSENSUS, loser marked REJECTED

Key insight: Because resolution is deterministic (based on content hashes), all nodes will independently arrive at the same conclusion without communication.

Event System

Event	Payload	Description
`validated`	{ contentHash, content }	Content passed local validation
`consensus`	{ contentHash, attestations }	Consensus threshold reached
`conflictDetected`	{ primaryKey, hashes }	Conflicting versions identified
`conflictResolved`	{ primaryKey, winner, loser }	Conflict deterministically resolved
`rejected`	{ contentHash, reason }	Content failed validation

Configuration

const config = {
  // Attestation requirements
  minAttestations: 1,              // Minimum nodes to reach consensus
  
  // Conflict handling
  conflictResolutionDelay: 5000,   // Wait time before resolving (ms)
  
  // Storage limits
  maxPendingContent: 10000,        // Maximum unresolved content
  
  // Security
  networkFingerprint: '...',       // Network identity (hash never exposed)
};

Integration with Other Protocols

MANTRA

Content and attestations propagate via epidemic gossip

STUPA

Consensus results broadcast with IMMEDIATE priority

ValidationOracle

Cryptographic validation of content before consensus

KARMA

Trust scores weight attestation significance

Backward Compatibility

For existing codebases using the original "ConsensusEngine" naming, legacy exports are maintained:

// Legacy imports still work
import { ConsensusEngine, ContentState } from 'yakmesh/oracle/consensus-engine';

// These map to the new LAMA names
// ConsensusEngine → LamaConsensus
// ContentState → DharmicState

Continue the Journey

← Previous

STUPA

Distributed storage

MANI

Time synchronization