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.
Related
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.
When running a private Ethereum network not requiring gas for transactions, can a contract function transaction fail for some "unpredictable" issue, other than explicit invocation of assert()/require()/revert(), for example dividing by 0 or some other issue with EVM or beyond EVM?
division by zero
integer overflow/underflow in Solidity 0.8+ (previous versions let the number overflow, 0.8 throws an exception)
accessing out-of-bounds array index
message call (aka internal transaction) to an address that does not implement the called function (might have been selfdestruct or changed implementation behind a proxy)
These I could think of right now. I'm sure there's more examples, generally runtime errors cause by some logical mistake.
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.
This is the code that I'm using to send signed transactions to mainnet programmatically:
import Web3 from 'web3'
import EthereumTx from 'ethereumjs-tx'
const web3 = new Web3(new Web3.providers.HttpProvider(INFURA_URL))
const Contract = new web3.eth.Contract(ABI, CONTRACT_ADDRESS)
const createItem = (name, price, nonce, callback) => {
console.log(`Nonce: ${nonce}. Create an Item with Name: ${name}, Price: ${price}`)
const data = Contract.methods.createItem(name, price).encodeABI()
const tx = new EthereumTx({
nonce: nonce,
gasPrice: web3.utils.toHex(web3.utils.toWei('4', 'gwei')),
gasLimit: 400000,
to: CONTRACT_ADDRESS,
value: 0,
data: data,
})
tx.sign(new Buffer(MAINNET_PRIVATE_KEY, 'hex'))
const raw = '0x' + tx.serialize().toString('hex')
web3.eth.sendSignedTransaction(raw, callback)
}
export default createItem
I have to mass create (i.e. populate) items in my contract, and I want to do it programatically. However, while the code works well in ropsten, it fails to send all the transactions in mainnet; it only sends the first few transactions and doesn't send the rest. The errors are not helpful because this error is usually guaranteed to occur:
Unhandled rejection Error: Transaction was not mined within 50 blocks, please make sure your transaction was properly sent. Be aware that it might still be mined!
I wonder how other people do when they have to send a lot of transactions to Ethereum mainnet today. Is there anything I'm doing wrong?
You basically cannot reliably do what you guys are trying to do. Here's a set of problems that arises:
Transactions only succeed in nonce order. If an early nonce is pending (or worse, went missing), the other transaction will pend until the early nonce has been consumed (or it gets removed from the mempool).
There's no hard rule for when a transaction will drop from the mempool. This is scary when you've made a nonce error or an intermediary nonce has not reached the network for some reason because you don't know what is going to happen when you finally post that nonce.
Many transactions with the same nonce can be sent. They are very likely to be selected by gas price (because miners are incentivized to do exactly that). One useful trick when something strange has happened is to clear out your nonces by sending a bunch of high gas price, zero value transactions. You might call this an increment method. Remember this comes with a cost.
A lot of tools do one of two things to handle nonces: a live read from getTransactionCount() or a read from getTransactionCount() followed by incrementing for each additional transaction you send. Neither of these work reliably: for the first, transactions are sometimes pending but not visible in the pool yet. This seems to especially happen if gas price is below safemin, but I'm not entirely sure what is happening here. For the second, if any other system sends a transaction with the same address, it will not work.
So, how do we work around this?
A smart contract is a straightforward way to reduce a transaction from many sender nonces to few sender nonces. Write a contract that sends all your different transactions, then send the budget to that contract. This is a relatively high cost (in terms of time/effort/expertise) way to solve the problem.
Just do it anyway, batch style. When I've had to send many transactions manually, I've batched them in to sets of 10 or so and gone for it. Incrementing the nonce manually each time (because the transaction is usually not on the network yet) and then waiting sufficiently long for all the transactions to confirm. Don't rely on pending transactions on Etherscan or similar to determine whether this is working, as things often vanish unpredictably from this level. Never reuse a nonce for a different transaction that isn't a 0ing high gas transaction - you will screw it up and you'll end up sending the same transaction twice by mistake.
Serialize. One-by-one you post a transaction, wait for it to confirm, increment your nonce. This is probably the best of the easy-to-implement automated solutions. It will not fail. It might buffer forever if you have a constant stream of transactions. It also assures you can never have more than one transaction per block, limiting your throughput to 4 a minute or so.
Fire and retry. This is a little sketchy because it involves reusing nonces for different transactions. Send all (or some large batch) of your transactions to the network. If any fail, restart from the failure nonce and send again. There's possibly a more intelligent solution where you just try to swap out the missing nonce. You'll need to be very careful you never send a transaction that is secretly in the pending-but-not-visible pool.
New address for every transaction. A buffering step of distributing funds to your own addresses ensures you never screw it up for other people. It does double your transaction time and cost though.
I think some variant of fire and retry is what most of the big services (like pools and exchanges) do. Some of these can be improved by splitting the budget over a few addresses as available (reducing the collision frequency).
I want to get all receipt records of some address (address A) from blockchain. I use web3.eth.getBlock and web3.eth.getTransaction to get all transactions related to A.
But I find if ethers are transfered to address A by invoking 'A.send' or 'A.transfer' function in contract, I can only get a contract call transaction which from caller address to contract address. And I can't find relationship between this transaction and address A.
Is there any way to get transactions invoked by contract for A?
Thanks.
Short answer: listen to events instead of monitoring transactions.
Why can't I find the transactions "invoked by" the contract?
A contract does not invoke/create its own transaction (it doesn't have a private key to sign one). A contract can call other contracts during its own execution, as you've seen, but those calls are all executed as part of the same transaction.
The recommended way to discover executed function calls is to use events. If the contract you want to watch does not specify an event on the call you want to watch, you may be in for some heavy lifting: tracing every transaction's execution at the EVM level (something that big block explorers do to generate some of the extra info they provide).
If you are stuck tracing: you can find more about using ethereumjs-vm or geth's debug_traceTransaction on this Ethereum StackExchange Question about internal transactions.