Over the last 12 months, we’ve seen an explosion in BTC bridging infra. What was once a 3-hour WBTC minting window with a 1% fee has evolved into near-instant cross-chain swaps and sub-10 bps spreads.

We broke down 10 top BTC bridges by two of your favourite metrics: Speed & Fees. Here’s how they stack up.

1. Optimex

Speed: ~10–15 minutes (1 BTC confirmation)
Fees: 1%

Pros:
No AMM slippage
Custody-less swaps

Cons:
RFQ model depends on active makers
Limited destination assets

2. Bitcoin Bridge (by PermuteFi)

Speed: ~ 10–20 mins (1 BTC confirmation)
Fees: ~0.1%

Pros:
BTC-native bridge
Lowest cost bridging
Very deep liquidity bridge

Cons:
Still in closed beta

3. Garden Finance

Speed: ~5–10 mins
Fees: 0.3%

Pros:
Fastest non-custodial bridge
No wrapping

Cons:
Still gaining awareness among retail users
Low liquidity (can’t swap more than 5 BTC)

4. Relay

Speed: 20 mins(1 BTC confirmation or less)
Fees: ~ 0.2% + Network Cost

Pros:
Extremely fast routing
Broadest chain support

Cons:
Relies on wrapped assets (e.g., WBTC)

5. ThorSwap

Speed: ~30–40 minutes
Fees: ~0.9% total (AMM model)

Pros:
Native asset swaps (no wrapping)
Proven decentralization (THORChain security)

Cons:
Slower than newer bridges
Higher slippage for large swaps
Have been compromised in the past

6. deBridge

Speed: Under 1 minute (for wrapped assets)
Fees: ~0.05%–0.1% average; highly optimized

Pros:
Smart routing via makers
Extremely low latency across chains

Cons:
BTC mints not instant on-chain
Also relies on wrapped assets

7. Across

Speed: 3 minutes
Fees: 0.05%

Pros:
Fast bridging

Cons:
Very limited token pairs
Can’t bridge native BTC

8. Avalanche BTC.b

Speed: ~1–2 hours (multiple confirmations + SGX process)
Fees: $3 to bridge in, $20 to bridge out (flat) + Bitcoin transaction fee (<$2)

Pros:
Deep liquidity on Avalanche
No % fees, good for whales

Cons:
Fixed fees harsh on small user
Doesn’t directly connect to Ethereum

9. Threshold tBTC

Speed: 10 min (optimistic mint); ~3–4 hours for full finality
Fees: Mint fee is 0% & Redemption fee is 0.2%

Pros:
Fully decentralized bridge
Native ERC-20 tBTC with strong integrations

Cons:
Slower redemptions (~6–12 hrs)
Slightly complex UX
Have been compromised in the past

10. Chainflip

Speed: ~10–30 minutes (BTC swaps)
Fees: ~0.2% (plus 0.05% for Boost)

Pros:
Seamless cross-chain AMM
Deep liquidity and market-maker support

Cons:
Boost swaps cost extra
Protocol still ramping up integrations

TL;DR Table

More bridges, lower latency, better fees.

Bitcoin is finally becoming multichain.

Resources

• Garden Docs
• Optimex docs
• Relay Bridge
• THORChain GitHub
• deBridge Protocol
• Across docs
• Avalanche BTC.b
• Threshold tBTC
• Chainflip Docs

It is often incorrectly assumed by builders that aggregation layers are a trade-off between reducing your gas cost in return for increasing your latency. That’s not true.

In fact, aggregation layers decrease both your latency and your gas cost. How? This is because the cost of verifying a proof is so high right now that projects can afford to send their proofs only after very long intervals ~ once every 3–4 hours. Using aggregation, we will reduce the cost of verifying proofs by so much, that you will be able to send your proofs to Ethereum in quick intervals.

Over time, as the cost per proof keeps getting lower, the projects will send proofs with higher and higher frequency.

So in the long term, what is the lower limit of proof submission interval that customers can demand?

Ans → 15s i.e. the Ethereum Blocktime. This is because you can add your proofs on Ethereum only as quickly as blocks are added to the chain.

This means that aggregation layers must generate their proofs in ~1s so that the projects’ proofs get added in the same block they would have been added in w/o aggregation latency. Note that projects must generate their own proofs as well within this 15s window, which means there would not be much time left for aggregation latency. This scenario will obviously play out over a long period of time.

