Security Analysis

Trust Boundaries

The Elastos system has five distinct trust boundaries, each with different security properties:

Boundary 1: Main Chain Consensus (Highest Trust)

• PoW Security: Inherits Bitcoin's full hash rate via merged mining (AuxPoW, Chain ID 1224)
• BPoS Finality: BPoS validators provide instant finality with two-thirds supermajority confirmation
• BFT Threshold: Tolerates up to one-third malicious validators
• Dual-layer protection: Attacker needs both >50% Bitcoin hash rate AND >2/3 arbiter keys
• Degradation safeguard: Falls back to pure PoW if BPoS stalls for 12 hours

Boundary 2: Cross-Chain Bridge (Weakest Link)

• Deposit direction (main → side): Trustless: sidechains independently verify SPV Merkle proofs
• Withdrawal direction (side → main): Semi-trusted: requires two-thirds supermajority validator multi-sig (or Schnorr aggregate). More than one-third colluding validators can:
  • Approve fraudulent withdrawals
  • Block legitimate withdrawals
• Small transfers (under 1 ELA): Only single on-duty arbiter signature required
• No fraud proofs or challenge periods (unlike optimistic rollups)

Boundary 3: Sidechain Consensus

• Same BPoS validator set as main chain, using PBFT
• Instant finality (no reorgs once committed)
• Same BFT threshold: tolerates up to one-third malicious validators
• Cross-chain blocked during PoW fallback mode (safety valve)

Boundary 4: Identity (Self-Sovereign)

• Users generate and control their own keys
• DID documents anchored on EID chain (PBFT finality)
• No authority can modify a DID without the controller's private key
• Multiple authentication keys supported for key rotation

Boundary 5: Storage (Operator-Trusted)

• Authentication is DID-based (cryptographically secure)
• Hive Node operator has full access to stored data
• No end-to-end encryption enforced by default
• Users can run their own Hive Node for full sovereignty

Trust Flow Hierarchy

MOST TRUSTED
    │
    ▼
Bitcoin PoW (exahashes of hash power)
    │
    ▼
ELA Main Chain (BPoS finality + PoW base)
    │
    ▼
Arbiter Set (2/3+1 threshold, elected validators)
    │
    ├─────> ESC/EID Consensus (same arbiter set, PBFT)
    │           │
    │           ├─────> DID Anchoring (self-sovereign, chain-verified)
    │           │           │
    │           │           └─────> Hive Auth (DID-based, operator-trusted data)
    │           │
    │           └─────> Smart Contracts (standard EVM security model)
    │                       │
    │                       └─────> StakeTicket / ELink (precompile-dependent)
    │
    └─────> Cross-Chain Bridge (trustless deposits, semi-trusted withdrawals)
    │
    ▼
LEAST TRUSTED
    │
    ▼
Carrier P2P (self-sovereign identity, relay trust)

Attack Surface Matrix

Attack Vector	Impact	Difficulty	Mitigations
51% Bitcoin hash rate	Reverse PoW blocks	Very High	BPoS finality prevents double-spends even if PoW compromised
Arbiter collusion (>2/3 of 12 Council members)	Steal cross-chain funds	High	Election system, staking requirements, transparent voting
Single arbiter compromise	Steal small transfers (under 1 ELA)	Medium	Threshold configurable, amount limited
DID key theft	Identity impersonation	Medium	Multi-key support, key rotation
Hive Node compromise	Data breach	Medium	Client-side encryption (optional), user-run nodes
EID chain outage	DID resolution failure	Medium	Multiple EID nodes, SDK fallback endpoints
Smart contract vulnerability	Fund loss on ESC	Medium	Standard EVM security model, audit required
P2P network partitioning	Delayed consensus	Medium	Multiple bootstrap nodes, peer discovery
Precompile bug (1000-1009)	Incorrect governance data	Medium	Precompile code is part of node binary
Schnorr nonce reuse	Private key extraction	Critical	Random nonce generation (not deterministic RFC 6979)

Critical Security Observations

P-256 Curve Choice

The ELA main chain and DID system use NIST P-256 (secp256r1), a government-standardized curve. Some cryptographers have expressed concerns about potential NIST backdoors. All main chain and DID private key operations are on this curve. The Schnorr signature implementation also operates on P-256.

Schnorr Nonce Generation

danger

The Schnorr implementation uses random bytes (not deterministic RFC 6979):

func deterministicGetK0(d []byte) (*big.Int, error) {
    message, _ := randomBytes(32)
    h := sha256.Sum256(append(d, message[:]...))
    ...
}

The function name deterministicGetK0 is misleading: it uses randomBytes(32) and is not deterministic. If the random number generator is compromised or produces duplicate nonces across sessions, private keys could be extracted. However, the concatenation with the private key (d) provides some protection against pure PRNG failure.

Single Genesis Address Escrow

Each sidechain's cross-chain funds are held in a single multi-sig address derived from the genesis block hash. If this address is compromised (13+ arbiter keys), all cross-chain funds for that sidechain are at risk. There is no per-user escrow or time-locked recovery.

SPV Security Limitations

