ethereumjs-monorepo VS ETH-Staking-Service-22Cap-Signaling

EthereumJS VM is an Ethereum client written in javascript, so if you can write an Ethereum client in JavaScript it seems pretty reasonable that you could write an alternative with Javascript. The thing is, EthereumJS VM isn't actually fast enough to keep up with the mainnet blockchain, and it would be difficult to write a full featured blockchain with a turing complete scripting language that could process transactions on par with the volume of transactions Ethereum handles in JavaScript for performance reasons. Certainly you could write something lower volume in JavaScript.

If it is a precompile, then we have just a handful of choices.

For instance, when I first read the EVM source code I knew JS the best, thus I read the source code from the Ethereum JS GitHub repo: https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm

Daily Kiln: Beacon sync merged to master for ethereumjs. Still trying to solve The Mystery of the Missing Receipts. Sometimes a CL client throws an error about non-consecutive deposit indexes, and it doesn't resolve without a fresh sync. There was a regression in lighthouse that I was helping troubleshoot for a couple of new testers in #testingthemerge. There's an open PR that fixes it.

Daily Kiln: erigon is fixed, so I'm back to lighthouse-ethereumjs being the only client pair with issues. This PR might fix that, but I'm waiting until optimistic sync gets merged to the master branch before switching back to it.

Daily Kiln: sproul (from lighthouse) was able to use some information I provided to troubleshoot issues with lighthouse-ethereumjs. ethereumjs is missing some fields required by the spec in the response to eth_getBlockByHash. In addition, he created an issue for lighthouse so it won't mark the EL as offline if a non-essential API call fails.

Daily Kiln: lighthouse and nimbus both pushed updates which fixed syncing with ethereumjs by increasing the timeout for engine_new_payload (as well as engine_forkchoice_updated in just lighthouse). ethereumjs has a pending pull request which should improve speed by only executing the block in engine_new_payload. There's a strong possibility that I'll have 25/25 client pairs synced and attesting by tomorrow.

Daily Kiln: Today's focus was ethereumjs. I set up all five client pairs. I addressed a number of issues that I encountered in their Discord with ryanio - mostly incorrectly handled RPC calls - and one of those issues resulted in a pull request to fix compatibility with teku.

JavasScript (from ethereumjs)

I tried to help u/superphiz with his 22% limit (see: my GitHub page where I tried to help community engagement). Outside of a few token responses by projects that would never reach 22% anyway, nothing. Funnily enough, to Lido's credit (yucky!) they were actually one of the few projects to take the request seriously, although it was shot down by governance pretty handily. I don't care enough to link the thread (unless you really want me too, I can), but Lido governance made it clearly it doesn't really think they are doing anything wrong. They view themselves as a Union type entity. And while I've saved my hear the struggle by not keeping up with it... I'm doubtful much of their internally proposed solutions to help mitigate risk made it to pass, or were super low hanging fruit.

If I became a HOP delegate, this would be my first time doing any type of delegated governance work. So I can understand some hesitation in delegating to a new coming. However, between the general knowledge throughout my history in the space and my involvement in other projects I think I can do a good job at it. Some examples where I've been part of projects to better the Ethereum ecosystem include content creation for Support1559.org (no longer functional, so here is the GitHub referencing that as part of a bigger EIP1559 signaling project), ethsunshine.com (commits), and ethmerge.com (joint commit). I also took a stab an aggregating commitments to 22% staking caps (GitHub Page), as well as am one of the multisig members of the EVMavericks project. Those have all had varying degrees of success, but they have been steps in my goal of being more than a passive investor. As noted above, I think trying out the delegate space is sort of a new mountain to conquer, hence my hemming and hawing about it broadly.

HERE is the current list of staking entities that have either committed, not committed, or haven't responded. As always, any suggestions, content to add, or Pull Requests are welcome!

As always, the list can be found here of entities who have not made commitments yet.

In the meantime, our work is not done. There are still 20 other staking entities with over .1% of network penetration that have not committed to capping at 22%. Over the weekend I created a page to track all the staking entities commitments - https://github.com/BobRossiETH/ETH-Staking-Service-22Cap-Signaling. Getting a big list of committed entities will go a long way to putting pressure on the Lido DAO to commit as well. It will be a harder sell for someone to limit themselves if no one else is doing it...

Quick update since last night. What started with just Stakewise now has Rockepool and Swell Network publicly committing to keep their Validator share under 22% of the network! Progress can be tracked here - https://github.com/BobRossiETH/ETH-Staking-Service-22Cap-Signaling