docs: migrate old blog posts

docs/index.md

@@ -0,0 +1 @@
+# hi

posts/kintsugi-merge.md

@@ -0,0 +1,185 @@
+---
+layout: post
+title: Nimbus + Nethermind - Kintsugi tutorial
+description: Ethereum can support both full nodes and light clients, it contains a peer to peer layer which allows nodes to send messages to each other.
+date: 2021-11-23T10:00
+authors: sacha
+published: true
+---
+
+# Nimbus + Nethermind - Kintsugi tutorial
+
+<!-- truncate -->
+
+![header-image](/posts/kintsugi-merge/header.png)
+
+_Diagram courtesy of Mikhail Kalinin's [Engine API design space](https://hackmd.io/@n0ble/consensus_api_design_space) document. Note that this diagram dates from the Amphora era, and so is not strictly accurate. Nevertheless the general communication flow between consensus and execution for Kintsugi is the same._
+
+> Kintsugi, also known as kintsukuroi, is the Japanese art of repairing broken pottery by mending the areas of breakage with lacquer dusted or mixed with powdered gold. [pic.twitter.com/M9BiJfLqLb](https://t.co/M9BiJfLqLb)
+> 
+> — Monica Zeng (@monicazng) [November 27, 2020](https://twitter.com/monicazng/status/1332314234265477121?ref_src=twsrc%5Etfw)
+
+The Merge November sprint – _Kintsugi -_ has kicked off.  
+  
+Kintsugi [specs](http://spec.merge.wiki/) and [milestones](https://notes.ethereum.org/@djrtwo/kintsugi-milestones) were released earlier this month. And we, along with the other client teams, have started participating in the weekly rolling merge devnets in preparation for the more open and persistent testnet planned for early December.
+
+### #[Kintsugi spec: quick recap](#kintsugi-spec-quick-recap)
+
+Kintsugi incorporates all of the learnings (along with some minor adjustments) from the previous interop, [Amphora](https://blog.ethereum.org/2021/10/15/amphora-merge-milestone/).  
+  
+At a high-level, the scope of work on updating consensus layer client software to Kintsugi specification is as follows:
+
+* Implement the new version of consensus-spec and pass all consensus-spec tests
+
+* Implement the new version of [Engine API](https://github.com/ethereum/execution-apis/blob/89070c4d6f2fbe125a906f0cca1fedda84b8a2a6/src/engine/specification.md) method calls
+
+* Implement or update already existing implementation of the [optimistic sync](https://github.com/sigp/lighthouse/issues/2691)
+
+On the execution layer side, it looks like this:
+
+* Implement the new version of [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675)
+
+* Implement [EIP-4399](https://eips.ethereum.org/EIPS/eip-4399)
+
+* Implement the new version of [Engine API](https://github.com/ethereum/execution-apis/blob/89070c4d6f2fbe125a906f0cca1fedda84b8a2a6/src/engine/specification.md) server
+
+
+> Support Ethereum ecosystem client diversity!  
+>   
+> Consider running:  
+>   
+> \* Nethermind [https://t.co/8A3bkliGAy](https://t.co/8A3bkliGAy) or Besu [https://t.co/RNPpIXrVX3](https://t.co/RNPpIXrVX3) for an ethereum mainnet node  
+>   
+> \* Nimbus [https://t.co/8LWdsGEuKi](https://t.co/8LWdsGEuKi) or Teku [https://t.co/mXUWTxKlPu](https://t.co/mXUWTxKlPu) if you're on the eth2 Medalla testnet
+> 
+> — vitalik.eth (@VitalikButerin) [August 11, 2020](https://twitter.com/VitalikButerin/status/1293317390613110785?ref_src=twsrc%5Etfw)
+
+In line with our commitment to client diversity, this tutorial will tackle how to run a Nimbus local testnet with Nethermind (if you wish to do the same with Geth, see [this document](https://github.com/status-im/nimbus-eth2/blob/unstable/docs/interop_merge.md)).
+
+We assume you have a working and up to date installation of Nimbus - if this is not the case, please start by following the instructions [here](https://nimbus.guide/quick-start.html).
+
+### 1- Install dotnet
+
+[Nethermind](https://docs.nethermind.io/nethermind/) is a .NET Core-based Ethereum client, so the first step is to download dotnet.
+
+```
+https://dotnet.microsoft.com/download
+```
+
+_Note that you may need to download a specific version of dotnet to be able to build the Nethermind kintsugi branch. In this guide we use version `5.0.12`. By the time you read this guide you may need version `6.0`._
+
+### 2- Build Nethermind
+
+From the command line, run the following:
+
+```
+git clone https://github.com/NethermindEth/nethermind.git --recursive -b themerge_kintsugi
+cd src/Nethermind
+dotnet build Nethermind.sln -c Release
+# if src/Nethermind/Nethermind.Runner/bin/Release/net5.0/plugins has no Nethermind.Merge.Plugin.dll plugin then you may need to run the build again
+dotnet build Nethermind.sln -c Release
+```
+
+### 3- Run Nethermind
+
+Once Nethermind has been built, you are ready to run it:
+
+```
+cd Nethermind.Runner
+rm -rf bin/Release/net5.0/nethermind_db
+dotnet run -c Release -- --config themerge_kintsugi_m2 --Merge.TerminalTotalDifficulty 0
+```
+
+### 4- Checkout the Nimbus Kintsugi branch
+
+With Nethermind running, open a separate terminal window. Change into the `nimbus-eth2` directory and run:
+
+```
+git checkout kintsugi
+git pull
+make update
+```
+
+### 5- Launch local testnet
+
+Still in `nimbus-eth2`, run:
+
+```
+./scripts/launch_local_testnet.sh --preset minimal --nodes 4 --disable-htop --stop-at-epoch 7 -- --verify-finalization --discv5:no
+```
+
+This will create a 4-node local testnet with 128 validators that will exist for 7 epochs. Feel free to try out different parameters if you so wish.
+
+### 6- Check Nimbus' output
+
+If all is working correctly, the Nimbus console output should look something like:
+
+```
+nimbus-eth2$ N=0; while ./scripts/launch_local_testnet.sh --preset minimal --nodes 4 --disable-htop --stop-at-epoch 8 -- --verify-finalization --discv5:no; do N=$((N+1)); echo "That was run #${N}"; sleep 67; done
+Building: build/nimbus_beacon_node
+Building: build/nimbus_signing_process
+Building: build/deposit_contract
+Build completed successfully: build/nimbus_signing_process
+Build completed successfully: build/deposit_contract
+Build completed successfully: build/nimbus_beacon_node
+NOT 2021-11-17 15:40:11.894+01:00 Generating deposits                        tid=966934 file=keystore_management.nim:562 totalNewValidators=128 validatorsDir=local_testnet_data/validators secretsDir=local_testnet_data/secrets
+NOT 2021-11-17 15:40:51.434+01:00 Deposit data written                       tid=966934 file=deposit_contract.nim:222 filename=local_testnet_data/deposits.json
+Wrote local_testnet_data/genesis.ssz
+WRN 2021-11-17 15:40:51.443+01:00 Using insecure password to lock networking key key_path=local_testnet_data/network_key.json
+INF 2021-11-17 15:40:52.184+01:00 New network key storage was created        topics="networking" key_path=local_testnet_data/network_key.json network_public_key=08021221029b0d9c63dc15335b6f1f73dc359a0bda88a84cc7e0346f12e64084673a35a915
+Wrote local_testnet_data/bootstrap_nodes.txt
+Wrote local_testnet_data/config.yaml:
+DEPOSIT_NETWORK_ID: 1
+PRESET_BASE: minimal
+MIN_GENESIS_ACTIVE_VALIDATOR_COUNT: 128
+MIN_GENESIS_TIME: 0
+GENESIS_DELAY: 10
+DEPOSIT_CONTRACT_ADDRESS: 0x0000000000000000000000000000000000000000
+ETH1_FOLLOW_DISTANCE: 1
+ALTAIR_FORK_EPOCH: 1
+MERGE_FORK_EPOCH: 2
+TERMINAL_TOTAL_DIFFICULTY: 0
+That was run #1
+```
+
+If you're using macOS you may also see a bunch of warnings that look like
+
+```
+warning: (x86_64)  could not find object file symbol for symbol _br_rsa_pkcs1_sig_unpad.pad1
+```
+
+You can safely ignore these.
+
+### 7- Check Nethermind's output
+
+On the Nethermind side, you should pay particular attention to the following JSON RPC calls: `engine_forkchoiceUpdatedV1`, `engine_getPayloadV1`, `engine_executePayloadV1` – these document the consensus calling the [engine api](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.4/src/engine/specification.md) for a valuable payload.
+
+To elaborate a little, in a post-merge beacon chain, a consensus layer client needs to call two functions from the execution layer client in order to prepare a block:
+
+* `engine_forkchoiceUpdatedV1`, which returns the `status` (\`SUCCESS\` or \`SYNCING\`) and a `payloadId`.
+
+* `engine_getPayloadV1` which accepts a `payloadId`.
+
+The ultimate goal of these two calls is to allow for an execution (eth1) block to be included in a consensus (eth2) block.
+
+_More formally**,** `engine_executePayloadV1` verifies the payload according to the execution environment rule set ([EIP-3675](https://eips.ethereum.org/EIPS/eip-3675#specification)) and returns the status of the verification_
+
+`forkchoiceUpdatedV1` first propagates the change in the fork choice to the execution client (for example, the head of the chain and the finalized block must be updated according to the given data) before initiating the preparation of the payload  if it is needed; this allows the consensus client to be able to give the execution client some time to prepare the payload (i.e., find the best set of transactions it can from the mempool) before the `getPayloadV1` call is made.
+
+To borrow an explanation from Danny Ryan, intuitively the call semantics are:
+
+* "update your fork choice" (no payload build requested)
+
+* "update your fork choice and start building something valuable on top of it!" (payload build requested)
+
+The latter only happens when you need to propose a block.
+
+### How do we know that the merge has happened?
+
+The first `engine_executePayloadV1` method call that communicates a valid payload to the execution client initiates the Merge transition.
+
+Then the first `[POS_FORKCHOICE_UPDATED](https://eips.ethereum.org/EIPS/eip-3675#specification)` event (in the form of a `engine_forkchoiceUpdatedV1` method call) that finalises the first communicated payload finishes the transition.
+
+After the Merge transition is finalised, the Merge can be considered as having happened.
+
+This tutorial is adapted from [Dustin Brody's original](https://github.com/status-im/nimbus-eth2/blob/unstable/docs/neth-m2-nimbus.md) (Dustin has been leading the charge on the Merge interop front at Nimbus). If you get stuck anywhere, or have any questions at all please don't hesitate to get in touch with us on our [discord](https://discord.gg/9SSF5tAd). You can keep track of our Kintsugi progress [here](https://github.com/status-im/nimbus-eth2/pull/3093), and Nethermind's progress [here](https://github.com/NethermindEth/nethermind/pull/3597).

posts/light-nodes-ethereum-endgame.md

@@ -0,0 +1,82 @@
+---
+layout: post
+title: The importance of light nodes in Vitalik's endgame
+description: Ethereum can support both full nodes and light clients, it contains a peer to peer layer which allows nodes to send messages to each other.
+date: 2021-12-10T10:00
+authors: sacha
+published: true
+---
+
+# Nimbus client 2022 year-end recap
+
+<!-- truncate -->
+
+![header-image](/posts/light-nodes-ethereum-endgame/header.png)
+
+
+_image courtesy of [Vitalik's endgame post](https://vitalik.ca/general/2021/12/06/endgame.html)_
+
+### Preface
+
+Ethereum can support both full nodes and light clients, it contains a peer to peer layer which allows nodes to send messages to each other. While Ethereum's current architecture is not particularly well-suited to light clients, the beacon chain architecture is. This means that post-merge, they will have an important role to play. A light client is a cheaper alternative to a full node (from a bandwidth and resource consumption perspective) since it only downloads the header from each block and trusts the full nodes to check that the state transitions are correct (in other words, a light client trusts the full nodes it is peered with to verify that the block producer hasn't tried to print new coins,  spend coins from an address for which they don’t have the private key, or make larger blocks than the consensus rules allow them to do). This does beg the question however: under what assumptions are light clients able to protect themselves from malicious block producers?
+
+### Relaxing assumptions
+
+In [the endgame](https://vitalik.ca/general/2021/12/06/endgame.html), we expect that most individuals will transact on Ethereum using light clients without even knowing it. For example, the plan has always been for the [Status mobile app](https://status.im/get/) to come integrated with a light version of Nimbus.  
+  
+Since light clients typically only download block headers, and don’t verify transactions themselves, we are used to thinking of them as having weak security guarantees compared to full nodes: under the conventional model, they are forced to rely on an honest majority assumption (which means they must assume the chain is valid by default).  
+  
+However, it turns out that we can do significantly better than that.
+
+Thanks to the magic of [fraud and data availability proofs](https://arxiv.org/abs/1809.09044), we can relax the honest majority assumption, and make a 1/N honesty assumption instead. Practically speaking this means a light client only needs to be peered with a _single_ honest full node in order to inherit almost the same security guarantees. In the rest of this post we will refer to this genre of light client as a _light node_.
+
+### A light sketch
+
+While we won't get into the [gory details](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) here, here's a light sketch of how this works.
+
+When a light node receives a block header, it [probabilistically samples](https://coinmarketcap.com/alexandria/article/what-is-data-availability) enough shares from the [Merkle tree](https://blog.iden3.io/merkle-trees-visual-introduction.html) that the Merkle root represents to convince itself that the entire tree is indeed available for full nodes to verify (in other words, the light node is able to verify that the block producer has not withheld any data from the network).
+
+At the same time, it listens for fraud proofs – a small, and quickly verifiable proof that a specific transaction in a block is invalid – from the nodes it is peered with. A valid fraud proof convinces that light node that the Merkle root in the block header is in fact incorrect. In the absence of a valid fraud proof, it goes ahead and accepts the block header as truthful.
+
+### What does this tell us?
+
+The key takeaway here is that **as long as a light node is peered with at least one honest full node, it has practically the same security guarantees as that full node** (since it can expect to receive a fraud proof from it if the block header it receives is incorrect).
+
+A more subtle insight to be gleaned here is the following: **light nodes can only offer the same protection as full nodes if enough people run both light and full nodes.** This is true because you need enough light nodes in the network to collectively recover blocks, and enough honest full nodes to give every light client a good chance of being connected to at least one of them.
+
+It follows that to ensure a resilient network, one in which individuals transacting on Ethereum can detect if/when block producers are trying to [change the rules](https://dankradfeist.de/ethereum/2021/05/20/what-everyone-gets-wrong-about-51percent-attacks.html) on them, we need to do two things:
+
+1. Make it dead simple to run a light node on mobile devices (and other resource-restricted devices).
+    
+2. Make it dead simple to run a full node on low-power commodity hardware (in particular this includes Raspberry Pis and everyday laptops).
+
+These two things become **especially important in a world in which block production is centralised** (the [likely endgame](https://vitalik.ca/general/2021/12/06/endgame.html) we are heading for).
+
+### A means to self-sovereignty
+
+To fork [the words](https://twitter.com/jadler0/status/1433985695396282372?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1433985695396282372%7Ctwgr%5E%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Four.status.im%2Fp%2Fdbab5f30-9e0b-49fb-84c7-ef7adb9d9455%2F) of John Adler: thanks to fraud proofs and data availability sampling, we can think of decentralisation as some function of the cost to run a full node and the cost to run a light node. Not because running either is anything special, but because they are a means to an end: self sovereignty\*.  
+  
+\*Self sovereignty in this context means that we, the community, are able to detect when block producers try to change the rules that we all agree on.
+
+### Resources
+
+* [Beacon Chain Light Client Classification](https://ethresear.ch/t/beacon-chain-light-client-classification/11061)
+
+* [Beacon Chain Light Client Networking](https://ethresear.ch/t/beacon-chain-light-client-networking/11063)
+
+* [Beacon Chain Light Client Design Doc](https://notes.ethereum.org/@ralexstokes/S1RSe1JlF)
+
+* [Bootstrapping the Beacon Chain Light Client Ecosystem](https://notes.ethereum.org/@ralexstokes/S1RSe1JlF)
+
+* [Altair: Minimum Light Client Spec](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/sync-protocol.md)
+
+* [Lodestar Light Client Demo](https://github.com/ChainSafe/eth2-light-client-demo/tree/dapplion/update-to-prater)
+
+* [Nimbus Light Client Syncing Implementation](https://github.com/status-im/nimbus-eth2/issues/2337)
+
+* [Experimental Nimbus Light Client Server](https://github.com/etan-status/nimbus-eth2/compare/merkle-multiproof...etan-status:lightclient-api)  
+    (expand the commit description ... for instructions on how to play with it)
+
+* [Run a Nimbus Beacon Node](https://nimbus.guide/quick-start.html)  
+
+_Thanks to Barnabé Monnot and Ștefan Talpalaru for reading drafts of this._

posts/nimbus-execution-layer.md

@@ -0,0 +1,108 @@
+---
+layout: post
+title: Nimbus - Execution Layer
+description: It is a little known secret that, in addition to our consensus layer (eth2) client we are building out an execution layer (eth1) client - with the objective that it should be ready for the merge.
+date: 2021-11-13T10:00
+authors: sacha
+published: true
+---
+
+# Nimbus: Execution Layer
+
+<!-- truncate -->
+
+![header-image](/posts/nimbus-execution-layer/header.png)
+
+It is a little known secret that, in addition to our consensus layer (eth2) client we are building out an execution layer (eth1) client - with the objective that it should be ready for the merge.
+
+Why is this important? One topical reason is client diversity.
+
+> 1/ A diverse execution-layer client ecosystem is at the heart of all that we’re building together.  
+> 
+> Today, we're excited to announce that [@compoundgrants](https://twitter.com/compoundgrants?ref_src=twsrc%5Etfw), [@krakenfx](https://twitter.com/krakenfx?ref_src=twsrc%5Etfw), [@LidoFinance](https://twitter.com/LidoFinance?ref_src=twsrc%5Etfw), [@synthetix\_io](https://twitter.com/synthetix_io?ref_src=twsrc%5Etfw), [@graphprotocol](https://twitter.com/graphprotocol?ref_src=twsrc%5Etfw) & [@Uniswap](https://twitter.com/Uniswap?ref_src=twsrc%5Etfw) are donating $250K each to support [#Ethereum](https://twitter.com/hashtag/Ethereum?src=hash&ref_src=twsrc%5Etfw) client teams.
+> 
+> — Ethereum (@ethereum) [August 24, 2021](https://twitter.com/ethereum/status/1430124634104545288?ref_src=twsrc%5Etfw)
+
+To put it simply, the more functional and performant clients we have on both layers (consensus + execution), the better and more resilient Ethereum stands to be.
+
+> \* we already have the most client diversity out of any chain  
+> 
+> \* but we can do better. the beacon chain was built to incentivise this, and so stakers are pushed to run minority clients  
+> 
+> \* by having ensuring that no one client is dominant, we harden ourselves against bugs
+> 
+> — carlbeek.eth (@CarlBeek) [October 15, 2021](https://twitter.com/CarlBeek/status/1449126854498078722?ref_src=twsrc%5Etfw)
+
+While **client diversity is crucial to a resilient Ethereum**, it alone would not warrant such a huge engineering effort on our part.
+
+Our high level vision, and the main reason we're rolling our own execution layer client, is for **easy and seamless integration with Status** - both desktop and mobile.
+
+> I can't wait to run Nimbus straight from Status Desktop [#hyped](https://twitter.com/hashtag/hyped?src=hash&ref_src=twsrc%5Etfw)
+> 
+> — Jarrad Hope | @ethstatus (@0xc1c4da) [August 12, 2020](https://twitter.com/0xc1c4da/status/1293473249347555334?ref_src=twsrc%5Etfw)
+
+Such an integration requires a custom, embeddable, and ultra-efficient Ethereum client - across both execution and consensus layer environments.
+
+### Relationship with Fluffy
+
+To achieve the above requires us to optimize resource consumption in novel ways. At the execution layer, we aim to offer **a unique combination of lower space usage and faster sync.**
+
+Our method of syncing, which we call beam-ish sync, will allow nodes to participate in the network early, while data sync continues in the background - this behaviour is similar to [Fluffy](https://our.status.im/nimbus-fluffly/) (our [Portal Network](https://www.ethportal.net/) light client) and our work there will be re-used here - the idea is that we'll eventually integrate Fluffy into our execution client.
+
+In addition to integating Fluffy, one of our main design goals is to make it as easy as possible for our consensus and execution clients to be bundled into a single piece of software; this will drastically improve the UX of running a post-merge client, making it very similar to running a pre-merge PoW client today.
+
+This ties into our overarching vision: to significantly lower the barrier to running both full nodes and light clients, and in doing so help make Ethereum as accessible and decentralised as possible.
+
+> Decentralization is the cost to run a full node. Not because running a full node is inherently anything special, but because it's a means to an end: self-soverignty. Being able to detect when block producers try to change the rules that we the community all agree on.
+> 
+> — John Adler | ✨⛽ (@jadler0) [September 4, 2021](https://twitter.com/jadler0/status/1433985695396282372?ref_src=twsrc%5Etfw)
+
+### Recent progress
+
+Some highlights from the past 6 months include:
+
+* Significantly expanded the team: meet [Jamie](https://github.com/jlokier) and [Jordan](https://github.com/mjfh)
+  
+* Renewed funding from the EF to accelerate  development
+  
+* Completed Berlin and London fork compatibility (EIP-1559): we now pass nearly all the EF Hive testsuite, and 100% of contract execution tests (47,951 tests)
+  
+* New GraphQL and WebSocket APIs, complementing JSON-RPC
+  
+* EVMC compatibility, supporting third-party optimised EVM plugins. Up to 100x memory saving during contract executions. Asynchronous EVM to execute many contracts in parallel (while they wait for data from the network)
+  
+* Proof-of-authority validation for the Goerli test network. Updated network protocols, to work with the latest eth/65-66 and snap/1 protocols
+  
+* A prototype new mechanism for state sync which combines what have been called Fast sync, Snap sync and Beam sync in a self-tuning way, and allows the user to participate in the network (read accounts, run transactions etc.) while sync is still in progress
+  
+* A working transaction pool
+  
+
+> Spotted in the [@ethnimbus](https://twitter.com/ethnimbus?ref_src=twsrc%5Etfw) discord today.. [pic.twitter.com/1Ffqgd1iDz](https://t.co/1Ffqgd1iDz)
+> 
+> — Jacek Sieka (@jcksie) [October 8, 2021](https://twitter.com/jcksie/status/1446399794243592200?ref_src=twsrc%5Etfw)
+
+Wahay! I can confirm there have been no other issues (consensus, networking) syncing up to the head block of Goerli, and I can finally answer the question: "What happens if you just run `nimbus --goerli` today?"
+
+### Still in progress
+
+While we've made significant progress on many fronts, we still have our work cut out for us in the run up to the merge. As it stands, we are currently working on:
+
+* A significant redesign of the storage database to use less disk space and run faster
+  
+* The ability to post a transaction for one's own account
+  
+* Implementing [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) (aka The Merge)
+  
+
+> In a month, we would like to launch a larger Merge devnet with better client distribution, once development stabilizes more.  
+> 
+> 4/5
+> 
+> — proto.eth 🚂 🦇 🔊 (@protolambda) [October 11, 2021](https://twitter.com/protolambda/status/1447595072543920132?ref_src=twsrc%5Etfw)
+
+### Stay updated
+
+The plan for this month is to participate in the rolling merge devnets  - one per week - before the more persistent testnet planned for the first week of December. We are working as hard as we can to try to have our execution layer client ready in time. Our immediate goal however is to pass the merge interop milestones in local tests.
+
+If you have any questions or would like to stay updated on our progress, please join our [discord](https://discord.gg/7G5GCMRZ) and or sign up to our [newsletter](http://subscribe.nimbus.team/).

posts/nimbus-update-pre-merge-devnets.md

@@ -0,0 +1,118 @@
+---
+layout: post
+title: Nimbus update - Pre-merge interop!
+description: It is a little known secret that, in addition to our consensus layer (eth2) client we are building out an execution layer (eth1) client - with the objective that it should be ready for the merge.
+date: 2021-10-02T10:00
+authors: sacha
+published: true
+---
+
+# Nimbus: Execution Layer
+
+<!-- truncate -->
+
+![header-image](/posts/nimbus-update-pre-merge-devnets/header.png)
+
+In the words of Danny Ryan, Altair is here and the Merge is coming!
+
+> Finalized no. 29[https://t.co/ssVYW3M8d7](https://t.co/ssVYW3M8d7)  
+>
+> Altair is here; the Merge is coming.  
+>
+> tl;dr below
+> 
+> — dannyryan 🚂 (@dannyryan) [September 28, 2021](https://twitter.com/dannyryan/status/1442873900652646405?ref_src=twsrc%5Etfw)
+
+We first simulated the merge back in April/May of this year.
+
+> \> This is the first time all eth2 and eth1 clients communicated with each other in an emulation of the merger which removes Proof of Work miners and fully upgrades the network to Proof of Stake.  
+>
+> eth2 progress deniers in disbelief [https://t.co/VGlWCI5d3v](https://t.co/VGlWCI5d3v)
+> 
+> — banteg (@bantg) [May 1, 2021](https://twitter.com/bantg/status/1388609381869236227?ref_src=twsrc%5Etfw)
+
+  
+Fast forwards 5 months and we're finally ready for a more realistic follow-up.
+
+> the merge is coming fast. THE MERGE Y'ALL. arguably the largest event in blockchain history since the bitcoin genesis block. It's proof that together we can build a decentralized future, and (responsibly) improve and innovate on the core infrastructure via rough social consensus [https://t.co/2h6GMKF2wJ](https://t.co/2h6GMKF2wJ)
+> 
+> — kassandra.eth (@RitualTypist) [September 28, 2021](https://twitter.com/RitualTypist/status/1442888325535125510?ref_src=twsrc%5Etfw)
+
+This time, the interop will [build off Altair](https://hackmd.io/@n0ble/merge-interop-spec), rather than Phase 0.  
+Importantly, we'll be testing the transition mechanism that will take us from a pre to post merge world.
+
+> Productionizing the Merge spec includes:  
+> \- Improving the Consensus API (separating it from the user JSON-RPC)  
+> \- Implementing the logic for the latest fork-transition approach  
+> \- Rebase the work onto Altair/London upgrades
+> 
+> — proto.eth 🚂 🦇 🔊 (@protolambda) [May 12, 2021](https://twitter.com/protolambda/status/1392448056591884288?ref_src=twsrc%5Etfw)
+
+The merge spec has just recently been "productionised"
+
+
+We also have a 5th client on the block  :)  
+
+> LODESTAR JOINED THE 100% CLUB 😎 Max profitability for a full day on Eth2.0 mainnet.  
+>
+> \*I test in prod\* master [@gregthegreek](https://twitter.com/gregthegreek?ref_src=twsrc%5Etfw) plz enjoy your sweet rewards [@ChainSafeth](https://twitter.com/ChainSafeth?ref_src=twsrc%5Etfw) 🚀🚀🚀🚀 [pic.twitter.com/e8RMR8fRdi](https://t.co/e8RMR8fRdi)
+> 
+> — Lion ⟠ dapplion .eth (@dapplion) [September 17, 2021](https://twitter.com/dapplion/status/1438882897260425217?ref_src=twsrc%5Etfw)
+
+### Merge quick sync
+
+In general an Ethereum client consists of two layers - the consensus layer and the execution layer.
+
+The consensus layer is responsible for the consensus, i.e. block validity, and fork choice rule. As it stands, on mainnet, we rely on PoW consensus. The Merge enables PoS consensus driven by the beacon chain.
+
+The execution-layer is responsible for transaction bundling, execution, and state management. During the merge this layer will be represented by modified pre-merge PoW clients (eg. geth, nethermind, besu, openethereum, turbogeth, etc).
+
+The key to a successful merge is getting these two layers to talk to each other: the plan right now is for them to interact via a one-way communication protocol, driven by the consensus layer (although this approach is not yet set in stone).
+
+> Note that if these layers are bundled into a single piece of software, then the UX of running a post-merge client becomes very similar to running a pre-merge PoW client today (which is precisely why we are working so hard on building out [our execution layer client](https://github.com/status-im/nimbus-eth1)).
+
+If you'd like to to dig into the details, [this document](https://hackmd.io/@n0ble/merge-interop-spec) specifies the modifications that must be made to beacon chain and pre-merge clients to turn them into a post-merge consensus node and execution engine, respectively.
+
+### Our progress
+
+We have passed all the [merge spec tests](https://notes.ethereum.org/@9AeMAlpyQYaAAyuj47BzRw/rkwW3ceVY). If you want to get your hands dirty, you can actually [verify this for yourself](https://github.com/status-im/nimbus-eth2/blob/amphora-merge-interop/docs/interop_merge.md#verify-that-nimbus-runs-through-the-same-examples)!
+
+And while we're waiting for a compatible execution client, we have everything you need to [start experimenting](https://github.com/status-im/nimbus-eth2/blob/amphora-merge-interop/docs/interop_merge.md) on the consensus side.
+
+> Eager to get started with [#themerge](https://twitter.com/hashtag/themerge?src=hash&ref_src=twsrc%5Etfw) experiments? Our interop branch has got everything you need for the consensus side: [https://t.co/rRwO27kmaK](https://t.co/rRwO27kmaK)
+> 
+> — Nimbus (@ethnimbus) [October 1, 2021](https://twitter.com/ethnimbus/status/1443943484893839370?ref_src=twsrc%5Etfw)
+
+You can keep track of our broader progress [here](https://github.com/status-im/nimbus-eth2/issues/2859).
+
+### Interop lock in: round 2
+
+In the [words of Ben Edgington](https://t.co/97X85jdCzM?amp=1), the cat is out of the bag - the eth1 and eth2 client teams will be meeting up in early October to get some Merge devnets running.
+
+You can think of this as round 2 of the interop event we did two years ago.
+
+Expect to hear a lot of updates from the client teams as we build out the Merge logic and test our software together on short-lived devnets.
+
+In anticipation, we'll leave you with some highlights from the previous lockin.
+
+> [#Lighthouse](https://twitter.com/hashtag/Lighthouse?src=hash&ref_src=twsrc%5Etfw) and [@ethnimbus](https://twitter.com/ethnimbus?ref_src=twsrc%5Etfw) just finalized a [#Eth2](https://twitter.com/hashtag/Eth2?src=hash&ref_src=twsrc%5Etfw) epoch!  
+>
+> As far as I know, this is the first instance of finality on a multi-client Eth2 testnet!  
+>
+> Thanks [@protolambda](https://twitter.com/protolambda?ref_src=twsrc%5Etfw), [@dannyryan](https://twitter.com/dannyryan?ref_src=twsrc%5Etfw) for the help. Great work on the networking stack [@AgeManning](https://twitter.com/AgeManning?ref_src=twsrc%5Etfw) and [@jcksie](https://twitter.com/jcksie?ref_src=twsrc%5Etfw)![#Eth2](https://twitter.com/hashtag/Eth2?src=hash&ref_src=twsrc%5Etfw) is coming! [pic.twitter.com/vC5m9OuaT8](https://t.co/vC5m9OuaT8)
+>
+> — Paul Hauner (@paulhauner) [September 9, 2019](https://twitter.com/paulhauner/status/1170952290469122048?ref_src=twsrc%5Etfw)
+
+> Artemis just achieved [#interop](https://twitter.com/hashtag/interop?src=hash&ref_src=twsrc%5Etfw) with [@ethnimbus](https://twitter.com/ethnimbus?ref_src=twsrc%5Etfw) [pic.twitter.com/JWkIg3XinW](https://t.co/JWkIg3XinW)
+> 
+> — Joseph Delong 🔱 (@josephdelong) [September 10, 2019](https://twitter.com/josephdelong/status/1171465845513408514?ref_src=twsrc%5Etfw)
+
+> Validator monitoring coming to an [@ethnimbus](https://twitter.com/ethnimbus?ref_src=twsrc%5Etfw) near you \*soon(TM)\*: [https://t.co/x65lpxJ3t4](https://t.co/x65lpxJ3t4) - based on the excellent and pioneering work done by [@paulhauner](https://twitter.com/paulhauner?ref_src=twsrc%5Etfw) / [@sigp\_io](https://twitter.com/sigp_io?ref_src=twsrc%5Etfw) - by and large compatible metrics make dashboard/monitoring interop easier too!
+> 
+> — Jacek Sieka (@jcksie) [September 30, 2021](https://twitter.com/jcksie/status/1443568596865589248?ref_src=twsrc%5Etfw)
+
+> Fully autonomous [#eth2](https://twitter.com/hashtag/eth2?src=hash&ref_src=twsrc%5Etfw) beacon chain between [@ethnimbus](https://twitter.com/ethnimbus?ref_src=twsrc%5Etfw) and [#lighthouse](https://twitter.com/hashtag/lighthouse?src=hash&ref_src=twsrc%5Etfw) on a pair of raspberries found in the Canadian wilderness! [pic.twitter.com/Xkps1Yu3DS](https://t.co/Xkps1Yu3DS)
+> 
+> — Jacek Sieka (@jcksie) [September 11, 2019](https://twitter.com/jcksie/status/1171886857908609024?ref_src=twsrc%5Etfw)
+
+_P.S. Keep your eyes peeled for an [Ethereum Foundation blogpost](https://blog.ethereum.org) on Monday. This will include all mainnet Altair releases. We will also be making a more formal Altair announcement next week._