[DIS] Rosen Bridge - Connecting CKB to Cardano, Ergo, and Beyond

Armeanio · December 20, 2024, 5:16pm

Armeanio · December 20, 2024, 5:16pm

Armeanio · December 20, 2024, 5:16pm

Armeanio · December 20, 2024, 5:23pm

Its important for Rosen infrastructure to be flexible/multi channel to prevent a single dependency.

This requires some investigation and development building connections on top of nodes, explorers, and other infrastructure.

This is always different chain to chain and requires some adaptation. Some ecosystems have higher performance services (built for apps) different node implementations, and explorers.

It is not so much a technical barrier as an understanding of the variety, speed, complexity and costs of existing infrastructure and services each ecosystem supports.

That doesn’t prohibit development, its just a matter of tailoring each chain based on the infrastructure that exists.

I tried to make the statement regarding investigation open as I am not familiar with all that exists.
Connecting with core devs and ecosystem devs is always a huge help in this process.

Armeanio · December 20, 2024, 5:36pm

I am a big fan of RGB++ as it opens a completely new field and potential models. Which is awesome, keep innovating. Was in ETHDenver and this was a quite popular topic of discussion.

From a base perspective.

That of a miner… A huge benefit is simply transactions and fees. For dapps in the ecosystem, it creates new channels for liquidity which helps TVL and growth. For projects it is the capacity to grow in market exposure, liquidity and create new community. For the general holder it creates new trade options, potential yield opportunities and markets.

Bridges coexisting create unique opportunities we can use the wBTC/cbBTC pair or various stable coin pairs where LP’s provide liquidity removing an element of impermanent loss and seek yield. We see the same for stable coin pairs.

I will never be one to say this is the one end all be all solution. Every design has pros, cons, and tradeoffs.

Rosen was designed to address friction points Ergo experiences as a UTXO and PoW chain given the current state of the industry. We hope that solution can open doors and opportunities for other chains/communities facing the same obstacles in growth.

Probably the main advantages vs RGB++ is more time related as this is a relatively new solution.

RGB++ was designed to work with UTXOs, but how it will work with Ethereum and other account model based chains is not as straightforward since they do not have UTXOs.
RGB++ follows new standards that may take a while for the industry to fully adopt. Rosen Bridge utilizes existing standards on each destination chain, providing a faster adoption path that doesn’t require any changes.
RGB++ is an emerging technology that it is still being built and iterated on. Adoption and recognition will take time. Rosen Bridge will allow Nervos to immediately begin working with other UTXO Alliance chains and EVM chains and take part in initiatives that benefit all connected communities.

Armeanio · December 20, 2024, 5:40pm

Fiber is something I need to learn more about and become familiar with tbh. Not able to track everything even within the Ergo ecosystem.

Plurality creates hardness and unique opportunities. Which is always a good thing. Diversity of assets and opportunities just create a more healthy ecosystem and economy.

Happy to learn more and see when and where collaboration might make sense.

phroi · December 20, 2024, 6:56pm

Sorry for the delay everyone, some family health issues.

Hey @Armeanio, nice to meet with you!! So sorry to hear, I wish your family to get better soon!

It’s a really interesting design and I personally really appreciate the slide where you document the well known attacks. At the moment I cannot really think of a good way of breaking the Rosen Bridge, even in the event that the RSN price was almost zero. This three level hierarchical division of roles seems really well thought.

Sure, I’d like to help. By now I’m pretty familiar with the tech I used for building iCKB. Surely not enough to cover all the bases for the Rosen Bridge integration, but it’s a starting point.

Some of our community members may still have some reserves on this proposal and we’ll resolve them in this discussion, but generally we are all agree that it’s a very positive sentiment.

After the 25th December you’ll have as much time as you need before initiating the second vote, no need to rush to the second vote with an ineligible/incomplete proposal.

Let’s make together these technical evaluations, analyses and detailed milestones in the context of the Nervos L1 integration before proceeding to the next step.

Love & Peace, Phroi

phroi · December 22, 2024, 4:38pm

I’ll keep adding questions here @Armeanio and, when you are available, feel free to reply to them one by one!!

A) What bridging fees can we expect to be applied? What are the standard fees on the Rosen Bridge?

I heard a 0.5% out of context and took me by surprise.

Changing topic, watchers have two tasks: running a full node of the bridged chain and monitoring on this node for inbound txs. And for this service they are incentivized. That said, running a full node is tedious, error prone and resource intensive. So some watchers may look into the feasibility of taking shortcuts, by using remote nodes. So my second question is:

B) How does the Rosen Bridge protocol make sure that these watcher do not conspire together ending up using a small set of remote full nodes?

As shown this is not some kind of hypothetical thinking as the incentives are not fully aligned. Also, if we additionally assume that Guards can also use the very same subset of nodes, then a bridge hack becomes very real very fast.

