# [Panel] Ethereum 2.0: next step to Serenity / [座談] 以太坊 2.0：衝出寧靜號 - Hsiao-Wei Wang

{%hackmd _ghxQ119SgGRHLhgYaK2iQ %}

[TOC]

> 從這裡開始寫 :pencil:
>

## Core values of Eth2

Hsiao-Wei: Core values of Eth2

Vitalik:
general purpose platform
feel free to go and build things
finance, some identity things, whatevery you want to build.
Eth platforms takes care of all the common stuffs for you
trying to perseve it as much as possible
efficiecy improve proof of stake
execution envrionement
general
as Danny said take things we learned from eth1 and move forward the best we can.

## Decrepcated sharding and Casper contract

Hsiao-Wei:
backward companitibility
there's decrepcated sharding contract and the decrepcated Casper contract
EIP 1011
Why this change happened?
What's the change between old and new conctracts?

Vitalik:
Oh, I remeber that contract (NOTE: Caspter contract) I think I wrote it.
Instead of Eth2 as this kind of rooted existing
benefits of new system
optimize it for specific
sharding much more recently
what's the gas cost of updating state
a data structure
make Eth2 much more efficient

Danny:
One of the other reasons was the two path we were taking
ultimately
decentralization
radical appraoch
minimum requirements to participate

## 8 active clients

Hsiao-Wei:
Beacon chain...a huge project right now
8 active clients, including light house
I'm working on the Trinity client.

Alex Stokes:

Adrian Manning:
In Phase 0

## Elaborate more about Phase 1

Hsiao-Wei:
Phase 1 is coming. We did a developer survey last month
elaborate more about Phase 1

Vitalik:
test each component for some time before
a lot of economic value on top of it
seperations to have

- proof of stake
- sharding for data
- sharding including data and computation

Phase 2 specific problems

- Ether move cross shard
- implement and optimize webassembly

a lot of details
there's no point of ...release the entire system

Phase 1: Chain has no computation but can hold a lot of data

- Eth1 chain can be aware of Eth2 chain, bridge that Danny was talking yesterday through lightclient
- Optimistic rollup: 100~1000 tps even before all of the applications before running.

Crank up the complexity & utility overtime. progressive approach

Danny:

Parallelize different development

- Phase 0 relatively stable, developers actively working.
- Phase 1, researchers are very active specifying.
- Phase 2, Research team, Ewasm team, and Quilt team

Cleanly separated into phases.

## Composability between eth1 and eth2

Hsiao-Wei:

Client teams are working on Phase 0
Protocols... Phase 1 refining
the Phase 2 teams like ewasm and EEs execution environemtns implementations
people are worry about the composability
between eth1 and eth2. can we still use
cross shard..

### Danny: Composability is a concern but not breaking. Need better languages and tooling.

people are concerned about composibility and shard systems in general.

If you have state and applications exist in certain shard and want to speak, communicate, and interact with applications on another shard. That fundamentally works differently from layer 1 in eth1 today, where we can call a contract A from contract B within exactly same transaction have the result one and the other.

Generally in a sharded system you don't break composability, applications can similarly communicate with each other in an asynchronous manner rather than the synchronous manner. The problem is you do have certain things changed in the developer experience like

- guarantee atomicity of actions
- having things happen within scope of single transaction.

If we have sufficient tools and high level languages to deal with in mass complexity, you can compose applications in a very similar way and do similar things we've seen in Eth1 and likely do even more.

So definitely a concern. With better languages and tooling, doesn't break composability as people were saying.

### Vitalik: Things work differently but think harder you still have composability.

The main change you get when you shard
things don't just work as it worked before
communication between shard is async instead of sync
Phase 1 more than one slot
Shard A and have an effect on Shard B at one slot later

You can't have something on shard A reads something on shard B and based on the reading on shard B immediately do something else on shard A right after.

You can implement these things on top with locking schemes but you can't do it directly.

For example, ERC20s you need to redesign them a little bit. You can't have one contract on one shard be the token contract.
you have to have tokens some kind of presence on every shard.
Even the duplication of the code is not an issue. You can put the code on the beacon chain as a beacon chain contract.

Yanking mechanism: I want to do one thing and based on that one thing I do another thing, and based on that thing I do a third thing. You can have an individual contract that pulls all the things in one shard and do
the synchronous thing and if you want you can move them out.

This is a generalization of locking as it exist in traditional database atomic transaction theory.
You need to use different design patterns that takes maximal advantages of locking. For example, the more you can design your application as being a set of different contracts with one contract per unit of activity the better.

For example, ENS names are independent contracts, MakerDAO CDPs are independent contracts. You'll just need more things to have that workflow. that you can have that kind of synchronous like do 10 things at the same mentality as you do now.

you have to think a little harder but still there.

## Eth1 -> Eth2 Transition and Eth2 as the finality gadget

Hsiao-Wei:
Another things worry people is...
Eth2 as the finality gadget
Alex is working on the working group on various topics

Alex Stokes:
As Vitalik and Danny were saying...
Using Beacon chain launching soon to finalize the Eth .. chain The briedge concept
Eth1 chain to know about
initial study very risky if we can avoid it that's more preferable

Hsiao-Wei:
Vitalik seconded Danny's conclusion yesterday
any remarkable tradeoffs that you'd like to share about?

Vitalik:
Maybe the DAO.... fork that's the tradeoff

at some point we decided enough was enough
one of them was schedule calling
to execute 10 blocks to 100 blocks
a good decision that we abandaded that

That's one example functionality verses
uploading and downloading the gas limit
how about... gas limit
subtled decisions invovled

Danny:
mature shards but better
constantly having conversations
whethers it's worth having multiple
enhance user experience
always a balance

Alex:
EEs experiment with different alternatives
EES on top of Eth2
really confusing for people
managing the complexity there

Danny:
EEs landscape
execution environment Eth1 we have account, state, transaction
abstracting those things
specify dynamically
ewasm code
shard block data
you can make an EE that looks like Ethereum or bitcoin or some things that we haven't thought about.
maybe an Eth2 EE
very scable decentralized layer...in 20 years

## Client discussion

Hsiao-Wei:
Let's move to the client discussion. Adrian is here with us today. cross client testing because we have 7, 8 clients here.

Adrian:
cyber-security strong focus on security
integrate security
one tool we use **fuzzing** the security analysis tool
fuzzing Light house
try to secure all of the clients
global open source contribution differential fuzzing
all of the clients at once

## Biggest challenge for client implementation

Hsiao-Wei:
client actually connect to each other
biggest challenge client...

Adrian:
the client interopability test
things explode
lighthouse in particular we managed to avoid that
using Rust
hard to keep track of everything
there's an update in Rust where we needed to rewrite everything

Alex:
libp2p working with Raul and various teams. how to make this work for both parties. First time clients talking to each other. many bugs. Python client compared to Rust is much slower. beyond writing performance test. Lots of fun.

Diederik:
Many clients. randomly finding bugs
8 different implementations
help each other find bugs

## Questions for Diederik

Hsiao-Wei:
I have a question for D
Diederik is only 21 years old, being a researcher at EF is his first job after dropping the school.
What's your story
esppeically Eth2.0

Diederik:
community endless meetups you can go all over the world
open finance, create your own rules
permissionless
different legos
In the world many different developers communities different things come together
protocols you can build and contructions you can build

computer science problems
dive into and try and dig it it's really rewarding
it all comes together as protocol develepment.

Danny:
The best hires that EF and the ecosystem
People show up and do the hard work
finding things you are passionate about
I was talking to Chih-Cheng Asian culture operate very direct way just go for it. Proto is one of the best developers.. he is just a guy that showed up..

DiederiK
moved to Hong Kong had many meetups
if you reach out and contact these people

Adrian:
If you like Rust, you like Go,

## What to expect next

Hsiao-Wei:
what can we expect
what can we look forward

Adrian:
If you find something that you're interested in
anything you're passionate in. Dig in. Passionate about the Rust language. They really like Rust. don't need to know anything about blockchain. DHT. Rust Programming Language.

Danny:
I spent a long time using open source and admiring open source. Typo in README, just go fix it. Just do it. Started doing little things. Start making little contributions.

Vitalik:
I definitely did some typo fixing back in the days.

###### tags: `crosslink2019`