Busting Myths: Aggregation Increases latency was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was in my final year at IIT Delhi, totally lost. There was this thesis I was supposed to write on the work I was doing in the biotech lab. However, it was impossible for me to find the motivation to do that work, and I had kind of given up on completing my degree as a result.

However, one day, my lab supervisor told me that the work I was doing was commercially relevant, and if I created the tech we were trying to develop, we could get paid millions per year in licensing fees from biotech companies.

And suddenly, the motivation I was missing was found. II went after this idea with everything I had.

Our idea was → Cutting down the analysis time for “Peptide Mass Fingerprinting”, by finding a way to use single-pass mass spectrometry to generate results with similar accuracy as tandom mass spectrometry.

After a couple of months, our work hit a dead-end, and the most we could do was publish a paper for it.

However the seed was sown. I now knew what I needed to do.

I told myself — “I just need to find a cutting-edge technology, make it commerically meaningful, and I can change the world.”

This was July 2017.

The Darkest 14 days of my Life

At this point i graduated, and I was supposed to join this analytics company in Mumbai. But I really wanted to startup right away. However, so far in my life, I had developed this habit of starting projects, abandoning them, and then regretting later. And I was really scared to repeat it. So I thought, “let’s me at least join the company and do something useful for them, before jumping into the startup blackhole.” Besides, the company was in Mumbai, where I wanted to go for starting-up anyways….

So I joined.

Up until this point in my life, I had thoughts in my head regarding technology, science and changing the world, but I could never find anyone to discuss them with. Joining this company was kind of my last hope of finding like minded people, and upon meeting people in the company, that was shattered too.

I was really desperate to discuss those thoughts with someone, and I could not find anyone. So I turned towards internet, trying to type out my thoughts on google and maybe something shows up? After 10 mins of search, I came across this random book by a guy I had never heard of → Peter Thiel, and I just thought I would give it a read. I found an online pdf version and start reading….

After reading the first paragraph, I was like — “Holy shit! This guy is talking about everything that’s in my head!” It took me 2 hours to process this, after which I began reading more…

Upon reaching the end of the page, I was barely able to breath, and i sort of froze up, and i could not hear anything anymore…

I still very vividly remember the exact place I was sitting on. It was in the middle of a training session by the company.

I managed to read till the first paragraph on the second page, after which it was very clear to me → “I either resign and startup right now, or I don’t think about starting up ever again.” I was worried that I might get insitituionzed if I spend too much time in that office….

After this, I snuck out of the office somehow, and started calling up everyone I knew → friends, dad and relatives. Everyone said the same thing — “Are you crazy?”.

In the evening I ended up meeting with a friend at Marine drive, a very famous road in Mumbai along the sealine. It was evening, high tide, and the sea was hitting the seawall quite aggresively, upon which we were sitting.

I told my friend → “I wanna startup”. He was like — “Yeah, obviously. I didn’t really understand why you joined a company in the first place. You are a startup kind of guy…”

I resigned the very next day.

After resigning, i was in the office for a couple of hours, and everyone told me the exact same thing — “congratulations”. I could not understand why they all said so, so I asked, and they told me — “everyone wants to startup, but you are actually doing it.” Lol, then I knew I had taken the right decision.

As such, we have developed a library that enables creating a zk-snark proof of a batch of Ed25519 signatures. The code can be found here. Our circuits are built using Circom and we use Rapidsnark for proof generation.

Let's dive into how it works.

To implement the Ed25519 signature verification in a zk-circuits, we do the following 3 steps —

1. Define the finite field used by Ed25519 inside the SNARK finite field
2. Defining basic operations such as addition, multiplication, and modulo for the Ed25519 finite field inside the zk-circuit
3. Defining the twisted Edwards curve inside the SNARK finite field

1. Defining Ed25519 Finite Field Inside SNARK Finite Field

The Problem Statement

Verification of SNARKs can be particularly expensive in on-chain execution environments. For cheaper and efficient verification, Ethereum includes precompiles introduced in EIP 196 and EIP 197, which support curve operations and optimal ate pairing check for the elliptic curve alt_bn128. This means we should also use the alt_bn128 curve for generating our proofs if we want efficient proof verification on-chain.

