# ECC R&D and Engineering Flight Plan **URL:** \ **Category:** General\ **Created:** [November 22, 2019, 9:29pm UTC](https://forum.zcashcommunity.com/t/ecc-r-d-and-engineering-flight-plan/35483 "2019-11-22T21:29:05Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![tromer](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/tromer/32/14860_2.png) [@tromer](https://forum.zcashcommunity.com/u/tromer)\ **Post date:** [November 22, 2019, 10:46pm UTC](https://forum.zcashcommunity.com/t/ecc-r-d-and-engineering-flight-plan/35483/2 "2019-11-22T22:46:13Z")
Thanks @nathan-at-least, and everyone who supported him, for preparing this plan! It’s solid, well-thought-out, well-presented and the short-term objectives are extremely compelling. I particularly like the multi-scale approach, the rationale given for every objective, and the explicit success indicators. Reading through this, I have some comments/suggestions/questions: * * * While Horizon 1 is beautifully worked out, **Horizons 2 and 3 are very blurry**. In particular, the discussion of Horizon 2 (which starts just 6 months from now) is mostly about what _other_ teams will do, and says little about ECC’s objectives and tasks during these 18 months. Especially with the Dev Fund question on the table, I think more clarity is needed on what ECC will be up to in the upcoming _years_. * * * Where do **user-defined assets and programmability** fit into the picture? They’re clearly excluded from Horizon 1, but are they envisioned to happen later on? When does ECC even start researching them in earnest? * * * It would have been helpful to get some quantitative indication of the **quantity of effort** each objective requires, especially as one balances these objectives against other potential ones. Likewise, it would be helpful to explicitly call our **risk factors** , such as “research required” or external dependencies. * * * On _Mobile wallet SDK improvements_, it’s unclear what’s the **scope of the mobile wallet SDK** , and what functionality still needs to be developed. I love the plan to develop a functional **“dogfood” shielded ZEC wallet**! We learned so much from the Zcon1 prototype, and it feels that doing a real mainnet wallet is going to be huge, both in stress-testing the SDK functionality and in getting feedback on shielded tech usability. * * * On _Viewing key support_: yay! What about the per-transaction **payment disclosures** (as we used to have in Sprout, in addition to the per-private-key viewing keys)? * * * On _Community-driven protocol development_, you say: > - Zcash Foundation and at least two of the four other participating development organizations publicly endorse the new process I’m curious, who are **“the four other participating development organizations”**? * * * > - ECC publishes a new version of the Halo paper with optimizations and performance benchmarks How about **finishing the Halo paper** by making clear security claims, and providing security proofs? And adding missing features like zero knowledge? To the execution success criteria, I would add “the Halo paper is accepted for publication in a high-tier peer-reviewed academic venue”. Also, what about research and communication on **how to use Halo** in Zcash? We’ve seen how Halo can be used to verify PoW (which is a relatively easy application which doesn’t even need ZK). But AFAIK nothing’s been said about how Halo would be used to verify _transactions_. Because Halo not succinct in the efficient-verifier sense, it’s not a drop-in replacement zk-SNARK; rather, it would need some new application-layer protocols to exploit its amortized verification using recursive composition. Similarly, without pertinent application-level protocols, we don’t know if Halo is helpful for achieving _scalability_. It sure feels it is, because we know from Coda that recursive compositions helps many aspects of scalability, but more concrete planning is needed here. * * * Also on Scalability 2021, this strategic success indicator worries me: > - Zcash’s Scalability 2021 effort is referenced in one or more high-quality industry reports about scalability **Being referenced in a report** is not a good goal to set for the engineering flight plan. To put it bluntly, if _all_ that’s done for Scalability 2021 by the end of Horizon 1 is what you set out to do as the execution success criteria, i.e., you never get around to designing the application-level-protocol connection between Halo and scalable Zcash, then no one _should_ believe you’ve made any progress towards Scalability 2021. So if some reporter or industry evaluator is nonetheless fooled into thinking otherwise, I don’t consider it an indication of success for the engineering flight plan. * * * Well that’s all for now… Thanks again for the deep thinking and excellent presentation, and for pushing the bar on technical plan transparency in our ecosystem. Looking forward to the ongoing discussion! --- _[View the full topic](https://forum.zcashcommunity.com/t/ecc-r-d-and-engineering-flight-plan/35483)._