Changing topic, Two bridging transaction got stuck. While some glitches are expected from a work-in-progress hierarchical distributed system, we need to understand what’s happening to evaluate your system. So my next question is:

C) Could you please explain what happened with these two txs? Has any new measure been taken to prevent this kind of corner case?

Love & Peace, Phroi

knmo · December 22, 2024, 10:57pm

Sounds like an integration into the fi5box Fullnode device for Lightning and Bitcoin could be useful:
https://fi5box.com/

Armeanio · December 23, 2024, 9:43pm

Every blockchain supported by the guard-service in the bridge has some requirements that are defined in abstract classes and structures in this project.

AbstractChain is an abstract class containing all actions required by guard-service to support a blockchain in rosen-bridge. Each chain requires some actions to communicate with the blockchain APIs to get/send data from/to the blockchain. These actions are defined inAbstractChainNetwork and a single object of it will be initiated in AbstractChain constructor.

Since UTxO-based blockchains require some additional and common actions such as getting boxes (UTxOs), AbstractUtxoChain and AbstractUtxoChainNetwork class are provided too.

Add New Chain

Adding a new chain to the guard-service is being done in two steps and is independent of implementing a required network package.

The first step is to define an abstract network class inheriting AbstractChain (or AbstractUtxoChain if the blockchain is UTxO-based). Based on the implementation of chain class, some network functions may be added to this network class.

// Ergo is an UTxO-based blockchain, so class inherits AbstractUtxoChainNetwork // Abstract<chain_name>Network class AbstractErgoNetwork extends AbstractUtxoChainNetwork { … }

After defining network class, a chain class should be implemented, inheriting AbstractChain (or AbstractUtxoChain if the blockchain is UTxO-based) which implements all required functions. The functions will be explained in the Chain Class Document section. Any required actions found in this step which relates directly to the blockchain network should be added to the network class. Also network variable type should be declared as the network class type.

// Ergo is an UTxO-based blockchain, so class inherits AbstractUtxoChain // <chain_name>Chain class ErgoChain extends AbstractUtxoChain { declare network: ErgoNetwork; … }

Note that implementing chain class is independent of implementing its network class and only its definition is required.

Add New Network

Implementing a network class for a chain can proceed after an abstract network class is defined for that chain. In order to implement a new network, a class inheriting the chain’s network class should be implemented. The functions will be explained in the Network Class Document section. Class name should contain both name of the chain and source of data. For example, in case of Ergo chain and adding a network class to communicate with Explorer, the class will be as follows:

// <chain_name><data_source>Network class ErgoExplorerNetwork extends ErgoNetwork { … }

Note that network class should be developed in a separate package, independent of the chain package.

Chain Class Document

`AbstractChain`

Required functions are as follows:

generatePaymentTransaction
- generates unsigned PaymentTransaction for payment order
- @param eventId the event id
- @param txType transaction type
- @param order the payment order (list of single payments)
- @param unsignedTransactions ongoing unsigned PaymentTransactions which will be used to prevent double spending (gathered from database and guard TxAgreement process)
- @param serializedSignedTransactions the serialized string of ongoing signed transactions which will be used for chaining transactions (gathered from database and mempool)
- @returns the generated PaymentTransaction
getTransactionAssets
- gets input and output assets of a PaymentTransaction
- @param transaction the PaymentTransaction
- @returns an object containing the amount of input and output assets
extractTransactionOrder
- extracts payment order of a PaymentTransaction
- @param transaction the PaymentTransaction
- @returns the transaction payment order (list of single payments)
verifyTransactionFee
- verifies transaction fee for a PaymentTransaction
- @param transaction the PaymentTransaction
- @returns true if the transaction fee is verified
verifyNoTokenBurned
- verifies no token burned in a PaymentTransaction
- @param transaction the PaymentTransaction
- @returns true if no token burned
verifyTransactionExtraConditions
- verifies additional conditions for a PaymentTransaction
- @param transaction the PaymentTransaction
- @returns true if the transaction is verified
- NOTE: This function is implemented in AbstractChain and will return true. In any chain that requires extra check to verify the transaction, this function should be overridden.
verifyEvent
- verifies an event data with its corresponding lock transaction
- @param event the event trigger model
- @param eventSerializedBox the serialized string of the event trigger box
- @param feeConfig minimum fee and rsn ratio config for the event
- @returns true if the event is verified
isTxValid
- checks if a transaction is still valid and can be sent to the network
- @param transaction the transaction
- @returns true if the transaction is still valid
signTransaction
- requests the corresponding signer service to sign the transaction
- @param transaction the transaction
- @param requiredSign the required number of sign
- @returns the signed transaction
getTxConfirmationStatus
- extracts confirmation status for a transaction
- @param transactionId the transaction id
- @param transactionType type of the transaction
- @returns the transaction confirmation status
submitTransaction
- submits a transaction to the blockchain
- @param transaction the transaction
isTxInMempool
- checks if a transaction is in mempool (returns false if the chain has no mempool)
- @param transactionId the transaction id
- @returns true if the transaction is in mempool
getMinimumNativeToken
- gets the minimum amount of native token for transferring asset
- @returns the minimum amount
getRWTToken
- gets the RWT token id
- @returns the RWT token id
PaymentTransactionFromJson
- converts json representation of the payment transaction to PaymentTransaction
- @param jsonString the json representation of the payment transaction
- @returns PaymentTransaction object

