Clawback Operation #2881

sisuresh · 2021-01-19T18:18:38Z

Description

Added AUTH_CLAWBACK_ENABLED_FLAG account flag.
- Added SET_OPTIONS_AUTH_REVOCABLE_REQUIRED result code. This is returned if AUTH_CLAWBACK_ENABLED_FLAG is set without AUTH_REVOCABLE_FLAG.
Added CLAWBACK_ENABLED_FLAG trustline flag.
- Modified AllowTrust to only modify AUTHORIZED_FLAG and AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG.
Added ClawbackOp.

Checklist

Reviewed the contributing document
Rebased on top of master (no merge commits)
Ran clang-format v5.0.0 (via make format or the Visual Studio extension)
Compiles
Ran all tests
If change impacts performance, include supporting evidence per the performance document

jonjove

Reviewed everything but the tests.

src/xdr/Stellar-transaction.x

src/transactions/SetOptionsOpFrame.cpp

jonjove · 2021-01-19T22:03:14Z

src/transactions/SetOptionsOpFrame.cpp

@@ -18,9 +18,11 @@ namespace stellar
 {

 static const uint32 allAccountFlags =
-    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG);
+    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG |


After reviewing the way that trustLineFlagIsValid was done in the next commit, I'm also questioning whether we should be using a similar approach for the MASK_ACCOUNT_FLAGS. I think it would probably be slightly better in that the invariant would be able to check for flags that were introduced in later versions when running earlier versions, which is valuable for ensuring correctness in parallel catchup. What do you think?

I think that the reason we could not check this in the bucket entries invariant was that when we apply buckets, we do not know the protocol version (or at least the code was not written in a friendly way) - if it's too involved we should open an issue to address this separately from this PR

but if you mean that there should be a accountFlagIsValid equivalent to trustLineFlagIsValid that we can use both invariants and in setOptions that makes sense to me

The last commit (bf6bf6e068b7ad24dc3d7418c444cd89b04a5c3e) adds the account flag validity check to LedgerEntryIsValid, but it works a little different from trustline flag validation.

We can reuse trustLineFlagIsValid in the invariants and AllowTrustOpFrame::doCheckValid because mAllowTrust.authorize is the next expected state of the trustline flags. SetOptionsOpFrame doesn't work the same way because its parameters change specific bits in the flag. Due to this, we need three different checks -

At validation - check that parameter bits are valid.

At apply - check that the revocable/clawback combo is valid.

Invariants - check that the both conditions above are true.

I kept these changes as a separate commit for now, but will squash it if we think this is worth doing. We will also have a very similar issue with SetTrustlineFlagsOp, so the pattern used here should be used in the new operation.

The cap will also need to be updated to reflect MASK_ACCOUNT_FLAGS_V16.

@MonsieurNicolas I wasn't very clear or specific, but as @sisuresh correctly inferred I was talking about the LedgerEntryIsValid invariant. I agree that any changes to bucket invariants are way out of scope for this PR (but it's an interesting thing to wonder about).

src/transactions/TransactionUtils.cpp

src/transactions/ClawbackOpFrame.cpp

src/transactions/TransactionUtils.cpp

src/transactions/AllowTrustOpFrame.cpp

src/xdr/Stellar-ledger-entries.x

MonsieurNicolas · 2021-01-20T18:48:36Z

src/transactions/SetOptionsOpFrame.cpp

@@ -18,9 +18,11 @@ namespace stellar
 {

 static const uint32 allAccountFlags =
-    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG);
+    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG |


I think that the reason we could not check this in the bucket entries invariant was that when we apply buckets, we do not know the protocol version (or at least the code was not written in a friendly way) - if it's too involved we should open an issue to address this separately from this PR

MonsieurNicolas · 2021-01-20T18:55:25Z

src/transactions/SetOptionsOpFrame.cpp

