Succinct Labs AMA

Succinct Labs’ mission is to build a decentralized permissionless and open-source interoperability layer for Ethereum and other platforms. Their focus is on providing a better trust-minimized bridge architecture based on their novel proof of consensus via zk-SNARKs. The bridge security is based on the verification of consensus by light clients of a source chain, and the execution layer of a target chain. Succinct uses the Sync Committee which is a random subset of 512 Ethereum validators that rotates every 27 hours. This offers slightly less security but is good enough for a light client to verify the consensus of the chain.

Uma Roy, Co-founder and CEO of Succinct Labs, joined us for an AMA on April 18th.

vVv: With frequent bridge hacks resulting in losses amounting to hundreds of millions, would you agree that cross-chain interactions are the weakest link in Web 3?

Uma: Absolutely. High-profile hacks like the $600 million Ronin hack or the Wormhole, Nomad, and Harmony incidents highlight the vulnerabilities in cross-chain bridging. It’s indeed one of the most pressing issues in this space.

vVv: Succinct Labs is addressing these cross-chain interoperability problems. Can you briefly describe your background and what inspired you to initiate this project?

Uma: My interest in zk- SNARK, a math-heavy concept, led me to this field. I began to explore and experiment with its applications. The idea for Succinct Labs was born when the Gnosis chain wanted a trustless bridge between Ethereum and themselves. We demonstrated that a gas-efficient light client for Ethereum using zk- SNARKs was feasible, which led us to expand this concept for all chains, hence the birth of Succinct Labs.

vVv: To better understand the benefits of Succinct Labs’ solution, could you outline the issues with existing bridges?

Uma: The primary problem with current bridges stems from their reliance on centralized entities. These entities often consist of a multisig – a group of people who monitor and manage asset transfers between chains. A user locks up assets on one chain, and the multisig watches for these deposits, minting wrapped versions of the tokens on the destination chain. The system is flawed in several ways. Firstly, it’s not censorship-resistant; the multisig can arbitrarily decide not to mint equivalent assets on the other side. Secondly, it’s not permissionless – the multisig controls who can join their group. Lastly, it lacks security. If the multisig keys are compromised, the attacker can effectively drain all assets from the deposit contract. Despite these glaring issues, such bridges are prevalent due to their operational simplicity.

vVv: Considering the inconsistencies of existing bridges with the principle of decentralization, I am keen to learn more about your solution. Can you provide a high-level overview of your protocol, Telepathy?

Uma: Telepathy is based on the concept of “light client bridging”. In essence, it’s a method for two blockchains to communicate by verifying each other’s consensus. For example, if we’re bridging from Ethereum to Polygon, Polygon verifies that Ethereum has reached consensus on a specific state, such as a user making a deposit into a contract. Once Polygon verifies this, it can take corresponding actions on its side. This model of bridging is popular because it’s trustless – it depends on the verification of the consensus of one chain by another, not a centralized entity. However, there is a challenge. Running a light client on-chain, which is necessary for this kind of bridging, is computationally expensive. It requires verification of different signature schemes, and accurate validators, among other things. This is where zk-SNARKs come in. Zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a cryptographic proof that allows for the verification of a large amount of computation in a very short amount of time. Projects like Polygon, zkSync, StarkWare, and others use zk-SNARKs to scale execution. We apply the same principle to scale consensus verification. In our system, the computation required for verifying a light client is packaged into a zk-SNARK proof. Verifying this proof on-chain is relatively cheap, allowing us to run light clients efficiently on-chain and enable trustless bridging.

vVv: Let’s delve deeper into the technicalities. Can you outline the architecture of Telepathy and the different components required to establish such a solution?

