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
James Hancock
@MadeofTin
I have always thought about it as “immutability” and “decentralization” as the primary directives for ETC and ETH. But, that is just my observation.
Hudson Jameson
@Souptacular

@/all All Core Devs Call in 8 hours

Agenda: ethereum/pm#138

Hudson Jameson
@Souptacular
Btw just updated agenda to include most recent comments.
James Hancock
@MadeofTin
@econoar Just following up I am still working on the IceAge update.
Tim Beiko
@timbeiko
@Souptacular count me in for the EIPIP meeting :smile:
Wei Tang
@sorpaas
@timbeiko re https://twitter.com/TimBeiko/status/1195352606501228547
That tweet is not actually accurate -- EIP-1702 is always a part of EIP-2348. We're rather discussing, that it's unnecessary to add another account versioning solution (EIP-1707 code prefix) when you already have an account versioning solution (EIP-1702).
Tim Beiko
@timbeiko
Thanks for the clarification, Wei! I’ll share the update.
Danno Ferrin
@shemnon
EIP1702 is referenced as a standalone EIP, because it’s been published. The other bits I pulled in are from EIPs that never got to the published state. The cherry pick of BEGINDATA got published so I reference that via EIP as well.
they are in the “requires” section.
Wei Tang
@sorpaas

Regarding the discussion in the meeting on tooling support for EIP-1707 code prefix vs 44-VERTXN account versioning extension. Thanks to MrChico for spotting this -- the concern on 44-VERTXN's ecosystem tooling support can be wholly addressed just by making the version field optional with default value 0. https://specs.that.world/44-vertxn/

This I believe, from all information I have in hand, means that 44-VERTXN is nearly superior in all aspects compared with EIP-1707 code prefix.

Ghost
@ghost~55c3ed250fc9f982beac84b3
I know one use case for versioning that I recently thought about - it is deprecation of opcodes. There are some opcodes that we would like to deprecate, but it is hard to enforce it without either breaking some deployed code, or versioning. (For example, if one wants to deprecate CALLCODE, or even GAS opcodes)
Paweł Bylica
@chfast
@ppratscher Aleth 1.7.0 supports Istanbul. I wander who is this guy running the single Aleth node :)
James Hancock
@MadeofTin
:)
Wei Tang
@sorpaas

I know one use case for versioning that I recently thought about

The biggest use case for versioning is definitely to avoid the next situation similar to EIP-1884. EIP-2348 discussed today does not do anything about that at all. However, fortunately, we have this covered. ethereum/EIPs#2341

Danno Ferrin
@shemnon
EIP-1884 was about mispriced gas code. As long as there is a window between the announced fix (via spec) and mainnet deployment then there will be a wide open window to set up abusive contracts. Unless those contracts are forcefully deleted (good luck) the network would still be at risk. Versioning won’t be able to address that.
Wei Tang
@sorpaas
@shemnon That's where you got it completely wrong. If you want to understand how the issue can be fixed, refer to the devcon talk (https://twitter.com/sorpaas/status/1188611187413585920) or the forward-compatible EVM proposal ethereum/EIPs#2341
Danno Ferrin
@shemnon
One thought I’ve been mulling around is gas surcharges in addition to the in EVM gas pricing. It would involve tracking two gas consumptions but the EVM keeps it’s prices and the surcharge is applied w/o causing OOG in CALL code. The details to be worked out is would the surcharge be checked only once or as the surcharge is applied to the calling account’s gas limit. Kind of like in US sales transaction you have the cost of the item, then taxes, then all sorts of add ons.
Wei Tang
@sorpaas
No disrespect, but you're just reinventing the wheels here..
Danno Ferrin
@shemnon
Gasless is more than just versioning.
Ghost
@ghost~55c3ed250fc9f982beac84b3
I think as I understand it, EIP-2341 as basically disallowing the GAS opcode (and perhaps other mechanism that allow contracts to observe current left-over gas), but also preventing the CALL/DELEGATECALL/STATICCALL opcodes to dispense gas to the dependent invocation (essentially, either removing the first argument altogether, or making it "mute"). I am watching the video with your talk now, @sorpaas
Yeah, I see the answer to my question in the talk now :)
Ghost
@ghost~55c3ed250fc9f982beac84b3
What I would look at, regarding the Versionless EVM proposal, is a potential for adversarial behaviour BEFORE such change (EIP-2341) gets rolled out. As far as understand, anything that was deployed before that, is "untouchable" by the EIP-2341, and any further changes (like gas cost hikes). If versioning is inherited from parent contract to the child, then it would be quite easy to deploy generic factories that would be used to take advantage of the old rules, with the cheaper opcodes, no?
Ghost
@ghost~55c3ed250fc9f982beac84b3
I have a feeling that the boat of full backwards-compatibility has sailed the minute the initial EVM design has been rolled out in Frontier. EVM with its ability to generate code and spawn new contracts, and compute jumps, seems like being so "polymorphic" (much more than quasi-Turing completeness would require) that it is quite hard to place any restrictions without either some kind of work-around existing, or breaking backwards compatibility.
Wei Tang
@sorpaas

If versioning is inherited from parent contract to the child, then it would be quite easy to deploy generic factories that would be used to take advantage of the old rules, with the cheaper opcodes, no?

@AlexeyAkhunov I don't think the goal here is to "prevent people from using older versions", but rather to "encourage people to use newer versions". Older versions are fine and people can continue to create new contracts of it as long as there are no current known EVM vulnerabilities (otherwise, we need emergency hard fork and backward compatibility has to be broken anyway). In the mean time, to encourage using new account versions, we can do changes such as systematically decrease opcode gas cost, so that older account versions are slightly more expensive to use, and contracts are better off migrating to the forward-compatible EVM version when it is possible.

Back to your questions -- the direct answer is a quantitative "yes", but I do think the above should have addressed the concerns behind the question.

Adrian Sutton
@ajsutton
There doesn’t have to be a current known vulnerability. I can deploy a generic factory contract now and then at any point in the future use it to deploy a new contract under old rules and exploit any vulnerability that becomes known in the future.
Wei Tang
@sorpaas

@ajsutton Okay let me rephrase it -- older versions are fine and people can continue to create new contracts of it as long as there are no current known EVM vulnerabilities. The thing is, whenever there's a vulnerability, we'd want to patch it both in the legacy EVM and the forward-compatible EVM. Because it's patched in legacy EVM, contracts under old rules cannot exploit it either.

This is why I also emphasis that account versioning is not for emergency hard forks. Those are situations where backward compatibility has to be broken.

Martin Holst Swende
@holiman

avoid the next situation similar to EIP-1884

account versioning is not for emergency hard forks. Those are situations where backward compatibility has to be broken.

Well, as I see it, if we don't 1884 now, we will eventually have to do it in an emergency instead. So I still don't see how that reasoning applies to 1884. I guess you mean that next time, we can ship it "softly" even earlier, and let people migrate, and only much later actually change/remove it "breakingly", and then not bothering the "active ecosystem". If so, I finally understood your reasoning :)

Wei Tang
@sorpaas

@holiman Yeah. That's one way the forward-compatible EVM can work, and I do think that's a viable method. But just want to provide you an idea that will have even less backward incompatibility impact, and does what 1884 tries to accomplish.

Imagine, in an alternative universe, we decide to apply 1884 after 1702/39-UNGAS/40-UNUSED. The current 1884 specs, we increase certain opcode's gas cost, but note that this is functionally equivalent to decrease other opcode's gas cost. We apply 1884 as follows:

  • In legacy EVM (version 0), we do nothing.
  • In forward-compatible EVM (version 1), we apply 1884 by decreasing other opcode's gas cost.

After this is done, we make sure to inform miners to configure their client to set the block gas limit according to the forward-compatible EVM gas cost config. Note that this is something that has to be done when we re-calibrate gas cost anyway, no matter whether account versioning is in place. When hard fork happens:

  • In forward-compatible EVM, any exploit is fixed, because as noted earlier, while we do not change gas cost of SLOAD, etc, we decreased gas cost of all other opcodes, which is functionality equivalent to increasing gas cost of SLOAD, etc.
  • In legacy EVM, the situation is that SLOAD gas cost equal to the forward-compatible EVM, while other opcode gas cost is more expensive compared with the forward-compatible EVM. The gas config becomes in all cases more expensive compared with forward-compatible EVM. As a result, the exploit also cannot happen.

Nothing is perfect. This method certainly involves a slight increase in implementation complexity, and sometimes, gas cost analysis might be too complex to adopt this method, and we may be just better off using what you said above. But I just want to note that this is a possibility, and it indeed works for "simple" cases like EIP-1884.

I also want to note that once things move forward to the forward-compatible EVM, we can expect less and less of this when we do gas cost changes. After all, the forward-compatible EVM is forward-compatible in gas cost changes.

