RFC 12 Implementation: Proposal generation #3747
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This move is meant to reflect the fact that wallet maintainer is no longer a thing and, we want to make proposal generator a standalone module that will be used by `pkg/tbtc`. By the way, we are also cleaning up proposal-related commands from the maintainer-cli.
Here we implement the core logic of the proposal generator. Specific proposal tasks will be added in the follow-up changesets.
Here we inject the `tbtcpg.ProposalGenerator` to the `tbtc.node` component.
Here we introduce the implementation of the `tbtcpg.proposalTask` for deposit sweeps.
Here we introduce the implementation of the `tbtcpg.proposalTask` for redemptions.
Here we adjust the tasks code to the current requirements. Redemptions and deposits are now fetched for specific wallet. There is no need to maintain the possibility to do so for multiple wallets in the same time. Because of that, we are simplifying the code. By the way, we are adjusting logging and tests.
Some proposals may need some additional data about the wallet (e.g. moving funds). Here we are trying to satisfy them by introducing a `CoordinationProposalRequest` type that is used to feed the generator with necessary data.
tomaszslabon
approved these changes
Dec 4, 2023
tomaszslabon
added a commit
that referenced
this pull request
Dec 5, 2023
Refs: keep-network/tbtc-v2#737 Depends on: #3747 Here we present the fourth part of the changes meant to implement [RFC 12: Decentralized wallet coordination](https://github.com/keep-network/tbtc-v2/blob/main/docs/rfc/rfc-12.adoc) in the tBTC wallet client. This pull request focuses on the coordination result processing. ### Result processor Here we implement the `processCoordinationResult` function that receives coordination results, detects the proposal type, and triggers the appropriate proposal handler exposed by the `node` component. This function also sets up the proposal processing start block (i.e. coordination window end block) and the proposal expiry block. ### Detach `WalletCoordinator` event handlers Due to the above changes, from now on, the `node` component fires wallet actions based on incoming coordination results. The `node` component no longer listens for events coming from the `WalletCoordinator` contract. We are taking the opportunity and remove those handlers along with the auxiliary code (e.g. events deduplication). ### Next steps The next steps on the way towards RFC 12 implementation are: - Write `WalletProposalValidator` contract and integrate it with the client - Cleanup `WalletCoordinator` leftovers in the client - Modify the SPV maintainter to not rely on `WalletCoordinator`'s events during unproven transactions lookup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refs: keep-network/tbtc-v2#737
Depends on: #3745
Here we present the third part of the changes meant to implement RFC 12: Decentralized wallet coordination in the tBTC wallet client. This pull request focuses on proposal generation.
Remove wallet coordination from the maintainer module
So far, the maintainer bot implemented in the
pkg/maintainerpackage was responsible for wallet coordination. The logic was living in thepkg/maintainer/walletsub-package. As the maintainer bot is no longer responsible for wallet coordination, we are detaching the wallet coordination from there. This has also an impact on the maintainer-cli. Commands responsible for deposit sweep and redemption proposal submission are no longer available.Move code from
pkg/maintainer/walletpackage topkg/tbtcpgAlthough the maintainer no longer uses the wallet coordination code, that code is still useful for the new coordination mechanism. It contains the logic necessary to produce coordination proposals. Hence, we moved it to the new
pkg/tbtcpgpackage and exposed an entry point componentProposalGeneratorthat implements thetbtc.CoordinationProposalGeneratorinterface. Thanks to that, thepkg/tbtcpackage can use the code frompkg/tbtcpgto generate coordination proposals.Ideally, the code from
pkg/tbtcpgshould be embedded intopkg/tbtc. However, both packages are not compatible out of the box. Merging them would require a lot of breaking changes. As RFC 12 implementation is already a complex task, we decided to keeppkg/tbtcpgas a separate being for now, to reduce risk.Last but not least, the code in
pkg/tbtcpgwas simplified. This code no longer needs to handle proposals for multiple wallets at the same time so focusing on a single wallet allowed us to remove redundant code and facilitate further maintenance.Wire up
pkg/tbtcpgpackage topkg/tbtcAs mentioned in the previous section, the
pkg/tbtcpgimplements thetbtc.CoordinationProposalGeneratorinterface so it can be used to generate proposals within the new coordination mechanism. This was achieved by injecting thetbtcpg.ProposalGeneratoras a dependency totbtc.node, during the setup process.Next steps
The next steps on the way towards RFC 12 implementation are:
processCoordinationResultfunction and refactornode's handlers appropriately)WalletCoordinator's events handlers and remove unnecessary code fromchain.go)WalletCoordinator's events during unproven transactions lookup