# Ethereum Deb Repository Open, secure, easy and standardized way how to run Ethereum software on Debian based distributions. ## Motivation Ethereum ecosystem contains a lot of useful software which enables user to fully embrace Ethereum network in trustless manner. Foundation of this lays on client implementations which should be easy to run by anybody. On top of Eth1 clients, users might want to run more software from the ecosystem like Eth2 beacon and validator nodes, L2 software, monitoring tools, etc. Manual installation and configuration of this kind of Ethereum tool stack is not an easy task, especially with focus on security and stability. It is not impossible, but comes with trade offs like: * Time, education and confidence to do it * Potential security and stability issues caused by misconfiguration * Security risks stemming from failure to verify the software properly * It gets repetitive if one has to do it for multiple times There are solutions on operating system level. It comes with package manager, service configuration management which can be used to handle Ethereum software stack. Most of the software in OS runs in background as service, operates various tasks and user even doesn't have to be aware of that. Ethereum software could behave the same way too. All important software in one place like this can help with incentivization to run own node and support client variety on the network. This kind of repository can be utilized by users, developers, businesses or service providers since it can provide easy to use, secure and stable infrastructure. ## Design, Requirements Idea of this repository is developed in accordance with Unix philosophy. Each piece of software is playing own role and can be easily altered. With this design, repository achieves composability and compartmentalization. ### Composability Core of this approach is composability of `deb` packages. Services separated into own packages allow: * Easier management * Both on developer and user side * Better security * Smaller attack surface, avoiding redundant software * Fast response to vulnerabilities * Altering packages * Ability to swap different implementations of same function Packages also enable utilizing dependencies and recommendations. Higher level packages require lower packages as dependency, e.g. eth2 client depends on eth1 client which includes all its dependencies, etc. Recommendations can be used for creating a default setup. All packages should install software as compliant with Linux File System Hierarchy Standard. ### Packages Parts of Ethereum software are contained in various types of packages. User flow can start with just installing service package which then depends/recommends packages containing binary, configuration, system service, OS native dependencies, etc. Installing one base package therefore does not represent only software itself but its functionality within the system and stack. Each is like a piece of puzzle in the whole tool stack. Building complex deb packages like this manually would be overwhelming and potentially introduce vulnerabilities. Most of automation can be solve with tools like [debcrafter](https://github.com/Kixunil/debcrafter/). Types of packages include: * Binary packages * Contains executable which can be run * Recommends default service packages * Service packages * Handles system service and configuration * Depends on binary and configuration packages * Comes with own user with minimal privileges * Configuration packages * Handles configuration of software * Installing one package can trigger change of config in different software Example of basic client packages: ![](https://storage.googleapis.com/ethereum-hackmd/upload_ed55dc7a868296a6865e378c6dac2712.png) ### Security Repository can utilize systemd security features and system users and groups to achieve security by isolation. Automatic configuration will prevent potentially vulnerable misconfiguration. This is achieved under assumptions: * Each service has unique user * Users have minimal privileges limited to software running under them * One compromised service therefore cannot access others data * Using `no_new_privs` can prevent even attack with vulnerabilities in sudo * Systemd security * Security hardening on service level enables additional tweaks * Flags for managing privileges, protecting directories, parts of the system * Example https://github.com/GrapheneOS/AttestationServer/blob/master/attestation.service * Secure RPC exposing * Automation of secure endpoint exposure with possible configuration * Filtering, balancing, proxy protection * Dshacle and Nginx/HAProxy setup with * Tor for exposing on onion service * Nginx and certbot for clearnet exposure with https Security and system compartmentalization achieved by this setup would set a high security standard for automatically deployed stacks. ### Included software MVP should contain at least basic node setup with Eth1 and Eth2 client. Complete list of software in the stack could look like this: * Execution clients * Go-ethereum * OpenEthereum * Nethermind * Besu * Erigon * Consensus clients * Lighthouse * Prysm * Teku * Nimbus * Lodestar * Monitoring * Prometheus * InfluxDB * Grafana * Exposing API * Nginx * Tor * Dshackle * HAProxy * Certbot * Ecosystem software, Developer tools, Layer 2, Sidechains, etc * Optimism, Arbitrum ZKsync, Loopring, Raiden nodes, tooling * Other ecosystem tools, e.g. IPFS, Tornado relayer * Point of sale system, e.g. xpayserver * Block explorer, e.g. Alethio Lite Explorer, Otterscan * etc Source to this repository should be openly published and open for contributions so various ecosystem players can contribute their software. Repository should be compatible and officially supported on major Debian based systems, currently Debian Buster, Ubuntu 20.04. ## User story Resulting UX will allow user to install Ethereum software without worrying about dependencies, manual configuration or verification. Few examples: * `apt install geth-mainnet-full` will install all dependent software, go-ethereum client, setup default full node mainnet config and start it as a service so user is ready to use it * `apt install lighthouse` will install all dependencies - libraries and eth1 client, setup default configuration and user is ready to use it * `apt install openethereum prysm grafana` will install and setup OE eth1 client, Prysm eth2 client, Grafana monitoring with all dependencies, configuration they require, post install script uploads dashboard to Grafana and user can just use all these tools preconfigured * `systemctl stop besu` will safely stop Besu client * `dpkg-reconfigure geth` allows changing optional configuration of package ## Current alternatives Some of the proposed software offers own Debian repositories. However these do not provide composability with other applications and there is no single repo which would contain all important applications. Dappnode and similar based on Docker are limited to its usage and security. Deb repo provides deeper integration into OS and its management tools, standard approaches and security.
Last changed by  
 
