Refactor solver calls to directly from Atlas #225

BenSparksCode · 2024-06-12T12:02:57Z

Audit issues resolved in this PR:

https://github.com/spearbit-audits/review-fastlane/issues/31
- Changed DAppControl.preSolverCall() and DAppControl.postSolverCall() to return nothing instead of a bool indicating success. Then, in EE, we only check the bool success returned from the delegatecall to see if failed. No decoding of returned data needed. Fixed here 33f24c0
https://github.com/spearbit-audits/review-fastlane/issues/103
- As the actual solver call no longer goes via the EE, but now goes directly from Atlas to the solver contract, this issue no longer exists.
https://github.com/spearbit-audits/review-fastlane/issues/110
- Resolved with comment and named error for clarity, _releaseSolverLock() no longer called inside _getBidAmount().
https://github.com/spearbit-audits/review-fastlane/issues/127
- Resolved by removing holdSolverLock() completely. Call index is still incremented in _executeSolverOperation() but should now be done once per solverOp, regardless of success or failure of the solverOp.
https://github.com/spearbit-audits/review-fastlane/issues/138
- Resolved with Atlas calling directly to solver. Note: validateBalances() has been removed and instead we check that the solver has repaid anything owed via their reconcile() call by checking the fulfilled bool from _solverLockData() at the end of solverCall() in Atlas. Note, we do a final check that deposits >= claims + withdrawals so even if the solver didn't fully repay what they owe via reconcile(), the postSolverCall hook has the opportunity to cover the remainder via contribute().
https://github.com/spearbit-audits/review-fastlane/issues/137
- Resolved in both cases. validateBalances() case is resolved by removing the function and only including the necessary logic (no lock check needed) at the end of atlasSolverCall().
https://github.com/spearbit-audits/review-fastlane/issues/140
- Resolved due to a direct call from Atlas to the solver contract. Additionally, the reference implementation of atlasSolverCall() in SolverBase.sol checks that the msg.sender is Atlas.
https://github.com/spearbit-audits/review-fastlane/issues/161
- Resolved due to Atlas calling the solver contract directly, as there is no need to append lockBytes (which includes solverOutcome) to this call.
https://github.com/spearbit-audits/review-fastlane/issues/195
- Resolved, as a failing _trySolverLock() now reverts with an InsufficientEscrow error which is caught and reflected in result.
https://github.com/spearbit-audits/review-fastlane/issues/149
- The handling of invertsBidValue has been simplified a lot in this PR. This mode is when a solver's bid wins if its the lowest, and represents the amount of assets they will take instead of give, from the Execution Environment.

Previously resolved audit issues affected by this PR:

https://github.com/spearbit-audits/review-fastlane/issues/150
- This issue was resolved previously by @jj1980a. The problem has not been re-introduced with this PR.

Note: Atlas is currently about 800 bytes over the contract size limit. We will resolve the size limit issue after the major structural change PRs - most likely the upcoming locking mechanism PR and a gas refund accounting revamp PR.

…three separate functions that are each called by escrow contract. This new design now has Atlas calling the solver contracts instead of the executionEnvironment calling the solver contracts, which should increase the safety. The math / bid verification accounting has also been simplified, and a new SolverTracker struct has been introduced to assist with data passing between the layers.

…is PR

BenSparksCode · 2024-06-13T18:20:06Z

Some clean up changes:

Made _bidFindingIteration() more "symmetrical" with _bidKnownIteration() by doing _executeSolverOperation() and allocateValue() directly inside. Also think its easier to see key.solverOutcome set to the solver index correctly in both that way.
Removed SolverTracker memory vars that weren't used
Renamed sTracker vars to solverTracker, a little bit more clear imo
Renamed sender param in atlasSolverCall() to solverOpFrom for clarity. This address param is always the solverOp.from.
Renamed bidRecipient param in atlasSolverCall() to executionEnvironment for clarity. Bids always sent to EE.
Added a few comments and natspec for clarity

src/contracts/libraries/SafetyBits.sol

src/contracts/atlas/Escrow.sol

…e of the solver try/catch

…all()`

src/contracts/atlas/Escrow.sol

ephess · 2024-06-16T21:31:43Z

src/contracts/atlas/Escrow.sol

+            } else if (errorSwitch == SolverOperationReverted.selector) {
+                result = 1 << uint256(SolverOutcome.SolverOpReverted);
+            } else if (errorSwitch == PostSolverFailed.selector) {


Error and SolverOutcome names differ, suggest renaming the error:

- error SolverOperationReverted(); + error SolverOpReverted();

Fixed here 1632ec2

ephess · 2024-06-16T21:32:32Z

src/contracts/atlas/Escrow.sol

+            } else if (errorSwitch == SolverBidUnpaid.selector) {
+                result = 1 << uint256(SolverOutcome.BidNotPaid);
+            } else if (errorSwitch == BalanceNotReconciled.selector) {


Error and SolverOutcome names differ, suggest renaming the error:

- error SolverBidUnpaid(); + error BidNotPaid();

Fixed here 1632ec2

ephess · 2024-06-16T21:37:16Z

src/contracts/atlas/Escrow.sol

+            } else if (errorSwitch == IntentUnfulfilled.selector) {
+                result = 1 << uint256(SolverOutcome.IntentUnfulfilled);
+            } else if (errorSwitch == SolverBidUnpaid.selector) {


IntentUnfulfilled does not seem to be thrown anywhere. Do we still need this?

Good catch, removed here 1632ec2

ephess · 2024-06-16T21:38:21Z

src/contracts/atlas/Escrow.sol

+            } else if (errorSwitch == InvalidEntry.selector) {
+                // DAppControl is attacking solver contract - treat as AlteredControl
+                result = 1 << uint256(SolverOutcome.AlteredControl);
+            } else if (errorSwitch == CallbackNotCalled.selector) {


CallbackNotCalled does not seem to be thrown anywhere, do we still need it?

Good catch, I've split up the checks at end of solverCall() to revert with either BalanceNotReconciled or CallbackNotCalled. I think the granularity for diagnosing what exactly caused the failure is useful. See 1632ec2

ephess · 2024-06-16T23:13:59Z

src/contracts/atlas/Storage.sol

@@ -85,6 +85,14 @@ contract Storage is AtlasEvents, AtlasErrors, AtlasConstants {
    /// @return calledBack Boolean indicating whether the solver has called back via `reconcile`.
    /// @return fulfilled Boolean indicating whether the solver's outstanding debt has been repaid via `reconcile`.
    function solverLockData() public view returns (address currentSolver, bool calledBack, bool fulfilled) {
+        return _solverLockData();


I don't understand the point of this, does it do something? Seems like this wrapping will increase the gas usage by about 88 from my tests.

Its more gas efficient to call an internal function than a public one, but we still need to expose that function publically for dapps or solvers to call. But good catch, the outer function should be external not public. Fixed here c1e3e1b

src/contracts/examples/intents-example/V4SwapIntent.sol

test/Escrow.t.sol

ephess · 2024-06-16T23:56:55Z

test/ExecutionEnvironment.t.sol

@@ -361,6 +330,7 @@ contract ExecutionEnvironmentTest is BaseTest {
        (status,) = address(executionEnvironment).call(postOpsData);
    }

+    /*
    function test_solverMetaTryCatch() public {


Shouldn't test_solverMetaTryCatch be removed now?

Yes but we should also add 2 new tests, for solverPreTryCatch and solverPostTryCatch. I've added a note to refactor this one into those 2 and left it commented as some of this test code may be reused in the new ones. Will add it to the list of tests to do after the audit fixes.

ephess · 2024-06-17T03:02:20Z

Aside from those comments above, this all LGTM.

From the issues above, they all seem to be addressed, except I'm not sure about https://github.com/spearbit-audits/review-fastlane/issues/149

That one feels like it's gonna need a thorough review.

Co-authored-by: ephess <[email protected]>

…/atlas into atlas-calls-solver

src/contracts/atlas/ExecutionEnvironment.sol

jgcogsystematictrading · 2024-06-17T23:07:23Z

src/contracts/atlas/ExecutionEnvironment.sol

-                endBalance = etherIsBidToken ? endBalance : address(this).balance;
-            }
+        // bidValue is not inverted; Higher bids are better; solver must deposit >= bidAmount
+        if (!solverTracker.invertsBidValue) {


Why do the floor and ceiling records get taken after the pre and post solver calls for !invertsBidValue, but the records get taken beforehand for invertsBidValue?

This is a good question. So to rephrase, if mode is invertsBidValue, the change is measured over preSolverCall, solverCall, and postSolverCall. But if the mode is normal bid value, the change is just measured over solverCall.

I think it could be because, in invertsBidValue mode, the assets must be transferred to the solver in the preSolver hook (because it would be less secure / more complex with approvals, to allow the solver to pull them in the solver call). So we take the starting balance measurement before a dapp might transfer assets in the preSolver hook. Same reasoning on the other side I think - assets representing the bid may be transferred to the solver in postSolver hook so check end balance after that. This way we support transferring those bid assets on either side of the solver call.

Whereas in normal bid mode, we just measure the assets the solver pays which only happens in solver call. So we can measure that type of bid more tightly (excluding changes due to pre and post solver hooks).

What you described would make sense, but that doesn't seem to be the implementation if i'm reading the code correctly. I worded it a bit weirdly at first. The below is the correct re-phrasing:

invertsBidValue the change is measured over preSolverCall and solverCall.
normal mode the change is measured over solverCall and postSolverCall.

The idea is to have a hook that takes place outside of the balance check for each option so that we can transform or otherwise adjust the balances. For the inverted bids, we wanted to be able to move inventory in so that we could then give it to the solver before the solver call, and for the normal bids we wanted to be able to move inventory out that we have received from the solver after the solver call.

Cool makes sense, lets add comments to the code that document this.

Edit: This seems fine because the only party who can affect the bid amount calculation is the dapp, who in doing so knows they are affecting the bid this way. No other party can act between the solver execution and the end of the postSolverHook (end of bid phase calculation) other than the dapp.

Original: A consequence of this is that if a dapp calls contribute() in the postSolverHook in:

normal mode this causes the contribution to be reduced from the bid amount calculation

invertsBidBalue: this causes the contribution to be included in the bid amount calculation

Could this cause any issues?

jgcogsystematictrading · 2024-06-18T02:38:45Z

This PR treats on-chain bid finding the same as regular known bids to determine solver payments. This seems intuitively right but Alex's comments seem to say we might want to do it some other way? https://github.com/spearbit-audits/review-fastlane/pull/1/files#r1561952304

BenSparksCode · 2024-06-18T07:10:19Z

This PR treats on-chain bid finding the same as regular known bids to determine solver payments. This seems intuitively right but Alex's comments seem to say we might want to do it some other way? https://github.com/spearbit-audits/review-fastlane/pull/1/files#r1561952304

I think Alex's comment there is more accurately implemented in the code after this PR - any ETH surplus in the EE (change measured across the pre and post solver hooks) is only considered to be the bid, and is completely separate from the solver's gas or borrowed ETH repayment. The gas / borrow repayment is handled by solver calling reconcile() on Atlas during the solver call, and can be supplemented by the dapp calling contribute() on Atlas.

So I don't think there was any other way that was explored, but rather that the original idea has been implemented much more cleanly in this PR.

jgcogsystematictrading · 2024-06-19T19:07:53Z

src/contracts/atlas/Escrow.sol

+        (, calledback, success) = _solverLockData();
+
+        if (!calledback) revert CallbackNotCalled();
+        if (!success && deposits < claims + withdrawals) revert BalanceNotReconciled();


Doesnt this check still trust this unreliable fulfilled flag? https://github.com/orgs/FastLane-Labs/projects/7/views/1?pane=issue&itemId=67398082

Yes it still uses the fulfilled flag - but the idea is that it should be reliable now. As of the Lock PR, borrow is limited to SolverOperations phase or before, and reconcile() can only be called during the SolverOperations phase. So, if a solver calls reconcile() and sets fulfilled = true then we know it can't go back to unfulfilled as the dapp can no longer borrow - only repay further via contribute()

thogard785 and others added 9 commits May 22, 2024 00:44

updating progress - still need to update many tests.

b80f2dd

fixed solver value passing

fa23af8

fixed incorrect call target for ex post bid finding

34abc0e

reverted the SolverTracker arg passing back to previous format for th…

6f63c65

…is PR

added data decoding for pre and post solver hook return values

02f36b1

Merge branch 'spearbit-audit-fixes' into atlas-calls-solver

83e42ad

fmt: run forge fmt

dccf544

chore: comments, rename vars for clarity, clean up

08bcbd0

chore: SafetyBits standardization and clean up

77e278c

BenSparksCode commented Jun 13, 2024

View reviewed changes

src/contracts/libraries/SafetyBits.sol Outdated Show resolved Hide resolved

BenSparksCode commented Jun 13, 2024

View reviewed changes

src/contracts/libraries/SafetyBits.sol Outdated Show resolved Hide resolved

BenSparksCode commented Jun 13, 2024

View reviewed changes

src/contracts/atlas/Escrow.sol Outdated Show resolved Hide resolved

BenSparksCode and others added 7 commits June 13, 2024 21:59

docs: update Execution Environment natspec for new hooks

d3768d9

fmt: run forge fmt

2b4c8f4

added PostSolver hook support to permit69 dapp transfers

313d0c7

removed holdSolverLock, which is no longer used

82c8be0

updated safeDappTransfer constant test

0442fee

added InsufficientEscrow error to identify insufficient escrows insid…

823aeda

…e of the solver try/catch

optimization: no return in pre/postSolverCall hook

33f24c0

BenSparksCode mentioned this pull request Jun 14, 2024

Spearbit Audit Fixes #166

Merged

BenSparksCode added 3 commits June 14, 2024 17:42

docs: clarify non-standard revert on success in _getBidAmount()

2de8ee2

chore: clearer unreachable error, IAtlas fn pointers for less size

8f8dff2

refactor: rm validateBalances() use _solverLockData() in `solverC…

bfe20a3

…all()`

thogard785 reviewed Jun 14, 2024

View reviewed changes

src/contracts/atlas/Escrow.sol Outdated Show resolved Hide resolved

BenSparksCode added 3 commits June 15, 2024 12:44

fix: add back repayment check after postSolverCall()

7da6083

test: dapp covers solver shortfall via contribute()

d159ba4

fix: check calledBack and fulfilled in solverCall()

8af6f6c

BenSparksCode requested a review from ephess June 16, 2024 16:30

ephess reviewed Jun 16, 2024

View reviewed changes

src/contracts/examples/intents-example/V4SwapIntent.sol Outdated Show resolved Hide resolved

ephess reviewed Jun 16, 2024

View reviewed changes

test/Escrow.t.sol Outdated Show resolved Hide resolved

ephess reviewed Jun 16, 2024

View reviewed changes

fix: isolate CallbackNotCalled check, standardize error names

1632ec2

jj1980a mentioned this pull request Jun 17, 2024

validateBalances checks the end balance instead of relying on the sol… #235

Closed

BenSparksCode and others added 4 commits June 17, 2024 09:13

Update src/contracts/examples/intents-example/V4SwapIntent.sol

ad4ae30

Co-authored-by: ephess <[email protected]>

chore: validUserOperation helper can use any control address

43f7ce7

Merge branch 'atlas-calls-solver' of https://github.com/FastLane-Labs…

d8f8f06

…/atlas into atlas-calls-solver

fix: make solverLockData() external not public

c1e3e1b

BenSparksCode requested review from ephess and jj1980a June 17, 2024 13:25

jgcogsystematictrading reviewed Jun 17, 2024

View reviewed changes

src/contracts/atlas/ExecutionEnvironment.sol Show resolved Hide resolved

jgcogsystematictrading reviewed Jun 17, 2024

View reviewed changes

ephess approved these changes Jun 18, 2024

View reviewed changes

jj1980a approved these changes Jun 18, 2024

View reviewed changes

BenSparksCode added 2 commits June 18, 2024 09:33

Merge branch 'spearbit-audit-fixes' into atlas-calls-solver

eb7935d

fmt: run forge fmt

aa461cd

BenSparksCode merged commit f924c36 into spearbit-audit-fixes Jun 18, 2024
3 checks passed

BenSparksCode deleted the atlas-calls-solver branch June 18, 2024 07:38

jgcogsystematictrading reviewed Jun 19, 2024

View reviewed changes

BenSparksCode mentioned this pull request Jun 22, 2024

Lock streamlining #227

Merged

jgcogsystematictrading mentioned this pull request Jul 11, 2024

refactor: solverPostTryCatch for consistent balance recording and improved error handling #350

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor solver calls to directly from Atlas #225

Refactor solver calls to directly from Atlas #225

BenSparksCode commented Jun 12, 2024 •

edited

Loading

BenSparksCode commented Jun 13, 2024

ephess Jun 16, 2024

BenSparksCode Jun 17, 2024

ephess Jun 16, 2024

BenSparksCode Jun 17, 2024

ephess Jun 16, 2024

BenSparksCode Jun 17, 2024

ephess Jun 16, 2024

BenSparksCode Jun 17, 2024

ephess Jun 16, 2024

BenSparksCode Jun 17, 2024

ephess Jun 16, 2024 •

edited

Loading

BenSparksCode Jun 17, 2024

ephess commented Jun 17, 2024

jgcogsystematictrading Jun 17, 2024

BenSparksCode Jun 18, 2024 •

edited

Loading

jgcogsystematictrading Jun 18, 2024

thogard785 Jun 19, 2024

jgcogsystematictrading Jun 19, 2024

jgcogsystematictrading Jun 20, 2024 •

edited

Loading

jgcogsystematictrading commented Jun 18, 2024

BenSparksCode commented Jun 18, 2024

jgcogsystematictrading Jun 19, 2024

BenSparksCode Jun 22, 2024

Refactor solver calls to directly from Atlas #225

Refactor solver calls to directly from Atlas #225

Conversation

BenSparksCode commented Jun 12, 2024 • edited Loading

BenSparksCode commented Jun 13, 2024

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

ephess Jun 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ephess commented Jun 17, 2024

Choose a reason for hiding this comment

BenSparksCode Jun 18, 2024 • edited Loading

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

jgcogsystematictrading Jun 20, 2024 • edited Loading

Choose a reason for hiding this comment

jgcogsystematictrading commented Jun 18, 2024

BenSparksCode commented Jun 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BenSparksCode commented Jun 12, 2024 •

edited

Loading

ephess Jun 16, 2024 •

edited

Loading

BenSparksCode Jun 18, 2024 •

edited

Loading

jgcogsystematictrading Jun 20, 2024 •

edited

Loading