Uma: The architecture of Telepathy consists of several key components. Let’s take the example of bridging from Ethereum to Polygon. On Polygon, there is an Ethereum light client smart contract. This contract gets updated with zk-SNARK proofs, which it verifies and uses to keep track of Ethereum’s state. Another contract acts as the messaging layer, facilitating the sending of messages from Ethereum. When a message is to be executed on Polygon, it calls the light client smart contract, which verifies – using the light client’s block headers – that the transaction or action did indeed occur on Ethereum. After verification, it executes the message. This method enables arbitrary message passing, a critical prerequisite for bridging. To perform bridging, a bridge contract sends a message to the other side to mint a wrapped version of an asset, for example. One of the unique features of our system is its permissionless nature. Anyone can generate a proof and submit an update to the light client, and anyone can relay their message. This is unlike existing bridges, where certain multisig members need to sign off. Our verification is based on cryptographic proof that the actions occurred on the other chain, eliminating the need for centralized control.

Telepathy, our current product, is a messaging system that facilitates sending messages from Ethereum to any other chain. It includes a smart contract that functions as an Ethereum light client. This system allows messages sent from Ethereum to be executed on the other chain’s smart contract, with the Ethereum light client verifying the process.

vVv: So you always run a light client on the target chain, and which chains are currently supported?

Uma: Yes, currently we support Gnosis, Polygon, Avalanche, Binance Smart Chain, Optimism and Arbitrum. It’s really easy to deploy this system to any new EVM chain as well.

vVv: Is it complicated to add additional chains, specifically non-EVM compatible chains, to the system you’ve discussed?

Uma: Adding non-EVM chains to the system isn’t overly complicated. The main task is writing a smart contract capable of verifying proofs and managing the light client. This can be somewhat challenging, but once completed, the contract can be reused for other chains. We haven’t prioritized this task yet, but it’s feasible.

vVv: Can you explain the process, from the perspective of an end user who wants to interact with a dApp, until the message is transmitted to another chain?

Uma: Sure, imagine a user interacting with a dApp that’s partially running on Ethereum and partially on a more cost-effective chain, like Gnosis chain. For instance, a game could have its logic on Gnosis but use Ethereum for NFTs. If a user acquires an NFT, they might unlock a feature on the Gnosis part of the game. The system would first check the user’s NFT ownership on Ethereum, then send a message through Telepathy to the Gnosis chain, which would unlock the game feature. This way, the more costly elements remain on Ethereum, while the more computationally heavy parts can run on a cheaper chain, with our system facilitating communication between the two.

vVv: Can you elaborate on the roles of the off-chain actors, operators, and relayers in this system? Who manages this infrastructure?

Uma: The operator in our system is responsible for generating proofs and updating the light clients. Currently, we manage the operator role, but it’s a permissionless position that anyone capable of generating these proofs could fill. The relayer, on the other hand, watches one chain for messages and relays them to the other side. We keep these two roles separate for clarity, despite their similar functions as off-chain actors updating contracts. The operator focuses on the light client, while the relayer is more concerned with the messaging layer.

vVv: So everyone can run operators and relayers in the future?

Uma: Yes, as of right now the code is not open-source yet but the smart contracts are all permissionless so anyone can submit these updates, as long as you submit the correct transaction information because it’s all verified with these Merkle proofs or with zk-SNARKS.

vVv: What are the incentives to run an operator or relayer?

Uma: At the moment, we manage the infrastructure for operators and relayers to support our customers who pay us to run these systems on their behalf. However, in the future, we’re considering implementing a fee and gas system, where users pay a fee and a decentralized group of relayers or operators receive payments for submitting updates.

vVv: What is the economic model for the protocol? Will users pay a fee for each transaction?

Uma: We’re still working on the best fee structure, but we envision that users will pay a fee for sending messages through the system. The goal is to create a model that’s easy for developers to work with.

vVv: Will end users recognize telepathy, or is it more of a background infrastructure connecting chains?

Uma: Currently, Telepathy is primarily developer-focused, providing infrastructure for creating multi-chain dApps. It’s not so much about end users sending messages, but rather about developers using Telepathy to enable seamless interactions between chains for their dApps.

vVv: How do you plan to attract new developers to build on top of your protocol? Do you have any concepts in place for collaboration?

Uma: We already have some early partners, like Gnosis and Across protocol, who are attracted by the security benefits that our system provides. Developers can already use our system, which is live on mainnet for multiple chains, by referring to our documentation and seeking support through our Discord or early partner program. We’re excited to help developers get onboarded and start using our protocol.

vVv: Do you have any established partnerships with projects that the developer community can leverage?

Uma: Yes, we do have established partnerships with projects. Gnosis is one of them. They have a chain with the same architecture as Ethereum, which makes it convenient for developers to deploy and test their dApps in a lower-stakes environment before going to the mainnet. We often use Gnosis as our testnet due to its cost-effectiveness and wide range of ecosystems and apps. We’re working with Gnosis to enhance the security of their native bridge, which is currently a multisig bridge.

Another partner we are working with is Across Protocol, a liquidity layer that has conducted over a billion dollars in volume. As part of their operations, they need to pass messages between chains, and we are helping them facilitate this between Ethereum and other chains like Avalanche and Binance Smart Chain.

We also have several other developers using our system for a variety of use cases. One example is governance, where the results from Ethereum Layer-1 need to be transmitted to different chains. Another is Chainlink Oracles on L1 that need to reflect information on other chains. Additionally, registries like ENS or Worldcoin can use our messaging layer to ensure their registries are reflected across different chains.

vVv: What is your future vision for Succinct, in the next three to five years? Where will you be at that time?

Uma: Crypto is a rapidly evolving space, making long-term predictions challenging. However, in the short term, we aim to eliminate the need for multisig bridges, which we believe have many issues. We want to continue developing ZK light clients for other chains, connecting them all through Succinct light clients powered by zk-SNARKS. Our long-term vision is to secure all messages, value, and data movement across all chains through proof of consensus rather than multisig. This is a significant undertaking given the number of different chains and consensus systems, but it’s a vision we’re actively working towards.

vVv: It’s impressive to see such modesty in the face of this potentially groundbreaking endeavor. If this project comes to fruition, it will indeed be monumental, possibly solving a billion-dollar problem in the Web 3 space. It’s clear that we need such solutions to build trust in decentralized applications. The mainstream media often amplifies news of substantial hacks or vulnerability exploits, which can undermine confidence. So, a solution like this could be a crucial element in fostering interest and trust in Web 3, and from the Web 2 space.

Uma: Absolutely, bridge hacks have a twofold negative impact. Not only are they devastating for the direct victims, but they also tarnish the reputation of the entire crypto space. Seeing such headlines, which in my view are largely avoidable, creates a negative perception. It’s clear that the current approach to bridging is inadequate and requires improvement.

vVv: Understood. So, you’ve expressed that you aim to replace traditional bridges. Is there a reason to maintain these legacy bridging systems? Do they cater to a specific use case or provide a benefit that would justify their survival?

Uma: One argument often made by proponents of multisig bridges is that they offer speed and cost benefits. While this may be true in the short term, the landscape of zero-knowledge (ZK) technology is rapidly evolving and making significant progress daily. In the long run, I don’t see a particular reason to retain them. We can establish layers such as liquidity layers or optimistic rollups, which operate faster and are ultimately settled by ZK. For instance, if we look at various liquidity layers, such as Hydro Protocol, Connext, or Across, they operate by providing an optimistic fill, which is later settled in the ZK layer. Therefore, I believe these zk-SNARK-powered proof-of-consensus messages will serve as the settlement layer, and on top of that, we can implement faster solutions for a better user experience. However, in the short term, until we establish this ZK settlement layer, we may still need to resort to multisig methods for some unavailable directions. Ultimately, if technology continues to progress at its current rate, I don’t anticipate a need for multisig in the future.

vVv: Earlier, you mentioned proof of consensus. Could you elaborate on this concept?