`AbstractUtxoChain`

Required functions which only are needed in UTxO-based chains are as follows:

getMempoolBoxMapping
- generates mapping from input box id to serialized string of output box (filtered by address, containing the token)
- @param address the address
- @param tokenId the token id
- @returns a Map from input box id to serialized string of output box
getBoxInfo
- extracts box id and assets of a box
- @param serializedBox the serialized string of the box
- @returns an object containing the box id and assets

Network Class Document

`AbstractChainNetwork`

Required functions are as follows:

getHeight
- gets the blockchain height
- @returns the blockchain height
getTxConfirmation
- gets confirmation for a transaction or -1 if tx is not in the blockchain
- @param transactionId the transaction id
- @returns the transaction confirmation
getAddressAssets
- gets the amount of each asset in an address
- @param address the address
- @returns an object containing the amount of each asset
getBlockTransactionIds
- gets id of all transactions in the given block
- @param blockId the block id
- @returns list of the transaction ids in the block
getBlockInfo
- gets info of the given block
- @param blockId the block id
- @returns an object containing block info (hash, parent hash and height of the block)
getTransaction
- gets a transaction
- @param transactionId the transaction id
- @param blockId the block id
- @returns the serialized string of the transaction
submitTransaction
- submits a transaction
- @param transaction the transaction
getMempoolTransactions
- gets all transactions in mempool (returns empty list if the chain has no mempool)
- @returns list of serialized string of the transactions in mempool

`AbstractUtxoChainNetwork`

Required functions that are only needed in UTxO-based chains are as follows:

getAddressBoxes
- gets confirmed and unspent boxes of an address
- @param address the address
- @param offset
- @param limit
- @returns list of serialized string of the boxes
isBoxUnspentAndValid
- checks if a box is still unspent and valid
- @param boxId the box id
- @returns true if the box is unspent and valid

In our GitHub, you can see previous structures and integrations.

We will need to work with and test the performance of different infrastructure.

Armeanio · December 23, 2024, 10:01pm

.5% is the base fee. You are paying for security across the actor set. Compared to many fees on DEXs, this is reasonable relative to the amount of redundancy created, in my opinion.

I see people trading meme coins at 1-3% fees, paying 2-4% credit card transfer fees without difficulty. There are a lot of list fee’s, and market-making fees that are required to list on exchanges that are hidden from the general public.

It is important to consider it a friction cost for arbitrage for liquidity providers. If the price slips beyond .5% across two markets, the arbitrage potential is profitable. This is not unreasonable to overcome looking at markets.

The Rosen watchers can use infrastructure.

Having multichannel support is important; however, if we try to force distribution across channels, that isn’t realistic. Honestly, a lot depends on the maturity of a chain.

I can use the example of Cardano, where we have services like

https://blockfrost.io/ etc.

I think we can assume as CKB grows and builds, more of this type of infrastructure, options will expand. It will always be something to watch and potentially maintain.

It should always be an open competition. In my opinion, it is impossible to align this forcibly. Infrastructure and even node client diversity should always be an open competition.

Rosen, before launch, was distributed across a global set of open-source developers in the Ergo ecosystem. Manual cold/hot transactions can get hung due to coordination friction. No funds are at risk here; the transaction hasn’t reached the necessary settlement consensus. We are working on an improvement atm.

This is currently under testing. Here are the last network performance stats.

phroi · December 23, 2024, 10:50pm

Hey @Armeanio, thank you for entartaining my curiosity

Very well designed API, let me know if you see any potential issue in the future implementation of a particular method, so that we can discuss it here.

Sure, because it’s the seller who takes the hit and that’s exactly why we are seeing sellers moving from credit card to the (free) instant SEPA in the Eurozone.

On the other side, sometimes in Asia, when you pay by card, you’ll see the seller gently asking you to pay an additional 3-4% to cover those fees.

You are indeed right, centralization is cheap (you just need to run a server), while decentralization is not (see Bitcoin global running costs).

That said, a 0.5% is not a small percentage by any means, which brings to:

