ethereumjs-monorepo VS eth2.0-specs

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)

Eth2 beacon blocks get a "graffiti" data field, "to be used in wonderful and unpredictable ways".

Eth2.0 spec v0.6.0 "Spring Cleaning" is out.

Ethereum developers propose an increase in validator rewards for Eth 2.0 .

Eth2 Phase 0 spec v0.3 is out, named "Let There Be Liquidity", which includes a number of small feature additions/modifications, clarifications, and minor bug fixes.

Justin Drake adds a mechanism to the Eth2.0 spec for validators to transfer their balance on the beacon chain (to be removed after phase 1).

The Eth2 spec v0.2 gets out, containing a number of small feature additions/modifications, helpers, clarifications, minor bug fixes, and the introduction of a point-wise shuffle.

And finally, hard-core specs here: https://github.com/ethereum/eth2.0-specs

The Ethereum 2.0 spec v0.12 "Quarantine Haircut" uses IETF's hash-to-curve draft for BLS, and is the closest version to the final Eth 2.0. release.

"offence is identified and protocol-level penalties are enacted by a “whistleblower.” The whistleblower collects evidence of the offence and commits proof(s) to a block proposer for inclusion on-chain. After Phase 0 the whistleblower will earn the majority of those rewards (seven-eighths), but in Phase 0 the block proposer earns the full reward."

Eth2 beacon blocks get a "graffiti" data field, "to be used in wonderful and unpredictable ways".