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

feat: give pallpark gas estimates #422

Merged
merged 1 commit into from
Aug 6, 2020
Merged

feat: give pallpark gas estimates #422

merged 1 commit into from
Aug 6, 2020

Conversation

chadoh
Copy link
Contributor

@chadoh chadoh commented Jul 28, 2020

Partially addresses near/devx#235

This is a largely a rewrite of our previous gas document

git is terrible at formatting such diffs; I recommend viewing this work primarily by looking at the preview: https://docs-pr-422.onrender.com/docs/concepts/gas (but please do come back and comment on specific lines in the "Files changed" tab here)

@render
Copy link

render bot commented Jul 28, 2020

@chadoh chadoh force-pushed the gas branch 4 times, most recently from 0e04472 to 7533420 Compare August 3, 2020 22:25

Note that this covers the cost of uploading and writing bytes to storage, but does _not_ cover the cost of holding these bytes in storage. Long-term storage is compensated via [storage staking], a recoverable cost-per-byte amount that will also be deducted from your account during contract deployment.

The AssemblyScript contract in [this example Fungible Token](https://github.com/near-examples/FT/pull/42) compiles to just over 16kb (the Rust contract is much larger, but this [will be optimized](???)). Using the calculation above, we find that it requires **0.81 TGas** (and thus 0.081mN at minimum gas price) for the transaction fee to deploy the contract, while 1.5N will be locked up for storage staking.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@nearmax is there an existing issue for tracking the Rust contract size optimization?

Copy link
Contributor

Choose a reason for hiding this comment

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

| Setting an escrow for a fungible token | [44k] | 0.926 | 2.51 | [8] | 0.8
| Checking a balance for a fungible token | 0 | 0 | 0 | 0 | 0

<super>†</super> Function calls require spinning up a VM and loading all compiled Wasm bytes into memory, hence the increased cost over base operations; this is [being optimized](???).
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@nearmax is there a an existing issue for tracking runtime-starting/Wasm-loading optimization?

Copy link
Contributor

Choose a reason for hiding this comment

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

And in [`near-api-js`](https://github.com/near/near-api-js), given a `contract` that you've instantiated with `new Contract`, you can attach an explicit gas amount when calling a change method on this contract with:

contract.myFunction({ arg1: 'val1' }, '300000000000000')
And in [`near-api-js`](https://github.com/near/near-api-js), you can also specify an explicit amount of gas units to attach when calling a change method; see [example here](https://github.com/near-examples/guest-book/blob/ceb2a39e53351b4ffc21d01987e2b0b21d633fa7/src/App.js#L29).
Copy link
Contributor

Choose a reason for hiding this comment

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

Curious why we want the user to click away for a line of code example?

Copy link
Contributor Author

@chadoh chadoh Aug 6, 2020

Choose a reason for hiding this comment

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

Because it's actually many lines of code, plus an entire src/config.js file. @janedegtiareva and I discussed and thought maybe it was better to link to an example rather than bulk this page with all that boilerplate.

Here's how we usually bootstrap a contract object so you can finally call your change method on it:

import getConfig from './config.js'
import { connect, Contract, keyStores, WalletConnection } as nearAPI from 'near-api-js'

const nearConfig = getConfig(process.env.NODE_ENV || 'testnet')

async function initContract() {
  window.near = await connect({
    deps: {
      keyStore: new keyStores.BrowserLocalStorageKeyStore()
    },
    ...nearConfig
  })

  window.walletConnection = new WalletConnection(near)

  window.contract = await new Contract(walletConnection.account(), nearConfig.contractName, {
    changeMethods: ['myFunction'],
  })
}

window.nearInitPromise = initContract()

// then later, when some event happens
window.contract.addMessage({ arg1: "val1" }, '300000000000000')

I think all of this boilerplate can and should go away, but until then, I don't see a great way to simplify it to a point that it fits into this document without being a bit distracting.

What do you think?

@chadoh chadoh merged commit ed18958 into master Aug 6, 2020
@chadoh chadoh deleted the gas branch August 6, 2020 12:05
@chadoh
Copy link
Contributor Author

chadoh commented Aug 6, 2020

I've merged in its current state at @amgando's request, since he wanted the new document ahead of a workshop he's running in a few hours.

Please keep feedback coming in, and I will address it in follow-up PRs. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants