New answers tagged gas
1
The difference can be explained by how the compiler implement those types.
bytesNN is fixed sequence of NN bytes while string is a dynamic array of bytes. Using string increases the runtime bytecode due to a few auxiliary function included by the compiler.
For a public variable the compiler has to create a getter function.
A constant declaration will be ...
1
The second approach will not have a computation cost of zero(0). Running computations on the blockchain that do not store any values will still incur a cost.
There will be some cost to the second approach. Events are generally cheaper than storage on ETH but not free.
Keep in mind that if you fire off an event from your Solidity code that event will get ...
0
i suppose the more restrictive it is, the more it is efficient, hence the reason why private would be more efficient than internal ?
EDIT : i mean the resulted code once compiled would be more efficient, at least that's what i'm thinking and makes sense to me, correct me if i'm wrong.
0
You're getting a gas estimation failed error, this means:
You don't have enough ETH to perform this transaction
If this is the case, get more ETH
You don't have enough ERC20 token to perform this transaction (like LINK, DAI, etc)
If this is the case, get more of the ERC20 token, or fund your contract with LINK.
You have some other issue with your logic ...
1
Aave employs the concept of an "index" - it's not that the protocol writes to the storage of all user accounts, but that the index gets updated and this is paid for by users. Later on, whoever queries the "balanceOf" function (which is free because is constant) will use the latest index to calculate the given user's balance.
This is ...
0
Method #1. There's no way that method #2 will be faster, because method #1 is method #2 + a chance for the transaction to confirm earlier.
If you send at 1pm a transaction with 10gwei/gas, if by chance there is low network activity, your transaction will get picked up.
If not, anyway you will speed it up at 2pm, same as method #2.
So you don't lose anything (...
2
Changing a value from 0 to a non-0 value will always cost 20,000 gas. There is no way to pre-initialise a variable with a value of 0, to make it not cost 20,000 gas when changing the value.
An alternative approach to get around this is to initialise the variable as 1, and use a getter to get the value of the variable, e.g.
contract Demo {
uint256 private ...
2
Gas is the measure of computation required to execute your transaction, depending on what functions your contract uses the gas used changes. This is analogous to the transaction bytes size in Bitcoin transactions.
The fees you set are how much gwei you are willing to pay for each gas unit, that's why it's PerGas. It's analogous to the satoshi/vbytes in ...
0
Your contract looks like a Synthetix derivative. If that's the case, then updateReward is here: https://github.com/Synthetixio/synthetix/blob/develop/contracts/StakingRewards.sol#L152
The Synthetix contract uses a complicated staking algorithm. That means it's not very cheap to use. But the good thing is that the cost doesn't go up as the number of stakers ...
0
it's pretty easy. you do it like this. via signatures. you need a backend....
function matchAddresSigner(bytes32 hash, bytes memory signature) private view returns (bool) {
return _signerAddress == hash.recover(signature);
}
with
require(matchAddresSigner(hash, sig), "no direct mint");
....
0
There's some difference in behavior but in your example the gas consumption is about the same. An array has to maintain its length and your mapping uses a counter instead. All data in the array is stored continuously and the mapping is spread in the store but that doesn't affect the costs.
0
Let's find out the answer empirically, with Remix. Take this contract:
// SPDX-License-Identifier: Unlicense
pragma solidity >=0.8.9;
contract SingleConstant {
uint256 internal foo;
function getFoo() external view returns (uint256) {
return foo;
}
function getFoo(uint256 newFoo) external {
foo = newFoo;
}
}
...
0
There is a better way to ensure specific transaction order inside the block - use flashbots. It allows you to send a bundle of transactions guaranteeing that they will be mined in a block in this exact order next to each other. Futhermore, if one of the bundled transactions reverts the entire bundle will not be included in a block so you don't have to pay ...
0
Yes, it is always free to call the view function outside the contract. However, they do cost gas when you call it inside a transaction.
0
edit Per the comment on the OP, the hex keyword allows direct packing of hex bytes into a contract. For example,
function bytes() external pure returns(bytes memory) {
return hex"12ABCD"; // Can be arbitrarily large; only takes up byte-sized space in gas
}
—
You could also do this with assembly code. Simply direct-packing the bytes array ends ...
1
After a bit of searching I figured out that the receipt should be the mined object.. I also wasn't sending any value with the transaction.
const addr1Bal = await provider.getBalance(addr1.address)
const txValue = ethers.utils.parseEther('0.03').mul(BigNumber.from('4'))
const tx = await contract.connect(addr1).mint(4, { value: txValue })
...
0
This means 1 of 2 things:
You need to set a manual gas price with something like:
some_gas_price = 100000
contract.deploy({"from": from_account, "gas_price": some_gas_price})
or you could use a gas strategy:
from brownie.network.gas.strategies import GasNowStrategy
.
.
.
contract.deploy({"from": from_account,"gas_price&...
1
Isn't the speculation over cryptos actually bad for the blockchain itself?
Any native blockchain medium of exchange of unit of accounting must be disconnected from a political currency, like USD or Yuan, as otherwise it would very hard to achieve a global consensus mechanism, where global being working across geopolitical adversaries.
the more a currency ...
0
I believe it is not an issue because if the price increase so much then transaction fees will go down as per need. And the high amount of transaction creating bottle neck is somewhat resolved in EIP-1559. And still if the organisation thinks the transaction cost it to high for them then, they can switch to parachain like BSC or Polygon.
0
A very simple solution: you can have a nonce in your contract storage.
uint256 contractNonce;
uint256 f;
function setF(uint256 newF, uint256 providedNonce) public {
revert(providedNonce <= contractNonce);
f = newF;
contractNonce++;
}
1
require(msg.value <= 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff) // or type(uint256).max/2
would work. Its unlikely someone try to send more than 5.7*10^58 ETH to your contract though x)
1
It uses web3.eth.estimateGas (https://web3js.readthedocs.io/en/v1.2.11/web3-eth.html), which basically runs the transaction locally and returns the amount of gas used. It's pretty good most of the times but it can definitely get it wrong. Not sure in which specific cases though.
Top 50 recent answers are included