diff --git a/docs/architecture/_category_.json b/docs/architecture/_category_.json new file mode 100644 index 0000000..77cb267 --- /dev/null +++ b/docs/architecture/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Architecture", + "position": 4, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/architecture/architecture.md b/docs/architecture/architecture.md new file mode 100644 index 0000000..8835258 --- /dev/null +++ b/docs/architecture/architecture.md @@ -0,0 +1,14 @@ +--- +sidebar_position: 1 +--- + + +# Base Layer for Many Usecases + +![](../img/usecases_tfgrid.png) + +Our Decentralized Cloud Technology the ideal platform for hosting any web3 and AI workloads. + +Our Zero-OS operating system also supports integrated GPUs, ensuring optimal performance for decentralized AI applications. + +> Any workload (web2/3 and AI) can run on on our Decentralized Cloud. diff --git a/docs/architecture/cloudengine.md b/docs/architecture/cloudengine.md new file mode 100644 index 0000000..87882f0 --- /dev/null +++ b/docs/architecture/cloudengine.md @@ -0,0 +1,27 @@ +--- +sidebar_position: 2 +--- + + +# Architecture Cloud Engine + +![](../img/cloud_engine.jpg) + + + +The 3 Nodes form the base layer, providing compute, storage, and network capabilities. + +The quantum safe network enables all IT workloads to communicate with one another using the most efficient route and the strongest security measures. + +![](../img/cloudengine_architecture.png) + +The Storage layer make sure we all have perfect control over our storage and can never loose our information. + + + +## Autonomous Deployments + +![](../img/autonomous_workloads.png) + +The hero's can deploy and manage IT workloads on our behalf. + diff --git a/docs/architecture/hero_virtual_admin.md b/docs/architecture/hero_virtual_admin.md new file mode 100644 index 0000000..9d7ecf7 --- /dev/null +++ b/docs/architecture/hero_virtual_admin.md @@ -0,0 +1,32 @@ +--- +sidebar_position: 4 +--- + +# Hero as Virtual System Administrator + +![](../img/virtual_sysadmin.jpg) + + +![](../img/3bot_virtualsysadmin.png) + +Every individual has a personal Hero—a virtual assistant that manages your digital life and serves as your system administrator for AI or Edge Cloud workloads. + +These Heroes communicate with each other over the private Mycelium network, which offers a secure message bus for scalable and secure communication. + +A Hero can store an unlimited amount of information, and only your Hero has access to this data, deciding how and when it can be shared with other Heroes or AI systems. + +Active 24/7, your Hero continuously monitors your IT infrastructure. If something goes wrong, the Hero will automatically resolve the issue, ensuring smooth and uninterrupted service. + + +### Natural Evolution + +![](../img/hero_archit.png) + + + +We believe this represents the natural evolution away from reliance on centralized services. + +With millions of Heroes working together, can form a collective global intelligence, leveraging various tools to interact with existing services on behalf of their users within all safety of our own sovereignity. + + + diff --git a/docs/architecture/internet_arch.md b/docs/architecture/internet_arch.md new file mode 100644 index 0000000..32107e2 --- /dev/null +++ b/docs/architecture/internet_arch.md @@ -0,0 +1,64 @@ +--- +sidebar_position: 3 +--- + +# Architecture for an Upgraded Internet + + +![](../img/architecture.png) + +- **3Nodes**: Deliver compute, storage, and GPU capacity. +- **Mycelium Routers**: Allow all Mycelium Network participants to communicate with each other and also connect over existing Internet links. Mycelium Routers provide bandwidth to our ecosystem. +- **WebGateways**: Provide a bridge between the current Internet and the Mycelium Network. +- **Hero 3Bots**: Represent our digital lives and possess the knowledge to act as virtual system administrators, ensuring our IT workloads remain operational. +- **Users**: Arrange their digital lives through their Hero 3Bots. +- **AI Clouds**: Are created by connecting GPUs from the 3Nodes over the Mycelium Network. + +## 3Nodes + +Each 3node provides compute, storage and network capacity, its the core capacity layer of the cloud. + +![](../img/3node.png) + +A cloud needs hardware/servers to function. Servers of all shapes and sizes can be added. The production of Cloud Capacity is called Farming and parties who add these servers to the grid are called Farmers. + +Farmers download the Zero-OS operating system and boot their servers. Once booted, these servers become 3Nodes. The 3Nodes will register themselves in a blockchain. Once registered, the capacity of the 3Nodes will become available. This enables a peer2peer environment for people or companies to reserve their Internet Capacity directly from the hardware but yet allowing full control by commercial parties if that would be required. + +Each 3Node is running our Zero-OS operating system. + +## Mycelium Routers + +Mycelium is an end-to-end encrypted overlay meshed wireless network with agents available for any desktop and mobile operating system. + +We have also created a dedicated Mycelium Router. Mycelium Routers seamlessly integrate with our Mycelium network technology, efficiently selecting the shortest path between all participants. + +These Mycelium Routers are compatible not only with Satelite, Wi-Fi but also with 4G and 5G networks, ensuring versatile connectivity options. + +The Mycelium Routers can be installed in locations with substantial network capacity, allowing everyone to bridge between the current Internet and the overlay Mycelium network. + +## Web Gateways + +The Web Gateway serves as a mechanism to connect the private (overlay) networks (Mycelium) to the open Internet. + +By not providing an open and direct path into the private network, many malicious phishing and hacking attempts are stopped at the Web Gateway level for container applications. + +The Web Gateways provide HTTP(S) and, in the future, other web services, which get forwarded to the relevant service exposing itself over Mycelium. This setup offers multiple access points to various backend services. + + +## TFChain: Our Blockchain + +This blockchain does the following: + +- registry for all 3bots (identity system, aka phonebook) +- registry for all farmers & 3nodes +- registry for our reputation system +- info as required for the Smart Contract for IT + +This is the hart of our operational system of our decentralized cloud. + + +## Ultra Scalable + +![](../img/architecture_scalable.png) + +This architecture scales to the planet. \ No newline at end of file diff --git a/docs/cloud_reinvented/_category_.json b/docs/cloud_reinvented/_category_.json new file mode 100644 index 0000000..88255d6 --- /dev/null +++ b/docs/cloud_reinvented/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "The Cloud Re-Invented", + "position": 3, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/cloud_reinvented/cloud_like_insurance.md b/docs/cloud_reinvented/cloud_like_insurance.md new file mode 100644 index 0000000..6556108 --- /dev/null +++ b/docs/cloud_reinvented/cloud_like_insurance.md @@ -0,0 +1,62 @@ +--- +title: Cloud Beyond Cost +sidebar_position: 3 +--- + + +![](../img/farming_pools.jpg) + +# The Cloud: Beyond Cost – A Business Perspective + +## Introduction + +The transition to cloud computing isn't solely driven by cost savings. + + While affordability is a factor, the primary appeal of cloud services lies in their reliability, scalability, and performance. + + This parallels the concept of insurance, where customers are willing to pay a premium for the assurance of superior service and uptime. + + In the decentralized infrastructure (DePIN) space, establishing trust and reliability is super important, but not enough available in current offerings. + +## Cost vs. Quality + +### Reliability and Uptime + +Customers often prefer to pay a higher price for cloud services that guarantee better uptime and reliability. + +For example, paying $10 per terabyte for a service with stellar uptime and customer support is more appealing than a $5 per terabyte service with frequent downtimes and minimal support. The value proposition lies in uninterrupted access to data and services, which is critical for business operations. + +### Service Level Agreements (SLAs) + +Service Level Agreements (SLAs) play a crucial role in this decision-making process. + + SLAs provide a clear, contractual guarantee of the service levels customers can expect. Companies offering robust SLAs with high uptime guarantees, fast response times, and comprehensive support are more attractive, even at a higher cost. + +## Decentralized Infrastructure (DePIN) and Trust + +### Challenges in DePIN + +One of the significant challenges in DePIN is ensuring that customers can trust decentralized hosters. + +Unlike traditional centralized providers, decentralized hosters need to establish credibility and reliability in a market that is inherently less controlled. + +### Farming Pools and Legal Decentralization + +#### Formation of Farming Pools + +Hosters can group together in farming pools, creating a collaborative environment where resources and responsibilities are shared. These pools can offer combined storage and computational power, enhancing overall performance and reliability. + +#### Security Token Offerings (STOs) + +To fund these farming pools, we can utilize Security Token Offerings (STOs). Investors can buy tokens, representing shares in these pools, thus promoting legal decentralization. This model not only democratizes investment but also ensures that the operations of these pools are transparent and regulated. + +### Transparency and Legal Assurance + +#### Open SLAs + +Each farming pool must be explicit about the SLAs they can deliver. Transparency in service commitments ensures that customers know what performance and reliability to expect. This openness is critical in building trust in a decentralized environment. + +#### Legal Blockchain Contracts + +Blockchain contracts must be legally binding in the real world. These contracts should clearly define the terms of service, dispute resolution mechanisms, and compliance with relevant regulations. Legal enforceability ensures that customers can trust the decentralized hosters to honor their commitments. + diff --git a/docs/cloud_reinvented/cloud_reinvented.md b/docs/cloud_reinvented/cloud_reinvented.md new file mode 100644 index 0000000..908705a --- /dev/null +++ b/docs/cloud_reinvented/cloud_reinvented.md @@ -0,0 +1,32 @@ +--- +title: A New Cloud Engine +sidebar_position: 1 +--- + +# A New Cloud Engine + +## Requirements for a New Cloud Engine + +![alt text](../img/requirements.png) + +- Compute, Storage, Network need to be + - Local + - Sovereign + - Private + - More Secure +- Storage needs to be + - More reliable with less overhead (only 20% overhead needed) + - Capable to be global and be used as CDN (Content Delivery Network) + - Fast enough for the Use Case at hand + - Data can never get lost nor corrupted. + - Storage can scale to Zetabytes as Easily as Petabytes +- Network needs to be + - Working no matter what happens with existing network, route around issues. + - Local sensitive (chose shortest path) + - End2End Encrypted + - Capable to really know where information goes to or comes from (authenticity) +- The full system needs to be + - Autonomous & self Healing + - It should be possible to operate without human Intervention +- Green + - We believe Internet / Cloud can be delivered using at least 10x less energy. diff --git a/docs/cloud_reinvented/internet_reinvented.md b/docs/cloud_reinvented/internet_reinvented.md new file mode 100644 index 0000000..21d62bb --- /dev/null +++ b/docs/cloud_reinvented/internet_reinvented.md @@ -0,0 +1,60 @@ +--- +title: Internet Re-Invented +sidebar_position: 2 +--- + +# The Internet’s Natural Progression + +The Internet was always meant to be a peer-to-peer infrastructure. + +As large companies became profit and data centric, centralization quickly became the norm. + +***We have a vision of the Internet which is much more close to how the Internet was intended to be.*** + +## Requirements For A New Internet + +- Compute, Storage, Network need to be + - Local + - Sovereign + - Private + - More Secure +- Storage needs to be + - More reliable with less overhead + - Capable to be global and be used as Content Delivery Network (CDN) + - Fast enough for the use case at hand +- Network needs to be + - Working no matter what happens with existing network, route around issues + - Local sensitive (chose shortest path) + - End2End Encrypted + - Capable to really know where information goes to or comes from (authenticity) + +## Internet/Cloud Architecture + +!!wiki.include page:'internet_archtecture0.md' + +## Base Layer for a New Cloud / Internet + +![](../img/base_layer.png) + +We need a new cloud engine which supports the evolution of the Internet + + +## Natural Progression + +![alt text](../img/natural_progression.png) + +We envision a world where every person is at the center of their digital life. In this new Internet, each person has their own digital avatar, which we call a ***Hero***. + +The technical backbone enabling the Hero is a component known as the 3Bot. This server, owned and managed by you, operates on our decentralized cloud infrastructure. + +Communication between 3Bots is optimized to use the shortest possible paths, ensuring that all interactions are end-to-end encrypted for maximum security and privacy. + + +## 3Bot Architecture + +![alt text](../img/arch_minimal.png) + +The underlying network of capacity is the decentralized cloud which is like the basic IT energy which makes all of this possible. + +The cecentralized cloud is the result of more than 20 years of development and it is now active on more than 2000 nodes. + diff --git a/docs/cloud_reinvented/world_records.md b/docs/cloud_reinvented/world_records.md new file mode 100644 index 0000000..4267351 --- /dev/null +++ b/docs/cloud_reinvented/world_records.md @@ -0,0 +1,14 @@ +--- +title: World Records +sidebar_position: 4 +--- + +## World Records + +Our team is working on re-inventing layers of the Internet for more than 30 years. While we were doing so this has resulted in some world records and innovative products. + +Here is an overview of those achievements: + +![](../img/world_records.png) + + diff --git a/docs/features/_category_.json b/docs/features/_category_.json new file mode 100644 index 0000000..19460c2 --- /dev/null +++ b/docs/features/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Core Features", + "position": 7, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/features/compute/_category_.json b/docs/features/compute/_category_.json new file mode 100644 index 0000000..61402d5 --- /dev/null +++ b/docs/features/compute/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Compute", + "position": 2, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/features/compute/compute.md b/docs/features/compute/compute.md new file mode 100644 index 0000000..7c0162c --- /dev/null +++ b/docs/features/compute/compute.md @@ -0,0 +1,24 @@ +--- +sidebar_position: 1 +title: Compute Layer +--- + +# Compute Layer + +![](../../img/zos_compute.png) + +Default features: + +- Compatible with Docker +- Compatible with any VM (Virtual Machine) +- Compatible with any Linux workload +- Integrated unique storage & network primitives +- Integrated smart contract for IT layer + +We have the following unique advantages: + +- No need to work with images, we work with our unique ZOS FS +- Every container runs in a dedicated virtual machine providing more security +- The containers talk to each other over a private network (Mycelium) +- The containers can use a web gateway to allow internet users to connect to the applications which are running in their secure containers +- Can use core-x to manage the workload diff --git a/docs/features/compute/zero_deploy.md b/docs/features/compute/zero_deploy.md new file mode 100644 index 0000000..752dbbd --- /dev/null +++ b/docs/features/compute/zero_deploy.md @@ -0,0 +1,39 @@ +--- +sidebar_position: 3 +title: Zero-Deploy +--- + + +## Deterministic Deployment + + +The concept of Zero-Deploy is a key component of the **Smart Contract for IT** framework, which can be applied to any type of workload—whether it's containers, virtual machines (VMs), network gateways, volumes, Kubernetes resources, or other network elements. This framework serves as a formal agreement between a farmer (provider) and a user regarding the deployment of an IT workload. + +### Process + +1. **Build Your Code** + Develop and prepare your application code. + +2. **Convert to Zero-Image** + Use a CI/CD solution (e.g., Hero CI/CD) to convert your Docker build (or other format) into a Zero-Image format. + +3. **Define the Workload** + Specify all the details of your workload, including network bridges, web gateways, required machines, and more. + +4. **Register and Sign** + Register the workload and sign it with your private key. + +5. **Automatic Detection** + All necessary Zero-OS nodes (our infrastructure) will detect that a new workload needs to be deployed. + +6. **Deployment Process** + The nodes will pull down the formal workload descriptions and initiate the deployment process. + +7. **Validation** + Every step of the deployment is verified by Zero-OS (ZOS) to ensure that the intended result is accurately replicated. If any discrepancies are detected, ZOS will halt the deployment and provide an error message. + +### Benefits + +- **Deterministic Deployment**: There is no dynamic behavior during deployment at runtime, ensuring a consistent and predictable outcome. +- **Strict Compliance**: No process can start unless all files and configurations are fully described at the flist level. + diff --git a/docs/features/compute/zero_install.md b/docs/features/compute/zero_install.md new file mode 100644 index 0000000..37f7a19 --- /dev/null +++ b/docs/features/compute/zero_install.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 4 +title: Zero-Install +--- + + +## Zero install + +![](../../img/boot.png) + +The Zero-OS is delivered to the 3Nodes over the internet network (network boot) and does not need to be installed. + + +### 3Node Install + +1. Deploy a computer +2. Configure a farm on the TFGrid explorer +3. Download the bootloader and put on a USB stick or configure a network boot device +4. Power on the computer and connect to the internet +5. Boot! The computer will automatically download the components of the operating system (Zero-OS) + +The actual bootloader is very small, it brings up the network interface of your computer and queries TFGrid for the remainder of the boot files needed. + +The operating system is not installed on any local storage medium (hard disk, ssd), Zero-OS is stateless. + +The mechanism to allow this to work in a safe and efficient manner is an innovation called our container virtual filesystem. + +### Process + +- optionally: configure booting from secure BIOS +- optionally: install signing certificate in the BIOS, to make sure that only the right bootloader can be started +- the bootloader (ISO, PXE, USB, ...) get's downloaded from Internet (TFGrid CDN or private deployment) +- core-0 (the first boot process) starts, self verification happens +- the metadata for the the required software modules is downloaded and checked against signature and hashes +- the core-0 zero_image service diff --git a/docs/features/compute/zero_os.md b/docs/features/compute/zero_os.md new file mode 100644 index 0000000..f5378e5 --- /dev/null +++ b/docs/features/compute/zero_os.md @@ -0,0 +1,46 @@ +--- +sidebar_position: 2 +title: Zero-OS +--- + + +# Zero-OS + +![](../../img/zos23.png) + +A revolutionary operating system which can be booted on most modern computers. Once installed Zero-OS locks the hardware and makes it accessible to the decentralized marketplace or a centralized ultra secure deployment system. Blockchain mechanism can be used to strongly control how workloads are deployed on the system. + +![](../../img/zos_overview.png) + +## ZOS Compute & Storage Overview + +![](../../img/zos_overview_compute_storage.jpg) + +## ZOS Network Overview + +![](../../img/zos_network_overview.jpg) + + +### Imagine An Operating System With The Following Benefits + +- Up to 10x more efficient for certain workloads (e.g. storage) +- No install required +- All files are deduped for the VM's, containers and the ZOS itself, no more data duplicated filesystems +- The hacking footprint is very small which leads to much safer systems + - Every file is fingerprinted and gets checked at launch time of an application + - There is no shell or server interface on the operating system + - The networks are end2end encrypted between all Nodes +- It is possible to completely disconnect the compute/storage from the network service part which means hackers have a lot less chance to access the data +- A smart contract for the IT layer allows groups of people to deploy IT workloads with consensus and full control +- All workloads which can run on linux can run on Zero-OS but in a much more controlled, private and safe way + +> We have created an operating system from scratch. We used the Linux kernel and its components and then built further on it. We have been able to achieve all of the above benefits. + +## Requirements: + +- **Autonomy**: TF Grid needs to create compute, storage and networking capacity everywhere. We could not rely on a remote (or a local) maintenance of the operating system by owners or operating system administrators. +- **Simplicity**: An operating system should be simple, able to exist anywhere for anyone, and be good for the planet. +- **Stateless**: In a grid (peer-to-peer) set up, the sum of the components provides a stable basis for single elements to fail and not bring the whole system down. Therefore, it is necessary for single elements to be stateless, and the state needs to be stored within the grid. + + + diff --git a/docs/features/compute/zkube.md b/docs/features/compute/zkube.md new file mode 100644 index 0000000..74ee4c3 --- /dev/null +++ b/docs/features/compute/zkube.md @@ -0,0 +1,34 @@ +--- +sidebar_position: 5 +title: ZKube +--- + + +# ZKube + +TFGrid is compatible with Kubernetes Technology. + +![](../../img/kubernetes_0.jpg) + +### Unique for our Kubernetes implementation + +- The Kubernetes networks are on top of our Mycelium technology which means all traffic between containers and kubernetes hosts is end2end encrypted independent of where your Kubernetes nodes are deployed. +- You can mount a Quantum Safe Storage System underneath a Kubernetes Node (VM), which means that you can deploy containers on top of QSFS to host unlimited amounts of storage in a super safe way. +- You Kubernetes environment is for sure 100% decentralized, you define where you want to deploy your Kubernetes nodes and only you have access to the deployed workloads on the TFGrid. + +### Features + +* integration with znet (efficient, secure encrypted network between the zero_vms) +* can be easily deployed at the edge +* single-tenant! + + + +### Architecture + +![](../../img/zkube_architecture.jpg) + diff --git a/docs/features/features.md b/docs/features/features.md new file mode 100644 index 0000000..1e65389 --- /dev/null +++ b/docs/features/features.md @@ -0,0 +1,44 @@ +--- +title: Decentralized Cloud Technology +sidebar_position: 1 +--- + + +# Decentralized Cloud Technology Features + +We present the highlights of our decentralized cloud technology that solves many of the current IT and cloud challenges. + +![](../img/cloud_features.png) + +## Zero OS as a generator for Compute, Storage, Network capacity + +### Compute (uses CU) + +- ZKube + - kubernetes deployment +- Zero VM + - the container or virtual machine running inside ZOS +- CoreX + - process manager (optional), can be used to get remote access to your zero_vm + +A 3Node is a Zero-OS enabled computer which is hosted with any of the Cloud Providers. + +### There are 4 storage mechanisms which can be used to store your data: + +- ZOS FS + - is our dedupe unique filesystem, replaces docker images. +- ZOS Mount + - is a mounted disk location on SSD, this can be used as faster storage location. +- Quantum Safe Filesystem + - this is a super unique storage system, data can never be lost or corrupted. Please be reminded that this storage layer is only meant to be used for secondary storage applications. +- ZOS Disk + - a virtual disk technology, only for TFTech OEM partners. + +### There are 4 ways how networks can be connected to a Z-Machine. + +- Mycelium = Planetary network + - is a planetary scalable network, we have clients for windows, osx, android and iphone. +- ZOS NIC + - connection to a public ipaddress +- WEB GW + - web gateway, a secure way to allow internet traffic reach your secure Z-Machine. \ No newline at end of file diff --git a/docs/features/networking/_category_.json b/docs/features/networking/_category_.json new file mode 100644 index 0000000..fb5db30 --- /dev/null +++ b/docs/features/networking/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Network", + "position": 4, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/features/networking/mycelium.md b/docs/features/networking/mycelium.md new file mode 100644 index 0000000..26ab9df --- /dev/null +++ b/docs/features/networking/mycelium.md @@ -0,0 +1,16 @@ +--- +sidebar_position: 2 +title: Mycelium +description: Our Planetary Network +--- + + +# Mycelium: Our Planetary Network + +![alt text](../../img/mycelium.png) + +The planetary network called Mycelium is an overlay network which lives on top of the existing Internet or other peer-to-peer networks created. + +In the Mycelium network, everyone is connected to everyone. End-to-end encryption between users of an app and the app runs behind the network wall. + +!!wiki.include page:'tech:mycelium0.md' \ No newline at end of file diff --git a/docs/features/networking/networking.md b/docs/features/networking/networking.md new file mode 100644 index 0000000..63dafa1 --- /dev/null +++ b/docs/features/networking/networking.md @@ -0,0 +1,35 @@ +--- +sidebar_position: 1 +--- + + +# Network Technology Overview + +Our decentralized networking platform allows any compute and storage workload to be connected together on a private (overlay) network and exposed to the existing Internet network. The peer-to-peer network platform allows any workload to be connected over secure encrypted networks, which will look for the shortest path between nodes. + +### Secure Mesh Overlay Network (Peer-to-Peer) + +ZNet is the foundation of any architecture running on the TF Grid. It can be seen as a virtual private data center and the network allows all of the *N* containers to connect to all of the *(N-1)* other containers. Any network connection is a secure network connection between your containers, it creates a peer-to-peer network between containers. + +![alt text](../../img/net1.png) + +No connection is made with the Internet. The ZNet is a single tenant network and by default not connected to the public Internet. Everything stays private. For connecting to the public Internet, a Web Gateway is included in the product to allow for public access, if and when required. + +### Redundancy + +As integrated with Web Gateway + +![alt text](../../img/net2.png) + +- Any app can get (securely) connected to the Internet by any chosen IP address made available by ThreeFold network farmers through WebW +- An app can be connected to multiple web gateways at once, the DNS round robin principle will provide load balancing and redundancy +- An easy clustering mechanism where web gateways and nodes can be lost and the public service will still be up and running +- Easy maintenance. When containers are moved or re-created, the same end user connection can be reused as that connection is terminated on the Web Gateway. The moved or newly created Web Gateway will recreate the socket to the Web Gateway and receive inbound traffic. + +### Network Wall + +![](../../img/network_wall.png) + +For OEM projects we can implement a cloud deployment without using TCP-IP or Ethernet this can lead to super secure environments, ideal to battle the Cuber Pandemic. + + diff --git a/docs/features/networking/webgw.md b/docs/features/networking/webgw.md new file mode 100644 index 0000000..1e17cdc --- /dev/null +++ b/docs/features/networking/webgw.md @@ -0,0 +1,43 @@ +--- +sidebar_position: 3 +title: Web Gateway +--- + +# Web Gateway + +The Web Gateway is a mechanism to connect private networks to the open Internet in such a way that there is no direct connection between the Internet and the secure workloads running in the Zero VMs. + +![](../../img/webgateway.jpg) + +### Key Benefits + +- Separation between where compute workloads are and where services are exposed +- Redundancy: Each app can be exposed on multiple web gateways at once +- Support for many interfaces +- Helps resolve shortage of IPv4 addresses + +### Implementation + +Some 3Nodes support gateway functionality (this is configured by the farmers). A 3Node with gateway configuration can then accept gateway workloads and forward traffic to Zero VMs that only have Planetary Network or IPv6 addresses. + +The gateway workloads consist of a name (prefix) that first needs to be reserved on the blockchain. Then, the list of backend IPs. There are other flags that can be set to control automatic TLS (please check Terraform documentation for the exact details of a reservation). + +Once the 3Node receives this workload, the network configures proxy for this name and the Planetary Network IPs. + +### Security + +Zero VMs have to have a Planetary Network IP or any other IPv6 (IPv4 is also accepted). This means that any person connected to the Planetary Network can also reach the Zero VM without the need for a proxy. + +So it's up to the Zero VM owner/maintainer to make sure it is secured and that only the required ports are open. + +### Redundant Network Connection + +![](../../img/redundant_net.jpg) + +### Unlimited Scale + +![](../../img/webgw_scaling.jpg) + +The network architecture is a pure scale-out network system. It can scale to unlimited size, there is simply no bottleneck. Network "supply" is created by network farmers, and network "demand" is done by TF Grid users. + +Supply and demand scale independently. For supply, there can be unlimited network farmers providing web gateways on their own 3Nodes, and unlimited compute farmers providing 3Nodes for compute and storage. The demand side is driven by developers creating software that runs on the grid, system integrators creating solutions for enterprises, and so on. Globally, there is exponentially-growing demand for data processing and storage use cases. \ No newline at end of file diff --git a/docs/features/qsss_home/_category_.json b/docs/features/qsss_home/_category_.json new file mode 100644 index 0000000..fcf9c50 --- /dev/null +++ b/docs/features/qsss_home/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Storage", + "position": 2, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/features/qsss_home/nft_storage.md b/docs/features/qsss_home/nft_storage.md new file mode 100644 index 0000000..845226f --- /dev/null +++ b/docs/features/qsss_home/nft_storage.md @@ -0,0 +1,92 @@ +--- +sidebar_position: 4 +title: NFT Storage +--- + + +# Quantum Safe Storage System for NFT + +Our technology enables quantum safe storage for NFT. + +![](../../img/nft_architecture_updated.png) + +The owner of the NFT can upload the data using one of our supported interfaces: + +- Http upload (everything possible on https://nft.storage/ is also possible on our system) +- Filesystem + +Anyone in the world can retrieve the NFT (if allowed) and the data will be verified when doing so. The data is available anywhere in the world using multiple interfaces again (IPFS, HTTP(S) etc.). Caching happens on a global level. No special software or account on ThreeFold is needed to do this. + +The NFT system operates on top of a very reliable storage system which is sustainable for the planet and ultra secure and private. The NFT owner also owns the data. + + +## The Benefits + +#### Persistence = Owned by the data user, as represented by their associated 3Bot + + +The system is not based on a shared-all architecture. + +Whoever stores the data has full control over: + +- Where data is stored (specific locations) +- The redundancy policy which is used +- How long the data is kept +- CDN policy (where the data is available and for how long) + + +#### Reliability + +- Data cannot be corrupted +- Data cannot be lost +- Each time data is fetched back the hash (fingerprint) is checked. If there are any issues then autorecovery occurs +- All data is encrypted and compressed (unique per storage owner) +- Data owner chooses the level of redundancy + +#### Lookup + +- Multi URL & storage network support (see more in the interfaces section) +- IPFS, HyperDrive URL schema +- Unique DNS schema (with long key which is globally unique) + +#### CDN Support + +Each file (movie, image etc.) stored is available in many locations worldwide. + +Each file gets a unique url pointing to the data which can be retrieved from all these locations. + +Caching happens at each endpoint. + +#### Self Healing & Auto Correcting Storage Interface + +Any corruption e.g. bitrot gets automatically detected and corrected. + +In case of a HD crash or storage node crash the data will automatically be expanded again to fit the chosen redundancy policy. + +#### The Storage Algoritm Uses Quantum Safe Storage System As Its Base + +Not even a quantum computer can hack data stored on our QSSS. + +The QSSS is a super innovative storage system which works on planetary scale and has many benefits compared to shared and/or replicated storage systems. + +It uses forward looking error correcting codes inside. + +#### Green + +Storage uses upto 10x less energy compared to classic replicated system. + +#### Multi Interface + +The stored data is available over multiple interfaces at once. + +- Interfaces + - IPFS + - HTTP(S) on top of 3Bot + - Syncthing + - Filesystem + +This allows ultimate flexibility from the end user perspective. + +The object (video, image etc.) can easily be embedded in any website or other representation which supports http. + + diff --git a/docs/features/qsss_home/qss_algorithm.md b/docs/features/qsss_home/qss_algorithm.md new file mode 100644 index 0000000..682d0c6 --- /dev/null +++ b/docs/features/qsss_home/qss_algorithm.md @@ -0,0 +1,118 @@ +--- +sidebar_position: 2 +--- + +# Quantum Safe Storage Algoritm + +The Quantum Safe Storage Algorithm is the heart of the Storage engine. The storage engine takes the original data objects and creates data part descriptions that it stores over many virtual storage devices (ZDB/s). + +Data gets stored over multiple ZDB's in such a way that data can never be lost. + +Unique features + +- Data always append, can never be lost +- Even a quantum computer cannot decrypt the data +- Data is spread over multiple sites. If these sites are lost the data will still be available +- Protects from datarot + +## The Problem + +Today we produce more data than ever before. We cannot continue to make full copies of data to make sure it is stored reliably. This will simply not scale. We need to move from securing the whole dataset to securing all the objects that make up a dataset. + +We are using technology which was originally used for communication in space. + +The algo stores data fragments over multiple devices (physical storage devices ). + +The solution is not based on replication or sharding, the algo represents the data as equasions which are distributed over multiple locations. + + +## How Data Is Stored Today + +![alt text](../../img/storage_today.png) + +In most distributed systems, as used on the Internet or in blockchain today, the data will get replicated (sometimes after sharding, which means distributed based on the content of the file and spread out over the world). + +This leads to a lot of overhead and minimal control where the data is. + +In well optimized systems overhead will be 400% but in some it can be orders of magnitude higher to get to a reasonable redundancy level. + +## The Quantum Safe Storage System Works Differently + +![alt text](../../img/qsss_overview.png) + +We have developed a new storage algorithm which is more efficient, ultra reliable and gives you full control over where your data is stored. + +Our approach is different. Let's try to visualize this new approach with a simple analogy using equations. + +Let a,b,c,d.... be the parts of the original object. You could create endless unique equations using these parts. A simple example: let's assume we have 3 parts of original objects that have the following values: + +``` +a=1 +b=2 +c=3 +``` + +(and for reference the part of the real-world objects is not a simple number like `1` but a unique digital number describing the part, like the binary code for it `110101011101011101010111101110111100001010101111011.....`). + + +With these numbers we could create endless amounts of equations: + +``` +1: a+b+c=6 +2: c-b-a=0 +3: b-c+a=0 +4: 2b+a-c=2 +5: 5c-b-a=12 + +etc. + +``` + +Mathematically we only need 3 to describe the content (value) of the fragments. But creating more adds reliability. Now store those equations distributed (one equation per physical storage device) and forget the original object. So we no longer have access to the values of a, b, c and we just remember the locations of all the equations created with the original data fragments. + +Mathematically we need three equations (any 3 of the total) to recover the original values for a, b or c. So do a request to retrieve 3 of the many equations and the first 3 to arrive are good enough to recalculate the original values. Three randomly retrieved equations are: + +``` +5c-b-a=12 +b-c+a=0 +2b+a-c=2 +``` +And this is a mathematical system we could solve: + +- First: `b-c+a=0 -> b=c-a` +- Second: `2b+a-c=2 -> c=2b+a-2 -> c=2(c-a)+a-2 -> c=2c-2a+a-2 -> c=a+2` +- Third: `5c-b-a=12 -> 5(a+2)-(c-a)-a=12 -> 5a+10-(a+2)+a-a=12 -> 5a-a-2=2 -> 4a=4 -> a=1` + +Now that we know `a=1` we could solve the rest `c=a+2=3` and `b=c-a=2`. And we have from 3 random equations regenerated the original fragments and could now recreate the original object. + +The redundancy and reliability in this system results from creating equations (more than needed) and storing them. As shown these equations in any random order can recreate the original fragments and therefore redundancy comes in at a much lower overhead. + +In our system we don't do this with 3 parts but with thousands. + +### Example of 16/4 + + +Each object is fragmented into 16 parts. So we have 16 original fragments for which we need 16 equations to mathematically describe them. Now let's make 20 equations and store them dispersedly on 20 devices. To recreate the original object we only need 16 equations. The first 16 that we find and collect allows us to recover the fragment and in the end the original object. We could lose any 4 of those original 20 equations. + +The likelihood of losing 4 independent, dispersed storage devices at the same time is very low. Since we have continuous monitoring of all of the stored equations, we could create additional equations immediately when one of them is missing, making it an auto-regeneration of lost data and a self-repairing storage system. + +> The overhead in this example is 4 out of 20 which is a mere **20%** instead of **400%** . + +## Content Delivery + +This system can be used as backend for content delivery networks. + +E.g. content distribution policy could be a 10/50 distribution which means, the content of a movie would be distributed over 60 locations from which we can lose 50 at the same time. + +If someone now wants to download the data, the first 10 locations to answer will provide enough of the data parts to rebuild the data. + +The overhead here is more, compared to previous example, but stil orders of magnitude lower compared to other CDN systems. + +## The Quantum Safe Storage System Can Avoid Datarot + +Datarot is the fact that data storage degrades over time and becomes unreadable e.g. on a harddisk. + +The storage system provided by ThreeFold intercepts this silent data corruption ensurinf that data does not rot. + +> See also https://en.wikipedia.org/wiki/Data_degradation + diff --git a/docs/features/qsss_home/qss_filesystem.md b/docs/features/qsss_home/qss_filesystem.md new file mode 100644 index 0000000..d434779 --- /dev/null +++ b/docs/features/qsss_home/qss_filesystem.md @@ -0,0 +1,67 @@ +--- +sidebar_position: 5 +--- + +# Quantum Safe Filesystem + +Our quantum safe filesystem technology has unique features. + +![](../../img/qss_fs_arch.png) + +A redundant filesystem, can store PB's (millions of gigabytes) of information. + +Unique features: + +- Unlimited scalability (many petabytes) +- Quantum Safe: + - No farmer knows what the data is + - Even a quantum computer cannot decrypt the data +- Data can't be lost + - Protection for datarot, data will autorepair +- Data is kept forever (data does not get deleted) +- Data is dispersed over multiple sites + - Even if the sites go down the data will not be lost +- Up to 10x more efficient than storing on classic storage cloud systems +- Can be mounted as filesystem on any OS or any deployment system (OSX, Linux, Windows, Docker, Kubernetes etc.) +- Compatible with ± all data workloads (not high performance data driven workloads like a database) +- Self-healing: when a node or disk is lost, the storage system can get back to the original redundancy level +- Helps with compliance for regulations like GDPR (as the hosting facility has no view on what is stored: information is encrypted and incomplete) +- Hybrid: can be installed onsite, public and private +- Read-write caching on encoding node (the front end) + + +## Mount Any Files In Your Storage Infrastructure + +The QSFS is a mechanism to mount any file system (in any format) on the grid, in a quantum secure way. + +This storage layer relies on 3 primitives: + +- [0-db](https://github.com/threefoldtech/0-db) is the storage engine. +It is an always append database, which stores objects in an immutable format. It allows history to be kept out-of-the-box, good performance on disk, low overhead, easy data structure and easy backup (linear copy and immutable files). + +- [0-stor-v2](https://github.com/threefoldtech/0-stor_v2) is used to disperse the data into chunks by performing 'forward-looking error-correcting code' (FLECC) on it and send the fragments to safe locations. +It takes files in any format as input, encrypts the file with AES based on a user-defined key, then FLECC-encodes the file and spreads out the result +to multiple 0-DBs. The number of generated chunks is configurable to make it more or less robust against data loss through unavailable fragments. Even if some 0-DBs are unreachable, you can still retrieve the original data, and missing 0-DBs can even be rebuilt to have full consistency. It is an essential element of the operational backup. + +- [0-db-fs](https://github.com/threefoldtech/0-db-fs) is the filesystem driver which uses 0-DB as a primary storage engine. It manages the storage of directories and metadata in a dedicated namespace and file payloads in another dedicated namespace. + +Together they form a storage layer that is quantum secure: even the most powerful computer can't hack the system because no single node contains all of the information needed to reconstruct the data. + + + +This concept scales forever, and you can bring any file system on top of it: +- S3 storage +- any backup system +- an ftp-server +- IPFS and Hypercore distributed file sharing protocols + + + +## Architecture + +By using our filesystem inside a Virtual Machine or Kubernetes, the cloud user can deploy any storage application on top e.g. Minio for S3 storage, OwnCloud as online fileserver. + +![](../../img/qsstorage_architecture.jpg) + +Any storage workload can be deployed on top of the zstor. + diff --git a/docs/features/qsss_home/qss_zero_knowledge_proof.md b/docs/features/qsss_home/qss_zero_knowledge_proof.md new file mode 100644 index 0000000..ebdb6f4 --- /dev/null +++ b/docs/features/qsss_home/qss_zero_knowledge_proof.md @@ -0,0 +1,15 @@ +--- +sidebar_position: 3 +title: Zero Knowledge Proof +--- + +# Zero Knowledge Proof Storage System + +The Quantum Safe Storage System is zero knowledge proof compliant. The storage system is made up of / split into 2 components: the actual storage devices use to store the data (ZDB's) and the Quantum Safe Storage engine. + + +![](../../img/qss_system.jpg) + +The zero proof knowledge compliancy comes from the fact that all of the physical storage nodes (3Nodes) can prove that they store a valid part of the data that the quantum safe storage engine (QSSE) has stored on multiple independent devices. The QSSE can validate that all of the QSSE storage devices have a valid part of the original information. The storage devices however have no idea what the original stored data is as they only have a part (description) of the original data and have no access to the original data part or the complete original data objects. + + diff --git a/docs/features/qsss_home/qsss_home.md b/docs/features/qsss_home/qsss_home.md new file mode 100644 index 0000000..2797541 --- /dev/null +++ b/docs/features/qsss_home/qsss_home.md @@ -0,0 +1,34 @@ +--- +sidebar_position: 1 +--- + +# Quantum Safe Storage System + +Our storage architecture follows the true peer2peer design of the cecentralized cloud system. + +![](../../img/qsss_intro2.png) + +Any participating node only stores small incomplete parts of objects (files, photos, movies, databases etc.) by offering a slice of the present (local) storage devices. Managing the storage and retrieval of all of these distributed fragments is done by a software that creates development or end-user interfaces for this storage algorithm. We call this '**dispersed storage**'. + +## Benefits + +- Not even a quantum computer can hack +- Zetabytes can be stored as easily as Petabytes +- The system is truly autonomous & self healing +- Datarot is detected and fixed. +- There is 100% contorl over where data is (GDPR) + +## Architecture + +![](../../img/storage_arch.png) + +The cloud user can mix and match storage technologies as are required for their application. + +## Peer2Peer Advantages + +Peer2peer provides the unique proposition of selecting storage providers that match your application and service of business criteria. For example, you might be looking to store data for your application in a certain geographic area (for governance and compliance) reasons. You might also want to use different "storage policies" for different types of data. Examples are live versus archived data. All of these uses cases are possible with this storage architecture, and could be built by using the same building slice produced by farmers and consumed by developers or end-users. + +> There is 100% control over where the data is positioned and the security is incredible. + + + diff --git a/docs/img/3bot_virtualsysadmin.png b/docs/img/3bot_virtualsysadmin.png new file mode 100644 index 0000000..3e2ca70 Binary files /dev/null and b/docs/img/3bot_virtualsysadmin.png differ diff --git a/docs/img/3node.png b/docs/img/3node.png new file mode 100644 index 0000000..e5ce261 Binary files /dev/null and b/docs/img/3node.png differ diff --git a/docs/img/arch_minimal.png b/docs/img/arch_minimal.png new file mode 100644 index 0000000..224dad9 Binary files /dev/null and b/docs/img/arch_minimal.png differ diff --git a/docs/img/architecture.png b/docs/img/architecture.png new file mode 100644 index 0000000..7219176 Binary files /dev/null and b/docs/img/architecture.png differ diff --git a/docs/img/architecture_scalable.png b/docs/img/architecture_scalable.png new file mode 100644 index 0000000..e5de1c1 Binary files /dev/null and b/docs/img/architecture_scalable.png differ diff --git a/docs/img/autonomous_workloads.png b/docs/img/autonomous_workloads.png new file mode 100644 index 0000000..0bcec2e Binary files /dev/null and b/docs/img/autonomous_workloads.png differ diff --git a/docs/img/autonous3bots.png b/docs/img/autonous3bots.png new file mode 100644 index 0000000..2c0abe5 Binary files /dev/null and b/docs/img/autonous3bots.png differ diff --git a/docs/img/boot.png b/docs/img/boot.png new file mode 100644 index 0000000..6fcd493 Binary files /dev/null and b/docs/img/boot.png differ diff --git a/docs/img/cloud_engine.jpg b/docs/img/cloud_engine.jpg new file mode 100644 index 0000000..1290fd3 Binary files /dev/null and b/docs/img/cloud_engine.jpg differ diff --git a/docs/img/cloud_farming.jpg b/docs/img/cloud_farming.jpg new file mode 100644 index 0000000..1290fd3 Binary files /dev/null and b/docs/img/cloud_farming.jpg differ diff --git a/docs/img/cloud_features.png b/docs/img/cloud_features.png new file mode 100644 index 0000000..f4836f5 Binary files /dev/null and b/docs/img/cloud_features.png differ diff --git a/docs/img/cloudengine_architecture.png b/docs/img/cloudengine_architecture.png new file mode 100644 index 0000000..2c5bc6e Binary files /dev/null and b/docs/img/cloudengine_architecture.png differ diff --git a/docs/img/compatible.png b/docs/img/compatible.png new file mode 100644 index 0000000..e2a6c12 Binary files /dev/null and b/docs/img/compatible.png differ diff --git a/docs/img/dream_comes_true copy.png b/docs/img/dream_comes_true copy.png new file mode 100644 index 0000000..e9ddb02 Binary files /dev/null and b/docs/img/dream_comes_true copy.png differ diff --git a/docs/img/energy_efficient.png b/docs/img/energy_efficient.png new file mode 100644 index 0000000..2434b98 Binary files /dev/null and b/docs/img/energy_efficient.png differ diff --git a/docs/img/farming_pools.jpg b/docs/img/farming_pools.jpg new file mode 100644 index 0000000..5115427 Binary files /dev/null and b/docs/img/farming_pools.jpg differ diff --git a/docs/img/freezone.png b/docs/img/freezone.png new file mode 100644 index 0000000..c0d435d Binary files /dev/null and b/docs/img/freezone.png differ diff --git a/docs/img/freezone2.png b/docs/img/freezone2.png new file mode 100644 index 0000000..34cf3de Binary files /dev/null and b/docs/img/freezone2.png differ diff --git a/docs/img/hero_archit.png b/docs/img/hero_archit.png new file mode 100644 index 0000000..a62e536 Binary files /dev/null and b/docs/img/hero_archit.png differ diff --git a/docs/img/holochain.png b/docs/img/holochain.png new file mode 100644 index 0000000..d97c104 Binary files /dev/null and b/docs/img/holochain.png differ diff --git a/docs/img/holochain2.png b/docs/img/holochain2.png new file mode 100644 index 0000000..c3fb9ac Binary files /dev/null and b/docs/img/holochain2.png differ diff --git a/docs/img/ipfs.jpg b/docs/img/ipfs.jpg new file mode 100644 index 0000000..0927468 Binary files /dev/null and b/docs/img/ipfs.jpg differ diff --git a/docs/img/itcontract.png b/docs/img/itcontract.png new file mode 100644 index 0000000..820e13d Binary files /dev/null and b/docs/img/itcontract.png differ diff --git a/docs/img/itcontract2.png b/docs/img/itcontract2.png new file mode 100644 index 0000000..7114507 Binary files /dev/null and b/docs/img/itcontract2.png differ diff --git a/docs/img/kubernetes_0.jpg b/docs/img/kubernetes_0.jpg new file mode 100644 index 0000000..f976a52 Binary files /dev/null and b/docs/img/kubernetes_0.jpg differ diff --git a/docs/img/mycelium.png b/docs/img/mycelium.png new file mode 100644 index 0000000..96cfa1b Binary files /dev/null and b/docs/img/mycelium.png differ diff --git a/docs/img/mycelium00.png b/docs/img/mycelium00.png new file mode 100644 index 0000000..96cfa1b Binary files /dev/null and b/docs/img/mycelium00.png differ diff --git a/docs/img/natural_progression.png b/docs/img/natural_progression.png new file mode 100644 index 0000000..8619698 Binary files /dev/null and b/docs/img/natural_progression.png differ diff --git a/docs/img/net1.png b/docs/img/net1.png new file mode 100644 index 0000000..2df8a29 Binary files /dev/null and b/docs/img/net1.png differ diff --git a/docs/img/net2.png b/docs/img/net2.png new file mode 100644 index 0000000..d2d2658 Binary files /dev/null and b/docs/img/net2.png differ diff --git a/docs/img/network_wall.png b/docs/img/network_wall.png new file mode 100644 index 0000000..6baa448 Binary files /dev/null and b/docs/img/network_wall.png differ diff --git a/docs/img/nft_architecture_updated.png b/docs/img/nft_architecture_updated.png new file mode 100644 index 0000000..4ad2363 Binary files /dev/null and b/docs/img/nft_architecture_updated.png differ diff --git a/docs/img/peer2peer_network.jpg b/docs/img/peer2peer_network.jpg new file mode 100644 index 0000000..d5b8f69 Binary files /dev/null and b/docs/img/peer2peer_network.jpg differ diff --git a/docs/img/planetary_net.jpg b/docs/img/planetary_net.jpg new file mode 100644 index 0000000..f4be658 Binary files /dev/null and b/docs/img/planetary_net.jpg differ diff --git a/docs/img/qss_fs_arch.png b/docs/img/qss_fs_arch.png new file mode 100644 index 0000000..7a33e77 Binary files /dev/null and b/docs/img/qss_fs_arch.png differ diff --git a/docs/img/qss_system.jpg b/docs/img/qss_system.jpg new file mode 100644 index 0000000..3c4656e Binary files /dev/null and b/docs/img/qss_system.jpg differ diff --git a/docs/img/qsss.png b/docs/img/qsss.png new file mode 100644 index 0000000..2bbe588 Binary files /dev/null and b/docs/img/qsss.png differ diff --git a/docs/img/qsss_intro2.png b/docs/img/qsss_intro2.png new file mode 100644 index 0000000..cc40d29 Binary files /dev/null and b/docs/img/qsss_intro2.png differ diff --git a/docs/img/qsss_overview.png b/docs/img/qsss_overview.png new file mode 100644 index 0000000..3f47b53 Binary files /dev/null and b/docs/img/qsss_overview.png differ diff --git a/docs/img/qsstorage_architecture.jpg b/docs/img/qsstorage_architecture.jpg new file mode 100644 index 0000000..811e6ab Binary files /dev/null and b/docs/img/qsstorage_architecture.jpg differ diff --git a/docs/img/re_invented.png b/docs/img/re_invented.png new file mode 100644 index 0000000..630c217 Binary files /dev/null and b/docs/img/re_invented.png differ diff --git a/docs/img/redundant_net.jpg b/docs/img/redundant_net.jpg new file mode 100644 index 0000000..1975ef7 Binary files /dev/null and b/docs/img/redundant_net.jpg differ diff --git a/docs/img/requirements.png b/docs/img/requirements.png new file mode 100644 index 0000000..295c6c4 Binary files /dev/null and b/docs/img/requirements.png differ diff --git a/docs/img/roadmap.jpg b/docs/img/roadmap.jpg new file mode 100644 index 0000000..5390f6d Binary files /dev/null and b/docs/img/roadmap.jpg differ diff --git a/docs/img/shortest_path_routing.jpg b/docs/img/shortest_path_routing.jpg new file mode 100644 index 0000000..f3f281f Binary files /dev/null and b/docs/img/shortest_path_routing.jpg differ diff --git a/docs/img/sikana1.png b/docs/img/sikana1.png new file mode 100644 index 0000000..6acf040 Binary files /dev/null and b/docs/img/sikana1.png differ diff --git a/docs/img/sikana2.png b/docs/img/sikana2.png new file mode 100644 index 0000000..39af218 Binary files /dev/null and b/docs/img/sikana2.png differ diff --git a/docs/img/smartcontract_deploy.png b/docs/img/smartcontract_deploy.png new file mode 100644 index 0000000..8c0a900 Binary files /dev/null and b/docs/img/smartcontract_deploy.png differ diff --git a/docs/img/storage_arch.png b/docs/img/storage_arch.png new file mode 100644 index 0000000..a4c56e1 Binary files /dev/null and b/docs/img/storage_arch.png differ diff --git a/docs/img/storage_inno.png b/docs/img/storage_inno.png new file mode 100644 index 0000000..01a0608 Binary files /dev/null and b/docs/img/storage_inno.png differ diff --git a/docs/img/storage_today.png b/docs/img/storage_today.png new file mode 100644 index 0000000..80d8114 Binary files /dev/null and b/docs/img/storage_today.png differ diff --git a/docs/img/syncthing.jpg b/docs/img/syncthing.jpg new file mode 100644 index 0000000..cd1a17e Binary files /dev/null and b/docs/img/syncthing.jpg differ diff --git a/docs/img/tanzania1.png b/docs/img/tanzania1.png new file mode 100644 index 0000000..850f431 Binary files /dev/null and b/docs/img/tanzania1.png differ diff --git a/docs/img/tiers1.png b/docs/img/tiers1.png new file mode 100644 index 0000000..9e2e9a4 Binary files /dev/null and b/docs/img/tiers1.png differ diff --git a/docs/img/tiers_6pod.png b/docs/img/tiers_6pod.png new file mode 100644 index 0000000..1b67785 Binary files /dev/null and b/docs/img/tiers_6pod.png differ diff --git a/docs/img/tiers_container.png b/docs/img/tiers_container.png new file mode 100644 index 0000000..6b213a5 Binary files /dev/null and b/docs/img/tiers_container.png differ diff --git a/docs/img/tiers_pod.png b/docs/img/tiers_pod.png new file mode 100644 index 0000000..f0bcf44 Binary files /dev/null and b/docs/img/tiers_pod.png differ diff --git a/docs/img/usecases_tfgrid.png b/docs/img/usecases_tfgrid.png new file mode 100644 index 0000000..2eb8667 Binary files /dev/null and b/docs/img/usecases_tfgrid.png differ diff --git a/docs/img/vindo0.png b/docs/img/vindo0.png new file mode 100644 index 0000000..2e2720d Binary files /dev/null and b/docs/img/vindo0.png differ diff --git a/docs/img/vindo1.png b/docs/img/vindo1.png new file mode 100644 index 0000000..9c33536 Binary files /dev/null and b/docs/img/vindo1.png differ diff --git a/docs/img/vindo2.png b/docs/img/vindo2.png new file mode 100644 index 0000000..87bdc5f Binary files /dev/null and b/docs/img/vindo2.png differ diff --git a/docs/img/vindo3.png b/docs/img/vindo3.png new file mode 100644 index 0000000..fa67e56 Binary files /dev/null and b/docs/img/vindo3.png differ diff --git a/docs/img/vindo4.png b/docs/img/vindo4.png new file mode 100644 index 0000000..ded2f16 Binary files /dev/null and b/docs/img/vindo4.png differ diff --git a/docs/img/vindo5.png b/docs/img/vindo5.png new file mode 100644 index 0000000..0ae7541 Binary files /dev/null and b/docs/img/vindo5.png differ diff --git a/docs/img/vindo6.png b/docs/img/vindo6.png new file mode 100644 index 0000000..1395b91 Binary files /dev/null and b/docs/img/vindo6.png differ diff --git a/docs/img/vindo7.png b/docs/img/vindo7.png new file mode 100644 index 0000000..28cc1fe Binary files /dev/null and b/docs/img/vindo7.png differ diff --git a/docs/img/vindo8.png b/docs/img/vindo8.png new file mode 100644 index 0000000..76408c8 Binary files /dev/null and b/docs/img/vindo8.png differ diff --git a/docs/img/virtual_browser.jpg b/docs/img/virtual_browser.jpg new file mode 100644 index 0000000..40948e5 Binary files /dev/null and b/docs/img/virtual_browser.jpg differ diff --git a/docs/img/virtual_sysadmin.jpg b/docs/img/virtual_sysadmin.jpg new file mode 100644 index 0000000..cb429ab Binary files /dev/null and b/docs/img/virtual_sysadmin.jpg differ diff --git a/docs/img/vstreaming.png b/docs/img/vstreaming.png new file mode 100644 index 0000000..f3a0f98 Binary files /dev/null and b/docs/img/vstreaming.png differ diff --git a/docs/img/vverse_museum.png b/docs/img/vverse_museum.png new file mode 100644 index 0000000..f6a160a Binary files /dev/null and b/docs/img/vverse_museum.png differ diff --git a/docs/img/vverse_museum2.png b/docs/img/vverse_museum2.png new file mode 100644 index 0000000..5e6aac3 Binary files /dev/null and b/docs/img/vverse_museum2.png differ diff --git a/docs/img/webgateway.jpg b/docs/img/webgateway.jpg new file mode 100644 index 0000000..ce67712 Binary files /dev/null and b/docs/img/webgateway.jpg differ diff --git a/docs/img/webgw_scaling.jpg b/docs/img/webgw_scaling.jpg new file mode 100644 index 0000000..ad8819c Binary files /dev/null and b/docs/img/webgw_scaling.jpg differ diff --git a/docs/img/whitelists.jpg b/docs/img/whitelists.jpg new file mode 100644 index 0000000..2958abb Binary files /dev/null and b/docs/img/whitelists.jpg differ diff --git a/docs/img/world_records.png b/docs/img/world_records.png new file mode 100644 index 0000000..01fa5d0 Binary files /dev/null and b/docs/img/world_records.png differ diff --git a/docs/img/zkube_architecture.jpg b/docs/img/zkube_architecture.jpg new file mode 100644 index 0000000..f8fc59a Binary files /dev/null and b/docs/img/zkube_architecture.jpg differ diff --git a/docs/img/zos00.png b/docs/img/zos00.png new file mode 100644 index 0000000..ce96ec3 Binary files /dev/null and b/docs/img/zos00.png differ diff --git a/docs/img/zos23.png b/docs/img/zos23.png new file mode 100644 index 0000000..230315d Binary files /dev/null and b/docs/img/zos23.png differ diff --git a/docs/img/zos_compute.png b/docs/img/zos_compute.png new file mode 100644 index 0000000..ecb22c0 Binary files /dev/null and b/docs/img/zos_compute.png differ diff --git a/docs/img/zos_images.jpg b/docs/img/zos_images.jpg new file mode 100644 index 0000000..2d8302f Binary files /dev/null and b/docs/img/zos_images.jpg differ diff --git a/docs/img/zos_network_overview.jpg b/docs/img/zos_network_overview.jpg new file mode 100644 index 0000000..febb1d6 Binary files /dev/null and b/docs/img/zos_network_overview.jpg differ diff --git a/docs/img/zos_overview.png b/docs/img/zos_overview.png new file mode 100644 index 0000000..572e280 Binary files /dev/null and b/docs/img/zos_overview.png differ diff --git a/docs/img/zos_overview_compute_storage.jpg b/docs/img/zos_overview_compute_storage.jpg new file mode 100644 index 0000000..23257e5 Binary files /dev/null and b/docs/img/zos_overview_compute_storage.jpg differ diff --git a/docs/key_innovations_overview/_category_.json b/docs/key_innovations_overview/_category_.json new file mode 100644 index 0000000..acea738 --- /dev/null +++ b/docs/key_innovations_overview/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Key Innovations", + "position": 5, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/key_innovations_overview/compute_inno/_category_.json b/docs/key_innovations_overview/compute_inno/_category_.json new file mode 100644 index 0000000..4947f76 --- /dev/null +++ b/docs/key_innovations_overview/compute_inno/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Compute", + "position": 1, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/key_innovations_overview/compute_inno/compute_inno.md b/docs/key_innovations_overview/compute_inno/compute_inno.md new file mode 100644 index 0000000..504d6bf --- /dev/null +++ b/docs/key_innovations_overview/compute_inno/compute_inno.md @@ -0,0 +1,64 @@ +--- +sidebar_position: 1 +description: The computer layer of the grid +--- + +# Compute Layer + +| | Compute Layer | Default | +|----------------|--------------------------------------------------------------------------------|------------------------------------------------------------------| +| Management | Full P2P, done by 3bot Agents, blockchain IT contract | Centralized e.g. Kubernetes, ... | +| OS Deploy | Stateless, there are no files copied on local HDD/SSD. | Deploy image or execute installer on a physical server | +| OS Upgrade | Seamless, rolling upgrades, 100% modular and pre-deterministic, decentralized | Difficult and error prone + vulnerable from security perspective | +| Tamperproof | If file gets modified Zero-OS will not boot the file. | No, man in middle is possible. | +| Scalability | To the world | Expensive and depending on lots of capital | +| Security | A lot of effort went into the capability to deploy for high security usecases. | Very hard to deploy securely, and expensive | +| Green | For certain workloads we can safe upto 10x on power usage | Super power hungry. | +| Liquid Cooling | Easy to do because of autonomous behavior no need to replace HW. | Hard to do, how to do maintenance. | +| Sovereign | Yes | No | +| Complexity | Anyone can do it, we made it to allow everyone to be a provider. | Real experts needed. | + +> We do not compare our system with those that claim to be full cloud solutions but merely deploy containers using other management systems and optionally connect to a blockchain for billing purposes. Nor do we compare with marketplace systems that simply act as frontends for other systems. We believe these systems, while visually impressive, lack substantial technological foundations and cannot serve as a fundamental base layer for others. + +## Zero-OS + +![](../../img/zos00.png) + +ThreeFold has developed its own operating system, Zero-OS, which is based on the Linux Kernel. The purpose of Zero-OS is to strip away the unnecessary complexities commonly found in contemporary operating systems. + +**Key Features of Zero-OS:** + +Zero-OS is designed with minimalism in mind, supporting only a few fundamental primitives that handle essential low-level functions: + +1. **Storage Capacity** +2. **Compute Capacity** +3. **Network Capacity** + +**Security and Simplicity:** + +Zero-OS provides a Autonomous Decentralized Cloud. + +This not only blocks hacker access but also eliminates human error, enhancing both security and reliability. + +### Deployment by IT contract + +Secure Reproducable Verified Authenticated + +![](../../img/itcontract.png) + +The purpose of the smart contract for IT is to create and enable autonomous IT. Autonomous self-driving IT is possible. + +Once a smart contract for IT is created, it will be registered in the TFChain Blockchain. + +![](../../img/itcontract2.png) + +## Compatible with the world + +![](../../img/compatible.png) + + +## 3Bots: The Autonomous Layer + +![](../../img/autonous3bots.png) + + diff --git a/docs/key_innovations_overview/compute_inno/zero_deploy_inno.md b/docs/key_innovations_overview/compute_inno/zero_deploy_inno.md new file mode 100644 index 0000000..166ccb0 --- /dev/null +++ b/docs/key_innovations_overview/compute_inno/zero_deploy_inno.md @@ -0,0 +1,42 @@ +--- +title: Deterministic Deploy +sidebar_position: 3 +--- + + +![Smart Contract Deployment](../../img/smartcontract_deploy.png) + + +## Deterministic Deployment + + +The concept of Zero-Deploy is a key component of the **Smart Contract for IT** framework, which can be applied to any type of workload—whether it's containers, virtual machines (VMs), network gateways, volumes, Kubernetes resources, or other network elements. This framework serves as a formal agreement between a farmer (provider) and a user regarding the deployment of an IT workload. + +### Process + +1. **Build Your Code** + Develop and prepare your application code. + +2. **Convert to Zero-Image** + Use a CI/CD solution (e.g., Hero CI/CD) to convert your Docker build (or other format) into a Zero-Image format. + +3. **Define the Workload** + Specify all the details of your workload, including network bridges, web gateways, required machines, and more. + +4. **Register and Sign** + Register the workload and sign it with your private key. + +5. **Automatic Detection** + All necessary Zero-OS nodes (our infrastructure) will detect that a new workload needs to be deployed. + +6. **Deployment Process** + The nodes will pull down the formal workload descriptions and initiate the deployment process. + +7. **Validation** + Every step of the deployment is verified by Zero-OS (ZOS) to ensure that the intended result is accurately replicated. If any discrepancies are detected, ZOS will halt the deployment and provide an error message. + +### Benefits + +- **Deterministic Deployment**: There is no dynamic behavior during deployment at runtime, ensuring a consistent and predictable outcome. +- **Strict Compliance**: No process can start unless all files and configurations are fully described at the flist level. + diff --git a/docs/key_innovations_overview/compute_inno/zero_image_inno.md b/docs/key_innovations_overview/compute_inno/zero_image_inno.md new file mode 100644 index 0000000..63decce --- /dev/null +++ b/docs/key_innovations_overview/compute_inno/zero_image_inno.md @@ -0,0 +1,40 @@ +--- +title: Zero-Images +sidebar_position: 3 +--- + +![](../../img/zos_images.jpg) + + +### The Problem + +The current method of deploying workloads in the cloud using Docker containers and virtual machine images has inherent issues. These images consume significant storage space, result in slow and bandwidth-intensive transfers to the internet's edge, drive up costs, introduce complexity, and pose security risks due to difficulties in tracking their contents over time. + +For instance, a complete Ubuntu image can easily be 2 GB in size, comprising millions of files. In contrast, the Flist (metadata for Zero-Image) for a full Ubuntu image is less than 2 MB (1000 times smaller). Based on this flist only the required files will be dowbloaded which can easily be 10x less compared to the original image size. These downloaded files (or subparts of files) are identified by a fingerprint (hash) and will only boot once authenticity can be verified. + + +### Process + +- Zero-OS or the Zero-Image Command Line (works on linux) gets informed to provision a virtual filesystem based on a Zero-Image URL. +- The Zero-Image Metadata is stored on e.g. an S3 Server or our Zero-Hub. + + +### Introducing Flist + +A new image format that separates the image data (comprising files and subfile parts) from the metadata describing the image structure. + +An Flist's format uniquely encompasses comprehensive file descriptions along with all relevant metadata such as size, modification and creation timestamps, and POSIX attributes. Additionally, it incorporates a fingerprint for each component, ensuring deterministic behavior—a crucial feature for security focused use cases. + +Flists provide the flexibility to manage metadata and data as separate entities, offering a versatile approach to handling various build and delivery scenarios. + +### The Benefits + +- **Rapid deployment:** Zero-OS enables containers and virtual machines to launch up to 100 times faster, especially in decentralized scenarios. +- **Enhanced security:** Zero-OS prevents tampering with images, ensuring higher security levels. +- **Reduced storage and bandwidth:** Zero-OS significantly reduces storage and bandwidth requirements, potentially achieving up to a 100-fold improvement. +- **Deterministic deployments:** engineers can precisely define deployments beforehand, ensuring predictable outcomes without changes during deployment. +- **100% compatible:** with existing standards, docker and virtual machines. The same format is useful for VM's as well as any container technology. + +### Status + +Usable for years, see Zero-OS. \ No newline at end of file diff --git a/docs/key_innovations_overview/compute_inno/zero_install_inno.md b/docs/key_innovations_overview/compute_inno/zero_install_inno.md new file mode 100644 index 0000000..7f32d56 --- /dev/null +++ b/docs/key_innovations_overview/compute_inno/zero_install_inno.md @@ -0,0 +1,32 @@ +--- +title: Zero-Install +sidebar_position: 4 +--- + +![](../../img/boot.png) + +The Zero-OS is delivered to the 3Nodes over the internet network (network boot) and does not need to be installed. + + +### 3Node Install + +1. Deploy a computer +2. Configure a farm on the TFGrid explorer +3. Download the bootloader and put on a USB stick or configure a network boot device +4. Power on the computer and connect to the internet +5. Boot! The computer will automatically download the components of the operating system (Zero-OS) + +The actual bootloader is very small, it brings up the network interface of your computer and queries TFGrid for the remainder of the boot files needed. + +The operating system is not installed on any local storage medium (hard disk, ssd), Zero-OS is stateless. + +The mechanism to allow this to work in a safe and efficient manner is an innovation called our container virtual filesystem. + +### Process + +- optionally: configure booting from secure BIOS +- optionally: install signing certificate in the BIOS, to make sure that only the right bootloader can be started +- the bootloader (ISO, PXE, USB, ...) get's downloaded from Internet (TFGrid CDN or private deployment) +- core-0 (the first boot process) starts, self verification happens +- the metadata for the the required software modules is downloaded and checked against signature and hashes +- the core-0 zero_image service diff --git a/docs/key_innovations_overview/energy_efficient.md b/docs/key_innovations_overview/energy_efficient.md new file mode 100644 index 0000000..edf71b4 --- /dev/null +++ b/docs/key_innovations_overview/energy_efficient.md @@ -0,0 +1,14 @@ +--- +sidebar_position: 4 +--- + +# Energy Efficient + +Below are some of the ways in which we achieve energy efficiency as compared to traditional models. + +![alt text](../img/energy_efficient.png) + +In addition, a decentralized peer-to-peer infrastructure which finds the shortest path between end points is by nature energy-efficient. Data needs to travel a much shorter distance. + +> Depending on the use case the our approach can lead to 10x energy savings. + diff --git a/docs/key_innovations_overview/network_inno/_category_.json b/docs/key_innovations_overview/network_inno/_category_.json new file mode 100644 index 0000000..f21d59f --- /dev/null +++ b/docs/key_innovations_overview/network_inno/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Network", + "position": 2, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/key_innovations_overview/network_inno/mycelium_inno.md b/docs/key_innovations_overview/network_inno/mycelium_inno.md new file mode 100644 index 0000000..8b0390c --- /dev/null +++ b/docs/key_innovations_overview/network_inno/mycelium_inno.md @@ -0,0 +1,36 @@ +--- +title: Mycelium +sidebar_position: 2 +--- + +![](../../img/peer2peer_network.jpg) + +## Mycelium: A New Network Layer for the Internet + +![](../../img/mycelium00.png) + +### The Problem + +The current centralized state of the internet poses significant security risks, with compromised routers and growing cyber threats (trillions of USD per year now), making everyone vulnerable to hacking. Industry responses involve disabling original features, hindering true peer-to-peer connectivity and personal server capabilities. Workarounds and system hacks have become the norm. + +**Our Internet is seriously broken. We need new ways to communicate** + +### Introducing Mycelium + +Mycelium is an overlay network layer designed to enhance the existing internet infrastructure while remaining compatible with all current applications. It empowers true peer-to-peer communication. By installing a Network Agent on your device, you gain the ability to securely connect with any other participant on this network. Mycelium intelligently reroutes traffic to maintain connectivity taking location of you and your peer into consideration. + +### The Benefits + + +- **Continuous connectivity:** Mycelium ensures uninterrupted connectivity by dynamically rerouting traffic through available connections (friends, satellites, 4/5G, fiber). +- **End-to-end encryption:** robust encryption stops man-in-the-middle attacks, guaranteeing secure communication. +- **Proof of authenticity (POA): ensures that we know who we are communicating with +- **Optimized routing:** Mycelium finds the shortest path between network participants, reducing latency and keeping traffic localized. +- **Universal server capability:** empowers individuals to act as servers, a foundational element for any peer-to-peer system. +- **Full Compatibility:** Mycelium seamlessly integrates with the current internet, supporting any application. +- **Impressive speed:** achieves 1 Gbps per Network Agent, ensuring rapid data transfer. + +### Status + +In beta and usable from TFGrid 3.13, its our 3e generation approach to networking and took us years to do. We are looking forward to your feedback. + diff --git a/docs/key_innovations_overview/network_inno/mycelium_shortest_path_routing_inno.md b/docs/key_innovations_overview/network_inno/mycelium_shortest_path_routing_inno.md new file mode 100644 index 0000000..d5d4b99 --- /dev/null +++ b/docs/key_innovations_overview/network_inno/mycelium_shortest_path_routing_inno.md @@ -0,0 +1,64 @@ +--- +title: Shortest Path Routing +sidebar_position: 3 +--- + +![](../../img/shortest_path_routing.jpg) + +# Shortest Path Routing + +## Empowering Connectivity with an End-to-End Encrypted Overlay Network + +### The Concept of End-to-End Encryption + +End-to-end encryption (E2EE) ensures that data is encrypted on the sender's device and only decrypted on the recipient's device. This means that no intermediaries, including service providers, can access or alter the data while it is in transit. + +### Shortest Path Routing in Overlay Networks + +An overlay network is a virtual network built on top of an existing physical network. + +Each enduser mycelium agent will execute custom routing logic and protocols to improve connectivity. + +- In the context of a Mycelium peer-to-peer (P2P) overlay network, nodes (participants) can dynamically discover and connect to each other, forming a mesh-like structure. +- Shortest Path Routing: The network can use algorithms to find the shortest or most efficient path between nodes. This ensures that data packets travel the minimum distance required to reach their destination, reducing latency and improving performance. + +### Multi-Hop Communication + +In a P2P overlay network, data can hop through multiple nodes to reach its destination. This means that if a direct connection is not available, the data can be relayed through intermediary nodes. For example: + +1. **Node A** wants to send data to **Node D**. +2. There is no direct connection, but **Node A** can reach **Node B**, which can reach **Node C**, which finally reaches **Node D**. +3. The data is encrypted end-to-end, so it remains secure throughout its journey. + +Network usage tracking and billing can be used to make sure all participants are rewarded. + +### Leveraging Existing Networks + +This overlay network operates on top of existing internet infrastructure. + +This leads to: + +1. **Cost Efficiency**: By leveraging existing infrastructure, there is no need for extensive new investments in physical hardware. +2. **Flexibility**: The network can dynamically adapt to changing conditions, such as network congestion or outages. + +### Improving Connectivity for Underserved Populations + +Currently, around 4 billion people lack decent internet access. + +Mycelium can significantly improve their connectivity: + +1. **Decentralized Access**: People in remote or underserved areas can connect to the network through nearby nodes, which may belong to friends, community members, or even commercial providers offering bandwidth. +2. **Community-Driven Networks**: Local communities can set up nodes that connect to the broader overlay network, creating a resilient and scalable web of connectivity. +3. **Increased Bandwidth**: By aggregating available bandwidth from multiple sources, the overlay network can provide higher data rates and more reliable connections. + +### Example Scenario + +Imagine a remote village with limited internet access. The villagers set up several nodes that connect to each other and to nearby towns with better connectivity, also some of the nodes can be connected to Internet over satelite, mobile 4g or other mechanisms. + +Here’s how it works: + +1. **Local Node Setup**: Villagers install nodes on their devices, which form a local mesh network. +2. **Connecting to Broader Network**: Some nodes have access to satellite internet or long-range Wi-Fi that connects to nearby towns. +3. **Dynamic Routing**: When a villager wants to access online resources, their data is encrypted end-to-end and routed through the shortest path available, which may include local nodes, satellite links, and commercial internet providers. +4. **Enhanced Access**: This setup leverages all available bandwidth sources, providing more reliable and faster internet access to the village. + diff --git a/docs/key_innovations_overview/network_inno/mycelium_whiltelist.md b/docs/key_innovations_overview/network_inno/mycelium_whiltelist.md new file mode 100644 index 0000000..0795d7c --- /dev/null +++ b/docs/key_innovations_overview/network_inno/mycelium_whiltelist.md @@ -0,0 +1,59 @@ +--- +title: Whitelists +sidebar_position: 4 +--- + +![](../../img/whitelists.jpg) + +# Mycelium Whitelists + +> Rethinking Network Security: Beyond Traditional Firewalls + +### The Limitations of Traditional Firewalls + +Firewalls have long been the cornerstone of network security, operating as gatekeepers to keep malicious actors out. + +They work by monitoring incoming and outgoing network traffic and applying security rules to block or allow data packets based on predefined criteria. However, while firewalls are effective at creating a barrier, they have inherent limitations: + +1. **Perimeter Focus**: Firewalls are designed to protect the perimeter of the network. This approach assumes that threats come from outside the network, but it does not adequately address threats from within. +2. **Static Rules**: Firewalls rely on static rules that can be bypassed by sophisticated attacks. They do not adapt dynamically to changing threat landscapes. +3. **Single Point of Failure**: As a centralized barrier, firewalls represent a single point of failure. If a firewall is compromised, the entire network can be exposed. + +### The Need for Strong Authentication and Peer-to-Peer Communication + +To address these limitations, a more modern approach to network security involves strong authentication and decentralized communication. By ensuring that all participants on the network are strongly authenticated, we can establish trust at the individual level rather than relying solely on perimeter defenses. + +#### Strong Authentication + +Strong authentication involves verifying the identity of network participants using robust methods such as: + +- **Multi-Factor Authentication (MFA)**: Requires multiple forms of verification, such as passwords, biometrics, and hardware tokens. +- **Public Key Infrastructure (PKI)**: Uses cryptographic keys to authenticate users and devices. + +By implementing strong authentication, we can ensure that only legitimate users and devices can access the network, significantly reducing the risk of unauthorized access. + +#### Peer-to-Peer Communication Over an Overlay Network + +Instead of routing all traffic through a central firewall, participants can communicate directly with each other and applications using a peer-to-peer (P2P) overlay network. An overlay network, called Mycelium, can facilitate this decentralized communication. + +- **Mycelium Overlay Network**: This overlay network functions like a mesh, allowing nodes (participants) to connect directly with each other and applications. It provides a resilient and scalable architecture where each node can dynamically find the best path for communication. + +### Whitelists and Group-Based Access Control + +To further enhance security, applications can use whitelists and group-based access control. This approach involves: + +1. **Whitelisting Users**: Only allowing access to users who are explicitly permitted. This can be based on strong authentication credentials. +2. **Group-Based Access Control**: Organizing users into groups with specific permissions. Each application can define which groups have access based on their source IP addresses and other criteria. + +#### Example Scenario + +Consider an application hosted on the network. Instead of relying on a firewall to block unauthorized access, the application uses Mycelium to communicate with authenticated peers. It employs a whitelist to specify which users or groups can access the application. For instance: + +- **Group A**: Developers with access to development resources. +- **Group B**: Administrators with access to administrative tools. +- **Group C**: End-users with access to specific application features. + +Each group’s access is controlled by specifying the allowed source IP addresses and other authentication factors. This ensures that only authorized users can access the application, regardless of their location. + +> only available in the enterprise edition. + diff --git a/docs/key_innovations_overview/network_inno/network_inno.md b/docs/key_innovations_overview/network_inno/network_inno.md new file mode 100644 index 0000000..d519fd1 --- /dev/null +++ b/docs/key_innovations_overview/network_inno/network_inno.md @@ -0,0 +1,21 @@ +--- +title: Network Layer +sidebar_position: 1 +--- + +# Network Layer + +| | ThreeFold Network Layer | Other Overlay Network Technologies (like VPN) | +|-----------------------------|-----------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------| +| Management | Full P2P, done by 3bot Agents, blockchain IT contract | Centralized leading to security issues | +| Locality | Find shortest path on latency and quality, this allows traffic to stay sovereign. | NO, based on centralized control mechanisms or inefficient algorithms that route traffic indiscriminately across the globe. | +| Encryption | End2End ecryption, unique for every relation, linked to private key | Normally based on key exchange, or pre-shared keys. | +| Post Quantum | Possible (ask us) | No | +| Scalability | Our aim is to be planetary scalable, but we need more exposure. | Bad | +| Compatibility | We aim to support mobile, desktop, IOT, ... | Depends, often not | +| Backdoors | NO, all is based on opensource | Often, yes, unfortunately. | +| Performance | Quite good, 1 gbit / sec can be achieved on std node (which is high for overlay) | Often slow. | +| Security Model | Whitelist model | Blacklist model, list who is bad e.g. firewalls | +| Fully integrated in compute | Yes | Lots of different solutions | + + diff --git a/docs/key_innovations_overview/network_inno/virtual_browser.md b/docs/key_innovations_overview/network_inno/virtual_browser.md new file mode 100644 index 0000000..4ade075 --- /dev/null +++ b/docs/key_innovations_overview/network_inno/virtual_browser.md @@ -0,0 +1,76 @@ +--- +title: Virtual Browser +sidebar_position: 5 +--- + +![](../../img/virtual_browser.jpg) + +## Secure Remote Browser Concept + +### Overview + +In this concept, users interact with a secure web application through their web browsers without running JavaScript locally. + +Instead, the actual browser logic and JavaScript execution occur in a secure, remote virtual browser hosted in a secure part of a private cloud. This setup provides enhanced security and control, ensuring that users are protected from malicious scripts and other threats. + +### Key Components + +1. **Client-Side Browser (Local Browser)** + - **Rendering Only**: The user's local browser is responsible only for rendering content. It draws the user interface using technologies like HTML5 Canvas. + - **No Local JavaScript Execution**: No JavaScript code runs on the local browser, eliminating the risk of client-side script attacks. + +2. **Remote Browser (Virtual Browser)** + - **Secure Execution Environment**: The remote browser runs within a secure container in the cloud. For example, this could be within the secure network of a bank. + - **JavaScript Execution**: All JavaScript execution happens in the remote browser. This environment is tightly controlled and monitored. + - **Context Validation**: Each JavaScript file executed is checked to ensure it originates from the original, built application. This prevents unauthorized or malicious scripts from running. + +3. **Session Management** + - **Ephemeral Sessions**: Each user session is temporary. After a session ends, the context is destroyed and rebuilt for the next session, ensuring a clean state each time. + - **Session Recording**: Sessions can be recorded, similar to screen CCTV, for auditing and security purposes. This allows for detailed monitoring and review if needed. + +4. **Network Service Lists and Mycelium Integration** + - **Secure Communication**: The connection between the local browser and the remote browser uses end-to-end encryption. The Mycelium overlay network ensures the shortest path and secure, peer-to-peer communication. + - **Access Control**: Network service lists and group-based access control manage which users can access specific applications, enhancing security and control. + +### Example Workflow + +1. **User Initiates Connection** + - The user opens their local browser and navigates to the bank's application URL. + - The local browser connects to the remote browser hosted in the bank's secure cloud environment. + +2. **Remote Browser Setup** + - A new, secure container is instantiated for the user's session. + - The remote browser loads the bank's application and validates all JavaScript files. + +3. **Rendering in Local Browser** + - The remote browser executes the JavaScript and sends the rendered output to the local browser. + - The local browser draws this output on the canvas, providing a seamless user experience. + +4. **Session Management** + - Throughout the session, all interactions are processed by the remote browser. + - User interactions (e.g., clicks, form submissions) are sent to the remote browser, which processes them and updates the rendered output accordingly. + +5. **Session Termination** + - When the user finishes their session, the remote browser context is destroyed. + - Any recorded session data is stored securely for auditing purposes. + +### Benefits + +1. **Enhanced Security** + - By not running JavaScript locally, the risk of client-side attacks such as cross-site scripting (XSS) is eliminated. + - The remote browser's secure environment ensures that only validated scripts execute. + +2. **Controlled Environment** + - The bank has full control over the execution environment, allowing for stringent security policies and monitoring. + - Ephemeral sessions ensure that each user starts with a clean slate, reducing the risk of persistent threats. + +3. **Auditing and Compliance** + - Session recording provides a detailed audit trail, which is valuable for security reviews and compliance with regulatory requirements. + +4. **Improved User Experience** + - Users benefit from a secure browsing experience without performance degradation, as rendering is offloaded to the client's local browser. + +### Integration with Mycelium and Network Service Lists +By combining this remote browser concept with Mycelium and network service lists, we can ensure secure and efficient communication: +- **Mycelium Overlay Network**: Ensures that the connection between the local and remote browser is routed through the most efficient path, leveraging peer-to-peer connections where possible. +- **Network Service Lists**: Manage which users and groups can access the remote browser and specific applications, providing fine-grained access control. diff --git a/docs/key_innovations_overview/storage_inno/_category_.json b/docs/key_innovations_overview/storage_inno/_category_.json new file mode 100644 index 0000000..9e8ed08 --- /dev/null +++ b/docs/key_innovations_overview/storage_inno/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Storage", + "position": 3, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/key_innovations_overview/storage_inno/fungistor_innovation.md b/docs/key_innovations_overview/storage_inno/fungistor_innovation.md new file mode 100644 index 0000000..6f2c644 --- /dev/null +++ b/docs/key_innovations_overview/storage_inno/fungistor_innovation.md @@ -0,0 +1,32 @@ +--- +title: FungiStor +sidebar_position: 4 +--- + +## FungiStor (End 2024) + +### The Problem + +Existing blockchain, internet, and P2P content delivery and storage systems suffer from sluggish performance and are too expensive. Content retrieval is often slow, and the overhead for ensuring redundancy is excessive. We require innovative approaches to facilitate efficient information sharing among users. + +Content delivery frequently represents the most significant expense for social networks. Running a basic social video network for 10 million users currently costs approximately $2 million per month using traditional cloud providers. We have the potential to reduce this cost by several orders of magnitude. + + +### Introducing FungiStor + +FungiStor is a peer-to-peer (P2P) content delivery layer designed to store and distribute an extensive range of objects, including images, videos, files, and more. It has the capability to handle trillions of objects and files efficiently. FungiStor serves as an excellent solution for content delivery networks (CDNs), significantly reducing costs for organizations seeking to stream or deliver substantial data volumes to their user base. + + +### The Benefits + +- **Global scalability, sub-50ms lookups:** FungiStor scales worldwide with ultra-fast data retrieval under 50 milliseconds. +- **Localized content delivery:** prioritizes local data access for optimized speed and efficiency. +- **Quantum-Safe security:** incorporates robust quantum security measures. +- **Interoperability:** works seamlessly with IPFS, Torrent, and more. +- **Cost efficiency:** offers significant cost savings, potentially 10 to 100 times less than conventional solutions. + +### Status + +Planned for the end of 2024 + +Remark, FungiStor will act as the backend infrastructure for the Flists within our own system. It is versatile and can be utilized by anyone in need of a global-level content delivery system for files, objects, and images. diff --git a/docs/key_innovations_overview/storage_inno/qsfs_innovation.md b/docs/key_innovations_overview/storage_inno/qsfs_innovation.md new file mode 100644 index 0000000..906c751 --- /dev/null +++ b/docs/key_innovations_overview/storage_inno/qsfs_innovation.md @@ -0,0 +1,32 @@ +--- +title: Quantum Safe Storage +sidebar_position: 2 +--- + +## Quantum Safe File System + + + +### The Problem + +There is a growing need for more accessible and user-friendly solutions to store and manage large volumes of data efficiently. + +While Zero-Stor addresses numerous storage challenges effectively, it may not be accessible or user-friendly for typical developers or system administrators. QSFS has been developed to bridge this gap and provide a more approachable storage solution. + +### Introducing QSFS + +A filesystem utilizing Zero-Stor as its backend. Metadata is safeguarded to prevent loss, inheriting Zero-Stor's benefits and simplifying usage for developers and system administrators. + +The filesystem is always deployed in one location, data is distributed (using zero-stor) across multiple sites for unparalleled reliability. + +Metadata redundancy is included. While not consistently synchronized in real-time, the system allows configuration of consistency levels. Typically, the decentralized state may lag by up to 15 minutes. + +This filesystem can be mounted under various storage-aware applications, such as backup servers, file servers, or S3 servers, enhancing versatility. + +### Benefits + +- Inherits the advantages of Zero-Stor, including enhanced data security, efficiency, and scalability. +- Provides a user-friendly interface for seamless integration with a wide range of applications. +- Offers considerable scalability capabilities, although not unlimited in scale. +- Achieves reasonable performance data transfer rates of up to 50 MB/sec, particularly for larger files. +- Can scale to about 2 million files per filesystem. \ No newline at end of file diff --git a/docs/key_innovations_overview/storage_inno/storage_inno.md b/docs/key_innovations_overview/storage_inno/storage_inno.md new file mode 100644 index 0000000..049bc06 --- /dev/null +++ b/docs/key_innovations_overview/storage_inno/storage_inno.md @@ -0,0 +1,22 @@ +--- +title: Storage Layer +sidebar_position: 1 +--- + +![](../../img/storage_inno.png) + +# Storage + + +| | ThreeFold Storage Layer | Overlay Storage Systems | +|-----------------------------|------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------| +| Quantum Safe | Yes, novel encoding system (not encryption based) makes impossible to hack data. | No | +| Post Quantum | Possible (ask us) | No | +| Scalability | Yes, this system exists +10 years, is being used by large orgs for zetabytes. | Some systems, most not, but centralized. | +| Compatibility | Yes thanks to filesystem approach | Depends, often not | +| Backdoors | NO, all is based on opensource | ? | +| Performance | Is not a super fast system but good for most cases, +- 100 MB / sec per content creator. | Variable, hard to say, some are | +| Efficiency for redundancy | Ultra efficient, only 20% overhead to allow 4 locations to go down | NO, sometimes +5 copies = 500% | +| Fully integrated in compute | Yes | Lots of different solutions | +| Management | Full P2P, done by 3bot Agents, blockchain IT contract | Centralized leading to security issues | +| Locality | Data can be local and sovereign, full control by the the user (data creator) | Based on centralized control mechanisms or inefficient algorithms that route traffic indiscriminately across the globe. | diff --git a/docs/key_innovations_overview/storage_inno/zstor_innovation.md b/docs/key_innovations_overview/storage_inno/zstor_innovation.md new file mode 100644 index 0000000..a495180 --- /dev/null +++ b/docs/key_innovations_overview/storage_inno/zstor_innovation.md @@ -0,0 +1,13 @@ +--- +title: Quantum Safe Filesystem +sidebar_position: 3 +--- + + +## Zero-Stor : A Quantum Safe Backend Storage System + +Zeros-Stor is a quantum safe backend storage system that use efficient algorithms to ensure maximal use of storage. + +![](../../img/qsss.png) + +!!wiki.include page:zstor_innovation_short \ No newline at end of file diff --git a/docs/roadmap/_category_.json b/docs/roadmap/_category_.json new file mode 100644 index 0000000..4f1803e --- /dev/null +++ b/docs/roadmap/_category_.json @@ -0,0 +1,7 @@ +{ + "label": "Roadmap", + "position": 6, + "link": { + "type": "generated-index", + } + } \ No newline at end of file diff --git a/docs/roadmap/enterprise_roadmap.md b/docs/roadmap/enterprise_roadmap.md new file mode 100644 index 0000000..2aa3e54 --- /dev/null +++ b/docs/roadmap/enterprise_roadmap.md @@ -0,0 +1,53 @@ +--- +title: Enterprise Roadmap +sidebar_position: 2 +--- + + +# Government, Commercial hosters, Telco and Enterprise Roadmap + +We are working on our Government, Commercial hosters, Telco and Enterprise Release of our Technology. + +> 90% of the work has been done as part of our base offering but we need additional features for enterprise + +## Enterprise User Interface + +The current user interface is designed for an open-source tech audience. For enterprise use, we need a different approach to meet the unique needs of enterprise environments: + +- **Private or Hybrid Context**: All operations should be conducted within a private or hybrid cloud context to ensure security and compliance. +- **Enhanced Monitoring**: We need more comprehensive monitoring dashboard screens to provide real-time insights and analytics. +- **Identity Management Integration**: Integration with enterprise-grade Identity Management solutions, such as LDAP, Active Directory, and SSO (Single Sign-On), is essential. +- **Enterprise-Friendly UI**: The user interface needs to be redesigned to be more intuitive and tailored to enterprise users, focusing on usability and efficiency. +- **Token Irrelevance**: Tokens are not a priority in this context and should be de-emphasized in the solution. + +## Windows Support + +The virtual Machine technology we use does support windows, but we need to do some further integration. + +## High Performance Network Integration + +- **Local Network Integration**: Zero-OS is designed to support a wide range of technologies, though additional integration work is required to optimize performance. +- **High-Speed Backbones**: We aim to support high-speed Ethernet and RDMA (Infiniband) based backbones. +- **Instrumentation Enhancements**: Additional instrumentation needs to be incorporated into Zero-OS to achieve optimal performance. +- **Target Performance**: Our goal is to achieve network speeds exceeding 100 Gbps. +- **Custom Integration**: We offer integration with selected network equipment from our customers, accommodating custom integration requirements. + +## High Performance Storage Block Device Integration + +Next to the existing already integrated storage backends we want to support a high performance redundant storage block device. + +- High performance redundant storage network +- Supports our high speed backbone as defined above +- Scalable to thousands of machines per cluster. +- Replication capability between zones. +- **Custom Integration**: We offer integration with selected storage equipment from our customers, accommodating custom integration requirements. + +## Service Level Management + +- The system will have hooks and visualization for achievement of Service levels. +- This will allow a commercial service provider to get to higher revenue and better uptime management. + +## Support for Liquid Cooling tanks + +- Do a test setup in liquid cooling rack or node, we can use our selfhealing capabilities to manage better. +- Is Integration effort, not really code changes \ No newline at end of file diff --git a/docs/roadmap/hero_roadmap.md b/docs/roadmap/hero_roadmap.md new file mode 100644 index 0000000..b05be21 --- /dev/null +++ b/docs/roadmap/hero_roadmap.md @@ -0,0 +1,28 @@ +--- +title: Hero Roadmap +sidebar_position: 4 +--- + + +## Hero (3Bot) High Level Roadmap + +The first version of our Hero enables the management of core services such as an innovative database backend, a sovereign git system, and the automatic integration and deployment of our workloads. + +This stack allows everyone to deploy scalable web 2/3/4 apps on top of the TFGrid. + + +| | Roadmap | Timing | +| -------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------ | +| Hero Publisher | Publish websites, e-books, ... on top of TFGrid | Q4 24 | +| Hero CI = Continuous Integration | Easier to use Continuous Integration / Development, very powerfull, with multi node support | Q4 24 | +| Hero Play | Integrate declarative automation and configuration management as part of wiki approach in hero Publisher | Q4 24 | +| Hero Git | Alternative to centralized Github (based on Gitea), fully integrated on top of TFGrid | Q4 24 | +| Hero DB | Flexible ultra redundant database stor with indexing, queries, stored procesudes, super scalable replication | Q4 24 | +| Hero OSIS | Object Storage and Index system integrates with hero Git, all data on git based backend | Q4 24 | +| Hero WEB | Web framework (with co-routines) using Vlang, deployable globally on TFGrid, integrated with Mycelium Net and Names. | Q4 24 | +| Hero Monitor | Monitor all your different components on redundant monitoring stack | Q4 24 | +| Hero Happs | Hero natively supports Holochain HAPPS | Q1 25 | +| Hero Actors | Hero can serve actors which respond and act on OpenRPC calls ideal as backend for web or other apps. | Q1 25 | +| Hero Web 3 Gateway | Hero aims to have native support for chosen Web3 partner solutions | Q1 25 | + +All of above is fully integrated with Mycelium Network and the TF Grid. diff --git a/docs/roadmap/roadmap.md b/docs/roadmap/roadmap.md new file mode 100644 index 0000000..fc66441 --- /dev/null +++ b/docs/roadmap/roadmap.md @@ -0,0 +1,43 @@ +--- +title: Roadmap in Phases +sidebar_position: 1 +--- + + +![](../img/roadmap.jpg) + +# Roadmap in Phases + +## phase 1: wave 1 of companies, leading to our expertise + +- technology creation, was result of 20 years of evolution +- 7 startups acquired as part of this process +- technology used globally by big vendors +- +600m USD Exits + +## phase 2: proof of tech + +- Technology launched globally (as opensource) +- +60,000,000 vcpu active +- Large scale proof of core technology +- Focus on early adoptors in tech space (cloud, web 2/3 ...) +- 50m USD funded by founders, community and farmers (people providing capacity) + +## phase 3: commercialization & global expansion + +### phase 3.1: Commercial Partners + +- ThreeFold Launches with Commercial Strategic Partners + - Telco Operatators + - IT Integrators +- Enterprise Roadmap delivered < 6 months (is mainly integration, documentation and UI work) +- Together with partners we deliver on the many projects which are in our funnel today e.g. East Africa, Brazil + +### phase 3.2: Large Scale Financancing for Infrastructure + +**Large scaling financing round** + +- financing for infrastructure projects (trillions available right now for infra in emerging countries) +- Public STO (security token offering), let world co-own the infra for their Internet +- large partnerships drive alternative to Tier 3/4 Datacenters + diff --git a/docs/roadmap/tfgrid_roadmap.md b/docs/roadmap/tfgrid_roadmap.md new file mode 100644 index 0000000..d1c27be --- /dev/null +++ b/docs/roadmap/tfgrid_roadmap.md @@ -0,0 +1,61 @@ +--- +title: Open-Source TFGrid Roadmap +sidebar_position: 3 +--- + + +## TFGrid High Level Roadmap + +### Status Today + +The core offering is functioning effectively, maintained through a community-driven, best-effort approach. Currently, +there are no Service Level Agreements (SLAs) in place, and there should be increased visibility for users regarding their expectations for uptime, +performance, and other service related requirements. + +The uptime and stability of Zero-OS are very good. + +Additionally, hardware compatibility is excellent, with most machines now supported out of the box. + + +| | Status today | SDK/API | Web UI | +| ----------------------- | ------------------------------------------------------------------------------------------------------------ | ------- | ------ | +| Zero-OS | Used for management of +30,000 logical CPU cores | yes | yes | +| Zero-Images (flists) | Basis for Zero-OS modules as well as replaces images for VM's ... | yes | yes | +| Zero-Images from Docker | convert docker through our Hub | yes | yes | +| Zero-Images Hub | ThreeFold is hosting some as well as everyone can install their own Hub | yes | yes | +| Mycelium Core | Integrated in Zero-OS for VM's as well s ZDB and monitoring | yes | yes | +| Mycelium Message Bus | Can be used by any developer for their own usecases | NA | NA | +| Quantum Safe Storage | Usable for experts only, is reliably working for +6 years, +100 MB/sec per stream | yes | no | +| Quantum Safe Filesystem | QSFS= usable for experts, is a fuse based filesystem on top of the QSS Core | yes | no | +| Zero-OS Kubernetes | Working very well, Integrated in ZOS, uses our overlay networks based on Wireguard, can use QSFS underneith. | yes | yes | +| Zero-OS VM's | The base of our service portfolio, missing is better service level management | yes | yes | +| Zero-OS Monitoring | Working well | yes | yes | +| Zero-OS VM Monitoring | Working well, can be retrieved through SDK | yes | yes | +| Zero-OS Web Gateway | Working well, but documentation not good enough, and not enough of them deployed | yes | yes | +| Zero-Boot | There are multiple ways active on how to deploy Zero-OS all are stateless and capable for full secure boot | | | + +### Planned new features: + +Considerable effort is being made to enable our partners to go into production; +however, for this initiative to truly succeed on planetary level, we need many more nodes deployed in the field. + +Below you can find some of the planned features of TFGrid 4.0 mainly to achieve ability to scale to hundred of thousand of nodes. + +| | Roadmap | Timing | +| ----------------------------------- | ---------------------------------------------------------------- | ------ | +| Zero-OS v4 (our next major release) | v4, no more TFChain, mutual credit, marketplace | Q1 25 | +| FungiStor | A revolutionary different way how to deliver content | Q1 25 | +| Zero-Images on FungiStor | Can be stored on FungiStor | Q1 25 | +| Zero-Images from Docker | CI/CD integration (See Hero CI/CD) | Q4 24 | +| Zero-Images Hub | CI/CD integration (See Hero CI/CD) no more need for separate Hub | Q4 24 | +| Mycelium Core | Just more hardening and testing | Q4 24 | +| Mycelium Message Bus | Replace our current RMB, all our own RPC over Mycelium | Q4 24 | +| Quantum Safe Storage | Integration in UI, better documentation | Q4 24 | +| Quantum Safe Filesystem | Integration in UI, better documentation | Q4 24 | +| Zero-OS Kubernetes | No changes planned | | +| Zero-OS VM's | Integration Hero CI , use cloud slices to manage | Q1 25 | +| Zero-OS Monitoring | More docu and easier API | Q1 25 | +| Zero-OS Web Gateway | Need more deployed, better integration with new Mycelium | Q4 24 | +| Zero-Boot | No changes planned | | +| Mycelium Names | in v4, name services | Q1 25 | +| Zero-OS Cloud,Storage,AI Slices | as part of marketplace for v4, flexible billing mutual credit | Q1 25 | \ No newline at end of file