Here’s an update about what we’ve been doing recently building red·bridge. We’ve updated our milestones based on the new support from Avalanche Foundation’s InfraBUIDL() program. They are:
- Demo Bridge with Functional UX
- Threat Model for ZavaX Oracle Revisions after Review
- ACP-77 Architecture Revisions
- ZCG Milestone 4 “Support for bridging ZEC to ZEC.rbr in both directions on testnets, with a one-validator Subnet, to C-Chain (assuming supported) or Subnet, and UX and UI design for GUI completed.”
- ZCG Milestone 5 “Fully functional deployment to Zcash and Avalanche testnets, with a 3-validator Subnet, with CLI support.”
- Threat Model for Bridge Reviewed
- ZCG Milestone 6 “GUI: bridge integration into Metamask, and publishing of the source code to a public Github repo.”
- First Audit (Least Authority)
- First Audit Fixes
- Second Audit (Halborn or other well-regarded auditor)
- Second Audit Fixes
- Incentivized Testnet (with RBR rewards)
We completed Demo Bridge with Functional UX a month back and even have some enhancements which we will announce soon. Next up are these three, which we are working on concurrently:
- Threat Model for ZavaX Oracle Revisions after Review
- ACP-77 Architecture Revisions
- ZCG Milestone 4 “Support for bridging ZEC to ZEC.rbr in both directions on testnets, with a one-validator Subnet, to C-Chain (assuming supported) or Subnet, and UX and UI design for GUI completed.”
For (1), we are in the middle of an audit of a threat model we have written up for our proof-of-concept ZavaX Oracle, a permissioned blockchain that runs on the Avalanche Fuji testnet. We have received initial feedback from Least Authority and are making a round of revisions to the threat model before asking them for more feedback.
For (2), we are working on these revisions. The biggest challenge is that Avalanche ACP-77 is so new that the documentation for it is not as thorough as one might wish. Also, the group of people who know the answers to our questions is small and stretched thin, so getting answers at times is slow and difficult. Once we get the answers we need, the actual changes should not be substantial, but it’s important that we do them exactly right.
For (3), we are working on building a PoC for using Avalanche’s ICM (inter-chain messaging protocol). Again, because we are working on brand new tech, we are facing similar challenges as with (2). For instance, Avalanche has created documentation on ICM, but it focuses on L1-to-L1 messaging where both L1s are running a fork of the EVM (Ethereum Virtual Machine). However, we are building an L1 with a custom VM, and the only documentation on messaging with custom VMs is very old and vague.
Our team has experience writing documentation for undocumented systems. Indeed, we won awards from Avalanche for helping to document an early version of L1s, called subnets. We will propose to AF to write some documentation as an additional milestone if no one else is going to do it. While this could push our schedule back a month, it is necessary to gather this information to proceed.
(3) is by far the most challenging milestone because our success is dependent on even more new tech. We have not even dug deep into FROST integration, for instance. It should work (and we’ve had excellent support from the FROST team) but FROST is brand new as well, and the devil is in the details.
Thanks for reading!