Uma: Yeah, so what we call our zk-SNARK proofs that power the light client, is a Succinct proof of consensus that the validators have come to agree to a certain state of the world. We call it proof of consensus for short. We think it’s kind of a nice name to describe this concept, as opposed to zk-SNARK-powered light clients, which is kind of a mouthful. It’s just like, proof of consensus secured bridging is kind of our terminology for it.

vVv: How does the protocol handle upgrades? Is a governance process required, or does the team control access keys and dictate upgrades?

Uma: That’s an excellent question. Just like rollups in the Ethereum ecosystem need to upgrade when the underlying execution upgrades—for example, if the EVM adds a precompile or changes the way it computes the state root—we too, must upgrade when there are changes in the consensus layer. Recently, for instance, the Shapella upgrade (Shanghai on the execution layer and Capella on the consensus layer) required us to update our messaging layer due to changes in the structure of the Merkle proofs. Our current upgrade procedure involves a seven-day timelock pathway. We initiate an upgrade, and after seven days, the timelock executes. At the moment, the upgrade mechanism is a multisig on each chain controlled by our team. However, we envision transitioning to a decentralized governance mechanism for conducting these upgrades in the future—similar to how optimistic rollups either currently have, or plan to establish decentralized governance for upgrading their rollup logic.

vVv: Could you tell me how many transactions are included per batch on the Ethereum side, and how long it takes to generate the proof?

Uma: The proof generation time is actually quite short—typically between one to two minutes. Ethereum’s consensus protocol has a concept of finality where a block is considered finalized after two epochs. Since an epoch is about six minutes, it generally takes around 12 minutes for a block to be finalized. On the destination chain, we update once every epoch, effectively showing the most recent Ethereum state on that chain per epoch. For chains that are more expensive, we update less frequently. The number of messages sent in that epoch determines the size of the batch, but we don’t have a specific number—it’s merely a function of the messages sent during that epoch which are then verified against that update in the light client.

vVv: On average, what are the costs associated with transferring a message?

Uma: To verify a message, it costs around 200,000 gas on the destination chain to verify all the Merkle proofs and so forth. To update the light client, it costs approximately 300,000 gas. This happens once every six minutes but can also be less frequent if there are fewer messages.

vVv: Will you be implementing recursive proofs from the start?

Uma: That’s a great question. Recursion is an advanced ZK technique that allows one ZK proof to be verified within another proof. It’s powerful because it allows you to aggregate an arbitrary amount of computation into one proof. For example, if I have a proof of consensus for one chain and a proof of consensus for another chain, I can combine them into one “mega-proof” for the same verification cost on Ethereum. We’re actively working on implementing recursion for our new proof-of-consensus mechanisms. While it’s a somewhat newer technology in the ZK field and we’ve avoided it in our current protocol to prioritize security and dependability, we definitely plan on using recursion for our future developments.

vVv: There are numerous other interoperability solutions on the market, such as Layer Zero, Axelar, or Cosmos IBC, which you mentioned earlier. Can you elaborate on the advantages of Telepathy over these other solutions?

Uma: Absolutely. IBC is quite similar to what we’re aiming for, but it needs to be integrated into your chain. While all Cosmos chains come with IBC, Ethereum, for instance, does not implement the IBC spec. Our goal is to create an IBC-like light client bridging system that doesn’t require integration into the chain. So, compared to IBC, we share similar principles, but our approach is more Ethereum-centric and can be adopted by any ecosystem, which is a major advantage.

  Layer Zero protocol, on the other hand, essentially operates like a multisig backed by a Chainlink Oracle, making it a highly centralized solution. You need permissioned Oracle updaters and relayers to maintain its security, so it doesn’t offer the same security properties and trade-offs that users typically seek.

  Axelar’s model is more intriguing. They have an intermediary chain that takes on the responsibility of signing, replacing the multisig with a dynamic network of validators. However, if you use Axelar, you’re depending on the economic security of their intermediary chain, which makes it an economic security argument. For instance, if you’re bridging between Ethereum and Polygon through Axelar, your security is only as strong as the weakest link—in this case, Axelar.

  The ZK approach, in contrast, allows the chains to interact directly, caring only about their own security and nothing else. This method excludes any intermediary, making it the most direct, native, and trust-minimizing way to implement bridging. While Axelar’s design is a definite improvement over the traditional multisig model and likely more secure, it still requires a chain in the middle. The ZK approach, on the other hand, facilitates direct interaction between the chains involved, each verifying the other’s proofs, without the need for an intermediary. This makes it the most direct and native way to bridge, involving the least additional trust assumptions. So, in my view, although there are other notable solutions in the market, the ZK approach we’re taking with Telepathy offers superior security and flexibility.

