X-Talk Overview
Last updated
Last updated
To get an overall Perspective on L1X and X-Talk; watch the video on this link.
X-Talk is a bridgeless infrastructure designed for seamless inter-chain communication. Its primary function is to process, store, and execute event-driven data and payloads, guided by a set of predefined rules specific to each event type. This architecture enables a deterministic application of rules on various types, all facilitated through the X-Talk Flow Contract.
X-Talk Flow Contract includes X-Talk Contract, Event Configuration Contract and Signing-Broadcasting Contract as a subset of the flow contract. These contracts process instructions based on X-Talk messaging standard or instruction sets.
To realise this, X-Talk harnesses the L1X Protocol, a comprehensive protocol suite that includes:
L1X Virtual Machine (VM): Executes the X-Flow contracts.
Networking: Ensures efficient communication within the ecosystem.
Consensus: Ensures all nodes reach agreement on the data's validity.
State Layer: Maintains and manages the state of contracts.
This structure grants X-Talk its layered, modular architecture comprising various node types, each having a distinct role, underpinned by a robust storage layer.
The heart of X-Talk is its X-Talk Rule Engine, which is responsible for the dynamic consensus across multiple levels. The Rule Engine enforces rules specific to each event type, ensuring a seamless flow of cross-chain interactions. It not only maintains the protocol's communication integrity but also its interaction processes' reliability.
Upon storing event data, the system applies these predefined rules to modify the payload. This modification takes into account the client chain's state and the conditions inherent to the L1X contract state. The process culminates in the Get_Payload_To_Sign function. This function synthesises the set rules with business and application logic. For instance, it might produce a sign_payload for an x_chain_method based on a specific state value determination which can be transformed.
XTalk vs Bridge
Number of Contracts
1 (CrossChainSwapFlow)
Multiple (e.g., 3-5)
Contract Complexity
Decentralised
Distributed
State Management
Within the contract
Across multiple contracts
Event Handling
Directly in the contract
Handled by individual specialised contracts
Verification Process
Unified within the single contract
Often split across multiple contracts
Storage Interaction
Direct through load and save methods
Might be spread across different contracts, leading to increased gas costs and complexity
Interoperability
Designed for cross-chain applications
Requires external connectors or oracles for each chain involved
Security Concerns
Decentralised point of failure with less complexity
Multiple points of failure due to distributed nature, but isolates risks
Development Complexity
Lower (single contract development)
Higher (coordination between multiple contracts)
Execution Efficiency
More efficient due to logic with a single Decentralised Contract
Higher Overhead and complexity due to multiple contract interactions
