Publication date: October 13, 2024
As we progress through our comprehensive research and technical specification phase, we are continuously gaining new insights and identifying clearer implementation paths to realize the vision of the Logos Project. The project centers around establishing a community-driven, decentralized physical infrastructure for the Web3, moving beyond the centralized data centers that characterize the Web2 era and enabling a true Web3-native physical infrastructure. In this article, I want to outline how the Logos Edge Hubs can help bring this vision to reality and why they are more essential to the project than initially considered. I'll also provide a brief summary of our thought processes, analyses and decision-making foundations that have led us to a feasible implementation solution of our vision.
To put it simply, YES, the idea is to provide an alternative to traditional centralized data centers for Web3. This requires a fundamental shift in how physical IT infrastructure is managed - something that is far from easy to achieve, but from our perspective, absolutely necessary. For a WHY this is the case, you can read our previous article Web3 and the Cloud: A Conflict of Principles (opens in a new tab).
Since we're building the physical infrastructure for Web3, cloud solutions and traditional data centers are out of the question, making alternative approaches necessary. One of the strategies to be utilized in the Logos Project is leveraging private community devices to provide physical infrastructure resources for Web3. However, this approach has its limitations. When it comes to microservice architectures and serverless solutions, this method can be quite effective and is already being adopted by many computing-focused DePINs (Decentralised Physical Infrastructure Networks). The challenge arises with larger workloads that require more resources than what a typical person might have at home.
For example, if we consider running high-demand workloads like a validator, even an efficient one such as a Polkadot validator, which requires 8 physical cores @ 3.4GHz and 32 GB of RAM, this isn't feasible unless there's access to gaming PCs/laptops or a dedicated home server. There are, of course, some types of nodes - like RPC nodes or offchain workers that don't require substantial resources, making this approach more suitable for some parts of the infrastructure. This is why this strategy is part of the Logos Network: it enables a significant amount of physical hardware to be contributed, serving various segments of the Web3 infrastructure.
The second approach we are aimig to utilize is something we call the DEM (Distributed Execution Machine), originally named DVM. The Distributed Execution Machine (DEM) is a concept developed by LogosLabs to create a system capable of efficiently distributing system processes across multiple physical CPUs, enabling load balancing across various physical CPUs and memory devices. Approaches like Virtual Symmetric Multiprocessing (vSMP) or Message Passing Interface (MPI) aren't new concepts and can facilitate this approach.
The catch is that when critical and latency-sensitive processes are distributed to one device and non-latency-sensitive processes are assigned to another, the conditions need to be near-perfect. This is because we're operating in the microsecond range. First, we face the physical limitations of latency in fiber optic transmission, which is around 5 microseconds per kilometer. This means that the processes being synchronized can't have a large distance between them in the case that low latency is required. While technically feasible, achieving such low-latency environments consistently is challenging and highly dependent on the circumstances.
The second critical factor for this approach is hardware compatibility. The CPUs must be compatible with each other, as differences in generations or architectures can lead to significant challenges. Incompatible CPUs can hinder the execution and synchronization of processes. While virtualization technologies can help mitigate these issues by abstracting hardware differences, this still introduces several practical obstacles in terms of implementation.
The DEM is intended to work in combination with the Logos Edge Hubs, where the idea is to run critical processes on the Edge Hubs while non-latency-sensitive processes, such as off-chain computations for example, are executed on separate CPUs. However, even with the Edge Hubs, the required conditions - especially at the initial stage of the network where provider distances will be relatively high - won't often be met, which could severely hinder scaling.
These two approaches, which are part of our concept, can address certain areas but are not enough to make data centers for Web3 unnecessary. This is why the Logos Edge Hubs are critical for providing a feasible infrastructure. Originally, the Logos Edge Hubs were intended to enable the DEM and act as a fallback when community-provided resources were insufficient. The approach is now being expanded, so that the Hubs not only serve as a fallback and the foundation for the OpenStack environment, but also as additional compute nodes that can run Web3 infrastructure. Simply put, more Logos Edge Hubs will be needed to make the physical infrastructure both efficient and decentralized.
Integration of Logos Edge Hubs and community devices enabling the sub0layer.
A Logos Edge Hub is essentially a server that acts as a compute node in an OpenStack environment. Unlike community devices, Logos Edge Hubs are equipped with more resources than a typical PC or laptop can provide. This allows for more efficient resource management as easier and faster scaling through virtualization capabilities.
The Logos Edge Hubs are being developed by LogosLabs and are specifically designed to work efficiently and securely in a distributed environment. These won't be the typical, overpriced, high-end servers found in data centers. Instead, they will be hardware that meet the necessary network requirements, which anyone can easily provide to the network - even without much technical knowledge - and be fairly compensated for its operation, a principle that is not new to DePINs.
The utilization of Logos Edge Hubs on this scale is a necessary step toward replacing data centers in Web3. We aim to decentralize hardware that has long been centralized. In the early days of Web3, the idea was that the community would run it themselves from home, but this wasn't really feasible due to the technical knowledge and effort required. Even today, that remains the case, except now there are services that simplify things for the community by hosting it for them in the cloud. This, however, incurs costs, as cloud services have considerable operational expenses, which are reflected in their pricing.
With the introduction of the Logos Edge Hubs and their decentralized operation, many of these costs can be eliminated, making computation more affordable. A Logos Edge Hub isn't a validator that requires complex configuration. Instead, it's a hardware component that only needs to be connected to the network, which involves minimal effort and can be operated by many participants.
With the evolved approach of Logos Edge Hubs and with the community-provided devices, it becomes possible to fully realize the vision of the sub0layer. This will be a significant step forward, but we are also talking about the next stage of the internet, which naturally involves major shifts and considerable effort for improvement. We are striving for a future where Web3 infrastructure operates without traditional, centralized data centers - where the Web3 is maintained on a decentralized, trustless, transparent and community-driven infrastructure that truly reflects the values of a Web3-worthy physical infrastructure.
Do you have questions or want to discuss more? Join our discussion on Discord (opens in a new tab)
References:
- AMD Symmetric multiprocessing (opens in a new tab)
- AMD Asymmetric Multiprocessing (opens in a new tab)
- Fiber-optic communication (opens in a new tab)
- Latency in optical fiber systems (opens in a new tab)
- Message Passing Interface (MPI) (opens in a new tab)
- Polkadot validator requirements (opens in a new tab)
- Symmetric multiprocessing (SMP) (opens in a new tab)