# Node Architecture & Consensus Mechanism ### **PoX (Proof of X) Network Architecture** TheL1X network comprises two distinct types of nodes: Full Validator Nodes (FVN) and Event Listener Nodes (ELN). FVNs play a pivotal role in network validation, block proposal, consensus participation, and overall network integrity maintenance. ELNs serve as integral components of the X-Talk process, facilitating seamless cross-chain communication across various blockchain networks. ELNs listen, process, and relay events to the broader L1X network for subsequent processing and action. ### **PoX Consensus Mechanism** In the quest for achieving consensus and decentralization, the participation of network participants holds the utmost importance. Trust in the blockchain network and the availability of trusted participants are crucial factors that drive the success and sustainability of any blockchain ecosystem. To address this, we implemented a mechanism that efficiently considers both old and new participants in the PoX consensus. By incorporating parameters such as StakeScore, KinScore, and XScore, we aim to evaluate participants' stake holdings, active involvement, and adherence to security measures. These parameters play a vital role in achieving consensus, promoting decentralization, and ensuring the integrity and security of the network.

Incorporating weightage for each metric within StakeScore and KinScore introduces a crucial layer of flexibility, enabling the system to dynamically adjust to shifting L1X network dynamics. By assigning weights to individual metrics, such as stake holdings, activity levels, and adherence to security measures, the evaluation process becomes more nuanced and responsive. This adaptability allows the PoX consensus mechanism to effectively accommodate changes in participant behaviour, stake distribution, and network conditions over time. Consequently, the weighted approach enhances the system's resilience, promotes fairness, and ensures optimal performance, ultimately contributing to the long-term stability and sustainability of the blockchain ecosystem. Table 1: StakeScore Weightage

Table 2: KinScore Weightage

XScore is the weighted sum of StakeScore and KinScore, where StakeScore encompasses Stake Balance, Stake Age, and Locking Period, while KinScore comprises uptime, participation history, response time, and adherence to security measures. This composite XScore is calculated for all nodes that have staked a minimum balance and are currently available. Those nodes with an XScore exceeding the XScore Threshold become eligible for the subsequent epoch of the consensus process. To preserve privacy and security, homomorphic encryption is applied to XScore, ensuring confidentiality while allowing computation on encrypted data. Subsequently, a randomized algorithm is employed on the homomorphically encrypted XScores to randomly select the block proposer for each epoch, contributing to the fairness and robustness of the consensus mechanism.

### **X-Talk / ELN Consensus Mechanism** To assess the reputation of ELNs in the L1X blockchain network, we utilize three key parameters: \- StakeScore, \- EventScore, and \- XTalkScore. These parameters are crucial for enabling effective X-Talk communication between different blockchain networks. StakeScore considers various aspects such as stake balance, stake age, and locking period. By considering these factors, we can gauge the commitment and reliability of ELNs in supporting the network. EventScore considers their participation history in events and activities relevant to the L1X network. This score provides insights into how actively ELNs contribute to the development and growth of the network. Thus, XTalkScore plays a vital role in evaluating ELNs' ability to facilitate seamless communication across different blockchain networks through X-Talk process.

Adding weightages to StakeScore and EventScore provides a flexible and adaptive approach to handle changing network dynamics, allowing the scoring system to reflect current priorities, balance conflicting objectives, and adapt to the evolving needs of the network and its stakeholders. Table 3: StakeScore Weightage

Table 4: EventScore Weightage

XTalkScore is a composite metric derived from the weighted summation of StakeScore and EventScore. StakeScore itself is determined by a weighted combination of Stake Balance, Stake Age, and Locking Period, while EventScore is a weighted amalgamation of factors such as uptime, event accuracy, processing time, and integration efficiency. XTalkScore computation is applicable to all ELNs meeting the minimum staking requirement and being actively accessible. ELNs surpassing the predetermined Threshold value of XTalkScore qualify for potential selection as Leaders for the X-Talk process, while those falling below serve as listeners without broadcast privileges.

### **FVN Network Framework** L1X is meticulously crafted to deliver unparalleled scalability, efficiency, and adaptability in managing a diverse array of transactions. At its heart lies a sophisticated architecture centered around super clusters, each comprised of numerous clusters. Every cluster is tasked with processing distinct transaction types, strategically distributed for optimal workload handling. This innovative design fosters heightened transaction throughput and maximizes resource efficiency across the L1X network.

### **Transaction Lifecycle** In the context of a Multi-Chain Balancer Pool Transaction, the transaction flow can be outlined as follows: 1\. Initially, a user seeking to deposit USDC obtains X Balancer Pool Tokens (XBPT) and assesses the price impact from the pool maintained by the L1X EVM. 2\. Subsequently, the user adds liquidity on the client chain contract. 3\. Upon liquidity addition, an event is emitted from the L1X contract on the client chain, which is received by ELN listener nodes on the L1X blockchain network. 4\. These ELNs store, verify, schedule, format, and broadcast the event to the FVNs of the L1X network. This initiates the lifecycle of contract execution within the L1XVM. The L1XVM registers the event details, including a UUID, to the L1X EVM Contract Liquidity Collection Register. 5\. Depending on the transaction type (Join, Exit, or Swap), the Balancer Handler Execution Contract executes cross-contract cross-VM calls to perform the corresponding action. 6\. The Liquidity Pool on the L1X EVM then issues XBPT tokens to the receiver address, with the BPT issuance flag set in the L1X EVM Contract Liquidity Collection Register. 7\. Finally, calculations are performed, and the Distributor Contract distributes the tokens accordingly.

MultiChain Balancer Pool Transactional Flow Model

**A deep dive into the L1X Consensus Mechanism and Node infrastructure can be viewed in this video.** {% embed url="" %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://l1x-sdk.gitbook.io/l1x-foundation/~/changes/LFZDsepHxDLzljHk3CxA/node-hosting-on-l1x/node-architecture-and-consensus-mechanism.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.