On Collateralization of L1 Proposers for Giving Preconfirmations notes taken during ZuBerlin sequencing & proposer commitment days + feedback from @mteam Background Current working assumption: L1 proposers need collateralization to ensure compliance with preconfirmation promises. Concern: 1000 ETH as collateral is considered too high for a healthy proposer adoption. Data Insights ~99% of mainnet blocks since Jan '24 are worth <1 ETH; no blocks >1000 ETH. Original 1000 ETH proposal based on these findings

This document is supposed to be a brief annotation of the official setup documentation for becoming a Puffer node operator on Holesky testnet (1ETH bond requirement) ...but may very well be adapted for testing/running a full, native validator (32ETH) on the beacon chain from inside a SGX-enclave. We'll be zooming in on connecting the hardware enclave with the consensus client, specifically the validator client (VC). Depending on the consensus client of choice, the VC may be a separate binary. It manages validators using data obtained from the consensus/beacon client via a HTTP API. Consequently, VCs are very lightweight pieces of software, well-suited to be run on low-powered devices.

:::success Of scope are SGX-capable Intel CPUs in order to allow for the lowest possible Puffer bond requirements (1 ETH). Unfortunately, SGX has been deprecated for Intel consumer products since 2022. Instead, Intel’s server products have to be considered as well. [1] ::: 🧛🏼‍♂️ (Option #1) Cloud Server - aka 'The Toothless Vampire' :bulb:Idea: Running a full node & secure-signer in the cloud Often times the performance bottleneck for running an Ethereum full node on a VPS is a slow SSD. A dedicated server with a NVMe SSD, such as OVH Advanced-1, is usually recommended. Although cloud-hosted servers generally provide Intel's SGX-capable CPUs, it should be doublechecked if the SGX features are enabled for a given subscription plan.