Connect with us

Ethereum

Ethereum [ETH] 2.0 client: Lighthouse project update released

Anvita M V

Published

on

Ethereum [ETH] 2.0 client: Lighthouse project update released
Source: Unsplash

Recently, the developer team at Sigma Prime also known as SigP took to Twitter to announce an update on the recently launched open source Ethereum 2.0 client called ‘Lighthouse’. The team discussed the progress in the project and laid out the roadmap for future work.

In the official blog post, the team stated that the post covers the progress in the Lighthouse project carried out in the past two weeks. The team has successfully implemented the pre-processing of the Block. Lighthouse update 1 includes a Boneh–Lynn–Shacham [BLS] aggregate signature. However, the team stated that the BLS signatures are still unsafe.

A simpleSerialize [SSZ] has been implemented. A draft specification of the SSZ produced by SigP has been merged into the Ethereum 2.o specification repository.

Furthermore, they explained the block pre-processing implementation. SigP stated that it has been the most significant achievement implementing and benchmarking it.

The block pre-processing involves the process of accepting a serialized block from an untrusted source and “deeming” it valid. According to the team, the pre-processing stage is required to reduce the impact of malicious blocks on the system. The processing will be quick and inexpensive.

They further explained that the pre-processing stage involves many steps like validating the attestations, processing the attestations concurrently, de-serialization of records before validation to fail in cases of “bad attestations”. They added:

“A single invalid attestation invalidates the entire block so we avoid de-serializing them all up-front.”

The team also stated that they have performed pre-processing benchmarks. With the implementation of the BLS aggregate signatures, the team was able to use real signature verification and provide the pre-processing benchmarks.

According to the team, there has been some confusion in the Ethereum community regarding 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 mitigates the “rouge-key attack” and allows signatures across distinct messages but is slower. Eth 2.0 protects against the rouge-key attack by requiring a bls_proof_of_possession on validator registration and naturally requires all signed messages to be identical (non-distinct).”

They added that the old scheme was faster and they did not require the features of the ‘new’ scheme.

Over the coming weeks, the team stated that they will be working on fuzzing framework, libp2p daemon, state transition logic. They will also be working on an implementation of the Friendly Finality Gadget [FFG] fork choice rule.





Subscribe to AMBCrypto’s Newsletter




Follow us on Telegram | Twitter | Facebook



Anvita Mysore Vadiraj is a full-time content writer at AMBCrypto. Her passion lies in writing and delivering apt information to users. Currently, she does not hold any form of cryptocurrencies.

Ethereum

Ethereum [ETH]: ProgPow audit may not be completed before Istanbul

Priya

Published

on

By

Ethereum [ETH]: ProgPow audit may not be completed before Istanbul
Source: Unsplash

Programmatic Proof-of-Work [ProgPow] has undoubtedly been one of the most controversial upgrades of Ethereum. The algorithm that promises to ward off ASIC mining would probably not make it till after the Istanbul hardfork. A blog post titled ‘ProgPow Audit Delay Issue’ published by Hudson Jameson, a member of EF, stated that they encountered problems with ProgPow audit.

Hudson Jameson explained the situation,

“We had a hardware partner who specialized in ASICs who was going to work with Least Authority to perform the hardware parts of the audit. They are no longer participating in the audit so we are looking for other auditors for the hardware portion.”

Further, Jameson stated that there were “some good candidates” to fill in the position, however, it would “effectively delay” the start of the audit even further than what they had anticipated. This was the sole reason the team was uncertain whether the audit would be ready before the Istanbul hardfork.

Along with this, the member also spoke about the funding pertaining to ProgPow miner, where he remarked,

“On top of that I am not sure if anyone has sorted the funding situation in order to build an open source ProgPoW miner.”

Due to these problems, Hudson presented two options, first, delay “ProgPoW until the hardfork after Istanbul”, and second, let ProgPow have its own hardfork once the audit was completed. Hudson further stated that “this was not an ideal situation at all, but despite our best efforts, it is what we have before us”.



McDogger, a Redditor said,

“I personally would prefer a third option (stop with the audits, drop progpow and spend time/ money on Eth 1.x finality) but if I had to chose than it’s certainly option 1. Progpow […] doesn’t deserve it’s own – contentious, because it’s just one change and not many other improvements – hardfork.”

The initial announcement was made on Ethereum Cat Herders Update #9, where Pooja Ranjan, a EF member, stated that “logistical issues” were the reason for the delay of ProgPow audit, adding that the timeline for the start and end of the audit were not even decided yet.





Subscribe to AMBCrypto’s Newsletter


Continue Reading

Trending