mhtirogla
Home
Systems
API
Pricing
About
Log in
← Back
Home
›
Systems
›
Security and identity
audit-log
tamper-evident audit log
Trillian
System
Techniques · 5
Primitives · 17
audit-log
Raft
distributed · medium: Leader-based consensus on a replicated log; one leader per term, majority commit; the default for a strongly consistent replicated state machine.
›
Tamper-evident audit log
security · medium: An append-only log whose Merkle root, signed per batch, lets anyone verify an entry is present and history was never rewritten, with log-size proofs.
›
Transparency log
security · medium: A public append-only Merkle tree whose signed heads let anyone verify an entry is present and history was only extended, with log-size proofs.
›
Witness cosigning
security · medium: Independent witnesses cosign log checkpoints so a log cannot show different views to different clients
State-machine snapshots
distributed · medium: Periodically save the state a log has produced at index i so the log prefix can be deleted; recovery and catch-up become load snapshot plus replay suffix.
›
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
Merkle tree
data-structures · low: Hash tree for verifying and diffing large datasets with logarithmic proofs
Digital signatures (Ed25519)
security · low: Small, fast, deterministic public-key signatures that prove who produced a message; the default for tokens, releases and protocols.
›
Trusted timestamping
security · low: RFC 3161 time-stamp tokens: a TSA signs a hash with time, proving data existed then
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
B+ tree
storage · low: Balanced high-fanout search tree with all values in linked leaves; the default on-disk index for point lookups and range scans.
›
Group commit
storage · low: Let concurrent committers share one log write and fsync; throughput grows with concurrency while each commit still waits at most about two fsyncs.
›
Leases
distributed · low: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.
›
Exponential backoff with jitter
systems · low: Retry after delays that grow geometrically and are randomized, so failed clients spread out instead of hammering a recovering service in synchronized waves.
›
Segmented log
distributed · low: Split an append-only log into files named by their first offset, write only the newest, and find any record by binary search plus a sparse index.
›
Copy-on-write fork
hardware-os · low: fork() gives the child the parent's whole address space by sharing pages read-only and copying one only when someone writes it; vfork and posix_spawn skip even that.
›
Copy on write snapshots
storage · low: Point-in-time snapshots by sharing pages/extents and copying only on write
Futex-based mutex
concurrency · low: A mutex that is one atomic word in user space and enters the kernel (futex wait/wake) only under contention; how std and glibc locks work.
›
Fencing tokens
distributed · low: A number that grows with every lock grant and is checked by the protected resource, so a paused ex-holder's late write is rejected.
›
SIMD programming
hardware-os · low: Process 4-16 lanes per instruction with AVX2, AVX-512 or NEON via Rust std::arch, with runtime dispatch and a portable fallback.
›
+ 1 more primitives
System
Techniques · 5
Primitives · 17
audit-log
Raft
distributed · medium: Leader-based consensus on a replicated log; one leader per term, majority commit; the default for a strongly consistent replicated state machine.
›
Tamper-evident audit log
security · medium: An append-only log whose Merkle root, signed per batch, lets anyone verify an entry is present and history was never rewritten, with log-size proofs.
›
Transparency log
security · medium: A public append-only Merkle tree whose signed heads let anyone verify an entry is present and history was only extended, with log-size proofs.
›
Witness cosigning
security · medium: Independent witnesses cosign log checkpoints so a log cannot show different views to different clients
State-machine snapshots
distributed · medium: Periodically save the state a log has produced at index i so the log prefix can be deleted; recovery and catch-up become load snapshot plus replay suffix.
›
Write-ahead log
storage · low: Append each change to a checksummed sequential log and fsync it before touching data pages; the basis of crash durability in nearly every database.
›
Merkle tree
data-structures · low: Hash tree for verifying and diffing large datasets with logarithmic proofs
Digital signatures (Ed25519)
security · low: Small, fast, deterministic public-key signatures that prove who produced a message; the default for tokens, releases and protocols.
›
Trusted timestamping
security · low: RFC 3161 time-stamp tokens: a TSA signs a hash with time, proving data existed then
CRC32C checksums
hardware-os · low: The Castagnoli CRC-32 with dedicated instructions on x86 (SSE4.2) and ARMv8. It is the standard fast integrity check for storage blocks, logs and network frames.
›
fsync, O_DSYNC and O_DIRECT
hardware-os · low: What fsync, fdatasync, O_DSYNC, O_DIRECT and F_FULLFSYNC really guarantee on Linux and macOS, and the exact call sequences for crash-safe files.
›
B+ tree
storage · low: Balanced high-fanout search tree with all values in linked leaves; the default on-disk index for point lookups and range scans.
›
Group commit
storage · low: Let concurrent committers share one log write and fsync; throughput grows with concurrency while each commit still waits at most about two fsyncs.
›
Leases
distributed · low: A lock that expires on its own: bounded-time ownership that survives crashes and partitions, given bounded clock drift and fencing tokens on writes.
›
Exponential backoff with jitter
systems · low: Retry after delays that grow geometrically and are randomized, so failed clients spread out instead of hammering a recovering service in synchronized waves.
›
Segmented log
distributed · low: Split an append-only log into files named by their first offset, write only the newest, and find any record by binary search plus a sparse index.
›
Copy-on-write fork
hardware-os · low: fork() gives the child the parent's whole address space by sharing pages read-only and copying one only when someone writes it; vfork and posix_spawn skip even that.
›
Copy on write snapshots
storage · low: Point-in-time snapshots by sharing pages/extents and copying only on write
Futex-based mutex
concurrency · low: A mutex that is one atomic word in user space and enters the kernel (futex wait/wake) only under contention; how std and glibc locks work.
›
Fencing tokens
distributed · low: A number that grows with every lock grant and is checked by the protected resource, so a paused ex-holder's late write is rejected.
›
SIMD programming
hardware-os · low: Process 4-16 lanes per instruction with AVX2, AVX-512 or NEON via Rust std::arch, with runtime dispatch and a portable fallback.
›
PRNGs (PCG, xoshiro)
numerics · low: Small, fast, statistically strong non-cryptographic generators: PCG32 and xoshiro256**, with seeding, parallel streams and unbiased ranges.
›
Copy for AI
Similar systems
Share the most building blocks with this one.
coordination-store
29 %
key-transparency
28 %
ledger-db
23 %
btree-engine
22 %
filesystem
21 %