Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Nick Johnson
@Arachnid
If we'd had that condition to start, this would never have been an issue - it's only an issue because the conditions required aren't local.
Micah Zoltu
@MicahZoltu
Would the proposed change mean that if the last instruction of a contract is a storage update, then that transaction will always demand excess gas?
Nick Johnson
@Arachnid
It would, which isn't a problem on its own (anything that offers a refund also requires 'excess' gas) but it would complicate gas estimation code a little.
Actually, that last bit isn't true - current gas estimators do a binary search until the execution succeeds.
Micah Zoltu
@MicahZoltu
Also, we would need to have this not apply to simple ETH transfers I'm guessing, since they currently use exactly 21,000 gas (and there is a lot of tooling that depends on this). I doubt this is a problem since I'm guessing this logic would be part of EVM execution, not simple value transfers.
Nick Johnson
@Arachnid
@MicahZoltu Simple ETH transfers don't get the gas stipend (Which is irritating; I've been meaning to propose an EIP to change that).
Ghost
@ghost~55c3ed250fc9f982beac84b3
I would say this - it is likely that we will be changing the cost of SSTORE again soon - to manage the state size growth. I do not exactly know how. So I would not rush re-introducing this EIP unless it is really critical for something. Like REVERT in Constantinople, it makes the gas pricing fairer, but it does accelerate the state growth, unfortunately (because by saving gas on SSTORE, more state expansions can be done in one block)
Nick Johnson
@Arachnid
@AlexeyAkhunov It doesn't accelerate state growth - with this EIP, the cost of a SSTORE that actually enlarges storage remains the same. Only SSTOREs that result in no net change are cheaper.
Wei Tang
@sorpaas
@MicahZoltu @Arachnid I think it wouldn't, given that it's applied with net metering together. Anything that previously doesn't revert, won't revert.
Nick Johnson
@Arachnid
In fact, only SSTOREs that don't result in additional disk writes are cheaper.
Ghost
@ghost~55c3ed250fc9f982beac84b3
@Arachnid I understand that perfectly. What I am saying is that now that SSTORE is generally cheaper, there is more gas left in the block to do anything else, which includes state expansion :)
Micah Zoltu
@MicahZoltu
Heh, are you arguing effectively that we should only increase gas costs of all/any things?
Ghost
@ghost~55c3ed250fc9f982beac84b3
The same logic is why we saw Ethereum clients working much harder after Byzantium - because of the REVERT
@MicahZoltu Sort of
Nick Johnson
@Arachnid
@AlexeyAkhunov Did we see that?
Alex Beregszaszi
@axic
@AlexeyAkhunov hmm, that is an interesting observation
Geoff Hayes
@hayesgm
What about performing STATICCALL instead of CALL when performing an Eth transfer with <= 2600 gas?
Corey Petty
@corpetty
what are the most common types of smart contracts the could be vulnerable? trying to be clear in the blog draft
Micah Zoltu
@MicahZoltu
I'm generally with @holiman that @Youv's proposal introduces "yet-another-special-case" that needs to be coded for. Since it protects/encourages people doing what I personally consider to be a bad practice, I'm don't think the increased debt is worth it.
Ghost
@ghost~55c3ed250fc9f982beac84b3
@Arachnid Yes, I remember discussing it in this chat some months ago
Nick Johnson
@Arachnid
@hayesgm That was @vbuterin 's suggestion on the call.
Does STATICALL preserve log outputs, though?
Alex Beregszaszi
@axic
@hayesgm that was a proposed solution, but that restricts the contracts from doing other things they were allowed to do
Geoff Hayes
@hayesgm
Ah yes, and reverts.
Nick Johnson
@Arachnid
@MicahZoltu Whether we think it's a bad practice or not, we can't change that; it's an invariant that it's too late to break.
Alex Beregszaszi
@axic
@AlexeyAkhunov so basically a node can have a large pool of transactions, e.g. which have a total limit of 20M gas, and include more and more as transactions stop early with reverts
Micah Zoltu
@MicahZoltu
@Arachnid Eh, I'm not convinced it is an invariant. It is a common "best practice", but it is well known that gas prices can change and people (me) have been trying to warn others about that fact for some time (since those people started recommending stipends as a best practice).
Ghost
@ghost~55c3ed250fc9f982beac84b3
@axic Yes, previously lots of contracts used "throw" as an invariant check - that used to burn lots of gas, but without any work needed to be done
@axic With reverts, the invariant checks became much more economical
Micah Zoltu
@MicahZoltu
@axic What other things do Static Calls stop other than storage updates?
Jordi Baylina
@jbaylina
For me, this is the best way to transfer ETH without the reentrancy danger: https://www.reddit.com/r/ethdev/comments/6ekz2j/a_secure_way_to_make_a_send_in_ethereum/
Alex Beregszaszi
@axic
@MicahZoltu well, one edge is case doing a CALL, which they can
Ghost
@ghost~55c3ed250fc9f982beac84b3
and we saw that when you do a full sync (I did it many many time), the going gets tough after Byzantium
Micah Zoltu
@MicahZoltu
@axic Ah, I kind of assumed all CALL operations were auto-converted to STATIC_CALL operations at runtime.
Any attempts to make state-changing operations inside an execution instance with STATIC set to true will instead throw an exception. These operations include CREATE, CREATE2, LOG0, LOG1, LOG2, LOG3, LOG4, SSTORE, and SELFDESTRUCT. They also include CALL with a non-zero value. As an exception, CALLCODE is not considered state-changing, even with a non-zero value.
LOG* is the major reason token contracts would have code in the “fallback” function
Micah Zoltu
@MicahZoltu
Yeah. The inability to log is quite unfortunate.
Make .transfer be KINDA_STATIC_CALL, which allows LOG*. :wink:
Alex Beregszaszi
@axic
I’m sure it is possible to formulate a proper EIP defining this special case how to execute a function which only has the stipend, but it is not as simple as saying “it turns into a staticcall”.
Micah Zoltu
@MicahZoltu
:thumbsup:
Geoff Hayes
@hayesgm
I honestly think the best long-term solution here would be to allow contracts to specify an EVM-version or set of EVM-flags. This way you could always depend on your contract working a specific way, but we could allow new contracts to have different behavior (e.g. the benefit of lower gas costs). The problem is that contract-to-contract calls would become difficult or impossible to analyze. It would also make it clear that contracts cannot depend on certain aspects of remote contracts, such as gas limits on unknown code.
Micah Zoltu
@MicahZoltu
@hayesgm I think, for the reason you mentioned at the end, that would not actually resolve this particular issue.
Nick Johnson
@Arachnid
@MicahZoltu I'm pretty sure the gas stipend was designed with this in mind. There's a reason it's greater than the cost of a log4 but less than the cost of an SSTORE.
Micah Zoltu
@MicahZoltu
@Arachnid I agree that .transfer and .send were designed with this in mind. I guess the question is whether Solidity behavior is part of the larger Ethereum "guarantee" or not?
Nick Johnson
@Arachnid
@MicahZoltu The gas stipend is built in to the EVM, it's not a Solidity feature.
Micah Zoltu
@MicahZoltu
Hmm, I thought Solidity compiled .transfer down to CALL ... 2300 ...?
Nick Johnson
@Arachnid
At this point I don't think we can, or should, remove the invariant. And even if we come up with another solution for the net gas metering change, I think we should consider adding the gas > 2300 restriction to clients anyway. Presently we have an invariant that's not explicitly enforced anywhere. We should add a guard that explicitly ensures the invariant is preserved.
@MicahZoltu No, a CALL with value > 0 and gas < 2300 will automatically provide 2300 gas instead.
Micah Zoltu
@MicahZoltu
Ah, I see...