Proof of Time: Can Blockchain Security Be Built Over Years Instead of Bought?

Proof of Time: Can Blockchain Security Be Built Over Years Instead of Bought?

The mathematical baseline for Proof of Infrastructure Endurance (PoIE): what holds up, what doesn’t, and what we test next. Most blockchains give influence to whoever can spend the most right now: hash power in Proof of Work, stake in Proof of Stake. Whoever brings the most resources today can, in principle, take over tomorrow. GrahamBell, the Layer 1 blockchain I’m building, tests a different idea. New identities (IDs) are issued one at a time at a fixed global rate, one every 30 seconds (1,051,200 a year), no matter how much hardware joins. Each participant can try at most one hash per second, and groups of other participants, called Witness Chains, enforce that cap. If that holds, influence can’t be bought in a burst. It has to be built up over years, while everyone else builds it up too. I call this Proof of Infrastructure Endurance (PoIE), or Proof of Time (A new time-based sybil-resistance model). That’s a claim, not a result. So Stage 1 of the project is to test it openly and publish the results whether they support it or not. This article covers the first milestone. What this milestone is, and isn’t Milestone 1 is math, not a network simulation. It calculates exact formulas and exact probabilities for the rules in the current specification. Independent methods cross-check them (exhaustive enumeration, dynamic programming and seeded Monte Carlo); all 130 checks agree, and anyone can reproduce every number bit for bit from the repository. It deliberately takes a worst case: the attacker’s IDs are online 100% of the time, while honest IDs are online only part of the time. It also assumes the rate limit holds: no one can win more than their fair share of new IDs by faking participants. Whether the limit holds in practice, and what it would cost to get around, is what the next milestones test. Everything below is conditional on it. 1. Time does what it’s supposed to do Suppose an attacker wins a share s of all new IDs. Its share of active IDs rises towards a ceiling and never passes it. If every honest ID is online, the ceiling is simply s. An attacker winning 30% of new IDs ends at 30%, never at 51%. If only a fraction f of honest IDs is online, the ceiling is s / (s + f(1 − s)). With half of honest IDs online, an attacker winning 40% of new IDs does eventually pass 51%, after 16.4 years. Honest uptime is therefore part of the security model, not an afterthought. Long-run attacker share. Horizontal: the share of new IDs the attacker wins. Vertical: the share of all active IDs it eventually holds. With every honest ID online (dark line), the attacker never holds more than its share of new IDs. Honest downtime (lighter lines) raises it, which is why uptime is part of the security model. The extreme case is an attacker that wins every new ID. Starting from 2.9 million existing IDs, it still needs 2.87 years to reach 51%. That number is why we raised the planned genesis distribution from 2.1M to 2.9M IDs. At 2.1M, a two-year floor held only while 96% of genesis IDs stayed active. At 2.9M it tolerates 30% of them going inactive. 2. The math broke parts of the design, and we fixed them This is the part I value most. The analysis found real weaknesses, and the specification changed because of them: Restart attack. In an earlier design, a miner’s randomness stayed the same for its whole connection. It could work out when it would win, and reconnect until it got a better draw. That was worth 150–182× the honest rate. Fresh randomness every round, with one attempt per round, brings it to exactly 1×: no advantage at all. Committee capture. The committee that manages placement used to be filled by block miners. Under that rule, an attacker with 25% of IDs could stall it with probability above 99.9%. Seats are now filled by lottery over all active IDs, and the same attacker succeeds with probability about 2 in a million. Difficulty. With a Bitcoin-style retarget, an attacker who doubles the miners for one window earns 100% more IDs per miner-second. Count-based difficulty, which follows the exact number of admitted miners, removes that first-order gain. Seat churn. Every time a witness went offline, its seat used to be reshuffled, giving an attacker constant fresh chances at a favourable group. Now a seat is freed only by a ban or an absence longer than 30 days. That cuts seat changes to 3.6% of what they were. 3. What is still weak Each witness group has 40 seats and needs 27 signatures to approve. Capture is very unlikely. With 25% of registered IDs, the chance an attacker holds enough seats to sign without any honest member is about 2 in 100 million per group. Even then it cannot make an invalid or early block valid, because every validator re-checks every block. Blocking is much easier. Holding 14 of 40 seats is enough to refuse to sign and stall a group. At 25%, that happens in about 10% of groups. It’s local. A stalled group affects only its own miners, who move elsewhere in about 450 seconds, and the rest of the network keeps running. The calculation assumes refusing to sign costs nothing. The protocol bans an online witness that still refuses after its “One Chance”. Whether that ban makes blocking too expensive is the most important question for the next stage. Honest uptime matters more than I expected. Without any attacker, keeping fewer than 1% of groups stalled needs honest witnesses online 81.5% of the time under a simple “any 27 of 40” rule. It needs 90.75% under the current rule, which also requires 7 of the 10 members of a group’s leader chain. That leader requirement costs nine points of uptime, so we’ll test replacing it: any 27 of 40 makes a block valid, and the leader is paid only if it signed. What’s next M2, cryptographic core. BLS signatures and randomness, tested against manipulation. M3, issuance simulation. Thousands of simulated nodes with realistic outages: the main test of the thesis, including the rate limit. M4, witness layer. Bans, the alternative quorum rules and blocking attacks. M5, costs. What an attacker must pay, and what a household computer can handle. M6, full scale. The full-scale runs and a public release. The code, every table, the cross-checks and the assumptions behind each number are open source (Apache-2.0):https://github.com/HurairahShamsi/grahambell-simulation If you see a flaw, I want to hear it. That is the point of doing this in public. Learn more: https://grahambell.io

Original Source

Read the full article at Hackernoon →

KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.