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
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...
Nick Johnson
@Arachnid
From the YP, appendix g:
Gcallstipend 2300 A stipend for the called contract subtracted from Gcallvalue for a non-zero value transfer
Ghost
@ghost~55c3ed250fc9f982beac84b3
Also, regarding the intent of EIP-1283 (which was previously EIP-1087), it was mainly to enable inter-frame communication within the same transaction. I wrote an alternative EIP, which has the same intent, but does not have the issue of EIP-1283 (1087): https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1153.md. Of course, I did not know about the the problem with EIP-1283/1087. What I am saying - if the demand for this change is really high, we can still do it, and even cheaper
Nick Johnson
@Arachnid
@Vendoreth_gitlab This is not the place to ask; please find a more appropriate channel.
Piper Merriam
@pipermerriam
@Vendoreth_gitlab this isn't the place to get individual support, try ethereum.stackexchange.com
Alex Beregszaszi
@axic
Also note there were some proposals to even increase the gas stipend. Here’s the EIP with reasoning: https://eips.ethereum.org/EIPS/eip-1285
Nick Johnson
@Arachnid
@jbaylina We absolutely should not encourage using selfdestruct to send; it's a nasty edge case, and allowing contracts to react to value transfers is a feature, not a bug.
Piper Merriam
@pipermerriam
Would this be considered a non-issue if the solidity docs were updated to 1) make it clear that these APIs don't protect against re-entrancy and 2) make it clear that re-entrency protection using GAS stipends isn't viable.
Micah Zoltu
@MicahZoltu
The real invariant people want is something that I don't think we can reasonably provide (reentrancy protection). The first-level proxy invariant people want is, "this call can't result in a storage update before it returns" (something I have always been against because it means contracts can't do interesting things when receiving ETH).
Nick Johnson
@Arachnid
@pipermerriam It's not just a Solidity issue, it's in the EVM. And I think it's far too late to change this invariant.
@MicahZoltu We could provide something like that by introducing a new call type, but that's a lot of extra complexity.
Micah Zoltu
@MicahZoltu
@Arachnid Yeah, I'm not a fan of it, but I think it is what people want (people often want things that are bad for them).
Nick Johnson
@Arachnid
@Vendoreth_gitlab Unless you need help updating an Ethereum client implementation you maintain to support Constantinople, this is not the appropriate place.
@MicahZoltu Right now what we need to do is preserve what people have.
Micah Zoltu
@MicahZoltu
While I am a fan of backward compatibility, I'm not a fan of getting locked in to decisions forever either beacuse people wrote code that makes assumptions it shouldn't have made. I can appreciate delaying a change like this for some amount of time to give people time to deal with it, but I'm not a fan of asserting that "we will always have this debt because one or more people may have made an inappropriate assumption while writing code". Knowing that the stipend value was set at the EVM layer may be enough to gain my support in delaying this EIP for a whole HF cycle, but I'm not convinced that we should permanently hack around it or indefinitely support the idea that < stipend means no storage changes.
Nick Johnson
@Arachnid
I mean, I'm not a fan of that either. But I don't think breaking existing code like this is an option we have. Part of the point of deploying on Ethereum is that your code will keep functioning the same way tomorrow as it does today.
It'd be particularly nasty to make non-backwards-compatible changes in an environment where there's no built in mechanism for upgrading code.
One of the big selling points of using Ethereum is that if I want, I can eliminate all trusted parties from my code: no owner, no trusted upgrade mechanism, nothing. We break that if we start introducing changes that retroactively make secure contracts insecure.
Micah Zoltu
@MicahZoltu
I have always suspected that Ethereum will eventually need to fall into that sort of mode (I call it Enterprise mode), where there are strong guarantees of no breaking changes. I guess I had hoped that we weren't there yet because I think Ethereum still has a lot of improvement necessary that won't be possible under that sort of constraint.
Perhaps the saving grace is Ethereum 2.0? We can run Ethereum 1.x in Enterprise mode indefinitely, yet gain benefits from lessons learned in Ethereum 2.0 where we can make all sorts of breaking changes.
Nick Johnson
@Arachnid
I think we've always been in "no breaking changes" mode, personally, ever since mainnet launch.
People use the network to do real things with real stakes.
And yes, 2.0 gives us lots of opportunity to make things better.