In my eyes it couldn’t be less tricky, let’s walk together thru this:
Let’s assume that we are in the future where CommunityDAO X exists and it is fully on-chain. By voting on-chain, CommunityDAO members can directly unlock a community lock, which hold Common Knowledge Assets.
Back to us, CommunityDAO v2 exists and it is mostly off-chain. By voting off-chain, CommunityDAO members signal their decision to the Top Representatives. Representatives, by unlocking the community lock (which hold Common Knowledge Assets), materialize such decisions.
Where is the trickiness?
Common Knowledge Assets can be any kind of cell, ranging from simple CKB capacity cells to Script Binaries, it makes no difference for the lock on the cells.
For sure a multisig in the short term, as per RFC. Once we move to on-chain voting, we can easily upgrade the lock logic.
Side Note: I’d like to point out that if such a mechanism existed, iCKB would likely be deployed by type with such a lock, so this is a need already felt by the Community.
Open-source development in conjunction with this mechanism is what will transition Common Knowledge Base from a name to a fact.
Maintaining a competitive edge is necessary in business, and being a closed source is a way of protecting that. Good projects will turn down a grant if there is a restriction that they view as a hindrance to their success.
To work around this, there are several things I put into the DAO soft rules:
Public funding implies public code. Every project that received grant funding must agree to open source the Nervos-specific portions of the project. This is typically smart contract code and transaction generation code. It does not include the project’s complete code base.
Many projects have already shown they are willing to open-source smart contract code since this is a relatively common practice in other ecosystems. This rule goes a step further to also require the transaction generation code, which is a stronger need with the Cell Model. While this is not the full project, this will help us to continue building up our public code base of reference code, while also helping to ensure accountability and security of the smart contract code itself.
Projects that receive grant funding in excess of $50,000 USD must agree to provide a reasonable means for the Nervos community to persist the project if the team chooses to abandon it. In most cases, the most simple way to accomplish this is to transfer the full source code and all relevant data, accounts, and rights, to a community team that can take over the operation of the project. If a suitable team cannot be found, the project must be open-sourced completely.
This rule is aimed to directly address the problems we have had with the recovery of abandoned projects. I see this as being a harder sell to teams, but they may be willing to accept this on the basis that failure is not their intended goal.
For projects that have reasons that they will not agree to these terms, special exceptions can be made. These rules are being put in as soft rules specifically because they can be overturned by community vote.
I agree with the general concept of a community-owned upgradeable smart contract. However, there are a lot of considerations around this. It adds additional process and overhead and requires solutions that we don’t readily have answers for. This would be a good topic for further research and public debate.
Who owns the contracts? It is too easy to simply say “the community”. A more meaningful answer needs to address who is responsible for the continued operation of the contracts and the off-chain components needed to use them.
Who can update the contracts? Not who controls the ability to update, but who can submit the update itself? A lot of knowledge may be required to do an update properly. There are always considerations around security and compatibility, but also around the general design and intent of the contract. If the original author is gone, so is all the peripheral knowledge of the project. It can be very difficult to find someone who understands the project well enough to keep it moving in the right direction.
What are the eligibility requirements? Assurance requires redundancy and inherently creates a need for more processes that can easily become cumbersome and eventually cost-ineffective. We have to define the exact criteria of what contracts justify the higher cost and inefficiency of such a process, as well as what the criteria are to transfer it back to private ownership again or retire it permanently.
I just want to say that everything that is developed now and in the future must use PQC. NIST-approved FIPS 205 (formerly SPHINCS+) like the Quantum-Purse wallet
using post quantum cryptography as a standard today is impractical and unnecessary. Elliptic curve cryptography has 5-10 years of shelf life left, it should be used when appropriate.
Post quantum cryptography is a great choice for anyone storing CKB over the long term, but for other uses cases, alternatives should be considered.
The period of time you mention here is very short compared to the expected time that CKB still has ahead of it. Serious new developments should be designed with ten or fifteen years ahead of them.
Practical everyday applications have already implemented PQC, or a hybrid solution. For example, the messenger SimpleX and the email provider Tuta.
Votes for the government are done after a relatively short period of time, but during this time great damage could be done by exploiting vulnerabilities of untimely encryption. This can be particularly damaging to the reputation and credibility of the system or the industry as a whole.
There will be a public discussion of the Community Fund DAO v2 proposal later today (9pm UTC, 5pm EDT, 2pm PST). I invite anyone who is interested in this to attend and offer their insights. There will be another discussion organised to cater for community based in CST.
Anything related to the proposal is up for discussion, although there will be focus on the following aspects:
Following on from this Space, there is another planned public discussion later today (9pm UTC, 5pm EDT, 2pm PST) to discuss the following topics related to the proposal:
Grant budgets and team autonomy
Voting power rules
Down payment policies
As before, I invite anyone interested in this to tune in. If you have thoughts or insight into these topics then that too is most welcome.
Part 3 of the community discussion around CKB Community Fund DAO v2 is happening later today (9pm UTC, 5pm EDT, 2pm PST) to discuss the following topics related to the proposal:
How to attract more DAO applicants
Incentives for early participation (part 2)
Policies on adjusting grant amounts after commencement
Once again, I invite anyone interested in this to tune in. If you have thoughts or insight into these topics then that too is most welcome.
Okay after reviewing palmyra and my own broader considerations to funding and CKB as a whole. it’s of my observation that CKB is at the pinnacle of blockchain technology. Most of the projects that i would argue have maintained success at this point have been able to showcase these aspects-- Joyid, RGB++ etc… and the one’s that haven’t have simply fallen off. Now just because we have funds doesn’t necessarily mean we need to be using them. It’s very easy to waist money, I propose we weigh quality over quantity and focus on projects that are guided to us from our leading tech’s like Jan, cypher that has a better idea of the big picture of CKB and how this potential project can benefit not only the ecosystem as a whole but more importantly where the ecosystem is going. I realize this means funding far less projects but with this approach we can more greatly support the one’s that we are. I am English but i am also prudent and i share some of the sentiments I have been hearing from the Chinese CKB community. As the ecosystem Develops people will naturally come to want to build on CKB and they will do so without funding. For now due to the reasons i have highlighted its my opinion that cutting the fat and having a more exclusive approach to funding will be more beneficial
I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times