-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Deliverable] Deploy RLN smart contract to a L2 mainnet #258
Comments
Added an outline for the RLN contract rollout procedure on Linea (testnet, then mainnet). |
Thanks for the breakdown! My interpretation of the next tasks and possible owners (perhaps we can create subissues for each, if you agree)?
Future tasks will then involve the audit, moving to mainnet, upgrading the spec etc. I think we can create issues for these when we get to this point. |
LGTM!
Is this task testnet-only initially, in your view? I'm not sure how much more stringent we need to be with the multisig on testnet as compared to mainnet... |
cc-ing @Ivansete-status for his thoughts but I think this is the plan! |
For testnet I think it makes sense to have a multisig with at least 3 participants, but only requiring a single signature to authorize transactions (to not delay changes on testnet if required). This is to minimize the likelyhood of having to deploy a new contract on the testnet, update nwaku-compose and ask nwaku users to register in this new contract. Such a scenario could arise due to various reasons, including the potential loss of the keys associated with the address that owns the smart contract; the owner of the contract leaving Waku without designating a new owner for the contract, or, unfortunately, unforeseen circumstances such as a serious accident that would stop the owner from setting up a new owner for the contract. |
Thanks for the heads-up @richard-ramos ! In my opinion, the RLN-related work has the lowest priority. I'd vote to start working on that in H2-2025, or at least after we've completed the integration of nwaku in status. wdyt @jm-clius , @fryorcraken ? |
I would say that upgrading nwaku-compose and the registration script to work with the test contract should be priority. We can certainly get help from some researchers, if needed, but note that I'm hopefully referring to a very small task here - pointing to the new contract from nwaku-compose and making sure the registration script can function with this new contract. |
Okay, thanks for clarifying @jm-clius ! If it is a small task we can interleave it with the status-go integration. |
It would be good to also summarize the rights of the owner of the contract for the implementation somewhere (README of contract repo?) so that it's clearly stated when discussing with rest of the org. |
Submitted a PR: |
Roadmap definition
Output
Background
The RLN contract is a key component of Waku architecture, and a new version is currently in development. This upgrade aims to enhance membership management capabilities, as outlined in the specification.
The current RLN contract is deployed only on the Sepolia testnet, but the upgraded version is planned for deployment on a mainnet, specifically Linea, a ZK-rollup.
This document formalizes the RLN contract upgrade process. While motivated by the current upgrade, the outlined steps are general enough to be reused for future upgrades.
The contract rollout procedure involves at least two deployments: first to a testnet, and later to a mainnet. These steps may be repeated as needed based on testing outcomes. The upgrade procedure outlines the minimal necessary steps but can be expanded if required.
Contract Rollout Procedure
1. Setup a Multisig
The contract should not be controlled by a single party. Ownership must eventually be renounced, and, in the meantime, distributed through a multisig contract. Key steps include:
2. Deploy the Contract
3. Upgrade nwaku
4. Upgrade RLN Membership Registration Tools
Modify RLN membership registration tools, such as the
register-rln.sh
script (see nwaku-compose), to reflect the new contract and allow user-specified rate limits. Optionally, extend functionality to support additional contract actions like "extend membership" and "withdraw deposit."5. Test RLN Functionality
Test the upgraded contract using the registration tools, addressing any issues and optimizing for gas efficiency.
6. Transfer Ownership to the Multisig
Transfer contract ownership to the multisig, balancing the timing between sufficient testing and minimizing risks.
7. Upgrade The Waku Network (TWN)
Encourage TWN node operators to upgrade their nodes. Steps include:
8. Review and Audit the Contract
Conduct both internal reviews and external audits throughout the process, especially for the final mainnet version.
9. Update the RLN Contract Specification
As the upgrade reaches mainnet, update the specification to reflect the upgraded mainnet contract. Advance the specification to "draft" status.
Future Work
The following steps may be considered for medium-to-long term after the upgrade is complete.
1. Contract Monitoring
Implement real-time monitoring and alerts for unusual activity.
2. Bug Bounty Program
Launch a bug bounty program to identify and address vulnerabilities.
3. Testnet-TWN Parallel to Mainnet-TWN
The current upgrade will move TWN from a testnet contract on Sepolia (L1) to a mainnet contract on Linea L2.
Consider maintaining a testnet-based Waku network to test future upgrades in a realistic setting.
4. UI-based RLN Membership Tools
Develop a user-friendly interface to manage RLN memberships, displaying key membership data and enabling actions like extending or withdrawing memberships.
The text was updated successfully, but these errors were encountered: