Vault #220
Vault #220
Conversation
markspanbroek
force-pushed
the
update-solidity
branch
from
20a32c1 to
81e88dd
Compare
markspanbroek
force-pushed
the
update-solidity
branch
from
81e88dd to
b54cd59
Compare
|
Added functionality to have multiple accounts for an account holder inside a fund. This ensures that in the codex marketplace we keep funds for the client and for each slot separate, even though some providers may choose to fill multiple slots, or a client might decide to fill a slot in the storage contract itself. |
markspanbroek
force-pushed
the
vault
branch
2 times, most recently
from
3049325 to
724670b
Compare
|
Replaced 🔥 burnFund() with ❄️ freezeFund(). |
There was a problem hiding this comment.
Really great job Mark! Huge effort 💪 🙌
This was quite a lot to go through. I used the implementation branch (master...vault-integration#diff-5973808e32384782b5978a63e85b893b67d634be8aa42001f0ef480f189a0688R179) to get a better understanding of how some of the functionality relates to the Marketplace.
One question:
When we discussed freezing the vault, we discussed that it would not be able to be unfrozen by a controlling party. In this implementation, unfreezing happens after some time has elapsed, making the funds withdrawable again. Is the idea here that in the case of an attack, the vaults would all be locked in some way with a very long expiry?
| LockStatus lockStatus = lock.status(); | ||
| if (lockStatus == LockStatus.Locked) { | ||
| Account memory account = _accounts[controller][fund][id]; | ||
| account.update(Timestamps.currentTime()); |
There was a problem hiding this comment.
I find update a bit awkward in the context of a view, where nothing is being stored, except for in memory. Maybe atEnd or simulateEndAt...?
There was a problem hiding this comment.
Yeah, I was also bit puzzled by this 😅 Maybe a better name would better convey what is happening here and why. I like the "simulate" word from Eric's suggestion, but then it does not make sense in the cases where the account is actually stored?
There was a problem hiding this comment.
I also find it bit hard to find a better name, because it updates the struct that you pass as a parameter. Names such as atEnd() or simulateAtEnd() suggest to me that there would be a return value with the calculated values.
Maybe updateFlow()?
There was a problem hiding this comment.
Maybe updateSelf? Or updateSelfAtEnd?
markspanbroek
force-pushed
the
update-solidity
branch
from
b54cd59 to
6816355
Compare
There was a problem hiding this comment.
Great work Mark! 🎉
I don't see any big problem with the general approach and design here. My only concern is the usage of the uint128 for the balance tracking. See my comment bellow.
This is big PR, so this is just my first iteration of review. Will do more later on.
| struct Balance { | ||
| /// Available tokens can be transfered | ||
| uint128 available; | ||
| /// Designated tokens can no longer be transfered | ||
| uint128 designated; | ||
| } |
There was a problem hiding this comment.
I am not sure about the uint128. I understand your reasoning, but then if this should be a "general purpose contract", doing this optimization is IMHO wrong. You also don't have balances in ERC20 tracked with uint128 even though "it should be good enough for most cases".
There was a problem hiding this comment.
Looking at how this propagates to the Marketplace contract, I am more unsure about this.
There was a problem hiding this comment.
@AuHau and I discussed this in our meeting last week. To summarize:
- we don't expect there to be any tokens for which uint128 is insufficient
- using uint128 saves gas costs, because less storage is used
- uint128 could be a hindrance for the community to use the vault
- they might have to cast from uint256 to uint128, which needs to be done with care
- it is unclear whether the gas cost savings from having to store less bytes are worth it
I suggested to keep it at uint128 for now, and change it to uint256 if needed
| LockStatus lockStatus = lock.status(); | ||
| if (lockStatus == LockStatus.Locked) { | ||
| Account memory account = _accounts[controller][fund][id]; | ||
| account.update(Timestamps.currentTime()); |
There was a problem hiding this comment.
Yeah, I was also bit puzzled by this 😅 Maybe a better name would better convey what is happening here and why. I like the "simulate" word from Eric's suggestion, but then it does not make sense in the cases where the account is actually stored?
|
Thanks for the good feedback @AuHau and @emizzle. I think I addressed most of the naming concerns.
The |
markspanbroek
force-pushed
the
update-solidity
branch
from
6816355 to
7b14c20
Compare
- NoLock -> Inactive - Unlocked -> Withdrawing
Co-Authored-by: Adam Uhlíř <[email protected]>
Updates to the API of the Vault contract as worked on in codex-storage/codex-contracts-eth#220 Most important changes: - token transfers are much more restricted in the vault, improving its safety - when a storage request fails, only the providers at fault are punished, the rest are not - when a storage request fails, the client is only reimbursed for the remaining time in the contract - no longer possible for the marketplace to request one final storage proof before allowing withdrawal - repair reward is temporarily stored with the client's funds while slot is free, and not yet filled; this could lead to client withdrawing repair rewards when slots are free when the request ends
Adds a
Vaultcontract, that allows funds to be locked up for a certain amount of time. These funds can be transferred, burned or even flow over time to other addresses.Follows the design from codex-research/design/contract-deployment
Requires #219 to be merged first.