Thank you for the proposal. I like the motivation and idea proposed at a high level but wanted to flag that it may be a more significant undertaking than expected across research, development, and testing. In addition, it is important to note that these changes will likely extend across both pocket-core and the ~2-year-old forked Tendermint codebase, so the developers will need to have an extensive understanding of both.
It’s also worth mentioning that the core team is looking into optimizing some low-hanging fruit (e.g. WRT. storage), though the cost to node runners will still be high until v1 is officially released. Re modifications to the claim/proof lifecycle - this is why V1 is following an “optimistic” approach, but I believe that these changes in V0 will not be trivial.
Concerns
My main points of concern are:
- Implementation: Implementation is non-trivial and could extend well into the v1 development lifecycle, at which point the network operational overhead of having two breaking upgrades may not be worth it.
- Support: This will likely require the support / advisorship of the core protocol team members. Timer permitting, we’d be happy to review documents and answer questions, but our main focus is V1.
- Tokenomics: Assuming all the safety guarantees are met, if significant changes to the core protocol are made, this could impact Pocket’s tokenomics, which would require a lengthier discussion. E.g. the WAGMI discussion alone spanned multiple months.
- Quality Assurance: In addition to the implementation in point (1), I believe testing and quality assurance of the changes would be even more difficult since bugs can’t be simply “patched”. With every minor and major release that has come out in V0, the team builds an extensive plan with lots of testing and has found some critical bugs along the way. As a newer member of the team, I was very impressed by the detailed hundreds of pages used to test some of the recent and upcoming releases.
Suggestion
With that being said, I personally really want to support community contribution and involvement as much as possible. So my suggestion would be to:
- The DAO provides a small grant (e.g. 1%-5%) to fund the research for this proposal. The deliverable for this grant will be a design document and QA plan.
- The community and core protocol team members review and provide feedback on the proposed changes and testing plan. This can help scope the level of changes, highlight missing gaps, and give insight into the feasibility of the proposed design.
- Assuming (2) goes well, the DAO could provide another small grant (e.g. another 1%-5%) to fund the development of a prototype.
- Many issues & challenges are often uncovered in step (3), and timelines change, which can guide the research team as to whether this should be pursued.
- Depending on the outcome of (4), the DAO could provide the remaining funds.
Wins
I think this would be a win-win-win for the following reasons:
- There is the potential upside for lower costs for node runners.
- Even if the project fails is not pursued after the research or prototyping phase, the team will still be compensated for the time.
- The protocol team is very invested in making V1 more contributor-friendly through better tooling, better documentation, a better codebase, and well-defined processes for proposal, submissions and reviews. This could be an excellent opportunity to support, work with and learn from external contributors in the community, which will guide how we can further improve it in V1.