-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Contracts remove deposit accounts #14589
Contracts remove deposit accounts #14589
Conversation
…migrate-to-fungible-traits
frame/contracts/src/storage/meter.rs
Outdated
} | ||
|
||
/// Charges from `origin` a storage deposit for contract instantiation. | ||
/// Charge from `origin` a storage deposit plus the ed for contract instantiation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We transfer ed then charge deposit minus ed, so this comment or the code seems wrong 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
charge
is in itself a transfer
, so I would not distinguish from transfer and charge. In fact we are taking "storage deposit + ed" from the origin.
How can we rephrase this to make it more clear?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact we are taking "storage deposit + ed" from the origin.
are you?
we do
T::Currency::transfer(origin, contract, ed, Preservation::Preserve)?;
//...
E::charge(origin, contract, &deposit.saturating_sub(&Deposit::Charge(ed)), false)?;
you take ed
and then deposit - ed
, am I overlooking something here?
also since we transfer ed directly, couldn't we then use fn charge_deposit
to delay the charge until later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you take
ed
and thendeposit - ed
, am I overlooking something here?
yes, you're right
also since we transfer ed directly, couldn't we then use
fn charge_deposit
to delay the charge until later?
absolutely, good point
frame/contracts/src/storage/meter.rs
Outdated
// We also need to make sure that the contract's account itself exists. | ||
T::Currency::transfer(origin, contract, ed, Preservation::Preserve)?; | ||
System::<T>::inc_consumers(contract)?; | ||
E::charge(origin, contract, &deposit.saturating_sub(&Deposit::Charge(ed)), false)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comment above seems off as well now, since you start by transferring ed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't think we need any comment at all there, maybe just the fact that we are excluding the ed
from the deposit
because it was transferred in the previous step. Would you add anything else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep let's just remove it, also see my comment above
* transfer to beneficiary after transfer_on_hold * wip * add consumer comment * review updates * fix typo * make clippy happy * refactor `Terminated` * rename ContractStatus to ContractState * rename status to state * replace Contribution::Alive to ContractState::Alive
bot fmt |
@juangirini https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3408730 was started for your command Comment |
@juangirini Command |
The CI pipeline was cancelled due to failure one of the required jobs. |
fn is_alive(&self) -> bool { | ||
matches!(self.own_contribution, Contribution::Alive(_)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep it around seems easier to read than in lining matches!(self.contract_state(), ContractState::Alive)
in a few places
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could be, though given the fact that we have ContractState::Alive
and Contribution::Alive()
the inline seems more meaningful... but I don't have a strong opinion here
@agryaznov wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's about contract's state, not RawMeter's. I think it's ok like this.
fn is_alive(&self) -> bool { | ||
matches!(self.own_contribution, Contribution::Alive(_)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's about contract's state, not RawMeter's. I think it's ok like this.
Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>
Co-authored-by: Sasha Gryaznov <hi@agryaznov.com>
bot merge |
Waiting for commit status. |
Merge cancelled due to error. Error: Statuses failed for 63ae66a |
bot merge force |
In this PR we are removing the deposit accounts.
This is a follow up of #14020 in which we got rid of the Currency traits in favour of the fungible traits, and therefore we hold deposits instead of reserving them.
ED doesn't contribute to held balances and this balance can only be slashed by the same
HoldReason
it was created under, removing the need of maintaining the deposit accounts.Migrations
Migrations v10 and v13 operated over deposit accounts and they have been updated to be kept backwards compatible for those chain which haven't ran it yet.
A new migration v15 has been added that moved the balance on the deposit accounts back to the contract accounts and hold them there under the
StorageDepositReserve
reason.This new migration needs to be added to the Config
Cumulus companion: paritytech/cumulus#2973
Complementary PR #14767