Skip to content

Commit

Permalink
Merge pull request #169 from euler-xyz/cantina-fixes
Browse files Browse the repository at this point in the history
Cantina contest fixes
  • Loading branch information
hoytech authored Aug 12, 2024
2 parents b14c418 + 78db50f commit 084b322
Show file tree
Hide file tree
Showing 11 changed files with 156 additions and 57 deletions.
2 changes: 1 addition & 1 deletion docs/specs.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
|CER-36 |Account and Vault Status Checks immediate |If the Execution Context's `checksDeferred` flag is not set, required Account and Vault Status Checks MUST be performed immediately |
|CER-48 |Account and Vault Status Checks not performed |Forgiven Account and Vault Status Checks will not be performed when the Execution Context's `checksDeferred` flag is cleared, unless they are required again after the forgiveness |
|CER-35 |Account and Vault Status Checks storage sets restored |Both Account- and Vault-Status-Checks-related storage sets MUST return to their default state when the Execution Context's `checksDeferred` flag is cleared and the checks are performed |
|CER-25 |Call/Batch EVC self-call |In Call and Batch, if the target is the EVC, the account specified MUST be `address(0)` for the sake of consistency. In that case, the EVC MUST be `delegatecall`ed to preserve the `msg.sender` and, depending on a function, a function-specific authentication is performed |
|CER-25 |Call/Batch EVC self-call |In Call and Batch, for the sake of consistency, if the target is the EVC, the account specified MUST be address(0) and the value specified MUST be 0. In that case, the EVC MUST be `delegatecall`ed to preserve the `msg.sender` and, depending on a function, a function-specific authentication is performed |
|CER-23 |Call/Batch callback |In Call and Batch, if the target is `msg.sender`, the caller MAY specify any Account address to be set in the Execution Context's on behalf of Account address. In that case, the authentication is not performed |
|CER-24 |Call/Batch external call |In Call and Batch, if the target is not `msg.sender`, only the Owner or an Operator of the specified Account MUST be allowed to perform Call and individual Batch operations on behalf of the Account |
|CER-20 |Checks-deferrable calls | |
Expand Down
6 changes: 2 additions & 4 deletions docs/whitepaper.md
Original file line number Diff line number Diff line change
Expand Up @@ -235,7 +235,7 @@ Sub-accounts allow users access to multiple (up to 256) virtual accounts that ar

Since an account can only have one controller at a time (except for mid-transaction), sub-accounts are also the only way an Ethereum account can hold multiple Vault borrows concurrently.

The EVC also maintains a look-up mapping `ownerLookup` so sub-accounts can be easily resolved to owner addresses, on- or off-chain. This mapping is populated when an address interacts with the EVC for the first time. In order to resolve a sub-account, the `getAccountOwner` function should be called with a sub-account address. It will either return the account's primary address, or revert with an error if the account has not yet interacted with the EVC.
The EVC also maintains a look-up mapping `ownerLookup` so sub-accounts can be easily resolved to owner addresses, on- or off-chain. This mapping is populated when an address interacts with the EVC for the first time. In order to resolve a sub-account, the `getAccountOwner` function should be called with a sub-account address. It will either return the account's primary address, or `address(0)` if the account has not yet interacted with the EVC.

#### Operators

Expand Down Expand Up @@ -270,9 +270,7 @@ The previous value of `onBehalfOfAccount` is stored in a local "cache" variable

#### checksInProgress

The EVC invokes the `checkAccountStatus` and `checkVaultStatus` callbacks using low-level `call` instead of `staticcall` so that controllers can checkpoint state during these operations. However, because of this there is a danger that the EVC could be re-entered during these operations, either directly by a controller, or indirectly by a contract it invokes.

Because of this, the EVC's execution context maintains a `checksInProgress` mutex that is acquired before unwinding the sets of accounts and vaults that need checking. This mutex is also checked during operations that alter these sets. If it did not do this, then information cached by the higher-level unwinding function (such as the sizes of the sets) could become inconsistent with the underlying storage, which could be used to bypass these critical checks.
Because the EVC invokes the `checkAccountStatus` and `checkVaultStatus` callbacks that could re-enter the EVC, either directly or by a contract they invoke, the EVC's execution context maintains a `checksInProgress` mutex that is acquired before unwinding the sets of accounts and vaults that need checking. This mutex is also checked during operations that alter these sets. If it did not do this, then information cached by the higher-level unwinding function (such as the sizes of the sets) could become inconsistent with the underlying storage, which could be used to bypass these critical checks.

#### controlCollateralInProgress

Expand Down
Loading

0 comments on commit 084b322

Please sign in to comment.