docs: ADR-071 Bank/v2 #20316
docs: ADR-071 Bank/v2 #20316
Conversation
Co-Authored-By: Julien Robert <29894366+julienrbrt@users.noreply.github.com>
|
Note Reviews pausedUse the following commands to manage reviews:
WalkthroughWalkthroughThe proposed changes in Changes
Possibly related issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Out of diff range and nitpick comments (3)
docs/architecture/adr-071-bank-v2.md (3)
13-13: Remove trailing space for cleaner formatting.
25-25: Remove trailing space for cleaner formatting.
92-92: Ensure the file ends with a single newline character.
Review Details
Configuration used: .coderabbit.yml
Review profile: CHILL
Files selected for processing (1)
- docs/architecture/adr-071-bank-v2.md (1 hunks)
Additional Context Used
LanguageTool (6)
docs/architecture/adr-071-bank-v2.md (6)
Near line 17: Possible missing comma found.
Context: ...duplicates functionalities (with 4 send functions for instance). Additionally, the integ...
Near line 21: Opting for a less wordy alternative here can improve the clarity of your writing.
Context: ...in the core modules. This rewrite will not only reduce the complexity but also improve the efficiency and UX of the bank modul...
Near line 33: A comma may be missing after the conjunctive/linking adverb ‘Currently’.
Context: ...and does not exceed its intended scope. Currently the permissions allow all denoms, so th...
Near line 61: Consider a shorter alternative to avoid wordiness.
Context: ...ng a v2 needs to be thought thoroughly. In order to not force all dependencies to immediate...
Near line 63: A comma may be missing after the conjunctive/linking adverb ‘Instead’.
Context: ...a newcosmossdk.io/bank/v2go module. Instead the bank protos will be versioned from ...
Near line 81: The word “fallback” is a noun. The verb is spelled with a space.
Context: ...in (IBC-ed custom asset should possibly fallback to the default implementation) * Many a...
Path-based Instructions (1)
docs/architecture/adr-071-bank-v2.md (1)
Pattern
**/*.md: "Assess the documentation for misspellings, grammatical errors, missing documentation and correctness"
|
|
||
| In addition to the above, the bank module is currently too rigid and handles too many tasks, so this proposal aims to streamline the module by focusing on core functions `Send`, `Mint`, and `Burn`. | ||
|
|
||
| Currently, the module is split accross different keepers with scattered and duplicates functionalities (with 4 send functions for instance). |
There was a problem hiding this comment.
Consider adding a comma after "Additionally" for better readability.
- Additionally the integration of the token factory into the bank module allows for standardization, and better integration within the core modules.
+ Additionally, the integration of the token factory into the bank module allows for standardization, and better integration within the core modules.Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| Currently, the module is split accross different keepers with scattered and duplicates functionalities (with 4 send functions for instance). | |
| Currently, the module is split accross different keepers with scattered and duplicates functionalities (with 4 send functions for instance). |
|
@coderabbitai pause |
Actions PerformedReviews paused. |
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
One negative is that this means that different asset implementations could have different state layouts and that it may be hard to query all the balances of a given account for all demons, especially considering what's being proposed for state indexing.
Instead why not simply have callbacks for OnMint, OnBurn and OnTransfer that allow for custom validation and even side effects, but keep all the state management in x/bank? Why would any denom implementation need to actually have a different state layout for balance or supply? Wouldn't it mostly be around allowing or disallowing the operation?
|
Also, a few more open questions about the proposed design occur to me. What actually are these I want to propose an alternate design where bank exposes three admin operations:
To me this design covers all the cases I can think of without any of the downsides related to inconsistent state and events. It also defines a clear way to use the |
|
@testinginprod might be good to get your thoughts on Aarons comment above as the denom/asset interface was your suggestion |
docs/architecture/adr-071-bank-v2.md
Outdated
| } | ||
| ``` | ||
|
|
||
| If admin account defines these callbacks, `x/bank` will call `x/accounts` `MsgExecute` with the `OnTransfer`, `GetBalance` or `GetSupply` callbacks: |
There was a problem hiding this comment.
call back on queries would need to also be in the indexing layer right?
There was a problem hiding this comment.
Not sure quite what you mean. The indexing layer wouldn't index any balances or supplies that aren't managed by x/bank. For those we would need to figure out some indexing solution for the x/accounts implementations.
|
|
||
| Bank is a widely used module, so getting a v2 needs to be thought thoroughly. In order to not force all dependencies to immediately migrate to bank/v2, the same _upgrading_ path will be taken as for the `gov` module. | ||
|
|
||
| This means `cosmossdk.io/bank` will stay one module and there won't be a new `cosmossdk.io/bank/v2` go module. Instead the bank protos will be versioned from `v1beta1` (current bank) to `v2`. |
There was a problem hiding this comment.
i dont think we should do this since we dont want to support all the queries there right now? should we assume we have an offchain indexer in this sense and make sure we dont store extra data for queries?
|
For visibility, here's my feedback from our call today @samricotta
The changes to send restrictions should be documented, particularly if they'll be applied globally in conjunction with the new hook, on a per-denom basis within the new hooks functionality, or on a per-denom basis in conjunction with the new hooks. Also note that if send restrictions are to be replaced by transfer hooks, this would be considered a breaking change (though acceptable imo given their relatively limited adoption)
|
One of my main concerns with this rewrite is that send restrictions will be ruined. They MUST continue to be applied globally. They should be consulted any time funds are being moved. We've got three modules that use send restrictions:
On a separate note, One of the things we currently like about the bank module is that it records everything all in one place. So we can ask for an account's balances, and get everything belonging to them, regardless of the denom. We also have an I'm also concerned that there won't be a way for a module to facilitate movement of funds. Specifically, if the "from" has to be determined by the signer of a message, it seems like it'll be impossible for anything to move funds except through a MsgSend signed by the user. In a lot of our use cases, they signed a previous message that explicitly gives some other actor the ability to move specific funds out of their account. |
Description
The main objective of bank is to condense and streamline the role of the bank module. Currently it handles a multitude of jobs such as handle sends, handle account restrictions, handle delegation counting, minting and burning of coins, we want to streamline this.
Within the ADR we cover ways to achieve this with pros and cons.
We would like to add more implementation details in the next coming days and more importantly obtain feedback
Reference: #17579
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!in the type prefix if API or client breaking changeCHANGELOG.mdReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
Summary by CodeRabbit
Documentation
New Features
Refactor
Send,Mint, andBurn.Chores