Swtch to mdx

website/docs/About/Changelog.md → website/docs/About/Changelog.mdx

@@ -526,7 +526,7 @@ The headline feature is support for the Ethrex and Anchor clients.
 - Require Lodestar `1.34.1` or later
 - Require Reth `1.8.0` or later
 - `nodeexporter` uses `host` networking, which uses a configurable port and requires changes to `ufw` **if**
-ufw has been placed "in front of" Docker, see [Cloud Security](../Support/Cloud.md).
+ufw has been placed "in front of" Docker, see [Cloud Security](../Support/Cloud.mdx).
 
 Changes
 - Support Ethrex execution client
@@ -2190,7 +2190,7 @@ from scratch of the DB.
 *This is an optional upgrade, that contains new features*
 
 * `sudo ./ethd prune-geth` simplifies pruning Geth
-* Separating consensus client and validator client is now supported for Teku, Lighthouse and Prysm. Please see the [Secure Web Proxy](../Usage/ReverseProxy.md) instructions.
+* Separating consensus client and validator client is now supported for Teku, Lighthouse and Prysm. Please see the [Secure Web Proxy](../Usage/ReverseProxy.mdx) instructions.
 ## v1.2.5.2 2021-06-07
 
 *This is a bugfix upgrade*
@@ -2307,7 +2307,7 @@ instructions.
   a breaking change for existing Grafana, Prysm Web and shared/standalone eth1 clients. You will need to
   add `grafana-insecure.yml`, `prysm-web-insecure.yml`, `eth1-insecure.yml`, depending on service you use,
   to your `COMPOSE_FILE` inside `.env`. Alternatively and recommended, add `traefik-cf.yml` or `traefik-aws.yml`
-  and start using secure https:// ! Please see [reverse proxy instructions](../Usage/ReverseProxy.md).
+  and start using secure https:// ! Please see [reverse proxy instructions](../Usage/ReverseProxy.mdx).
 * Added wizard.sh shell script for quick initial setup
 * Added node reporter Grafana dashboard to alert on low CPU, Memory or Disk Space
 

website/docs/About/Clients.md → website/docs/About/Clients.mdx

@@ -33,4 +33,4 @@ Currently supported additional options:
 - Grafana dashboard
 - slasher - running slasher is optional and requires additional resources
 
-Please see [Prysm Web](../Usage/WebUI.md) for Web UI support on Prysm.
+Please see [Prysm Web](../Usage/WebUI.mdx) for Web UI support on Prysm.

website/docs/About/Overview.md → website/docs/About/Overview.mdx

@@ -14,17 +14,17 @@ with full control for advanced users.
 Recommended hardware, whether your own hardware or a VPS, is:
 - 32 to 64 GiB of RAM - 16 GiB works but can be challenging depending on client mix
 - 4 to 8 CPU cores
