Towns 백서 전문

e hostname | Yes | - | Yes | | TOWNS\_ENV | Environment name for network configuration (beta for testnet, omega for mainnet) | Yes | beta | - | | WALLETPRIVATEKEY | Node ECDSA private key string | Yes | - | Yes | <Note> Testnet Values provided above are as of May 2024. New contract addresses can be found in `packages/generated/**` of river repo. </Note> <Warning> Environment variables marked as Secret require proper encrypted storage and management. It is up to node operators to choose a secure store for such secrets depending on their runtime operating environment be it cloud or on-premise. </Warning> ### Cross-chain Requirements `CHAINSSTRING` environment variable is a comma-separated, colon delimited list of chain ID's and RPC Urls that is required for nodes to support cross-chain entitlement checks. As of June 2024, the Towns network must support the following chainIds listed in the below table for testnet, mainnet, respectively. As an example, using redacted RPC urls from Web3 providers, the `CHAINSSTRING` environment variable for Mainnet would look like: ``` 1:https://eth-mainnet.g.alchemy.com/v2/$ETHEREUM_API_KEY,8453:https://base-mainnet.g.alchemy.com/v2/$BASE_API_KEY,42161:https://arb-mainnet.g.alchemy.com/v2/$ARBITRUM_MAINNET_API_KEY,137:https://polygon-mainnet.g.alchemy.com/v2/$POLYGON_API_KEY,10:https://opt-mainnet.g.alchemy.com/v2/$OPTIMISM_API_KEY ``` <Warning>Do not use public RPC provider urls found on [chainlist](https://chainlist.org/) or elsewhere as these are notoriously unstable. Node Operators are encouraged to provision RPC Urls for high availability for each supported chainId by using custom provisioned provider urls from [Alchemy](https://www.alchemy.com/) or [Infura](https://www.infura.io/).</Warning> ### Testnet Cross-Chain Chain Ids Required On testnet, nodes should support the following chain ids with configured RPC endpoints for cross-chain entitlement checks. | Chain Id | Network | | -------- | ---------------- | | 1 | Ethereum Mainnet | | 11155111 | Ethereum Sepolia | | 8453 | Base Mainnet | | 84532 | Base Sepolia | | 42161 | Arbitrum One | | 137 | Polygon Mainnet | | 10 | Optimism Mainnet | | 10200 | Gnosis Chiado | ### Mainnet Cross-Chain Chain Ids Required On mainnet, nodes should support the following 6 chain ids for cross-chain entitlement checks. | Chain Id | Network | | -------- | ---------------- | | 1 | Ethereum Mainnet | | 8453 | Base Mainnet | | 42161 | Arbitrum One | | 137 | Polygon Mainnet | | 10 | Optimism Mainnet | | 100 | Gnosis | # Upgrade Node Source: https://docs.towns.com/node-operator/tutorials/upgrade-towns-stream-node The following guide illustrates how to upgrade a Towns Stream Node on Towns Chain in Testnet. The Mainnet guide follows from this guide with modifications to contract addresses and rpc url for Towns Chain. <Note>It is assumed that the node operator wallet registered on Base has been bridged to Towns Chain by the DAO and that the node operator has warm access to this wallet to perform node operations to register, and update a fleet of nodes.</Note> Nodes will need to be upgraded as part of maintenance operations to keep up-to-date with version upgrades and fixes. Upgrading can be accomplished from source or docker image. This guide will focus on upgrading from the Towns Protocol public ecr registry: `public.ecr.aws/h5v6m2x1/river`, which hosts docker images built for version upgrades and hotfixes across testnet and mainnet. ### Node Components The below diagram describes component relations between Node FE (Frontend), Node Identity, Node Storage, IP Address, Stream from the network's perspective assuming an [Operational](https://github.com/towns-protocol/towns/blob/main/packages/contracts/src/river/registry/libraries/RegistryStorage.sol#L33) Node FE as described by the RiverRegistry on-chain state. ```mermaid theme={null} --- title: Node Components Network Perspective --- erDiagram NodeFE ||--|| WalletIdentity : "has a" NodeFE ||--|| NodeStorage : "attaches to" NodeStorage ||--|| WalletIdentity : "is partitioned by" NodeFE ||--|| IPAddress : "points to one" NodeFE ||--|| Stream : "is randomly assigned" Stream ||--|| NodeFE : "has reference to on-chain" ``` ### Upgrade a Node Upgrading Node FE software can be achieved with a new node identity or existing node identity. <Note>It is currently reccommended to upgrade node software with existing node identity that is stored in RiverRegistry. Once Stream rebalancing is implemented, upgrades that create and register a new node identity can be safely enacted without potential stream downtime.</Note> The below assumes an upgrade path from docker. Futures guides will focus on upgrades from source. ```mermaid theme={null} flowchart TB updateSoftware("pull latest image from Towns docker registry") --> ID("use current node identity?") ID -- no --> newNodeID("new node identity") ID -- yes --> existingNodeID("current node identity") existingNodeID --> startNodeFE("start Node FE from image") startNodeFE --> healthChecks("run health checks") healthChecks -- pass --> shutdownExisting("shutdown existing Node FE") healthChecks -- fail --> restartExisting("restart existing Node FE") ``` ### Upgrading a Node with existing identity steps The below steps further describe the reccommended path to upgrade Node FE from the RHS of the above flowchart. <Note>This guide assumes the node operator performing the upgrade has access to an existing node's wallet private key as well as credentials to connect to a write instance of the Node Storage instance.</Note> <Steps> <Step title="Pull latest river image"> ```bash theme={null} $ docker pull public.ecr.aws/h5v6m2x1/river:testnet ``` </Step> <Step title="Start Node FE"> Once you've pulled the latest image and have set your environment variables, you can start your Node FE docker container within your network configuration. <Warning>Ensure you are starting your node's container with `SKIP_GENKEY=true` otherwise a new node wallet will be created and attached to your Node storage.</Warning> If you have any load balancers configured, please ensure that the public IP pointed to by the node identity's node url (found in RiverRegistry) routes to the new pid for this Node FE. </Step> <Step title="Run health checks"> If you've exposed metrics, you should have a separate service running on `http:/localhost:8081/metrics` that you can inspect to ensure the Node FE is up and running properly. </Step> <Step title="Shutdown old Node FE"> If you've come this far, you have a new Node FE pid running attached to your Node Storage Postgres DB meaning the node is ready to serve writes. Furthermore, your node URL attached to your node's identity should be resolving to the IP of your node. At this point, you can safely shutdown your old Node FE as it is not proxying any traffic for the network. </Step> </Steps> # Governance Framework Source: https://docs.towns.com/token-governance/governance-framework The Towns Lodge Governance Framework is designed to ensure a balanced, sustainable, and effective development of the **Towns Protocol**. By ensuring all the mechanisms for compliance and administrative requirements are met, the members can focus on funding decisions that will shape the future of the protocol and the community. Continued funding decisions to the existing framework allows would allow for the members to be involved without taking on community roles – however, the governance process also supports community growth and member roles.\ For example, the Grants Program could easily become a part of the Towns Lodge with members of the community being elected to form the committee or funding decisions beyond the existing Association can be complicated to expand the mechanisms for which the Treasury supports the Towns Protocol.\ This framework is the bedrock upon which the Towns Lodge operates, providing a structured approach to decentralized decision-making ### Decentralization Central to the Towns Lodge is the principle of decentralization. This ensures that power and decision-making are not concentrated in the hands of a few but are distributed across the wider community. The governance framework is designed to prevent central points of failure and promote a diverse and inclusive decision-making process. ### Transparency Every aspect of the Towns Lodge, from proposal submission to the final implementation of decisions, is conducted with utmost transparency. Token voting ensures that all actions are recorded and are publicly verifiable, fostering trust and accountability within the community. # Overview Source: https://docs.towns.com/token-governance/overview The Towns Lodge represents a pivotal component in the **Towns Protocol** ecosystem, embodying a decentralized governance structure that upholds the principles of transparency, autonomy, and community-driven decision-making. Organized as a Wyoming Decentralized Unincorporated Nonprofit Association, the Towns Lodge oversees 3 billion TOWNS Tokens in its Treasury allowing all tokenholders to have a voice in how that value should be utilized in shaping protocol's future. ## The Essence of Towns Lodge At its core, Towns Lodge facilitates a democratic platform where proposals related to the **Towns Protocol** are discussed, voted upon, and implemented. This ensures that the protocol evolves in a way that resonates with the collective will of its stakeholders, specifically those who run the network, create Spaces, and use River for communication. Its structure is designed to be both inclusive and effective, accommodating diverse opinions while maintaining a streamlined decision-making process. ## Functionality and Governance Towns Lodge is designed for an incremental rollout to allow TOWNS tokenholders the ability to experience the system as designed. At present, the River Eridanus Association board of directors makes governance decisions to directly and indirectly further the growth and development of the Towns Protocol. However, in a novel application designed to empower TOWNS tokenholders – the 3 billion TOWNS Tokens held in the Treasury are under the control of the TOWNS tokenholders themselves.\ When token governance is goes live on January 1st, 2026, it is the TOWNS tokenholders who will decide whether to keep funding the **River Eridanus Association** and through proposals always have a voice in the decision-making. ## Token-based Governance Towns Lodge is pioneering a new governance structure focused on getting the actual stakeholders of the ecosystem the most important voice, without requiring them to shoulder the day-to-day operations (although – if that is the direction members ultimately want – they would be able to accomplish it through governance). Node Operation NFT and Space Owner NFT holders will have a preferential role within in token governance as their proposals will be subject to lower temp-check thresholds before bringing their proposal to a vote of the community – giving those that have invested their time and energy to the community the clearest voice in its decisions. The Towns Token (TOWNS) plays a crucial role in the governance model. It serves as a tool for voting, where the weight of a stakeholder's vote is proportional to their token holdings. This token-based governance model encourages active participation from the community, ensuring that those who are invested in the protocol have a say in its direction. ## Vision and Mission The Towns Lodge’s objective is to create a self-sustaining, resilient, and adaptable protocol that remains responsive to the needs of its users and the broader blockchain community. By fostering an environment of collaboration and innovation, Towns Lodge aims to lead the way in demonstrating the power and potential of decentralized governance in the blockchain realm. # Towns Token Source: https://docs.towns.com/token-governance/towns-token # Overview The Towns Token (TOWNS) serves multiple roles in the Towns ecosystem. Nodes are required to have a minimum amount of tokens delegated in order to operate in the network. TOWNS token is used to compensate Nodes via inflationary rewards. Spaces earn additional functionality when they reach different levels of token delegation. As a governance token, it empowers its holders to influence the direction and policies of the ecosystem. TOWNS is also used to incentivize node operators, developers, and users while fostering long-term growth and engagement of the Towns protocol. ## Utility of TOWNS ### Use by Nodes TOWNS tokens are essential for nodes within the Towns network. To operate, nodes must have a minimum requirement of TOWNS tokens delegated to them. This requirement ensures a committed and stable node operation within the network. Moreover, nodes with a higher amount of staked tokens gain priority in the operational queue, reflecting the finite capacity of active nodes at any given moment. * This requirement is met by a combination of tokens delegated directly to the node as well as Spaces that point their delegated tokens to that node. ### Use by Spaces Spaces within the Towns ecosystem can leverage TOWNS tokens for enhanced functionalities and governance. With delegated tokens, Spaces can implement custom entitlement logic on other EVM chains besides Base. Higher amounts of delegated tokens allows for custom pricing modules without [Towns Lodge](https://townslodge.com) approval, such as allowing members access at no cost. ### Token Delegation * **User to Space/Node Delegation**: TOWNS holders can delegate their tokens to either a Space or a Node, a mechanism that underpins the governance model of the Towns ecosystem. This delegated stake allows users to contribute to the protocol's governance, emphasizing the role of Space operators as key governance participants. * Delegated tokens are not transferable. When tokens are undelegated, a 60-day countdown is initiated before the tokens are transferable again. This period is required to allow time to rebalance streams of a given node if delegation is removed below the minimum requirement. * **Spaces Pointing to Nodes**: Spaces can point their tokens to nodes, aiding them in meeting the minimum operational requirements. This symbiotic relationship allows Spaces to partake in the inflationary rewards earned by the Node, without transferring governance rights, which remain with the Space. * It is important to note that by pointing to a given node, a Space is signifying good nodes to operate in the ecosystem but has no additional relationship where the Space would be provided better service, as all active Nodes in the system perform equal work. ### Use for Governance Governance within the Towns ecosystem is exclusively driven by delegated tokens. This model ensures that only stakeholders actively participating through delegation have a say in governance decisions, promoting a more engaged and responsible governance community. ## Token Information * **Symbol/Network**: TOWNS is an ERC20 token on the Base and Ethereum Mainnet. * **Supply**: The initial supply is set at 10 billion tokens, with a designed inflationary model. * **Inflation**: TOWNS token is programmed with initial 8% inflation which decreases linearly over 20 years until it hits a final inflation rate of 2%. * **Distribution**: The distribution of TOWNS tokens is as follows: approximately 35% to the team and investors, 5% to HNT Labs, and the remaining 60% allocated to the association. The initial allocations to the team and investors are subject to a one-year lock-up period, followed by a two-year linear vesting schedule. * **Contract Addresses**: The TOWNS token is deployed on: Base: 0x00000000A22C618fd6b4D7E9A335C4B96B189a38 Ethereum: 0x000000Fa00b200406de700041CFc6b19BbFB4d13 ## Association Initiatives ### Airdrops The Towns ecosystem will conduct multiple airdrops targeting various stakeholders to stimulate engagement and reward early adopters. The first airdrop will focus on Space Owners with paying members, paying members, other Space Owners and members, in that order. ### Community Rewards A biweekly distribution model is planned for Community Rewards, allocating a fixed amount of tokens to Spaces with significant delegated tokens relative to each other. These rewards are designed to encourage token delegation and active participation in governance and introduce a team competition component to drive engagement. These incentive rewards will either be distributed to the Space or back to the members directly pro rata. ### Grants Programs The association will establish committees to oversee the grant programs, aimed at supporting the development of the Towns Protocol and its applications. These grants are intended to catalyze innovation and growth within the Towns ecosystem. The initial grants will focus on client developers building on the Towns protocol and additional Towns stream and storage implementations for the protocol itself. # Node Operators Source: https://docs.towns.com/towns-messaging-protocol/node-operators ## Registration and Delegation * **Node Registry Contract**: Node Operators begin by calling the `register` function on the Node Registry contract deployed on Base. This initial step enters them into the system and marks the beginning of their operational journey. * **Soliciting Delegation**: After registration, Node Operators are eligible to solicit delegation to their address. This is a crucial step where operators gather support from token holders, who delegate their tokens to the operator as a sign of trust and endorsement. ## Approval Process * **Petitioning for Approval**: Once a Node Operator has accumulated sufficient delegation, they can petition the DAO for approval. This step is vital as it involves a review by the DAO to ensure the operator meets the required standards and guidelines for network operation. * **Approval**: If approved, the Node Operator is officially added to the active set on the River Registry contract deployed on the Towns Chain. This approval marks the operator as a trusted and recognized entity within the network. ## Node Management * **Adding Individual Nodes**: With approval, Node Operators can then add individual Nodes under their wing. This involves configuring and setting up Nodes to perform various functions within the network. * **Node States**: Nodes can exist in several states: * **Idle**: Newly added Nodes start in an idle state, where they are present within the network but not actively participating in operations. * **Unattached State**: Nodes can then move to an unattached state, where they run and relay requests without being responsible for any specific stream. In this state, Nodes do not have dedicated storage and serve a more auxiliary function. * **Attached State**: The ultimate goal for a Node is to reach the attached state, where it becomes fully operational and responsible for new streams. In this state, a Node is fully integrated into the network, participating in data storage, processing, and relay functions. * **Exiting**: The Node is signaling that it is planning to exit and so should begin offloading stream data to other active nodes in the network. # Overview Source: https://docs.towns.com/towns-messaging-protocol/overview ## Introduction The Towns Messaging Protocol is the essential infrastructure for validating and moving encrypted messages between users. It introduces an innovative approach to secure and private group messaging. Designed to operate seamlessly within the blockchain infrastructure, this protocol leverages the robustness of decentralized technology to offer a high-quality permissionless messaging experience. Read/write entitlements are secured on Base, allowing Towns to make liveliness tradeoffs to send messages to thousands of participants as fast as any existing centralized social network. Towns protocol is initially