diff --git a/components/TangleQuickstart.tsx b/components/TangleQuickstart.tsx index 511e0300..3fab51b4 100644 --- a/components/TangleQuickstart.tsx +++ b/components/TangleQuickstart.tsx @@ -78,7 +78,7 @@ export const MonitoringArea = () => { description: `Power your metrics and alerting with the leading open-source monitoring solution.`, name: "Prometheus Setup", }} - href="docs/ecosystem-roles/validator/monitoring/prometheus/" + href="docs/node/monitoring/prometheus/" > { description: `Handle alerts sent by client applications such as the Prometheus server`, name: "AlertManager Setup", }} - href="/docs/ecosystem-roles/validator/monitoring/alert-manager/" + href="/docs/node/monitoring/alert-manager/" > { description: `Visualize results from multiple data sources simultaneously.`, name: "Grafana Dashboards", }} - href="/docs/ecosystem-roles/validator/monitoring/grafana/" + href="/docs/node/monitoring/grafana/" > { description: `Horizontally scalable, highly available, multi-tenant log aggregation system.`, name: "Loki Log Management", }} - href="/docs/ecosystem-roles/validator/monitoring/loki/" + href="/docs/node/monitoring/loki/" > ); diff --git a/pages/docs/_meta.json b/pages/docs/_meta.json index 4cef17ea..05fa9376 100644 --- a/pages/docs/_meta.json +++ b/pages/docs/_meta.json @@ -6,7 +6,6 @@ "network-information-configuration": "Network Configuration", "build": "Build", "node": "Node", - "learn": "Learn", "governance": "Govern", "community": "Community", "faqs": "FAQs", diff --git a/pages/docs/build/pallets/_meta.json b/pages/docs/build/pallets/_meta.json index 23cce300..969b1d14 100644 --- a/pages/docs/build/pallets/_meta.json +++ b/pages/docs/build/pallets/_meta.json @@ -3,7 +3,6 @@ "democracy": "Democracy Pallet", "collectives": "Collectives Pallet", "identity": "Identity Pallet", - "crosschain-pallets": "Cross-chain Pallets", "balances-and-accounts": "Balances Pallet", "consensus-mechanism": "nPoS and the Staking Pallet", "frontier": "Frontier (EVM) Pallets", diff --git a/pages/docs/build/pallets/crosschain-pallets.mdx b/pages/docs/build/pallets/crosschain-pallets.mdx deleted file mode 100644 index fa339d0f..00000000 --- a/pages/docs/build/pallets/crosschain-pallets.mdx +++ /dev/null @@ -1,96 +0,0 @@ -# DKG Governance - -The DKG governance is split between different Substrate pallets that each handle a different aspect of the system. - -## Pallets - -The DKG runtime is uses the following pallets which are central to how the protocol functions. - -### pallet-dkg-metadata - -The metadata pallet tracks information about the DKG state. This includes the active and next authority -sets and their authority set IDs, the active and next DKG public keys, thresholds, historical refreshes, -and more. It’s main purpose is to provide on-chain information about the DKG and the next DKG for clients -who are participating in the protocol. - -The pallet houses a few sub-protocols, namely: - -- The refresh protocol -- The misbehaviour and reputation protocol - -One main importance of this pallet is to deterministically identify the best authorities for the next -DKG’s authority set in order to signal participation to clients in the membership set. This ensures that -all offchain clients see the same state of the world. - -- [Docs](https://webb-tools.github.io/dkg-substrate/pallet_dkg_metadata/index.html) -- [Source](https://github.com/webb-tools/dkg-substrate/tree/master/pallets/dkg-metadata) - -### pallet-dkg-proposals - -This pallet maintains the valid proposers and the first layer of the governance system: voting on proposals -to be signed by the DKG. The valid proposers is superset of the current DKG authorities. Active DKG -authorities are continuously rotated into the proposer set. - -This pallet maintains a queue for pending proposals which the DKG authorities vote on and if the vote threshold -is met, the proposal is passed on to be handled by a type that implements the `ProposalHandlerTrait`. The -proposals meant to be processed by this pallet are primarily `AnchorUpdateProposals` but can be extended to -support any type of proposal that is meant to be submitted by the valid proposers. - -- [Docs](https://webb-tools.github.io/dkg-substrate/pallet_dkg_proposals/index.html) -- [Source](https://github.com/webb-tools/dkg-substrate/tree/master/pallets/dkg-proposals) - -### pallet-dkg-proposal-handler - -This pallet implements the `ProposalHandlerTrait` and accepts proposals through this handler system. In the -current incarnation, the **pallet-dkg-proposals** passes successfully passed unsigned proposals to this pallet -for queuing for eventual signing by the DKG. All unsigned proposals handled here are added to a queue which each -DKG client continues to poll from using a runtime API. - -Off-chain, unsigned proposals move through the DKG’s threshold signature protocol and eventually, if successful, -get re-submitted on-chain as signed proposals. The unsigned proposal records are removed and the signed proposals -are stored in the pallet’s storage for inspection by any observing system, such as an oracle or relayer network. - -This pallet represents the second stage in the governance protocol. That is, after the first layer of the governance -system decides on which proposals to sign, this pallet helps expose those proposals and enable submission of them -after successful threshold-signing. - -- [Docs](https://webb-tools.github.io/dkg-substrate/pallet_dkg_proposal_handler/index.html) -- [Source](https://github.com/webb-tools/dkg-substrate/tree/master/pallets/dkg-proposal-handler) - -## Client - -The DKG client (or gadget) is the main service that interfaces with the pallet system and overall governance protocol. -It is responsible for listening to the chain and participating (if selected) in the DKG protocol. - -### dkg-gadget - -The DKG gadget is an offchain service that executes the DKG protocols and stores data in off-chain storage for the -on-chain system to fetch and post back on-chain. It also listens to changes in the proposal handler and metadata -pallets in order to properly: - -- Rotate keys -- Sign unsigned proposals -- Set and clear offchain storage -- Report misbehaviours. - -We are always executing a DKG signing protocol for the current authority set **and the DKG key generation protocol -for next authority set if none has completed**. - -- [Docs](https://webb-tools.github.io/dkg-substrate/dkg_gadget/index.html) -- [Source](https://github.com/webb-tools/dkg-substrate/tree/master/dkg-gadget) - -### **Note on Offchain workers** - -The DKG makes use of offchain workers to store data ready for on-chain submission. - -If running a live chain as a validator, please add your sr25519 account keys to the node's local keystore -either by using the `author_insertKey` RPC or using the `key` subcommand - -``` -dkg-standalone-node key insert --key-type acco --scheme sr25519 --suri -``` - -> Key Type is `acco` Scheme is sr25519 - -**Note** For the standalone node the account being added to the keystore should be the Stash account used in staking -not the Controller account diff --git a/pages/docs/faqs.mdx b/pages/docs/faqs.mdx index eb8d67fe..1d3c90b7 100644 --- a/pages/docs/faqs.mdx +++ b/pages/docs/faqs.mdx @@ -1,16 +1,16 @@ -# General FAQ: Frequently Asked questions +# General FAQ: Frequently Asked Questions -Q: Where can I get help? +## Where can I get help? -A: Our Discord is the best place to get assistance with your node or other questions about the project. See http://webb.tools/community for links to that Discord and more. +Our Discord is the best place to get assistance with your node or other questions about the project. See http://webb.tools/community for links to Discord and more. -Q: How do I stay up to date? +## How do I stay up to date? -A: All upgrades and important technical information are announced on Discord and Twitter, in the #tangle-network channel. See http://webb.tools/community for links to that Discord and more. +All upgrades and important technical information are announced on Discord and Twitter, in the #tangle-network channel. See http://webb.tools/community for links to Discord and more. -Q: What are the hardware requirements? +## What are the hardware requirements? -A: The following specifications are the ideal or recommended, but nodes can be run with less. Testnet nodes have also been run using AWS `t3.Large` instances. +The following specifications are the ideal or recommended, but nodes can be run with less. Testnet nodes have also been run using AWS `t3.Large` instances. | Component | Requirements | | --------- | ------------------------------------------------------------------------------------------------------ | @@ -21,18 +21,19 @@ A: The following specifications are the ideal or recommended, but nodes can be r See https://docs.webb.tools/docs/ecosystem-roles/validator/requirements/ for more information. -Q: What about backup nodes? +## What about backup nodes? -A: We recommedend that you run two machines with the same specifications, in different countries and service providers in order to decentralize and make your services more robust. If your primary fails you can quickly resume services on your backup and continue to produce blocks and earn rewards. Please refer to the Q&A on failovers below. +We recommend that you run two machines with the same specifications, in different countries and service providers to decentralize and make your services more robust. If your primary fails you can quickly resume services on your backup and continue to produce blocks and earn rewards. Please refer to the Q&A on failovers below. -Q: What are the different networks? +## What are the different networks? -A: There are three networks, each will require dedicated hardware. The Moonbase Alpha TestNet is free and should be used to familiarize yourself with the setup. +There are two networks, each will require dedicated hardware. The Tangle TestNet is free and should be used to familiarize yourself with the setup. Tangle Network - Mainnet, not launched yet. + Tangle Testnet - Launched. -Q: What ports do I allow on my firewall? +## What ports do I allow on my firewall? As stated before, the standalone nodes will listen on multiple ports. The default Substrate ports are used in the standalone, while the relay chain will listen on the next higher port. @@ -53,74 +54,34 @@ The only ports that need to be open for incoming traffic are those designated fo | WS | 9944 | | Prometheus | 9615 | -Q: Is there a binary? - -A: We're working on this, check back soon! - -Q: What are the recommendations on monitoring my node? - -A: Monitoring is critical for success as a node operator. See our full Monitoring guide at https://docs.webb.tools/docs/ecosystem-roles/validator/monitoring/quickstart// - -Q: What are the KPIs I should be monitoring? - -A: The main key performance indicator for a node operator is the number of blocks produced. The prometheus metric for this is called substrate_proposer_block_constructed_count. - -Q: How should I setup alerting? - -A: Alerting is critical for your success as a node operator, see our full guide to using our recommended AlertManager at https://docs.webb.tools/docs/ecosystem-roles/validator/monitoring/alert-manager/ - -Q: What is the failover process if my primary node is down? - -A: When the primary server is down, the best way to perform a failover to the backup server is to perform a key association update. Each server should have a unique set of keys already. Run the setKeys author mapping extrinsic. You can follow the Mapping Extrinsic instructions and modify the instructions to use the setKeys extrinsic. - -Q: What should I look for in the logs? - -A: For full support, see our guides on logging at https://docs.webb.tools/docs/ecosystem-roles/validator/monitoring/loki/ . - -Q: How much stake do I need to become an validator in the active set? - -Per era, the NPoS system selects a certain number of nodes with the most TNT to validate. Therefore, minimum amount required to become an active nominator and earn rewards may change from era to era. You can check the active validator set's stake at https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Ftangle-standalone-archive.webb.tools#/staking - -Q: How do I set an identity on my account? - -A: Setting an identity on chain will help to identify your node and attract delegations. You can set an identity by following the instructions on Polkadot's Identity Documentation at https://wiki.polkadot.network/docs/learn-identity - -## Privacy and Security FAQs - -**Q: How does Webb Protocol ensure the privacy and security of its users?** - -A: Webb Protocol employs cutting-edge privacy technologies, such as zero-knowledge proofs, distributed key generation, and secure relayer systems, to maintain the privacy and security of users' assets and information. - -## Anchor System and Relayer System - -**Q: Can you explain the role of the Anchor System and the Relayer System in the Webb Protocol?** +## Is there a binary? -A: The Anchor System connects merkle trees on different blockchains, ensuring liveness and safety. The Relayer System acts as an oracle, data relayer, and protocol governance participant, relaying information for connected Anchors and enhancing the overall security of the system. +We're working on this, check back soon! -**Q: How does the Anchor System work, and what is its significance in the Webb Protocol?** +## What are the recommendations for monitoring my node? -A: The Anchor System connects merkle trees on different blockchains using a graph-like framework, allowing anchors to maintain the latest state of their neighboring anchors. This interconnectedness enables users to prove the existence of data in any anchor from any anchor, satisfying the properties of liveness and safety. +Monitoring is critical for success as a node operator. See our full Monitoring guide at https://docs.webb.tools/docs/node/monitoring/quickstart// -**Q: What role do relayers play in the Webb Protocol, and how do they contribute to the overall security of the system?** +## What are the KPIs I should be monitoring? -A: Relayers in the Webb Protocol serve as multi-faceted oracles, data relayers, and protocol governance participants. They relay information for a connected set of anchors on a bridge, updating each anchor's state and allowing applications to reference data stored across connected anchors. By fulfilling their roles, relayers enhance the overall security of the system. +The main key performance indicator for a node operator is the number of blocks produced. The Prometheus metric for this is called substrate_proposer_block_constructed_count. -**Q: Can you explain the Distributed Key Generation (DKG) protocol and its significance in ensuring the safety and liveness of the Anchor System?** +## How should I set up alerting? -A: The DKG protocol governs the Anchor System by acting as a security tool. Trust is placed in the DKG to sign the data it is meant to sign, ensuring bridge updates are valid. The protocol guarantees the safety and liveness of the Anchor System, maintaining its ability to be updated in a partially-synchronous environment while ensuring all updates are valid. +Alerting is critical for your success as a node operator, see our full guide to using our recommended AlertManager at https://docs.webb.tools/docs/node/monitoring/alert-manager/ -## Cross-Chain and Asset Transfers +## What is the failover process if my primary node is down? -**Q: What are the benefits of using Tangle Network** +When the primary server is down, the best way to perform a failover to the backup server is to perform a key association update. Each server should have a unique set of keys already. Run the setKeys author mapping extrinsic. You can follow the Mapping Extrinsic instructions and modify the instructions to use the setKeys extrinsic. -A: Tangle Network employs a set of technologies that faciliate secure and private governance and easy bridging of cross-chain and private applications, in ways that improve the privacy of all applications that connect. +## What should I look for in the logs? -**Q: What advantages does Hubble Bridge offer for users?** +For full support, see our guides on logging at https://docs.webb.tools/docs/node/monitoring/loki/. -A: Hubble Bridge offers an easy-to-use interface for privately moving assets cross-chain, leveraging Webb's Shielded Asset Protocol for secure and private transactions. This allows users to maintain privacy while transferring assets between blockchains efficiently. +## How much stake do I need to become a validator in the active set? -## Collaboration, Governance, and Platform +Per era, the NPoS system selects a certain number of nodes with the most TNT to validate. Therefore, the minimum amount required to become an active nominator and earn rewards may change from era to era. You can check the active validator set's stake at https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Ftangle-standalone-archive.webb.tools#/staking -**Q: What are the latest innovations and research in the field of privacy and blockchain that Webb Protocol is working on?** +## How do I set an identity on my account? -A: Webb Protocol is continually working on innovations in privacy and blockchain, focusing on areas such as zero-knowledge proofs, cross-chain privacy solutions, secure messaging, and privacy-preserving identity systems. +Setting an identity on-chain will help to identify your node and attract delegations. You can set an identity by following the instructions on Polkadot's Identity Documentation at https://wiki.polkadot.network/docs/learn-identity diff --git a/pages/docs/learn/_meta.json b/pages/docs/learn/_meta.json deleted file mode 100644 index 52396d45..00000000 --- a/pages/docs/learn/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "webb-protocol": "Webb Protocol on Tangle", - "incentives": "Incentives, Staking and Slashing", - "understanding-dkg-tangle": "Intro to Distributed Key Generation (DKG)", - "distributed-key-gen": "DKG In-Depth", - "tss-governance": "TSS In-Depth", - "addresses": "Tangle Addresses" -} diff --git a/pages/docs/learn/distributed-key-gen.mdx b/pages/docs/learn/distributed-key-gen.mdx deleted file mode 100644 index ce4548e5..00000000 --- a/pages/docs/learn/distributed-key-gen.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: DKG -description: Overview of a distributed key generation protocol for governing Webb applications. ---- - -import DKGKeygenImages from '../../../components/images/DKGKeygenProtocol' -import DKGSigningImages from '../../../components/images/DKGSigningProtocol' -import Callout from "../../../components/Callout"; - -# Distributed Key Generation Protocol - -This page will provide an overview of the Distributed Key Generation (DKG) protocol, what it is, -its intended use, and how it interacts with the wider system. - -The primary purpose of the DKG protocol is to govern the Anchor System. More precisely, the DKG -act as a security instrument to the Anchor System, that is, we say that the bridge updates are -valid if they are signed by the DKG. The security of the system then rests on the DKG signing the -actual data that it is meant to sign. Effectively, trust is placed in the DKG. - -## What is a DKG - -A [DKG](https://en.wikipedia.org/wiki/Distributed_key_generation) stands for a distributed key -generation protocol. It is a cryptographic multi-party protocol in which multiple parties -contribute to the creation of a shared public and private key. This keypair can then be used -for different use cases such as signing and encryption. We call the output of these use cases -threshold signatures and threshold encryptions respectively. In the Webb ecosystem, our DKG is -primarily used for generating threshold signatures. It is comprised of two protocols that each -network participants runs independently: - -1. Threshold-key-generation -2. Threshold-signature-scheme - -The (1) distributed key generation protocol takes a secret parameter as input, and outputs the -private signing key (sk) and public key (pk). The returned private signing key (sk) is only a -share of the private key, where the values of all returned private signing key shares constitute -a (t,n) threshold secret sharing of the private signing key. - - - -The (2) distributed signing protocol takes the private signing key (sk) of each network participant, -and the message to be signed (m) as inputs. The output is a valid signature. The public input message -are updates (proposals) that are being signed using a threshold-signature-scheme. - - - -The DKG makes use of these distributed key generation and signing protocols to govern distributed applications, -namely the Anchor System. Each distributed application in question has a variety of parameters it needs to -govern. These parameters can be as simple as individual integer values or byte array or as complicated as -entries in a key/value storage map. - -Distributed applications using the DKG define a protocol for handling signed messages. After verifying the -signature of such a message, the application handles the message contents by mutating its internal state -with the newly received data. - -We additionally utilize any number of pre-processing protocols for decided what the DKG signs with the -purpose of improving the security of the end-user applications. Since we trust signatures from the DKG -without fault, we must ensure messages proposed for signing are not proposed maliciously. An example of -such a system is a majority voting protocol, i.e. that a majority of parties signal validity over a -message before the message is processed by the DKG. - -## Want to learn more? - -- [One Round Threshold ECDSA with Identifiable Abort](https://eprint.iacr.org/2020/540.pdf) - -## Contribute to the Webb DKG Protocol - -We are actively making improvements to the Webb DKG Protocol. Check out the below DKG repository and source documentation to start. Have feedback to share about a Webb -relayer? We want to hear from you, share your thoughts [here](https://github.com/webb-tools/feedback/discussions/categories/dkg-feedback). - - - Please keep in mind that this repo is in active development, and may not be fully functional. If you find a bug, please report it [here](https://github.com/webb-tools/dkg-substrate/issues/new/choose). - diff --git a/pages/docs/learn/incentives.mdx b/pages/docs/learn/incentives.mdx deleted file mode 100644 index 68dcd187..00000000 --- a/pages/docs/learn/incentives.mdx +++ /dev/null @@ -1,31 +0,0 @@ -# Tangle Network Incentives - -Tangle Network is built on, Substrate, a powerful framework developed by Parity Technologies for creating blockchains. It comes with many built-in functionalities, allowing developers to customize their blockchain with an array of features. Among these features, staking and slashing play crucial roles in ensuring the security and robustness of Substrate-based networks. - -## Staking - -Staking is a system used by proof-of-stake (PoS) blockchains to secure the network, incentivize behavior, and distribute rewards. In Substrate, a number of nodes, known as validators, are selected to produce blocks and confirm transactions. Users can participate as: - -- **Validators**: Validators are responsible for proposing new blocks and validating proposed blocks. They need to be highly secure and continuously online. Validators stake their own tokens and can receive tokens from nominators. - -- **Nominators**: Nominators support validators by staking tokens on them. They share in the rewards and risks of validators, without needing to run a node themselves. - -Validators and nominators are rewarded with new tokens generated by the network, proportional to the amount of tokens they have staked. - -## Slashing - -To ensure validators behave properly, Substrate uses a mechanism known as slashing. If a validator misbehaves, a portion (or all) of their staked tokens are confiscated ("slashed") by the network. There are several types of misbehavior that can lead to slashing: - -- **Equivocation**: Equivocation occurs when a validator signs two or more conflicting blocks at the same height in the chain. It is considered a severe misbehavior as it could cause a fork in the network. - -- **Offline Validators**: Validators are expected to be online and participating in consensus. Validators who are offline for an extended period can be slashed. - -- **Malicious Behavior**: Any malicious actions against the network, like trying to manipulate consensus or carry out an attack, can result in slashing. - -## Misbehavior Reporting - -Substrate also includes mechanisms for reporting misbehavior. Any network participant can submit proof of validator misbehavior to the chain. If the proof is valid, the validator is slashed, and the reporter is usually rewarded with a portion of the slashed amount. - -## Malicious Signing - -A validator signing arbitrary or malicious messages is another significant misbehavior. This can include signing a message that would lead to equivocation or attempting to manipulate consensus. The penalty for malicious signing is typically severe, often resulting in the slashing of the validator's entire stake. diff --git a/pages/docs/learn/tss-governance.mdx b/pages/docs/learn/tss-governance.mdx deleted file mode 100644 index 4ef5138b..00000000 --- a/pages/docs/learn/tss-governance.mdx +++ /dev/null @@ -1,38 +0,0 @@ -# Threshold Signature Scheme (TSS) in Webb Protocol: Enhancing Bridge Governance - -## Introduction - -The Threshold Signature Scheme (TSS) plays a critical role in the Webb Protocol, an ecosystem for cross-chain and private dApps. One of the core components of the protocol is the private and multi-chain Hubble bridge, which facilitates seamless interoperability between different blockchains. In this document, we explore the problem that TSS solves and its significance in enhancing bridge governance specifically within the Webb Protocol ecosystem. - -## Bridge Governance - -Bridge governance presents a challenge when it comes to updating the state of bridge contracts with the corresponding parties on the other side of the bridge. Traditional approaches rely on trust in a single entity or a small group of participants to execute these updates. However, this centralized approach raises concerns regarding security, integrity, and potential manipulation of the bridge's state. - -## Solution: Decentralizing Trust with Threshold Signature Scheme (TSS) - -The Webb Protocol addresses the challenge of bridge governance by leveraging the power of the Threshold Signature Scheme. TSS decentralizes trust and introduces a robust mechanism for executing updates to the set of bridge contracts across different chains. - -Let's delve into the key advantages and improvements offered by TSS in the Webb Protocol context: - -1. Enhanced Security: - - - TSS utilizes a threshold of signatures (t+1) from a participating group of (t,n) parties. - - This distributed approach significantly reduces the risk of a single point of failure, collusion, or malicious behavior. - -2. Decentralization and Trustlessness: - - - TSS enables the Webb Protocol to achieve a decentralized bridge governance model. - - The (t,n) threshold can accommodate a large number of participants, ensuring a diverse and decentralized network of validators and signers. - -3. Resilience to Attacks: - - - TSS mitigates potential attacks, such as collusion or compromise of a single party. - - As long as the minimum threshold (t) is met, the system remains secure and resilient. - -4. Scalability and Flexibility: - - The flexibility of TSS allows the Webb Protocol to adapt and scale according to its evolving needs. - - The (t,n) threshold can be adjusted within certain limits to strike a balance between decentralization and performance. - -## Conclusion - -The incorporation of the Threshold Signature Scheme (TSS) within the Webb Protocol's bridge governance brings significant improvements in terms of security, decentralization, and resilience. TSS enables the protocol to execute updates to bridge contracts with the involvement of multiple parties, thereby decentralizing trust and mitigating risks associated with centralized approaches. By leveraging TSS, the Webb Protocol paves the way for a more secure and trustless environment specifically for cross-chain dApps, empowering users and fostering innovation in the blockchain space. diff --git a/pages/docs/learn/understanding-dkg-tangle.mdx b/pages/docs/learn/understanding-dkg-tangle.mdx deleted file mode 100644 index 49933d3c..00000000 --- a/pages/docs/learn/understanding-dkg-tangle.mdx +++ /dev/null @@ -1,74 +0,0 @@ -# Understanding DKG in Tangle Network - -import DKGRotationImages from '/components/images/DKGRotation' -import DKGReputationImages from '/components/images/DKGReputation' - -## Authority Selection - -The authority selection system for DKG authorities uses a simple reputation mechanism for selecting the best set -of authorities to participate in the key generation and signing protocols. The integer thresholds for keygen authorities -and signing authorities are set and governed on-chain and directly correspond to the number of DKG clients that will -participate in either protocols. - -For a keygen threshold of **_n_** and a signing threshold of **_t_**, we take the top-**_n_** authorities on chain by -reputation. Out of these **_n_** keygen authorities, **_t+1_** of them are selected for signing. The keygen set remains -fixed over the course of the session, whereas the signing set can change amidst misbehaviours in signing protocol participation. - -### Reputation Calculation - -The `pallet-dkg-metadata` is responsible for calculating and maintaining the reputation scores of all active validators. Reputation serves as a metric to assess and evaluate the authorities, taking into account the number of valid keygen operations performed by the authority and any reported misbehaviors. - -The misbehaviour reporting process is based on an honest-threshold assumption. If DKG authorities misbehave off-chain, any observing authority can submit a report against the offending authority. Once a threshold number of reports are submitted, the offending authority will experience a loss of reputation. The reputation map is used by each DKG authority to ensure that every authority can generate a deterministic signing set for threshold signing protocols. Initially, the signing set consists of the top `t` DKG authorities according to their reputation. - -The formula for updating reputation based on misbehaviour is as follows: - -``` -AUTHORITY_REPUTATION = DECAY_PERCENTAGE * AUTHORITY_REPUTATION -``` - -## Jailing authorities - -For each instance of misconduct that is verified and reported to an authority, the implicated authority will be temporarily suspended or "jailed" for a specific number of sessions. During this suspension, the authority will not be included in the selection process for the authority selection set. This serves as a punitive measure against malicious behaviour. The authority may be reinstated after a predetermined period of time has passed. - - - -## Key rotation - -The DKG required network participants to rotate their shared private signing keys in an effort to keep the -network secure. On a new session, the new authorities (from validators) are selected and the -next authorities are selected. - -1. These next authorities run **_keygen_** protocol discussed above and output a new group keypair on-chain, - denoted `next_dkg_public_key`. -2. The current authorities (having already run this process in the step before) see this event and if it is time - to refresh, they begin to sign the `next_dkg_public_key` with their key, the `dkg_public_key`. -3. The signature from the active keypair of the next keypair is posted on-chain. -4. Once this signature is posted, anyone can propagate it. - - Any relayer. - - Any user who wants to update the governor of their contract. - -### Key rotation flow - -The on-chain keys are rotated every session. This is done so that the DKG validators and network validators are -aligned and new validators can leave and join as desired. At the end of the session's target period, the Tangle -runtime triggers the process to generate a new key. A new distributed key generation protocol executes with the -next on-chain authorities. These authorities then work together to generate a new key. The active (current) authorities -then sign the newly generated key with a threshold signature and post it on-chain to complete a successful key rotation. - - - -## Misbehaviour Reporting & Reputation - -Misbehaviour reporting follows an oracle-based approach. The DKG protocol we utilize has identifiable aborts, meaning it is possible to identify the party misbehaving during the protocol’s execution. While every honest party sees this misbehaviour, it is tricky to identify on-chain, as it would require running the protocol itself on-chain and verifying the misbehaviour proof. - -Instead of pushing proofs of misbehaviour on-chain, we utilize a threshold voting-based approach. For a threshold **t** and offender **o**, if **t** parties report the same misbehaviour containing the type of misbehaviour, the round of misbehaviour, and the offending authority, then the party’s reputation reduces according to the function: - -``` -reputation(o) = α * reputation(o) -``` - -When a good action occurs, such as successfully rotating keys or signing a proposal and submitting it on-chain, the reputation increases according to the function: - -``` -reputation(o) = α * reputation(o) + 1,000,000,000 -``` diff --git a/pages/docs/learn/webb-protocol.mdx b/pages/docs/learn/webb-protocol.mdx deleted file mode 100644 index 8b2a1e38..00000000 --- a/pages/docs/learn/webb-protocol.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "Tangle Network and Webb Protocol" ---- - -# Guide to Tangle Network and Webb Protocol - -Tangle Network and Webb Protocol join forces to enhance privacy, interoperability, and scalability for decentralized applications (dApps). This guide provides a detailed overview of Webb Protocol, its core components, and its role in the Tangle Network ecosystem. - -## Overview - -Webb Protocol aims to resolve privacy and scalability issues that have become ubiquitous in the world of decentralized applications. It achieves this by offering a privacy-focused, interoperable, and scalable framework that interacts with various blockchains. - -Tangle Network, a Substrate-based platform fully compatible with Ethereum, hosts and supports the governance of this transformative protocol to offer advanced privacy options and scalability to developers and users. - -## Core Components of Webb Protocol - -Webb Protocol introduces two pivotal components - the Anchor System and the Distributed Key Generation (DKG) protocol. - -### Anchor System - -The Anchor System is a smart contract-based, graph-like framework that maintains an interconnected network of blockchains, referred to as anchors. Each anchor features an on-chain Merkle tree and an edge list to manage and update linked metadata, enabling cross-chain applications with potential privacy features. - -The system guarantees Liveness and Safety— ensuring the continuous update of all anchors and validating all anchor updates. Oracle and Relayer Networks in a partially-synchronous environment connect the various blockchains and preserve user privacy by delegating proof submission through an overlay network. - -### Distributed Key Generation (DKG) protocol - -The DKG protocol is the security foundation of Webb Protocol. It validates updates in the Anchor System using a shared key pair. This protocol employs a cryptographic multi-party mechanism to generate a shared public and private key for threshold signatures and threshold encryptions. It encompasses two significant protocols— the threshold-key-generation protocol, and the threshold-signature-scheme or the distributed signing protocol. This secure framework handles signed messages and ensures the absence of malicious proposals. - -## Operations within a Proof of Stake (PoS) Blockchain - -Webb Protocol operates within a PoS blockchain protocol. It adapts to changing validator set sizes and maintains security with the execution of the Key Rotation Protocol and Misbehaviour Protocol during each session. The system uses standardized messages to facilitate seamless communication within the system. - -## Unique Features - -Webb Protocol employs a hybrid threshold and light-client validation protocol. It allows for threshold-signed messages to be deemed valid while enforcing message signing only when they can be verified as true against a light client. diff --git a/pages/docs/network-information-configuration.mdx b/pages/docs/network-information-configuration.mdx index 182c2914..eeb6f2b5 100644 --- a/pages/docs/network-information-configuration.mdx +++ b/pages/docs/network-information-configuration.mdx @@ -43,7 +43,6 @@ Before starting development on our TestNets, fund your account with tTNT tokens, | Network | Source For Tokens | | -------------- | -------------------------- | | Tangle Testnet | https://faucet.webb.tools/ | -| Tangle Mainnet | To be announced | ## Development Tools @@ -59,7 +58,7 @@ As an Ethereum-compatible, Substrate-based chain, Tangle Network allows for the ## Participating in the Tangle Network -Joining the Tangle Network community is easy. You can run a node, develop a Dapp, or contribute to our open-source codebase. For more information, visit our [Node Operation Guide](/docs/ecosystem-roles/role-overview/), and [Contribution Guide](/docs/contribute). +Joining the Tangle Network community is easy. You can run a node, develop a Dapp, or contribute to our open-source codebase. For more information, visit our [Node Operation Guide](/docs/node/quickstart/), and [Contribution Guide](/docs/contribute). ## Looking Ahead: Mainnet Launches diff --git a/pages/docs/node/docker-node.mdx b/pages/docs/node/docker-node.mdx index 6579d203..3b074020 100644 --- a/pages/docs/node/docker-node.mdx +++ b/pages/docs/node/docker-node.mdx @@ -9,7 +9,7 @@ import { Tabs } from 'nextra/components'; # Deploying a Tangle Network Node with Docker A Tangle Network node can be spun up quickly using Docker. **This guide covers both Full Node and Validator Node deployment.** . For more information on installing Docker, -please visit the official Docker [docs](https://docs.docker.com/get-docker/). Make sure that your system meets the requirements which can read [here](https://docs.webb.tools/docs/ecosystem-roles/validator/requirements/). +please visit the official Docker [docs](https://docs.docker.com/get-docker/). Make sure that your system meets the requirements which can read [here](docs/node/hardware/). ## Setup the Docker Environment @@ -21,7 +21,7 @@ set their keys, fetch the applicable chainspec and run the start command to get ```sh filename="pull" copy # Only use "main" if you know what you are doing, it will use the latest and maybe unstable version of the node. -docker pull ghcr.io/webb-tools/tangle/tangle-standalone:main +docker pull ghcr.io/webb-tools/tangle/tangle:main ``` ### 2. Create a local directory to store the chain data: @@ -55,7 +55,7 @@ Please make a reference where you have stored this `json` file as we will need i To start the node run the following command: ```sh filename="docker run" copy -docker run --rm -it -v /var/lib/tangle/:/data ghcr.io/webb-tools/tangle/tangle-standalone:main \ +docker run --rm -it -v /var/lib/tangle/:/data ghcr.io/webb-tools/tangle/tangle:main \ --chain tangle-testnet \ --name="YOUR-NODE-NAME" \ --base-path /data \ @@ -97,7 +97,7 @@ should paste your SURI when the command asks for it. ```sh filename="Acco" copy # it will ask for your suri, enter it. docker run --rm -it --platform linux/amd64 --network="host" -v "/var/lib/data" \ -ghcr.io/webb-tools/tangle/tangle-standalone:main \ +ghcr.io/webb-tools/tangle/tangle:main \ key insert --base-path /var/lib/tangle/ \ --chain /data/chainspecs/tangle-standalone.json \ --scheme Sr25519 \ @@ -108,7 +108,7 @@ ghcr.io/webb-tools/tangle/tangle-standalone:main \ ```sh filename="Babe" copy docker run --rm -it --platform linux/amd64 --network="host" -v "/var/lib/data" \ -ghcr.io/webb-tools/tangle/tangle-standalone:main \ +ghcr.io/webb-tools/tangle/tangle:main \ key insert --base-path /var/lib/tangle/ \ --chain /data/chainspecs/tangle-standalone.json \ --scheme Sr25519 \ @@ -119,18 +119,18 @@ ghcr.io/webb-tools/tangle/tangle-standalone:main \ ```sh filename="Imonline" copy docker run --rm -it --platform linux/amd64 --network="host" -v "/var/lib/data" \ -ghcr.io/webb-tools/tangle/tangle-standalone:main \ +ghcr.io/webb-tools/tangle/tangle:main \ key insert --base-path /var/lib/tangle/ \ --chain /data/chainspecs/tangle-standalone.json \ --scheme Sr25519 \ --key-type imon ``` -**Role Key** +**Role Keys** -```sh filename="DKG" copy +```sh filename="Role" copy docker run --rm -it --platform linux/amd64 --network="host" -v "/var/lib/data" \ -ghcr.io/webb-tools/tangle/tangle-standalone:main \ +ghcr.io/webb-tools/tangle/tangle:main \ tangle-standalone key insert --base-path /data \ --chain /data/chainspecs/tangle-standalone.json \ --scheme Ecdsa \ @@ -141,7 +141,7 @@ ghcr.io/webb-tools/tangle/tangle-standalone:main \ ```sh filename="Grandpa" copy docker run --rm -it --platform linux/amd64 --network="host" -v "/var/lib/data" \ -ghcr.io/webb-tools/tangle/tangle-standalone:main \ +ghcr.io/webb-tools/tangle/tangle:main \ tangle-standalone key insert --base-path /data \ --chain /data/chainspecs/tangle-standalone.json \ --scheme Ed25519 \ @@ -164,7 +164,7 @@ To start the node run the following command: ```sh filename="docker run" copy docker run --platform linux/amd64 --network="host" -v "/var/lib/data" --entrypoint ./tangle-standalone \ -ghcr.io/webb-tools/tangle/tangle-standalone:main \ +ghcr.io/webb-tools/tangle/tangle:main \ --base-path=/data \ --chain tangle-testnet \ --name="YOUR-NODE-NAME" \ @@ -246,10 +246,10 @@ The upgrade process is straightforward and is the same for a full node. sudo docker stop `CONTAINER_ID` ``` -2. Get the latest version of Tangle from the Tangle GitHub Release [page](https://github.com/webb-tools/tangle/pkgs/container/tangle%2Ftangle-standalone) +2. Get the latest version of Tangle from the Tangle GitHub Release [page](https://github.com/webb-tools/tangle/pkgs/container/tangle%2Ftangle -3. Pull the latest version of Tangle binary by doing `docker pull ghcr.io/webb-tools/tangle/tangle-standalone:{VERSION_CODE}`. - Example, if the latest version of Tangle is v0.1.2, then the command would be `docker pull ghcr.io/webb-tools/tangle/tangle-standalone:v0.1.12` +3. Pull the latest version of Tangle binary by doing `docker pull ghcr.io/webb-tools/tangle/tangle:{VERSION_CODE}`. + Example, if the latest version of Tangle is v0.1.2, then the command would be `docker pull ghcr.io/webb-tools/tangle/tangle:v0.1.12` 4. Restart the tangle container and you should have the updated version of the client. diff --git a/pages/docs/node/flags.mdx b/pages/docs/node/flags.mdx index 1350041e..7c8e1e23 100644 --- a/pages/docs/node/flags.mdx +++ b/pages/docs/node/flags.mdx @@ -77,7 +77,7 @@ Confirm the path and image with your image name: ``` docker run --network="host" -v "/var/lib/data:/data" -u $(id -u ${USER}):$(id -g ${USER}) -ghcr.io/webb-tools/tangle/tangle-standalone:main --help +ghcr.io/webb-tools/tangle/tangle:main --help ``` ### Using Systemd: @@ -88,7 +88,7 @@ If you used the binary directly: If you compiled the binary: -`./target/release/tangle-standalone-YOUR-VERSION-HERE> --help` +`./target/release/tangle-YOUR-VERSION-HERE> --help` Currently, your release may be one the following. diff --git a/pages/docs/node/monitoring/alert-manager.mdx b/pages/docs/node/monitoring/alert-manager.mdx index 26f849ae..26032b2f 100644 --- a/pages/docs/node/monitoring/alert-manager.mdx +++ b/pages/docs/node/monitoring/alert-manager.mdx @@ -9,7 +9,7 @@ import Callout from "../../../../components/Callout"; # Alert Manager Setup The following is a guide outlining the steps to setup AlertManager to send alerts when a Tangle node or DKG is being disrupted. If you do not have Tangle node setup yet, please -review the **Tangle Node Quickstart** setup guide [here](/docs/ecosystem-roles/validator/quickstart/). +review the **Tangle Node Quickstart** setup guide [here](/docs/node/quickstart/). In this guide we will configure the following modules to send alerts from a running Tangle node. diff --git a/pages/docs/node/monitoring/grafana.mdx b/pages/docs/node/monitoring/grafana.mdx index 8d69c3e0..11d9a187 100644 --- a/pages/docs/node/monitoring/grafana.mdx +++ b/pages/docs/node/monitoring/grafana.mdx @@ -9,7 +9,7 @@ import Callout from "../../../../components/Callout"; # Grafana Setup The following is a guide outlining the steps to setup Grafana Dashboard to visualize metric data for a Tangle node. If you do not have Tangle node setup yet, please -review the **Tangle Node Quickstart** setup guide [here](/docs/ecosystem-roles/validator/quickstart/). +review the **Tangle Node Quickstart** setup guide [here](/docs/node/quickstart/). In this guide we will configure the following modules to visualize metric data from a running Tangle node. diff --git a/pages/docs/node/monitoring/loki.mdx b/pages/docs/node/monitoring/loki.mdx index 9180b220..722660e8 100644 --- a/pages/docs/node/monitoring/loki.mdx +++ b/pages/docs/node/monitoring/loki.mdx @@ -9,7 +9,7 @@ import Callout from "../../../../components/Callout"; # Loki Log Management The following is a guide outlining the steps to setup Loki for log management of a Tangle node. If you do not have Tangle node setup yet, please -review the **Tangle Node Quickstart** setup guide [here](/docs/ecosystem-roles/validator/quickstart/). +review the **Tangle Node Quickstart** setup guide [here](/docs/node/quickstart/). In this guide we will configure the following modules to scrape metrics from the running Tangle node. diff --git a/pages/docs/node/monitoring/prometheus.mdx b/pages/docs/node/monitoring/prometheus.mdx index 21f9eacc..e2b5d652 100644 --- a/pages/docs/node/monitoring/prometheus.mdx +++ b/pages/docs/node/monitoring/prometheus.mdx @@ -9,7 +9,7 @@ import Callout from "../../../../components/Callout"; # Prometheus Setup The following is a guide outlining the steps to setup Prometheus to monitor a Tangle node. If you do not have Tangle node setup yet, please -review the **Tangle Node Quickstart** setup guide [here](/docs/ecosystem-roles/validator/quickstart/). It is important to note that +review the **Tangle Node Quickstart** setup guide [here](/docs/node/quickstart/). It is important to note that this guide's purpose is to help you get started with monitoring your Tangle node, not to advise on how to setup a node securely. Please take additional security and privacy measures into consideration. diff --git a/pages/docs/node/node-software.mdx b/pages/docs/node/node-software.mdx index 88bb7b61..7a0969b9 100644 --- a/pages/docs/node/node-software.mdx +++ b/pages/docs/node/node-software.mdx @@ -148,7 +148,7 @@ You will now have the `tangle-standalone` binary built in `target/release/` dir Once installed, you can begin syncing your node by running the following command. **Your path may vary depend on whether you used the binary, or built from source**: ```sh filename="Syncing node" copy -./target/release/tangle-standalone +./target/release/tangle ``` Once your node has fully syncronized with Tangle Network you may proceed to setup the diff --git a/pages/docs/node/quicknode.mdx b/pages/docs/node/quicknode.mdx index 1e2b97a2..352a75fc 100644 --- a/pages/docs/node/quicknode.mdx +++ b/pages/docs/node/quicknode.mdx @@ -6,11 +6,11 @@ description: Run a Tangle Validator node using systemd. # Tangle Validator Quickstart **Caution:** The following guide is only meant as a quickstart for anyone looking to run a tangle node with minimal -config, this guide uses automated keys and it is not recommended to run a validator using this setup long term, refer to [advanced](/docs/ecosystem-roles/validator/systemd/validator-node/) guide +config, this guide uses automated keys and it is not recommended to run a validator using this setup long term, refer to [advanced](/docs/node/systemd/) guide for a more secure long term setup. Before following this guide you should have already set up your machines environment, installed the dependencies, and -compiled the Tangle binary. If you have not done so, please refer to the [Requirements](/docs/ecosystem-roles/validator/requirements/) page. +compiled the Tangle binary. If you have not done so, please refer to the [Requirements](/docs/node/hardware/) page. ## Standalone Testnet @@ -22,10 +22,10 @@ Use the latest release version in the url in place of ``, you can visit wget https://github.com/webb-tools/tangle/releases/download//tangle-testnet-linux-amd64 ``` -For example, at the time of writing this document, the latest release is v0.4.7 and the link would be as follows +For example, at the time of writing this document, the latest release is v0.6.1 and the link would be as follows ``` -wget https://github.com/webb-tools/tangle/releases/download/v0.4.7/tangle-testnet-linux-amd64 +wget https://github.com/webb-tools/tangle/releases/download/v0.6.1/tangle-testnet-linux-amd64 ``` ### 2. Start the node binary @@ -85,6 +85,6 @@ If the node is running correctly, you should see an output similar to below: make sure to note down and keep this safely, in case you need to migrate or restart your node, these keys are essential. Congratulations! You have officially setup an Tangle Network node. The quickstart is only meant as a quickstart for anyone looking to run a tangle node with minimal -config, this guide uses automated keys and it is not recommended to run a validator using this setup long term, refer to [advanced](/docs/ecosystem-roles/validator/systemd/validator-node/) guide +config, this guide uses automated keys and it is not recommended to run a validator using this setup long term, refer to [advanced](/docs/node/systemd/) guide for a more secure long term setup.. If you are interested in learning how to setup monitoring for your node, please refer to the [monitoring](../monitoring/quickstart.mdx) page. diff --git a/pages/docs/node/systemd.mdx b/pages/docs/node/systemd.mdx index eba0a96f..692ce613 100644 --- a/pages/docs/node/systemd.mdx +++ b/pages/docs/node/systemd.mdx @@ -9,7 +9,7 @@ import { Tabs } from 'nextra/components' You can run your **full** or **validator** node as a systemd process so that it will automatically restart on server reboots or crashes, helping to avoid getting slashed. This guide now includes additional steps for setting up dependencies and Rust configuration, ensuring a smoother setup process. -Before following this guide, ensure that your machine's environment is set up and the Tangle binary is compiled. If you haven't done so, please refer to the [Requirements](https://docs.webb.tools/docs/ecosystem-roles/validator/requirements/) page. +Before following this guide, ensure that your machine's environment is set up and the Tangle binary is compiled. If you haven't done so, please refer to the [Requirements](docs/node/hardware/) page. ## Setup @@ -21,10 +21,10 @@ Use the latest release version in the url in place of ``, you can visit wget https://github.com/webb-tools/tangle/releases/download//tangle-testnet-linux-amd64 ``` -For example, at the time of writing this document, the latest release is v0.4.7 and the link would be as follows +For example, at the time of writing this document, the latest release is v0.6.1 and the link would be as follows ``` -wget https://github.com/webb-tools/tangle/releases/download/v0.4.7/tangle-testnet-linux-amd64 +wget https://github.com/webb-tools/tangle/releases/download/v0.6.1/tangle-testnet-linux-amd64 ``` ### 2. Install Dependencies @@ -58,7 +58,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly ```sh filename="mv" copy # Move the tangle-standalone binary to the bin directory (assumes you are in repo root directory) - sudo mv ./target/release/tangle-standalone /usr/bin/ + sudo mv ./target/release/tangle /usr/bin/ ``` Add the following contents to the service configuration file. Make sure to replace the **USERNAME** with the username you created in the previous step, add your own node name, and update @@ -149,7 +149,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly ```sh filename="Acco" copy # it will ask for your suri, enter it. - ./target/release/tangle-standalone key insert --base-path /data/validator/ \ + ./target/release/tangle key insert --base-path /data/validator/ \ --chain ./chainspecs/tangle-standalone.json \ --scheme Sr25519 \ --suri <"12-MNEMONIC-PHARSE"> \ @@ -160,7 +160,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly ```sh filename="Babe" copy # it will ask for your suri, enter it. - ./target/release/tangle-standalone key insert --base-path /data/validator/ \ + ./target/release/tangle key insert --base-path /data/validator/ \ --chain ./chainspecs/tangle-standalone.json \ --scheme Sr25519 \ --suri <"12-MNEMONIC-PHARSE"> \ @@ -171,7 +171,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly ```sh filename="Imonline" copy # it will ask for your suri, enter it. - ./target/release/tangle-standalone key insert --base-path /data/validator/ \ + ./target/release/tangle key insert --base-path /data/validator/ \ --chain ./chainspecs/tangle-standalone.json \ --scheme Sr25519 \ --suri <"12-MNEMONIC-PHARSE"> \ @@ -180,9 +180,9 @@ rustup target add wasm32-unknown-unknown --toolchain nightly **Role Keys** - ```sh filename="DKG" copy + ```sh filename="Role" copy # it will ask for your suri, enter it. - ./target/release/tangle-standalone key insert --base-path /data/validator/ \ + ./target/release/tangle key insert --base-path /data/validator/ \ --chain ./chainspecs/tangle-standalone.json \ --scheme Ecdsa \ --suri <"12-MNEMONIC-PHARSE"> \ @@ -193,7 +193,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly ```sh filename="Grandpa" copy # it will ask for your suri, enter it. - ./target/release/tangle-standalone key insert --base-path /data/validator/ \ + ./target/release/tangle key insert --base-path /data/validator/ \ --chain ./chainspecs/tangle-standalone.json \ --scheme Ed25519 \ --suri <"12-MNEMONIC-PHARSE"> \ @@ -213,7 +213,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly ```sh filename="mv" copy # Move the tangle-standalone binary to the bin directory (assumes you are in repo root directory) - sudo mv ./target/release/tangle-standalone /usr/bin/ + sudo mv ./target/release/tangle /usr/bin/ ``` Add the following contents to the service configuration file. Make sure to replace the **USERNAME** with the username you created in the previous step, add your own node name, and update any paths or ports to your own preference. @@ -330,7 +330,7 @@ rustup target add wasm32-unknown-unknown --toolchain nightly The following is the service configuration file, use this while completing the Full Node guide. - **Note:** To run with evm trace, you should use a binary built with `txpool` flag, refer [requirements](/docs/ecosystem-roles/validator/requirements/) page for more details. + **Note:** To run with evm trace, you should use a binary built with `txpool` flag, refer [requirements](/docs/node/hardware/) page for more details. ```sh filename="full.service" copy sudo tee /etc/systemd/system/full.service > /dev/null << EOF diff --git a/pages/docs/node/troubleshooting.mdx b/pages/docs/node/troubleshooting.mdx index d46c751c..fc1a7efb 100644 --- a/pages/docs/node/troubleshooting.mdx +++ b/pages/docs/node/troubleshooting.mdx @@ -8,18 +8,16 @@ import Callout from '/components/Callout'; ## Troubleshooting -**Logs** +### Logs If you'd like to run the node with verbose logs, you may add the following arguments during initial setup. Adjust the target for the desired logging level (debug | error | info| trace | warn): ```bash --ldkg=debug \ --ldkg_metadata=debug \ --lruntime::offchain=debug \ --ldkg_proposal_handler=debug \ --ldkg_proposals=debug +RUST_LOG=runtime=debug ./target/release/ --dev ``` +Refer substrate [doc](https://docs.substrate.io/test/debug/) for more details + ### P2P Ports Not Open @@ -63,14 +61,6 @@ After installation, ensure you've added /opt/homebrew/bin to your PATH: echo 'export PATH=/opt/homebrew/bin:$PATH' >> ~/.bash_profile ``` -#### Building dkg-substrate - -To build dkg-substrate in --release mode using the aarch64-apple-darwin Rust toolchain, set the required environment variables: - -```bash -echo 'export RUSTFLAGS="-L /opt/homebrew/lib"' >> ~/.bash_profile -``` - #### Dependencies 1. GMP: Ensure the gmp dependency is correctly installed. diff --git a/pages/docs/node/validator/requirements.mdx b/pages/docs/node/validator/requirements.mdx index 8fe30826..1edbf283 100644 --- a/pages/docs/node/validator/requirements.mdx +++ b/pages/docs/node/validator/requirements.mdx @@ -27,7 +27,7 @@ In the future, validators may be able to participate in other forms of reward-wi -2. **Setting Up Validator Infrastructure:** This includes ensuring that the node is properly configured, connected to the network, has the necessary keys set up, etc. Part of this setup will involve generating and injecting session keys (like Babe, Grandpa, etc.) which are crucial for various consensus and validation processes. +2. **Setting Up Validator Infrastructure:** This includes ensuring that the node is properly configured, connected to the network, has the necessary keys set up, etc. Part of this setup will involve generating and injecting session keys (like RoleKey, Babe, Grandpa, etc.) which are crucial for various consensus and validation processes. 3. **Nominating or Registering as a Validator:** After bonding tokens and setting up the validator node, the operator then registers or nominate their node as a validator candidate. This involves submitting a transaction to the network indicating their intention to validate. diff --git a/pages/docs/node/validator/validator-rewards.mdx b/pages/docs/node/validator/validator-rewards.mdx index 62981a9b..e022cc74 100644 --- a/pages/docs/node/validator/validator-rewards.mdx +++ b/pages/docs/node/validator/validator-rewards.mdx @@ -5,7 +5,7 @@ description: A brief overview of Tangle Network rewards and their payout scheme. # Validator Rewards -Running a [validator](validation.mdx) node on the Tangle Network allows you to connect to the network, sync with a bootnode, obtain local access to RPC endpoints, and also author blocks. The network rewards successful validators (users running validator nodes and actively producing blocks) by paying a set amount of network tokens as rewards. Validators are chosen using an algorithm [Babe](https://research.web3.foundation/Polkadot/protocols/block-production/Babe) that works to give every validator in the active set, a chance at authoring a block. +Running a [validator](validation.mdx) node on the Tangle Network allows you to connect to the network, sync with a bootnode, obtain local access to RPC endpoints, and also author blocks. The network rewards successful validators (users running validator nodes and actively producing blocks) by paying a set amount of network tokens as rewards. ## How Rewards are Calculated