[email protected]
426

Read more

Pectra Testnets Incidents Reports

Besu Any notable highlights from your team on Holešky incident? Please share if you kept any notes or postmortem https://hackmd.io/@siladu/H1qydmWhyx What client issues have you encountered during the period of long non-finality? We were running 5 CLs (except Grandine) along with Besu. All had issues at some point. We kept our besu-lighthouse node producing blocks when Holesky was suffering from its worst liveness issues. During recovery, our 5 nodes became VC-only nodes and we pointed them to various recovery beacon nodes which were hotfixed and synced separately. Sometimes we used other teams' beacons as well. Keeping the beacon nodes alive has been a struggle but things have been more stable in the couple of days. A lesson here is that it's handy to have the VC separated out (teku was combined). Another lesson is that maintaining 5 different configurations is time consuming when issues occur. For Holesky (and for Hoodi) we are going to move towards a beacon node setup of two larger nodes: one teku and lighthouse, which seem to have been the most stable clients for us. We also found and fixed an issue related to Besu snap sync in periods of non finality: https://github.com/hyperledger/besu/issues/8393 Any issues you have encountered after finalization on Holešky? We were running majority hotfixed lighthouse beacons at the time which suffered from an issue upon finality, but it was easy to resync, and that is now also fixed. Participation has been on the low side since finality which has made things more unstable than before the incident. We recently discovered an issue in our infra that was making things more unstable: our VMs were using ntp for time synchronization. Switching to chrony seems to be a notable improvement. Network conditions on Holesky brought this inaccuracy to light, we didn't notice significant issues before.

3/20/2025
Ephemery incentivisation program

Ephemery testnet has been running since December 2022 and providing Ethereum developers, users and validators with the easiest environment for testing. The Ephemery infrastructure has been steadily improving and growing over time. There are more genesis validators, block explorers, faucets, client implementations, auto deployers, deposit tooling and more. To learn more about Ephemery and its usage, checkout the repository with all resources To improve the Ephemery ecosystem even further, we are announcing the incentive program for providing infrastracture for the testnet. The goal of Ephemery is to become a sustainable testing enviroment which doesn't have to be deprecated in the future. Thanks to a generous donation and support from EthStaker, we can decentralize our network services, making Ephemery more resilient and usable. EthStaker is dedicating 12000 USD a year to support our testnet efforts. We are incredibly thankful for their dedication to Ephemery and the Ethereum testnet ecosystem. All donations to Ephemery will be vested and divided between infrastracture providers and contributors.

12/2/2024
Ethereum on PS4

I am currently syncing an Eth node on an old PlayStation 4 machine and since it was quite a journey, I am here to share details in the hope someone might replicate this effort one day. Everything started with a casual discussion about gaming with my peers. I am not much of a gamer, and recently I've only been playing some indie games from itch on my GNU/Linux laptop. There are some interesting big-name titles I'd like to try, but I lack the hardware to run them, and generally, I just don't like that games require a proprietary/DRM environment. Consoles seem like the cheapest option optimized for games but growing up I never owned one and I still cannot imagine owning hardware locked by the manufacturer for a single purpose. On the other hand, I know people have been hacking them for years, legends like geohot! Researching this, I fell down the PlayStation jailbreaking rabbit hole, and boy, it's quite huge. I believe PS4 is generally a great piece of hardware which still continues to please gamers, developers and hackers after many years. Hacking PS4 Older PS4 firmwares include vulnerabilities allowing us to take over the control. This enables you to tweak many things, pirate games and even run your own kernel on the machine! Clearly, this is the best and most fun thing to do with your PS(if you are into voiding warranties and bending rules :)). The only thing you need is a PS4 with old enough software and if you own one, the best advice is to NEVER UPDATE YOUR PLAYSTATION. An older or exploited firmware will block you from playing games online, using the PS Store, etc but I am not interested in that anyway, I want to run my Ethereum node. So here is what it takes:

9/14/2024
EPF - Guide for mentors

First of all, thank you so much for taking the time to be a mentor for the third EPF cohort. We sincerely appreciate your effort, and we'll do our best to put it to good use. Being mentor does not require a lot of commitment, it should be a smooth experience of helping to onboard new contributors. Here are some details about the program and your mentorship role to get you started. Program details Cohort 5 starts in mid June and run for 5 months. At the end, at Devconnect in November, you will also have a chance to attend a physical meetup with most active fellows. The program is opened and permissionless which means anybody can participate. From hundreds of application we receive, we are selecting around 20+ people who will also receive a stipend. All together, we expect around 30 individuals to contribute within the cohort. Participants are completely free to decide what project they want to work on. To nudge them into certain direction, feel free to submit project suggestions for fellows. If there is anything you/your team/your project need help with and you would like to see participants work on, please share it in the mentors form.

6/12/2024
Read more from [email protected]
Published on HackMD