Hi all,
I wanted to share an update on PoS research at ECC.
The most recent event is that I gave this presentation at Zcon4 on TFL. I’d like to share some of the feedback I got in that session and from multiple conversations at Zcon, my reaction to it, what we’ve been up to since then, and what we’re planning next.
Zcon4 Feedback
At Zcon I got two kinds of feedback:
- Could it be better to take an alternative approach where we transition Zcash from pure PoW to pure PoS in one step?
- Does TFL have security flaws, and if so, are they show-stoppers or something we can mitigate by improving the design?
Alternative Approach: A Single Complete Transition
I’ve thought a bit about these suggestions since Zcon4, and mainly about the perceived trade-offs vs a TFL style approach (or any multi-step approach) as well as considering timelines, resources, and the trade-off between considering many alternatives vs making further progress on specific alternatives. You can read more about the trade-offs we’ve identified on this github ticket comment.
The gist of it is that we intend to continue developing TFL for now up until it’s either a viable ZIP-worthy proposal, or until we identify specific blockers. We provide more explanation for this decision in this github ticket comment.
This doesn’t mean we wouldn’t welcome others to flesh out more concrete alternative proposals! If anyone does so, that could be helpful for Zcash.
However, given our limited bandwidth at ECC (especially since we’re currently highly focused on Emergency Mode) our goal is to produce one good specific proposal for everyone to evaluate, so we’ll continue refining the TFL approach.
TFL Security
The second category of feedback on TFL was around security concerns. As you can see in my presentation, there are multiple unresolved considerations to understand the security of TFL.
One thing to keep in mind about security: sometimes security can be more of a continuum of weaker or stronger on some specific continuum. But at the end of the day, what users need is a simple “yes / no” answer to “is it safe enough for my needs?” So we might argue some design is safe enough, even though it doesn’t have maximal security compared to other known alternatives. Any kind of argument about “safe enough” deserves a lot of scrutiny, because it can be extremely hard to know what users’ needs and risk tolerances are, and even when we do, it can be very hard to measure security against that. Nevertheless, we believe the best designs make conscientious trade-offs, and that includes for security considerations. None of this is to suggest we should diminish the Zcash development community’s top-notch record and culture on strong security.
Ok, with that, let’s dig into the primary concern we took out of the Zcon4 feedback about security. While there are multiple ways to frame the concern, a plain English summary goes like this:
Often security is guaranteed by the weakest link in a system. In the TFL design there are two core subsystems: PoW and PoS. So the core concern is: will the security be limited by the weakest guarantees provided by these two subsystems?
And that brings me to what we’ve been focused on since Zcon4:
Progress since Zcon4
All of our PoS research effort since Zcon4 has been focused on two goals: organizing the TFL roadmap and analyzing the “weakest link” security issue above.
If you want to see under the covers of the crude/early roadmap, we’re using github milestones with these two initial milestones:
- Design Phase 1 specifies a simplified subset of TFL more precisely based primarily on Ebb-and-Flow (and odds and ends we’ve picked up from studying Ethereum’s transition and Ghasper protocol). This milestone excludes most of the mechanics of PoS itself.
- Implementation Phase 1 specifies a codebase for simulating attacks. We want to get started on coding early in the design process so that as the design improves we’ll have working, though incomplete, prototypes. As the design matures we hope to have a fully functional testnet.
What’s Next?
We’ll keep posting updates as we go, and we’ll be refining and adding new R&D milestones. ECC will also be publishing more top-level roadmap posts that will give people a higher level understanding of PoS R&D progress (along with all our other efforts), so if you’d prefer the high level of only major milestones, stay tuned for those.