Since the Elastos ecosystem’s network architecture was first presented in the 2017 release of the Elastos whitepaper, Elastos Carrier has served as one of the ecosystem’s most robust platform services. As a decentralized, peer-to-peer framework that takes over all network traffic, Elastos Carrier remains the communication backbone of the Elastos ecosystem in 2022, providing truly secure and anonymous communication via its native global body of Carrier nodes. Nonetheless, with all strengths accounted for, Carrier’s first rendition still leaves a lot of room for improvement – especially in the mission to produce a competitive user experience. To get Carrier to the next level, the Trinity Tech team has been hard at work fine-tuning the best of what Carrier has to offer, while filling in the gaps and smoothing the rough edges.
Addressing Tradeoffs to Set the Stage for Carrier 2
As a completely decentralized communication network, Elastos Carrier provides uncompromising security and privacy. However, full peer-to-peer networks and decentralized systems come with tradeoffs – namely, inefficiency and inconsistent performance. As a result, applications built on fully decentralized networks often fall short relative to the standard experience users are accustomed to on their favorite web2 platforms.
In reality, the problems Carrier has encountered are the same problems faced by every blockchain-based platform and web3 ecosystem on the market today. It has become clear to developers, enthusiasts, and users alike that the challenges boil down to performance and user experience. Although improving user experience for web3 applications is far from impossible, practical solutions inevitably involve compromising on the decentralized mechanisms that give the web3 paradigm its power in the first place.
Achieving Balance with the Web5 Model
Following web3’s rise to prominence, web5 has quickly picked up traction from its promotion by influential figure Jack Dorsey. Like for web3, the primary goal of web5 is to decentralize internet infrastructure and return private data ownership to users. However, web5 infrastructure introduces a key concept in the Decentralized Web Node (DWN), in which groups of independent nodes cooperate to build decentralized web services based on defined protocol parameters. In this design, nodes function together in federated models.
Carrier 2’s design draws on the blueprint introduced by web5, whereby Carrier Supernodes cooperate in federated models to provide services for decentralized applications that run on the Carrier 2 network. Unlike Carrier’s first rendition, Carrier 2 comprises a two-layer network. The network’s first layer is a completely decentralized DHT network that functions in like fashion to Carrier’s original network topology, whereas the network’s second layer comprises a federation of Supernodes that support applications and the services they provide.
In order to operate Carrier 2’s Layer 2 network, Carrier 2 nodes are partitioned into 3 different groups:
- 1) Supernodes
Supernodes run the complete DHT protocol stack and form a completely decentralized DHT network together with other Regular Nodes. Supernodes also run one or several other services for the application layer, such as DHT Proxy, Shadow Service, and IM Service. These services may either be based on federated protocols or remain stateless, and all can implement addressing, matching, and other related operations through the DHT network without relying on a centralized domain name system. In addition, all services are available to any and all nodes on the Carrier 2 network.
In order to provide stable and reliable services, Supernodes must be public network nodes with relatively consistent public network IP addresses and reliable Internet data connection.
- 2) Regular Nodes
Regular nodes run the full DHT protocol stack along with Supernodes to form a fully decentralized DHT network. On the DHT network, regular nodes can use the services provided by Supernodes according to their own needs.
A Regular Node can take the form of any smart device, such as a PC, a set-top box, an embedded device, or others. For Regular Nodes, there are no special network access requirements; both mobile networks and home networks are valid as long as the nodes can access the internet. However, because running a full DHT protocol requires constant data traffic and power consumption, it is best practice to keep devices connected to charging docks. For mobile devices users, energy consumption is of even greater importance, and thus mobile devices may be better suited for use as Light Nodes.
- 3) Light Nodes
Light Nodes do not run the DHT protocol stack, and can access the DHT Proxy through the HTTP/WebSocket protocol to interact with the DHT network. Light nodes may also access application services provided by Supernodes as needed.
Light Nodes do not run the DHT stack, and can run in native applications or even in browsers. Without the basic energy consumption and traffic required by the DHT protocol stack, Light Nodes are also suitable for any mobile phone platform.
Together, Carrier 2’s three different node types form a complete Carrier 2 network that stands as a self-sufficient system that does not depend on traditional centralized services such as DNS or OAuth. In the Carrier 2 network, DHT supports basic network construction and facilitates a number of fundamental interactions, including:
- Node, name resolution, and addressing
- Basic authentication between nodes
- Basic authentication for applications and services
- Declaration and discovery of services
- Basic message interaction between nodes
Sustainability: Brings Tokenomics and Incentives to Carrier 2
In order to produce a network that is both principally decentralized and sustainable in its operations, Carrier 2 entails a multi-layered network where each layer introduces its own unique tokenomics and related incentives.
- Layer 1: Public & Permissionless DHT Network
Layer 1 is a public network that any node can join and use for free.
- Layer 2: Federated Services Network
Layer 2 supports application services that may either remain open and free, or require authentication and incorporate payment models. Carrier 2 provides basic tokenomic models to attract users to run Supernodes, so as to make for a more stable and efficient Carrier 2 network, and to expand more application layer services. Layer 2 also provides some token-based service billing and payment support, thereby enabling convenient payment services for Carrier-based service providers and users.
While Layer 1 can be best described as an open basic network that provides decentralized network support, Layer 2 aims to provide the necessary application services to produce a robust application ecosystem on Carrier 2. As a Federated Services Network, Carrier 2 will provide the following core services on Layer 2:
- DHT Proxy Service
The DHT API proxy service is based on the HTTP/WebSocket protocol, and enables Light Nodes to easily call the functions and services of the DHT network – in other words, without running the DHT protocol stack.
- Shadow Service
The Shadow Service allows users to map services under Network Address Translation (NAT) out to the rest of the internet, so as to allow other parties to remotely access what would otherwise be exclusively local services. Of course, in order to be decentralized, any web3 network must enable users to run their own services. Although users can run nodes on a public network or on their personal home networks, certain services may sometimes run on a personal network – in most cases using NAT, and without a consistent public address. In these scenarios, Carrier’s Shadow Service plays a significant role in supporting users that want to run nodes and support these networks.
- Key/Value Store Service
The DHT-based decentralized Key/Value storage service provides fast storage and retrieval for Key/Value data. In addition, the service provides data redundancy based on DHT to ensure availability.
- IM (Instant Messaging) Service
The IM Service is decentralized, and operates in Federation mode in similar fashion to the current email system. IM Service realizes the interconnection between IM server nodes through standard protocols, and uses Carrier’s DHT network to realize the transmission of IM messages between any two users with full transparency. With the support of Supernodes, the challenges related to slow online and unreliable offline message delivery faced by Carrier 1-based IM applications can be resolved.
The IM Service and its core functions are provided as standard services built into Supernodes, where the payment models will be determined by the operators of each particular Supernode. For example, one node operator may choose to run a node with basic service capabilities to provide free services for public welfare, or run a highly efficient node to provide services of higher quality and reliability, and charge higher fees in suit.
Looking Ahead: What’s Around the Corner for Carrier 2 on the Path to Adoption
All Layer 2 services represent major strides forward for both the Carrier 2 network and the Elastos ecosystem at large. For this reason, they will be implemented individually and independently in order to ensure optimal functionality. At present, the DHT Proxy Service and Shadow Service are of the highest priority, and will be included in the first version of Carrier 2’s Supernode software. Regarding timelines, the first edition of Carrier 2 Supernode software is slated for release around Q1 of 2023. The Key/Value Store Service and IM Service will be included in subsequent project plans.
In addition to the four core services addressed in detail above, the Carrier 2 network remains open for any individual or team to develop their own services. Individuals and teams may also rapidly build decentralized web applications with the help of Carrier 2’s basic service capabilities and the support of its tokenomic model.
First Steps: Elacity Digital Rights Management (DRM)
Even before its launch, Carrier 2 has drawn significant attention from interested parties around the ecosystem looking to integrate its forthcoming features into their platforms. Elacity, a web3 cloud city on Elastos Essentials, was the first ecosystem organization to express interest via Cyber Republic Proposal #91, which officially passed CR Council voting in late September. In the proposal, the Elacity team details plans to build an open source Digital Rights Management (DRM) platform that employs NFTs.
Having already incorporated all live elements of the Elastos tech stack, Elacity plans to leverage Carrier 2 to enable peer-to-peer (P2P) file sharing between user Data Vaults on its DRM platform. Providing a powerful innovation and exciting step forward for Elacity, Carrier 2 has the potential to serve a wide array of platforms and dApps throughout the Elastos ecosystem.
To stay up-to-date and in-the-know on the development of the Carrier 2 network, Elacity’s DRM platform, and other ecosystem applications and platform services in the Elastos tech stack, stay tuned here on the official Elastos Info Blog.
