48 lines
4.7 KiB
Markdown
48 lines
4.7 KiB
Markdown
# Deployments
|
|
|
|
## Overview
|
|
|
|
Zenith network deployments progress through multiple stages, each with different infrastructure requirements and operational models.
|
|
|
|
## Stage 0: Onboarding Phase
|
|
|
|
Stage 0 is operated entirely by Tlon with no external infrastructure required. This onboarding phase runs on a single centralized validator operated by Tlon for participant onboarding and attestation collection. External participants only need to interact with the onboarding application to submit their attestations and lockdrop commitments.
|
|
|
|
## Token Generation Event (TGE)
|
|
|
|
When Stage 0 is manually halted, anyone can recreate the genesis state from Stage 0 data following the TGE process. The TGE process verifies all attestations, validates point ownership against the Azimuth registry, and generates the complete genesis file with initial validator set and token allocations.
|
|
|
|
## Stage 1: Initial Mainnet
|
|
|
|
Stage 1 marks the transition to mainnet where validators begin joining the network. Galaxy operators deploy validator nodes while star operators deploy bundling nodes.
|
|
|
|
### Validator Node Deployment
|
|
|
|
Galaxy operators joining as validators configure their deployment using the zenith-ansible tooling. Key configuration requirements include setting the validator data directory, choosing a human-readable moniker for network identification, and configuring the Ethereum RPC endpoint for Azimuth monitoring. Operators must specify their Urbit galaxy ID and associated star ID along with peer connections to the bootstrap node.
|
|
|
|
The deployment process involves exporting the private key for the galaxy owner's account, which is required for both validator operations and the associated star's Janus service. Operators setup their validator node with appropriate port configurations to avoid conflicts, pull the necessary docker images, and initialize deployment directories. After starting the validator node, they create their validator registration using the exported private key.
|
|
|
|
Verification includes checking the node's sync status with the network, reviewing logs for proper operation, and confirming the validator appears in the bonded validator set. The node must maintain connectivity to the network and successfully participate in consensus to earn token accrual.
|
|
|
|
### Star Node Deployment
|
|
|
|
Star operators deploy follower nodes running in star mode to participate in the Janus transaction bundling system. These nodes bundle transactions from planets and submit them to their sponsoring galaxy without becoming validators themselves.
|
|
|
|
Configuration involves setting the star node data directory, moniker, and network connectivity including peers pointing to the sponsoring galaxy's validator node. Operators specify their Urbit star ID and configure the Janus galaxy URL pointing to their sponsor galaxy's Janus API endpoint. The star node requires the private key for the account that onboarded the star point.
|
|
|
|
The deployment process includes modifying port configurations to avoid conflicts with other nodes, pulling docker images, and setting up deployment directories. After starting the star node, operators verify it syncs with the Stage 1 chain by checking sync status and reviewing logs.
|
|
|
|
Once synced, the star node exposes a Janus API endpoint to accept transactions from planets. Transactions are bundled together, signed by the star, and forwarded to the sponsoring galaxy's Janus endpoint for inclusion in blocks. The star earns rewards from transaction bundling fees and optional network services.
|
|
|
|
### Infrastructure Requirements
|
|
|
|
Validator nodes require high-performance multi-core processors with substantial RAM for validator operations and reliable SSD storage. High-bandwidth, low-latency internet connections are essential along with backup systems for failover capabilities. Star nodes need multi-core processors capable of transaction aggregation with moderate RAM and storage requirements. Both node types require stable connectivity, health monitoring systems, and secure key management practices.
|
|
|
|
### Monitoring and Observability
|
|
|
|
Operators should monitor node sync status, log output for errors, and resource utilization including CPU, RAM, and storage. Network connectivity and peer connections require regular monitoring along with block production participation and transaction processing rates. Alerting systems should notify operators of issues requiring intervention.
|
|
|
|
### Security Hardening
|
|
|
|
Secure key management is critical for both validator and star operations. Operators should implement proper firewall configurations, restrict administrative access to authorized personnel, and maintain comprehensive audit logging. Data should be encrypted at rest and in transit with regular backups stored securely. Disaster recovery procedures should be tested periodically to ensure rapid recovery from failures.
|