[Discussion] Bring on the Dragon Bridge

[satojandro]

TL;DR

Near should seriously consider deploying a bridge to Binance Smart Chain (BSC) - the Dragon Bridge - as soon as the Rainbow Bridge testing and rollout are complete. Low-hanging fruit (EVM), keeping up with rapidly evolving tech trends.

Background / Market Trend

As the congestion and excessive cost of transacting continue to get worse on Ethereum, the Binance Smart Chain has proven what many Eth OGs thought was impossible: the pain was so strong it pushed users to other networks.

Over the last three months there has been a tsunami of users exiting the Ethereum ecosystem and going crazy on the exploding DeFi ecosystem on BSC. This trend is likely continue with mounting speculation on whether BSC will flip Ethereum (let’s create a Pulse market for that )

Opportunity / Challenge

The BSC exodus validates our hypothesis that users will migrate to Near as our superior technology continues to come to market.

It demonstrates that we have been on the right path by building the Rainbow Bridge with Eth to makes the transition for users as smooth as possible.

However, there is a massive challenge: there may not be many users left on Ethereum by the time we are mature enough to welcome the masses.

We also know that being able to participate in hot, liquid, Defi markets if or when needed is a very strong consideration for projects when choosing where to develop. I think the Dragon Bridge would help us attract more projects, knowing that they will be able to easily access both the Ethereum and the BSC Defi ecosystems if needed, without having to endure the potential drawbacks of either.

We must find ways to stay relevant, servicing our (future) users where they are, maximising optionality and making it attractive for devs and do so in a way that does not detract form the Core team efforts. I believe the Dragon Bridge could be a ‘low-hanging fruit’ that could add enormous value.

Technical Assumption / Other considerations

With my limited technical understanding, I am assuming that a Dragon Bridge deployment would be relatively straight forward as BSC is an EVM. I would welcome and highly encourage input from the devs on this point.

Some considerations would be:

1. Dragon Bridge v1: BSC to Near Mainnet

   a. Cross-chain asset consistency: how to ensure that an ERC-20 which was initially sent over to BSC (would be entering Near as an BEP-20), is recognised and becomes the same Near token as the same asset sent over the Rainbow Bridge as an ERC-20. (i.e. ERC-20 UNI or BEP-20 UNI would both converge as nUNI regardless of the bridge they come down)

   Assumption : it would be a lot cheaper for people to send assets into NEAR from BSC, including from other Networks other than Ethereum. BSC is likely to become a cheaper hub.

2. Dragon Bridge v2: BSV to Near EVM (EVM to EVM )
   a. Known Unknowns on my side, I’ll just sign post it here for now. Welcome discussion

I hope that we can start a conversation that hopefully informs the Near roadmap. Let me know if you agree with my observations of the market, benefits of creating a Dragon Bridge, technical considerations, or anything else that you may consider relevant.

[alex.shevchenko]

@satojandro, thanks for the suggestion. Absolutely same ideas are now circulating in the heads of Aurora team (Bridge + EVM). Nice name for this bridge

Our current priority is Aurora delivery to the mainnet. This requires attention from both parts of the team: ex-EVM team is working on the Aurora engine (EVM), while ex-Bridge team is implementing ETH connector and ability to bridge NEP-141 to Aurora engine. This will still take some time…

Then there’re multiple things that are highly requested: $NEAR->ERC-20 connector and NEP-141->ERC-20 connector. And, unfortunately, the Dragon bridge is rated as a third priority after the above mentioned two.

Assets consistency

From my point of view, the assets consistency is an open and quite complicated question. Every bridge to NEAR will add the whole additional complexity layer for solving the consistency of assets. If we have Ethereum and BSC, then we have assets like nDAI, nbDAI. But when we have an additional network (e.g. Polkadot), then we have the following spectrum: nDAI, nbDAI, npDAI, … and npbDAI, nbpDAI, nebpDAI, nepbDAI! If we add more networks, there’s a factorial progression of tokens that we should track.

From one point of view, we can say that this problem should be solved by AMM, from the other point of view, it will be extremely hard to provide enough liquidity for all potential wrappings of tokens already when we’ll have 6 networks connected.

Potentially, the bridge team can maintain the list of similar tokens. This is a centralised decision, so not so cool. A truly decentralised way how to implement consistency would most probably require some kind of protocol / standard. And obviously, NEAR protocol won’t be able to decide on this standard on its’ own.

Note: at the moment Rainbow Bridge does not even support the trustless bridging of token metadata. Even this small thing will require creation of an additional connector!

But now, let’s zoom out a bit. Assets consistency is even bigger problem. Not only fungible tokens should be consistent, but also NFTs, and contract data, like oracles or even above mentioned token metadata. So, this problem is much bigger…

Bridging to EVM

With the consistency problem solved, there’s no issues with bridging tokens in Aurora. It will be possible with our current approach, which is build NEP-141 bridging to Aurora. This internal NEAR bridge will support any NEP-141, independently from what chain they were bridged or originated on NEAR.

[nearmax]

FYI. Binance chain is using Tendermint so the header validation would have to be entirely rewritten from our current PoW validation for Ethereum.

[robert]

The OP is about Binance Smart Chain - which is fork of geth and uses Proof-of-Staked Authority (PoSA) consensus and EVM.

Binance Chain indeed uses Tendermint, but it’s a different chain and it’s not used for DeFi smart contracts.

