Synapse is a generalized cross-chain communications protocol that seamlessly connects decentralized applications across all chains. The project started as Nerve, a simple AMM on BINANCE Chain that enabled users to move assets between Ethereum and Binance Smart Chain but in 2021, the project transitioned to Synapse with loftier interoperability goals in mind.
The Synapse Protocol comprises a messaging architecture and a robust token design for achieving consensus regarding the validity of inter-chain transactions. It presents an expandable set of smart contracts that can be implemented on any blockchain, allowing developers to create native cross-chain applications.
As a base layer protocol, Synapse consists of three main components: Generalized Cross-chain Communication, an Optimistic Security Model, and the Synapse Bridge. Currently, the Synapse Bridge is the primary product, utilizing the Synapse network and cross-chain AMM. However, the team has plans for a Synapse v2, as well as a future Synapse PoS Chain enabling developers to build truly cross-chain applications, including cross-chain DEXs, lending platforms, yield aggregators, and more. However, the primary bridge still currently runs on an MPC with a few signers.
Future Synapse Chain
Synapse V2, announced in Q2 2022 and still no date set for the actual launch, is planned to feature generalized cross-chain messaging secured by optimistic verification similar to rollups like or the bridging solution Nomad. Using Synapse's generic messaging system, arbitrary data can be transmitted between previously siloed blockchains, creating a better user experience for users and an improved development landscape for developers and dapp integrations. Generic message forwarding includes calls to smart contracts, allowing smart contracts on various chains to interoperate effortlessly.
Generalized Cross-chain Messaging
In the new V2 system:
- A user initiates a transaction from the source chain
- Synapse receives a message and inserts it (actually, a Merkle root) into a transaction
- A Synapse notary attests to it
- A relayer sends the signed attestation to the destination chain
- Guards ensure there is no fraud during the challenge window
- Once the window is closed and no fraud is detected, the transaction is considered final and gets executed on the destination chain
Synapse Chain’s generalized messaging system allows for secure and seamless transmission of any type of data across chains. Applications no longer need to be deployed independently on multiple blockchains; instead, they can be deployed on a single chain and communicate with other chains. The generic message passing also encompasses smart contract calls, making it easier for smart contracts on different chains to work together. This has huge implications for developer and user experience as it provides a universal composability framework for blockchains. One perfect example is that, under this new design, users would be able to manage liquidity positions on various chains instead of having to constantly switch back and forth between blockchain networks. The hosting of cross-chain business logic on a single execution environment enhances efficiency, allowing for atomic interaction with state across diverse blockchains.
An essential aspect of the Synapse Chain is its utilization for the storage of attestations. In other messaging systems, the number of contracts requiring updates increases with the number of connected chains. With the Synapse Chain, only one chain needs to be updated with each valid cross-chain transaction, thereby reducing smart contract complexity and gas costs. All historical attestations of the system's cross-chain transactions are made available via Ethereum as the Synapse Chain settles back to Ethereum.
Optimistic Verification
The decision to construct the Synapse Chain as an Optimistic Rollup is based on four primary considerations: EVM compatibility, security, user experience, and simplicity. The Synapse Chain leverages the Ethereum Virtual Machine (EVM) to guarantee compatibility with the rich Ethereum developer and application ecosystem, providing a familiar developer experience.
In general, there are two types of bridges: trusted and trust-minimized. Trusted bridges depend on a counterparty consensus, usually an external validator set, while a single complete node can secure trust-minimized bridges.
Chains require two things to construct trust-minimized bridges: the same data availability (DA) guarantees and a mechanism to read each other's fraud or validity proofs. Because L1s don't meet the previous requirement of shared DA, they can't create trust-minimized bridges with each other. They rely on each other's agreement to communicate, significantly reducing security.
In contrast, rollups connect with Ethereum in a manner that minimizes the need for trust. They are “trust-minimized” because the smart contract on the L1 acts as a light client receiving block headers and validating by fraud/validity proofs. Ethereum has access to a rollup's data and conducts its on-chain fraud and validity proofs. This access and proof process are why rollups can have as little as one node but still maintain the same trust assumptions as the Ethereum base layer.
Rollups don't require validators; instead, a set of sequencers to produce blocks. The base layer provides the secure validator set, circumventing the security bootstrapping problem.
Additionally, rollups that share a settlement layer can build trust-minimized bridges between them because their state transitions can be easily verified through the settlement layer via full nodes.
As far as security, optimistically verified bridges fall between native and external implementations. They work much like Optimistic rollups in that they assume transactions are valid by default and then open a challenge period whereby monitors can contest the transactions if they believe fraud has occurred or it's invalid. If the challenge is successful, the transaction is reverted. They are secure as long as at least one honest validator manages to raise the alarm within the fraud-proof window versus externally verified bridges (original Synapse design) that requires an honest majority of validators.
Synapse's optimistic verification mechanism is secured by four off-chain actors:
- The Notary, who signs the Merkle root for each supported chain and holds SYN through attestations
- The Broadcaster (sequencer), who transmits updates from home contracts to replica contracts
- The Guard, who monitors cross-chain messages and provides fraud proofs if malicious state updates are detected
- The Executor, who executes the final transaction after the latency period is finished.
In terms of its architecture, all Synapse Chain blocks will be stored within a smart contract on the Ethereum blockchain, and block production will be managed by a solitary sequencer. The sequencer, responsible for state updates and transaction submissions back to Ethereum, will follow the decentralization roadmap of leading rollup protocols. At launch, gas will be paid to the sequencer in ETH but SYN could be implemented down the line.
One area in which optimistically verified bridges shine is in the event of a hack. In externally verified hacks, where the private keys of a majority of validators are compromised (ex: Ronin bridge hack), the attacker can remove all of the funds from the bridge and abscond. However, in an optimistically verified system, even if the attacker manages to get the private keys of all the validators, they still can't be guaranteed to get away with all funds as long as one honest watcher in the system identifies the fraud. If that happens, they can revoke the attacker's access to the funds. The tradeoff to this approach is the long challenge period, i.e., slow time to finality.
Upon the launch of the Synapse PoS Chain, Synapse will be able to replace AMM pools on each chain with liquidity on the Synapse chain, resulting in increased capital efficiency and a considerable reduction in SYN emissions.
However, there is no defined timeline for that reality. Until then, Synapse remains a simple bridge with simple trust assumptions.
