[ad_1]
Recently, the team of developers of Sigma Prime, also known as SigP, took Twitter to announce an update on the recently launched Open Source Ethereum 2.0 client called "Lighthouse". The team discussed progress in the project and outlined the roadmap for future work.
In the official blog post, the team stated that the post covers the Lighthouse project's progress over the past two weeks. The team successfully implemented block preprocessing. The Lighthouse 1 update includes a Boneh-Lynn-Shacham [BLS] aggregate signature. However, the team stated that the BLS signatures are not yet available.
A simpleSerialize [SSZ] it has been implemented. A draft specification of the SSZ produced by SigP has been incorporated into the Ethereum 2.o specification repository.
Furthermore, they explained the implementation of block preprocessing. SigP stated that it was the most significant result to implement and compare it.
Block pre-processing involves the process of accepting a serialized block from an untrusted source and "believing it" to be valid. According to the team, the pre-processing phase is needed to reduce the impact of malicious blocks on the system. Processing will be quick and inexpensive.
They also explained that the pre-processing phase involves many steps such as the validation of claims, the simultaneous processing of certificates, the de-serialization of records before the validation fails in cases of "bad claims". They added:
"A single invalid certificate invalidates the entire block, so we avoid having to serialize all of them in advance".
The team also stated that they performed pre-processing benchmarks. With the implementation of the BLS aggregated signatures, the team was able to use real signature verification and provide pre-processing benchmarks.
According to the team, there was some confusion in the Ethereum community about the exact BLS aggregation scheme used in the Ethereum 2.0 specification. SigP stated:
"Ethereum 2.0 uses the" old "scheme described in BGLS03.The new scheme attenuates the" rouge-key "attack and allows signatures through separate messages but is slower.Em 2.0 protects against keystroke rouge requesting a bls_proof_of_possession to register the validator and of course requires that all signed messages are identical (not distinct). "
They added that the old scheme was faster and did not require the characteristics of the "new" scheme.
In the coming weeks, the team said they will work on fuzzing framework, libp2p daemon, state transition logic. They will also work on an implementation of the Friendly Finality gadget [FFG] rule of choice of the fork.
Source link
