Trust Yourself - Introducing the Vea Bridge

Welcome to Vea, an interoperability protocol unifying rollups on Ethereum. Vea is the first cross-chain messaging solution for authenticated data based on a one-of-n trust assumption. Governance, oracles, attestations and even tokens, Vea complements the rollup ecosystem, increasing levels of interconnectivity.

Let's jump in.

Motivation

Kleros is a dispute resolution mechanism. Why are we developing a bridge?

One of the key roles of Kleros is resolving real world problems. Imagine you have a client, Alice, who wants to hire a web developer freelancer in Argentina. Instead of paying Bob the freelancer directly, Alice will make the payment to a smart contract that holds a payment in escrow. Kleros is an arbitration mechanism where if either party has a dispute, Kleros will resolve it.

Kleros is an arbitrator, but you can imagine any sort of oracle input being able to resolve this dispute. This is natural, given that you need to have the ability of transferring off-chain information on-chain. Now imagine that the dispute is based in not just two countries, but also on two different chains.

Current options on the market for sending messages across the Ethereum ecosystem in a trustless way are lackluster given the fact that most bridging solutions are either too slow and expensive or prone to attack vectors. For example, projects requiring on-chain governance have expensive solutions at hand on mainnet during peak chain congestion and attempting to use L2s presents interoperability challenges.

In the instance of Kleros, since the time we launched four years ago, many things changed in the Ethereum ecosystem. At the time of launch, the average transaction cost was around 1 gwei, but as the bull market, as well as the recent meme run have taught us, many applications become priced out of mainnet once volume starts picking up massively. Especially those that are designed for high volume, low value use cases, such as the above mentioned Kleros example.

The practicality of this problem is that, to take the example of our Alice, if the escrow amount is 100 DAI and the oracle that lives on another chain needs to be queried in order to establish cross-chain communication, native bridges simply take too long and are extremely costly.

How can this problem be resolved?

One idea would be to simply deploy an application on every single chain. This approach has important drawbacks, because oracles derive security from economic security. When an application is deployed across multiple networks, the liquidity is effectively split and so is the security budget.

Another solution would be to choose a home where one can concentrate economic security. As we know, home is where your node is and Kleros has chosen Ethereum mainnet and added the Gnosis Chain as an add on. Why these two? Because they're permissionless systems.

Most rollups at this moment do not function in a fully trustless manner and have another key issue, which is time efficiency. If you have any sort of oracle such as Kleros deployed on an optimistic rollup and you need a highly secure bridge, your cross-chain message is delayed for seven days with existing options. The limitation of having an application on a home chain is that this means that whenever anyone on another chain wants to use it, you need to make use of bridges.

Enter Vea.

The Vea Bridge

The Vea bridge an optimistically-verified bridge focused on cross chain apps that require sending messages (not tokens) across optimistic rollups, allowing messaging to pass through it in hours to days depending on the sending and receiving chain pairs. In the case of bridging from Arbitrum, we expect to bridge messages in about two days. How does it work?

Hint: Merkle trees are involved.

On the sending side, there is an incremental Merkle tree that maintains a compact state of all messages sent through the bridge. In this specific case, the tree has no fixed depth, the leaves are double hashed and we're using Keccak hashes. There is no ZK application here, there is no need for a fixed depth, but an incremental tree is most efficient in this case. In particular, this type of merkle tree is commonly referred to as a merkle mountain range.

The Inner Workings

We split time into epochs. You can imagine an epoch is around an hour in length. The idea is that on Arbitrum, on the sending side anyone can save the state of the bridge, the Merkle root in a storage slot, for example, in the first epoch (epoch zero) and some time later, after a delay on Ethereum, someone can make a claim right after a delay.

At this moment, we feel a safe delay is 30 hours. The reason for this assumption is that optimistic rollups don't operate synchronously with mainnet. The sequencer has some power to backdate transactions 24 hours. Because of this, you might not know the state of Arbitrum for at least 24 hours and then your node needs to sync. For this reason, 30 hours should be a safe time period for a claim delay.

30 hours later, someone makes a claim and they leave a deposit, starting the challenge period. In the happy case, after the challenge period the claim is accepted, the deposit is returned to the claimer and the state of the Merkle root is accepted. Anyone whose messages are included in that tree is able to relay their messages.

In the unhappy case, if someone challenges the claim, they are mandated to leave a deposit, enabling others to call the native bridges and resolve the dispute between the claimer and the challenger. Half of the deposit is burned, because the claimer and the challenger could be the same person, with the other half being rewarded to whichever party was honest. This is to prevent griefing attacks.

Griefing

The system is permissionless, thus there is a non-zero chance of griefing. Someone could make false claims and also challenge themselves, in which case they incur a cost, because half of their deposit will be burned and they slow down the bridge for a single epoch.

The response to this is the fact that the Merkle tree is growing in size and storing all messages that have ever been requested to be sent from Arbitrum to mainnet. What this means is that in order to delay the bridge, you need to spend a deposit or half of a deposit every epoch (when self-challenging).

One interesting parameter of the bridge is that honest parties need enough liquidity to challenge potentially malicious claims.

Vea Bridge Security Model - is it safe?

In short? Yes.

The idea is that since Proof-of-Stake and the merge, consensus is working like clockwork. Every slot time there's an opportunity for a block. The way it's working is that the Ethereum consensus has its own notion of epochs. In an epoch you have some randomly selected block proposers and those block proposers could build a block or if their hardware is malfunctioning or if they have some network issues, they might miss their opportunity to propose a block. In this case you might have a missing block.

The idea is that on-chain you can look at the difference between the block number and the timestamp to check how many blocks should there be and how many blocks are missing. Why is this relevant for challenge periods, for optimistic systems?

There are some concerns about censorship. If someone makes a malicious claim and an honest party actor wants to challenge that claim, that challenge could be censored. This could be censored by block producers. This is a type of censorship that Tornado Cash was experiencing where at some point 50% to 80% of block producers refused to include any transactions to Tornado Cash. In the case of 50% of block producers refusing to include transactions to Tornado Cash, that meant your transaction took twice as long to be accepted.

That's one type of censorship people call “weak censorship”. But, another type of censorship that the rollups are worried about and optimistic mechanism designers are worried about is "strong censorship" and that is censorship of block producers, not by block producers.

What this means is that a block producer might choose to include a transaction which will challenge an honest claim. But, there could be some network level denial of service sort of attacks, maybe eclipse attacks or other more sophisticated attacks at the network level, which will fork out a block that's been proposed.

This is very difficult to accomplish. There have been academic papers or theoretical attacks on slightly modified versions of Ethereum consensus.

Nonetheless, if you have an optimistic rollup where you have an escrow contract on mainnet that has hundreds of millions of dollars of value locked, then you have an attack vector. This sort of attack is not insignificant.

If there is censorship of block producers and there are blocks that are forked out, you are able to detect on mainnet if these blocks are missing and you can build a statistical test of whether or not you think forking censorship is happening based on risk tolerance.

Here's an example.

The equation above is a statistical equation, using the assumption that, for example, 10% of block producers will not censor a transaction. Then, we are able to build a test which says - in a two hour time period, if there are more than 34 blocks missing, then there could be a more than 1 in 1,000,000 chance that the transaction was successfully censored.

This sort of statistical analysis can give us a test customized for our risk tolerance of whether or not censorship is going on.

What you can see in the graph above is that in the first week following the merge, about 1% of blocks were missing from on Ethereum. This could be validators being offline or network issues. Two months later, four months later you have better performance and fewer blocks missing. After the Shapella fork, there are about 5% blocks missing. Actually, 24 hours after the hard fork there were 10% blocks missing, block producers missing their slots to propose blocks.

Going back to the point of a censorship test, what it allows us is to develop a criteria that says - if in a given time period there are more than 2% of blocks missing, we should slow the system down. Otherwise, we can go ahead with our two day bridging time. In practice, hard forks will usually slow down systems and as soon as block producers catch up on performance, the system will speed up again. The same thing is possible with Gnosis.