@@ -224,6 +237,13 @@ SetOptionsOpFrame::doCheckValid(uint32_t ledgerVersion)
            innerResult().code(SET_OPTIONS_UNKNOWN_FLAG);
            return false;
        }
+
+        if (ledgerVersion < 16 &&


Would it be clearer to just compute allAccountFlags based on protocol version (as a helper function)

I removed allAccountFlags in the last commit (bf6bf6e068b7ad24dc3d7418c444cd89b04a5c3e).

MonsieurNicolas · 2021-01-20T19:02:59Z

src/transactions/SetOptionsOpFrame.cpp

@@ -164,6 +166,17 @@ SetOptionsOpFrame::doApply(AbstractLedgerTxn& ltx)
        account.flags = account.flags | *mSetOptions.setFlags;
    }

+    // check clawback state after account.flags has changed


comment should just be explicit on what the invariant is:
ensure that revocable is set if clawback is set

MonsieurNicolas · 2021-01-20T19:03:04Z

src/transactions/SetOptionsOpFrame.cpp

+    if (mSetOptions.setFlags || mSetOptions.clearFlags)
+    {
+        if ((account.flags & AUTH_CLAWBACK_ENABLED_FLAG) &&
+            (account.flags & AUTH_REVOCABLE_FLAG) == 0)


extra parenthesis for clarity

if ((account.flags & AUTH_CLAWBACK_ENABLED_FLAG) && ((account.flags & AUTH_REVOCABLE_FLAG) == 0))

or maybe just

if ((account.flags & AUTH_CLAWBACK_ENABLED_FLAG) && ~(account.flags & AUTH_REVOCABLE_FLAG))

MonsieurNicolas · 2021-01-20T19:09:31Z

src/transactions/SetOptionsOpFrame.cpp

@@ -18,9 +18,11 @@ namespace stellar
 {

 static const uint32 allAccountFlags =
-    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG);
+    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG |


but if you mean that there should be a accountFlagIsValid equivalent to trustLineFlagIsValid that we can use both invariants and in setOptions that makes sense to me

MonsieurNicolas · 2021-01-20T19:11:17Z

src/transactions/TransactionUtils.cpp

@@ -847,16 +861,24 @@ setAuthorized(LedgerTxnHeader const& header, LedgerTxnEntry& entry,
 bool
 trustLineFlagIsValid(uint32_t flag, uint32_t ledgerVersion)
 {
+    uint32_t invalidAuthCombo =


I would prefer to have this in the else (for protocol 13 and later) as this doesn't apply for older versions of the protocol

src/transactions/ClawbackOpFrame.cpp

src/transactions/TransactionUtils.cpp

jonjove

This is almost ready from my perspective. A few comments from me, then if @MonsieurNicolas is happy with it we can merge.

jonjove · 2021-01-25T17:56:09Z

src/transactions/SetOptionsOpFrame.cpp

@@ -18,9 +18,11 @@ namespace stellar
 {

 static const uint32 allAccountFlags =
-    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG);
+    (AUTH_REQUIRED_FLAG | AUTH_REVOCABLE_FLAG | AUTH_IMMUTABLE_FLAG |


@MonsieurNicolas I wasn't very clear or specific, but as @sisuresh correctly inferred I was talking about the LedgerEntryIsValid invariant. I agree that any changes to bucket invariants are way out of scope for this PR (but it's an interesting thing to wonder about).

src/transactions/SetOptionsOpFrame.cpp

jonjove · 2021-01-25T20:45:48Z

src/test/TxTests.cpp

@@ -1190,6 +1190,27 @@ revokeSponsorship(AccountID const& accID, SignerKey const& key)
    return op;
 }

+Operation
+clawback(AccountID const& from, Asset const& asset, int64_t amount)


Nitpick: this interface is a little strange. It entirely ignores the issuer of asset, and allows you to specify native (which you didn't handle). You should probably just take AssetCode const&.

Yeah I can see how the intent isn't as clear as it can be here. I ended up using AssetCode here, and adding a REQUIRE(asset.type() != ASSET_TYPE_NATIVE); check above in TestAccount.

What is the motivation for leaving it as Asset const& in TestAccount?

It's simpler to use the existing Asset instead of creating an AssetCode off of it. If you feel strongly about this I can change the signature and use a assetToAssetCode helper method in the tests.

It's test so I don't feel particularly strongly either way. I just worry about things that could be confusing, but I don't think this is so bad.

src/transactions/test/ClawbackTests.cpp

MonsieurNicolas · 2021-01-26T23:05:22Z

r+ 5f07723

sisuresh requested a review from jonjove January 19, 2021 18:18

jonjove reviewed Jan 19, 2021

View reviewed changes

MonsieurNicolas requested changes Jan 20, 2021

View reviewed changes

sisuresh force-pushed the clawback branch from 620af1f to bf6bf6e Compare January 22, 2021 17:25

jonjove reviewed Jan 25, 2021

View reviewed changes

sisuresh added 10 commits January 26, 2021 12:41

Ran clang-format

399fc23

Clawback - Add xdr

23440bc

Clawback - Add AUTH_CLAWBACK_ENABLED_FLAG

b4b6c02

Clawback - Add CLAWBACK_ENABLED flag to trustline

06eb548

Clawback - Add addBalanceSkipAuthorization method

caddc13

Clawback - Use common method to create Asset

7d0e0a1

Clawback - getAsset - throw on unexpected assetCode type

bb011f9

Clawback - Add ClawbackOp

b59e33d

Clawback - Update AllowTrust

a9a7a4d

Clawback - Move setAuthorized to AllowTrust

fb2babb

sisuresh force-pushed the clawback branch from bf6bf6e to 9d783fe Compare January 26, 2021 21:09

sisuresh added 3 commits January 26, 2021 13:11

Clawback - Add tests

c33cb24

Clawback - Update LedgerEntryIsValid and tests

0d25739

Clawback - Update Visual Studio files

5f07723

sisuresh force-pushed the clawback branch from 9d783fe to 5f07723 Compare January 26, 2021 21:11

latobarita merged commit 2c5b510 into stellar:master Jan 27, 2021

jonjove mentioned this pull request Mar 30, 2021

Implement CAP-0035 #2886

Closed

4 tasks

This was referenced Aug 10, 2021

Strong typing for Stellar trezor/trezor-firmware#1755

Merged

fix(python/stellar): correct the data type passed to StellarAllowTrustOp.is_authorized. trezor/trezor-firmware#1756

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clawback Operation #2881

Clawback Operation #2881

sisuresh commented Jan 19, 2021 •

edited

Loading

jonjove left a comment

jonjove Jan 19, 2021

MonsieurNicolas Jan 20, 2021

MonsieurNicolas Jan 20, 2021

sisuresh Jan 22, 2021

sisuresh Jan 22, 2021

jonjove Jan 25, 2021

MonsieurNicolas Jan 20, 2021

MonsieurNicolas Jan 20, 2021

sisuresh Jan 22, 2021

MonsieurNicolas Jan 20, 2021

sisuresh Jan 22, 2021

MonsieurNicolas Jan 20, 2021

sisuresh Jan 22, 2021

MonsieurNicolas Jan 20, 2021

MonsieurNicolas Jan 20, 2021

sisuresh Jan 22, 2021

jonjove left a comment

jonjove Jan 25, 2021

jonjove Jan 25, 2021

sisuresh Jan 26, 2021

jonjove Jan 26, 2021

sisuresh Jan 26, 2021

jonjove Jan 26, 2021

MonsieurNicolas commented Jan 26, 2021

Clawback Operation #2881

Clawback Operation #2881

Conversation

sisuresh commented Jan 19, 2021 • edited Loading

Description

Checklist

jonjove left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonjove left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MonsieurNicolas commented Jan 26, 2021

sisuresh commented Jan 19, 2021 •

edited

Loading