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
Adrian Sutton
@ajsutton
When the dust settles we’ll need to work out what to do with Ropsten (and other test networks) where Constantinople has already shipped.
Micah Zoltu
@MicahZoltu
@holiman I think we should have a more extended discussion on that EIP before cutting it entirely, and more impact analysis.
Péter Szilágyi
@karalabe
@holiman PTAL ethereum/go-ethereum#18454
Martin Holst Swende
@holiman
@MicahZoltu yeah, I agree. I was just summarizing the general discussion in the call
Micah Zoltu
@MicahZoltu
:thumbsup: To echo what @Arachnid alluded to earlier before I told him to be quiet, we can't forever be stuck with high gas costs because some people write bad code.
Péter Szilágyi
@karalabe
I think we need to murder the gas stipend
Micah Zoltu
@MicahZoltu
My personal vote on next steps would be to simply delay Constantinople to give people time to upgrade their contracts, withdraw their ETH, etc. given the upcoming change, as well as time for people to do some EVM analysis to find potentially broken contracts with lower false-positives. However, I don't think that we should not implement this EIP, and I don't think we should delay this EIP by another HF (6 months).
Taylor Monahan
@tayvano

Moving information from ZOOM chat to here for posterity

From Yoav Weiss to Everyone: (12:15 PM)

Since we're delaying the fork and have time to fix it now, I'd like to re-propose the fix I brought up earlier: Accept the EIP to lower the SSTORE fee, but add a condition that reverts storage access if gasleft < 2300. This preserves the original intention of the EIP (lowering the fees) while preventing exploitation. It is unlikely that a legit transaction will need to access storage while gasleft < 2300.


From Yoav Weiss to Everyone: (12:15 PM)

So when we apply the fork again, maybe we could do that and keep it as close as possible to the original fork.


From Nick Johnson to Everyone: (12:18 PM)

Yoav, that’s an excellent idea for a fix.

Vitalik (audio)
(expresses some hesitance around not being certain about full extent of vuln? more analysis would need to be done)

Nick Johnson
@Arachnid
I really like Yoav's idea; in my mind it's the purest expression of the current invariant (that 2300 gas is not enough to make a state change).
Alex Beregszaszi
@axic
I think it is a reasonable workaround to fix it, but we also need to keep in mind it is another tiny condition introduced into the design. Will this limit us even further in the future?
Nick Johnson
@Arachnid
I personally think it's the reverse - it makes an existing invariant self-contained instead of depending on other factors.
Martin Holst Swende
@holiman
It's a patchy patch, might work but adds tech debt IMO
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.
Alex Beregszaszi
@axic
https://eips.ethereum.org/EIPS/eip-214
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.