Support PermissionDelegation Amendment XLS-74d XLS-75d - #5354
Conversation
70a6362 to
5b262d1
Compare
c8bc5f6 to
e8e74f1
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5354 +/- ##
=========================================
+ Coverage 78.1% 78.3% +0.1%
=========================================
Files 795 800 +5
Lines 68653 69025 +372
Branches 8276 8275 -1
=========================================
+ Hits 53644 54022 +378
+ Misses 15009 15003 -6
🚀 New features to boost your workflow:
|
e8e74f1 to
b1f0387
Compare
b1f0387 to
4495956
Compare
4495956 to
49ca2b8
Compare
|
Also, I propose that we shouldn't need to squash commits. Commits makes it easier for the reviewers to keep track of the changes, and they will all be squashed in the end anyways. Also, the audit relies on a particular commit hash, so it's best to keep the commit history as authentic as possible. |
gregtatcam
left a comment
There was a problem hiding this comment.
👍 LGTM
I have a few minor comments for your consideration,
ximinez
left a comment
There was a problem hiding this comment.
It looks like all my concerns have been addressed. I have not reviewed the whole PR, so I can not "approve", but I will dismiss my stale change request review.
As noted above, dismissing this change request.
| if (tx.isFieldPresent(sfWalletLocator) || | ||
| tx.isFieldPresent(sfNFTokenMinter)) | ||
| return tecNO_PERMISSION; |
There was a problem hiding this comment.
Isn't it necessary to check the WalletSize field?
There was a problem hiding this comment.
The WalletSize field does nothing according to https://xrpl.org/docs/references/protocol/transactions/types/accountset
Although WalletSize is defined, there's no code in AccountSet setting WalletSize, which approves that the field is not used.
There was a problem hiding this comment.
Yes, WalletSize does not change AccountRoot, but it is a field that can be specified in AccountSet transactions.
It seems strange that a transaction would succeed when only sfWaletSize is specified by an account with permissions only for AccountEmailHashSet.
There was a problem hiding this comment.
Ah, if we have some specific permission for AccountSet, are AccountSet transactions (empty execution) that don't change AccountRoot allowed?
| if (uSetFlag != 0 || uClearFlag != 0 || uTxFlags != tfFullyCanonicalSig) | ||
| return tecNO_PERMISSION; |
There was a problem hiding this comment.
The check now already blocks batch transaction and returns tecNO_PERMISSION. If the tx flag is not equal to the auto filled tfFullyCanonicalSig, it will return tecNO_PERMISSION. I think we don't need to modify for Batch.
There was a problem hiding this comment.
Good Catch! @tequdev! You are right, as the current code stands Batch Inner AccountSet for Domain is rejected with NO_PERMISSION. tfUniversalMask should have been used here.
There was a problem hiding this comment.
ok. Got it. So we are supporting delegation within the Batch transactions, even though Batch itself could not be delegated. Please ignore my previous comment. @dangell7 Thank you for updating.
## High Level Overview of Change <!-- Please include a summary/list of the changes. If too broad, please consider splitting into multiple PRs. --> Adds support for Account Permission Delegation ([XLS-74d, XLS-75d](https://github.com/XRPLF/XRPL-Standards/pull/257/files)) Changes will include: - Adding a new transaction `DelegateSet` - Adding a common optional field `Delegate` to `SimpleTab` ### Context of Change <!-- Please include the context of a change. If a bug fix, when was the bug introduced? What was the behavior? If a new feature, why was this architecture chosen? What were the alternatives? If a refactor, how is this better than the previous implementation? If there is a design document for this feature, please link it here. --> rippled PR: XRPLF/rippled#5354. ### Type of Change <!-- Please check relevant options, delete irrelevant ones. --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] Refactor (non-breaking change that only restructures code) - [ ] Tests (You added tests for code that already exists, or your new feature included in this PR) - [ ] Documentation Updates - [ ] Translation Updates - [ ] Release ## Before / After <!-- If just refactoring / back-end changes, this can be just an in-English description of the change at a technical level. If a UI change, screenshots should be included. --> ### DelegateSet Simple Tab <img width="1008" alt="Screenshot 2025-05-21 at 3 17 53 PM" src="https://github.com/user-attachments/assets/f1058289-25c8-4f3d-8f7c-513354d58406" /> ### DelegateSet Table Detail <img width="1210" alt="Screenshot 2025-05-21 at 3 21 02 PM" src="https://github.com/user-attachments/assets/7ab86e54-379e-44f9-b6eb-f3269feac072" /> ### DelegateSet Description <img width="898" alt="Screenshot 2025-05-21 at 3 22 00 PM" src="https://github.com/user-attachments/assets/3542f6e3-7d1f-48c7-946a-87e8a7ba8fd3" /> ### An authorized Payment transaction Simple Tab <img width="1027" alt="Screenshot 2025-05-21 at 3 23 08 PM" src="https://github.com/user-attachments/assets/87deee32-fd75-4a06-ab55-56c341495eb0" /> ### An authorized Payment transaction Description <img width="719" alt="Screenshot 2025-05-21 at 3 23 29 PM" src="https://github.com/user-attachments/assets/f1d69437-cd4b-404a-b679-ccc14dfa3754" />
## High Level Overview of Change <!-- Please include a summary/list of the changes. If too broad, please consider splitting into multiple PRs. --> Adds support for Account Permission Delegation ([XLS-74d, XLS-75d](https://github.com/XRPLF/XRPL-Standards/pull/257/files)) Changes will include: - Adding a new transaction `DelegateSet` - Adding a common optional field `Delegate` to `SimpleTab` ### Context of Change <!-- Please include the context of a change. If a bug fix, when was the bug introduced? What was the behavior? If a new feature, why was this architecture chosen? What were the alternatives? If a refactor, how is this better than the previous implementation? If there is a design document for this feature, please link it here. --> rippled PR: XRPLF/rippled#5354. ### Type of Change <!-- Please check relevant options, delete irrelevant ones. --> - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] Refactor (non-breaking change that only restructures code) - [ ] Tests (You added tests for code that already exists, or your new feature included in this PR) - [ ] Documentation Updates - [ ] Translation Updates - [ ] Release ## Before / After <!-- If just refactoring / back-end changes, this can be just an in-English description of the change at a technical level. If a UI change, screenshots should be included. --> ### DelegateSet Simple Tab <img width="1008" alt="Screenshot 2025-05-21 at 3 17 53 PM" src="https://github.com/user-attachments/assets/f1058289-25c8-4f3d-8f7c-513354d58406" /> ### DelegateSet Table Detail <img width="1210" alt="Screenshot 2025-05-21 at 3 21 02 PM" src="https://github.com/user-attachments/assets/7ab86e54-379e-44f9-b6eb-f3269feac072" /> ### DelegateSet Description <img width="898" alt="Screenshot 2025-05-21 at 3 22 00 PM" src="https://github.com/user-attachments/assets/3542f6e3-7d1f-48c7-946a-87e8a7ba8fd3" /> ### An authorized Payment transaction Simple Tab <img width="1027" alt="Screenshot 2025-05-21 at 3 23 08 PM" src="https://github.com/user-attachments/assets/87deee32-fd75-4a06-ab55-56c341495eb0" /> ### An authorized Payment transaction Description <img width="719" alt="Screenshot 2025-05-21 at 3 23 29 PM" src="https://github.com/user-attachments/assets/f1d69437-cd4b-404a-b679-ccc14dfa3754" />
This change implements the account permission delegation described in XLS-75d, see XRPLF/XRPL-Standards#257. * Introduces transaction-level and granular permissions that can be delegated to other accounts. * Adds `DelegateSet` transaction to grant specified permissions to another account. * Adds `ltDelegate` ledger object to maintain the permission list for delegating/delegated account pair. * Adds an optional `Delegate` field in common fields, allowing a delegated account to send transactions on behalf of the delegating account within the granted permission scope. The `Account` field remains the delegating account; the `Delegate` field specifies the delegated account. The transaction is signed by the delegated account.
spec:
https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0074d-account-permissions
https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0075d-permission-delegation
This amendment is called
PermissionDelegationDelegateSettransaction is added so that a delegating account can give permission to delegated account to send transaction on his behalf.Ledger object
Delegateis created, its keylet is hashed from delegating and delegated account.optional common field
Delegateis added, to indicate that a transaction is a delegating transaction.The following transaction is a delegating transaction,
Delegateaccount is the sender of the transaction and will sign this transaction,Accountis the delegating account,Added a
checkPermissionfunction to check if the delegated account is authorized to send the transaction. And it can be extended in each sub-transactor to check the granular permissions.the delegated account pays the fee
can query
account_objectsof the delegating account to see the permissions he owns.A delegate transaction can be multi-signed by the delegated account's signer list
High Level Overview of Change
Context of Change
Type of Change
.gitignore, formatting, dropping support for older tooling)API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)