Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add storage deposit support in apps #6657

Merged
merged 16 commits into from
Dec 22, 2021

Conversation

statictype
Copy link
Member

@statictype statictype commented Dec 10, 2021

Introduced in Substrate here

Done:

  • storageDepositLimit = null
  • rename endowment to value
  • update input info text
  • make value input zeroable where storageDepositLimit is present (updated nodes)

@statictype statictype changed the title Add storage deposit support Add storage deposit support in apps Dec 10, 2021
@statictype
Copy link
Member Author

statictype commented Dec 12, 2021

instantiation works now on nodes with or without the latest changes, as far as I tested

i can't get call to work though, i keep getting this error when the modal opens

new node
Screenshot 2021-12-12 at 23 08 02

old node
Screenshot 2021-12-12 at 23 02 54

@jacogr
Copy link
Member

jacogr commented Dec 13, 2021

The above one is problematic - the RPC results changed. The API have a __fallback specifier that may cater for this case. But basically the error suggests it cannot decode a number (I would guess... the bn.js errors def. have something exactly like that)

isZeroable={hasStorageDeposit}
isZeroable={contractAbi.constructors[constructorIndex].isPayable}
Copy link

@athei athei Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does isZeroable do if true? Asking because zero could still be a valid value when the constructor/message is payable.

Copy link
Member Author

@statictype statictype Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's true then 0 can be an acceptable value, otherwise the input validation fails. the input gets a red border and you can't move to the next step

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now i tried with the older node and even if the constructor is not payable, the transaction fails with "contract not founded" if i pass 0.
is is safe to assume that if the node supports storage deposit than the value can be 0 for non payable constructors?

Copy link

@athei athei Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have to differentiate between ABI (payable) and the node. ABI comes from ink! and is decoupled from the node version.

Old Node:
Always needs value/endowment in order to pay for rent. Disregard payable.

New Node:
Does not need any value except if the constructor is payable. Hence you should not even show the field and use 0 when the constructor isn't payable.

ink!:
Ink constructors are implicitly payable. The fuck up is that this is implicit. The field is missing from ABI. What you should do is interpete the absense of the payable field as payable = true. We intent to make it explicit and also allow to make them not payable. The following is forward compatible:
undefined -> true
false-> false
true -> true

Copy link
Member Author

@statictype statictype Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, got it!
i am using this api.tx.contracts.instantiate.meta.args.length === 6 to check if the node has storage deposit or not. because the changes to value are related to storage deposit i wanted to double check it the same condition can be used

@statictype
Copy link
Member Author

@jacogr this is ready for review, i think. is there something else we can do to get this available to the users faster?

@jacogr
Copy link
Member

jacogr commented Dec 21, 2021

I'll get through the queue - I know I'm a bottlenck, it takes a while to get to stuff in the review queue. (In apps I currently have a large number of PRs > 1 month old which has not had a look, the queue should be at 0 and it runs longer than a page here, just because of not getting there. It has been quite neglected due to pressures elsewhere.)

@statictype
Copy link
Member Author

whenever you have some time. build should pass now.

@jacogr
Copy link
Member

jacogr commented Dec 22, 2021

On the list for today.

Copy link
Member

@jacogr jacogr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm code-wise, just some small comments.

The bumps here are weird, was it done manually?

@@ -50,6 +51,7 @@ function Deploy ({ codeHash, constructorIndex = 0, onClose, setConstructorIndex

const [name, isNameValid, setName] = useNonEmptyString(code && code.json.name);
const { contractAbi, errorText, isAbiError, isAbiSupplied, isAbiValid, onChangeAbi, onRemoveAbi } = useAbi([code && code.json.abi, code && code.contractAbi], codeHash, true);
const isConstructorPayable = contractAbi?.constructors[constructorIndex].isPayable !== false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would always be true. It does not get set on constructors at this point at all. So it will be undefined !== false in all cases.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the intention is to make the constructors explicitly payable / not payable in ink!
just trying to be forward compatible. but yes, it's an unnecessary check at this point.

Copy link
Member

@jacogr jacogr Dec 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that, but it is actually not forward-compatible at all :) Until we have a plan for the actual ABI definitions, so at this point is is guessing... So, if we want to really do this - pass the flag here https://github.com/polkadot-js/api/blob/master/packages/api-contract/src/Abi/index.ts#L93 (like we do for messages)

For now it would need to always be isPayable: true. When the time comes that the constructors pass it, on the API level it would need to change that field into an Option<bool> for the decoders. The we need to change the always-true be a isPayable: o.isNone || o.unwrap().isTrue (to maintain backwards compat where it was not passed)

So not against the checks, however the tristate logic should not sit quite here. It is ok for now, but needs cleanup on the ABI level and then here.

yarn.lock Outdated
languageName: node
linkType: hard

"@polkadot/api-contract@npm:^7.0.3-0":
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somewhere things got mismatched between the versions here - the ./dev/all-update.sh script will ensure there is a single version and dedupe it as well. (The lockfile here is weird with the -0 & -1 matching)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what i did is to bump the versions in package.json and then run yarn

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, yes, that is the issue - they are in multiple places in the root and in the workspace level (not actually enough, most pages do still pull in transient deps).

@jacogr jacogr mentioned this pull request Dec 22, 2021
@jacogr
Copy link
Member

jacogr commented Dec 22, 2021

Just merge in master and we should be good to go :)

Copy link
Member

@jacogr jacogr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much, this is great!

@jacogr jacogr merged commit c2be422 into polkadot-js:master Dec 22, 2021
@polkadot-js-bot
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@polkadot-js polkadot-js locked as resolved and limited conversation to collaborators Dec 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants