OpenHash SCI 논문 초안 v1.2 · Do Young Min · AI City Inc. · 2026-03-23
OpenHash: A Probabilistic Hierarchical Layer Distribution System for
Proof-of-Work-Free Data Integrity Verification in Distributed Networks
문서 정보 (수정 시 이 블록을 갱신하십시오)
버전 : v1.2
최종 수정 : 2026-03-23
상태 : 초안 (Draft — 전용 인스턴스 실측값 반영)
대상 저널 : [투고 저널명 기입]
저자 : Do Young Min
소속 : AI City Inc.
교신저자 : tensor.city@gmail.com
투고 예정 : March 2026
기반 특허 : 확률적 계층 분산 기반 데이터 무결성 검증 시스템 (출원번호: 미정)
수정 이력
v1.0 2026-03-23 초안 작성 (Do Young Min, K-OpenLaw 연구그룹)
v1.1 2026-03-23 5절 전면 개정 — AWS 공유 환경 실험 5종 결과 반영
(EXP1 단일노드, EXP2 2노드, EXP3 4노드+Merkle,
EXP4 2계층 L1x4→L2x1, EXP5 LPBFT 3단계 합의)
v1.2 2026-03-23 5절 수치 확정 — AWS 전용 인스턴스 실측값으로 전면 갱신
(EXP-D1 단일노드TPS/지연, EXP-D2 스레드 선형성,
EXP-D3 프로세스 선형성, EXP-D4 계층간검증/LPBFT/Merkle)
환경: c5.2xlarge, Intel Xeon 8275CL @ 3.00GHz, 8 vCPU
ABSTRACT
Background:
Existing distributed ledger technologies (DLTs), including blockchain
variants employing Proof-of-Work (PoW) or Proof-of-Stake (PoS) consensus,
suffer from prohibitive energy consumption, limited throughput, and poor
scalability. Bitcoin alone consumes approximately 121 TWh of electricity
annually, while transaction finality latencies of 10 minutes (Bitcoin) and
12 seconds (Ethereum) preclude real-time applications. Alternative
approaches based on Directed Acyclic Graphs (DAGs) or Hashgraph protocols
improve throughput but remain anchored to pure algorithmic consensus,
failing to exploit the trust structure inherent in real-world physical
communication infrastructures.
Methods:
We present OpenHash, a Probabilistic Hierarchical Layer Distribution (PHLD)
system that leverages the existing physical layered structure of
telecommunications infrastructure to guarantee data integrity without PoW,
PoS, or continuous global consensus. The system employs a five-tier
administrative hierarchy (sub-district, district, metropolitan, national,
global) corresponding to existing network topology. A Probabilistic Layer
Selection Module (PLSM) performs double-rehashing of document hashes and
timestamps via SHA-256 to determine recording tiers according to asymmetric
probability distributions weighted by data importance and transaction
locality. Inter-layer mutual verification is achieved through top-down
BLS-signature-based Merkle proof auditing and bottom-up real-time anomaly
monitoring. A Lightweight PBFT (LPBFT) consensus is invoked only under
emergency conditions. The system was implemented and evaluated on AWS cloud
infrastructure (Intel Xeon Platinum 8259CL, 2.50 GHz).
Results:
Inter-layer verification latency averaged 1.47 ms (median 1.44 ms;
95th percentile 1.54 ms) over 1,000 iterations. End-to-end transaction
processing latency averaged 3.09 ms (median 3.02 ms; 95th percentile
Ed25519 signatures. Extrapolating to a national deployment of 7,000
sub-district nodes (two per ~3,500 administrative units in the Republic of
Korea), aggregate throughput scales linearly to tens of millions of TPS.
Merkle-tree batch aggregation reduces inter-layer synchronization bandwidth
by over 99% compared to naive hash broadcasting. The LPBFT emergency
consensus completes in an average of 16.87 ms and is projected to activate
fewer than 10 times per year (<0.01% of operational time).
Conclusions:
OpenHash eliminates energy-intensive consensus while achieving millisecond-
level transaction finality and linear horizontal scalability. By treating
the physical administrative hierarchy of existing telecommunications
networks as a trust substrate rather than a mere data conduit, the system
establishes a novel paradigm for data integrity verification that is
simultaneously energy-efficient, high-throughput, and compliant with
real-world regulatory structures. OpenHash has potential applications in
national payment systems, electronic health records, governmental document
authentication, and any domain requiring auditable, low-latency data
integrity at national or global scale.
Keywords:
distributed ledger; data integrity; probabilistic layer selection;
hierarchical consensus; hash chain; Byzantine fault tolerance;
blockchain alternative; energy-efficient verification; Merkle tree;
BLS signature
The proliferation of distributed ledger technologies (DLTs) since the
introduction of Bitcoin in 2008 [1] has demonstrated the feasibility of
trustless, decentralized record-keeping at global scale. However, the dominant
consensus paradigm—Proof-of-Work (PoW)—imposes an energy cost that is
ecologically unsustainable: Bitcoin's annual electricity consumption
(approximately 121 TWh) rivals that of medium-sized nations [2]. The successor
paradigm, Proof-of-Stake (PoS), reduces energy expenditure but introduces
wealth-concentration vulnerabilities in which early adopters who control stake
at genesis can reconstruct the entire chain [3].
Beyond energy, throughput and latency remain fundamental barriers. Bitcoin
averages one block per ten minutes; Ethereum's proof-of-stake transition
reduced block time to twelve seconds but still cannot support real-time payment
settlement. Alternative DLT architectures—DAG-based systems such as IOTA
Tangle [4] and Nano Block-lattice, and virtual-voting approaches such as
Hashgraph [5]—improve throughput but preserve a core assumption that trust must
be constructed entirely within the digital domain from cryptographic primitives
and algorithmic consensus.
A critical but under-explored insight is that real-world communication networks
are not merely conduits for data; they are themselves structured according to
trusted administrative hierarchies (sub-district, district, metropolitan,
national, global) that already embody physical, legal, and organizational trust.
If this existing hierarchical trust structure could serve as the foundation for
data integrity verification, the overhead of consensus-as-computation could be
largely eliminated.
This paper introduces OpenHash, a Probabilistic Hierarchical Layer Distribution
(PHLD) system for data integrity verification that exploits the existing layered
physical infrastructure of telecommunications networks. The principal
contributions are:
(1) A probabilistic layer selection algorithm that selects the recording tier
for each transaction via double-SHA-256 rehashing of the document hash
and timestamp, distributing network load asymmetrically across
administrative tiers without global agreement.
(2) A per-layer balance invariance verification module that identifies
fraudulent transactions in real time by enforcing conservation of
aggregate balances at and above the Lowest Common Administrative Tier
(LCAT) of the transacting parties.
(3) A five-stage transaction validation pipeline (balance check, identity
verification, limit check, anomaly detection, regulatory compliance)
providing multi-layer defense against fraudulent transactions.
(4) A dual-direction inter-layer mutual verification scheme (top-down
BLS/Merkle-proof auditing; bottom-up real-time anomaly monitoring) that
supersedes continuous global consensus and restricts the LPBFT emergency
consensus to rare fault conditions.
(5) Empirical performance characterization on production-grade cloud hardware
demonstrating sub-5 ms end-to-end transaction latency and linear
throughput scaling.
Section 2 surveys related work. Section 3 presents the system architecture and
its theoretical foundations. Section 4 describes each functional module in
detail. Section 5 reports experimental performance measurements. Section 6
discusses security properties, limitations, and future directions. Section 7
concludes.
2.1 Blockchain and Proof-of-Work Systems
Nakamoto's seminal Bitcoin protocol [1] introduced a chain of cryptographically
linked blocks secured by PoW. Subsequent systems—Ethereum [6], Litecoin, and
others—refined the base design but retained energy-intensive mining as the
Sybil-resistance mechanism. The annual energy expenditure of PoW networks is
widely documented [2, 7] and has motivated extensive research into
energy-efficient alternatives.
PoS replaces computational work with economic stake as the Sybil-resistance
mechanism, drastically reducing energy consumption [8]. However, stake
concentration at genesis grants early validators disproportionate influence,
and the nothing-at-stake problem has required additional slashing mechanisms
[3]. Delegated PoS (DPoS) and variations such as Tendermint/Cosmos [9] improve
finality but require an online validator set, introducing liveness assumptions.
IOTA Tangle [4] organizes transactions in a Directed Acyclic Graph (DAG) where
each new transaction references and validates two prior ones. This eliminates
mining fees and enables zero-fee microtransactions but requires a centralized
Coordinator node for security in practice, limiting decentralization. Nano
Block-lattice [10] assigns each account its own chain within a DAG, enabling
asynchronous operation, yet relies on delegated representatives for conflict
resolution. None of these systems leverage physical administrative hierarchies
as a trust substrate.
Hashgraph [5] achieves asynchronous Byzantine Fault Tolerance (aBFT) via
gossip-about-gossip and virtual voting without explicit message rounds. Its
strong consistency guarantees and high throughput are attractive, but the
algorithm is patented and optimized for permissioned networks, limiting broad
adoption. Furthermore, like DAG-based systems, Hashgraph constructs trust
purely algorithmically.
2.5 Hierarchical and Physical-Infrastructure-Aware Systems
Prior work on hierarchical consensus [11] and geographic sharding [12] has
explored how network topology can improve scalability, but these approaches
still require consensus within shards and do not exploit the administrative
layer structure of existing telecommunications infrastructure as a trust
foundation. Merkle tree-based integrity proofs [13] are well-established for
efficient batch verification but are typically embedded within conventional DLT
frameworks. OpenHash distinguishes itself by treating the physical five-tier
administrative hierarchy as the primary trust substrate, relegating
cryptographic consensus to an emergency fallback.
Castro and Liskov's Practical Byzantine Fault Tolerance (PBFT) [14] provides
safety and liveness in asynchronous networks tolerating up to floor((n-1)/3)
Byzantine faults in a network of n nodes, with O(n^2) message complexity. This
quadratic overhead has prompted numerous lightweight variants [15, 16].
OpenHash's LPBFT borrows the three-phase protocol (pre-prepare, prepare,
commit) but restricts participation to Representative nodes and confines
activation to emergency conditions, achieving average consensus latency of
OpenHash maps the logical trust structure of the system onto a five-tier
administrative hierarchy that mirrors the physical layered structure of national
telecommunications networks. From lowest to highest, the tiers are:
L1 Sub-district (eup / myeon / dong)
L2 District (si / gun / gu)
L3 Metropolitan (gwangyeoksi / do)
L4 Nation
L5 Global
Each tier is identified by a hierarchical identifier following the pattern:
GLOBAL > KR > KR-JEJU > KR-JEJU-SEOGWIPO > KR-JEJU-SEOGWIPO-JUNGMUN
In a South Korean national deployment, L1 comprises approximately 3,500
sub-district nodes, L2 comprises 226 district nodes, L3 comprises 17
metropolitan/provincial nodes, L4 comprises one national node, and L5
comprises one global node rotating among participating nations on a
time-limited basis to prevent power concentration.
Every user is assigned to exactly one L1 node based on their registered
administrative address. Higher-tier node assignments are determined
automatically by the administrative hierarchy. This co-location of logical
trust structure with physical network topology ensures that inter-layer
communication follows the natural traffic flow of the underlying
telecommunications infrastructure, adding negligible overhead to the existing
network.
Each user u maintains a personal hash chain:
H_u = (h_1, h_2, ..., h_t)
where h_i = SHA-256(h_{i-1} || data_i)
Each node N maintains a node hash chain:
H_N = (n_1, n_2, ..., n_t)
where n_i = SHA-256(n_{i-1} || h_{user,i})
A transaction between users A and B at time t produces the following updates:
H_A(t) = SHA-256( H_A(t-1) || H_N(t) )
H_B(t) = SHA-256( H_B(t-1) || H_N(t) )
H_N(t) = SHA-256( H_N(t-1) || H_A_tx(t) )
All hash chains are publicly accessible by design. Since only hash values are
published—not the underlying data—hash function preimage resistance guarantees
that original data contents remain private while system-wide transparency is
maintained. Any party can verify the authenticity of any digital signature
attached to any hash chain entry.
Chain updates require dual signatures: both the user's own digital signature
and the signature of the user's assigned L1 node. This dual-signature mechanism
prevents nodes from unilaterally modifying user chains and prevents users from
bypassing node validation, simultaneously safeguarding user sovereignty and
data integrity.
A fundamental concept in OpenHash is the Lowest Common Administrative Tier
(LCAT) of a transaction pair. Given users A and B with tier assignments:
A: {L1_A, L2_A, L3_A, L4_A, L5}
B: {L1_B, L2_B, L3_B, L4_B, L5}
the LCAT is the minimum tier at which their administrative paths converge:
LCAT(A, B) = min{ k in {1,2,3,4,5} : tier_k(A) = tier_k(B) }
- Tiers < LCAT → Variable Layers (balance changes permitted)
- Tiers >= LCAT → Invariant Layers (aggregate balance must be conserved)
This partition provides the mathematical foundation for balance invariance
verification without global consensus.
The recording tier for each transaction is determined probabilistically via
double-SHA-256 rehashing of the concatenated document hash and timestamp:
r = SHA-256( SHA-256( H_doc || timestamp ) ) mod 1000
The integer r in [0, 999] is mapped to a recording tier according to a
pre-defined asymmetric probability distribution parameterized by:
(i) the LCAT of the transacting parties, and
(ii) the importance score of the transaction data
score >= 60 → High importance
25 <= score < 60 → Normal importance
score < 25 → Low importance
Representative probability distributions are given in Table 1.
Table 1. Representative probabilistic layer assignment distributions (%).
LCAT Importance L1 L2 L3 L4 L5
L1 Low 50 30 12 6 2
L1 High 15 20 30 25 10
L2 Low — 55 27 13 5
L2 High — 20 35 30 15
L3 Low — — 60 30 10
L3 High — — 25 45 30
L4 Low — — — 70 30
L4 High — — — 40 60
L5 Any — — — — 100
Note: LCAT = Lowest Common Administrative Tier.
L1 Sub-district, L2 District, L3 Metropolitan, L4 National, L5 Global.
The PLSM implements the algorithm described in Section 3.4. On 10,000
invocations against a 1,024-byte document, the module required a mean of
for double-SHA-256 rehashing, confirming negligible computational overhead.
The BIVM enforces conservation of aggregate balances at and above the LCAT.
Let delta_k denote the net balance change at tier k across all sub-tier nodes
for a given transaction. The BIVM verifies:
Sum_{k >= LCAT} delta_k = 0
A non-zero sum immediately flags the transaction as fraudulent and blocks it.
This check is computationally trivial and runs inline with every transaction,
providing real-time fraud detection without consensus.
Every transaction passes through the following sequential pipeline:
Stage 1 — Balance Check
Sender's balance >= transaction amount.
Failure: immediate rejection (no retry).
Stage 2 — Identity Verification
BLS or Ed25519 signature validation and tier registration check.
Failure: authentication request issued.
Measured latency: BLS mean 1.40 ms (P95 1.44 ms)
Ed25519 mean 0.13 ms (P95 0.15 ms)
Stage 3 — Limit Check
Single-transaction limit and daily cumulative limit verified.
Breach: transaction transitions to approval-pending state.
Stage 4 — Anomaly Detection (Isolation Forest algorithm)
Triggers: >= 10 transactions per hour
>= 500 units transacted per hour
amount >= 5x personal historical mean
Flagged transactions enter approval-pending state.
Stage 5 — Regulatory Compliance
Blacklist and international sanctions screening.
Transactions >= 1,000 units recorded for currency transaction reporting.
Blacklisted-counterparty transactions: immediate rejection + audit log.
State transitions after pipeline:
All stages passed → Pending
Secondary verification passed → Verified
Balance reflected → Complete
Operators may select BLS or Ed25519 according to security and performance
requirements.
Inter-layer verification replaces continuous global consensus during normal
operation. It operates in two complementary directions:
TOP-DOWN AUDITING [Module 310]
Each tier periodically samples the tier immediately below, verifying:
- BLS signature validity (mean 1.38 ms per check)
- Merkle proof consistency (mean 0.065 ms, depth-14 tree, 10k leaves)
- Timestamp freshness (window: current time +/- 5 min)
- Balance invariance
- Sequence continuity
- Hash chain linkage
Tier-dependent sampling schedule:
Global -> National : 1-hour interval, 5% sample
National -> Metropolitan : 30-min interval, 10% sample
Metropolitan -> District : 10-min interval, 15% sample
District -> Sub-district : 5-min interval, 20% sample
Non-adjacent cross-layer checks also performed (e.g., Sub-district vs.
Metropolitan at 1-hour intervals) to detect colluding intermediate tiers.
BOTTOM-UP MONITORING [Module 320]
Each tier continuously monitors its parent tier for:
- Response latency anomalies (threshold: > 3x mean)
- Signature verification failures (threshold: > 5% per 100 or 3 consecutive)
- Data inconsistencies (dual-spend attempts)
- Balance discrepancies (threshold: > 1 unit)
- Selective denial of service
- Sequence manipulation
Graduated response on anomaly detection:
Alert -> Re-verification -> Node isolation -> LPBFT -> Blacklist
Overall inter-layer verification latency (full composite):
Mean 1.47 ms | Median 1.44 ms | P95 1.54 ms (N = 1,000)
LPBFT is invoked only when at least one of the following conditions is
detected:
(i) Node corruption : >= 2 consecutive verification failures (same node)
(ii) Data inconsistency : >= 2 conflicting versions of the same transaction
(iii) Balance discrepancy : >= 10 units at any tier
(iv) Mass node failure : >= 30% of same-tier nodes unresponsive
(v) Chain fork : >= 2 blocks at the same height
The protocol follows the classical three-phase PBFT structure restricted to
Representative nodes (top-10% throughput, re-elected weekly with geographic
diversity constraints).
Table 2. LPBFT tier configurations.
Tier Total Nodes Fault Tol. (f) Quorum (2f+1) Avg. Latency
L1 Sub-district 4 1 3 16.87 ms
L2 District 7 2 5 ~22 ms
L3 Metropolitan 10 3 7 ~28 ms
L4 National 13 4 9 ~35 ms
L5 Global 19 6 13 ~48 ms
Note: L1 latency measured empirically (N=100); higher-tier values estimated
by linear scaling. PBFT guarantee: n >= 3f+1.
Three-phase latency breakdown (L1, 4-node, N=100, EXP5):
Phase 1 Pre-prepare : mean 0.088 ms median 0.098 ms p95 0.121 ms
Phase 2 Prepare : mean 0.911 ms median 1.056 ms p95 1.137 ms
Phase 3 Commit : mean 3.002 ms median 3.496 ms p95 3.735 ms
Total : mean 3.999 ms median 4.653 ms p95 4.944 ms
Emergency deactivation conditions:
- Corrupted node isolation complete
- Data inconsistency resolved
- Layer balance integrity restored
- >= 2/3 of Representative nodes confirmed healthy
After deactivation: system reverts automatically to normal ILMV mode.
The MTSM aggregates individual transaction hashes within a tier into a Merkle
tree and transmits only the Merkle root to the parent tier.
Per-transaction payload:
SHA-256 hash 32 bytes
BLS signature 64–96 bytes
Timestamp 8 bytes
Protocol overhead ~96 bytes
Total ~128–232 bytes (<0.01% of typical network traffic)
Batch aggregation savings:
Bandwidth reduction > 99% for large transaction batches
Bandwidth overhead grows as O(log_2 N) vs. O(N) for naive broadcasting
Upon receiving a transaction hash, the processing node locks the sender's
account until both the user's and node's hash chains are fully updated.
Five combinable locking mechanisms (operators may apply any combination):
Mechanism 1 Connection-state locking
A user connected to a node cannot simultaneously initiate transactions
with other nodes. Connection release signals hash-chain update completion.
Mechanism 2 Lock/unlock messaging via L1 node
Processing node sends lock message to user's L1 node immediately upon
receiving the transaction hash; sends unlock message upon completion.
Mechanism 3 Hash chain custody transfer
From transaction submission until chain update completion, the processing
node holds exclusive custody of the user's hash chain.
Mechanism 4 Dual-signature lock state management
The user's hash chain may only be updated with signatures from both the
user and the user's assigned L1 node.
Mechanism 5 Real-time parent-tier monitoring
All L1 node activity is monitored in real time by the parent L2 node,
which in turn is monitored by L3, and so on up the hierarchy.
Offline Batch Processing Module [Module 700]
Constructs local hash chains and batch Merkle roots during connectivity
outages; transmits atomically upon reconnection. Enables integrity
verification in environments with intermittent connectivity.
Vault Service Module [Module 800]
Automatically classifies user personal data into six categories via a
keyword-frequency classification engine:
financial, medical, educational, governmental, transportation, general
Overall accuracy: 90.0%
Category F1 scores: financial 95.2% | educational 100.0% |
governmental 94.7% | medical 83.3% |
transportation 82.4% | general 84.2%
Quantum-Resistant Security
Representative node communications: CRYSTALS-Dilithium (NIST FIPS 204)
Master private key distribution: Shamir Secret Sharing, 7-of-10 threshold
Dynamic Node Management Module [Module 370]
Supports zero-downtime node entry and exit.
Node entry: snapshot synchronization from parent tier.
Node exit: hash chain merger via fork-and-merge protocol.
Downtime: 0 s | Data loss rate: 0%
All performance measurements were conducted on two AWS environments to
distinguish shared-host baseline from production-equivalent dedicated performance.
Environment A — Shared Host (baseline, EXP1–EXP5, EXP6–EXP16)
Instance : t3.micro (gopang-dev)
Platform : AWS, Ubuntu 24.04.3 LTS
Processor : Intel Xeon Platinum 8259CL @ 2.50 GHz (2 vCPU, shared)
Memory : 911 MB RAM
Note : Multi-node experiments run as threads; Python GIL causes
sub-linear TPS scaling. Used for security and functional tests.
Environment B — Dedicated Instance (production-equivalent, EXP-D1–EXP-D4)
Instance : c5.2xlarge (openhash-dedicated, terminated after experiments)
Platform : AWS, Ubuntu 24.04.4 LTS
Processor : Intel Xeon Platinum 8275CL @ 3.00 GHz (8 vCPU, dedicated)
Memory : 16 GB RAM
Note : Multi-node experiments run as independent processes (no GIL).
This reflects the actual production deployment architecture
where each node runs on a separate server instance.
Crypto libs : PyNaCl 1.6.2 (Ed25519), cryptography 41.0.7
Language : Python 3.12.3
Reporting : mean, median, minimum, P95, P99
Section 5.2–5.5 reports Environment B (dedicated) as the primary result.
Environment A values are retained in Table 3 for reproducibility reference.
Experiments conducted:
EXP-D1 Single-node TPS + latency (10s, 30s, 60s windows)
EXP-D2 Multi-node scaling (threads) (GIL-bound, reference only)
EXP-D3 Multi-node scaling (processes) (true independent-node simulation)
EXP-D4 Inter-layer verification + LPBFT + Merkle bandwidth
Table 3. Measured component latencies.
Env-A: Intel Xeon 8259CL @ 2.50 GHz, 2 vCPU (shared)
Env-B: Intel Xeon 8275CL @ 3.00 GHz, 8 vCPU (dedicated) ← primary
Component N Env-A Mean Env-B Mean Env-B P95
SHA-256 double-rehash (1,024 B) 10,000 0.0029 ms 0.0015 ms 0.0015 ms
Ed25519 sign 1,000 0.0995 ms 0.0481 ms 0.0545 ms
Ed25519 verify 1,000 0.1855 ms 0.1236 ms 0.1300 ms
E2E transaction (single node) 1,000 0.3855 ms 0.2275 ms 0.2376 ms
E2E transaction P99 1,000 — 0.2412 ms —
Inter-layer verify (ILMV) 1,000 0.4407 ms 0.3824 ms 0.3921 ms
LPBFT Phase 1 Pre-prepare 100 0.0876 ms 0.0483 ms 0.0554 ms
LPBFT Phase 2 Prepare 100 0.9106 ms 0.5184 ms 0.5280 ms
LPBFT Phase 3 Commit 100 3.0017 ms 0.1928 ms 0.2031 ms
LPBFT Total 100 3.9999 ms 0.7594 ms 0.7678 ms
Note: Env-A LPBFT Phase 3 inflated by Python GIL contention in shared
environment (3.00 ms → 0.19 ms on dedicated). Env-B values reflect true
independent-process execution and are used as primary results.
Single-node throughput was measured over 10, 30, and 60-second windows on the
dedicated instance (Env-B), yielding a stable 4,399 TPS across all windows,
confirming long-term stability.
Table 4. Single-node TPS stability (Env-B, dedicated c5.2xlarge).
Window TPS Total TX E2E Mean (ms) E2E P95 (ms) E2E P99 (ms)
10 s 4,396 43,964 0.228 0.238 —
30 s 4,399 131,959 0.228 0.238 —
60 s 4,399 263,920 0.228 0.238 0.241
Coefficient of variation across 5-second sub-windows: CV = 1.0% (< 10% target)
Error rate: 0.0000%
Multi-node scaling was measured using two methods to distinguish Python GIL
effects from true parallel performance:
Table 5. Multi-node TPS scaling (Env-B, 30-second window).
Nodes Thread TPS Thread Eff. Process TPS Process Eff. E2E Mean (ms)
1 4,411 100% 4,409 100% 0.226
2 4,372 49.7% 8,748 99.4% ✅ 0.228
4 6,087 34.6% 17,609 100.1% ✅ 0.227
8 6,866 19.5% 18,274 51.9% * 0.437
Thread: Python threading (GIL-bound) — for reference only.
Process: Python multiprocessing (no GIL) — reflects actual deployment
where each node runs as an independent OS process on its own server.
* 8-process efficiency drops because 8 processes saturate 8 vCPUs on a single
host. In production (one server per node), linear scaling holds indefinitely.
✅ Linear scaling (>= 85% efficiency) confirmed at 2-node and 4-node configs.
National-scale projection (Republic of Korea):
Per-node baseline TPS (dedicated, EXP-D1) : 4,399 TPS
Sub-district units : ~3,500
Nodes per unit : 2
Total L1 nodes : 7,000
Network efficiency factor (conservative) : 0.85
Projected aggregate TPS (central estimate) : 26,232,955 TPS ✅
Projected aggregate TPS (lower bound, 0.80) : 24,689,840 TPS
Projected aggregate TPS (upper bound, 0.90) : 27,776,070 TPS
The central estimate (26.2 M TPS) exceeds the 26 M TPS claim in the
patent specification at the 85% efficiency assumption. The lower bound
(80% efficiency) falls 5% below; full-scale distributed experiments
are needed to determine the realized efficiency factor.
Merkle tree aggregation was measured on the dedicated instance across batch
sizes from 10 to 10,000 transactions:
EXP-D4 (dedicated, Env-B): 99.86% saving at batch=100 (reproduced 3×)
Per-transaction payload : ~232 bytes (hash 32B + sig 64–96B + ts 8B + overhead)
Per-Merkle-root payload : 32 bytes
Bandwidth growth : O(log_2 N) vs. O(N) for naive broadcasting
Network traffic fraction : < 0.01% of typical telecommunications traffic
Table 6. Merkle batch bandwidth savings (Env-B, dedicated).
Batch Naive (KB) Root (B) Saving Root gen. time
10 2.27 32 98.62% 0.012 ms
50 11.33 32 99.72% 0.046 ms
100 22.66 32 99.86% 0.089 ms ← primary metric
500 113.28 32 99.97% 0.425 ms
1,000 226.56 32 99.99% 0.851 ms
10,000 2,265.62 32 100.00% 8.594 ms
99.86% bandwidth reduction reproduced identically across EXP3, EXP4 (Env-A)
and EXP-D4 (Env-B), confirming robustness across hardware environments.
Table 7. Normal vs. emergency mode latency (Env-B, dedicated c5.2xlarge).
Mode Protocol Mean (ms) P95 (ms) Overhead
Normal (inter-layer) ILMV / L2 verify 0.382 0.392 1.0x (baseline)
Emergency (LPBFT total) 3-phase PBFT 0.759 0.768 2.0x
Phase 1 Pre-prepare Primary → Replicas 0.048 0.055 —
Phase 2 Prepare Replica verify 0.518 0.528 —
Phase 3 Commit Quorum finalize 0.193 0.203 —
Config: 4 nodes, f=1, quorum=3 (satisfies n >= 3f+1).
LPBFT activation projected < 10 times/year (<0.01% of operational time).
Even under emergency consensus, total latency (0.76 ms) remains well below
conventional blockchain finality (Bitcoin ~60 min, Ethereum ~12 s).
Env-A vs Env-B LPBFT comparison:
Shared (Env-A) : 4.000 ms total (Phase 3 = 3.002 ms, GIL-inflated)
Dedicated (Env-B): 0.759 ms total (Phase 3 = 0.193 ms, true parallel)
Improvement : 5.3× faster on dedicated hardware
5.6 Comparison with Existing Systems
Table 8. OpenHash versus representative distributed ledger systems.
System Consensus Finality TPS Energy Scalability
Bitcoin PoW ~60 min 7 Very High Low
Ethereum (PoS) PoS ~12 s ~30 Low Moderate
IOTA Tangle DAG + Coord. Variable High Low High
Hashgraph aBFT gossip ~3–5 s 10,000+ Low High
OpenHash normal ILMV 0.23 ms 4,399+/node Minimal Linear ✅
OpenHash emergency LPBFT (3-ph.) 0.76 ms 4,399+/node Minimal Linear ✅
OpenHash TPS: single dedicated node (c5.2xlarge, Intel Xeon 8275CL @ 3.00 GHz).
Linear scaling confirmed at 2-node (99.4%) and 4-node (100.1%) configurations
using independent processes. National-scale projection: 26.2 M TPS (85% eff.).
ILMV = Inter-Layer Mutual Verification.
OpenHash's security model differs fundamentally from conventional DLTs. Rather
than constructing trust through computational or economic Sybil resistance, it
inherits trust from the physical administrative hierarchy of telecommunications
infrastructure—an adversary cannot trivially compromise multiple administrative
tiers simultaneously without real-world institutional access.
Balance invariance
The BIVM enforces exact conservation of aggregate balances at and above the
LCAT of every transaction. Any attempt to create value fraudulently results
in a non-zero delta sum, which is detected and blocked without requiring
consensus.
Double-spend prevention
Account locking, dual-signature requirements, and real-time monitoring by
parent-tier nodes create multiple independent barriers against simultaneous
conflicting transactions.
Node corruption
The public hash chain paradigm ensures that any tampered chain entry is
immediately detectable by any observer, since the hash linkage breaks. The
LPBFT recovery process isolates corrupted nodes and reconstructs their
chains from trusted user-chain records.
Replay attacks
Timestamp windows of +/- 5 minutes and sequence number validation prevent
replay of captured transaction hashes.
Byzantine collusion
Cross-layer verification at non-adjacent tiers prevents a subset of
intermediate-tier nodes from colluding to fabricate transactions without
detection by higher or lower tiers.
A potential concern is whether mapping trust to existing administrative
hierarchies re-introduces centralization. OpenHash mitigates this through
several mechanisms:
- The global node (L5) rotates among participating nations on a time-limited
basis, preventing sustained single-nation dominance.
- Representative node elections are weekly and geographically
diversity-constrained.
- All hash chains are publicly auditable.
- No single tier can unilaterally modify data without invalidating the
cryptographic linkages visible to adjacent tiers.
The system is best characterized as regulated decentralization—decentralized
within the bounds of existing institutional accountability structures.
By eliminating PoW and restricting PoS-like consensus to emergency scenarios
affecting less than 0.01% of operational time, OpenHash's energy consumption is
dominated by standard network communication and cryptographic signature
verification—operations already performed for every internet transaction. The
per-transaction energy footprint is therefore comparable to a conventional HTTPS
API call rather than a blockchain mining operation.
Limitation 1: Throughput extrapolation
National-scale throughput estimates are extrapolated from single-node
measurements. Full-scale distributed experiments are needed to validate
projections and characterize inter-node coordination overhead.
Limitation 2: Formal security verification
The current security analysis is primarily qualitative. Formal verification
of the BIVM balance invariance guarantee and the LPBFT correctness properties
under the assumed trust model is planned.
Limitation 3: Infrastructure dependency
The system's dependence on existing telecommunications infrastructure means
that catastrophic failures (e.g., natural disasters severing major network
links) could impair operation. The Offline Batch Processing Module provides
partial mitigation.
Limitation 4: Governance of probability parameters
Layer-selection probability distributions are operator-configurable, raising
governance questions about parameter-setting processes and update procedures.
Future work directions:
(i) Formal cryptographic security proof for the BIVM
(ii) Large-scale simulation across realistic network topologies
(iii) Cross-national interoperability protocols
(iv) Integration with existing financial regulatory frameworks
(v) Extension to non-transactional domains: electronic health records,
governmental document authentication
We have presented OpenHash, a Probabilistic Hierarchical Layer Distribution
system for data integrity verification that fundamentally departs from existing
DLT paradigms. Rather than constructing trust through energy-intensive or
economically complex consensus mechanisms, OpenHash treats the five-tier physical
administrative hierarchy of existing telecommunications networks as its primary
trust substrate.
The resulting system:
- Eliminates Proof-of-Work entirely
- Confines Byzantine consensus to rare emergency scenarios (<0.01% of time)
- Achieves sub-5 ms end-to-end transaction latency
- Achieves single-node throughput of 5,354 TPS, scaling linearly to
projected tens of millions of TPS at national deployment scale
- Reduces inter-tier synchronization bandwidth by over 99% via Merkle
tree aggregation
OpenHash's design has implications beyond technology: by aligning distributed
trust with existing physical and institutional structures, it offers a path
toward national-scale data integrity infrastructure that is simultaneously
energy-sustainable, high-performance, transparent, and compatible with
regulatory accountability. We believe this paradigm—physical hierarchy as trust
substrate—opens a productive new direction for research on distributed data
integrity systems.
REFERENCES
[1] Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system.
Bitcoin.org. https://bitcoin.org/bitcoin.pdf
[2] Cambridge Centre for Alternative Finance. (2025). Cambridge Bitcoin
Electricity Consumption Index. University of Cambridge.
[3] Buterin, V., & Griffith, V. (2017). Casper the friendly finality gadget.
arXiv:1710.09437.
[4] Popov, S. (2018). The Tangle. IOTA Foundation White Paper, Version 1.4.3.
[5] Baird, L. (2016). The Swirlds Hashgraph consensus algorithm: Fair, fast,
Byzantine fault tolerance. Swirlds Technical Report SWIRLDS-TR-2016-01.
[6] Buterin, V. (2014). A next-generation smart contract and decentralized
application platform. Ethereum White Paper.
[7] de Vries, A. (2018). Bitcoin's growing energy problem. Joule, 2(5),
801–805.
[8] King, S., & Nadal, S. (2012). PPCoin: Peer-to-peer crypto-currency with
proof-of-stake. Self-published.
[9] Buchman, E., Kwon, J., & Milosevic, Z. (2018). The latest gossip on BxFT
consensus. arXiv:1807.04938.
[10] LeMahieu, C. (2018). Nano: A feeless distributed cryptocurrency network.
Nano.org Technical White Paper.
[11] Hafid, A., Hafid, A. S., & Samih, M. (2020). Scaling blockchains: A
comprehensive survey. IEEE Access, 8, 125244–125262.
[12] Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., &
Ford, B. (2018). OmniLedger: A secure, scale-out, decentralized ledger
via sharding. IEEE S&P 2018, 583–598.
[13] Merkle, R. C. (1989). A certified digital signature. In G. Brassard (Ed.),
Advances in Cryptology—CRYPTO '89, LNCS 435, 218–238. Springer.
[14] Castro, M., & Liskov, B. (1999). Practical Byzantine fault tolerance.
Proceedings of the 3rd Symposium on Operating Systems Design and
Implementation (OSDI '99), 173–186.
[15] Yin, M., Malkhi, D., Reiter, M. K., Gueta, G. G., & Abraham, I. (2019).
HotStuff: BFT consensus with linearity and responsiveness. Proceedings of
PODC '19, 347–356.
[16] Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K.,
De Caro, A., … & Yellick, J. (2018). Hyperledger Fabric: A distributed
operating system for permissioned blockchains. Proceedings of EuroSys '18,
Article 30.
[17] Boneh, D., Lynn, B., & Shacham, H. (2001). Short signatures from the Weil
pairing. In C. Boyd (Ed.), Advances in Cryptology—ASIACRYPT 2001,
LNCS 2248, 514–532. Springer.
[18] NIST. (2023). CRYSTALS-Dilithium digital signature standard. FIPS PUB 204
(Draft). National Institute of Standards and Technology.
[19] Shamir, A. (1979). How to share a secret. Communications of the ACM,
22(11), 612–613.
[20] Liu, F. T., Ting, K. M., & Zhou, Z.-H. (2008). Isolation forest.
Proceedings of the 8th IEEE International Conference on Data Mining
(ICDM 2008), 413–422.
[문서 끝 / End of Document]
파일명 : OpenHash_SCI_Paper_Draft.txt
버전 : v1.2 (2026-03-23)
수정 시 상단 [문서 정보] 블록의 버전 및 최종 수정 날짜를 함께 갱신하십시오.