How do you verify a fast-moving blockchain like Solana on another chain, without relying on trusted entity? This has long been a challenge in the cross-chain space. Today, we’re excited to announce a breakthrough: As a part of our multichain settlement stack, we built the first fully working ZK Solana light client on DevNet and verified a slot on Solana Mainnet. In essence, we can now generate a succinct cryptographic proof that Solana’s validators agreed on a particular change in the ledger— and verify this proof anywhere, on any chain (starting with Ethereum).

You can check out https://github.com/twinexyz/solana-proofs for the Mainnet Groth16 proofs of slot: #326251073. We’ve specifically proven account delta proof for Pyth SOL Oracle PDA H6ARHf6YXhGYeQfUzQNGk6rDNnLBQKrenN712K4AQJEG. But we can now prove whatever PDA we want (hint: Twine’s Devnet is coming sooner than expected)

Why Consensus Proving?

Cross-chain bridges historically rely on trusted intermediaries — often multisignature committees or federations — that attest to events on the source chain. Unfortunately, these trust-based designs are vulnerable to human error, social engineering, and outright hacks. In fact, many of the largest crypto hacks in history stem from bridge vulnerabilities or compromised multisigs. A stark example is the recent front-end attack on the Safe (formerly Gnosis Safe) multisig wallet used by the Bybit exchange. In February 2025, hackers (likely North Korea’s Lazarus Group) injected malicious code into Safe’s web interface, tricking all three multisig key holders into signing a fraudulent transaction and stealing $1.4 billion in ETH—the largest exploit in crypto history.

The Safe smart contract itself was secure; it was the trusted UI that got compromised. This incident underscores how even a UI or oracle can become a single point of failure, undermining the security of an otherwise robust system.

Bridging solutions that depend on a handful of validators or custodians pose similar risks. If a majority of bridge guardians are hacked or colluded, they can forge transfers and completely drain funds. We’ve seen this with frequent bridge hacks in the past, amounting over multiple billion dollars. Clearly, trust-minimized alternatives are needed.

This is where zero-knowledge proofs come in. Imagine a “light client” that doesn’t trust any middlemen, but instead directly verifies a succinct proof of another chain’s state. Using ZK proofs for consensus, a target chain (like Ethereum) can validate that Solana’s validators have collectively agreed on a state change, without needing to re-run Solana’s transactions or trust a third party. As Succinct describes, a ZK light client proving Solana’s consensus can “replace traditional methods of bridging that rely on insecure multisigs”.

In other words, ZK proofs let us swap out fragile multisig attestations with an unforgeable mathematical proof of Solana’s ledger finality. This approach offers a provably secure alternative: if the proof verifies, the chain’s consensus was valid – period. No amount of social engineering or key theft can produce a valid proof for a false statement.

What Does It Take to Prove a Blockchain’s Consensus?

In a Proof-of-Stake system like Solana, validators vote on blocks or state change and the supermajority vote (typically >66% of stake) defines the canonical chain. To create a ZK proof of consensus, the prover must demonstrate two things:

• a set of validator signatures on a specific block (or block hash) are all valid, and

• the sum of those validators’ stake weights exceeds the consensus threshold. Essentially, proving consensus = proving a weighted signature set agreed to the block or state change.

This is a non-trivial technical challenge. Blockchains like Ethereum and Solana have many validators signing in each round. Consider Ethereum’s beacon chain: it currently has more than one million validators with a current maximum of 65,535 randomly sampled validators contributing to finality votes on each slot. Solana’s cluster is smaller (on the order of a thousand active validators), but it’s still a large batch of signatures to verify. Verifying a single digital signature (whether an ECDSA, EdDSA, or BLS signature) inside a SNARK is already heavy because of often non native field arithmetics both for signatures and hashes; verifying hundreds or thousands pushes the limits of today’s proving systems.

Verifying one signature in zero-knowledge involves performing the signature scheme’s verification algorithm within the circuit (e.g. elliptic curve scalar multiplications for Ed25519 or group additions and pairings calculations for BLS). Now imagine doing this for 512 signatures in one proof – that’s hundreds of thousands of curve operations! The scale for Ethereum (tens of thousands of signatures) is even higher. Clearly, efficiency is paramount. We need clever techniques and optimizations to handle these bulk verifications.

In summary, proving consensus entails constructing a SNARK (or similar ZK proof) that embeds a batch signature verification and a weighted tally. The proof convinces a verifier that “Block X was signed by validators controlling >=66% of stake.” If we can create such a proof succinctly, any chain or contract can trust Solana’s block X as final by simply checking the proof.

First Challenge – Do We Need to Prove Every Block?

Proving consensus for every block on Solana is a computationally challenging task. This is because Solana produces a block every ~400ms which is much faster than any practical SNARK prover today. There’s also a large cost associated with it. Therefore, at the tradeoff of latency, we prove a range of blocks at the interval of every k slots.

Fortunately, we can optimize computation drastically by leveraging a fundamental blockchain property: each block header commits to the previous block via a hash pointer. In a hash-linked chain, proving one block’s validity and its hash link to a prior block implicitly proves the prior block existed (because to forge it, one would have to find a hash collision or preimage). We do not need to individually prove every block in sequence if we can jump in k steps and rely on the cryptographic links for integrity. For example, if the last proven block was Block N-k, then by proving Block N and the hash pointer from Block N through Block N-k, we prove the existence of  k finalized blocks at the cost of proving consensus on a single block. The upper bound for k is defined by the epoch length which lasts for 432,000 slots (2-3 days).

Practically, our consensus proof can therefore focus on every k blocks – typically the latest finalized slot after the last proof was calculated and at least one transaction of interest happened on the blockchain – rather than every single slot. The ZK proof would include the final block’s hash and the fact that this hash was arrived at by the chain’s progression. We can safely assume that any block not in the chain would require a hash collision to fake, which is computationally infeasible. By linking past and future blocks through hashes, we compress thousands of blocks into one succinct proof step. The challenge then shifts to: picking the right block to prove (e.g. one that is finalized and won’t be reverted) and ensuring our proof includes the necessary hashes to tie it into Solana’s chain.

Solana’s Unique Challenges

Every blockchain has its quirks, and Solana’s consensus and ledger structure introduce unique hurdles for the Twine Consensus Prover. Three issues in particular stand out:

• Solana’s concept of a BankHash (state root) differs from Ethereum’s state root and overall consensus logic;

• Solana’s Tower BFT votes work a bit differently - validators effectively vote on the state, not just individual blocks), and

• the way finality and forks are handled in Solana’s Tower BFT consensus.

BankHash vs. Ethereum’s State Root: In Ethereum, each block header contains a Merkle root of the entire state (all accounts and contracts). This state root is a cryptographic commitment that allows light clients to verify specific account proofs easily. Solana, prioritizing speed, took a different approach. It does not compute a full Merkle trie of all accounts per block (which would be according to the team’s motivation too slow at Solana’s throughput). Instead, Solana uses a Bank Hash as a kind of state fingerprint. In early versions, the bank hash was basically the XOR of all account hashes – extremely fast to update, but not cryptographically collision-resistant. In current implementations, Solana’s bank hash is a combination of several components:

• previous bank hash (parent),

• a Merkle root of only the accounts that changed in the current block (called the accounts delta hash),

• the number of signatures in the block,

• the last PoH (Proof of History) hash of the block​

Formally, one can write it as:

BankHash=H(prev_bankhash∥accounts_delta_hash∥signature_count∥last_blockhash)

This design is clever: it makes updating the state commitment much cheaper than re-hashing the entire state each block, yet it retains some cryptographic soundness (collision resistance comes from the Merkle and final hash). However, it also means there’s no simple persistent state root that a light client can use to prove arbitrary account balances at will. Only accounts that were modified in a given slot are directly provable via that slot’s delta Merkle. This means we have to exploit this feature to link an event on Solana to the Bank hash which the validators vote on.

For our purposes, proving Solana’s consensus doesn’t require verifying every account state, but we do need to be mindful that the thing validators sign (the bank hash) is an amalgam of state components, not just a block hash of transactions. Our ZK prover must therefore validate the bank hash computation to some extent or at least use the same inputs the validators used. We chose to expose the bank hash’s components in our pipeline (more on this shortly) so that the proof can confirm the chain state progresses correctly and hasn’t been spoofed. In contrast, a ZK light client for Ethereum can more straightforwardly use the provided state root as a commitment.

Validators Vote on State, Not Just Blocks: In Solana’s Tower BFT consensus, validators don’t simply attest “Block X is good” once. They cast votes on an ongoing basis, and each vote includes the hash of the ledger state (the bank hash) at a certain slot. More specifically, they vote using this data structure: TowerSyncInfo {vote_for_slot: u64, vote_for_hash: Hash, lockouts: u64, message: Message, signature: Vec, voter_pubkey: Pubkey} These votes have a lockout mechanism (they can’t keep voting on divergent forks without penalty), and after enough votes stacking on top of each other, a block becomes final (or “rooted”). The important nuance is that Solana validators are essentially voting on a fork choice, which corresponds to a sequence of blocks culminating in a certain state (identified by the bank hash). This is slightly different from, say, classic PBFT or Ethereum’s Casper, where votes are often thought of as endorsing a particular block height or checkpoint. In Solana, a validator’s vote message contains (slot, bank_hash) – meaning “I affirm the ledger up to this slot with this state hash.” More on Solana’s TowerBFT consensus mechanism can be found here.

Why does this matter for the ZK prover? It means the consensus proof must capture the correct pairings of slots and bank hashes that were voted on. We can’t just take any block hash; we need to keep accurate track of the entire fork tree. If our prover is tracking Solana in real-time, it must pick up these vote transactions and know which bank hash reached the supermajority threshold. In practice, once a supermajority of stake has voted on a block’s bank hash, Solana considers that block optimistically confirmed (and after some additional rounds it becomes finalized). So our proof likely targets the bank hash of a block that got 2/3+ votes. We gather those votes and verify all their signatures and weights inside the proof.

One quirk: because validators vote on the state and because of potential forks, it’s possible (though rare, under normal conditions) that not every validator voted on the exact same slot – some might vote a bit further ahead if the leader produces multiple blocks quickly. But finality implies convergence: eventually, one chain of state has the majority. Our system deals with this by focusing on the finalized bank (the “root”) and the votes that contributed to it (possibly - votes on subsequent slots).

Finality and Forks: Solana’s consensus is a safety-over-liveness design that prefers consistency after a short window. It achieves finality by leveraging the Tower BFT mechanism: validators’ votes have exponentially increasing lockouts. After enough consecutive votes on the same fork, a validator is locked out from switching forks without losing all the progress (and risking slashing if double-voting is detected). In simpler terms, if a block has, say, 32 votes deep of confirmations by a supermajority, it becomes practically impossible to revert – that block is final. This usually occurs within seconds unless the network is unstable. However, Solana does not have an explicit “finalized checkpoint” concept like Ethereum’s epochs; instead it has the notion of a rooted slot. Once a slot is rooted, it means it’s agreed to be in the longest chain and won’t be forked out.

Our ZK prover must therefore be careful to prove a finalized state, not a fork that could be orphaned. The good news is our system (named Twine prover) ties into Solana’s node software and can detect when a block becomes rooted. We only generate proofs for rooted (final) bank hashes, ensuring the proof isn’t invalidated by a later reorg. We also incorporate the “ancestor chain” in the proof: i.e. we prove that the finalized bank hash at slot N indeed descends from a known earlier root (using the parent bank hashes). This guards against any fork ambiguity.

