Successes with merge testnets, plans for a v1.4.0 release.
TL;DR
- Lighthouse was involved in the successful launch of the Nocturne merge testnet.
- A new v1.4.0 release is planned for mid-June which contains several shiny new features.
Rayonism (Merge Testnets)
In very exciting news, the Nocturne testnet launched successfully this week. As of the time of writing, it's operating successfully with ETH transfers and contract deployments happening smoothly.
This is the most successful "merge" testnet we've seen so far; a great indication for the ability for Ethereum ditch proof-of-work this year or next.
... a great indication for the ability for Ethereum ditch proof-of-work this year or next.
We don't expect this testnet to last too long though, development is still not complete and there are active efforts running to try and break it (so we can learn from the failures). The goal for Nocturne is to provide a platform for development and experimentation, not indication of full production readiness.
The goal for Nocturne is to provide a platform for development and experimentation, not indication of full production readiness.
You can inspect the chain at the Nocturne beaconcha.in explorer. If you look closely you'll see that the Lighthouse team was lucky enough to be randomly assigned the first block in the Nocturne chain! This doesn't mean a whole lot, but it's certainly a pleasant surprise.
There isn't any public documentation for joining this testnet, but technically-advanced users can hop into the Rayonism Discord channel and ask for some help. I politely and respectfully request that you only do this if you plan to contribute, the developers are very busy and on-boarding spectators to an unpolished testnet may not be the best use of their time.
Release: v1.4.0
It's been almost a month since the previous Lighthouse release. Generally, I think this is a good thing. It means we haven't been discovering critical bugs and pestering users with updates. Updating a staking set up is a source of anxiety for users and we strive to achieve a "set and forget" experience.
Updating a staking set up is a source of anxiety for users and we strive to achieve a "set and forget" experience.
That being said, we're still not complete with Lighthouse development and I'm not sure we ever will be. We've got some major new features we'd like to deliver and some annoying quirks to fix.
To balance the yin and yang of continual improvement verses hands-free operation, we've decided to roll our upcoming features into one big release: v1.4.0: Space Beth. This is our first Beth release and we hope that our release can be as rad as she is.
In addition to being less work for users, rolling our features into a single release also gives the ability to run a beta program to catch any annoyances before they hit the production stream.
Our list of features is ambitious, so we're not announcing a firm release date, but we're aiming to release v1.4.0 in mid-June. It's important to note that we're not guaranteeing zero releases between now and v1.4.0, if there are bug fixes required we'll be publishing v1.3.x releases.
.. we're aiming to release v1.4.0 in mid-June.
The rest of this post will list and describe the features we intend to include in v1.4.0.
v1.4.0: Beta Windows Support
Presently Lighthouse only supports Windows via Windows Subsystem for Linux (WSL). We know that there are a lot of Windows users out there that would like to run Lighthouse and we're sorry we haven't been able to fully support you so far.
In v1.4.0 we'll be including Enable Compatibility with Windows by our newest team member ethDreamer.
This will mark beta support for Windows. Before we announce full Windows support we'd like to give ourselves some more time to do extensive testing and fully integrate Windows into our testing infrastructure.
Thanks again to ethDreamer for taking the initiative here. We hope that Windows users can see this is a commitment to Lighthouse being as inclusive as possible 💖.
v1.4.0: Over 80% Reduction in Eth1 Queries
Over in #2340, macladson has been working on reducing the amount of outbound requests to Eth1 nodes by over 80%!
This means less work for your Eth1 node (e.g., Geth, Nethermind, etc) and fewer requests on any centralized pay-to-play service you might be using as a backup (e.g., Infura, Alchemy, etc).
v1.4.0: Approximately 50% Reduction in Memory Usage
As discussed heavily in previous blog posts, I've been working on tuning the GNU memory allocator over in #2299.
Testing and benchmarking is going very well and we're looking at reducing the memory footprint of a Lighthouse Beacon Node by about 50%.
I've been excited to ship this optimization for some time now, but I'm taking my time to ensure we choose optimal parameters that deliver tangible benefits without causing side-effects.
v1.4.0: Initial Altair Support
Altair is the first upgrade (viz., hard-fork) of the Beacon Chain and, according to the Altair spec, provides:
- Sync committees to support light clients.
- Incentive accounting reforms to reduce spec complexity.
- Penalty parameter updates towards their planned maximally punitive values.
Whilst v1.4.0 wont actually result in the implementation of the Altair
upgrade on the Beacon Chain, it will be the first time the Altair components are included in the
Lighthouse stable branch. Having the Altair code in stable is a step closer
towards the initial Altair forks we'll apply to the Pyrmont and Altair
testnets before we target Mainnet. It also means we can continue to develop new
features with respect to the Altair upgrade.
v1.4.0: Doppelganger Protection
A doppelganger is a term which has been coined to refer to the same validator running on two different validator clients. As all astute stakers know, running the same validator twice is a mortal sin and practically guaranteed to result in slashing.
Doppelganger protection is an on-by-default feature we're adding to the Lighthouse Validator Client (VC) which involves waiting for 2-3 epochs before starting a validator. During this waiting period, the VC will query the Beacon Node to see if it has seen that validator producing signed messages during this waiting period. If messages are found, the VC will assume that another instance of that validator exists and shut down the entire VC.
This ultimately results in a trade-off; lose a few attestation rewards and very rarely a block reward but gain additional protection from slashing. The costs of missed rewards (less than US$10) verses being ejected from the validator set and waiting until withdrawals are implemented seems like a no-brainer to us. We'll provide doppelganger protection by default, but allow the dare-devils out there to disable it with a CLI flag.
It's important to note that doppelganger protection is an imperfect and best-effort slashing protection approach. Users will still need to be as cautious as ever with regards to duplicating their validators. Don't get foolhardy just because there's an additional layer of protection!
Thanks to realbigsean for his efforts on implementing this feature over in Doppelganger Protection.
v1.4.0: Remote Signer Support
Some institutional users have recently indicated that support for remote signers in the Lighthouse Validator Client (VC) is very important for them.
Presently, the VC expects all validator keys to be stored as an encrypted keystore on the filesystem. With v1.4.0, we'll also add the ability for the VC to call out to some remote server supporting the EIP-3030 remote signer interface for signatures. This permits a separation of the VC and cryptographic key material.
Lighthouse already includes a server-side implementation of EIP-3030 by hermanjunge, it's just the VC that needs to be updated to support calls to this server.
We don't expect this feature to be useful to everyday users, the separation between the Beacon Node (BN) and VC is adequate for most non-enterprise solutions.