# ETH 1.X Kickoff Call
Nov 19th

## Broad goals and intro

These calls should be "safer" than the all core devs meeting, so as a format we want to keep it friendly and a little less formal than those calls.

This is a meeting for the plan that began at Devcon in Osaka for the revitalized research effort to move Eth1.0 into an Eth2.0 execution environment

Broadly, we want to make it easier to get a client online, and change the paradigm of what it means to run a client.

We want to make it easier to query and access
* logs --
* transaction history --
* Tree database --

These elements make it difficult for people to get nodes up and running in a reasonable amount of time.

@TimBelko -- concerns about open vs. closed calls.
@Piper -- open calls are fine, but we likely don't want to stream the calls to the public.

ETH clients have a coordination problem: Individual client teams work independently on solutions to a common problem (such as sync speed), and don't come together soon enough to compare notes and pick a single direction to continue in.

## Client Teams and dedicated devs
@Piper - one suggestion to improve coordination is if each team can have a dedicated person working solely on 1.x

@Alexy - agreed. When people split their time, not a lot gets done.

@PeterS - I have a problem with this. With joined teams, the maintainer teams feel the pain of the performance, but other people working on research introduce new (unworkable) solutions without that experience.

@piper - This isn't a necessary outcome; there can be a high level of coordination between the research and implementation teams, and it just depends on the process.

## Timeline
18-24 months is the 'finger in the air' estimation.

We want a long term, high-level vision, but with tangible, short-term deliverables.

### Required work
* moving to binary Trie
* Witness generation and propogation

### Optional work
* Beam Sync
* Ancient Chain data pruning
* Less opinionated state syncing and database layouts

## Working Model
@Piper would like to be the high-level coordinator for this work, scheduling meetings, cross-coordinating with different teams, etc.

The Ethresear.ch forums seem like the best place to coordinate this effort.

telegram channel will be forthcoming.

## Discussion on witnesses and other issues
@martin - Witnesses - either we have statelessness as the main type of client, or we will have stateful nodes that all other nodes leech from for their data, sort of like an oracle model.

@Piper - Making sure that we can support stateless clients is something we need to address carefully, but there are incremental ways we can make that happen without taxing the network.

@Alexey - The witnesses will be travelling along with the blocks. It seems that the miners are the ones who should be attaching the witnesses and making sure they are proved and attached at block creation.

@Martin - malicious miners could block proofs... (I need to clarify this, my connection dropped out)

@Alexey - The witness can be ingested in chunks --

@peter -

@Alexey -

@Martin - 2 problems - I want a transaction, I need to make a witness for my transaction. But with 200 transaction, we don't want individual proofs for each transaction.

-- This is probably done by the miner

@Peter - impossible in the current data layout to create a witness for a transaction.

@Piper -- these questions are open and not fully explored, but in principle they seem solvable.

Witnesses can be produced well after the blocks are mined and in the chain, and are more a part of sync rather than something the network depends on. So this can make for a 'safer' environment to test these things out.

In the beam sync model, the witness model is a supplementary way of doing things, and the client can always default back to the 'traditional' fast or full sync.

@Peter - we have been talking about witnesses for a while now, but step 0 should be for us to generate them for mainnet blocks and see how large they are.

@JasonCarver -- We have done some testing already-- 10-11K trie nodes

@Alexey - moving average over 2k blocks ? is 1MB per block -- before the gas limit increase.

@Peter - from my perspective 1MB is not feasible

@Piper - these are experiments at this point, and we're starting out looking for safe ways to continue experimenting and iterating towards better and better solutions

@Martin - Q - how would this change if we doubled the block times and doubled the transactions per block.

@alexey - one snag is that the contract code, in a stateless paradigm contract calls must include the entire contract code in the witness. But switching to a binary tree might help with this issue.

@danny - there are some experiments from starkware that suggest the network could handle much larger blocksizes (even an order of magnitude higher)

@Guillaume - Q - in the list of things that Alexey wanted to work on... is he still intending to work on them?

@Piper - no decisions have been made, and my proposals have not been agreed upon

@Alexey - there are many things that we still want to do, but I would need more help from people to work on them.

## Talent and dedicated people from client teams

On the call, Geth, Besu, Trinity, Turbo-geth (february), Quill? from ETH2

@Peter - Geth -- we are almost certain that we won't be able to do that, because we can't find a person to work on it. But if we could find someone, yes, it would be good.

@Piper - if everyone on the call could tap their networks, we want to cast our net wide.

@Tim Besu is working on finding some new talent as well

@Will - We have someone who is already working on some of these issues, and have been playing already with binary tree stuff.

@Alexey - 2 main objectives: prove that the turbo-geth layout is superior in most situations, and stateless clients. https://github.com/ledgerwatch/turbo-geth/issues
I'm actually starting to be the bottleneck- but at the moment I'm full, but will start looking for new people soon

@piper - trinity is looking for a beta release by march or april

* Meeting in person on a semi-regular basis *

We want to look for a time to come together for a summit for 2-3 days to discuss these things in person. Target is sometime in the spring, and we want to try to look for a summit every 3-4 months.

Also, we of course want a regular call to keep in sync and focused. Let's shoot for a call in something like 2 weeks, with an agenda and some more in-depth discussions.

## Questions

@James - Who all has a list of things important for 1.x inclusion.

note taking best practices - maybe a bit of a delay on publishing?

@Danny - The more we treat this as a concern, the more it becomes a concern. I'm not personally worried about keeping everything public -- it's chill.

@Alexey - let's hear from some of the people who attended the call!

@MartinLundfall - I feel like someone who doesn't have a lot of insight (mentioned by peter), so I'd like hear and see if some of my assumptions are verified, and interested in the issues surrounding transaction witnesses and storage.

@AlexB - from the eWASM team we are definitely keen to keep an eye on what's going on. 1 - particle gas cost. Pricing of the EVM. 2 - use-cases for WASM in 1.x this came up in the EIP about EC precompiles 3 - changes that will be needed in 1.0 to make a transition or good cooperation between the 1.0 and 2.0 networks. These are what we're interested in.

@alexey - the second one is in my list, and I've thought about the particle gas cost, so I'll include them. The 3rd is pretty big...

@Piper - callin it! Thanks everyone for joining!

Expect some notifications about putting together a telegram group, but for now the best place to coordinate and discuss is going to be the **ETH1.x Topic** on the ethresear.ch forum.

## Links from chat:
Alexey - Research Topic list
https://ledgerwatch.github.io/Ethereum_1_Research_topics.html

Piper - Research Topic list
https://notes.ethereum.org/cISMnGRMR6-EWka8QLLlYw

What is a safe data size?

https://ethereum-magicians.org/t/eip-2028-transaction-data-gas-cost-reduction/3280/24