To summarize Solana’s challenges: we had to account for a non-standard state commitment (BankHash), a non-standard voting mechanism and ensure our proof verifies the same condition the network considers for finality (supermajority of votes on a state). We also had to instrument the Solana node to get the right data (votes, stakes, hashes) at the right time, because the standard interfaces would not allow us to get the data necessary. That leads us to the engineering we did in the Solana client.

Twine’s ZK Consensus Prover

Building a ZK prover for Solana’s consensus required custom infrastructure at the Solana node level. We built our solution, Twine Consensus Prover, by extending Solana’s open-source code in two key ways:

• a custom Geyser plugin for streaming consensus-relevant data out of the node, and

• a modified Agave Solana Node that exposes low-level state info (like bank hash components and stakes) needed for cryptographic proving. Let’s break down these components:

Geyser Plugin – Capturing Real-Time Data

Solana provides a plugin interface called Geyser that allows a validator node to stream out events (accounts updates, transactions, etc.) to external consumers. We developed a Geyser plugin specifically for consensus proving. Its job is to act as a high-throughput firehose of just the data our prover needs:

• Validator Vote Observations: Whenever a validator vote transaction is observed, we capture the vote’s contents – the slot voted on, the bank hash, and the validator’s identity (public key). We log these in an efficient in-memory pipeline.

• Slot Finalization Events: The plugin keeps track of the latest slot that has achieved a supermajority of votes (optimistic confirmation) and when a slot is officially rooted/finalized by the node. When a new root is set, we know the previous root is final.

• Stake Weight Information: To verify a vote’s weight, the prover needs to know each validator’s stake. Our plugin therefore pulls in the stake distribution (e.g., from the epoch’s stake assignments or stake accounts). We might update this info at epoch boundaries or when stake changes significantly. We ensure we have a mapping of validator pubkeys to their stake weight in the current epoch.

• Block Hash and State Data: For each slot of interest (especially the root slots), we obtain the parent bank hash and any other pieces required to recompute the bank hash (like the accounts delta hash for that slot, signature count, etc.). Some of this isn’t directly exposed via normal Geyser, so our modified node assists here.

The plugin is built for throughput and low latency. Solana can produce hundreds of votes per second (each validator votes on every few slots). We implemented buffering and batch processing so that capturing these events does not bottleneck the validator. The data is fed into our proving system’s queue in real-time, so as soon as a block is final, we have everything needed to start proof generation. Essentially, the Geyser plugin is the bridge between the live Solana network and our ZK prover, siphoning off a concise trace of consensus: “these validators (with these stakes) signed this bank hash at slot N, which links from slot N-1, etc.”

Modified Agave Node – Exposing Bank Hash Internals

Agave is a performance-oriented Solana validator client (an alternative implementation developed by the Solana/Anatoly team at one point). We took an Agave-based node and modified it to better support our prover use case. Specifically, we added instrumentation to expose the components of the bank hash and other consensus-critical data (stakes, votes) through Geyser or RPC:

• The node provides the accounts_delta_hash for each slot (the Merkle root of changed accounts) and the last_blockhash (the PoH result) that get combined into the bank hash. By retrieving these, our prover can independently compute the bank hash for verification purposes. This is crucial: we don’t want to just trust the node’s bank hash blindly; we recompute it inside the ZK circuit from first principles (hashing the parent bank hash, Merkle root, etc.) to ensure consistency.

• The node exposes when a vote is included and the signature count of each block (used in the bank hash). Again, this allows our circuit to confirm that the bank hash was formed correctly (matching what validators signed).

• We extended the Geyser interface to emit a special event once a slot is rooted ( confirmed by >=2/3 stake). This acts as a trigger for our prover to take a snapshot of the votes. Essentially, “Slot N reached consensus threshold with these votes.” At that point, waiting for it to be rooted is just a safety measure; the votes are what we need to prove. There was an interface to get rooted status, but we’ve added more needed data to the event.

