Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
DEV🕶TIME: A Vara ↔️ Ethereum Bridge Deep Dive
Recorded: May 20, 2025 Duration: 0:42:27Space Recording
Short Summary
In a recent session, the launch of the VAR Ethereum bridge was announced, marking a significant advancement in blockchain interoperability. The testnet is live, inviting users to engage with the platform, while discussions on liquidity, partnerships, and innovative recovery mechanisms highlight the project's growth potential and alignment with current trends in the crypto space.
Full Transcription
Thank you. All right, hello everyone, welcome to today's DevTag.
Let's just wait a few minutes.
We're going to add our speakers to the stage and then we're going to start.
Hello, Georgie. Can you hear me?
Yep. Hello, Claire.
Welcome. Let's also add Dima to the stage.
I'm already here.
Oh, my God.
What's up? Amazing. I still see you
as a listener. So I hope you guys are fine. How are you doing today? Yeah, pretty good as usual.
Like another working day, including the bridge stuff, exist stuff and stuff all right so a small introduction
today we're gonna have xspace about the var ethereum bridge this is gonna be technical session
as georgie and dima are both core developers. We're going to dive into the technical aspects.
Last week, we had an X-Space with Luis and our ambassadors
who dived into the community effect and features and stuff.
So if you didn't join, make sure to find this X-Space as well.
And I think we can start.
The session is recorded, so anyone who couldn't join or would be late can join later. I just got this big testnet live thumbnail here. Yes,
the VAR Bridge testnet is live so make sure to check it out and feel free to test it yourself.
I just see Georgi got lost. Am I right?
Yes, you're right, just because he's having some issues with the X app on his iPhone.
So it's more likely the God of X decided that I'm good for today's session, but George will have all the glitches.
Okay, okay.
Let's hope he will be able to join.
I know some of the questions for him are going to be later,
so maybe we can slowly start.
Ah, okay, he is back.
You're back, George.
It's okay, it's typical.
Twitter is always doing this stuff and jokes with us.
So let's hope it's going to work for you.
And let's start.
And, yeah, here is the first question.
So, guys, what was the original vision behind creating the VAR Ethereum bridge?
And what kind of key benefits does it
bring to the whole VAR ecosystem? I think nowadays with a lot of layer 1s
existing in the world, a lot of competitive guys to each other, a lot of
huge dev commands, it's kind of obvious why do layer 1 developers develop the bridges to them.
Just because initially it was only one option to bridge some assets from one ecosystem to another.
Then we had a lot of success, a lot of centralized bridges and stuff. Everybody keeps building or keep doing some, you know, like third party, third party promotions and ask somebody to build a bridge or connect already existing bridging solutions like multi
chain and stuff.
So it's just as simple as it is, just we need to explore our benefits for our new benefits for our network.
We need a new liquidity.
We need a new users who may be kind of afraid to bring their assets to us, or maybe they
are not confident enough to start building something here.
But now it's possible.
It's more flexible.
It's more easy to just come and use for example usdt and any other uh any other
protocols and tokens you are used to have all right uh since also it's uh georgie first time
if you would have any comments to any questions feel free to comment on what Dima says and also at the end of the session we're
gonna have open mic session with all the listeners and if they have some question they can ask us
so just wanted to mention this for you and thanks Dima for answering the first question and my dog
is playing with a toy in here so sorry for the squeezy noises and let's jump to the second
question uh if you guys could explain in simple terms how assets move from the uh bridge uh from
vara to ethereum and back through the bridge oh my god Actually, it helps a lot that we have these AMI sessions
constantly.
So I may reference to the previous ones
when we were talking about RISC-V or RISC-V.
I just totally forgot about this stuff.
Is it V or V?
OK, never mind.
The point is we were talking about the ZK proofs,
how does it work in simple terms or more text diving inside.
But anyway, if we focus only on our implementation,
we only need to explain it like to the child.
It will be something like this.
There is a transport protocol of the breach,
including one contract on Vara including one contract on vara one
contract on ethereum uh there is the key proofs somehow related to this but it doesn't matter we
keep going simple and when we breach some assets it means we reach a message from one network to
another that on this network we have locked some, so we need to mint them on another one.
It depends which direction we speak about.
For example, if some asset originally exists on VARA, so we need to lock it on VARA and mint on Ethereum.
Or otherwise, if something exists on Ethereum, we need to lock it on Ethereum and then mint on VARA.
And it's all the same into opposite direction so for
example if we breach some asset that originally exists on ethereum and we have it already minted
on vara we need to burn it on vara and then unlock it on ethereum so that's literally all
that you need to know how does it work just because it's as simple as it could be it's
know how does it work just because it's as simple as it could be. It's pretty much like
as everybody does in the bridge spaces and stuff.
Alright, and if we should follow up also, we mentioned ZK proofs in the past X-Space.
So in simple terms, how do zero knowledge proofs work in the VARA to Ethereum
direction of the bridge and what problem do they solve in this situation?
Yeah, we only have ZK proofs in one direction from VARA to Ethereum. What do they do? It's
What do they do? They prove somehow, according to the math inside the ZK proof, they prove that
at some point there was a block on VARA network that was finalized, signed by its validators,
all of them, or at least their majority. And then we prove that inside this block,
inside the Merkel root of the storage on VARA,
we had some key, which is responsible for representing
our message queue from VARA to Ethereum.
So basically, we provide, like in simple terms,
we provide a proof that we had a block.
It's finalized.
It's signed by actual validators
according to this block at this very uh time slot and there was uh some key uh that can contains uh
the message queue to ethereum so when we throw it to ethereum everything is checked on ethereum and
then we can extract this data already there.
So we can ask some third party contracts to accumulate this data, do some actions,
for example, lock and lock tokens, depending on what and who has submitted the message from VARA.
So, for example, in our implementation of assets bridging, we have one contract on VARA,
of of assets bridging we have one contract on VARA one on Ethereum they have dedicated addresses
one on Ethereum.
and they do know about each other and they only accept messages through the bridge from each other
so I think I think that's it so you mentioned we have ZK Bruce only from the direction VARA to
Ethereum and I'm not a technical person. So maybe could you say why?
Is it enough or it's like, you know, maybe it's super easy to understand for someone technical,
but I don't understand it.
So why is it only in one direction?
Is it like pointless to have it from the other direction as well?
Actually, when you develop something like in a world, in a tech world,
you do not need that you do not need. So when we work with our bridge from VAR to Ethereum,
we do need the key proofs because it's a huge amount of data that we need to verify.
They may not fit even the block of Ethereum, but in the opposite direction, we have another mechanism that is totally provable, totally secure, and also relies on the same data as
we rely inside the K-Proof.
But we do not need the K-Proof because this data somehow aggregated and more compact for
So we could process it inside the VAR block easily just because because our design because
of awesome instead of EVM and stuff. Thank you all right and then also what are the Merkel routes
how often does the bridge update them and why does the timing matter for the bridge security?
Why does the timing matter for the bridge security?
The Merkel root is a part of such data collection inside the tech world, which is everybody from some values and the point of this data structure that if you
have if you have some root you could verify that somewhere inside this data structure you have
some value so for example have a root x and I say Claire there is an element A inside this tree, and this is the root of the tree.
I can give you a small proof that allows you to verify that going through some dedicated branches, you could find this value.
So it's just simple to verify something being inside some huge data.
For example, almost all of the modern blockchains are built using or somehow using the Merkle
trees inside their block production.
So for example, inside Ethereum, there is a Merkle route for transactions inside the
blocks.
There is a Merkle route inside the block of ever happened events inside this block.
Speaking of VARA and the substrate at all, there is Merkle roots for the whole storage.
So each storage element is some key with its value and it all composed into a tree and it has its root.
So if we have a root, we can verify that something is inside this total
data storage. Yeah, it's something like this.
And going back to the original question,
how often do we submit them?
We update this Merkle root of the message queue
that we provide, that we bring from VARA to Ethereum. We update it on each message sent on each block.
If something was sent, we do update each block on VARA.
So you could be as fast as you want to be in terms of bridging this route from Vara to Ethereum. So having the less ping, having the less time
for answering you from Ethereum.
All right, thank you, Dima.
Also, another question.
How does the bridge validate Ethereum transaction
without relying on zero knowledge proofs in that direction?
And what role does the Ethereum beacon chain play?
Okay, so let me answer this question.
Good first question for me, actually.
question for me actually. The Ethereum Beacon Chain is the name of the original proof of
stake blockchain that was launched in 2020. The first scheduled upgrade for the Beacon
Chain was the Altar upgrade in 2021. It also added support for Ethereum's's light client protocol uh you know white clients program uh it's so
uh program that keep track of the chain uh of some chain if we talk about ethereum of
beacon block headers in that case but don't store the full ethereum state
state so it makes possible to synchronize fast faster and don't require a huge amount of
space of memory space for ethereum state data so the bridge utilizes that protocol it has a program called checkpoint light client
in minimal ethereum beacon chain light client that stores finalized block headers and the
sync committee sets it accepts newly finalized headers store them after verification and enables
newly analyzed headers store them after verification and enables trusted trustless validation of
ethereum side data with the help of billy s12381 elliptic curve cryptography this cryptography
is implemented as a so-called built-in program on the Vira site.
So I think that's all.
This client allows Bridge to validate any Ethereum transaction.
And I guess that's...
Yeah, so basically after it was implemented on Ethereum, the beacon chain itself, it was
super different things about execution and about validating results, having a consensus
between Ethereum validators.
So like the good guys developed this as a protocol and everybody uses it.
So we are not the first ones in these terms.
And the point is, so it's all thanks to the Miracle Roots we just mentioned.
And it helps us to also verify that there was a block, it was signed,
and there was such Miracle Roots for transactions, for events, and so on.
And actually, as you said, we can do it within one VAR block.
Yeah, of course. We have a lot of things we could do inside one VAR block just because it's awesome.
it's awesome, it's super optimized
It's super optimized gear protocol, as we all know.
gear protocol, as we all know.
As we all know.
Those who are listening our sessions,
they already know, right, Ima?
All right.
So, what is a
sync committee in Ethereum, and
how does the bridge use it to verify
information coming from Ethereum?
Another good question. As you know, many blockchains use the so-called concept as proof of stake, consensus mechanism
to finalize blocks and there are some parts or members that called validators
or block proposers a group of12 validators that is randomly selected
every sync committee period. It's about one day. And while the validator is a part of the
currently active sync committee, they are expected to continually sign the block header with their own private keys.
Sign the block header that is the new head of the chain at each slot. So the
light client protocol uses the sync committee mechanism to reduce the computational cost of verifying the validity of ethereum block
headers because verifying over 400 000 signatures per block can be quite expensive even in
settings outside of blockchains And yes, maybe it was noting to repeat that all these signatures, public-private key cryptography
is based on the elliptic curve cryptography known as BLAS-12.
known as BLS12.
It's also worth noticing that about the BLS cryptography,
that we have inside the Git protocol, we have built-in actors,
and there was a first built-in actor that implements BLS cryptography.
So the fun fact, it was implemented the same way.
Not exactly the same way, but it was like desired to be some built-in functionality
for Ethereum in the latest update inside the Pectra, if I'm not mistaken.
So it's kind of Ethereum follows us in our path, you know.
Interesting. Thank thank you guys. So how does the bridge use
virus validator set to ensure messages can be trusted when moving between
chains? Yeah I think it was already answered multiple times but just to sum
up it's the only block that were signed by the actual validator set are meant to be the true ones.
So if we have some block that is not signed, you cannot relate to Ethereum.
So nobody could verify it and your transaction will be declined by our contract on Ethereum.
So it's all about the validity of the validator set and the blocks they provide.
Actually, VARA validator set and their participants do not need to do anything
special just because all of this logic is already included inside the substrate,
inside the VARA network.
So nothing, nothing unusual is needed from the
validator perspective just because our bridge is just the palette inside inside the VARA substrate
was in runtime yeah all right so if we have some developers listening to us right now, how they can build on top of the bridge and create their own cross-chain applications?
And are there any tools which Vara provides to make it easier or can they find some information regarding this?
information regarding this?
As far as I know, we already have an article about this, how to integrate with our bridge.
I'm not sure if it was posted already.
Kular, could you help me with this one?
Anyway, there is a kind of simple way to go, just because we have this pilot in public there is a dedicated interface and
built-in actor so even the programs on VARA could call it so they could call something on Ethereum
and if you develop some protocol ahead of the transport layer of the bridge you only need
to write some contracts on VARA write some contracts on vara write some contracts on ethereum uh that will be responsible
for uh proxing messages so for example you write uh some contracts um on vara which does for
example which locks nfts so you lock nft on vara inside this contract this contract sends a message to the built-in actor of the bridge.
Bridge relates it on Ethereum to your contract,
which verifies that your contract on VARA already locked an NFT,
and it can mint the same NFT on Ethereum.
So it's just another idea what to implement on VARA.
Everybody just hop on this one and implement for us NFT bridging.
It will be good actually. Okay, so regarding the article, we have article regarding
cross-chain DeFi, which is available on VARA medium, And I also posted a viki regarding the bridge here
under the X-Space.
So if anyone wants to check it out,
feel free to have a look.
And let's go to the next question.
So what exactly are relayers in the bridge system
and how do they help move information
between Vara and Ethereum?
Okay, so on the macro level, bridge consists of two parts.
It's on-chain VARA programs and Ethereum contracts that perform some logic and actually keeps
track of assets and so on, and of chain parts.
These are just usual programs that can run on any operating system like Linux, MacOS
and so on and the relayers uh um
relays provide information outside the chain that on-chain program cannot receive as we know
or we can make an HTTP request to, in simple words,
open a site, check some message, email,
in on-chain program.
So we need some of-chain parts.
And the relators in this term play a crucial role in the bridges cross-chain communication
model.
These are permissionless actors that deliver various data and proofs between Ethereum and VARA. There are four types of relayers, two transport layers
for each direction and two message layers, again,
for each direction.
The transport relayer for Ethereum wire direction, as we already said, using light client protocol, receives the final updates via the beacon API and sends them to the on-chain checkpoint light client program.
and sends them to the on-chain Checkpoint LiteKind program.
This Checkpoint LiteKind program verifies various hashes,
signatures, and so on.
And if it's okay, it accepts it and saves
the corresponding checkpoint.
The Ethereum VARARA message relay listens for events from the corresponding bridging payment
contract and constructs proof of the inclusion of a block in the corresponding Ethereum epoch
and the Merkle proof for the transaction receipt in this block, and then sends all the data to
the VAR program.
This VAR program, usually called manager, some kind of manager, verifies both types of proofs with the help of
checkpoint light client program and if it's okay it
means or unlocks the corresponding assets
the transport relay for the wire eth Ethereum direction listens for messages from the gear-eth-bridge pellet that contain the Merkle root of the message Q, generates decay proofs for these
routes and sends them to the corresponding Ethereum contract. And the last one, a relay, it's a wire Ethereum message relay that upon receiving an event
from the corresponding bridging payment program constructs a Merkle proof for that message
in the queue and sends the data to the Ethereum contract. The rest is the same.
This contract verifies that the proof is okay and performs required actions.
So, yeah, Dima, go ahead.
Yeah, thank you.
So yeah, basically the relayers, they are just some off-chain scripts, some off-chain bots that only subscribe to some data from VARA to Ethereum and from Ethereum to VARA.
And maybe from VARA to Ethereum direction constructs the proof, the k-proofs, but it cannot be hacked, it cannot be somehow
replaced with another data just because it will be verified on both ends.
So it's totally permissionless, it's totally trustless, and everybody could be a relayer,
it's totally free of charge to become one.
But it's all up to you if you would like to just because you you may need
to cover transaction fees on vara and ethereum so yeah actually uh if you do not trust anybody
if you do not want to spend the money for some third-party services that provide the relay for
you uh you can just submit your assets from Vara to Ethereum for example. So lock it
inside our contract and then go manually create the ZK proof and submit it to Ethereum from your
personal account. So it doesn't matter who would submit the proofs just because proofs are provable
So since we are talking about the three layers, how does the bridge incentivize them to stay
online and process transaction quickly?
I don't know if you guys mentioned this, but maybe it would be good to add this additional
information.
Yeah, good question.
The bridge design actually has an incentivization model for real layers. And it supports so-called bridging payment mechanisms on both sides.
Bridging payment is the name of gear program Ethereum contract and or that collects fees for
teleporting messages from one chain to another. The user automatically pays a small fee when
initiating a cross-chain message which the relayor can later claim and these bridging payment flows are not strictly mandatory users are able
also to relay messages manually without paying an automatic fees
and you know it's it is because the bridge is fully permissionless
So it is because the bridge is fully permissionless.
Anyone can run a relay with the corresponding bridging payment program contract.
No special access is required for that. and availability across different network conditions.
All right.
So just a reminder to everyone who is listening,
as we have two last questions from my side.
And then if anyone has here any additional questions,
feel free to raise your hand we will gladly add you to
the stage and I'm sure also the speakers will be happy if you engage and have some questions for
them. And let's go to the question how does the bridge handle different token standards and
How does the bridge handle different token standards and decimal places between Ethereum and VARA?
New word for me.
Yeah, but you know what is decimals?
What?
Do you know what is decimals?
I guess it relates to numbers. What? Do you know what is decimals? No.
I guess it relates to numbers.
Yeah, exactly.
So it's a standard for the tokens and the decimals is amount of digits after the dot,
the separation from the whole part and the smaller parts of the natural natural numbers so um actually we don't need to somehow support uh these decimals
just because uh basically all of the uh fungible token standards support them inside so they do
keep only natural numbers for example i do have like a thousand of bitcoins or eth Ethereum, but it's not actually Ethereum just because it's one of a million
parts of Ethereum and it's all driven by the decimal amount.
And we don't need to support all of them.
We only right now support ERC-20 compatible tokens on Ethereum.
And it's all the same on the VARA because we have VFT VARA fungible token which
is total replica or re-implementation as you wish of this year C20 token standard from
Ethereum so we only support these ones if somebody wants to start bridging another
assets it's better to go and deploy his own bridge deployment on our testnet, which will be connected to our
palette and stuff. I think it will be somehow explained in our article about how to implement
your own approach using the bridge. I believe it will be posted soon.
I like that
with every session I'm learning
more and more from you guys
so if anyone is
keeping up with us
you're going to learn as well
alright I have a last
question for this session
I hope we're going to get some questions also
from the audience
so what happens if there is a network issue during
a bridge transaction and how does the system recover and ensure assets aren't lost? I would
say this is quite important question for those curious. So guys, what's the answer for this?
for this okay to answer this question we actually need to classify issues by type
so we could we could highlight the following on chain errors on the wire side uh on chain errors on ethereum side and of chain errors uh you know relayers
uh some issues on front ends and so on uh the last ones are the simplest the simplest
and not critical at all uh this is because the off-chain parts of the bridge
are trustless by design and cannot lead to the loss of assets.
If some or relayers went offline, then the bridge will be just paused.
I mean, there will be just no communication between two on-chain parts, VARA and Ethereum, and no transfer of assets
and so on.
And when relays will be restarted, they just continue to listen for required data and generate corresponding proofs
so the next one is error handling on the ethereum side it relies on the state rollback mechanism when gas is exhausted.
This nice property actually eliminates the possibility of ending up in an intermediate
state. the Ethereum fundamental design to avoid intermediate state, undesired states.
So data loss is actually impossible however there are some minor differences for VARA due to
the fact that the gear protocol is very flexible the programs implement message
tracking mechanism that allows any user any any actually any part to continue the transfer of funds from any intermediate states that
may arose due to network issues, insufficient amount of gas and some kind of that. Thanks to Ethereum and its restricted sync execution, we are super safe on Ethereum
just because if something didn't happen, it won't lead to corrupt states.
And due to VARAS flexibility and Gear protocol flexibility, We were forced to do some extra stuff about the
continuation of the execution from each point of termination, of possible termination, but it's
all handled. It was all reviewed by the auditors and we do have an audit report inside our repository of the breach. So yeah.
And speaking about the loss of funds, it's totally impossible, just because it's totally
provable through the math, through the ZKE proofs.
And for example, if you have your tokens locked on VARA because they were submitted to the
breach, you could go maybe in five years and claim your tokens just
because it will be available in in any time in the future
all right that was the last question for today's session so guys do you have some
additional comments you would like to say about the bridge? Anything we didn't mention and you think it's important to say?
Do you think we covered everything?
Yeah, we do think so, I guess.
Maybe we have some questions from the audience.
Does anyone, guys, have here questions?
Would anyone like to join the stage
and ask the speakers uh if so just feel free to raise your hand uh obviously if not it's all right
as well you can always jump to the discord and telegram. We are there 24. Well, sometimes we are sleeping,
but we try to answer as fast as we can.
And also all the devs are in the group.
So if you don't want to ask here or you're shy
or you have nothing to ask, it's okay.
I guess we had 40 minutes on the session.
I think it was really a nice session.
I'm glad we could cover all the technical aspects.
We published and shared all the important links here under the X-Space or here in the top.
I would like to thank Georgi.
It was his first time.
How did you like it with us, Georgi?
Are you going to join us now more often for all the X-Paces?
Thank you Claire for having me for that session
Okay, it was a pleasure
Okay, okay
Thanks Dima as well. It was pleasure as always
Thank you. Would you give me a moment to drop the mic as usual?
Well, I think you dropped it.
But yeah, feel free to share.
No, not yet. Not yet, actually, because I was preparing to this very moment.
And I would like to say that we may not be 24-7 available on Telegram or Discord,
but you know, we're always 24-7 available from the GitHub, and that's our privilege.
And then drop the mic thank you all right okay thanks
everyone who joined us today uh for the session thanks both of you for coming and see you in the
next session thanks everyone bye bye see you next time bye thank you everyone bye bye
Host
Vara Network
from
Vara Network