In essence, the sensitivity of our test is dependent on the network performance of block producers, so in the case of Gnosis, if there are more than 5% of blocks missing in a given time period, the system slows down.

The happy path is thus slightly modified in the way that after a challenge period passes, claims are accepted only if the censorship test passes.

Vea Features

To summarize, Vea flexes some very interesting capabilities:

• Anyone can force the correct execution. It's based on a "one-of-n" security or trust assumption that you yourself can be the honest participant in the system to force the bridge to execute properly.
• The system is permissionless. Anyone can participate, it's not closed off to a small set of validators or operators.
• The system is permanent - immutable and ungoverned. No governance parameters, no token, no rent seeking, no fees. The contracts are immutable based on these safe parameters that are set when you deploy the contract. It's a public good. Thing to note, as it's an inclusive system, delays are possible.
• The system is griefable. Attackers can spend deposits to slow down the process. The good thing about this system is that the cost of that delay grief increases linearly and one can only delay the process to a maximum of time it takes to call the native bridge (7-8 days for optimistic systems).

Cost Effectiveness

Vea Bridge is to be used to send messages between rollups and different chains.

Using Vea rather than the native bridges is much cheaper, given the fact that you don't pay mainnet gas in the happy path, given that you avoid it altogether. If there is a challenge, it's very clear who's paying mainnet gas, because the losing party will compensate the winning side.

To refer to the image above:

• Between Arbitrum and Optimism, it's both cheaper and faster than going through mainnet. In the happy path, it executes in two days.
• Bridging between an optimistic rollup to mainnet, Vea is a faster option, but not necessarily cheaper than going through mainnet.
• Going from optimistic rollups to Gnosis, the cost is significantly lower, as well as faster, since there's more block space on Gnosis. Reversely, bridging from Gnosis to some optimistic rollup, you save on transaction fees, but the system is not necessarily faster.

In the happy path, gas is paid on the destination chain and never on intermediary chains or Ethereum L1. If you're bridging from Ethereum, there is little benefit and you are encouraged to use the native bridges, since there is no benefit in cost nor speed. Vea is designed primarily as a bridge between optimistic rollups or for sending messages to and from optimistic rollups.

Just Use Vea

Vea is a new Ethereum primitive, a tool directed at developers who want to bolster their cross-chain stack, empower their projects and explore novel cross-chain use cases.

Would you like to move your on-chain governance to an L2 while retaining the security of Ethereum mainnet? Vea enables you to have cheaper voting while maintaining economic security. Any kind of message or attestation that needs to move across L2s and from an L2 to mainnet is faster, cheaper and more secure than using any other canonical bridge.

Vea opens a plethora of potential use cases as well, from bridging from an L3 like Arbitrum Orbit to mainnet to P2P exchanges between L2s, the options are there and we would love to chat if you are building a cross-chain project and would like to use Vea as your solution.

If you're a protocol needing a cross-chain solution, you should consider Vea, which allows you to pass messages across optimistic rollups essentially for free. Concentrate your economic security on a single chain and simply do message passing, outputs of the oracle that you can participate in as a watcher or a validator.

Vea enables you to be your own security for the bridge. If you're building a cross-chain application, Vea also enables you to build liquidity networks on top or cross-chain governance.

May the Bridging Begin

The current roadmap for Vea is that we'll be rolling out a testing environment for developers on Göerli and Chiado, with a testnet for participating validators coming soon and finally, a mainnet launch between Arbitrum and Gnosis, as well as Arbitrum and Ethereum mainnet. Veascan, Vea's native explorer is out, as well, giving you the ability to track transactions going over it, as well as claims being made.

The system works with even one trust assumption. Kleros is the first user of Vea and will be one of the bridge operators running a watcher checking for fraud and making claims about the state of the Merkle root.

You can already test out the Vea Lightbulb Demo here, where the switch 'lives' on Arbitrum Göerli and the bulb 'lives' on Gnosis Göerli or Chiado. Try it out for yourself and get acquainted with the technical documentation in our GitBook.

Get in touch with us via Telegram or Twitter to learn more, we'll be glad to indulge all your Vea needs.