```bbcode
LOGOS-Σ
A blockchain whose unit of state is an occupation cell, not an account.
Devnet only. No token sale. No mainnet. No price.
The claim in one paragraphEvery chain in production uses the account (or UTXO) as its unit of state. I argue that is a
granularity error, and that three separate "unsolved" problems — state bloat, hot shards, and
expensive state-root updates — are three consequences of it. LOGOS-Σ uses a content-addressed
cell as the unit instead. Every number below was measured on
real Ethereum mainnet data(blocks 25,730,163–25,730,222; 16,396 txs; 383 contracts), with a C11 benchmark. The negative
results are published as-is.
1. Sharding: the same algorithm, two granularitiesI routed real mainnet contract load (8,131 real calls, top-10% of contracts carry 70.66% of load)
onto 64 shards.
unit routing hottest shard vs ideal
----------------------------------------------------------------
account uniform hash (status quo) 2,587 20.36x
account Gibbs occupation 2,513 19.78x <- 1.03x = USELESS
cell uniform hash 160 1.26x
cell Gibbs occupation 133 1.047x
Note the third row.
Smart routing at account granularity bought me nothing (1.03x). I am
publishing that because it is the interesting part: the single hottest contract alone carries
30.9% of load, i.e. 19.8x the average per-shard load. No routing algorithm can split an
indivisible key — that is a lower bound, not an implementation flaw. It also means every
"smarter sharding" claim from an account-based chain is bounded by the same wall.
Change the unit to a cell and the same algorithm gives 20.36x -> 1.047x of ideal, a 19.45x
makespan improvement.
The value is in the granularity first, the algorithm second.
2. State root: a homomorphic commitment, not a Merkle treeroot = f_A(x) = A · x mod q q = 3^8, m = 100, n = 1024 (lattice / SIS)
one cell changes: f_A(x + Δ·e_j) = f_A(x) + Δ·A[:,j] ⟹ O(m), not O(log N) hashes
full recompute of root 63,813.2 ns
incremental update O(m) 846.4 ns -> 75.4x
Merkle-SHA-256 path, 20 levels ~58,090 ns -> 68.6x
incremental root == recomputed root -> byte-exact, verified over 20,000 updates
This is not an engineering trick. It is a property SHA-family hashes
provably cannot have:
if a compressing hash is a homomorphism on a full group, its kernel is a nontrivial subgroup and
collisions fall out of Gaussian elimination. f_A escapes that theorem because the hash domain is
the
short set {0,1,2}^n, which is not a subgroup — so a valid collision must be a short kernel
vector, i.e. SIS. One-wayness reduces to worst-case SVP (Ajtai 1996), so it is quantum-resistant on
a stated assumption rather than only via Grover-sqrt.
Honest trade-off:
raw hashing with f_A is 1.4x slower than SHA-256. The win is incremental
update, provable reduction, and aggregation-by-addition — not raw throughput.
3. State dedup on real chain datasource (real mainnet) block N cells D cells N/D saved
------------------------------------------------------------------------
tx calldata 16 B 507,737 196,367 2.59x 61.33%
tx calldata 32 B 253,868 140,545 1.81x 44.64%
contract bytecode 64 B (byte metric, chunked per object) 6.05% <- see below
Calldata dedup is real and the cause is measurable:
62.49% of calldata bytes are 0x00(32-byte ABI padding). Byte entropy is 3.93 bit/byte, so the entropy floor alone is 2.035x.
A correction to my own published number. An earlier draft reported 0.57% for bytecode at 64 B.
That was an artefact of my benchmark, which chunked across the concatenated buffer of 383 contracts
and thereby manufactured misalignment at every contract boundary. Chunking per object — the correct
model of chain state — gives 6.05% at 64 B, 21.70% at 16 B. The correction makes my number look
better, which is why I am stating it rather than quietly applying it.
Second negative result — a hypothesis of mine, refuted by measurement. I wrote that weak
bytecode dedup was caused by frame misalignment and that content-defined chunking (Rabin/CDC) would
fix it. I then measured it. Control test, to separate "CDC is useless here" from "I implemented CDC
wrong": on a deliberately 1-byte-shifted copy, fixed blocks recover 0.38% while CDC recovers 52.17%
— so the implementation works. But on real bytecode CDC moves 6.05% only to 7.07%. The hypothesis is
wrong: the 383 hottest mainnet contracts are simply distinct, and EIP-1167 proxies are 45 bytes and
rarely in the hot-call set. The bytecode figure stays low.
A surprise came with it: on calldata,
fixed chunking beats CDC by 1.65x (38.30% vs 23.18%),
because calldata has a real 32-byte ABI frame that CDC deliberately breaks. Design rule: align to the
frame when there is one, use CDC only when there is not. Today's sellable number is calldata/DA, not
bytecode.
Mandatory control: 4 MiB of random data, 32 B blocks: N = 131,072 -> D = 131,072, saving
0.00%. Nothing here creates bytes from nothing. Shannon and the pigeonhole bound hold; this
only harvests redundancy that is already in the data.
4. Devnet — running, not simulatedFour validator processes, real HTTP, 3-phase BFT (Tendermint/HotStuff-style, f < n/3 — the safety
part is not reinvented), leader chosen by Gibbs occupation instead of uniformly.
T1 consensus 4 nodes, same height, SAME state root PASS
T2 commitment incremental root == recomputed root, byte-exact PASS
T3 dedup 1,200 cell writes -> 302 physical cells (3.97x) PASS
T4 fault kill 1 of 4 (f=1 < n/3), chain keeps committing PASS
(T3 traffic is my own devnet load, chosen to have the shape of real calldata. It demonstrates the
mechanism; the market measurement is section 3, on mainnet data.)
5. Distribution — the part most L1s get wrongThe number one problem for a new L1 after mainnet is not TPS. It is that nobody uses it. The
standard answer is grants and airdrops, i.e. positive acquisition cost that stops working when the
money stops. Exactly two systems in history reached hundreds of millions of users at near-zero
acquisition cost:
i-mode (NTT DoCoMo, 1999; curated menu, 9% gateway fee) and
Monternet 移动梦网 (China Mobile, 2000; carrier billing, 85:15 revenue share). LOGOS-Σ puts
both in the protocol layer rather than the marketing layer: ΣMenu (pull, 9% protocol fee on dApp
revenue instead of volatile gas) and ΣPush (push, token-bucket quota allocated by occupation
rather than equally).
Measured on 250,839 real human comments: the top
10.42% of channels cover 80% of engagement
— nearly the same ratio as DoCoMo's 10.71% curated menu in 1999. And the honest caveat: when
occupation is
uniform, all three quota schemes tie (≈1x). ΣPush only pays off under real skew.
6. What does not exist yet- No mainnet. No circulating coin. No token sale. No price.
- 19.45x is routing makespan on real load — it is not a TPS figure.
- The L2 coordination numbers (11.16x mean / 15.36x p99) are borrowed from the underlying VMC mesh
work and have not been re-measured for a rollup sequencer. - f_A parameters still need an official lattice-estimator run before any production use.
- No independent cryptographic audit. No legal opinion on token issuance.
- Signatures currently use Ed25519. ML-DSA (FIPS 204) is the target — I will not hand-roll a
signature scheme.
7. What I want from this forumNot investors — reviewers. Specifically:
- Break the granularity argument in section 1. Is there an account-level scheme that beats the
indivisible-key lower bound? - Attack the f_A parameters (q=3^8, m=100, n=1024). The birthday bound is not the security
level here; lattice-SIS is, and it is cheaper. Tell me where m is too small. - Section 3 claims fixed chunking beats CDC on ABI-framed data. That clause is now normative in my spec,
so I would rather find it wrong here than after other people build on it. A counter-measurement on a
different block window is the most useful thing you can send me.
Website:
https://logossigma.comSource, benchmark, raw data manifest, devnet:
(https://github.com/anhkhoavanhua/logos-sigma)whitepaper:
https://github.com/anhkhoavanhua/logos-sigma/blob/main/docs/WHITEPAPER.md This is a technical document. It is not an offer, solicitation, or investment advice.```