SPV clients trust the longest valid header chain. A 51% attack on the main chain could temporarily fool SPV clients and therefore sidechains. This is the standard SPV trust model shared with Bitcoin SPV wallets.

No Fraud Proofs for Withdrawals

Unlike optimistic rollups, the cross-chain withdrawal system has no challenge period or fraud proof mechanism. Once 2/3+1 arbiters sign a withdrawal, it executes immediately. The only protection is the economic incentive of staked deposits.

Key Security Mechanisms

Multi-Signature Verification

Two schemes for cross-chain signatures:

Classic Multi-Sig: M-of-N where M = 2/3 * N + 1. Each arbiter signs independently. Signatures collected via P2P, merged positionally into the transaction's Program field.

Schnorr Aggregate: 3-phase protocol producing a single 64-byte signature. More efficient on-chain but requires 3 rounds of P2P communication.

SPV Proof Verification

Sidechains verify main chain deposits using Merkle proofs:

• Partial Merkle tree with CVE-2012-2459 protection (duplicate hash detection)
• Stack-based verification (not recursive, prevents stack overflow attacks)
• Proof includes block hash, transaction path, and Merkle hashes

Penalty Enforcement

• Illegal behavior (double-signing) punished via DPoSV2IllegalPenalty = 200 ELA
• Evidence transactions (IllegalProposalEvidence, IllegalVoteEvidence, IllegalBlockEvidence) are permanent on-chain
• Producers in Illegal state cannot re-register

Frozen Address System

Both Arbiter and main chain maintain frozen address lists:

• Frozen addresses excluded from all cross-chain operations
• Cannot receive deposits or initiate withdrawals
• Managed via on-chain governance transactions

Transaction Validation Defense

Two-phase validation prevents malformed transactions:

1. Sanity Check (stateless): Structure, size, format
2. Context Check (stateful): UTXO existence, balances, business logic

Double-spend prevention:

• mempool/conflictmanager.go detects double-spends in mempool
• Block validator checks existingTxInputs for duplicate UTXO consumption
• IsDoubleSpend() checks against the chain store

Component Security Matrix

Component	Auth Method	Encryption	Key Storage	Signing Curve	Weakest Link
ELA Main Chain	BPoS election + PoW	Public ledger	Node keystore	P-256	Arbiter key compromise
Validator	DPoS P2P identity	P2P message signing	keystore.dat	P-256	2/3+1 collusion
ESC/EID	Same arbiters (PBFT)	Public ledger	Node keystore	secp256k1	Same as main chain
DID	Self-sovereign keys	DID document signing	User device	P-256	Key loss/theft
Hive	DID challenge-response	Optional client-side	Server filesystem	N/A	Operator trust
Carrier v2	Ed25519 node identity	X25519 per-message	Node key file	Ed25519	Relay/super node trust
Essentials	Master password + biometric	AES-256 at rest	Device keychain	P-256 + secp256k1	Master password
StakeTicket	Precompile verification	On-chain	Contract state	P-256 (via precompile)	Precompile correctness
ELink Bridge	Arbiter P256 signatures	On-chain	Arbiter keystores	P-256	Oracle liveness

Smart Contract Security (ESC)

StakeTicket Contracts

Repo: Elastos.ELA.StakeTicket.Solidity

BPoS staking NFTs on ESC that interact with precompiled contracts 1000–1006. Each staking position is represented as an NFT (ERC-721). Contract calls precompiles to verify staking state on the main chain.

Security considerations:

• Depends on correctness of precompiled contracts (part of node binary, not auditable Solidity)
• Staking positions tied to main chain state: ESC contract cannot independently verify staking validity
• NFT transfers could decouple staking rights from actual stakes if precompile returns stale data

ELink Bridge Contracts

Repo: Elastos.ELink.Solidity

Chainlink-style oracle bridge with 12-arbiter BFT consensus:

• 50-channel concurrent request system
• Uses P256Verify precompile (address 1008) for arbiter signature verification
• 2/3+1 arbiter consensus required for oracle data submission

Security considerations:

• Oracle data is only as trustworthy as the arbiter set
• 50 concurrent channels could be exhausted in a DoS attack
• P256Verify precompile is the cryptographic bridge: a bug here breaks all oracle verification

Known Trust Assumptions

1. Bitcoin hash rate assumption: If Bitcoin's hash rate drops significantly or is redirected, ELA's PoW security weakens proportionally.

2. Arbiter honesty assumption: Two-thirds plus one of validators must be honest for cross-chain withdrawals to be secure.

3. Small transfer single-sig: Transfers below 1 ELA only require one arbiter's signature. A single compromised arbiter can approve fraudulent small withdrawals.

4. Hive Node operator trust: Hive Node operator has full access to stored data unless client implements encryption.

5. EID availability: DID resolution requires a running EID node. If all EID nodes go offline, DIDs cannot be resolved, breaking Hive authentication.

6. P-256 curve trust: NIST P-256 is used for all main chain and DID operations. Any weakness in this curve would compromise the entire main chain and identity system.

7. Single genesis address escrow: Each sidechain's cross-chain funds are held in a single multi-sig address. Compromise of more than one-third of validator keys exposes all funds for that sidechain.