I learned that data storage on NEAR protocol requires to stake NEAR tokens. Is there a way to monitor the total amount of data stored on chain? Didn't find it on NEAR Explorer (or perhaps didn't look at the right place)
The increase/decrease in storage use automatically locks some of the tokens on the account. Explorer displays "STORAGE USED" on the account details page (example). mainnet is configured (see EXPERIMENTAL_protocol_config JSON RPC method for other config options) to have "storage_amount_per_byte": "100000000000000000000", which means that 100kb of data (smart contract code, smart contract state, account access keys, and profile data [liquid balance, locked balance, account id]) locks 1 NEAR on your account (so you just cannot transfer/spend those tokens unless you remove something from the storage).
Related
I want to empty my transactable balance,but alwalys got LackofBalance error.
I've used gas price* gas limit and ransfer_cost + create_account_cost + add_key_cost.full_access_cost by
https://nomicon.io/GenesisConfig/RuntimeFeeConfig/ActionCreationConfig#transfer_cost to calculate fee and max transaction amount.None of them work well.
If your account is linked to the NEAR wallet, you can use Send MAX to transfer as much NEAR balance as possible. After that operation your account will be, in some sense, locked since you need to receive funds from someone to continue operating with it.
An alternative to getting ALL the funds from your account is deleting it and set another account as the target where all funds should go. This can be done via near-cli using near delete tobedestroyed.near receiver.near
It seems wNEAR is baked by wrap.near contract, but how does it work?
wrap.near holds w-near contract, which is FT [fungible token] implementation based on NEP-141 standard.
The idea is simple, you send native NEAR tokens and the contract keeps track of the balance of the sender account in its local storage, and there is a reverse operation which allows you to instruct the contract to send NEAR tokens back.
This FT always matches native NEAR token 1:1. "Wrapped" prefix in the name (wrapped NEAR or wNEAR) implies that it just turns native token into FT token. It was created to be compatible with Rainbow Bridge (Aurora) interfaces which allows to transfer FT across NEAR network <> Ethereum network (by locking the tokens in a contract on one network and unlocking the equivalent amount of tokens from a contract that is deployed on the other network).
So getting back to the technical implementation of w-near contract, you can find three core methods:
near_deposit expects NEAR native tokens attached to the function call, and those attached tokens will be deposited to wrap.near account, and in exchange the contract implementation will save a record in the storage that those tokens belong to the account that sent them
near_withdraw deducts the amount of tokens recorded for the account that called this function and sends a transfer of native NEAR tokens back to the caller
ft_transfer (it is implemented by near-sdk-rs helper) virtually transfers the wNEAR FT tokens by updating the records inside the contract storage. NOTE: there is no native transfer involved here, so the transaction will go from tokens sender to wrap.near contract, which will update the balances of the sender and receiver accordingly, and the receiver account will never receive a native NEAR call or NEAR tokens (until he/she calls near_withdraw)
To set up an account on the NEAR blockchain, it requires you to send some number of tokens to fund that account. For example, when using the NEAR Wallet to set up a new account, you have to fund it with 3N first. Why is this?
You can create a NEAR "implicit" account with 0 NEAR. Near implicit accounts are the same as in Ethereum or Bitcoin. You create the a keypair locally and the public key becomes your account id (a hex string, like in Ethereum or Bitcoin)
See here: https://nomicon.io/DataStructures/Account.html
and here: https://docs.near.org/docs/roles/integrator/implicit-accounts
You only need 3 NEAR if you want to create a "named" account, that is an account like alice.near that's way easier to use than implicit accounts like 641537c21dC82F97b7fC8AD778e99997beeE0d73
On NEAR, data usage is "funded" by holding a balance of tokens on the account which reserves the storage space. So, in order for the account to be created, it has to set aside some storage on the chain, which requires some amount of tokens to "pay" for those initial bytes of memory by sitting on the account.
This minimum balance depends on how much data the account uses and could start as low as < 1N for a basic account to ~40N for one with multifactor authentication and other bells and whistles added to it.
For more, see the docs at https://docs.near.org/docs/concepts/storage which describe the "state staking" approach used here.
Should I pay for every read from NEAR protocol?
How do I view the value stored in NEAR protocol smart contract? (e.g. staking pool fees)
What is the difference between view and change methods?
Should I pay for every read from NEAR protocol?
TL;DR: No, you should not.
In NEAR protocol there are to ways to interact with smart contracts:
Submit a transaction with a FunctionCall action, which will get the specified method executed on the chunk producing nodes and the result will be provable through the blockchain (in terms of near-api-js these are "change methods")
Call query(call_function) JSON RPC method, which will get the specified method executed on the RPC node itself in a read-only environment, and the call will never be recorded/proved through the blockchain (in terms of near-api-js these are "view methods")
You can change the state and chained operations (e.g. cross-contract calls, tokens transfer, or access key addition/deletion) only through the first approach since blockchain expects the user to cover the execution costs, so the user should sign their transaction, and they will get charged for the execution.
Sometimes, you don't need to change the state, instead, you only want to read a value stored on the chain, and paying for it is suboptimal (though if you need to prove that the operation has been made it might still be desirable). In this case, you would prefer the second approach. Calling a method through JSON RPC is free of charge and provides a limited context during the contract execution, but it is enough in some scenarios (e.g. when you want to check what is the staking pool fee, or who is the owner of the contract, etc).
Let's say I have a contract function that expects a certain amount of near to be send with a certain transaction, the function is called create_order, create_order takes a couple arguments.
I have my contract setup in the frontend under the name myContract.
I want to call myContract.create_order({...}) but the transaction fails because this method call doesn't have the right amount of NEAR tokens attached.
How do I assign a certain value of deposit to a transaction?
It's possible to use account.functionCall directly (without sugar for RPCs) to either attach amount or specify gas allowance for the call.
See Account#functionCall in nearlib.
Nearlib supports it using account.functionCall(..., amount). But it might not work, because of the design of the access keys with function calls. Default authorized access keys towards applications only allows function calls without attached token deposits (only prepaid gas). It's done this way to prevent apps from automatically using your balance without your explicit approval. Details on access keys are here: https://github.com/nearprotocol/NEPs/blob/master/text/0005-access-keys.md
The way to attach a deposit for the transaction should be done with the explicit approval from the wallet. The app should create a request for the wallet, redirect to the wallet for the approval (or through the popup). Once user approves the transaction, it's signed with full access key from the wallet directly and broadcasted. But I'm afraid we don't have this API on the wallet yet. Issue for this: https://github.com/nearprotocol/near-wallet/issues/56
AFAIK it is not supported at the moment. It will be available after this NEP https://github.com/nearprotocol/NEPs/pull/13 lands.