Title: Thread_to_begin_discussing__Ethereum_1_0__proposal
Category: Working_Groups

Author: jpitts
Date: 2018-11-01T09:59:37.988Z

In light of the amazing conversation that the community had around the subject of Ethereum 2.0 and its roadmap, I would like to propose a Ring / category for the current improvement proposals across clients on mainnet e.g. Ethereum 1.0.
Are there folks who would collect around such a ring? Probably there are quite a few!

Author: jpitts
Date: 2018-11-01T10:38:01.080Z

And in a way All Core Devs is the original ring around this, so this would be a category here on the forum where those who normally would be on All Core Dev calls and other stakeholders would discuss EIPs.

Author: fubuloubu
Date: 2018-11-02T10:58:17.702Z

The Security Ring (#working-groups:security) is talking about some of the execution layer plans for the near and far term, including the transition to eWASM.
Further information here:
Ethereum Backend Discussion

Author: bobsummerwill
Date: 2018-11-02T15:47:04.760Z

Yes, there is a very real need for this!

Author: latrasis
Date: 2018-11-04T19:50:13.614Z

Hi Bob! Do you think anyone be interested to read on a proposed security protocol? Current whitepaper

Author: jpitts
Date: 2018-11-13T03:51:48.634Z

@latrasis, this message probably belongs in a DM to Bob!

Author: jpitts
Date: 2018-11-13T04:00:06.673Z

According to the tweet by Ben Edgington entitled “Get your Ethereum 2.0 fix here”:

Proposals to evolve Ethereum 1.0 are being grouped under the name “Ethereum 1.x”.
There are working groups forming! Er, where?

Reducing state size growth
Implementing eWASM in some form
Benchmarking framework for evaluating performance proposals


EIPs / proposals out be the end of this month? WOW

From the Google Doc “What’s New In Eth2”:
image1262×726 61.6 KB

Author: boris
Date: 2018-11-13T05:04:13.799Z

Thanks for continuing to curate this, @jpitts. I also wonder where / how one gets involved with working groups. Would be good to list them and have a repo or channel or somewhere where people can knock on the door to find out more and get involved.
I’ve started on drawing diagrams of the Ethereum system – decomposing the entire Ethereum client and some of its specifications.
See Ethereum System Diagrams - Google Presentaties
Relevant for this thread is one suggestion that could get us not to eWASM, but rather to an LLVM integration that means we can support the end goal of eWASM much more quickly, AND not have to throw out or migrate existing smart contract code. It would be forward compatible.
Ethereum%20System%20Diagrams960×540 44 KB
@lrettig where’s the best place to have this LLVM discussion?
@fubuloubu wasn’t it someone from Trail of Bits who had started work on this? Can you connect us?

Author: fubuloubu
Date: 2018-11-13T05:14:31.043Z

cc @dguido
I believe it was more a chat and general agreement on an LLVM backend that produces EVM code being a great approach for the medium term.
Personally, I’d love to move that chart such that Vyper can use LLVM for optimization stages.

Edit: P.S. was gathering a working group on this…

Author: boris
Date: 2018-11-13T05:19:37.538Z

Yeah, I was trying to draw it as current state. LLVM is good at optimization so would just mean writing an LLVM backend for Vyper rather than doing the work of creating the bytecode, I think?
Maybe we should put it on the agenda for the EVM Evolution community call? I’ll link back to this here from the call agenda and we’ll cover it if there is interest.

Author: fubuloubu
Date: 2018-11-13T05:23:27.579Z

Maybe. I was considering it separately, including in the same chat as Yul, LLL, and all the other IRs that exist out there. Defining the optimization and security goals of the IR, best path(s) to get there, what the tradeoffs are, etc.
EVM stuff is one layer lower, so that was going to be a separate discussion as I had planned.

Author: boris
Date: 2018-11-13T05:25:22.027Z

OK. I kind of think they are all inter-related, and not talking across layers is one of the issues in the first place. MOAR DISCUSSION.
(also doing!)

Author: fubuloubu
Date: 2018-11-13T05:38:39.956Z

I know, it’s more of a practical thing. There’s already like 10 plus in each discussion. A lot of people in security community are interested in being included in this discussions, as they should.

Author: fubuloubu
Date: 2018-11-13T05:48:48.753Z

P.S. @karalabe I think is involved in the state and block growth discussions?

Author: dguido
Date: 2018-11-13T18:40:20.508Z

Hey Boris,
Yes, we have a detailed plan to implement a system similar to what you describe. We have worked on many compilers before, and about 1/3 of our company works on LLVM daily.
I think the best approach would be a purpose-built machine-level IR for optimal EVM generation, let’s call it “EIR” for Ethereum IR. We have a high level spec for what this IR would look like, and it would enable us to create an efficient backend for EVM. It would include gas cost information and low-level memory layout information.
I think it is just as important to consider building a frontend for Solidity, Vyper, or other languages in LLVM. Similar to Swift, we would probably want a high-level IR (not YUL) before handing it off to the rest of LLVM. For example, it would include accurate types, a CFG, and be in SSA form. Let’s call this one SOLIR for “Solidity IR.”
We have rapidly prototyped an IR that meets the frontend specifications we need inside Slither, an Ethereum static analyzer. It is still evolving and lacks, for instance, SSA but given a few more weeks of work it would be an acceptable IR to ease and enhance integration of Solidity, Vyper, and other languages into a modern compiler like LLVM. You can find details about it here: https://github.com/trailofbits/slither/wiki/SlithIR. You’ll note we already have working code and it correctly translates all Solidity available on Etherscan. Adding support for translating Vyper or LLL to this IR would only be a ~2-4 week process.
We have specs for our entire approach (frontend and backend) and want to begin working on it, however, we received no response after submitting a proposal to the Ethereum Foundation and, therefore, expect that our proposal for compiler development is no longer under consideration. We would still like to pursue this project because we think it’s the most important need for the Ethereum community to mature its software development process.
Let me know if you’d like to chat elsewhere. I can be reached at dan@trailofbits.com.
-Dan

Author: boris
Date: 2018-11-13T19:30:23.471Z

Hey Dan – this sounds great. I’ll send you a note by email. I think there are a number of people who believe in an LLVM approach. So there is a mix of rallying people around this as a direction, coordinating on moving forward, and getting grants / funding / sponsorship to do the work.
Our broad label for related work is EVM Evolution, and outside that, this ETH 1.x roadmap (which really is more like – let’s keep shipping new stuff iteratively) is how we move forward.

Author: jpitts
Date: 2018-11-14T01:23:06.189Z

How did you submit this to the Ethereum Foundation? It is the client developers, tool makers, and the the wider community to decide on a proposal like this.



 dguido:

We have specs for our entire approach (frontend and backend) and want to begin working on it, however, we received no response after submitting a proposal to the Ethereum Foundation and, therefore, expect that our proposal for compiler development is no longer under consideration. We would still like to pursue this project because we think it’s the most important need for the Ethereum community to mature its software development process.

Author: boris
Date: 2018-11-14T01:25:21.914Z

I think he meant a grant proposal.
But yes – @dguido the Ethereum Foundation doesn’t decide technical direction of the ecosystem. “We” get to work together and build what we find is valuable.

Author: jpitts
Date: 2018-11-14T01:59:06.480Z

I see, this is a very interesting proposal and nudges me to learn more about compiler details and LLVM!

Author: gcolvin
Date: 2018-11-19T16:23:19.966Z

@dguido This is, of course, very interesting to me.  Can you post a link to the grant proposal?

Author: jpitts
Date: 2018-11-23T18:05:56.637Z

A group of individuals has been meeting to discuss “Ethereum 1.0”. This group may be seen as All Core Devs, but its composition seems to be not fully representative and includes other stakeholders not generally associated with All Core Devs. For now, I will call this particular initiative “Ethereum 1.x”.
The existence of this group has been known to a number of people in the community who chose not to participate (I will soon write up details in a disclosure). Ethereum 1.x now has been more or less officially confirmed by participants on today’s All Core Devs call #50.
Unofficial “leaked” notes from the Ethereum 1.x proceedings:


docs.google.com



Notes: DevCon Eth 1.x and 2.0 Meetings
Notes: DevCon Eth 1.x and 2.0 Meetings  Hey all, here are Dan Heyman'snotes from the meetings over the last week. I know I missed bits so please feel free to add. Also, I definitely missed people in the attendee lists. Not everyone made it onto the...





CoinDesk article by @rachel-rose:
https://www.coindesk.com/ethereum-developers-are-quietly-planning-an-accelerated-tech-roadmap

Author: jpitts
Date: 2018-11-24T07:07:12.034Z

Epic breakdown of Ethereum 1.x by @cdetrio:




Ethereum 1 dot X: a half-baked roadmap for mainnet improvements Ethereum 1.x Ring


    Ethereum 1 dot X: a half-baked roadmap for mainnet improvements
I’m posting this without any prior review or draft feedback from other core devs. This is my personal perspective on what 1.x is about. All mistakes and misrepresentations are my fault. 
Summary
Ethereum 1.x is a codename for a comprehensive set of upgrades to the Ethereum mainnet intended for near-term adoption. The 1.x set of improvements will introduce major, breaking changes to the mainnet, while 2.0 (aka Serenity) undergoes pro…

Author: gcolvin
Date: 2019-01-28T06:08:19.341Z

jpitts:

How did you submit this to the Ethereum Foundation? It is the client developers, tool makers, and the the wider community to decide on a proposal like this.


This is a bad bind for low-level development.  It’s difficult to build wide consensus around a proposal that hasn’t been implemented, but difficult-to-impossible to implement such a proposal without financial support.