Chainflip Development Update — Oct 21st 2022

Chainflip Development Update — Oct 21st 2022

Hello dear friends. With Halloween fast approaching it’s time for another update from the spooky depths of Chainflip’s development dungeon. Those of you following along closely will be aware that our Perseverance testnet launch has been delayed due to some nasty surprises lurking inside the treacherous black box that is ZeroMQ. But more about this later.

Despite these release-related shenanigans, no fewer than 80 PRs have been merged since the last update. Chainflip is advancing at a frightening pace! Now that’s perseverance for you.

Progress Since Last Update

  • CI has been migrated from Circle CI to Github Actions.
  • We made a first successful end-to-end test of Menorca features, meaning we were able to deposit and withdraw Ethereum to a liquidity provider account.
  • Basic Polkadot transaction encoding is now working on the State Chain.
  • We did a lot of network debugging and built up a stronger understanding of our testnet environments, tools and logging infrastructure.
  • We took the opportunity of the aborted network launch to revamp our release procedure from the ground up.

Outlook

Over the next couple of weeks, our focuses (foci?) will be on getting Perseverance ready for prime-time, and pushing beyond Menorca further in the direction of its larger Balearic cousin, Ibiza.

Here Be Dragons

We were full of hope for our release of the Perseverance testnet, and we know you were too. However we discovered some issues during final testing that could have had a pretty serious impact on our threshold signing ceremonies. Without wanting to get too technical, our new peer-to-peer networking layer that we use for MPC ceremonies relies on a networking framework called zeromq. Zeromq makes a lot of things very easy, but some of its inner workings are little obscure. We discovered that sometimes when nodes restarted, they would be unable to reach the rest of the network. They would merrily keep sending messages, but none of the messages would reach their destination. We added some diagnostic logging, and the problem disappeared. Spooky! Could it be some quantum effect? Predictably, the cause was much more mundane. We discovered that the act of pulling the extra monitoring information out of the connection was enough to “unblock” it. The solution was simple, but the debugging effort took a lot of time, effort and experimentation.

So for now we have successfully exorcised the demons that were causing this particular issue, but ZeroMQ is full of tiny nooks and crevasses where as-yet unencountered dangers could be lying in the shadows, waiting for their moment.

We feel confident enough that the protective sigils we have put in place will hold the ZeroMQ demons at bay for now, but more work is to be done. In parallel, we will also be experimenting with other approaches. There are some rust-native implementations of the QUIC protocol that are showing some promise. Will QUIC prove to be our knight in shining armour? Or is it better the devil you know?

Tune in next time to find out.

MC Method Machine