bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 17쪽 중 10쪽
189a38](https://basescan.org/address/0x00000000A22C618fd6b4D7E9A335C4B96B189a38) |
| Ethereum Mainnet | [0x000000Fa00b200406de700041CFc6b19BbFB4d13](https://etherscan.io/address/0x000000Fa00b200406de700041CFc6b19BbFB4d13) |
### Mainnet Towns Chain Resources
| Description | URL |
| --------------------------- | ------------------------------------------------------------- |
| Towns Chain Explorer | [explorer.towns.com](https://explorer.towns.com) |
| Towns Chain RPC Node (HTTP) | [mainnet.rpc.towns.com](https://mainnet.rpc.towns.com) |
| Towns Chain Hub | [mainnet.hub.towns.com](https://mainnet.hub.towns.com) |
| Towns Chain Bridge L1 -> L2 | [mainnet.bridge.towns.com](https://mainnet.bridge.towns.com) |
| Towns Chain Status | [mainnet.status.towns.com](https://mainnet.status.towns.com/) |
### Testnet Towns Chain Resources
| Description | URL |
| --------------------------- | ---------------------------------------------------------------- |
| Towns Chain Explorer | [testnet.explorer.towns.com](https://testnet.explorer.towns.com) |
| Towns Chain RPC Node (HTTP) | [testnet.rpc.towns.com](https://testnet.rpc.towns.com/http) |
| Towns Chain Hub | [testnet.hub.towns.com](https://testnet.hub.towns.com) |
| Towns Chain Bridge L1 -> L2 | [testnet.bridge.towns.com](https://testnet.bridge.towns.com) |
### Celestia Data Availability Layer
Towns uses the Celestia [DA](https://docs.celestia.org/learn/how-celestia-works/data-availability-layer) (Data Availability) Namespace to store blob data on the Towns Chain in a scalable, highly available, and cost-effective manner.
| Namespace ID | Explorer |
| ------------------------ | ----------------------------------------------------------------------------------------------------- |
| ca1d e12a 2bf1 0ef2 0a85 | [celenium.io](https://celenium.io/namespace/000000000000000000000000000000000000ca1de12a2bf10ef20a85) |
# Introduction
Source: https://docs.towns.com/node-operator/introduction
The Towns Protocol is powered by a network of Stream Nodes that are registered on chain and run by Node Operators. This guide is intended as an introduction to getting started as an operator and running a node in the Towns network.
### Operating Towns Components
[Towns Stream Nodes](https://github.com/towns-protocol/towns/tree/main/core/node) are software components that are able to be run by anyone. Towns Protocol's incentive structure supports Towns Stream Node operators as a first-class actor in the network. Operators, once registered and approved by the DAO , can run a Stream Node on Towns Chain and participate in block validation as well as reward distribution.
Given the open-source nature of Towns, the Foundation also encourages developers who would like to run instances of Towns Chain on a network of their choice connected to self-hosted Towns Stream Nodes. Though these nodes would not technically be connected to the Towns protocol node network that is deployed on [Base Mainnet](https://basescan.org/), developers may find value in experimenting with different rollup implementation features.
### Operator Onboarding Lifecycle
Operator and node onboarding to the network follow a multi-stage lifecycle that is designed to ensure the operator is fully prepared and meets [requirements](/node-operator/tutorials/system-requirements-installation) to run a node in mainnet.
Each of the following steps are described in detail in subsequent sections.
<Steps>
<Step title="Register operator in Testnet" />
<Step title="DAO operator approval in Testnet" />
<Step title="Register node in Testnet" />
<Step title="Register operator in Mainnet" />
<Step title="Achieve sufficient TOWNS token delegation" />
<Step title="DAO operator approval in Mainnet" />
<Step title="Register node in Mainnet" />
<Step title="DAO operator activation in Mainnet" />
<Step title="Participate in TOWNS rewards distribution epochs" />
</Steps>
#### Stream Node Configuration Modes
The below table outlines the current operator service level that is supported by the Towns Protocol. Supported configurations are outlined in subsequent sections.
| Configuration | Description | Node Registration | Stream Reads | Stream Writes | Support |
| ------------- | ------------------------------------------------------------------------------------------------ | ----------------- | ------------ | ------------- | ------- |
| Full node | Stream node running inside Towns node network | ✅ | ✅ | ✅ | ✅ |
| Info mode | Stream node running in info mode, unattached to the network, for debug purposes only. | ❌ | ❌ | ❌ | ✅ |
| Archival node | Stream node running outside Towns node network storing all stream events from Towns node network | ❌ | Proxied | Proxied | ❌ |
# Release Process
Source: https://docs.towns.com/node-operator/release-process
Towns protocol releases process and guidelines for node operators.
Towns protocol releases follow a weekly cadence for both testnet and mainnet. Release artifacts, stream node images, are built and published to the [Towns Docker ECR](https://public.ecr.aws/h5v6m2x1/river).
## Release Process
<Steps>
<Step title="Testnet Upgrade">
Every Monday (by 11pm UTC), a new testnet release is cut from the latest alpha release candidate tag and published to the Towns Docker ECR. The release is tagged with the testnet version number in the form, `testnet/YYYY-MM-DD-##`.
The docker image is built and doubly tagged with `testnet` (mutable) and the commit sha (immutable).
<br />
<Note>Operators are encouraged to monitor the Towns Protocol [repository](https://github.com/towns-protocol/towns) for `testnet*` prefixed tags to upgrade nodes running in testnet.</Note>
</Step>
<Step title="Mainnet Upgrade">
Every Tuesday (by 11pm UTC), a new mainnet release is cut from the latest alpha release candidate tag and published to the Towns Docker ECR using the commit sha that was deployed to `testnet` last as the release branch. The release is tagged with the mainnet version number in the form, `mainnet/YYYY-MM-DD-##`.
The docker image is built and doubly tagged with `mainnet` (mutable) and the commit sha (immutable).
<br />
<Note>Operators are asked to ensure mainnet images are upgraded by eod Tuesday to ensure homogeneity of software versions running in mainnet.</Note>
</Step>
<Step title="Hotfix">
Occasionally, an urgent hotfix will be required to address critical issues. In such cases, the hotfix will be cut and published to the Towns Docker ECR with a `hotfix` tag, a `mainnet` tag, a `testnet` tag and commit sha tag.
Hotfixes will be explicitly communicated to operators to upgrade their nodes in the Towns Operator Town, `testnet` nodes first followed by `mainnet`.
</Step>
</Steps>
# Best Practices
Source: https://docs.towns.com/node-operator/tutorials/node-best-practices
The following guide describes high level best practices for running a Stream Node as a node operator.
## Node Operations Best Practices
Whether operating nodes in the public cloud or on-premise, the following best practices are recommended to ensure availability and reliability of your Stream Nodes.
### Maintenance
<Steps>
<Step title="Regular Updates">
* Keep your node software up to date with the latest security patches and feature updates. Regularly check for new releases.
* Using the deployment scripts, you can bring a new instance of a FE up into validation mode, and once you are confident it is passing health checks, you can switch it to be your new Running node and de-provision your prior FE.
* Storage schema updates are performed via db migrations using [golang-migrate](https://github.com/golang-migrate/migrate) and are performed automatically within releases as part of Node FE upgrades.
* You are encouraged to set `STANDBYONSTART` to true in your environment variables if you are running blue green deployments behind a proxy or network load balancer. This will allow you to bring up a new instance of the FE in standby mode, and once it is passing health checks, it will automatically switch to primary.
<br />
<Note>If your node operator has not yet been fully registered or your node has not yet been registered, you can test running an unattached Node Fe to ensure health checks pass by setting `STANDBYONSTART=true`. A node started in this manner will not attach to Storage layer or shutdown if it is not registered yet on the Towns Chain.</Note>
</Step>
<Step title="Backups">
* Implement routine backups of your Node Storage to prevent data loss.
* Establish an operating procedure for automated or manual data restoration from backups in the event of an outage.
* Use monitoring tools to track your node's performance and health.
* If your node storage crashes, you can restore a backup, and recover/catchup from the peers responsible for the same chunks of data.
<Warning>As of October 2024, stream replication has not yet been implemented. Until stream replication is implemented, data recovery cannot be achieved from peers. Therefore, it is important that node operators backup their node storage regularly and ensure high availability through their cloud provider database setup. </Warning>
</Step>
<Step title="Monitoring">
* Regularly review your node's performance. Use logs, metrics, and profiling tools exposed by node to tune your observability stack.
* Adjust resource allocation and network settings as needed to optimize for throughput and reliability.
<Note>By settings `METRICS__ENABLED=true` in your node's environment, you can enable detailed metrics collection for your node. Metrics are instrumented using [Open Telemetry](https://opentelemetry.io/docs/specs/otel/metrics/) and can be used to monitor your node's performance and health by navigating to the metrics endpoint at `https://<node-hostname>/metrics`. See [node observability](/node-operator/tutorials/node-observability) for more information.</Note>
</Step>
</Steps>
### Troubleshooting
Using logs, metrics and profiling tools, you can identify and resolve issues with your node. Some issues may have specific resolutions on the [Towns Issue Tracker](https://github.com/towns-protocol/towns/issues?q=is%3Aissue+is%3Aclosed).
If there's a new bug or security vulnerability found, please file an issue on the [Towns Issue Tracker](https://github.com/towns-protocol/towns/issues/new/choose) for the core development team to address.
<Steps>
<Step title="Common Issues">
* Address typical problems such as connectivity issues, slow transaction
processing, or database errors with targeted troubleshooting steps provided
in the network's documentation.
</Step>
<Step title="Diagnostic Tools">
Stream nodes are equipped with a variety of diagnostic tools to help you troubleshoot issues.
You can run pprof endpoints securely to collect and analyze profiling data emitted by your node. This is reccommended if you are experiencing performance issues or suspect memory leaks.
Set `DEBUGENDPOINTS__PPROF=true` in your environment variables to enable pprof endpoints.
Then either set `DEBUGENDPOINTS__PRIVATEDEBUGSERVERADDRESS` to a specific address (i.e. '127.0.0.1:8080') and port or `DEBUGENDPOINTS__MEMPROFILEDIR` to a directory to save the memory profile files periodically.
`pprof` endpoints available:
* /debug/pprof/
* /debug/pprof/cmdline
* /debug/pprof/profile
* /debug/pprof/symbol
* /debug/pprof/trace
See [debug.go](https://github.com/towns-protocol/river/blob/main/core/node/rpc/debug.go) for more information and full capabilities.
<Note>If saving pprof results to node image storage, you will need to mount a volume or read the files between node restarts to prevent losing them</Note>
<Note>If you are running a node in a containerized environment, you will need to mount a volume to the node's image storage directory to save the pprof results</Note>
</Step>
</Steps>
### Security
<Steps>
<Step title="Access Control">
* Implement strict access controls for administrative operations. Use secure
authentication methods to protect against unauthorized access.
</Step>
<Step title="Encryption and Network Security">
* Secure data in transit and at rest using encryption. Apply network
security best practices, such as firewalls and secure protocols, to protect
against external attacks.
</Step>
<Step title="Regular Security Audits">
* Conduct regular security audits to identify and mitigate potential
vulnerabilities. Stay informed about the latest security threats and apply
recommended countermeasures.
</Step>
</Steps>
# Node Observability
Source: https://docs.towns.com/node-operator/tutorials/node-observability
The following guide describes the observability capabilities of Towns Stream Nodes and how to monitor and manage them.
Stream nodes expose `/metrics` to export Prometheus metrics on port `443`. The metrics are exposed in the Prometheus format and can be scraped by a Prometheus server. Both `process_` and `river_` prefixed metrics are exportable.
Below are the required environment variables for the **Towns Stream Node Container** related to telemetry:
| Environment Variable | Value | Secret |
| -------------------- | ----- | ------ |
| METRICS\_\_ENABLED | true | no |
| LOG\_\_FORMAT | json | no |
| LOG\_\_LEVEL | info | no |
| LOG\_\_NOCOLOR | true | no |
### Log forwarding
Log forwarding is under construction.
# Register Operator
Source: https://docs.towns.com/node-operator/tutorials/register-towns-operator
The following guide illustrates how to register a new Node Operator to begin onboarding nodes. This guide uses Testnet as an example. The Mainnet guide follows from this guide with modifications to contract addresses and rpc url for Towns Chain.
### Requirements & Dependencies
* Foundry Toolkit: To install follow [this](https://book.getfoundry.sh/getting-started/installation) guide.
* Node Operator delegation: address migrated to Towns Chain by DAO (see below).
* Warm wallet access to Node Operator wallet.
* Sufficient gas on Node Operator wallet on both Base and Towns Chain to register
<Note>
The node operator wallet registered on Base must
be bridged to Towns Chain by the DAO prior to proceeding with node registration. Furthermore, the node operator needs warm access to this
wallet to perform node operations to register, and update a fleet of node instances.
</Note>
All contract addresses for testnet and mainnet needed to register operator can be found in the [contracts](/node-operator/contracts) section.
<Note>When referencing contract methods in the below guide, keep in mind that our contracts are deployed using the [Diamond Standard](https://www.quicknode.com/guides/ethereum-development/smart-contracts/the-diamond-standard-eip-2535-explained-part-1) pattern. This means for practical purposes that when interacting with contracts on Base or Towns Chain, you will be calling each method on the associated diamond contract.</Note>
### Registration Outline
The following outlines the logical steps to onboarding a Node Operator. Instructions are applicable to testnet and mainnet. Node Operator delegations are only needed for mainnet registration.
Instructions with specific calling signatures can be found below in the [Node Operator Registration](#node-operator-registration).
<Steps>
<Step title="Register Node Operator in Base">Operators starts the onboarding process calling [registerOperator](https://github.com/towns-protocol/towns/blob/main/packages/contracts/src/base/registry/facets/operator/NodeOperatorFacet.sol) on the [BaseRegistry](https://github.com/towns-protocol/towns/blob/main/packages/contracts/deployments/gamma/base/addresses/baseRegistry.json) [diamond](https://www.quicknode.com/guides/ethereum-development/smart-contracts/the-diamond-standard-eip-2535-explained-part-1) contract deployed on Base.</Step>
<Step title="Set Commission Rate in Base">Operator sets commission rate for rewards in Base calling [setCommissionRate](https://github.com/towns-protocol/towns/blob/main/packages/contracts/src/base/registry/facets/operator/NodeOperatorFacet.sol) on the BaseRegistry diamond contract with the desired commission rate in basis points.</Step>
<Step title="DAO approves operator">DAO approves operator in Base and Towns Chain via governance once 100mm delegations of TOWNS token are received to the operator</Step>
<Step title="DAO activates operator to start reward clock">Once a node is running and in a healthy state as observed by the network (see [check node health from debug multi dashboard](#check-node-health-from-debug-multi-dashboard)), DAO will activate operator which begins the clock for inclusion in the next reward distribution.</Step>
</Steps>
#### Node Operator Registration
1. Node Operator must call `registerOperator(address)` on the BaseRegistry diamond contract deployed
on Base with the address of the wallet that they wish to claim rewards with. Note that the claimer wallet can differ from the operator wallet.
<Info>Node operators can update the claimer address for receiving rewards from distribution by calling `setClaimAddressForOperator(claimer address, operator address) onlyClaimer` on the BaseRegistry contract with the desired wallet from the Node Operator wallet in Base. This is useful in separating concerns between the claim wallet that accrues rewards and the operator wallet which needs to be warm to facilitate node operations.</Info>
1. Node Operator can begin soliciting delegation after
being registered.
2. Node Operator should call `setCommissionRate(uint256)` on the BaseRegistry contract to set the commission rate for the operator. Ensure the commission rate is passed in using basis point notation (e.g. 10000 for 100%). Conversely, Node Operator can call the view, `getCommissionRate(address)` passing in their operator address to check their current commission rate.
3. After Node Operator receives at least `100m` TOWNS tokens delegated,
the DAO can approve it to enter into Towns Chain. The same address will be added
to River Registry on Towns Chain in order to begin configuring Nodes.
# Register Node
Source: https://docs.towns.com/node-operator/tutorials/register-towns-stream-node
The following guide illustrates how to register a new Stream Node instance on Towns Chain. This guide uses Testnet as an example. The Mainnet guide follows from this guide with modifications to contract addresses and rpc url for Towns Chain.
### Requirements & Dependencies
* Foundry Toolkit: To install follow [this](https://book.getfoundry.sh/getting-started/installation) guide.
* Node Operator delegation: address migrated to Towns Chain by DAO (see below).
* Warm wallet access to Node Operator wallet.
* Node URL pointing via DNS to Node FE attached to Node Storage.
* Access to Base over RPC endpoint
* Access to Towns Chain over RPC endpoint
* Sufficient gas on Node Operator wallet on both Base and Towns Chain to register
* Sufficient gas on Node FE wallet on Towns Chain and Base for validation and cross-chain transactions once node is operational.
<Note>
Node FE's are stateful and as such require consistent resolution of hostnames
to active instance. To avoid unintended bad consequences, it is strongly
encouraged to configure DNS for Node URL with exactly 1 A Record per domain
name. Put differently, each Node URL should point to at most 1 IP address.
</Note>
<Note>
The node operator wallet registered on Base must
be bridged to Towns Chain by the DAO prior to proceeding with node registration. Furthermore, the node operator needs warm access to this
wallet to perform node operations to register, and update a fleet of node instances.
</Note>
All contract addresses for testnet and mainnet needed to register nodes can be found in the [contracts](/node-operator/contracts) section.
<Note>When referencing contract methods in the below guide, keep in mind that our contracts are deployed using the [Diamond Standard](https://www.quicknode.com/guides/ethereum-development/sma프로젝트로 돌아가기
