I was wondering about Frost’s current status for the average Joe, and what is the most user-friendly way to use it in Zcash.
4 Likes
Frost for Zcash is largely done and the easiest way to use it currently (until any wallet tools it in) is to follow the ZF demo. I would guess it’s not tooled into any wallets just yet because it only just recently completed it’s audit and all of the other things going on in parallel in the Zcash wallet-developer scene over the past couple months has used up most extra bandwidth.
3 Likes
Participants have to use the command line to use it. I don’t think an average zcash user will do that.
Beyond that, they also need to know how to deploy a server and get a cert. I think that’s very few people.
1 Like
Correct. The demo comms-server is just that (though the current demo overall is a far cry from what is was a year ago) and there’s no guarantee about its contunued uptime but the ZF, who would help, can’t dictate who builds it into their wallet and how.
Initially, the easiest way to do this that I can think of right now would be to use tailcale because talking maximum 3 participants and should be no problem on a tailnet. It might work but I don’t know for sure Otherwise certbot or somethin eq but yeah, that’s trickier.
I also had an idea about wrapping the demo in a tui which doesn’t solve the problem of the command line so much as embraces it lol but then also yeah same questions about deployment though like I said I would investigate tailscale. (I might try it. Maybe a Headscale instance could work. I have yet to dabble with it but if these could be spun up automatically by the users (wallets, ideally I suppose) then maybe could bypass the need for tailscale.)
It’d be good if it didn’t rely on a third-party service for signing. I don’t feel very comfortable with that (could be safe, but it seems to leak timing information).
We have a design for a far more user-friendly Frost implementation for the Zenith wallet that doesn’t require a server to handle key generation or signing ceremonies.
4 Likes
The other current problem with FROST is that there is no specification for key generation, and thus nothing for anyone to reliably implement for interoperability. I raised this as an issue when reviewing the initial ZIP 312 draft, and then opened [ZIP 312] Key generation by str4d · Pull Request #883 · zcash/zips · GitHub as a starting point for specifying it; more progress needs to be made there.
1 Like
Indeed, currently there is no way for the average Zcash user to use FROST in a user-friendly way.
We completed the underlying work to make that happen - the FROST crate itself, and the frost-client and frostd server that help participants communicate which each other.
With that, the only thing missing is integrating with a wallet. However, ZF isn’t going to work on that since we have no expertise with graphical wallets, and it wouldn’t make sense for us to acquire that expertise at this point when we need to focus on zcashd deprecation. Instead, we are expecting some of the wallet maintainers to integrate it (and we’re happy to provide guidance to make that happen)
The server does not need to be trusted, it only helps sending messages back and forth. With our frost-client code, all messages are end-to-end encrypted. The server will learn some metadata (which public keys are talking to which public keys at what time - which can be mitigated with e.g. tor) but is not able to break privacy. Also, there is no reason for each person to run their own server. It’s very similar to lightwalletd. In fact, lightwalletd requires much more trust than frostd.
If wallet developers for some reason don’t want to deploy their own frostd servers we can always look into deploying a production frostd. (We have a development deployment already)
Regarding the possible timing leak, please report it so we can take a look.
This has been blocked since Aug 14 where I added some sketches on possible approaches to do it and I’m waiting for feedback since then. Apparently now it’s also blocked on post-quantum resistance where I’m also waiting for the design to be ready.
I also believe that a key generation for ZIP would be great but it’s not a blocker. It’s better to have something working that is not “interoperable” then to block for ages on the perfect interoperability solution.
That being said, I’ll update it and will start bugging the ZIP editors to review it 
6 Likes
I just don’t think there needs to be a central server at all when Zcash is perfectly capable of transmitting encrypted messages.
- Using Zcash for message sending is slow. FROST can run in a couple of seconds, if we use the blockchain then the it would take ~5 minutes
- Using Zcash for message sending is wasteful. The ephemeral encrypted data will be stored in the blockchain forever when there is absolutely no need to
- Using Zcash for message sending is awkward. Each participant would require a separate Zcash wallet account, only used for communication, in order to setup a FROST wallet account, which would create super confusing UX flows and make backups even more difficult
If we had a P2P communication layer running on the Zcash nodes without storing data in the blockchain, as has been suggested for other user cases, it would be great. But that does not exist yet.
1 Like
It’s not ideal, I agree. But personally, I’d prefer this solution rather than connecting to a server run by a third party for signing my transactions. The fact that TOR would be needed to avoid linking IP to signers is not a great story.
1 Like
I disagree. It’s not a lot of time; I can write the spec in the next 2 days. The delay since Aug 14 is not at all due to that. Most of it is due to not even knowing that it was waiting for review.
The quantum resilience piece is just this suggestion consisting of one extra paragraph. The analysis is complicated but the change to that ZIP absolutely is not.
Please note: I do not review draft PRs. Marked as draft means, to me, “not ready for review yet”. I didn’t know that a different convention was being used for this PR.
4 Likes
You would need Tor anyway to access lightwalletd if you want full security. Why is it not a “great story”?
The server may not be ideal but it’s a good enough first step for a lot of people. The ideal solution would require some P2P mechanism which we eventually want to look into.
Regardless, if you think using Zcash for communication is the way to go, then go ahead. My point is that ZF completed what it set out to do and wallet developers are not blocked by us.
Well, I don’t know what the ZF set out to do. Also, wallet developers were never blocked by the ZF since they could use other implementations or implement the Frost protocol themselves.
My question was about how usable Frost implementations are today for Zcash users.