PoS Validataor
Last updated
Last updated
OS: Ubuntu 20.04 (amd64) and above, you can download it here https://releases.ubuntu.com/20.04.6/ubuntu-20.04.6-live-server-amd64.iso
Checkpoint sync (recommended)Genesis syncWith checkpoint sync configured, your beacon node will begin syncing from a recently finalized checkpoint instead of syncing from genesis. This can make installations, validator migrations, recoveries, and network deployments way faster.
Follow the CLI prompts to generate your keys. You will need to enter:1. Your withdrawal Opside address(which is used to receive your validator rewards and your deposit when you exit)2. Password(which is used to encrypt your validator signing key)3. Repeat your withdrawal Opside address4. Repeat your PasswordThen there will be 24 mnemonic seed phrases. This is highly sensitive and should never be exposed to other people or networked hardware.
You should now have your mnemonic written down in a safe place and a keystore saved for each of your validators.
Please make sure you keep these safe, preferably offline.
Follow the CLI prompts to:
Enter your seed phrase(separated with space)
Waiting for the validator key generated
Waiting for the nodes launched
After client installed, ensure you are fully synced before submitting your staking deposit. This can take several days.
You will see:
Check here to see if the block height is close to the[number=48883], if yes, it's time for IDE to be deposited.
Go to Validator Launchpad, follow the steps to enter the Upload deposit data page, then upload the deposit data file you just generated.The deposit_data-[timestamp].json is located in directory testnet-auto-install/validator_keys/.
For MacOS, the deposit_data-[timestamp].json located in directory opside-staking-deposit-cli/validator_keys/
Or input the content of the deposit_data-[timestamp].json:
Use cat deposit_data-[timestamp].json to show the content.
Copy the content and paste it here:
Click Continue.
Check the summary and risks, then click Continue.
Go to https://opsi.de/validator/overview and search for your valdiator public key, index, or deposit address.
Port/protocol
Firewall rule
Reason/caveats
8545/TCP
Block all traffic.
This is the JSON-RPC port for your execution node's Query API. You (and apps) can use this port to check execution node status, query execution-layer chain data, and even submit transactions. This port generally shouldn't be exposed to the outside world.
3500/TCP
Block all traffic.
This is the JSON-RPC port for your beacon node's Query API. You (and apps) can use this port to check beacon node status and query consensus-layer chain data. This port generally shouldn't be exposed to the outside world.
8551/TCP
Block all traffic.
Your beacon node connects to your execution node's Engine API using this port. Inbound and outbound traffic should be allowed through this port only if your local beacon node is connecting to a remote execution node.
4000/TCP
Block all traffic.
Your validator uses this port to connect to your beacon node via gRPC. Inbound and outbound traffic should be allowed through this port only if your local validator is connecting to a remote beacon node.
*/UDP+TCP
Allow outbound traffic.
To discover peers, Prysm's beacon node dials out through random ports. Allowing outbound TCP/UDP traffic from any port will help Prysm find peers.
13000/TCP
Allow inbound and outbound traffic.
After we discover peers, we dial them through this port to establish an ongoing connection for libp2p and through which all gossip/p2p request and responses will flow.
12000/UDP
Allow inbound and outbound traffic.
Your beacon node exposes this UDP port so that other Ethereum nodes can discover your node, request chain data, and provide chain data.
33687/TCP+UDP
Allow inbound and outbound traffic.
33687/TCP is your execution node's listener port, while 33687/UDP is its discovery port. This rule lets your execution node connect to other peers.