By modifying the node, we avoided having to do expensive computations off to the side or redo the computation that has already been made by the node. Solana’s normal validator code wasn’t built with ZK proofs in mind, so some data (like the accounts Merkle paths or the exact stake distribution at the time of a vote) might not be readily accessible. Our enhanced Agave client fills those gaps. It effectively generates a stream of “witness data” for the proof: what were the inputs that led to consensus.

In combination, the Twine Geyser plugin and modified node create an efficient pipeline from live Solana consensus to a ZK proving engine. They ensure we capture all necessary cryptographic material (signatures, pubkeys, hashes) and nothing superfluous, which keeps the proving task as small as possible. This was critical for performance: we distill a complex, high-throughput system down to a minimal set of cryptographic assertions that need to be proven.

Account Delta Proofs in Twine

Twine implements a method for generating cryptographic proofs of Solana account state using Solana’s built-in consensus commitments. Each block (slot) in Solana has an accounts_delta_hash, which is the 16-ary Merkle root of all accounts that were modified in that slot. This hash is then incorporated into the slot’s BankHash—the validator-voted commitment that includes:

1. The parent_bankhash (the commitment of the previous slot).

2. The current slot’s accounts_delta_hash.

3. The num_sigs (the count of transaction signatures in the block).

4. The blockhash (an identifier for the current slot).

By anchoring the state of modified accounts to the BankHash, Twine’s method enables anyone to verify that a particular account change was included in a validated block. The key innovation is to use Solana’s existing consensus mechanism—where validators vote on each slot’s BankHash—to create a proof that an account had a certain state at a certain slot.

Core Concepts

• Accounts Delta Hash: In every new slot, Solana produces a Merkle tree (accounts_delta_hash) from all accounts modified in that slot. This means any account that changes in a slot will have its updated state included in the Merkle tree.

BankHash: The BankHash is a critical consensus commitment. It is computed by hashing together:

hashv(&[
parent_bankhash,
accounts_delta_hash,
num_sigs,
blockhash,
])

• Each validator votes on this BankHash, making it the authoritative commitment to the slot’s state changes.

• Merkle Proofs: Because the updated accounts are part of the Merkle tree, anyone can request a proof of inclusion (a Merkle branch) showing that a specific account’s state was indeed part of the tree. Combined with evidence that the accounts_delta_hash is included in the BankHash (and that validators have voted on this BankHash), the proof ties an account state to real Solana consensus.

In Twine, we only care about proving changes to our Program Derived Accounts (PDAs). Whenever one of our PDAs is updated, it automatically becomes part of the slot’s accounts_delta_hash, and thus is included in the slot’s BankHash. We then:

1. Capture Account UpdatesTwine’s PDAs are updated through regular on-chain instructions. If a PDA changes during a slot, that update is reflected in the accounts_delta_hash.

2. Generate Merkle ProofsA Geyser plugin or similar mechanism running in a validator (or an RPC node) can generate a Merkle proof for the changed account. This proof shows that the new state of our PDA was included in the accounts_delta_hash.

3. Tie in the BankHashThat same proof includes information proving that the accounts_delta_hash is part of the slot’s BankHash. Because validators vote on the BankHash, we now have a chain of evidence that the account state was included in a fully validated block.

4. Link Through the Correct Parent BankHashWe ensure that each slot’s BankHash is correctly linked to its parent by including the correct parent_bankhash—the prior slot’s state commitment—instead of relying on any unrelated block identifiers. This preserves the security guarantees of Solana’s consensus, preventing mismatches when verifying states across consecutive slots.

By leveraging the slot-to-slot linkage provided by Solana’s BankHash, Twine avoids any need for additional on-chain “copy” programs. Since our PDAs often change naturally through Twine’s usage, they are regularly included in the delta hash anyway. This significantly reduces overhead and complexity.

Benefits

• Efficient SPV-like ProofsTwine’s system is analogous to a Simple Payment Verification (SPV) model, providing compact Merkle inclusion proofs rooted in validator-voted commitments. A user can verify an account’s state at a given slot with no need to trust an RPC provider’s claim.