The alt_bn128 curve is defined under a finite field modulo the prime p = 21888242871839275222246405745257275088548364400416034343698204186575808495617. (henceforth referred to as prime128). This means that operations inside a zk-circuit using this curve can only support numbers up to prime128.

Similarly, the generation and verification of Ed25519 signatures are operations on the twisted Edwards curve which is defined in a finite field under the prime p = 2²⁵⁵— 19 (hence referred to as prime 25519). Note that prime25519 > prime128.

Now, in order to generate SNARK proofs of Ed25519 signatures that can be verified cheaply on Ethereum, we need to perform Ed25519 curve operations inside the alt_bn128 finite field.

To achieve this, since prime25519 > prime128, we essentially need to represent a larger finite field inside a smaller one. This means we can not use the native/decimal representations for Ed25519 field elements since the numbers will overflow. Hence, we must define our field elements in an alternative number system.

We tried two different approaches—

Approach 1: Binary (Base 2) representation

The easiest approach is to represent all numbers in binary format, with each signal (field element) in Circom representing each bit. Since the only enumerable value for each signal/variable is 0 | 1, implementing addition, subtraction (using 2's complement), and multiplication is fairly straightforward. Any well-known algorithms can be used to do the same. However, using a binary representation is not efficient because we end up using only a fraction of the information each signal can capture, requiring a much larger number of signals to define the same computation. This, in turn, leads to a infeasibly large number of constraints.

Approach 2: Using a larger base

We can represent numbers in the same manner as a lot of BigInteger libraries do, by fitting smaller chunks inside the largest possible native element and using an array of such chunks to form larger numbers. We can fit at max d = largest_possible_field_element - 1 in a single signal. Instead of base 2 (binary), we can let each signal represent a "digit" up to this number d. In other words, a number system with base d+1. Now the information captured by each signal can be maximized, reducing the required computation for basic arithmetic operations compared to a binary representation.

The base we used in our implementation is 2⁸⁵, which is much smaller than the maximum base that we can use. There’s a specific reason for this, related to our implementation of the modulus operation. This is discussed in later sections.

2. Finite Field with Base 2⁸⁵

Now that we can represent the elements from the Ed25519 finite field inside the alt_bn128 finite field, let us see how we can perform operations on these numbers. Given that we are not using the native/decimal representations for field elements, we cannot used the native + and *operations provided by the CPU. We must define our own custom functions for operators such as addition, multiplication and modulus.

Addition and Multiplication

Find the implementation of base 2⁸⁵ adder here and base 2⁸⁵ Multiplier here. The multiplication algorithm is basically standard long multiplication, where the carry is handled in the end.

Modulus under prime25519

We must perform the modulo operation in such a way that long division is avoided since it would be too expensive inside a zk-circuit. The algorithm we have used is as follows —

Let the prime p for the curve to be defined as p = 2²⁵⁵ - 19. Given input x, we need to calculate x % p

We define c = 2^255 and,
r = x % c(Note that r < 2²⁵⁵. Also r is simply the least significant 255 bits of x )
q = x // c(q is simply x sans the least significant 255 bits of x )

Note that 255 = 85*3 . This is the reason we have selected 2⁸⁵ as the base. Calculating r (and by extension q) becomes very efficient since we can simply take the first 3 elements of the array representing x to calculate r. Long division is not needed.

Hence we derive equation (1)

x = q*c + r
x = q*(p+19) + r   -- (1)

Simplifying (1) and taking modulus p on both sides

x % p = 19*q % p + r % p

Now, calculate r % p as:

if (r>=p): r % p = r - p
if (r<p): r % p = r

However, there is no way to define conditional logic inside a circuit. Instead, we use a multiplexer which serves the same purpose when one out of multiple values needs to be selected. In this particular case, we provide both r and r-p as the input signals to the multiplexer, and assign the selector to be 0 | 1 based on whether r - p underflowed or not.

We can apply this algorithm recursively to calculate 19q % p. Recursion also means that x can be of arbitrary size.

Now that we have the basic operators in place for the Ed25519 finite field, we can use these as building blocks to define the twisted Edwards curve inside our zk-circuit.

3. Defining the Twisted Edwards Curve in the alt_bn128 Finite Field

We need to take two things into account —

1. All the curve operations for Ed25519 must be implemented from scratch using our custom operators defined in the previous section.
2. We must represent all the Ed25519 operations as polynomials so that they can be represented in the R1CS constraint model.

Let's start with point addition. Re-arranging the point addition equation for the twisted Edwards curve such that only + and * are used, we get:-

If three points (x1, y1), (x2, y2) and (x3,y3) satisfy these two polynomials, we can say that the third point is the sum of the first two points.

Please note that for the + and * operations in the equations above, we will use the custom adder, and multiplier (and modulo) defined in the previous section.

In our Circom implementation, rather than using cartesian coordinates, we use the radix format as defined in the reference implementation (given here). This changes the polynomials a bit, but the core logic is the same. Please see the code here.

Scalar multiplication on the curve is essentially repeated point addition, hence it was easily implemented using the above circuit. Finally, we needed a Circom implementation for SHA512. We were able to modify the existing SHA256 implementation from the Circom library to achieve this.

Using the above as building blocks, we achieved a working implementation for Ed25519 signature verification, with the following performance parameters —

Next Steps

Since the largest power of tau ceremony available is 256 mn constraints, we can fit a max of 99 signatures in a single SNARK. However, validator sets could contain 1000’s if not 100s of 1000s of validators, and hence there is a need to scale this.

We are currently working on STARK based implementations and exploring the use of recursive proofs to achieve logarithmic scaling of proof generation time. We are also working with hardware acceleration companies for reduce proof generation time.

zk-Ed25519: Underlying Mathematics was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Electron SDK is an open source library that ships with multiple cryptographic primitives that are required by virtually all zk powered applications. Currently, developers have to spend months figuring out circuit implementations of various encryption, hashing, and signature schemes. As a result, most builders shy away from building ZK-powered applications. The goal behind Electron SDK is to reduce the lead time for developers to learn ZK so that they can start building within 3 weeks rather than 6 months. We aim to abstract away the complexities of ZK systems and cryptographic constructs so that developers can focus on their use case.

Let’s look at the various cryptographic libraries provided as part of Electron SDK.

zk-Ed25519

zk-Ed25519 is a circuit implementation written in Circom to prove validity of a batch of Ed25519 signatures. Today, most ZK builders choose to use Snark-friendly signature schemes such as EdDSA on babyjubjub curve for their applications, in spite of the fact that this leads to compatibility issues with existing blockchains This is because it’s hard to create a zk-prover for Ed25519 since it uses a finite field which is bigger than the altbn128 finite itself, the one used by zk-snarks. We solved this problem by defining the prime 25519 finite field on base 2⁸⁵. This enables fast multiplication and modulo operations on the twisted Edwards curve while keeping all field elements within altbn128 finite field.

Potential use cases include compression of Light Client headers, making privacy dApps compatible with existing wallets, and powering scalability rollups on rust-based chains.

Electron-rs

Electron-rs enables on-chain proof verification in rust-based ecosystems like Solana, CosmWasm, and NEAR. Till now rust based provers like arkworks-rs were not directly compatible to run on-chain due to various reasons like their dependency on non-wasm/BPF compatible dependencies and heavy computations which generally exceed the gas limits for any chain. Electron-rs is a complete plug-and-play verifier that is available as a ready-to-deploy smart contract that allows you to :

1. Store prepared verification keys in on-chain storage for quick access and updation.
2. Do fully optimized on-chain proof verification for as less as 150 TGas.

Available on NEAR, Solana and CosmWasm

AES-circom

The Advanced Encryption Standard (AES) is a specification of data encryption. AES is a symmetric key algorithm.

We have implemented the AES-GCM-SIV encryption scheme in Circom in order to be able to generate zk-snark for encryption, which can then in turn be verified on-chain. Even though AES-GCM-SIV is not Snark friendly, we still chose this encryption scheme as the Snark-friendly schemes haven’t yet been fully verified.

sha512-circom

sha512-circom is a circuit implementation for SHA-512, or Secure Hash Algorithm 512, a hashing algorithm used to convert arbitrary byte stream to a fixed-size output. SHA-512 is used in popular signature schemes, for eg. Ed25519; and some merkle tree implementations.

So far, our work on Electron SDK has been focused on building cryptographic primitives. However, going forward, we are focussing on improving the proof generation infrastructure for applications.

Future Roadmap for Electron SDK

In the future, there are two places where proofs will be regularly generated — cloud machines and client-side such as browsers. We are working on accelerating proof generation in both these places.

Proof Generation in Browsers

Electron SDK is moving away from Snarks and towards Starks. Proof generation using Snarks required the use of a proving key which can be several gigabytes in size even for the simplest applications. For privacy use cases, this means users will be required to download very large files for every dApp they interact with and re-download it every time their existing dApps go through an upgrade. Starks are very interesting here since they do not have large proving keys, and require fewer resources for proof generation.

We have run tests using distaff VM, a Stark-based VM which is easily compilable to Wasm and hence easy to make compatible with browsers. We were able to achieve 300 ms proof generation time for a simple adder circuit. We will be conducting more tests going forward to set benchmarks. Eventually, the goal is to achieve sub 1 second proof generation time even for complex applications.

Proof Generation in Cloud and Recursion Proofs

Since the computational resources with a smart contract are limited, it would not be possible to submit a proof for every user interaction. This is where recursion comes in. Recursive proving allows combining several proofs into one, thus compressing a massive number of user interactions into a single proof.

Starks are preferable in this case also since stark-based proof recursion is much easier, making it possible to aggregate multiple stark proofs into a single stark.

We are working on using plonky2’s recursive engine to reduce the proof gen time for zk-Ed25519. Based on initial tests, we believe we are close to reducing proof generation time to ~ 90 seconds from the current 16 minutes. We aim to achieve sub-5-second proving times for large batches of ed25519 using GPU-based acceleration.

Putting it together

Based on the research so far, we believe the future of ZK infra will have 3 components -

1. Proof generation in the browser using prover-friendly schemes such as Starks.
2. Use of recursive proofs to aggregate client-side proofs.
3. Use of hardware acceleration for speeding up cloud-based proof generation.
4. Use of recursion to convert the final aggregated proof to a Snark or similar verifier-friendly scheme before submission to a blockchain.

Ending Note:

We are already using Electron SDK to power the use cases we are building at Electron. Many members of the community have reached out to us to use our libraries, and we are happy very to provide support to projects that are building using our engine.

Continue reading part 2… (coming soon)

Join Electron’s Community:

Twitter | Telegram | Discord | Website | GitHub | LinkedIn | Youtube

Electron SDK: An Open Source Library for Building ZK Applications(Part 1) was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s dive deeper into how we can construct zk-proofs of transaction validity.

Checking the validity of a transaction can be done via full block verification or light client verification. Both these techniques essentially involve verifying a large number of digital signatures. On rust-based chains, ED25519 is the most popular digital signature scheme.

Hence, we must now figure out an approach to construct a single zk-snark proof for a large batch of ED25519 signatures.

Our approach involves two steps:-

1. Construct a snark proof of a single ED25519 signature.
2. Combine a batch of ED25519 snark proofs into a single snark proof.

Let’s understand each step in detail.

Step1: Construct a Snark Proof of a Single ED25519 Signature

We first implement the ED25519 signature scheme in R1CS constraints format using circom. R1CS is basically a polynomial representation of the maths behind ED25519. However, this has a problem. All mathematical operations defined in circom and zk-snarks only work with numbers less than or equal to prime number p = 21888242871839275222246405745257275088548364400416034343698204186575808495617. This is because altbn128 curve uses this prime number.

But the mathematics of ED25519 requires number operations beyond this number. To solve this problem, we represent all numbers in base 2⁵¹. This means all numbers always stay below prime p. We select 2⁵¹ as the base since it allows us to exploit certain mathematical properties of the prime number used by ED25519 (q = 2²⁵⁵-19). Finally, we use snarkJS library to construct the zk-proof.

Check out our github repo to see the implementation.

Step2: Recursively Combine many Snark Proofs into One Proof.

We must now combine multiple snarks proofs into one single proof. This single proof will prove all other proofs. How will we do that?

Say, we have two proofs proof1 and proof2. We can construct a third proof proof3 which proves that proof1 and proof2 are valid. The circom circuit would take proof1 and proof2 as input signals and then use a circom implementation of proof verification algorithm (on curve altbn128).

We can extend this to many proofs by creating a merkle tree sort of structure, where we successively combine proofs together to create a single proof.

This technique is adapted from recursive snark technology by Mina Protocol and plonky2 by Polygon Zero.

Conclusion

Zero-knowledge-based light clients have many applications. They allow us to prove transaction validity very cheaply anywhere, such as smart contracts on any blockchain or in cloud applications.

At Electron Labs, we are using them to build ultra-cheap cross-chain bridges. Many cross-chain transactions can be batched into a single snark proof. This makes cross-chain transaction costs very low, and nearly at par with normal blockchain transactions.

We are currently working on building ZKLC light clients for NEAR and tendermint blockchains. In the future, we plan to extend this technology to create proofs of an entire blockchain itself, which will have tremendous applications.

What is ZKLC and How it Works? was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Vitalik essentially makes a simple argument that standalone blockchains can survive short-term 51% attacks, while bridges would go through catastrophic failure under these conditions. Actually, we will show that bridges can survive such attacks, in the same manner a standalone blockchain survives it.

Consider Vitalik’s first argument:-

“suppose that you have 100 ETH on Ethereum, and Ethereum gets 51% attacked, so some transactions get censored and/or reverted. No matter what happens, you still have your 100 ETH.”

This concept is often referred to as “finality”. It means that as a transaction (that gave you 100 ETH) gets deeper into the blockchain (as more blocks are added on top of it), the difficulty of reverting this transaction rises exponentially. This happens because, in order to revert a transaction, the 51% attacker would need to build a new chain starting from the block containing this transaction. If many blocks have been added on top of this transaction, the attacker would need to recreate all those blocks. This would be hard to do for old transactions. But for new transactions, only a few blocks would need to be spoofed, and hence a 51% attacker might be able to revert them. This is the reason Metamask users are advised to wait for several blocks of confirmations before considering their transaction complete.

So far, so good.

Now consider Vitalik’s second argument:-

“if you move 100 ETH onto a bridge on Solana to get 100 Solana-WETH, and then Ethereum gets 51% attacked. The attacker deposited a bunch of their own ETH into Solana-WETH and then reverted that transaction on the Ethereum side as soon as the Solana side confirmed it. The Solana-WETH contract is now no longer fully backed, and perhaps your 100 Solana-WETH is now only worth 60 ETH.it.”

In this case, Vitalik is assuming that the moment the user moves their assets into the bridge, the bridge will instantly make the cross-chain action on Solana. However, the bridge could easily wait for the transaction to be “finalized” on Ethereum (ie wait for the tx to become several blocks deep), before taking the cross-chain action. This is similar to how Metamask users wait for several blocks of confirmations. This way, the bridge can be sure that even if Ethereum is 51% attacked after it takes the cross-chain action, the transactions processed by the bridge will not be reversed, since they are already several blocks deep.

The rest of Vitalik’s arguments are built on top of this argument only, hence we will not discuss them separately.

Going further with BFT consensus

BFT consensus systems like tendermint and NEAR provide instant finality as a feature, and hence transactions do not have to wait for any block confirmations at all. Hence, for BFT chains, cross-chain transactions are indistinguishable from same-chain transactions.

Our Reply to Vitalik’s Concerns on Cross-Chain Bridges. was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Standard Setup — Verify all signatures. ⅔ should be valid.

Probabilistic Setup — Verify only 19 signatures. All should be valid.

Let us now show that both cases — standard setup and probabilistic setup, provide almost the same level of security. Let's dive in.

Consider that a blockchain has a total of N validators (we have tested our model for N between 100 and 1 Million). As assumed by most blockchains, we also assume that a max of N/3 validators could be malicious. As a worst-case scenario, we assume that all these N/3 malicious validators are colluding together to attack Electron Protocol.

In the standard setup, all validators’ signatures would be verified, and since we know that no more than N/3 are malicious, we know that at least two-thirds of total validators have signed correctly and that we can trust this block. This is the security provided by the blockchain itself.

Now, in the probabilistic setup, we are going to verify all signatures from x (x=19) randomly selected validators. As a source of randomness, we use the hash of some block (it could be previous block or current or some combination). We know that the crypto community at large believes that the hash of blocks is not a good source of randomness, since the hash can be manipulated, however, we shall show in a separate article that in our case (and in our case only), hash of block provides very good security. For the scope of this article, let us assume that hash of block is a good source of randomness.

So now, using the hash of block as randomness, we can calculate a random subset of x validators from the entire N validator set. Now, for Electron Protocol to be hacked, x must contain only malicious nodes. Even if one honest node is included in x, this honest node’s signature will not agree with the signatures from other x-1 validators, and the attack will be detected.

We can now state this as a maths problem:-

We must calculate the probability that when the x subset is calculated, the probability that all x are from the malicious N/3 validators show be very low. OR the probability that at least one honest validator (from ⅔ * N) is selected in the x subset should be very high.

We can restate this in simpler terms, removing all references to blockchain-specific things and reducing the above statement to the high school probability question. Here it goes:-

Consider a total of N balls. Out of this, N/3 balls are red, while the remaining ⅔ * N balls are blue. If you draw x balls at random, what is the probability that all x balls are red?

Solution:-

If all balls are drawn together:-

Probability that a given drawn ball is red = ⅓

Probability that all x drawn balls are red = ⅓ * ⅓ … x times = (⅓ )^x

For the network to be secure, the following condition must be met:-

i.e. there is less than 1 in a billion chance that all validators selected in the subset are malicious.

If balls are drawn one by one:-

Probability that 1st ball is red = ⅓

Probability that 2nd ball is red = (N/3–1)/(N-1)

Probability that 3rd ball is red = (N/3–2)/(N-2)

…

Probability that xth ball is red = (N/3 — (x-1))/(N — (x-1))

Multiple all these terms together, we can write:-

Now, for the network to be secure, the following condition must be met:-

For large enough values of N, say 1000, this equation becomes the same as the case when all balls are drawn together.

The smallest integer value of x that satisfies the above two equations is 19.

Now someone might argue that 1 in a billion is not secure enough, they might ask for 1 in a trillion. We can easily do that. If you see these equations, the probability of hack diminishes exponentially with the value of x. So, by increasing x in small amounts, we can increase security by large amounts. So if I make x = 26, the probability of hack falls well below 1 in a trillion.

Ending Note:-

Electron Labs is building an interoperability protocol to make cross-chain products possible. Our goal is to enable the developer to think in blockchain agnostic terms. We are hiring!

Website :- https://electronlabs.org/

Github :- https://github.com/Atom-Labs-one

Discord :- https://discord.gg/WWuCPw8QEB

Telegram :- https://t.me/joinchat/XUknutKGjyhiZTA9

Twitter :- https://twitter.com/labs_electron

Security Analysis Of Validator Subset Approach was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Definition:-

Where g^x is exponentiation and mod m is the modulo operator.

The Module Operator
Let us understand the (mod m) operator deeper first. If y = x mod m, this means that y is the remainder when x is divided by m. Hence, one could write:-

where q is the quotient when x is divided by m

Let us look at some interesting properties of the mod m operator

Property 1:

Proof:-
Both a and b can be written as:-

Substituting these values of a and b in right side of the equation, we get:-

Substituting the values of a and b in left side of the equation, we get:-

As we can see, both the equations evaluate to the same value.

Property 2:

Proof:-
Substituting the previous values of a and b in left side of the equation, we get:-

Substituting in right side of the equation, we get:-

As we can see, both the equations evaluate to the same value.

The E(x) Operator
Now that we are comfortable with the modulo operator, let us turn our attention back to the E(x) encryption function we defined earlier. E(x) is called an encryption operation since it’s not easy to find the value of x given the value of E(x). Hence, E(x) is a one-way function. The cool thing about E(x) is that it allows us to perform basic arithmetic operations on x, even when only E(x) is known, but x is not known.
Let’s dive deeper into these interesting properties of the E(x) operator:-

Property 1:

Proof:-
Expanding the left side of the equation, we get:-

Using the property 2 of modulo multiplication defined previously, we can write:-

Which is the same as the right side of the equation.

Property 2:

Proof:
Expanding the left side of the equation, we get:-

Using the property 2 of modulo multiplication defined previously, we can write:-

Which is the same as the right side of the equation

This was a basic intro to some of the maths used in ZK-SNARKS. In the next article, I will attempt to create a basic zero-knowledge scheme using the Homomorphic encryption defined here.

References:
Here is an awesome article series by Makesym on ZK technology — Why and How zk-SNARK Works 2: Proving Knowledge of a Polynomial | by Maksym | Medium

In this article, we will discuss a key piece of Electron Protocol’s Interoperability technology — Bidirectional Light Clients. BDLC enables a smart contract to verify transactions from a different blockchain, without additional trust assumptions.

Let’s dive in.

Consider that two cross-chain smart contracts are trying to communicate with each other.

Since smart contracts can only work with on-chain data, and the underlying blockchain does not support connecting with the “outside” world, an off-chain entity (called relayer) is required that will read data from one contract and make it available on the cross-chain contract.

However, now we must devise a way so that we don’t need to trust the relayer to act honestly. One way to do this is to enable the smart contracts to verify the translation themselves.

We achieve this by running the Light Node of Chain A inside the smart contract on chain B, and vice versa. This way, whenever the relayers submit faulty/malicious transactions from chain A, the B smart contract can simply verify each transaction using the A light client it now has access to. Since Light Clients of both the chains are run inside the opposite chains’ smart contracts, this approach is called Bi-Directional Light Client (BDLC).

Lets us now understand the details of how this works, and how we fit a Light Node inside a smart contract.

Before that, let us understand what a light client is, and how it works?

Light Client is a piece of code that can independently verify whether a particular transaction is a valid blockchain transaction or not. The exact logic of this code is open source and fixed for a given blockchain. Light Clients do not require access to the entire blockchain data, and require little compuational power. They were originally designed to be implemented within IoT devices.

A Light Client works in two steps:-

1. First, check whether the concerned transaction is part of a given block or not.
2. Then, check whether the given block is “valid” or not. Valid means that it is part of the canonical chain.

Let us understand each step in more detail.

Step 1: Check whether the concerned transaction is part of a given block or not?

We do this by following the Merkle path. As shown below

Blockchains store transactions by organizing them in a Merkle tree. A Merkle tree is formed by successively hashing transactions with each other in pairs, until one single hash is left, which is called the Merkle root. This Merkle root is included in the block header. In essence, the Merkle root encapsulates all the transactions of that block.

Now, if we want to check whether tx[6] was part of the given block, we simply need to hash tx[6] (along with the data on the Merkle path, as shown in the diagram) successively until we reach a single hash. If this hash matches the Merkle root, then we know that tx[6] was indeed included in this block.

Now, if we can show that this block is “valid”, we can be confident that this transaction is indeed part of the blockchain.

Step 2: Check whether the given block is “valid” or not?

In order to be called a valid block, the given block (or rather block header) must be signed by at least ⅔ validators, and, the block must point to the previous valid block.

Now, checking signatures from thousands of validators on a smart contract would be computationally very expensive (and infeasible within a smart contract). But, we don’t need to verify all signatures, just 19 actually. Let us discuss how.

Verifying a Subset of Validators instead of All

To check validity, typically one needs to check that the block has at least two-thirds of validator signatures. However, instead, if one takes a random subset of just 19 validators, and checks all the 19 signatures, then almost the same level of security is achieved.

This is shown through the probabilistic analysis below.

Consider n validators, out of which ⅓ validators are malicious (⅓ is the maximum dishonest nodes that PoS blockchains can tolerate). n can be any number between 10 and 1 million.

Now we must select ‘x’ random validators from total ’n’, such that the probability that all ‘x’ validators are malicious is less than 1 in a billion. This can be described in the below formula (derivation of this formula can be found here).

Solving this equation, we get the result that

Verifying 19 signatures inside a smart contract is computationally feasible. (More about this will be added here as link)

Now, we must check if our block points to the previous canonical block or not. At first, it might seem that we would need to download all previous block headers. However, light clients avoid this by using a trick called block checkpoints. For now, we will not discuss this in detail, instead please see how Tendermint does this here and see Vitalik’s thoughts on this here (which is also the basis for Ethereum PoS light client). If you want this discussed in detail, please leave a comment.

At Electron Labs, we have used BDLC technology to build an interoperability protocol that exists completely as L2 smart contracts and only relies on the security of the underlying chains themselves. This is as opposed to existing protocols in the ecosystem that use either multi-sig, oracle, or some other centralized approach.

Ending Note

BDLC is the same technology that is powering Cosmos IBC, and NEAR’s rainbow bridge. It seems that Solana wormhole aims to implement this tech in the future as well.

Since posting this article, we have upgraded our technology to zero knowledge proofs based light clients. Check out https://medium.com/electron-labs/what-is-zklc-and-how-it-works-a5aaadf70fc0

What is BDLC and how it Works? was originally published in Electron Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.