I want to estimate gas of minting erc20 token without deploying contract. I am aware of contract.estimateGas but I dont have any contract address to test it. Is it possible to do it without providing contract address?
Each ERC20 contract can have different gas requirements, depending on its implementation.
Generally, token mint consists of one storage write, one event log, few memory operations, and usually one storage read (validating whether the user executing this function is authorized to mint tokens)... Which in total usually costs tens of thousands gas units.
But the actual cost is affected not only by the amount of operations but also number of functions in the contract, whether the mint function is external or public, and many other factors.
TLDR: "Usually tens of thousands of gas units" is the closest you can get without estimating against a specific implementation.
Related
Is it possible and or advisable to, in one step, deploy a smart contract, have it mint 50 nfts and send those 50 nfts to 50 different addresses all in one transaction?
Or would it be better practice to split these 3 different actions into two different transactions?
Would love any references to existing smart contracts that do anything similar!
Thank you!
It is not advisable to run Solidity functions with long running for loops that may exhaust the available gas. Because you are minting 50 NFTs it is likely you cannot fit all the execution function to a single Ethereum transaction and you need to do minting in smaller batches.
I deployed my smart contract(ERC-721) on truffle (Rinkeby | Ropsten | local node) and again on Remix and I keep getting an average cost of 0.0165 ether. This gas fee seems unrealistic to me, even though my contract is pretty simple.
I finally tried deploying to MAINNET using Truffle and the transactions stopped due to a low gas value. I switched over to REMIX and the new total gas fee is 0.65 ($2500) ether.
Is this a realistic amount to deploy a smart contract? or do I need to change some setting on remix?
Do the testnet's give a good representation of what gas fee will cost on mainnet ?
The amount of gas used from gas limit, not the gas price is going to be consistent between mainnet and testnets as the gas used from gas limit represents the amount of work that needs to be done to process the transaction logic in the EVM. Gas price (how much you pay for a unit of gas used) fluctuates as it is dependent on market economics/game theory, which is going to be very different on a test network vs live network.
References
https://ethereum.org/en/developers/docs/gas/
Is it possible to store gas that is not used inside a contract, so it can be used at a later time (presuming it is possible to require a certain amount of gas calling a function)?
I am trying to write a contract that requires user input and does something based upon that input at a later moment in time that will require gas.
As it does not sound really attractive to pay that gas out of the contract owners pocket I am looking for a way to make the user of the contract pay for the gas it needs to complete the request.
In fact, it is really possible to store gas in a contract for later use.
There are some operations in EVM that can return some gas that was payed before:
SSTORE: changing storage value from non-zero to zero releases 15000 gas
SELFDESTRUCT: destroying contract releases 24000 gas
That means that e.g. storing some value requires 20k gas, but deleting it form storage requires only 5k gas and releases 15k gas for later usage in the same transaction. Actually this is a reward for clearing up blockchain storage.
You can get more details by searching "refund" in Yellowpaper.
There is GasToken project that uses this very feature to store gas in contract when it is cheap and release (and use) when it is expensive.
To be clear, I don't think this allows user to issue transactions without paying gas at all.
Seems like you have mixed up a little bit the meaning of gas.
The gas is the Ether you have to pay to have your transaction mined. The gas is always paid by the address that calls the function(Contract) and not from the Contract itself or the owner of the Contract so it doesn't come out of the owners pocket. Also gas is basically ether so "storing gas" is to store Ether in a contract but you cannot store the gas that is used to mine the transaction. If you want to store Ether you have to send Ether to the Contract or have the users send Ether when they call a function.
I have been looking high and low about how to withdraw the funds from an Ethereum contract with no prevail. The Remix editor is giving the warning that this function may cause an infinite loop.
Gas requirement of function KOTH.cleanTheKingsChest() high: infinite. If the gas requirement of a function is higher than the block gas limit, it cannot be executed. Please avoid loops in your functions or actions that modify large areas of storage (this includes clearing or copying arrays in storage)
And...
Should I use Open-Zeppelin's safe math for this function?
function cleanTheKingsChest() public isOwner {
uint bal = address(this).balance;
address(owner).transfer(bal);
}
This will transfer all ether held by the contract to the owner’s address. There is no issue with the way you’re doing it.
The reason for the warning is because you are making a call out to another address. That address could itself be a contract with a custom defined transfer or fallback function (if no transfer method is defined). Since Remix doesn’t know what that implementation may do, it’ can’t estimate the gas usage. This isn’t a concern since transfer calls are limited to a 2100 gas stipend.
You don’t need SafeMath for that function since you’re not doing anything that can cause an overflow. However, in general, it’s a good idea to use it.
I have recently downloaded the GUI wallet, and it gives the option to create contract based wallets and connect to them to a main account. What is the difference between using a contract based wallet and an account? And what should be used to store my ether?
Contract-based wallets are more robust and can be more secure. For example, a contract can be setup to require transfers over a certain threshold to be approved my multiple people/keys. Even if these keys all reside on your local computer, having to compromise even a slightly-improved 2 of 3 can provide far greater security than a single key alone.
Additionally, contracts benefit from transaction receipts, which contain a permanent log of all events. This makes it much easier to inspect the state and verify the history of a contract. For example, when a new transaction request is initiated against a wallet contract requiring multiple signatures, an event log for "ConfirmationNeeded" with the operation ID will be added. After the operation has received the appropriate number of signatures, a "MultiTransact" might occur containing the recipient, value, and associated data with the transaction.
Standard accounts benefit from none of this and can only send transactions, not respond autonomously.
Here are advantages and disadvantages for comparison.
Advantages of contract-based account wallets:
Funds are not stored on a single key.
You can cycle through management keys.
Mutisig functionality; only execute a transaction on majority rule (eg. Gnosis Multisig)
Allows for account recovery, in case your management keys are lost (eg. Argent).
Set transfer and withdraw limits enforced by the contract.
You can have access controls for keys, meaning you can restrict what methods a key can invoke. Useful when you want to delegate control to someone else but restrict what they can do.
Batched transactions; execute multiple transactions as 1 atomic transaction.
Defi protocol composition; easily integrate with other smart contracts (eg. one-click DAI saving rate accounts)
Meta transactions: pay your transaction costs using a different asset, like a token (eg. Gas Station Network). Relayers may also offer free transactions (eg. Authereum)
Disadvantages of contract-based account wallets:
Contract are susceptible to attacks; people write buggy code all the time (eg. Parity hack). An Externally-owned account (EOA) can't be hacked because there is no code to hack.
Backward incompatible features may render funds locked if contract not properly written. (eg. Istanbul hardfork gas cost changes)
Deployment costs; unlikes key pairs which doesn't cost anything to generate, there's a fee cost for deploying contract-based accounts.