mleku/jericho
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

initial commit

Browse Source
This commit is contained in:
mleku
2025-11-30 20:53:00 +00:00
commit 1ebd88081c
5 changed files with 500 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.idea/jericho.mleku.dev.iml generated Normal file
View File

@@ -0,0 +1,12 @@
<?xml version="1.0" encoding="UTF-8"?>
<module type="WEB_MODULE" version="4">
<component name="NewModuleRootManager">
<content url="file://$MODULE_DIR$">
<excludeFolder url="file://$MODULE_DIR$/.tmp" />
<excludeFolder url="file://$MODULE_DIR$/temp" />
<excludeFolder url="file://$MODULE_DIR$/tmp" />
</content>
<orderEntry type="inheritedJdk" />
<orderEntry type="sourceFolder" forTests="false" />
</component>
</module>

10
.idea/misc.xml generated Normal file
View File

@@ -0,0 +1,10 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="MaterialThemeProjectNewConfig">
<option name="metadata">
<MTProjectMetadataState>
<option name="userId" value="-62fe7e2d:19874553008:-7ffa" />
</MTProjectMetadataState>
</option>
</component>
</project>

8
.idea/modules.xml generated Normal file
View File

@@ -0,0 +1,8 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ProjectModuleManager">
<modules>
<module fileurl="file://$PROJECT_DIR$/.idea/jericho.mleku.dev.iml" filepath="$PROJECT_DIR$/.idea/jericho.mleku.dev.iml" />
</modules>
</component>
</project>

16
.idea/workspace.xml generated Normal file
View File

@@ -0,0 +1,16 @@
<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ProjectViewState">
<option name="autoscrollFromSource" value="true" />
<option name="autoscrollToSource" value="true" />
<option name="hideEmptyMiddlePackages" value="true" />
<option name="openDirectoriesWithSingleClick" value="true" />
<option name="showExcludedFiles" value="false" />
<option name="showLibraryContents" value="true" />
</component>
<component name="PropertiesComponent">{
&quot;keyToString&quot;: {
&quot;last_opened_file_path&quot;: &quot;/home/mleku/src/github.com/PlebianApp&quot;
}
}</component>
</project>

454
Jericho Consensus.md Normal file
View File

@@ -0,0 +1,454 @@
# Jericho Consensus
## Overview
Jericho is a Byzantine fault-tolerant consensus mechanism combining CPU-equivalent proof of work with ephemeral bonding and democratic validation. It aims to eliminate monetary privilege (Cantillon effect) while maintaining security through distributed vigilance rather than capital hostage-taking.
## Core Components
### Block Production
Miners compete using a proof-of-work hash function based on large integer long division—an operation that cannot be meaningfully accelerated by specialized hardware. This ensures fair token issuance where acquisition cost is equivalent regardless of participant scale.
### Token Denomination
Tokens are represented as 128-bit unsigned fixed-point integers:
```
Token = uint128
Layout:
[ 32 bits whole | 96 bits fractional ]
whole part: 2^32 maximum whole tokens (4,294,967,296)
fractional part: 2^96 subdivisions per token (~28.9 decimal digits precision)
```
**Terminal supply:** 2^32 whole tokens (4,294,967,296 tokens)
This provides:
- Exact binary arithmetic (no floating-point rounding)
- Extreme precision for micro-transactions (1/2^96 ≈ 1.26 × 10^-29 tokens)
- Clean power-of-two total supply equals maximum representable whole value
- Simple overflow check: any value ≥ 2^128 is invalid
**Conversion:**
```
raw_value = whole_tokens × 2^96 + fractional_part
whole_tokens = raw_value >> 96
fractional = raw_value & ((1 << 96) - 1)
```
**Maximum raw value:** 2^128 - 1 (represents 2^32 - 2^-96 tokens, just under total supply)
### Token Emission
Block rewards follow a smooth exponential decay equivalent to Bitcoin's halving schedule. Rather than discrete halvings every 210,000 blocks, the reward decreases continuously:
```
block_reward = base_reward × e^(-λ × block_height)
where:
base_reward = 2^25 tokens = 33,554,432 tokens
λ = ln(2) / 210,000 ≈ 0.0000033 (decay constant)
terminal_supply = base_reward / λ = 2^32 tokens
This produces halving-equivalent checkpoints:
At block 210,000: reward = 2^24 tokens (16,777,216)
At block 420,000: reward = 2^23 tokens (8,388,608)
At block 630,000: reward = 2^22 tokens (4,194,304)
```
| Block Height | Reward (tokens) | Reward (2^n) | Cumulative Supply |
|--------------|------------------|--------------|-------------------|
| 0 | 33,554,432 | 2^25 | 0 |
| 105,000 | 23,726,566 | ~2^24.5 | ~2^31 |
| 210,000 | 16,777,216 | 2^24 | ~2^31.5 |
| 420,000 | 8,388,608 | 2^23 | ~2^31.8 |
| 630,000 | 4,194,304 | 2^22 | ~2^31.9 |
| ... | ... | ... | ... |
| ∞ | → 0 | → 0 | 2^32 |
**Cumulative supply formula:**
```
total_supply(h) = terminal_supply × (1 - e^(-λ × h))
= 2^32 × (1 - e^(-0.0000033 × h))
In fixed-point representation:
raw_supply(h) = 2^128 × (1 - e^(-λ × h))
```
**Implementation note:** The exponential can be computed via fixed-point arithmetic using Taylor series or lookup tables with interpolation to avoid floating-point operations in consensus-critical code.
Target block time: 10 minutes, adjusted via difficulty retargeting every 2016 blocks.
Block rewards are distributed:
- **70%** to the block producer (miner)
- **20%** split among endorsing validators (proportional to trust weight)
- **10%** to the challenge reserve pool (funds successful fraud proof rewards)
### Ephemeral Bonding
To propose or endorse a block, validators must post a temporary bond locked for a fixed challenge period. Bonds release automatically if unchallenged, creating rolling capital commitment without permanent lock-up. Validators who stop bonding automatically lose consensus influence—no explicit exit required.
**Bond Parameters:**
```
minimum_proposer_bond = 10 tokens
minimum_endorser_bond = 1 token
challenge_period = 100 blocks (~16.7 hours)
challenger_bond = 0.1 × proposer_bond
```
### Democratic Endorsement
Blocks require endorsement from validators whose trust weight exceeds a threshold. Trust flows through a web of attestations between participants. Attestation weight decays with bonding inactivity, causing the trust graph to self-prune inactive or abandoned nodes.
**Endorsement threshold:** A block is considered endorsed when validators representing ≥67% of active trust weight sign the block within the endorsement window (10 blocks after proposal).
### Adversarial Challenge Layer
During the challenge period, any participant may submit a fraud proof disputing block validity. Challengers post a smaller bond; the dispute resolves on-chain. Losers forfeit their bond to winners. This creates 1-of-N security: a single honest challenger defeats fraud.
## Fraudulent Block Definition
A block is fraudulent if it violates any of the following validity rules:
### Transaction Validity Fraud
| Fraud Type | Description | Proof Required |
|------------|-------------|----------------|
| Double spend | Transaction spends already-spent output | Both conflicting transactions with merkle proofs |
| Invalid signature | Transaction signature fails verification | The invalid transaction + public key |
| Insufficient balance | Spend exceeds available balance | Account state proof showing balance < spend |
| Invalid script | Script execution fails | Transaction + execution trace |
| Replay attack | Transaction replayed from different context | Original transaction + replay context |
### Block Structure Fraud
| Fraud Type | Description | Proof Required |
|------------|-------------|----------------|
| Invalid PoW | Block hash does not meet difficulty target | Block header |
| Invalid merkle root | Declared root mismatches transaction set | Transaction list + computed root |
| Invalid parent | Parent hash references non-existent/invalid block | Block header + chain state |
| Timestamp violation | Timestamp outside acceptable window | Block header + median time past |
| Oversized block | Block exceeds maximum size limit | Block header + size proof |
### Consensus Rule Fraud
| Fraud Type | Description | Proof Required |
|------------|-------------|----------------|
| Invalid coinbase | Block reward exceeds allowed emission | Coinbase transaction + block height |
| Missing endorsements | Insufficient trust weight endorsed | Block header + endorsement set |
| Bond violation | Proposer bond insufficient or expired | Proposer identity + bond state |
| Vesting violation | Tokens spent before vesting release | Transaction + vesting schedule proof |
| Invalid state root | Post-execution state root incorrect | Pre-state + transactions + computed post-state |
### Fraud Proof Structure
```
fraud_proof = {
block_hash: hash of disputed block
fraud_type: enumerated fraud category
evidence: type-specific proof data
witness: merkle proofs for state access
challenger: challenger public key
bond_tx: challenger bond transaction
signature: proof of challenger key ownership
}
```
### Fraud Resolution
1. **Submission**: Challenger submits fraud proof with bond (0.1 × proposer bond)
2. **Verification window**: 288 blocks (~48 hours) for on-chain verification
3. **Adjudication**: Deterministic verification of proof validity
4. **Settlement**:
- If fraud proven: proposer loses bond, challenger receives proposer bond + own bond return + challenge reserve bonus
- If fraud not proven: challenger loses bond to proposer
```
fraud_payout = {
to_challenger: proposer_bond + challenger_bond + reserve_bonus
reserve_bonus: min(proposer_bond × 0.5, challenge_reserve_balance × 0.01)
}
```
## Trust Attestation System
Trust attestations form the foundation of validator influence in the consensus. Unlike stake-weighted systems, trust is earned through explicit peer endorsement and sustained by ongoing participation.
### Attestation Structure
```
attestation = {
attester: attester public key
attestee: attestee public key
weight: integer weight (1-100)
expiry: block height when attestation expires (0 = no expiry)
conditions: optional behavioral conditions
signature: attester signature over attestation
}
```
### Trust Weight Calculation
Each validator's effective trust weight is computed as:
```
trust_weight(V) = Σ(attestation_weight(A, V) × attester_effectiveness(A))
for all attesters A who attested to V
attestation_weight(A, V) = base_weight(A, V) × time_decay(A, V) × activity_factor(A)
where:
base_weight(A, V) = weight declared in attestation (1-100)
time_decay(A, V) = 0.99^(blocks_since_attestation / 1000)
activity_factor(A) = min(1, bonding_blocks_last_10000 / 5000)
```
### Attester Effectiveness
An attester's own effectiveness determines how much weight their attestations carry:
```
attester_effectiveness(A) = trust_weight(A) × activity_factor(A) × reputation_factor(A)
reputation_factor(A) = 1 - (slashing_events(A) × 0.1)
clamped to [0, 1]
```
This creates recursive trust: validators who are themselves trusted carry more attestation weight.
### Trust Graph Properties
**Transitivity limits**: Trust does not flow transitively beyond direct attestations. If A trusts B and B trusts C, A does not automatically trust C. This prevents trust inflation.
**Decay mechanics**: Attestations decay over time unless refreshed. An attestation loses ~1% of its weight every 1000 blocks (~1 week). Attesters must periodically re-sign to maintain trust relationships.
**Activity requirement**: Attesters who stop bonding see their attestation effectiveness drop. After 10,000 blocks (~10 weeks) of inactivity, attestations from that identity carry zero weight.
### Attestation Operations
| Operation | Bond Required | Effect |
|-----------|---------------|--------|
| Create attestation | 0.1 tokens | New trust edge in graph |
| Update weight | 0.05 tokens | Modify existing attestation weight |
| Revoke attestation | 0 tokens | Remove trust edge immediately |
| Refresh attestation | 0.01 tokens | Reset decay timer |
### Trust Threshold for Consensus
```
endorsement_threshold = 0.67 × total_active_trust_weight
total_active_trust_weight = Σ(trust_weight(V) × activity_factor(V))
for all validators V with activity_factor > 0.1
```
A block achieves consensus when:
```
Σ(trust_weight(E)) ≥ endorsement_threshold
for all endorsers E who signed the block
```
### Sybil Resistance in Trust
The trust system resists Sybil attacks through:
1. **Identity cost**: Creating validators costs ~12 weeks CPU work
2. **Probation period**: New identities have 10% attestation effectiveness for 1000 blocks
3. **No self-attestation**: Validators cannot attest to themselves
4. **Attestation limits**: Each validator can create max 100 active attestations
5. **Collusion detection**: Highly interconnected clusters with no external attestations receive reduced weight
```
cluster_penalty(C) = 1 - (internal_edges(C) / (internal_edges(C) + external_edges(C)))^2
where cluster C is detected via graph community analysis
```
### Trust Bootstrap at Genesis
At network genesis, a predefined set of bootstrap attestations creates initial trust:
```
genesis_attestations = [
{attester: genesis_key_1, attestee: genesis_key_2, weight: 50},
{attester: genesis_key_2, attestee: genesis_key_1, weight: 50},
...
]
```
These bootstrap identities must have completed the work-bond registration. After 10,000 blocks, genesis attestations decay like any other, and the network trust graph becomes purely organic.
## Identity Bootstrap and Sybil Resistance
New validator identities must satisfy a work-bond requirement before participating in consensus. This mechanism serves dual purpose: bootstrapping the network without privileged token distribution, and creating ongoing Sybil resistance through identity cost.
### Work-Bond Mechanism
Every new public key entering the validator set must submit a proof-of-work demonstrating sustained computational commitment:
```
identity_proof = {
pubkey: new validator public key
work: PoW solution (long division hash)
timestamp: block height at submission
signature: proof of key ownership
}
```
The work requirement targets approximately twelve weeks of continuous single-thread CPU computation at genesis, establishing genuine cost for identity creation.
### Adaptive Identity Difficulty
As network token supply matures, identity cost transitions from pure computation to capital:
```
identity_cost = max(work_requirement, token_bond_equivalent)
where:
work_requirement = base_difficulty × decay_factor(supply)
token_bond_equivalent = minimum_bond × time_weight_factor
decay_factor(supply) = 2^(-supply / halving_constant)
```
| Network Maturity | Work Requirement | Token Alternative |
|--------------------|------------------|-------------------------------|
| Genesis | ~12 weeks CPU | Not available |
| Early (low supply) | ~6 weeks CPU | Expensive (scarce tokens) |
| Growth | ~2 weeks CPU | Moderate token bond |
| Mature | ~1 week CPU | Standard token bond preferred |
This creates equivalence: early participants pay in computation what later participants pay in capital. Neither enjoys privilege over the other.
### Sybil Economics
Creating validator identities always costs real resources:
```
sybil_attack_cost = N × identity_cost
where N = number of fake identities needed
```
At any network stage, identity cost equals approximately 12 weeks CPU work OR equivalent token bond.
To achieve 33% Byzantine threshold with 100 honest validators:
- Need ~50 Sybil identities
- Cost: 600 weeks CPU time OR 50 × token_bond
Identity cost scales with ambition. Casual participation is accessible; capture attempts are expensive.
### Identity Lifecycle
```
┌─────────────────────────────────────────────────────────┐
│ 1. REGISTRATION │
│ Submit identity_proof with PoW or token bond │
│ Identity enters probationary state │
└────────────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 2. PROBATION (1000 blocks) │
│ Can bond and validate │
│ Attestation weight: 10% of normal │
│ Cannot attest to other new identities │
└────────────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. ACTIVE │
│ Full participation rights │
│ Attestation weight grows with bonding activity │
│ Can attest to new identities │
└────────────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 4. INACTIVE (no bonding for N blocks) │
│ Attestation weight decays │
│ Eventually: identity suspended │
│ Reactivation: reduced work-bond (not full) │
└─────────────────────────────────────────────────────────┘
```
## Reward Vesting Schedule
Block rewards vest over one year following a halving pattern with progressively doubling periods. Each period releases double the previous amount over double the time, maintaining constant release rate while extending commitment duration.
### Schedule Structure
| Period | Duration | Cumulative Time | Release | Cumulative Release |
|--------|------------|-----------------|---------------|-------------------|
| 1 | 5.7 days | 5.7 days | 1/128 (0.78%) | 0.78% |
| 2 | 11.4 days | 17.1 days | 1/64 (1.56%) | 2.34% |
| 3 | 22.8 days | 39.9 days | 1/32 (3.13%) | 5.47% |
| 4 | 45.6 days | 85.5 days | 1/16 (6.25%) | 11.72% |
| 5 | 91.3 days | 176.8 days | 1/8 (12.5%) | 24.22% |
| 6 | 182.5 days | 359.3 days | 1/4 (25%) | 49.22% |
| 7 | 5.7 days | 365 days | ~1/2 (50.78%) | 100% |
### Game-Theoretic Effect
| Exit Timing | Reward Forfeited |
|----------------------|------------------|
| Early exit (1 month) | ~95% |
| Early exit (3 months)| ~88% |
| Early exit (6 months)| ~75% |
| Full year commitment | 0% |
This creates:
- **Continuous incentive**: Every additional day of honest participation unlocks more value
- **Compounding commitment**: Later periods contain majority of reward, binding validators to long-term network health
- **Attack deterrent**: Misbehavior forfeits substantial unvested rewards beyond immediate bond loss
- **Anti-mercenary pressure**: Quick profit-taking captures minimal value; patience rewarded exponentially
### Forfeiture Mechanics
Unvested rewards from slashed or departed validators return to the block reward pool, benefiting remaining honest participants. This creates collective incentive to identify and challenge bad actors early.
## Countermeasures
### Random Audits (Anti-Apathy)
Each block, a deterministic random selection obliges specific validators to demonstrate liveness and state awareness within a response window. Failure results in attestation weight reduction and partial bond slashing. Consecutive failures trigger temporary exclusion. This unpredictable obligation prevents passive participation.
### Time-Weighted Bonding (Anti-Concentration)
Newly bonded capital enters at reduced effectiveness (10%), scaling to full weight over thousands of blocks. This prevents flash concentration attacks and rewards patient commitment over mercenary capital deployment. Combined with sublinear influence curves, small long-term participants can match large short-term holders.
## Security Model
| Threat | Countermeasure |
|-----------------------|--------------------------------------------------------|
| Hardware privilege | CPU-equivalent PoW (long division) |
| Validation fraud | Economic bonds + adversarial challenges |
| Voter apathy | Random audits with slashing |
| Capital concentration | Time-weighted bonding + sublinear returns |
| Mercenary behavior | Progressive vesting over one year |
| Zombie validators | Automatic decay via bonding inactivity |
| Sybil attacks | Work-bond identity cost (~12 weeks CPU per identity) |
| Bootstrap privilege | Work-to-capital transition preserves cost equivalence |
## Properties
| Aspect | Mechanism |
|--------------------|------------------------------------------------------------|
| Sybil resistance | Work-bond identity registration (~12 weeks CPU) |
| Zombie elimination | Automatic via bonding inactivity decay |
| Attack cost | Bond loss + challenge certainty + vested reward forfeiture |
| Entry barrier | Moderate work OR equivalent capital (never free) |
| Governance | Democratic endorsement with activity-weighted voting |
| Commitment horizon | One year through vesting schedule |
| Bootstrap fairness | Work-capital equivalence across network maturity |
## Trade-offs
Jericho sacrifices the passive security of capital hostage-taking (Bitcoin's ASIC lock-in) for active security through distributed vigilance. It requires ongoing participation but offers fair issuance, accessible entry, and resistance to monetary privilege accumulation. The vesting schedule creates soft lock-in through future rewards rather than stranded hardware, aligning incentives without creating permanent barriers to exit.
The work-bond identity mechanism ensures that validator creation always costs real resources—computation early, capital later—eliminating both Sybil attacks and privileged genesis distribution. Early and late participants face equivalent barriers in different currencies.