-- 4TB ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) - TLC and DRAM.
+- 2TB to 4TB ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) - TLC and DRAM.
 
 ## Getting started
 
 After installing Linux, either Debian or [Ubuntu](https://docs.ethstaker.org/tutorials/installing-linux),
-please take a look at the [Quick Start](../Usage/QuickStart.md) instructions.
+please take a look at the [Quick Start](../Usage/QuickStart.mdx) instructions.
 
 If you wish to use a separate drive for Ethereum data, please check how to
-[tell Docker to use a second drive](../Usage/Prerequisites.md#change-docker-storage-location).
+[tell Docker to use a second drive](../Usage/Prerequisites.mdx#change-docker-storage-location).
 
-macOS and Windows users should start at the [Prerequisites](../Usage/Prerequisites.md#macos-prerequisites).
+macOS and Windows users should start at the [Prerequisites](../Usage/Prerequisites.mdx#macos-prerequisites).
 
 ## Node components
 

website/docs/Support/Cloud.md → website/docs/Support/Cloud.mdx

@@ -8,7 +8,7 @@ For the most part, nothing special needs to be done to run Eth Docker on a VPS.
 filter the traffic that can reach the machine: This is definitely not desirable for unsecured ports like Grafana
 or execution client, if the shared option is being used. All that should be reachable are the P2P ports.
 
-The arguably best way to secure Grafana and execution client ports is via encryption. For this, please see the [secure proxy](../Usage/ReverseProxy.md)
+The arguably best way to secure Grafana and execution client ports is via encryption. For this, please see the [secure proxy](../Usage/ReverseProxy.mdx)
 instructions.
 
 If you prefer to keep the ports unencrypted and wish to secure them via ufw, please read on.
@@ -142,7 +142,7 @@ to the actual defaults by adding more specific rules. For the Docker default sub
 `after.rules`.
 
 > With ISP traffic caps, it could be quite attractive to run the execution client in a small VPS, and reference it from a consensus client somewhere
-> else. This requires a [secure proxy](../Usage/ReverseProxy.md).
+> else. This requires a [secure proxy](../Usage/ReverseProxy.mdx).
 
 ## Allowing IPv6 traffic
 

website/docs/Support/SwitchClient.md → website/docs/Support/SwitchClient.mdx

@@ -193,7 +193,7 @@ Observe consensus client logs with `./ethd logs -f consensus`, see that it check
 
 **Exercise extreme caution. Running your validators in two locations at once would lead to slashing**
 
-Follow the [moving a validator](../Support/Moving.md) instructions. You'll be inside the old directory, e.g. `~/eth-docker`, for the first part where you delete the keys and make sure they are gone, and inside the new directory, e.g. `~/eth-staker`, for the second part where you import the keys again.
+Follow the [moving a validator](../Support/Moving.mdx) instructions. You'll be inside the old directory, e.g. `~/eth-docker`, for the first part where you delete the keys and make sure they are gone, and inside the new directory, e.g. `~/eth-staker`, for the second part where you import the keys again.
 
 ### 4. Shut down the old client and remove its storage
 
@@ -283,7 +283,7 @@ Verify that the validator can't find them: `sudo systemctl start prysmvalidator`
 
 `sudo systemctl stop prysmvalidator` and `sudo systemctl disable prysmvalidator` to shut it down for good.
 
-Follow the [moving a validator](../Support/Moving.md#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
+Follow the [moving a validator](../Support/Moving.mdx#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
 
 #### Metanull's guide
 
@@ -293,7 +293,7 @@ Verify that the validator can't find them: `sudo systemctl start validator` and
 
 `sudo systemctl stop validator` and `sudo systemctl disable validator` to shut it down for good.
 
-Follow the [moving a validator](../Support/Moving.md#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
+Follow the [moving a validator](../Support/Moving.mdx#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
 
 #### Coincashew's guide
 
@@ -303,7 +303,7 @@ Verify that the validator can't find them: `sudo systemctl start validator` and
 
 `sudo systemctl stop validator` and `sudo systemctl disable validator` to shut it down for good.
 
-Follow the [moving a validator](../Support/Moving.md#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
+Follow the [moving a validator](../Support/Moving.mdx#import-keys-into-new-client) instructions. You already removed the keys: Wait 15 minutes after that to protect against slashing, then import them again from inside the `~/eth-docker` directory.
 
 ### 3. Remove old beacon database
 

website/docs/Support/Update.md → website/docs/Support/Update.mdx

@@ -31,7 +31,7 @@ Inside the project directory, run:
 Then `cp .env .env.bak` and `cp default.env .env`, and set variables inside `.env`
 the way you need them, with `.env.bak` as a guide.
 
-Updating the tool itself is not always necessary. Please refer to the [Changelog](../About/Changelog.md) to see
+Updating the tool itself is not always necessary. Please refer to the [Changelog](../About/Changelog.mdx) to see
 whether changes have been made that you may want to use.
 
 ## Optional: Manually update the client "stack"

website/docs/Support/Windows.md → website/docs/Support/Windows.mdx

@@ -84,7 +84,7 @@ task to keep WSL in sync with your Windows clock. From non-admin Powershell, run
 `schtasks /Create /TN WSLTimeSync /TR "wsl -u root hwclock -s" /SC ONEVENT /EC System /MO "*[System[Provider[@Name='Microsoft-Windows-Kernel-Power'] and (EventID=107 or EventID=507) or Provider[@Name='Microsoft-Windows-Kernel-General'] and (EventID=1)]]" /F`.
 
 Docker
-- Use the [QuickStart](../Usage/QuickStart.md) instructions to install Eth Docker and get Docker-CE installed in Ubuntu. Log out and back in so your user can run Docker commands.
+- Use the [QuickStart](../Usage/QuickStart.mdx) instructions to install Eth Docker and get Docker-CE installed in Ubuntu. Log out and back in so your user can run Docker commands.
 
 Start on boot
 - Your node needs to run after Windows reboot for 24/7 uptime. WSL only starts well with a logged-in user.

website/docs/Support/ipv6.md → website/docs/Support/ipv6.mdx

@@ -46,10 +46,10 @@ addresses.
 ## Security
 
 `ufw` integration works; ports mapped to host can be blocked by a v6 deny rule. As with v4, ufw needs to be
-["in front of Docker"](../Support/Cloud.md) for this to work.
+["in front of Docker"](../Support/Cloud.mdx) for this to work.
 
 Note that host-mapped ports may not be reachable by default if ufw has been enabled. If you use ufw, please
-place it ["in front of Docker"](../Support/Cloud.md) and configure explicit allow rules for your P2P ports.
+place it ["in front of Docker"](../Support/Cloud.mdx) and configure explicit allow rules for your P2P ports.
 
 On your LAN firewall, if this is in a LAN, you'd need rules to allow the P2P ports incoming to the v6 address of your
 node.

website/docs/Usage/Advanced/ClientSetup.md → website/docs/Usage/Advanced/ClientSetup.mdx

@@ -118,9 +118,9 @@ Optionally, add encryption to the Grafana and/or Prysm Web pages:
 - `traefik-aws.yml` - use encrypting secure web proxy and use AWS Route53 for DNS management
 - `el-traefik.yml,` `cl-traefik.yml`, `ee-traefik.yml` - advanced use, use traefik for access to execution RPC,
 consensus REST and execution engine RPC API ports respectively. Be very cautious with these, always
-[firewall](../../Support/Cloud.md) that access to trusted source IPs.
+[firewall](../../Support/Cloud.mdx) that access to trusted source IPs.
 
-With these, you wouldn't use the `-shared.yml` files. Please see [Secure Web Proxy Instructions](../../Usage/ReverseProxy.md)
+With these, you wouldn't use the `-shared.yml` files. Please see [Secure Web Proxy Instructions](../../Usage/ReverseProxy.mdx)
 for setup instructions for either option.
 
 For example, Teku with Besu:

website/docs/Usage/Advanced/SSV.md → website/docs/Usage/Advanced/SSV.mdx

@@ -63,7 +63,7 @@ same way, you expect it to work, as well.
 
 Grafana dashboards are included.
 
-Please see the [secure proxy](../../Usage/ReverseProxy.md) docs if you'd like to run Grafana on a secured https port,
+Please see the [secure proxy](../../Usage/ReverseProxy.mdx) docs if you'd like to run Grafana on a secured https port,
 rather than insecure 3000.
 
 ## Debug logs

website/docs/Usage/Advanced/SharedPorts.md → website/docs/Usage/Advanced/SharedPorts.mdx

@@ -20,6 +20,6 @@ from the host. To be used alongside one of the consensus client yml files. **Not
 available from the host. To be used alongside one of the execution client yml files. **Not encrypted**, do not expose
 to Internet.
 
-- `CLIENT-cl-only.yml` - for running a [distributed consensus client and validator client](../../Usage/ReverseProxy.md)
+- `CLIENT-cl-only.yml` - for running a [distributed consensus client and validator client](../../Usage/ReverseProxy.mdx)
 setup.
 - `CLIENT-vc-only.yml` - the other side of the distributed client setup.

website/docs/Usage/Advanced/Vero.md → website/docs/Usage/Advanced/Vero.mdx

@@ -175,7 +175,7 @@ and `./ethd logs -f --tail 50 execution` and `./ethd logs -f --tail 50 mev-boost
 ## Vero on separate machines
 
 Very similar, just do not use aliases or `ext-network.yml`, and use either `cl-shared.yml` or `cl-traefik.yml:traefik-cf.yml`,
-see also [port sharing](./SharedPorts.md) and [reverse proxy](../ReverseProxy.md) instructions. Vero would then have a `CL_NODE` to point to each machine's IP address
+see also [port sharing](./SharedPorts.mdx) and [reverse proxy](../ReverseProxy.mdx) instructions. Vero would then have a `CL_NODE` to point to each machine's IP address
 or if using traefik, to the FQDN of each CL
 
 ## Grafana monitoring

website/docs/Usage/Hardware.md → website/docs/Usage/Hardware.mdx

@@ -7,23 +7,23 @@ sidebar_label: Hardware
 Recommended hardware:
 * 32 to 64 GiB of RAM - 16 GiB works but can be challenging depending on client mix
 * 4 to 8 CPU cores
-* 4TB ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) - TLC and DRAM
+* 2TB to 4TB ["mainstream" SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) - TLC and DRAM
 
 Generally, 8 GiB of RAM is a very tight fit, with only Nimbus/Geth reported to work. 16 GiB can be a tight fit
 depending on client mix, and 32 GiB is recommended. 64 GiB makes it possible to run additional services or
 even 3 different client combinations for safety. For 16 GiB RAM, a Nimbus/Nethermind combo works well.
 
 4+ CPU cores are recommended to deal with spikes in processing.
 
-An SSD is required for storage because the node databases are so IOPS-heavy. An Ethereum mainnet node takes ~ 1.1 TiB
-of storage initially, as of Jan 2024. The on-disk growth pattern differs between execution clients, see
-[resource use](../Usage/ResourceUsage.md).
+An SSD is required for storage because the node databases are so IOPS-heavy. An Ethereum full mainnet node takes ~ 1.8 TiB
+of storage initially. An Ethereum mainnet node with rolling history expiry takes around ~500 GiB of storage. Both as of
+August 2026.  
+The on-disk size differs between execution clients, see [resource use](../Usage/ResourceUsage.mdx).
 
-If you have a 2TB disk, it is expected to last (potentially with execution client pruning) until early 2025.
+If you have a 2TB disk, it is expected to last indefinitely with rolling history expiry and eventually mandatory proofs.
 Remy wrote a [migration guide to 4TB](https://docs.ethstaker.org/guides/monitoring-maintenance/migrating-to-a-larger-disk/).
-Also keep an eye on [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444).
 
-Two home server builds that I like and am happy to recommend are below. Both Intel and AMD support IPMI, which means
+Some home server builds that I like and am happy to recommend are below. Both Intel and AMD support IPMI, which means
 they can be managed and power-cycled remotely and need neither a GPU nor monitor. Both support ECC RAM, though the AMD
 option as of Sept 2020 was unable to report ECC errors via IPMI, only OS-level reporting worked.
 
@@ -32,21 +32,27 @@ option as of Sept 2020 was unable to report ECC errors via IPMI, only OS-level r
 * mITX: 
   * SuperMicro X11SCL-IF(-O) (1 NVMe)
     * Intel i3-9100F or Intel Xeon E-21xx/22xx (i5/7 do not support ECC) - ~ 840 USD with Fractal Node case and NVMe
+    * 32 GiB of DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
   * SuperMicro X12STL-IF(-O) (1 NVMe)
     * Intel Xeon E-23xx 
+    * 32 GiB of DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
   * SuperMicro X13SCL-IF(-O) (1 NVMe)
     * Intel Xeon E-24xx
+    * 32 GiB of DDR5 UDIMM ECC RAM (unbuffered, **not** registered)
 * uATX:
   * SuperMicro X11SCL-F(-O) (1 NVMe) or X11SCH-F(-O) (2 NVMe). SCH supports an iGPU
     * Intel i3-9100(F) or Intel Xeon E-21xx/22xx(G) (i5/7 do not support ECC) - ~ 900 USD with Fractal Node case and
+    * 32 GiB of DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
 NVMe
   * SuperMicro X12STL-F(-O) or X12STH-F(-O) (1 NVMe both). STH supports an iGPU
     * Intel Xeon E-23xx(G)
+    * 32 GiB of DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
   * SuperMicro X13SCL-F(-O) (1 NVMe) or X13SCH-F(-O) (2 NVMe)
     * Intel Xeon E-24xx
+    * 32 GiB of DDR5 UDIMM ECC RAM (unbuffered, **not** registered)
+  * SuperMicro X13SCL-F(-O) (1 NVMe) or X13SCH-F(-O) (2 NVMe)
 * Common components:
-  * 32 GiB of Micron or Samsung DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
-  * [4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
+  * [2TB or 4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
 
 **AMD**
 
@@ -56,16 +62,14 @@ NVMe
   * AsRock Rack X470D4U or X570D4U (2 NVMe both)
 * Common components:
   * AMD Ryzen CPU (Zen2/3), but not APU (APUs do not support ECC)
-  * 32 GiB of Micron or Samsung DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
-  * [4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
+  * 32 GiB of DDR4 UDIMM ECC RAM (unbuffered, **not** registered)
+  * [2TB or 4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
 
 * uATX Zen 4:
   * AsRock Rack B650D4U
   * AMD Ryzen 7000 CPU (Zen4), but not APU (APUs do not support ECC)
   * 32 GiB of DDR5 UDIMM ECC RAM (unbuffered, **not** registered)
-  * [4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
-
-The SuperMicro eStore is one good source of UDIMM ECC, DDR4 and DDR5 both.
+  * [2TB or 4TB M.2 NVMe SSD](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038)
 
 Plus, obviously, a case, PSU, case fans. Pick your own. Well-liked options are Node 304 (mITX) and Node 804 (uATX)
 with Seasonic PSUs, but really any quality case that won't cook your components will do. For a small uATX form factor,