Nuovo aggiornamento da parte di Danny Ryan circa l’andamento dello sviluppo della fase POS.
In questa “puntata”, in particolare viene analizzato il passaggio da Eth 1 ad Eth 2.0 (https://blog.ethereum.org/2019/11/21/eth2-quick-update-no-4/ ) .
“Welcome to the fourth installment of eth2 quick update. There are a lot of moving pieces to talk about this week. Other than the heroic eth2 client development going on, these are the highlights:
tldr;
- Grant to Sigma Prime for eth2 differential fuzzing
- Light Client Task Force is formed
- Some notes on the uni-directional bridge between eth1 and eth2
Differential fuzzing grant
Sigma Prime has been awarded a grant to lead the differential fuzzing effort for eth2 clients. This effort is critical to the success of launching a multi-client network by aiding in catching consensus issues prior to mainnet.
The act of “fuzzing” is the act of throwing many random inputs at a piece of software to see how it reacts. When fuzzing a single piece of software, the goal is often to find inputs that lead to unexpected crashes. When we find such inputs, we then figure out what went wrong and harden the software to this type of input.
Differential fuzzing is a bit different. Instead of explicitly looking for crashes, we look for instances in which different implementations of a protocol have a different output for the same input. In a blockchain context, we use differential fuzzing to find cases in which a series of blocks leads to a different resulting state on two different clients. Ideally in production there are no such cases.
Light client task force
Chainsafe/Lodestar, the recipients of an Ethereum Foundation grant for research and development on eth2 light clients, has formed the Light Client Task Force. This group has tasked themselves with ensuring that light clients are first class citizens in eth2. To this end, they are hosting a monthly call aimed at driving light client research, standards, specs, and education.
The need for a rich ecosystem of light clients and light client servers is only amplified in a sharded protocol like eth2. Even if a client is syncing some subset of the protocol (e.g. just a couple of shards), a user will very often need to get information about accounts, contracts, and the general state of things on another shard. A client could inefficiently sync the entire additional shard, but more often than not, lightly requesting information about specific accounts on the shard with succinct proofs will be the way to go.
Tune in to the next Light Client Task Force call to stay up-to-date on all things light in eth2.
eth1 -> eth2
In the early days of eth2, the transfer of ether from the existing ethereum chain (eth1) into the new beacon chain (eth2) will be uni-directional. That is, the ether moved into staking on eth2 will not be transferable (to start) back to eth1. The choice of a single directional transfer into validation is in an effort to minimize the risk profile that eth2 induces upon eth1, and to allow for a quicker development cycle on eth2 without having to fork eth1 in the process. There is some movement around creating a bi-directional bridge, but I’ll save discussion of the bridge mechanics and the trade-offs for a later post. Today, I’d like to get more into how this uni-directional transfer works and how it can be safely implemented without changing eth1.
On the existing ethereum PoW chain, we will deploy the eth2 validator contract. This contract has a single function called deposit which takes in a number of parameters to initialize a new validator (e.g. private key, withdrawal credentials, an ETH deposit, etc). There is no withdrawal function on this contract. Barring a fork to add in a bi-directional bridge, this deposited ETH now only exists in eth2 on the beacon chain.
It is then the validators’ responsibility on the beacon chain to come to consensus on the state of this contract such that new deposits can be processed. This is done by eth2 block proposers embedding recent eth1 data into a beacon block field called eth1_data. When enough block proposers during a voting period agree on recent eth1_data, this data is enshrined in the beacon chain state allowing for new deposits to be processed.
An important note about this mechanism is that the eth1_data is deep in the eth1 PoW chain – ~1000 blocks of “follow distance”. This follow distance induces a high latency in processing new validator deposits, but provides a high degree of safety in the coupling of these two systems. The eth1 chain would have to re-org deeper than 1000 blocks to break the link, and in such a case would require some manual intervention to overcome.
We are researching and prototyping the utilization the beacon chain to finalize eth1 (i.e. the finality gadget). This would require eth1 to defer its fork choice ultimately to the beacon chain, gaining security from the PoS validators, and allowing for a much quicker eth1 to eth2 deposits. The finality gadget also opens up other fun things such as the bi-directional bridge and exposing the eth2 data-layer to eth1. More on all of this in a later post :rocket:.”
credits: Danny Ryan
Eth1—–>Eth2.0 [traduzione in Ita]
All’inizio di eth2, il trasferimento di ether dalla catena ethereum esistente (eth1) alla nuova catena beacon (eth2) sarà unidirezionale. Cioè, l’ether spostato in staking su eth2 non sarà trasferibile (per iniziare) a eth1. La scelta di un singolo trasferimento direzionale in validazione è nel tentativo di minimizzare il profilo di rischio che eth2 induce su eth1 e di consentire un ciclo di sviluppo più rapido su eth2 senza dover deviare eth1 nel processo. C’è qualche movimento nel creare un collegamento bidirezionale, ma salverò la discussione sulla meccanica dello steoo e sui compromessi in un post successivo. Oggi, vorrei approfondire il modo in cui funziona questo trasferimento unidirezionale e come può essere implementato in sicurezza senza cambiare eth1.
Sulla catena PoW ethereum esistente, implementeremo il contratto di validazione eth2. Questo contratto ha una singola funzione chiamata deposito che accetta una serie di parametri per inizializzare un nuovo validatore (ad es. Chiave privata, credenziali di prelievo, un deposito ETH, ecc.). Non esiste alcuna funzione di recesso su questo contratto. Escludendo un fork da aggiungere in un collegamento bidirezionale, questo ETH depositato esiste ora solo in eth2 sulla beacon chain.
È quindi responsabilità dei validatori sulla beacon chain giungere a un consenso sullo stato di questo contratto in modo tale da poter elaborare nuovi depositi. Questo viene fatto dai proponenti del blocco eth2 che incorporano i recenti dati eth1 in un campo di blocco beacon chiamato eth1_data. Quando un numero sufficiente di proponenti di blocchi durante un periodo di votazione concorda sui recenti eth1_data, questi dati sono racchiusi nello stato della catena beacon, consentendo l’elaborazione di nuovi depositi.
Una nota importante di questo meccanismo è che eth1_data ha una profondità nella catena PoW eth1 di ~ 1000 blocchi di “follow distance”. Questa distanza di follow-up induce un’elevata latenza nell’elaborazione di nuovi depositi validatori, ma fornisce un elevato grado di sicurezza nell’accoppiamento di questi due sistemi. La catena eth1 dovrebbe riorganizzare più di 1000 blocchi per interrompere il collegamento, e in tal caso richiederebbe un intervento manuale per superarlo.
Stiamo ricercando e prototipando l’utilizzo della catena beacon per finalizzare eth1 (ovvero il finality gadget). Ciò richiederebbe che eth1 rinvii in definitiva la sua scelta di fork alla beacon chain, ottenendo sicurezza dai validatori PoS e consentendo un deposito molto più veloce di eth1 in eth2. Il finality gadget apre anche altre cose divertenti come il collegamento bidirezionale ed esponendo il livello di dati eth2 a eth1. Maggiori informazioni su tutto questo in un post successivo
