In the OP, I noted the following:
The rationale for bundling multiple updates into Confluence is that completing these updates together in a single protocol upgrade can create a bigger impact than executing the updates separately and because a migration to L2 will require a new contract deployment anyway so we can take advantage of the opportunity to make updates to contracts that would otherwise be more technically difficult to do if we had to upgrade already deployed contracts.
After some consideration, I think it could make sense to exclude the new StakingManager (and thus multi-delegation, improved earnings accounting implementation, etc.) from Confluence and instead consider it as a part of a post-Confluence LIP. The main reason I am suggesting this change is that the new StakingManager would increase the technical scope of Confluence pretty substantially since it would include multi-delegation support as well as a refactored earnings accounting implementation. For a security audit, it will likely need to be treated as a completely new contract which not only increases the surface area for bugs, but also increases the amount of time/effort that should go into the audit. If the focus of Confluence is instead the L1 <> L2 migration then, while there would still be new code introduced, the majority of the already audited code used on L1 could be re-used on L2. As a result, the amount of new code that would need to be audited would be substantially reduced relative to if the new StakingManager is included in Confluence. Of course, the proper steps to make sure the Confluence upgrade is performed security would still be undertaken, but less new code to audit would just reduce the required time for these steps.
With this in mind, the current upcoming milestones I see:
Note: The work for the “Complete Implementation w/ L2”, “Confluence LIP” and “Benchmarking” milestones will occur in parallel since the implementation w/ L2 will inform the final content of the Confluence LIP and will also enable benchmarking.
Complete Implementation w/ L2
The goal here is to complete an implementation that supports:
- L1 <> L2 stake migration
- All protocol transactions on L2 including rewards/fees distribution and probabilistic micropayment ticket redemption
For more details on the above, see this forum post.
One of the most commonly asked questions is which L2 will be used? This milestone will establish the L2 to be used.
While finalizing the L2 to use for Confluence will not occur until sufficient progress is made on the implementation for this milestone, the candidates that will be considered can be narrowed down based on not only their security/performance properties and adoption, but also on the following criteria:
- EVM compatibility. The reason for focusing on this is to support as much developer tooling as possible so that we can reduce the engineering effort and thus time required to access cost savings from L2
- Project roadmap. The reason for focusing on this is to ensure that the L2 used will be continuously improved to continue to bring cost savings for protocol transactions
- Expected level of maturity + amount of production usage by the time Confluence launches. The reason for focusing on this is that while there are a lot of exciting new advancements in the L2 being made consistently, there is a non-trivial chance of outages + breakage in the early days immediately following the beginning of production usage
Given the current L2 landscape and the above criteria, the two main L2s that are being considered closely are Optimism and Arbitrum (and initial prototyping has already occurred with Arbitrum). The main reason that the choice of L2 hasn’t been top priority previously is because extra attention was paid to how the migration process would work and identifying a process that could potentially be re-used in the future to allow the protocol to continue to adapt to the evolving blockchain scaling landscape (meaning that any additional cost savings available in the future can continue to be accessed).
Work here is underway.
Confluence LIP
In order for the Confluence protocol upgrade to be executed, a Confluence LIP must be approved by the community. The first step here is to create a draft LIP. Then, as the implementation is worked on, the content of the LIP will be finalized. From there, the LIP will move through the rest of the LIP process i.e. the Last Call period followed by a poll that orchestrators and delegators can vote in to approve or reject the LIP.
Work here is underway.
Benchmarking
As the implementation is worked on, we should be able to use the gas usage benchmarks for the contracts based on execution on the L2 along with historical gas price data from the L2 mainnet in order to estimate the expected transaction cost for the contracts if they were deployed on the L2 mainnet. The goal will be to re-run benchmarks as implementation continues and share them so that we can get a sense of the transaction cost savings to expect on the L2 even if they are just initial estimates.
Work here to commence soon with some more progress on implementation.
Public Testnet
Once the implementation is feature complete, a public testnet can be launched. This will be an opportunity to thoroughly test the implementation not only via formal test procedures, but also through the open participation of all community members. Once the public testnet is up and running, broadcasters, orchestrators and delegators will be able to test the L1 <> L2 stake migration and also submit L2 transactions in order to become familiar with how everything will work after mainnet launch. As the launch of the public testnet gets closer, there would be additional communication and coordination to support the participation of community members.
Security Audit
As testing occurs on the public testnet, a security audit would be completed for the contracts in order to ensure that user funds are safe for a mainnet launch.
Launch
After sufficient confidence in the security of the implementation is established via the public testnet and security audit, the mainnet launch would occur if the Confluence LIP is approved by the community.