Migration to MCD for xDai bridge

@phahulin thanks for update!

I have tagged new release 1.1.0 for the TokenBridge. It contains changes addressing the issues you found during recent testing and it means that it can be used to upgrade the xDai bridge validators.

LGTM. Well done!

These methods are in the Proxy contract rather than in the implementation. The ABI can be found here

Great news!

Quite interesting to see any feedback from validators after this tool usage. We planed to have similar as part of the TokenBridge UI but more customised for the TokenBridge use cases.

@ttk2 thanks for question! Currently we plan to upgrade the token bridge contracts (with support of Phase 1) on both sides of the xDai bridge on the next Tuesday (official MCD launch is Monday, 4 PM UTC). As soon as the bridge validators communicate to invoke migrateToMCD and collect signatures for actual method call (the plan is to do this on Tuesday) the xDai bridge will not relay deposits of SCD tokens. The deposit operation will be supported only for MCD tokens.

The xDai bridge contracts addresses will not be changed since the contracts were implemented to be upgradable.

Support of SCD will be added later when the corresponding changes will be ready for the contracts, oracle, monitor and UI. The current vision that it could be done in the middle of December.

I’m afraid I don’t understand the logic here, if backwards compatibility is a priority why not avoid breaking applications that need it for a month? It seems the only value of adding SCD support is that hopefully old applications will keep working. If you just want to clean out SCD that is sent to the new bridge you could simply add a automatic return or some other much easier handler.

It seems to me that most users of backwards compatibility won’t be able to accept a month downtime, so they will upgrade, and by the time backwards compatibility is available it won’t be used much.

I guess this is being done to meet the banner date?

Breaking compatibility with several day’s notice is insane. I can only come to the conclusion that you don’t think that anyone uses xDAI (or maybe just once a year for tacos at a crypto conference). We have about 50 real users on our network depending on xDAI for their internet access. I would strongly urge you to not change anything until you have the backwards compatibility working.

And where is the public announcement? The only warning we had is this thread where you are discussing some minute details on code. Where is the communication for people depending on this chain?

I asked about this here last month, and you guys said nothing: How wil xDai deal with the MCD switchover?

Maybe I’m mistaken- are you seriously planning to break your platform for existing users next Tuesday?

And where is the public announcement?

this thread is basically the public announcement and discussion platform

We have about 50 real users on our network depending on xDAI for their internet access.

that’s cool. I would be happy to add it as a use case https://www.xdaichain.com/about-xdai/use-cases for xDai and promote it. Or you can submit a PR yourself here https://github.com/xdaichain/site/tree/master/about-xdai/use-cases

Breaking compatibility with several day’s notice is insane.

What is the problem on your side to upgrade to MCDai? I would like to learn more.

We have about 50 real users on our network depending on xDAI for their internet access.

xDai and xDai chain will stay the same. The only difference will be on the Ethereum side.

1 Like

Sort of like how blockchain code isn’t just ‘rolled out’ without significant testing and vetting firmware releases also take some time. Since we have a network of routers paying each other for internet if one node fails the nodes behind it go offline. That’s not a risk you can take with someone’s internet service. Where at least 99.9% uptime is expected if not more.

We have automated uniswap so that the users deposit eth or dai into the router and it becomes xdai. Kinda of like burner wallet but living in someone’s home wifi router and totally automated. Users deposit when their balances are low, which could be any time, if they can’t deposit their service is cut off and everything starts to grind to a halt.

Upgrading to MCD won’t take more than changing a few variables and pushing a firmware update, something we do every month or so anyways. But since the bridge will go from SCD only to MCD only support overnight it essentially guarantees that there will be downtime during which users can not deposit or withdraw funds.

Coordinating our firmware updates to exactly match your banner day update is a very fragile process and not worth the risk. Sort of like if I said you had to deploy your smart contracts on an arbitrary day decided by me you’d probably refuse to skip auditing to meet it.

The backwards compatibility solution described by @akolotov is well thought out and would allow developers in general (not just us) to upgrade bridge applications on separate timelines. It’s the correct approach for a high availability service.

If I had not happened to ask about the deployment date this could have gone very differently. Clear top of line announcements of potentially breaking changes are the minimum for someone providing an API they intended to be used by many people.

This thread has been live for well over two weeks, not to mention the older, ongoing Github discussions and posts. Your team seems to be using the xDai bridge and and stable chain without accreditation, notifying the POA Network DevTeam of your involvement or reliance on the xDai Bridge or xDai chain.

Unintentional or not, posts on your site seem to claim authorship of the bridge, discuss deploying a new blockchain on Cosmos or a cosmos derivative, working directly with MakerDao (not xDai), etc. I seen no acknowledgment or credit to POA Network and its development team for use of its software. As mentioned in thread above, to provide public awareness, bidirectional feedback and acknowledgement of development by and support of the POA Network team, please consider adding your use case to the xDai website and GitHub at the following link:

https://github.com/xdaichain/site/tree/master/about-xdai/use-cases

Open Source software drives the distributed community and tend to foster known use cases, for some xDai examples here:

https://www.xdaichain.com/about-xdai/use-cases

Without acknowledgement, feedback, and contribution, great Open Source projects like those developed and maintained by POA Network will not be aware of or benefit from outside use. Make sure to join the community, contribute and participate!

@1proof Let me just clear some things up. We are using xDai since the Cosmos Ethereum bridge is not ready yet. So in this sense, we are a temporary user of xDai, and so perhaps lower value. We also have not paid POA any money, don’t have an SLA, and so can’t really complain about anything they do. My harsh tone above was perhaps unwarranted, but was more just incredulity that a breaking change would be rolled out in such a cavalier manner.

I also think that it’s not entirely POA’s fault. Maker did this poorly thought out renaming which has kind of forced POA’s hand. If Maker were to have called MCD “Mai” or something else, then I bet you’d be spinning up a whole separate “xMai” chain right now and there would be no problem.

Please direct me to any posts which “claim authorship of the bridge” and I will correct them.

The problem is that our routers use a 2 step process to turn Eth (which is easy to buy) into xDai and back again. So there is an automated process which turns Eth in the router’s address to “Sai” by sending it to Uniswap, then sends the Sai to the xDai bridge to be brought over onto xDai. When people withdraw money, the reverse process happens.

What breaks it is that the new bridge will not accept Sai any longer. The Sai sent to the bridge is just going to disappear until you roll out the backwards compatibility in a month.

If you waited to do this switchover until your backwards compatibility was working, there would be absolutely no problem. As @ttk2 said, the backwards compatibility design is good.

I imagine your hand is being forced on the early roll out by Maker’s poorly thought out renaming decision.

I’ve posted update guide in the neighboring thread

1 Like

We are waiting for the audit of the bridge. It is very unlikely that migration will happen this week. I expect it at the end of next week.

Hey, we were wondering if we should switch our stuff back to xDai. What is the upgrade plan exactly? Will you be upgrading to McDai without Sai backwards compatibility at the end of the week?

Will you be upgrading to McDai without Sai backwards compatibility at the end of the week?

The audit will end at the end of next week. We will post updates in this thread regarding timelines.

Hey, we were wondering if we should switch our stuff back to xDai.

The network is technically xSai now. It’s working as it worked before the migration.

2 Likes

Thanks! And sorry for my rude tone on Friday.

1 Like

I have made finalization in the initial description for contract changes related to the phase 2 of migration. The next step describes changes on the oracle and the monitor sides.

2 Likes

Will you post here before the migration happens?

Yes, no plans at the moment in foreseeable future. We are waiting for the security audit for Phase one and Phase two.

Everyone could join to code review of changes needed for the phase 2 of the migration:

1 Like

When is the migration going to happen?