XMTP Labs is taking a phased approach toward architectural and logical decentralization of the network. The mission is to make sure the network is permissionless: owned by infrastructure providers and users that choose to participate, which can be anyone. Taking it further, these permissionless infrastructure providers and users will become symbiotic, since one can’t exist without the other.
What does decentralization mean when it comes to XMTP?
Decentralization means two things:
- Decentralization of node operators: Multiple, uncorrelated node operators hold copies of the data in the XMTP network
- Decentralization of network value: the value generated by the network is distributed to participants according to their level of network contribution. This can be node providers, users, developers, governance, etc
Why is decentralization of XMTP so important?
- XMTP’s vision is to ensure that secure, private, and portable communication is a public good.
- Decentralization helps us fulfill this vision by creating a network that is self-governed (no central party is making the decisions) and permissionless (operators, developers, and users can participate in the network as they see fit) all while keeping user data secure, private, and portable.
Why is
xmtpd
(XMTP daemon) such a crucial milestone for us?- XMTPD (this is the software that nodes run to be a part of the network) allows XMTP Labs to experiment with Merkle-CRDT based replication and message relay (how messages propagate or gossip through the network).
- XMTP Labs is now providing those attributes directly with XMTPD which sets XMTP Labs up to continue validating implementations and methods for creating a decentralized network.
- XMTPD is currently experimental but anyone can run a testnet node today with it.
- Once Phase 1: Data Plane of decentralization is complete, XMTP Labs can onboard a trusted node operator partner to run a testnet node.
What does it mean that we’re building in public?
- XMTP Labs shares an initial roadmap for decentralization, that the community can respond to and iterate on.
- XMTP Labs shares the design of the decentralized network through a whitepaper
- XMTP Labs shares the codebase through public repos for XMTPD and any relevant decentralization work
What are the next steps we’re taking to continue to decentralize?
There are five phases to decentralization. We are currently in phase 1.
Phase 1: Data plane
This phase validates that XMTPD supports a reliable method for data replication between nodes, authorization of senders while maintaining user privacy, and a logic for retaining and pruning data held by the nodes.
- Implement full nodes with Merkle CRDT data synchronization and storage to ensure reliable data replication.
- Implement authorization for publishing.
- Onboard the first trusted external node operator on testnet.
- Implement data retention and eviction.
Phase 2: Control plane
This phase introduces smart contracts to provide stronger consistency for managing controls such as postage fees, advertised identities, or staking in the network.
- Implement and deploy Topics Contract for managing topic metadata.
- Implement Dispatcher for clients interacting with the control plane.
- Implement initial full node registration and staking via Consensus Contract.
- Implement and deploy Contacts Contract for managing advertised contacts.
Phase 3: Consensus and economic mechanisms
This phase introduces ways for node operators to be paid which incentivizes them run a node
- Integrate message fees via off-chain payment channels.
- Implement fee pooling and rewards distribution.
- Implement refundable fees.
Phase 4: Public mainnet
This phase is taking all of the testing from the previous phases and flipping the switch to make it public in prod for the world.
- Release the public mainnet.
Phase 5: Sharding This phase introduces sharding to help the network scale efficiently.
- Implement topic-based data sharding.
When will node providers be able to permissionlessly join the production network?
Once XMTP Labs completes phase 4. The timeline is still TBD but we’re looking at roughly a two year time horizon.
Are there any risks with being too centralized? Too decentralized?
- Too centralized
- Developer teams would be hesitant to trust building with XMTP since there is a history of centralized networks limiting dev access or making grand changes to the network once the network owners are pursuing different goals (e.g. Facebook, Twitter)
- There becomes a single point of failure
- Too decentralized
- Decentralization introduces risks for performance issues, security & privacy vulnerabilities, bad actor participation, and network scaling pains. The phases of decentralization XMTP Labs has outlined are to directly address these risks.
- Too centralized
What do you actually need in order to run a node?
- After XMTP Labs completes Phase 1: Data Plane, another party can run a node by running XMTPD on their server. This phase means XMTPD has:
- A reliable method for replicating data between nodes that ensures strong eventual consistency, data integrity, and efficient synchronization (validating Merkle-CRDT in Q2 checks this box)
- After XMTP Labs completes Phase 3: Consensus and Economic Mechanisms, another party will be incentivized to run a node. This phase means the network has:
- Methods for incentivizing and rewarding node operators for keeping the network secure and consistent through consensus.
- After XMTP Labs completes Phase 1: Data Plane, another party can run a node by running XMTPD on their server. This phase means XMTPD has:
What’s the incentive for running a node?
Node operators earn token rewards and fees for driving consensus of the network and facilitating any transactions between network participants
To follow the XMTP network on its path to decentralization, see the XMTP Community Forums.
Was the information on this page helpful?
powered by XMTP