• No Extra On-Chain MechanismsBecause Twine’s PDAs update frequently enough for our use cases, we do not require an on-chain “copy” program to force an account’s state into the delta hash. This approach is simpler and relies entirely on natural state changes.

• Affordable Trust-Minimized VerificationProofs can be validated by checking the Merkle branch, the BankHash commitment, and the corresponding validator attestations. This allows third-party or offline verifiers to confirm the authenticity of the account data.

• Potential for Zero-Knowledge IntegrationThe cryptographic commitments (Merkle paths and hashes) are suitable for embedding in zero-knowledge proofs (zk-SNARKs or other ZK circuits). This paves the way for advanced interchain verification scenarios, where another chain or rollup can trustlessly verify Solana states.

ZK Proving with SP1 and GKR

With the data in hand, the heavy lifting moves to the zero-knowledge prover itself. We’ve implemented two versions of provers - first on Succint’s SP1, a cutting-edge ZK virtual machine, and another one with techniques inspired by GKR (Goldwasser, Kalai, Rothblum) protocol to achieve speed and scalability.

SP1 – A General Purpose ZK VM : SP1 is a modern zero-knowledge Virtual Machine (developed by Succinct) that allows us to write normal Rust code and prove its execution in a SNARK.

SP1's power in our consensus prover lies in how it handles the three critical verification tasks: signature verification, hash chain linkage and account delta proof verification. Let's peek under the hood at how these are implemented:

We leveraged SP1 precompiles – most importantly, Ed25519 signature verification – in a convenient yet performant way. Rather than hand-crafting a circuit for Ed25519 (which is error-prone and inflexible), we wrote a Rust module to verify a batch of signatures, and ran it inside SP1’s zkVM. SP1’s prover is highly optimized for arithmetic-heavy workloads like signature verification​.

It can handle large numbers of field operations efficiently. By using SP1, we got two benefits: (a) we could reuse battle-tested cryptographic code (ensuring our Ed25519 checks are correct to the bit), and (b) we gained speed – SP1’s proving performance on signature verification is state-of-the-art.

Concretely, our ZK circuit (expressed via SP1) takes as input the CompleteProofPackage structure. This structure consist of a number of key components:

• vector of Bank Hashes and Bank Hash Components for a continuous range of slots;

• vector of Account Delta Proofs for all the changes in the monitored PDAs;

• vector of the validator votes for the last slot in chain (which should be the last slot);

• (optional) structure for collecting bank hash components and votes for slots ahead of the rooted one for the case where only votes on the future slots have led to the slot being rooted.

SP1 VM perform verification:

• of all the original vote signatures;

• account delta proofs;

• chain of bank-hashes. As the verification happens inside ZK VM, the succinct proof is being generated that could then be compressed to a compact Groth16 Proof. The proof is then provided to the special precompile on the Twine Execution Layer. If the proof is valid, the desired action can be performed on Twine. Twine execution (that also embeds the proof of verification of the Solana consensus proof) is then being generated with SP1 yet again, and that final proof is being provided to the Ethereum rollup smart contract and Solana Extension Program.

We employ the following hardware for proof data collection and  generation:

Solana Agave Fork Node and Geyser: Node + geyser spec: Dedicated (bare metal), AMD EPYC 9354 (3.25Ghz base) 32 Cores, 512 GB Ram, 2x NVME 2TB

Twine Prover: 1x NVidia H100 SXM5 80 GB 44 cores Intel Xeon Platinum 8470 (2GHz bas vCPUs), 200 GB RAM ($3.65/hr)

The current proof generation time using the SP1 protocol for a single Solana slot is 54 seconds. This duration encompasses all necessary computations and processes involved in generating a complete and verifiable proof for a given Solana slot along with the account proofs. Optimizations and advancements in the proving system and hardware acceleration could potentially reduce this timeframe in the future, leading to improved scalability and efficiency of Twine for the Solana network.

