Community Call - EVM Evolution
==============================

When: Nov 26th, 10am PST
Zoom Video: https://zoom.us/j/715268638
Agenda: https://github.com/spadebuilders/community/issues/14

## Action Items

### Plan an All EVM Call

https://github.com/spadebuilders/community/issues/20
* Need to make a list of EVM compatible clients / chains and gather contacts
* Brooke / Boris will meet with ETCDEV contacts as well

### Get clarity on ETH 1.x roadmap around EVM1.5 and eWASM

https://github.com/spadebuilders/community/issues/19

Goal is to have EVM Evolution support this process.

### What is the process of rolling out EIP615 Static Jumps and other EVM opcode additions

https://github.com/spadebuilders/community/issues/18
* First high level notes / process here https://hackmd.io/WmnAxhCsS1yd50hj9Ai7eg
* Will create tracking issues for this process -- e.g. PR against Yellow / Jello paper is the likely next step

---

General consensus continues to be that EIP615 is valuable and should get implemented, and that more learning / explanation around VMs and IRs to be done.

Further explanation to the wider community is needed on how [SlithIR](https://github.com/trailofbits/slither/wiki/SlithIR) -- an intermediate representation designed for analysis for security purposes -- is highly useful, and that Yul and/or LLVM are lower level IRs that can be used for performance optimization, but don't help with security analysis.

Some discussion on funding and funding sources. Trail of Bits happy to put some time in and collaborate with SPADE, others.

Brooke has a personal TO DO to correct / clarify some statements around EVM.

Boris [working on diagrams](https://docs.google.com/presentation/d/1UDW1KsNc5w8xaFLWaisn_ZFqWcflZHWs-_FUpDq_2kk/edit#slide=id.g4957478a19_0_0) to help communicate -- Dan shared some SlithIR and related writing that is helpful.

## Notes

Boris / SPADE
- working with Brooke
- open source infrastructure

Anthony & Yaz - ETC Cooperative
- helping out
- LLVM to EVM is of interest
- interested in tracking EVM upgrades to ETC

Stefan / Trail of Bits
- assurance work
- prior to ToB, quite a bit of assessment work -- physical, opsec
- program analysis, general interest in VM

Josselin / ToB
- security
- background in program analysis
- more generally in evolution of the EVM

Bryant / SecETH
- freelance
- security community
- wanted to be a part of it
- right direction we move to a more secure execution layer

Dan Guido / ToB
- CEO / co-founder ToB
- try to keep track of other resources

Brooke, SPADE
- broad interests in PLT, VM design
- talking in Berlin and then Prague EthMagicians about EVM design, with Greg Colvin and others
- many people not thrilled with current VM desgin -- weird stuff like 256bits, overflowing ints
- we've been looking at a number of proposals -- least controversial is EIP615 Static Jumps
- then EIP 616 SIMD plus some others like non-overflowing ints so that SafeMath doesn't
- with Serenity coming, what changes are needed to migrate the EVM
- if eWASM goes ahead, a smoother upgrade path for it
- LLVM backend
- argument for eWASM is that many languages -- but it just uses LLVM

So broadly:
- improving the existing machine
- upgrade path
- language improvements plugging into the LLVM

Dan
- created a proposal to modify the Solidity compiler -- eWASM and EVM at the same time
- Josselin and Stefan wrote the proposal
- consider it stalled with the EF
- what we do have in code form

Bryant
- Solidity has some capability to move to eWASM
- Vyper might be another tact to take

Brooke
- Clarification: are you referring to Yul or SlithIR?

Dan
- Yul is not suitable as IR
- SSA, full types and attributes, control flow graph -- that let you compile
- maybe in two years Yul could be an IR
- that's where Slithir comes in, its a front end to a compiler
- translate Solidity to the IR we design -- a linear IR, types and attributes, more complex optimizations and security review
- Josselin been main person working on it
- specification, code exists, and some passes on security and performance
- when we submitted proposal -- this would be more effective
- trepidation because its such a large piece of work -- to prove it, lets do it, and we'll show you
- SlithIR code is proof that technical direction is viable

Stefan
- went over Yul grammar -- doesn't match what is produced / consumed by the compiler
- some grammatical constructions that couldn't be codified -- a number of things didn't match the specification
- practical concerns like control flow and SSA, plus issues with the grammar
- have grammars that can parse the strict grammar, as well as lax grammar to work with SolC

Josselin
- something high level, where Yul is close to EVM -- not a lot of difference, between Yul and EVM
- primary concerns if you can take Yul bytecode and EVM bytecode

Dan
- done a lot -- beneficial to us
- review Solidity and other languages that turn into smart contracts
- clear incentive to do this
- some items are a bigger lift -- re-architecting portions of a compiler
- Josselin -- take every Friday from now until 2020
- SlithIR is going to continue to have resources given to it

Brooke
- SlithIR is far superior to Yul
- for sure the right direction
- funding being an issue in the ecosystem
- anyone been chatting with Ethereum Community Infrastructure Fund

Dan
- comment on tightening of the belt
- EF are being more conservative
- they may or may not feel they were a bit loose, and that there is a drive to get metrics and measurability
- proven results

Anthony / Yaz
- Grant proposals?

Boris
- we have one we can share
- soft fork / op code upgrades to the EVM

Brooke
- progress being made
- pieces can be done, don't have to ship everything in one go
- ECIF -- conversations with people like Lane, Piper and EF and others
- Saying that infra projects won't have benefits right away
- some are harder projects -- like rewriting a compiler
- won't see metrics if it takes a year
- interest to what ECF does, passing the hat

- Starting shipping things into clients immediately
- Orthogonal, aren't breaking changes
- Good design wouldn't have breaking changes
- Would use them confidently when there is some level of adoption
- Bottom up change
- Hard forks can be breaking changes
- Soft fork says that everyone
- Don't have to wait for COnstantinople
- No, we are at five 9s in the network
- Can do rolling updates
- Same amount of coordination between client maintainers
- But, don't have to throw the switch at one time
- Parity in March, Geth in May -- when we hit a critical number, can change the compilers

Bryant
- Vyper would move ASAP

Dan
- few things
- can assist with community -- Pegasys and Parity
- work with them to help them understand changes
- some ways to show results early
- like Slithir, where we wanted to show a front end
- wanted to show benefits quickly
- for example, have checks to help you migrate code
- could also build, with Rattle, EVM translator, brings it back to SSA form, to find the same things in SlithIR, inside of EVM
- would be easier to detect static detection with Rattle -- one potential proof of concept
- near term benefits
- building out tools at the same time shows more value

Bryant
- Vyper could point to 20% gas reduction, clear benefit

Brooke
- didn't have in scope, should add

Boris
- call out around opcodes

Anthony
- ETCDev would need more coordination; separate team
- Parity not an issue

Brooke
- feature flags adds complexity
- we as a community agree that these opcodes are available
- bottom up -- all the clients support it

Opcodes not available
cause a revert

Make changes to EVM
Testnet
Push it out
Whatever the migration is, medium form or other method
Getting it into clients
Hard part -- getting it into clients

Bryant
- Parity ETC fork

Anthony
- Parity is about 60% of the ETC network

Josselin
- pull request to Yellow Paper

Boris
- Yellow / Jello paper PR

Josselin
- if it is inside Yellow Paper, then clients need to understand

Boris
- does ETC refer to Yellow Paper? yes

Anthony
- more ETCDEV -- Boris to talk to Darcy
- bit signaling is too heavy?
- UASF are more hard fork-y -- won't cause netsplit, but transaction invalidation
- almost as bad as a netsplit
- NOTE: signaling needs review?

Bryant
- disincentive until it has been accepted by the five 9s

Brooke
- people shouldn't use it until there is community consensus
- flip the compilers to start using this feature

Bryant
- for example PyEVM client has groups of rules that you can opt into, and move from
- would be a rule change, upgrade of rule set
- that version of the EVM uses
- at this block height?

Brooke
- does need to be part of larger conversation
- a few people have suggested -- all core EVM call
- focused on just the EVM
- includes all the other blockchains that use the EVM
- beyond Ethereum and Ethereum Classic

TO DO: make list of EVM compatible -- Ella, Expanse, Ether Social, UBIQ --

Hyperledger list

EEA

===

Brooke
- LLVM

Dan
- not a vs thing, but complimentary
- lots of languages have high level IRs
- like Rust, which has 5 IRs
- Swift, same example, created by team that maintains core of LLVM
- Has a number of stages that Swift is translated to before it gets translated to LLVM IR

Josselin
- other languages to SlithIR
- could do Vyper to SlithIR to LLVM
- SlithIR is high level, LLVM is low level

Bryant
- Question: LLVM is better for optimization
- SlithIR is better for security analysis?

Dan:
- you want a high level IR for security analysis
- having types and attributes that you want in high level IR -- help you find logic bugs, security issues
- when you want optimization, like gas, accurate modeling that isn't important for security, but is from low level optimization
- tells me that compilation process -- at least two different IRs - one like SlithIR (Security), one that is like LLVM IR for performance
- preaching to the choir -- LLVM get combined effort of all these companies
- that is what we described to EF -- high level to low level, that produces efficient EVM

Bryant: LLVM easy path to eWASM code

Greg
- always had a concern to keep them complimentary
- keeping translation back and forth
- and keep things that can be translated
- notion that people would migrate their code to WASM not that likely

Brooke:
- broader than language adoption
- having tons of person hours thrown at the WASM VM
- very efficient on modern hardware
- there are other reasons for moving to WASM -- especially if there are big breaking changes in Serenity
- question of do we fix what we have for backwards compatability and control
- if there is a bug in WASM -- it becomes much harder to fix for the version that runs on Ethereum
- having opcodes for Elliptic Curve cryptography couldn't get it into WASM directly, also gas costs and so on

Stefan
- you're spot on
- lots of people behind WASM
- switching from EVM to WASM will be much more difficult
- especially if automatic translation will help
- like WASM environment, great tooling like Wasabi -- that we had to recreate from EVM
- don't see it as a panacea -- will be so difficult to get to

Greg
- performance gains are illusory, can't use the optimizations off the shelf, because they can go quadratic
- going to have to write our own compilers, won't meet our needs because DDOS attacks aren't a thing on web pages
- so you don't off the shelf get things running fast -- have to take care of it ourselves
- as an instruction set there isn't anything special about it

Stefan
- memory mitigation, timing mitigation, etc. in WASM are useful
- not any magic wand
- very interesting if we can sport WASM specific languages -- Grains, OCaml like -- a runner like that is an immediate run

Greg
- won't have WASM compilers out of the chute

Boris
- talk to WASM team? Highlight issues

Bryant
- when of WASM is more pertinent

Brooke
- wasn't WASM faster -- was having one upgrade every year isn't enough upgrades
- all changes happen on a regular basis
- maintainers frustrated to
- general desire to move to 3 month rolling updates
- that's scary! 4 times as fast -- move to 6 month plan, smaller numbers of changes
- development of Ethereum react more quickly

Bryant
- meeting after that, discussing making changes sooner
- testnet for WASM is up

Brooke
- technical discussions moved to be out in the open

Bryant
- precompiles as WASM code? TO DO

Josselin
- next clear step to get EIP 615 Static Jumps in?

Brooke
- PR it against Yellow / Jello
- Have a concrete implementation that people can look at
- EIP moved into Final
- Closed off as official piece of the standard