Micah Zoltu
@MicahZoltu
An advantage of versioning the EVM is that it could allow for long-term removal of things. For example, we could state that "in 2024 EVM version 0 will no longer be supported".
This gives people plenty of time to migrate away from EVM version 0, and it gives us the opportunity to create a better future.
Also, ETH 2.0 (or other EVM based blockchains) may only support EVM 1+, and having a standard for what is included in that set is valuable so that compilers can target it and people can design contracts that operate in a wider variety of systems.
Tomasz Kajetan Stańczak
@tkstanczak
@MicahZoltu what do you mean by 'not supported'
Ghost
@ghost~55c3ed250fc9f982beac84b3
@sorpaas Ok, now it makes more sense. But decreasing the gas cost of most opcodes would require something like "particle gas cost", something that @cdetrio suggested, right?
Micah Zoltu
@MicahZoltu
@tkstanczak Eventually disabled.
(unpopular opinion with the "immutability" folks)
And FWIW, I am personally on the fence with stuff like this (for similar reason the immutability folks are, though I think with more concrete arguments than you find on Twitter).
Wei Tang
@sorpaas
@AlexeyAkhunov Yeah that's a possibility, or we may come up with something better than "particle gas cost". For example, we can just keep a "discount factor" D for forward-compatible EVM, and we make the gas cost provided to be g0 / D, and the gas cost calculated to be g * D, where g is the actual gas cost, and g0 is the gas limit.
Tomasz Kajetan Stańczak
@tkstanczak
@MicahZoltu how do you ever want to record long maturation bonds or other long term debt instruments on chain that does not promise to maintain them operational?
Micah Zoltu
@MicahZoltu
@tkstanczak I think there is value (significant) in having a platform that cannot change. I also think there is value (significant) in being able to adapt or correct past mistakes. When any platform is just starting out, the ability to adapt is more valuable than being stable. When a platform is very mature, being stable is more valuable than being able to adapt. Everything between time 0 and time infinity is on a spectrum between those two.
I think Bitcoin calcified too early. I think Ethereum is not to the point yet where calcification of the protocol is the right choice either. I do think that eventually it will be the right choice, and different areas will make sense to calcify sooner rather than later.
For example, the issuance rate of ETH may be reasonable to calcify sooner than the EVM instruction set, and gas prices may be the last thing to calcify.
I do not know what the right timescale for calcification of the various parts are, but with regards to the EVM I think we are at a point where mid-term stability is important (we can't go doing backward incompatible changes every hard fork) but I don't think we are yet at the point where we should be locking down the EVM permanently (as Bitcoin has effectively done).
Tomasz Kajetan Stańczak
@tkstanczak
Doing backward incompatible changes when they are not necessary is a mistake.
James Hancock
@MadeofTin

To put it simply, the core architecture of ethereum as we know it today is not finished. If you are going to build a skyscraper(long term maturation of anything) first you build a solid foundation. Immutability on a foundation of sand won’t get anywhere long term. Until ethereum can last on its own for decades untouched we don’t have a foundation stable enough to lock forever.

I can see value in both camps and I am happy to see ETH and ETC working together. The differing values of each community adds value imo, as we will discover solutions otherwise we wouldn’t have. The version system outlined above as an example. That being said, if we don’t accept there are points we see differently and continue to rehash the same principles discussion I see it driving us further apart. Just my two cents.

Bob Summerwill
@bobsummerwill
@MadeofTin From ETC Summit 2017 - "Meredith Patterson - From Sand to Granite - How to Make Your House Endure"
https://www.youtube.com/watch?v=aipGCSGV8ZA
James Hancock
@MadeofTin
Thanks, I’ll check that out
James Hancock
@MadeofTin
Great video! I am adding it to my list to remember. Language is a big piece of the puzzle. I wonder if gas prices and state size management are considered higher or lower level systems in the context of a establishing firm foundation to build on.
Hudson Jameson
@Souptacular
So according to https://www.ethernodes.org/istanbul Istanbul is set to occur Saturday Dec. 7th. I am finishing up the blog post for blog.ethereum.org (waited until Monday for max exposure). How should I word in the blog that the time is variable between x and y? and if y is Saturday Dec. 7th what is x?
Danno Ferrin
@shemnon
So…. block times went longer than expected. My initial swag was for one time and I got feedback to use a shorter time. It trended up and past my initial time.