GKR – Parallelizing Consensus Proofs.

Twine’s Exploration of GKR and Multiple Consensus Proofs

SP1 was great for achieving our initial on-chain proof implementation. In our experience, it's currently the most production-ready ZKVM on the market. Yet we’re always exploring new approaches to improve performance. We noticed that much of our proving time was dominated by a single FOR loop, prompting us to seek methods for parallelizing proof computation.

This led us to Goldwasser-Kalai-Rothblum (GKR). Beyond its theoretical advantages, GKR has already been applied in practice for real-time consensus provers on Ethereum. The core insight is that instead of unrolling every operation in a single monolithic proof (often leading to quadratic complexity), GKR uses a layered approach. By performing a succinct sum-check across each layer in the circuit, it enables a more efficient verification of large computations.

In Twine’s prover, GKR techniques allow us to organize crucial operations—such as signature verifications and hash checks—into a layered computation. This approach is far more efficient than running separate proofs for each operation. For instance, validating 512 signatures independently would normally mean running the elliptic curve logic 512 times inside the circuit. With GKR, we embed those signatures into one circuit and use a sum-check to confirm correctness in bulk.

We currently maintain proofs for multiple blockchain consensus algorithms, including Solana and Ethereum. For Ethereum, we prove BLS signatures for Ethereum consensus of all the blocks attestations (up to 65535), demonstrating the chain’s finality in under 20 seconds of proof generation. Meanwhile, our proof-of-concept for Solana is already yielding promising benchmarks, with an initial target of completing the proof process in under 10 seconds.

Our approach, enhanced by GKR, has proven to significantly reduce overhead. With the GKR enhancements, we can verify hundreds of signatures and multiple hash computations in well under a minute on a single high-end machine. The one trade-off is proof size: it currently sits at about 256 MB. That said, we’re confident we can cut that down by three orders of magnitude—to roughly 256 KB—through improved polynomial commitments and other optimizations.

Moving forward, we plan to refine these GKR-based proofs further and continue shrinking proof generation time. Our goal is to bring efficient, parallelized consensus proving to production, ultimately enabling fast, trust-minimized validation of Solana, Ethereum, and beyond.

Future Work

While we now have a working Solana consensus ZK prover, there’s plenty of room for improvement and expansion. Our journey doesn’t end at this milestone – it’s just the beginning of trustless interoperability. Here are a few areas of future work we’re tackling next:

• Real-Time Proof Generation: Today’s proving pipeline, though optimized, might produce a proof on the order of minutes after a block is finalized. Our goal is to squeeze this down toward real-time or near-real-time. This involves optimizing at every layer: using GPUs or specialized hardware for the prover, refining the circuits further, and possibly leveraging proof recursion (proofs that incrementally build on previous proofs) to amortize costs. Real-time ZK proofs of consensus would allow continuous verification of Solana on other chains with minimal delay.

• Broader Blockchain Interoperability: The techniques we developed for Solana can be extended to other chains and integrated into cross-chain protocols. We plan to adapt the prover for other high-throughput chains as well as chains with a lot of liquidity that are currently under-utilized. Conversely, we want to enable Solana to verify other chains via ZK proofs, truly weaving it into the interchain ecosystem.

• Advanced Polynomial Commitment Schemes: As we push the limits of performance, we are also investigating next-generation proving systems. The GKR approach showed good results, yet we are exploring Folding-based solutions as well as different proof aggregation techniques to accommodate Twine’s expansion into more ecosystems.

• Beyond Bridging: Twine could be viewed as a programmable ZK-bridge or a multi-chain L2. With working practical full consensus proofs for Ethereum and Solana we have completed the initial vision to provide a single multi-chain execution environment. One chain to Twine them all. We are looking forward to expanding the approach to more chains - from Bitcoin to popular L2s.

If you are interested in building on Twine, please join our Devnet! Follow us on X @twinexyz to not miss any updates!