-
Notifications
You must be signed in to change notification settings - Fork 179
Create rubykai #31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
blacktatty-multi
wants to merge
1
commit into
cloudflare:dependabot/npm_and_yarn/wrangler-2.20.1
Choose a base branch
from
blacktatty-multi:patch-1
base: dependabot/npm_and_yarn/wrangler-2.20.1
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Create rubykai #31
blacktatty-multi
wants to merge
1
commit into
cloudflare:dependabot/npm_and_yarn/wrangler-2.20.1
from
blacktatty-multi:patch-1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
eth-diamond
Validator checklist
This checklist will help you understand the role of a validator and prepare you for the role.
Visit EthStaker on Discord or Reddit at any time during your setup for some friendly help!
Section 1
Before you start
Section 2
During setup
Section 3
After depositing
Section 1 - Before you start
Review this section before deciding to proceed with validator setup.
Recommendation disclaimer
Hardware suggestions are an ever-evolving target. Current minimum requirements are likely to increase by an order of magnitude after the introduction of Danksharding. Do your own research before depositing funds.
Hard drive
You need to run an execution client as well as your consensus client.
Since the Merge, third-party providers (such as Infura and Alchemy) are no longer viable options to outsource execution layer responsibilities. All stakers must run both an execution and a consensus client to properly attest to the network.
As of May 2022, you'll need ~1TB for the Mainnet execution chain data alone (growing at >1GB/day).
Ethereum had its genesis on July 30, 2015. It is growing in size over time, and the introduction of Danksharding will also increase storage, memory, and bandwidth requirements.
You'll need SSD storage to consistently handle necessary read/write speeds.
Be sure to account for enough space on your drive until you run maintenance on your node.
CPU and RAM
Check with client documentation to ensure the hardware you want to use is sufficient and supported.
Resource usage can vary significantly between clients. Research the different clients if you're working with resource constraints.
Internet
Ideally your internet connection should be reliable and as close to 24/7 as possible without interruption.
Ensure your bandwidth can't be throttled and isn't capped so your node stays in sync and will be ready to validate when called.
You need enough upload bandwidth too. As of May 2022 this is ~1.2-1.3 GB download and ~0.9-1 GB upload per hour, and is likely to increase.
Notes
Avoid overly-complicated setups and be aware of trade offs. Being offline for brief periods of time will result in small inactivity penalities, but will be recouped easily after being online again for about the same amount of time. Complicated power backups can add to the expense of your setup, and redundant backup validators can lead to a more serious penalty known as slashing.
More on slashing risks
Syncing your execution client may take a few days in the worst-case scenario.
Section 2 - During setup
Use this as a reference during client setup to check off important steps.
Initial setup
Start by setting up your chosen hardware and operating system.
To maximize security and efficiency of your node, use dedicated hardware to run your clients. This reduces risk of malware exposure and minimizes competition for computing resources, ensuring your node handles the network load and its validator responsibilities at all times.
Node security
Execution Client Default Port
Reth 30303 TCP/UDP
Erigon 30303 TCP/UDP
Besu 30303 TCP/UDP
Geth 30303 TCP/UDP
Nethermind 30303 TCP/UDP
Consensus Client Default Port
Nimbus 9000 TCP/UDP
Teku 9000 TCP/UDP
Lighthouse 9000 TCP/UDP
Prysm 13000 TCP, 12000 UDP
Learn about ports in networking
Configure time sync
For Ubuntu 20.04
Run the following command:
timedatectl
Check if
NTP Service
is
active
.
Check if
Local time
,
Time zone
, and
Universal time
are all correct.
If
NTP Service
is not
active
, run:
sudo timedatectl set-ntp on
If you see error message
Failed to set ntp: NTP not supported
, you may need to install
chrony
or
ntp
package.
Note: by default, VMs may disable NTP so you may need to find a work-around for your environment.
Note: the RTC (Real-Time Clock) time may be set to your local timezone instead of UTC, especially in a VM which has its clock configured on Windows.
Testnet practice
We strongly recommended you complete these steps on the current testnet before Mainnet. Holesky
Configure your execution client
Review validator roles and responsibilities
Reth
Reth is a modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust.
Configure Reth
Erigon
Erigon is an execution client on the efficiency frontier, written in Go.
Configure Erigon
Besu
Hyperledger Besu is an open-source Ethereum client developed under the Apache 2.0 license and written in Java.
Configure Besu
Geth
Geth is one of the three original implementations of the Ethereum protocol, written in Go.
Configure Geth
Nethermind
Nethermind is a robust client built on .NET core designed for performance, versatility and customizability.
Configure Nethermind
Remember
All stakers must operate an execution client with their consensus client.
Recommended
Discord: Reth | Erigon | Besu | Geth | Nethermind
Configure your consensus client
Nimbus
Nimbus is a research project and a consensus client implementation for Ethereum designed to perform well on embedded systems and personal mobile devices.
Configure Nimbus
Teku
PegaSys Teku is a Java-based Ethereum consensus client built to meet institutional needs and security requirements.
Configure Teku
Lighthouse
Lighthouse is a consensus client implementation, written in Rust with a heavy focus on speed and security.
Configure Lighthouse
Prysm
Prysm is a Go consensus client implementation of the Ethereum protocol with a focus on usability, security, and reliability.
Configure Prysm
Warning!
It is high risk to run your validator in multiple places. It will lead to a slashable event and ejection from the network. More on slashing risks
Recommended
Discord: Nimbus | Teku | Lighthouse | Prysm
JWT Authentication
Communication between the execution layer and consensus layer occurs using the Engine API. This is a set of JSON RPC methods that can be used to communicate between the two client layers.
This communication is secured using a JWT secret, which is a secret key that is shared only between the two clients to authenticate one another. This shared JWT secret must be made available to each client (both execution and consensus clients) to allow them to communicate with one another properly.
Consensus JWT docs: Lighthouse | Nimbus | Prysm | Teku
Execution JWT docs: Besu | Erigon | Geth | Nethermind | Reth
Set withdrawal address
Stakers must set a withdrawal address to unlock reward payments from the consensus layer. This is set when generating your validator keys.
If you do not provide a withdrawal address prior to depositing, you will have to perform an additional step to update your keys and enable withdrawals. Funds will be locked in the meantime.
More on staking withdrawals
Set fee recipient
Stakers must provide a fee recipient address to their consensus client in order to receive transaction fee rewards. This is a normal Ethereum address that you're used to.
If you do not provide an address to your client, you will not receive transaction fees when your validator proposes blocks.
See your consensus client documentation for client-specific instructions on how to set this.
Fee recipient docs: Lighthouse | Nimbus | Prysm | Teku
Consensus Layer Beacon Node (BN)
Required
Verify it with the following command to check if it returns the client version correctly:
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' http://<YourServerLocation>:8545
Make sure that your node has more than 20 peers.
Consensus Layer Validator Client (VC)
Required
Section 3 - After depositing
Protect your funds using monitoring software, and learn how to handle different real world scenarios.
These steps are optional but are recommended to optimize your node.
Monitoring
Prometheus and Grafana monitor
The clients support Prometheus and Grafana to help you visualize important real-time metrics about your validator.
Monitoring docs: Lighthouse | Nimbus | Prysm | Teku
Testnet simulations
While validating on the testnet, perform these simulations to learn more about your node, and better prepare yourself for Mainnet:
Advanced system architecture
To avoid exposing your validator identity to the network, you can use a trustworthy VPN to help reduce the risk of revealing your IP address.
Moreover, you can set your Validator Client (VC) and Beacon Node (BN) on separate machines and IPs so that even if your beacon node is vulnerable, your keystore is stored on a different machine.
Graffiti
You can use your validator client's graffiti flag to add a personal touch to your proposed blocks (some text of your choice). You will be able to see it using Beaconcha.in or BeaconScan blockchain explorers.
If you have questions, EthStaker community is a good place to get help! You can find support on Discord or Reddit.
Staking Launchpad
Deposit
Checklist
FAQ
Terms of Service
Become a validator 🦏
More on staking
The Ethereum roadmap
Avoid phishing
Staking economics
Formal verification report
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
eth-diamond
Validator checklist
This checklist will help you understand the role of a validator and prepare you for the role. Visit EthStaker on Discord or Reddit at any time during your setup for some friendly help!
Section 1
Before you start
Section 2
During setup
Section 3
After depositing
Section 1 - Before you start
Review this section before deciding to proceed with validator setup. Recommendation disclaimer
Hardware suggestions are an ever-evolving target. Current minimum requirements are likely to increase by an order of magnitude after the introduction of Danksharding. Do your own research before depositing funds. Hard drive
You need to run an execution client as well as your consensus client. Since the Merge, third-party providers (such as Infura and Alchemy) are no longer viable options to outsource execution layer responsibilities. All stakers must run both an execution and a consensus client to properly attest to the network. As of May 2022, you'll need ~1TB for the Mainnet execution chain data alone (growing at >1GB/day). Ethereum had its genesis on July 30, 2015. It is growing in size over time, and the introduction of Danksharding will also increase storage, memory, and bandwidth requirements. You'll need SSD storage to consistently handle necessary read/write speeds. Be sure to account for enough space on your drive until you run maintenance on your node. CPU and RAM
Check with client documentation to ensure the hardware you want to use is sufficient and supported. Resource usage can vary significantly between clients. Research the different clients if you're working with resource constraints. Internet
Ideally your internet connection should be reliable and as close to 24/7 as possible without interruption. Ensure your bandwidth can't be throttled and isn't capped so your node stays in sync and will be ready to validate when called. You need enough upload bandwidth too. As of May 2022 this is ~1.2-1.3 GB download and ~0.9-1 GB upload per hour, and is likely to increase. Notes
Avoid overly-complicated setups and be aware of trade offs. Being offline for brief periods of time will result in small inactivity penalities, but will be recouped easily after being online again for about the same amount of time. Complicated power backups can add to the expense of your setup, and redundant backup validators can lead to a more serious penalty known as slashing. More on slashing risks
Syncing your execution client may take a few days in the worst-case scenario. Section 2 - During setup
Use this as a reference during client setup to check off important steps. Initial setup
Start by setting up your chosen hardware and operating system. To maximize security and efficiency of your node, use dedicated hardware to run your clients. This reduces risk of malware exposure and minimizes competition for computing resources, ensuring your node handles the network load and its validator responsibilities at all times. Node security
Execution Client Default Port
Reth 30303 TCP/UDP
Erigon 30303 TCP/UDP
Besu 30303 TCP/UDP
Geth 30303 TCP/UDP
Nethermind 30303 TCP/UDP
Consensus Client Default Port
Nimbus 9000 TCP/UDP
Teku 9000 TCP/UDP
Lighthouse 9000 TCP/UDP
Prysm 13000 TCP, 12000 UDP
Learn about ports in networking
Configure time sync
For Ubuntu 20.04
Run the following command:
timedatectl
Check if
NTP Service
is
active
.
Check if
Local time
,
Time zone
, and
Universal time
are all correct.
If
NTP Service
is not
active
, run:
sudo timedatectl set-ntp on
If you see error message
Failed to set ntp: NTP not supported
, you may need to install
chrony
or
ntp
package.
Note: by default, VMs may disable NTP so you may need to find a work-around for your environment. Note: the RTC (Real-Time Clock) time may be set to your local timezone instead of UTC, especially in a VM which has its clock configured on Windows. Testnet practice
We strongly recommended you complete these steps on the current testnet before Mainnet. Holesky Configure your execution client
Review validator roles and responsibilities
Reth
Reth is a modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, written in Rust. Configure Reth
Erigon
Erigon is an execution client on the efficiency frontier, written in Go. Configure Erigon
Besu
Hyperledger Besu is an open-source Ethereum client developed under the Apache 2.0 license and written in Java. Configure Besu
Geth
Geth is one of the three original implementations of the Ethereum protocol, written in Go. Configure Geth
Nethermind
Nethermind is a robust client built on .NET core designed for performance, versatility and customizability. Configure Nethermind
Remember
All stakers must operate an execution client with their consensus client. Recommended
Discord: Reth | Erigon | Besu | Geth | Nethermind
Configure your consensus client
Nimbus
Nimbus is a research project and a consensus client implementation for Ethereum designed to perform well on embedded systems and personal mobile devices. Configure Nimbus
Teku
PegaSys Teku is a Java-based Ethereum consensus client built to meet institutional needs and security requirements. Configure Teku
Lighthouse
Lighthouse is a consensus client implementation, written in Rust with a heavy focus on speed and security. Configure Lighthouse
Prysm
Prysm is a Go consensus client implementation of the Ethereum protocol with a focus on usability, security, and reliability. Configure Prysm
Warning!
It is high risk to run your validator in multiple places. It will lead to a slashable event and ejection from the network. More on slashing risks Recommended
Discord: Nimbus | Teku | Lighthouse | Prysm
JWT Authentication
Communication between the execution layer and consensus layer occurs using the Engine API. This is a set of JSON RPC methods that can be used to communicate between the two client layers. This communication is secured using a JWT secret, which is a secret key that is shared only between the two clients to authenticate one another. This shared JWT secret must be made available to each client (both execution and consensus clients) to allow them to communicate with one another properly. Consensus JWT docs: Lighthouse | Nimbus | Prysm | Teku Execution JWT docs: Besu | Erigon | Geth | Nethermind | Reth Set withdrawal address
Stakers must set a withdrawal address to unlock reward payments from the consensus layer. This is set when generating your validator keys. If you do not provide a withdrawal address prior to depositing, you will have to perform an additional step to update your keys and enable withdrawals. Funds will be locked in the meantime. More on staking withdrawals
Set fee recipient
Stakers must provide a fee recipient address to their consensus client in order to receive transaction fee rewards. This is a normal Ethereum address that you're used to. If you do not provide an address to your client, you will not receive transaction fees when your validator proposes blocks. See your consensus client documentation for client-specific instructions on how to set this. Fee recipient docs: Lighthouse | Nimbus | Prysm | Teku Consensus Layer Beacon Node (BN)
Required
Verify it with the following command to check if it returns the client version correctly: curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' http://:8545 Make sure that your node has more than 20 peers.
Consensus Layer Validator Client (VC)
Required
Section 3 - After depositing
Protect your funds using monitoring software, and learn how to handle different real world scenarios. These steps are optional but are recommended to optimize your node. Monitoring
Prometheus and Grafana monitor
The clients support Prometheus and Grafana to help you visualize important real-time metrics about your validator. Monitoring docs: Lighthouse | Nimbus | Prysm | Teku Testnet simulations
While validating on the testnet, perform these simulations to learn more about your node, and better prepare yourself for Mainnet: Advanced system architecture
To avoid exposing your validator identity to the network, you can use a trustworthy VPN to help reduce the risk of revealing your IP address. Moreover, you can set your Validator Client (VC) and Beacon Node (BN) on separate machines and IPs so that even if your beacon node is vulnerable, your keystore is stored on a different machine. Graffiti
You can use your validator client's graffiti flag to add a personal touch to your proposed blocks (some text of your choice). You will be able to see it using Beaconcha.in or BeaconScan blockchain explorers. If you have questions, EthStaker community is a good place to get help! You can find support on Discord or Reddit. Staking Launchpad
Deposit
Checklist
FAQ
Terms of Service
Become a validator 🦏
More on staking
The Ethereum roadmap
Avoid phishing
Staking economics
Formal verification report