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.