I’ve made another update now, to move the opcode for SELFBALANCE to not collide with CHAINID, in case both gets accepted
@holiman why is the SELFBALANCE instruction at 0x47 and not 0x46 (which is the next free slot)?
Answer: EIP-1334 CHAINID opcode is proposed to use 0x46.
Yeah, as I wrote in the comment just above your question:
I must get better at expressing myself more clearly 
I think it’s clear, I was probably in write-only mode 
Specification looks great.
Requesting to add a reference please to EIP-165 and any other EIPs which are based on fixed gas costs. This could go under the backwards compatibility section. This proposal affects 165, but does not kill it. Just hoping to have this note there to set a precedent for future EIPs to perform a similar analysis.
Can you explain the effect and what exactly should be added to 1884? Perhaps even: could you open a PR adding it?
@fulldecent this message was mean to you but, FEM isn’t displaying the “replying to” header for some reason.
Hello Group
thanks for the chance to participate
I am currently a leading smart contracts developer for Kyber.
Kyberswap dapp is up and running a while now serving large number of users.
This change will create substantial additional gas costs for a trade on Kyber. (30%)
And thus affects the quality of service we give to our users.
It seems unreasonable to me an infra change will create a price raise in this magnitude to applications relying on it (dapps). It makes the infra layers practically dangerous to rely on.
Just imagine an infra change introducing changes of this magnitude to credit card services.
Saying all that, I saw the concrete data that supports introducing the change.
I claim infra changes of this magnitude, must take into consideration the dapps point of view. The Dapps running over Etheruem are the first “business partners” and their perspective should be considered. Since this is a shared path.
Let me suggest that in spite the math behind the numbers being very solid. Raising gas costs must be done more gradual.
Thank you
Ilan
I have to agree with Ilan. I’m with bZx and our dApp is the third largest on Kyber. We rely heavily on Kyber and perform multiple swaps. This would explosively increase the gas cost of running our contracts and the adverse effects could be severe. Such a rapid increase is extremely alarming.
I have stated this before but I want to note it again.
In general in the design of EVM I do not understand why we have things as EXTCODESIZE and CODESIZE. I can’t imagine that a simple check in one of the blocks regarding EXTCODESIZE to check if we are calling on the current address adds any significant overhead. Hence I do not see why these opcodes are not merged together in a single opcode where the gas price depends on the address you are calling on (an external address costs more gas).
I do understand that an extra opcode SELFBALANCE is consistent with the other opcodes CODESIZE and CODECOPY so adding this seems reasonable. However on all existing contracts which call their own balances (which are by no doubt a significant amount of contracts) a developer would like to change the BALANCE opcode to the new SELFBALANCE opcode regarding this EIP - but of course this is not possible in most if not all cases.
Why can’t we add an extra clause to the BALANCE opcode where "if BALANCE is called on the current ADDRESS the gas cost will be the same as SELFBALANCE" gas cost. I would like to propose this on EXTCODESIZE and EXTCODECOPY regarding CODESIZE and CODECOPY respectively too - so maybe this would be better in another EIP.
It just does not seem reasonable to me that in the current EIP the gas cost of an opcode is increased (BALANCE), but a new opcode is added (SELFBALANCE) where in some situations the “old” (BALANCE) opcode performs the exact same operation - but with more gas.
What is confusing is that in test cases it says "Test that balance(this) costs as before, " - this implies that reading the current account balance gas cost is the same - but it does not state which opcode is used for this?
3 Likes
Welcome @ilanDoron.
In my opinion, repricing is a necessary evil in order to reflect the actual cost of particular operations. Although it may not be the exact rationale for the opcodes in the original post, mispricing has led to DOS attacks in the past. Underpaying miners for their computation (thus losing security) is also a risk if pricing is not adjusted to reflect reality.
edit:
To be clear, I do think it’s important that dapps be affordable to users, but I think the way to do that is by reducing the overall gas price, not underpricing ops.
I also think that not breaking functionality which depends on outdated gas pricing assumptions is an important consideration.
1 Like
@axic thank you for the ping
Proposed fix for backwards compatibility:
Thank you for Your reply
I Agree opcodes should be correctly priced.
In this case we have two issues.
price change is very big and also it breaks one or our contracts.
I suggest the opcode repricing be done in a gradual fashion.
Looking forward, Etheruem being an infra layer, is dictated to have stable costs, as much as possible.
Which makes it more reliable to develop dapps using it.
This opcode repricing is an example which makes this layer less reliable as development infra.
Hey guys. I just realized something when I was thinking about using contracts in combination with CREATE2 to store large amounts of data (reading them from external contracts gets cheaper if you read a lot of data - see this article (not mine) about someone who researched this exact approach).
The problem relies on the fact that the proposed increase of SLOAD is from 200 -> 800. This is more than EXTCODECOPY (700 gas + 3 gas per word). This means that it is cheaper even reading a full slot (32 bytes / 8 words) using EXTCODECOPY. Correct me if I am wrong but this would cost 700 + 32/4 * 3 = 724 gas to read 32 bytes from an external contract. This does not seem rational to me and if this happens this might have the unintended side effects of people going to SSTORE data in other contracts (FYI: SSTORE equivalent: deploy a contract where the code is the storage, the actual storage of this contract would be empty) especially if those things are going to be read a lot (as opposed to writing it a lot which is pretty expensive). This might get some effects which were unintended like, for example, the GasToken which “abuses” the gas refund counter. We might hence see people deploying read-only contracts if this EIP gets deployed as-is because reading it is cheaper (and it will get much more cheaper if you start reading for example 2 slots - 748 gas as opposed to 1600 gas!).
Proposed solution would be to either bump EXTCODECOPY or to lower the proposed 800 gas for SLOAD.
3 Likes
Strange indeed. Maybe not a desired behaviour but loading contract bytecode is indeed much cheaper becase code is not stored in the Patricia tree.
1 Like
I was not aware that this was in fact cheaper so it is good that this is cleared up (note: not exactly aware about the storage location of the contract code / storage slots and the cost of looking these up - I assumed those were about the same). I do wonder if the EIP proposers are aware of this semi-weird gas pricing though, as this might bring these unintended (?) side effects (a la GasToken) at the Istanbul fork.
@holiman? I believe this is safe (although a bit awkward if it becomes a common practice and it may lead to the following EIPs having to deal with even stranger legacy contracts).
Is there a fundamental need for geth to lookup data in a SLOAD operation in a patricia merkle tree? It’s obvious that it is necessary to create the tree to calculate the storage tree root, but why can’t there be a constant-time lookup cache layer for reading these values? According to a recent analysis by Péter (here: https://twitter.com/peter_szilagyi/status/1166633058348556288) the raw uncompressed size of storage data is 15.32 GB, potentially allowing a reduction to below 9GB, which should enable a quite efficient cache.
If this is the case, then the increase in SLOAD time is more due to the implementation decisions taken by the client which can be fixed without a network upgrade. Given the current (relatively high due to recent client optimizations) gas cost for SSTORE, adding a slight cost with additional caching here while gaining considerable lookup speed for SLOAD should increase the performance overall significantly.
1 Like
After collecting more feedback on this from many involved like Péter Szilagyi, @holiman and @AlexeyAkhunov (turbo-geth) it is clear that actually a lot of work is currently going into getting constant-time lookup into geth, either as a side-effect of a new sync protocol or in the form of a new database layout.
I know that it is pretty late in the process, but knowing that this will be fixed client-side in the foreseeable future which might even require to make it a lot cheaper again, combined with the concerns from major projects and from new projects we are in contact with (which are afraid to choose Ethereum due to being less able to rely on it still working for them in the future - I know there are a lot of arguments for and against this, but it is a fact that EIP-1884 is being used as an argument against Ethereum), why not focus on the client implementations and drop this quite contested EIP?