Why We Moved to Tephra

🌋 This was a consensus migration, not a naming exercise

Silica did not move to Tephra because we wanted a cleaner label. We moved because the older consensus path — an aggressively modified DAG pipeline built around Tephra ingress and a first-generation Crystallite v1 commit path — was doing too many jobs across too many seams.

That older design borrowed from Narwhal/Bullshark-style thinking: separate payload dissemination from ordering, push data-plane work earlier, and let the DAG carry more of the protocol. That got us valuable properties early: strong batching, good payload fanout, and a clear performance mindset. But once we pushed it into a more demanding asynchronous, sharded, recovery-heavy environment, the edges started to show.

Tephra is the result of that learning. It is Silica's gossip-about-gossip (GaG) ordering layer: a hashgraph-style event DAG where honest nodes reconstruct the same communication history and derive deterministic order locally through structure and virtual voting.

🧱 What the old path was trying to achieve

The old pipeline was not misguided. It was trying to solve real problems the right way:

• Tephra ingress pushed transaction admission, batching, and dissemination out of the hot consensus core.
• The DAG structure let us reason about proposal ancestry without collapsing everything into a single linear mempool queue.
• Crystallite v1 tried to turn DAG progress into a deterministic commit path that execution could consume cleanly.
• The broader system was optimized for throughput, bounded hot paths, and sharded execution from the start.

In other words, v1 was a serious attempt to preserve the best parts of DAG-based dissemination while still producing deterministic order and finality surfaces for the rest of the stack.

⚠ Where the old design started fighting us

The challenge was not that the DAG idea was bad. The challenge was that too much consensus meaning had become distributed across multiple layers and heuristics.

1. Order was harder to reason about than it should have been

In the older path, deterministic commit behavior depended on more than “all honest nodes eventually see the same history.” In practice, parts of the commit decision could still be sensitive to which quorum-sized subset of next-round information arrived first and how exact parent references lined up at closure time.

That is survivable in a prototype. It is not the invariant you want at the heart of deterministic finality.

2. We paid for a split source of truth

The data plane was excellent at admission and dissemination, but the actual ordering truth lived further downstream in a commit/linearization path with its own structural assumptions. That meant engineers and operators had to keep asking a subtle question:

Is this layer carrying data, or is it already deciding consensus meaning?

When that boundary is blurry, debugging becomes slower, audits become harder, and recovery logic becomes more delicate.

3. Recovery and replay became more complicated than we wanted

Under partial visibility, backlog replay, or frontier repair, we found ourselves spending too much effort on synchronization corner cases: orphan handling, missing frontier material, certificate identity alignment, and keeping late-arriving DAG information from mutating the meaning of earlier progress.

A fast protocol that is hard to recover cleanly is not finished. It's just fast on a good day.

4. Too much coordination leaked into the control plane

The old path could be made to work, but it carried more semantic bookkeeping than we wanted. The protocol was doing useful work, but also spending too much energy proving to itself that different nodes were still talking about the same thing.

🔍 The specific limitation we refused to normalize

One of the core lessons from the v1 path was this: a deterministic protocol cannot allow commit meaning to depend on the wrong kind of partial view.

In the older leaderless DAG commit flow, a round could look “closed” once the next round crossed a quorum threshold, but the exact set of parent references visible at that moment could still influence which earlier slots appeared directly committable. Different honest nodes could therefore reach closure with different yet quorum-sized views and derive different immediate commit sets.

Once that happens, downstream artifacts such as commit indices, certificate identities, and finality packaging start inheriting divergence risk. Even if the system can eventually reconcile, the architecture is telling you something important: the ordering rule is not anchored tightly enough to a single canonical history.

🕸 Why Tephra is the better long-term foundation

Tephra changes the question. Instead of asking whether a separate commit heuristic can safely summarize a disseminated DAG, Tephra makes the event DAG itself the ordering substrate.

• Gossip-about-gossip: Each event records not just payload context, but who saw what and when through self-parent and other-parent links.
• Shared causal history: Honest nodes reconstruct the same event DAG from the same gossip history.
• Virtual voting: Witness, visibility, fame, and ordering are computed locally from structure rather than from a large stream of explicit vote traffic.
• Same DAG, same order: The protocol gets closer to the invariant we actually want — identical communication history yields identical ordered proposals.

Tephra does not merely replace an old commit function. It narrows the architecture around a stronger idea: ordering should come from the communication graph itself, not from downstream interpretation of a dissemination graph plus special-case commit rules.

🧭 What we kept, and what we intentionally changed

This migration was not a full discard-and-rewrite. Some parts of v1 were correct and stayed.

What we kept

• Tephra ingress still matters. It remains Silica's data plane for admission, batching, and dissemination.
• Crystallite still matters. It remains the deterministic execution/apply layer.
• Lithification still matters. Finalized results still need anchors, receipts, certificates, and replay-friendly checkpoints.
• Cali still matters. Monitoring and recovery are part of the architecture, not afterthoughts.

What changed

• Tephra is now the ordering truth. That boundary is explicit and intentional.
• Consensus meaning moved closer to the actual event graph.
• Execution no longer needs to inherit ambiguous ordering seams.
• Recovery logic gets to orbit a cleaner core.

🚀 The improvements we were aiming for

The point of moving to Tephra was not just “make it more elegant.” It was to improve the real properties that matter in a production protocol.

• Cleaner determinism: Fewer places where partial views can distort immediate commit interpretation.
• Less control-plane noise: More consensus meaning computed locally from structure, less carried in extra coordination traffic.
• Sharper layer boundaries: Tephra ingress disseminates, Tephra orders, Crystallite applies, Lithification packages, Cali judges and enforces.
• Better replay and recovery semantics: A stronger canonical history makes backlog replay and restart behavior easier to reason about.
• Stronger long-term scalability: Sharding and deterministic execution benefit from a simpler, more canonical ordering substrate.

🎯 Our intent going forward

Tephra is the consensus direction we actually want to scale, harden, and explain publicly.

The intention is straightforward:

1. Keep Tephra ingress narrow and excellent as the data plane.
2. Keep Tephra authoritative as the ordering and consensus layer.
3. Keep Crystallite honest as apply, not a second ordering engine.
4. Keep Lithification and Cali operationally useful as proof, checkpoint, monitoring, and recovery surfaces.

That gives us an architecture that is faster to reason about, easier to operate, and more faithful to the deterministic finality story we want Silica to tell.