Under which conditions tokens/protocols/chains get a rebate on the fee from the base 0.5% to a more sane 0.2%/0.3%?
Are there any listing fees for a new token to be listed on the Rosen Bridge before completion? What about after the completion?
What happens when a new token standard is created on Nervos L1? What listing fees applies for integrating this new hypotethical token standard?

Love & Peace, Phroi

JackyLHH · December 24, 2024, 7:07am

Hi @Armeanio , I personally suggest removing Milestone 1. In other words, $10k to be disbursed immediately upon proposal approval, $35k after the completion of the Testbed Release, and the remaining $35k after the Mainnet Release. The primary reason for this adjustment is that ‘Milestone 1: Technical Assessment and Development Plan’ is not solid enough and not easy to evaluate.

It would be great if you could update the proposal accordingly before submitting it to Metaforo for voting. Thanks.

Merry Christmas and Happy New Year.

Sam_zenGate · January 14, 2025, 6:53am

Hi @phroi - will do my best to answer some of your questions. I’ve worked closely with the Rosen team on several integrations - including Cardano & onboarding of stakepool operators to join as watchers.

Joe had an emergency come up the past few weeks and is getting back into the swing of things these past few days.

Fee Conditions: from what I understand there are some interesting batching related initiatives being created by the community. This would in theory allow multiple submissions to get grouped together to ensure the minimum fee is met for smaller amounts. The beauty of the open-source design of Rosen is that others can also deploy their own instance with a variable fee structure. It is also good to note that the fee sharing system is unique - such that most of the fees collected go back to the infrastructure providers (i.e the watchers; anyone can become a watcher; including you). This has seen huge success on other chains with Cardano Stakepool Operators also acting as watchers for Cardano transactions. I think we will see the same on the Nervos side.
Listing Fees: As Joe mentioned earlier, the fees charged by CEXs for native tokens are extremely expensive. In the near future there will be an initial listing fee to integrate native Nervos tokens - however this will be less than what CEX would charge. One of the main initiatives of Rosen is to ensure value stays within the ecosystem; not get extracted and accumulated by CEXes. The way the bridging fee structure is set up also allows for listing fees to be lower across the board.
We have seen this with the other chains like Cardano where token standards have changed. E.g CIP XXX to CIP YYY. The Rosen Team will be on top of these changes or upgrades as they come; as they have done so with other ecosystems. The goal with this project is to be transparent; both with the open-source of the code, but also with fees (how to pay watchers, charge for the bridge, listing related costs, etc…). This will be made transparent and community discussions will help define how to move forward.

Love & Peace, Sam

phroi · January 16, 2025, 12:16pm

Hey @Sam_zenGate, glad to have you here!!

So sorry to hear, I wish him and his family the best health

You know, the other day I was joking with a friend exactly about this:

Users surely pay big fees to the Rosen Bridge, we may as well get into a position to get best advantage from it

Back to us, replying point by point:

That sounds interesting, could you share some links?

AFAIK change nothing for higher amounts, the 0.5% fee still kicks in.

Sure sure, and that’s more than reasonable, I’m just asking for a quote estimate here.

For example, currently it doesn’t exist, cool, what would the items billed in such a future listing fee?

Would it be possible to bypass this fee by doing ourselves the necessary integration off-chain and on-chain? (Later on relinquishing the control of this integration to the proper entities in the Rosen Bridge)

Glad to hear!! Same as with 2.: right now there is no fee for the integration of a new standard, correct?

Say instead in the future it is added, would it be possible to bypass this fee by doing ourselves the necessary integration off-chain and on-chain?

I’d also like an official reply from @Armeanio on the topic when available: the possibility of making these integrations ourselves (if necessary) is the big difference between a closed system like a CEX and an open system, like possibly the Rosen Bridge.

Love & Peace, Phroi

phroi · March 6, 2025, 8:45am

It has been quite a while since last message. During this time I have kept an eye on Rosen Bridge Telegram Group and I’m very satisfied with what I’m seeing:

The watchers and guards are technically skilled in their roles.
Issues get acknowledged and solved as quickly as materially possible.
The code is evolving at a fast pace to be as standardized as possible.

All in all, I can see that Rosen Bridge is a good model, run in the right way and with a thriving community.

My only doubts were about Rosen Bridge high fees and the abandonment of Rosen Port, the project born from an ErgoHack to make the bridge more accessible for smaller transactions.

Say that the fees were to hamper Rosen Bridge adoption, we are still getting a good deal by effectively raising awareness within the Cardano and Ergo communities about Nervos. Trying to achieve the same with marketing campaigns would cost us millions and have uncertain results. On the other side, this integration cost us comparatively nothing and provides us a new DApp, backed by a strong team & community.

I have no more questions, you have my full support!!

Love & Peace, Phroi