by

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
is there an ethereum/pm for Eth 2?
James Hancock
@MadeofTin
Eth1/pm and Eth2/pm really are the same thing in the end as the merge.
They*
Alex Beregszaszi
@axic
If there are multiple calendars (ACD + Eth1x calls, Eth2 calls, EIP/Cat Herders, all-in-one combined) I’ll subscribe to the appropriate ones. Would be nice though to have a calendar maintained by someone haha
SHA256 should be priced not based on the len(input)/32 words, but as B + A*((len(input) + 8)/64 + 1)
James Hancock
@MadeofTin
:clap:
James Hancock
@MadeofTin

What are all the clients that intend to sync with YOLO? I want to try an async decision on changing to option 2, verses removing

Martin Holst Swende
@holiman
Re yolo: it's a bit up in the air, imo. So the subroutine eip specified BEGINSUB cost as 5, but geth/besu used 8, for one thing. The testcases that I updated have been reverted in the PR (but are fine on ethereum/tests).
The pricing change on 2565 has been thumbed down by OE ( ack @vorot93 ? ).
James Hancock
@MadeofTin
Okay, so neither is stable.
Artem Vorotnikov
@vorot93
We won’t implement option 1 of 2565, but may implement option 2.
Artem Vorotnikov
@vorot93
However, I’m not in favour rushing in 2565 and would rather focus on the initial two EIPs
James Hancock
@MadeofTin
I added a field to mark which parts have consensus and which still need to be fleshed out. I also added a table to show which clients intend to support and consensus around the specfication.
James Hancock
@MadeofTin

@timbeiko @pipermerriam @holiman @vorot93 @tkstanczak @holgerd77

Thoughts on option 2 vs leaving it out for this version. And let me know about intent to sync with the testnet.

*Disclaimer: For anyone reading along this is dicussing what goes into YOLO v1. Not mainnet. :ok_hand: This does not determine the final state of an EIP, nor its inclusion on mainnet.
James Hancock
@MadeofTin
Rough rough consensus on the spec among clients who plan on particpating in YOLO is enough to move these forward and particpation does not ultimately signal support for or against the EIP into mainnet.
/end rant
Link to the PR: ethereum/EIPs#2657
Tim Beiko
@timbeiko
For Besu, we can drop EIP-2565 and just focus on 2315 and 2537 :+1:
Karim T.
@matkt
I can see that there are two points to discuss on the EIP2315
Tomasz Kajetan Stańczak
@tkstanczak
one moment
we plan to support it
James Hancock
@MadeofTin
:thumbsup: i’ll add to the document
Greg Colvin
@gcolvin
@matkt
@holiman and I are finalizing the spec with new gas price for JUMPSUB and the changes to BEGINSUB — but not for JUMPSUB — recommended at
https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm-analysis/4229
The current draft is close. Spec is right, testcases are incomplete, gas is wrong. Should be fixed today.
https://eips.ethereum.org/EIPS/eip-2315
James Hancock
@MadeofTin

Great. :clap:

Unless there are strong objections from any of the clients I’ll remove Option (1) of EIP-2565 from the spec of YOLO-v1. I will give some time for responses before making the change.

Karim T.
@matkt
Thank you @gcolvin for your answer. So if I understand correctly the part "prevent jumping into another subroutine" will not be integrated in the EIP
Greg Colvin
@gcolvin
@matkt I am not proposing "prevent jumping into another subroutine”. EIP-2315 ia pure mechanism — semantics without syntax.
Tim Beiko
@timbeiko
@gcolvin to be clear, you’re opposing this PR, correct? ethereum/EIPs#2663
Greg Colvin
@gcolvin
@timbeiko Yes, I oppose ethereum/EIPs#2663
Paweł Bylica
@chfast
@gcolvin Can you explain the "semantics vs syntax" argument? No offense, but sounds as some unhelpful slogan.
Greg Colvin
@gcolvin

Git won’t let me comment right now for some reason, so:

This proposal amounts to a syntactic restriction on subroutine layout which can only be enforced at runtime. Compilers must still generate code to allow for this possibility, so it's not clear that it gains much. Further, for optimizing compilers and compilers of unusual languages this behavior can be a feature, no a bug.

EIP-615 is the kind of path that results from consistently enforcing syntactic constraints at deploy time -- it would require a versioning scheme, which this proposal does not.

On the other hand, this might be the only such change that can be checked at runtime -- further analysis would help. That is a good reason to get this in.

Overall, I oppose this proposal.

Paweł Bylica
@chfast
I would rather say it is a semantic change as it changes how JUMP behaves, not where you can put JUMP or any other instruction.
Greg Colvin
@gcolvin
The syntax restrictions are that subroutines are laid out a a serious of contiguous BEGINSUBs, and the JUMP and JUMPI instructions are limited to subroutine boundaries — just as in most higher-level languages. Unlike those languages this restriction cannot be enforced at compile time, only at runtime. I argue that semantic cnnstraints should be handled a deploy time — code that violate the costraints should not be depoyed at all.
I’d support a proposal that limited constraints to those jumps that are recognizably static— i.e. are preceded by the push of a constant. A compiler could detect that at deploy time and take advantage of it.
Inelectably polymorphic code would need to be handled with if-else chains.
Greg Colvin
@gcolvin
Does that make sense @chfast?
Alexander
@shamatar
Nice number for an EIP ethereum/EIPs#2666
This summarized my measurements on Rust and Go implementations
danibotcode
@danibotcode
EIP2666... Is that the one with the summoning circle, candles, and sigil of baphomet? 🤔
Alexander
@shamatar
Kind of. It will change a lot!
Greg Colvin
@gcolvin

@chfast

I argue that semantic cnnstraints should be handled a deploy time — code that violate the costraints should not be depoyed at all.

Confusing typo — meant “syntactic constrainsts should be handled at deploy time.
Martin Holst Swende
@holiman
Screenshot_2020-05-23 https hivetests ethdevops io.png
Way to go Nethermind, now passes all Hive p2p tests!
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> yay!
James Hancock
@MadeofTin
👏👏👏👏👏👏👏