Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

ethereum/AllCoreDevs

People

Repo info

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?

Tim Beiko

@timbeiko

https://github.com/ethereum/eth2.0-pm/issues

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

Alexander

@shamatar

Initial data on precompiles repricing https://docs.google.com/spreadsheets/d/1aCQnk7prrp3Mbcf011BE5zZnkbc3Iw7QAixn6mLbKS0/edit?usp=sharing

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

Option (1) of EIP-2565
- ("GQUADDIVISOR is set to ‘20’ per EIP-198. We recommend changing the value of this parameter to ‘200’.”)
https://github.com/ethereum/EIPs/pull/2657#discussion_r429088564

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 ? ).

(re pricing and general confusion, see https://github.com/ethereum/EIPs/pull/2662#issuecomment-631430967 )

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.

https://github.com/MadeofTin/EIPs/blob/patch-17/EIPS/eip-2657.md

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

The cost of the JUMPSUB opcode (5 or 8) https://github.com/ethereum/EIPs/pull/2662#issuecomment-631430967
The restriction proposal for JUMP. ethereum/EIPs#2663
How can we move forward on these subjects to finalize the implementation of this EIP?

Tomasz Kajetan Stańczak

@tkstanczak

one moment

NethermindEth/nethermind#1922

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

👏👏👏👏👏👏👏