[Chluff]

I think asset consistency should be left to the free market. First, an efficient AMM with little liquidity is possible, for example using a constant sum market maker, or other alternatives like Curve’s stable swap or Uniswap V3 liquidity concentration. And second, an Eth Dai and a BSC Dai don’t necessarily have the same value, the market can decide to factor in things like network security, degree of centralization (more risk because single point of failure) or practicality (exp: you can’t do much with 50 Dai on Eth because of high fees).

[satojandro]

I would also highlight that the ‘free market’ approach goes beyond individual agents and AMMs engaging in price discovery, but it also includes a much larger and powerful group of ‘innovators’ - projects such as Curve (Eth) or Elipsis, Belt (BSC) that are developed by the community to ease the interoperability of these assets.

My query around standards and consistency was more geared around trying to build in frameworks at a protocol level to minimise fraud. Even though I am aware, and I agree, that every user is ultimately responsible for their own transactions, a network that is ripe with fraud (or perceived to be) will be a turnoff for normies. This ought to be a consideration as we build amazing UX capable of mass adoption (no other chain has even tried).

[alex.shevchenko]

@Chluff

an Eth Dai and a BSC Dai don’t necessarily have the same value

This is correct, I must admit. Besides the reasons that you’ve listed, all of the bridged assets actually rely on the strengths of the brides and protocols they’re using. So, the more bridging is performed, the higher the probability that something will break. And it’s enough to have only one link broken, to bring the value to zero.

@satojandro

it also includes a much larger and powerful group of ‘innovators’ - projects such as Curve (Eth)

I also should admit that this is true. However, it complicates a lot the way how people think.
In ordinary word, people get used to the fact that USD banknotes are interchangeable. Imaging how horrible would be for the people in DC to search for a currency exchange to exchange California USD to DC USD. This would be complicated. And this was actually a period in the US banking system, that is called free banking.

I see the advantages and disadvantages of both approaches. Personally, I believe, everything starts with simple straightforward UX. And onboarding to Curve is for sure not to mass market.

---

Another point on the Dragon bridge:
We did not implemented PoSA, simply because Ethereum 1.0 has ethash. So to launch a fully trustless Dragon bridge somebody needs to work on the implementation of the consensus. However, there’s an option to launch the bridge in the PoA mode, when only trusted relayer submits block headers and contracts trust them. This feature was implemented to support Rinkeby. Here’re two questions:

1. We can launch Dragon Bridge faster in PoA mode and when the new consensus is implemented, update the bridge and make it trustless. What do you feel about this?
2. We can issue a grant for a third party to implement the PoSA consensus while we’re wrapping up Aurora. Is this something interesting to you or sufficiently experienced developers that you know?

[vlad]

@alex.shevchenko

• We can launch Dragon Bridge faster in PoA mode and when the new consensus is implemented, update the bridge and make it trustless. What do you feel about this?

Isn’t BSC itself essentially PoA? Meaning that you don’t really change much about security model if bridge is also PoA. Maybe to align incentives better some of the PoA signers should be large BNB holders and/or Binance itself.

[alex.shevchenko]

@vlad

Isn’t BSC itself essentially PoA? Meaning that you don’t really change much about security model if bridge is also PoA.

Well, BSC will argue that they’re PoA, since there’s a procedure how to become a BSC validator. However, many people are saying that this is PoA.

From my point of view anything that is not consensus is PoA.

In the case of the Rainbow Bridge, PoA mode is specifying a relayer who is able to submit block headers, and these headers are not verified, just trusted. Only one relayer can be specified.

[satojandro]

Fascinating discussion. I have been learning A LOT, but unfortunately I don’t think I have the technical depth to comment on the PoA (temporary) v PoSA questions.

What I do think I can contribute is the perspective from the average user: we really have no idea what is behind the screen, knowing it is ‘EVM compatible’ tends to be enough.*

The acute pain point now, with a recent example: Ethereum is simply unusable outside of the scope of derelict speculation.

I just tried to transfer $500 worth of DAI over the Rainbow Bridge. Just the network fee from my Binance account to my Eth wallet was $77. I stopped the process there, as with current gas prices of 241 gwei I don’t want to imagine what the transaction of using the bridge would’ve costed.

I had a strong vested interest in sending DAI over bridge: was planning to add liquidity to a couple of markets on Pulse (‘Will ETH flip BTC’) and also add liquidity of Ref finance, all while making instructional videos documenting the process. Even then, couldn’t really get the unit economics to work.

I’ll just buy the $500 worth of Near instead and transfer that out of Binance, exchange it once I enter paradise (Near ecosystem, Ref). However, that still leaves us with the same problem we started: how can we encourage the adoption of Bridges and increase the flow of assets, particularly those in demand such as DAI.

Aware that the above is just my personal experience, I do strongly believe that if BSC could be used as a (much) cheaper bridge - one that actually ‘exploits’ Binance willingness to subsidy their bridge and enable instant withdrawal of all assets as BEP-20s) - then we could open the floodgates to liquidity on Near.

So my humble contribution is that most likely a temporary PoA as a short term solution w trustless upgrade further down the track would work really well.

[*This is an area where we could do a lot of work in distinguishing the different types of EVMs and different kinds of bridges. This would fall squarely within the scope of the Open Web Sandbox, although I wonder whether we have people with the required technical expertise to explain these nuances.]

[joshwin77]

Thanks for sharing, nice information