Zcash Elastic Subnet Bridge on Avalanche

ZavaX is good, simple and original

3 Likes

Hello Community! You’re overdue for an update from us. We are still working on Milestone 3, completion date estimate is soon, July 15. Apart from deliverables, I have spent the bulk of my time recently coalition-building around ZavaX. This is a tricky and time-consuming business, and I hope to have some results to report to you soon.

I’m going to work to do more frequent and shorter updates for the community here. We have a two-week sprint pace, so I will try to keep up with that.

At least two of us who have been working on ZavaX will be attending Z|ECC Summit in San Diego next week. We find these in-person events really helpful as we build. Also, for anyone in the New York City area or Northeast US who would like to meet, please reach out!

Re branding, two notes. One is that Avalanche has rebranded subnet as Avalanche L1. Personally, I like it better overall.

Re ZavaX thanks for your comments above. Based on them, we are sticking with ZavaX for the Zcash-Avalanche bridge. The Avalanche L1 on which it resides will be called red·bridge. This is based on feedback from the Avalanche community. (The red·bridge L1 may contain other bridges in the future.)

We can’t wait to complete Milestone 3 and move onto Milestone 4 in which we begin to put it all together!

17 Likes

Hello,

Today we are providing Deliverable 3.1, “A written analysis posted to the forum of whether or not FROST should replace BLS for threshold signature signing, and if so, a redesign of UML diagrams to reflect this change.” Analysis follows. This will also be our update for this sprint.

In our initial design, we had assumed that we would be using BLS threshold signatures in the ZavaX bridge on red·bridge design because BLS was already being used by Avalanchego, the Avalanche node software, and is also used by Ethereum. FROST was also being considered, as it was first brought to my attention as a viable solution by @nathan-at-least at Zcon4.

Since then, after analysis, we have decided to use FROST threshold signatures instead. We have decided to do so for three reasons:

  1. We had been under the impression that because Avalanche used BLS signatures, it also used threshold BLS signatures. We assumed that audited libraries for threshold BLS signing, and signing group creation and maintenance, would already be available to us in Avalanchego. However, after showing the design to people deeply familiar with the Avalanchego codebase, I was informed that this assumption was incorrect. Avalanchego does support BLS, but it does not support threshold BLS. While it would be possible to implement threshold BLS from another codebase, it may not have been audited, and it would introduce another possible attack vector and complexity. Tight integration with Avalanchego was a major selling point for using threshold BLS, and with this not actually possible, other threshold signing options such as FROST looked more appealing.

  2. The Zcash Foundation has created and supports audited FROST libraries specifically for use with Zcash transactions. In our consideration of FROST, we have found the Zcash-FROST development team from ZF extremely accessible and helpful to us. We are a small team, so having support around us as we build is crucial for the bridge’s success. Also, Zcash-FROST was written to integrate with bridges such as ZavaX. It has everything we need for decentralized signature generation and threshold signing. Also, like BLS, it is scalable for our needs, supporting one thousand signature groups easily.

  3. We are funded by the Zcash community through @ZcashGrants, and as such, it makes sense for us to help strengthen Zcash software. The ZavaX bridge will be one of the first implementations of Zcash-FROST and as such can serve as a reference implementation for other projects. We hope this will help to expand the Zcash-FROST user base.

With the decision made to switch to FROST, we revised the ZavaX Bridge architectural documents, and you can find them here. Much thanks to @pacu (also funded by ZCG) for his invaluable help with these revisions. Also thanks to @conradoplg and @nsheep (on Discord) from ZF!

25 Likes

:100: :people_hugging: :+1:

3 Likes

Exciting news, we have finished rebuilding the ZavaX Oracle platform so that it is much more robust and resilient. It now runs on eight hosts of three different types. Reconfigured, it’s much harder to attack. We are testing it now, and as soon as we are done, we will release the results here and on GitHub. We will also release the new architecture, a threat model, and some revisions to the codebase.

All this lays the groundwork needed to build a robust red·bridge as we will use all the lessons learned while building and improving this PoC platform. Can’t wait to get started on the coding!

(We are still making changes and bringing nodes up and down for testing, so you may experience some of this as you try the site.)

Kit

18 Likes

Today we could not be more excited to be shipping Deliverable 3.2 to the community and @ZcashGrants. With this delivery, we complete Milestone 3 for the project.

“Implementation of security best practices to protect ZavaX Oracle subnet, and a report posted to the forum describing our penetration tester’s attempt to stop the ZavaX Oracle subnet from operating.”

This was a cumbersome but necessary deliverable in preparation for deploying a bridge that is both secure and robust. We split the three node ZavaX Oracle network across eight different servers, each with its own role and its own layers of protection. We then performed penetration testing on all servers and adjusted their configuration accordingly until all tests passed. Please see these notes which describe the new platform configuration in detail, and please see this report for the results of our penetration testing.

In other news, we are transitioning away from the name ZavaX to red·bridge. We had wanted to retain ZavaX in addition to red·bridge, but this has proved to be confusing to just about everyone we’ve talked to about the project outside of the Zcash community. Launching a new product is challenging enough without added confusion. We are also changing the staking token ticker from ZAX to RBR. Amazingly, no project has ever used those three letters before!

So the last time you will see “ZavaX” used is with this ZavaX Oracle testnet. Thank you for your service, ZavaX! :saluting_face:

As Josh says, onwards!

Kit

18 Likes

Will this work similarly to how BTC.b does on Avalanche?

Yes. The big difference is that BTC.b is bridged by the authority given to to a small number of Bitcoin-Avalanche bridge wardens, while with red·bridge, up to 1,000 guardians reach consensus on bridging ZEC.z, and anyone with enough of the RBR staking token can become a red·bridge guardian.

1 Like

This is very interesting. :face_with_monocle: i am starting to study Avalanche more… didn’t realize it was capable of all these things…

1 Like

red·bridge ! x.com

Please comment!

5 Likes

Posted in Global Discord + Telegram :+1: