-
Notifications
You must be signed in to change notification settings - Fork 3
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
RCP-240814A: Generalized Wallet Persistence in bp-wallet #11
Comments
We have to be careful when using I hope I helped. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
Bitlight is proposing a flexible and customizable storage solution for its wallet implementation, which can be integrated with various storage backends, including but not limited to FS. Previously, the project relied on two key functions in
bp-wallet
:BpWallet::detach
(to extract the internal wallet structure) andBpWallet::restore
(to restore the wallet from a stored state).Problem
With the removal of the
BpWallet::detach
andBpWallet::restore
APIs in the Beta7 release ofbp-wallet
, there is a need for a more generalized and versatile approach to wallet storage and recovery. This would provide downstream development projects with a seamless transition and an effective alternative for implementing their storage solutions.Proposal Goal
This RFC proposes a new design pattern for
bp-wallet
that provides a generalized and extensible persistence interface. This design will offer a standard interface for downstream projects to implement custom storage backends, while also ensuring high performance and compatibility with existing projects. The proposed design will maintain synchronous APIs to avoid breaking changes, while still allowing for asynchronous storage operations internally.Additional Notes
Since there is currently no RFC submission process available under the bp-wg organization, this proposal is being submitted under the rgb-wg organization. If needed, I am fully prepared to adjust the proposal's placement and design according to your guidance.
Next Steps
Once we have reached an agreement on the approach, the Bitlight team is prepared to assist in developing and implementing this proposal within
bp-wallet
.Wallet Persistence Design Document
Initial Consideration
The initial plan was to implement all APIs asynchronously. However, making the persistence operations asynchronous would require significant changes to the existing codebase, as all public APIs in
bp-wallet
are currently synchronous. Converting these APIs to asynchronous would introduce a substantial breaking change, especially since persistence operations are typically triggered during the execution of public APIs or when an object is dropped.For downstream developers, it's crucial that
bp-wallet
can automatically persist wallet data during runtime using a user-defined storage mechanism, without requiring explicit calls todetach
for saving internal fields.To avoid extensive refactoring and maintain the synchronous nature of the current APIs, this proposal outlines two synchronous persistence design approaches for the
Wallet
structure.Tip: If asynchronous storage is required (e.g., for S3), user can use
block_on
or similar methods within theStoreProvider
synchronous API to execute asynchronous operations, thereby achieving asynchronous persistence without altering the public APIs.Approach 1: Unified
StoreProvider
Synchronous API DesignDesign Overview
In the first approach, a unified
StoreProvider
trait is used to handle the persistence of all parts of theWallet
. This design centralizes all storage operations within a single trait, wherebp-wallet
serializes the data as strings or bytes before passing it to theStoreProvider
. Users only need to implement the storage logic.StoreProvider
TraitWallet
Structure and MethodsWallet
: TheStoreProvider
interface is used to load descriptions, data, cache, and Layer 2 data, which are then deserialized.Wallet
: Thesave
method serializes each component of theWallet
and stores them using theStoreProvider
if thedirty
flag is set totrue
.Wallet
automatically saves itself when dropped if thedirty
flag istrue
.Advantages
StoreProvider
interface, simplifying the API design.StoreProvider
trait.Approach 2: Multiple
StoreProvider
Synchronous API DesignDesign Overview
The second approach is more flexible, allowing each component of the
Wallet
(such as descriptions, data, cache, and Layer 2 data) to use separateStoreProvider
implementations. This enables different storage strategies for each component. This design was inspired a lot by your PR, thank you so much for exploring.StoreProvider
TraitWallet
Structure and MethodsWallet
: Each part of theWallet
is loaded using its correspondingStoreProvider
.Wallet
: Thesave
method saves each part of theWallet
using its respectiveStoreProvider
if thedirty
flag is set totrue
.Wallet
automatically saves itself when dropped if thedirty
flag istrue
.Advantages
Wallet
.StoreProvider
traits for different components as needed.Comparison and Selection
Conclusion
Both designs maintain the synchronous API nature, avoiding large-scale refactoring of the existing codebase. The choice of which design to adopt depends on the specific requirements of the use case. If the application needs to handle different storage strategies for various parts of the
Wallet
, the second design is more suitable. Otherwise, the first design offers sufficient flexibility with simpler implementation.Tip: For scenarios requiring asynchronous storage (such as S3),
block_on
or similar techniques can be employed within the synchronousStoreProvider
API to perform asynchronous operations, thus achieving asynchronous persistence without modifying the public APIs.Mock Code Examples (Draft Version)
Approach 1
Approach 2
This RFC outlines the problem, proposes two different approaches for the solution, and provides example code to illustrate each design. The goal is to allow
bp-wallet
to offer a generalized, customizable, and efficient persistence solution that supports various backend storage options without requiring significant changes to existing APIs.The text was updated successfully, but these errors were encountered: