Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
clientdiversity-org
This is the source code for https://clientdiversity.org, a resource site to assist client diversity efforts.
-
-
annotated-spec
Vitalik's annotated eth2 spec. Not intended to be "the" annotated spec; other documents like Ben Edgington's https://benjaminion.xyz/eth2-annotated-spec/ also exist. This one is intended to focus more on design rationale.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
What surprises me most about the Ethereum ecosystem is the software and release engineering of the implementations, especially the reference (now execution layer) go-ethereum.
As has been noted elsewhere "the merge" has been in progress for years. Here we are approximately three weeks out and just this morning the (allegedly) working merge ready go-ethereum client was released. Given that the Bellatrix upgrade is scheduled for 9/6 this gives the approximately 4500 Ethereum nodes (of which 3381 are geth)[0] 10 days to update...
It also doesn't help that they botched the prior release (two days ago) of the geth client that had a nasty corruption issue that requires a little more than the update warning footnote in this release to fix[1]. Many people who deployed 1.10.22 are re-syncing from (almost) scratch.
Even if you followed Prysm and the other Beacon implementations the deployment and configuration changes required are non-trivial[2] and again, the v3 release referenced in this announcement was only released two days ago!
As someone who runs Ethereum nodes I'm a little gun shy at this point deploying new releases of this stack, especially given how things have gone the past two days. Even with our relatively trivial application this gives little time for any testing or assurance process.
It's amazing to me given the stakes (value of the Ethereum chain) and complexity (huge) node operators are essentially in the position of waiting until mere days (or hours) to upgrade their nodes and as noted - there are thousands of us around the world.
IMO this is yet another indication that the real issue with regard to decentralization of blockchain solutions is the fact that (as pointed out by Moxie and others) the vast majority of the real users and platforms of Ethereum interact with the chain via a handful of centralized node providers (Alchemy, Infura, etc). Who can blame them given what a mess this is?
I'm also not picking on Ethereum specifically, the same things could be said about most of the other chains and implementations I've interacted with. Given the hype, promise, age, and value in the blockchain ecosystem the software itself makes Apache circa 1996 look like mature, rock solid software.
BTW, the Ethereum Foundation alone holds approximately $1.6B in assets[3] and investors have poured tens of billions of dollars in this ecosystem. IMO the quality and process of the fundamental software enabling all of this is inexcusable - it's not like they're wanting for resources to do this right.
[0] - https://ethernodes.org/
[1] - https://github.com/ethereum/go-ethereum/releases
[2] - https://docs.prylabs.network/docs/prepare-for-merge
[3] - https://www.coindesk.com/business/2022/04/19/ethereum-founda...
If you have a GPU that has more than 4 GB VRAM, you should be able to easily run it:
https://github.com/basujindal/stable-diffusion
I didn't manage to run it on mine, as it segfaults, but I've heard of people running it fine on an old 1060 (which I have too).
Client diversity has improved in recent months, particularly consensus clients:
https://clientdiversity.org/
I am one of the maintainers of the Go implementation of Ethereum proof-of-stake, called [Prysm](https://github.com/prysmaticlabs/prysm) and also implemented a "slasher" in Go that can be used to slash malicious validators. Anyone can run a slasher and you don't need to have 32 ETH to do so. As long as your slasher software can prove that a validator committed a slashable offense, you can submit this proof to any full node to proceed with slashing the malicious actor. It is permissionless, global, and we only need a few honest slashers in the world for the system to work correctly
https://github.com/ethereum/annotated-spec/blob/master/phase...
Here we have slashing fields in the block body where you insert your proofs of slashable offense. There are functions with a “slash” in the name that describes precise state transition.
The hard part of slashing is finding these proofs because you have to do more work than necessary to detect slashing and produce proofs - that’s what this software does. It’s more expensive to run a slasher but you need only one and it does not matter who runs it, anyone can run it. The link that you sent says that this slasher broadcasts proofs by default - that way anyone can include it.