Correct under contention, explicit when something is wrong.
Stability here means three things: two agents never hold the same lease, a writer that lost its lease cannot pass as current, and a broken record is reported instead of passed over.
Monotonic fencing tokens
Every Kibisis grant on a resource carries a token one higher than the previous grant, including when the same holder takes it again. Renew and release only work with the exact token that was granted. Across the contention runs, tokens never went backwards and no two holders overlapped.
| Measurement | Median | Range | Raw data |
|---|---|---|---|
| Contended lease attempts checked 16-thread and 32-thread runs combined | 64,000 attempts | same in every run | run1 run2 run3 run4 run5 · source · details |
| Times two holders had the lease at once 16-thread and 32-thread runs combined; counted by an independent check in the benchmark | 0 events | same in every run | run1 run2 run3 run4 run5 · source · details |
| Fencing tokens that went backwards 16-thread and 32-thread runs combined | 0 events | same in every run | run1 run2 run3 run4 run5 · source · details |
Multi-process coordination over SQLite
The Python SQLiteLeaseCoordinator coordinates separate processes through one database file. The test runs process counts from two to thirty-two, then pauses a holder past its deadline, and finally kills a process with SIGKILL while it holds the lease and checks the database with PRAGMA integrity_check. These runs use the test script from telarch-benchmarks commit 83f5ecd64ecc against the kibisis Python package at v0.1.0-alpha.4.
| Measurement | Median | Range | Raw data |
|---|---|---|---|
| Lease operations across separate processes 2, 4, 8, 16 and 32 OS processes sharing one SQLite lease database (Python package) | 1,900 operations | same in every run | run1 run2 run3 run4 run5 · source · details |
| Times two processes held the lease at once All five process counts; overlaps checked from every process's recorded hold intervals | 0 events | same in every run | run1 run2 run3 run4 run5 · source · details |
| Fencing tokens that went backwards across processes All five process counts | 0 events | same in every run | run1 run2 run3 run4 run5 · source · details |
| Late write from a paused holder rejected Holder pauses past its TTL (simulated with a sleep); a second process gets a higher token; a sink that compares tokens refuses the first holder's late write | yes | same in every run | run1 run2 run3 run4 run5 · source · details |
| Lease database intact after its holder is killed with SIGKILL A child process takes the lease and is killed with SIGKILL while holding it. After the lease's TTL, another process opens the database, PRAGMA integrity_check returns ok, and the lease is granted again with the next fencing token | yes | same in every run | run1 run2 run3 run4 run5 · source · details |
Fail-closed checks and rollback protection
- Argus verification returns a report marked invalid with the position of the first broken link; the report type is marked
#[must_use], andensure_valid()turns it into an error. - Checking against an anchor fails if the anchored event is missing or changed, which catches history that was rolled back, truncated or re-hashed.
- Argus refuses non-canonical payloads and malformed names before recording anything, and recovers a poisoned lock without losing committed events.
- Kibisis refuses
renewandreleasefor a token that is no longer current.
| Measurement | Median | Range | Raw data |
|---|---|---|---|
| Position reported for the edited event Event 500,000 of 1,000,000 edited in place; the verifier reports the first break | 500,000 | same in every run | run1 run2 run3 run4 run5 · source · details |
| Fully recomputed history passes a check without an anchor An attacker who can rewrite storage recomputes every hash after an edit; internal consistency alone cannot see it | yes | same in every run | run1 run2 run3 run4 run5 · source · details |
| Same recomputed history caught by the anchor Verification against the anchor recorded before the rewrite | yes | same in every run | run1 run2 run3 run4 run5 · source · details |
Partition simulation
A simulated ten-node network inside one process, with packet loss, checks that every node's audit chain still verifies after the partitions heal. It is a simulation, not a distributed deployment.
| Measurement | Median | Range | Raw data |
|---|---|---|---|
| Audit chains verified after partitions heal 10 simulated nodes; 0%, 25% and 50% simulated packet loss; every chain verified after reconciliation | yes | same in every run | run1 run2 run3 run4 run5 · source · details |
| Highest simulated packet loss Simulated network inside one process | 50% | same in every run | run1 run2 run3 run4 run5 · source · details |
How these numbers were measured. Each figure is the median of its runs, with the range of all runs beside it. Figures from the telarch-benchmarks programs: 5 runs at release tag v0.1.0-alpha.4 on 13th Gen Intel Core i5-13500, 20 logical CPUs, Linux 6.18, rustc 1.97.1, pinned to the performance-core threads (CPUs 0-11). Shared server, not isolated; each run started only after the 1-minute load average was below 4 on two checks 20 s apart. Python multi-process figures: 5 runs of gap3_kibisis_multiproc_crashes.py from telarch-benchmarks commit 83f5ecd64ecc, against the kibisis Python package at v0.1.0-alpha.4, on 13th Gen Intel Core i5-13500, 20 logical CPUs, Linux 6.18, Python 3.12.13, pinned to the performance-core threads (CPUs 0-11). Shared server, not isolated; each run started only after the 1-minute load average was below 4 on two checks 20 s apart. Synthetic data; real workloads will differ. Raw output of every run.