vVv: Who would you say is your closest competitor in the market currently?

Uma: That’s a nuanced question as it depends on how we define competitors. There are entities who aim to achieve the same end result, which is to send messages, but they may not offer the same security properties that we do. Other companies are also attempting to implement the concept of ZK bridging, similar to what we are doing. These are generally newer, smaller startups. Overall, there isn’t an existing player in the space that offers the exact security properties that we do, given the complexity involved in executing the ZK step.

vVv: Do you anticipate a “winner-takes-all” scenario in this technology sector, similar to how Chainlink has become the major player for Oracles due to the high risk involved?

Uma: While we certainly hope that users will prefer our solution and that we become a primary choice, the unique aspect of our ZK approach is that even if we become dominant, our system remains a true protocol – it is entirely permissionless. Anyone can generate updates or relay messages. Unlike systems like Chainlink which relies on a trusted network of node operators, our protocol can’t censor because anyone can generate proofs based on public inputs, which are the outputs of consensus. So, even if we become the dominant solution, users always have the option to operate within the system as it’s not exclusively us, which I believe is a desirable property of ZK-based systems.

vVv: Shifting to the topic of censorship, it’s understood that real censorship or data modification isn’t possible. But how can we ensure that Relayers won’t delay or withhold certain messages?

Uma: The open nature of our protocol means that anyone can relay the messages. If a user wishes to run their own Relayer to ensure timely delivery of their messages, they absolutely can. If they prefer someone else to run the Relayer for them, they would have to provide some form of incentive, perhaps payment. The key point is, if you want to control the latency, you have the option to run your own Relayer.

vVv: Will you be introducing your own token or will there be a fee cut from the base assets being transferred?

Uma: We have not yet fully decided on the exact fee mechanism or how it’s going to operate. This is certainly an important aspect for us to consider and plan for the future, but as of now, we’re still in the process of shaping that aspect of our project.

vVv: Could you share more about your current development progress and your roadmap going forward?

Uma: We have already launched on the Mainnet and are gradually onboarding more developers to use our product. We believe there are a lot of interesting use cases beyond just token bridging, such as governance, on-chain games, and reading Ethereum state on other chains. Our short-term roadmap involves encouraging and supporting developers to explore these areas with our product. Simultaneously, we are also working hard on implementing proof of consensus for other chains to start bridging information back into Ethereum and creating more connections.

vVv: How large is your team at the moment and are you currently hiring?

Uma: Our team is currently fairly small, consisting of about 10 people. While we are always open to adding talented individuals to our team, we’re not actively seeking to significantly expand in the short term. Our focus is on working efficiently to develop and deliver our product.

vVv: Absolutely. A balanced team does enhance efficiency and creates a more dynamic atmosphere. Speaking of which, how can our audience follow your project and engage with your community?

Uma: There are several ways to stay updated with our project. The easiest would be to follow us on Twitter at @SuccinctLabs, where we post all our updates and developments. You can also check out our documentation and demo. If you’re a developer and are interested in using our technology, we encourage you to sign up as an early partner for additional support and guidance. We also have a Discord community that you can join for more interactive discussions.

LISTEN TO THE SPOTIFY RECORDING BELOW FOR THE FULL SUCCINCT LABS AMA