...
@ -12,7 +12,7 @@ echo "Docs directory: $script_dir"
|
||||
# Change baseUrl to '/tftechdev/'
|
||||
sed -i "s|/tftech/|/tftechdev/|g" docusaurus.config.ts ./src/pages/index.tsx
|
||||
|
||||
bun build
|
||||
bun docusaurus build
|
||||
|
||||
rsync -rv --delete ${script_dir}/build/ root@info.ourworld.tf:/root/hero/www/info/tftechdev
|
||||
|
||||
|
2
build.sh
@ -9,6 +9,6 @@ export PATH=${BASE}/node_modules/.bin:$PATH
|
||||
|
||||
echo "Docs directory: $script_dir"
|
||||
|
||||
bun build
|
||||
bun docusaurus build
|
||||
|
||||
rsync -rv --delete ${script_dir}/build/ root@info.ourworld.tf:/root/hero/www/info/tftech
|
||||
|
@ -1,7 +0,0 @@
|
||||
{
|
||||
"label": "Core Features",
|
||||
"position": 9,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
}
|
@ -1,7 +0,0 @@
|
||||
{
|
||||
"label": "Compute",
|
||||
"position": 2,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
}
|
@ -1,24 +0,0 @@
|
||||
---
|
||||
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
|
@ -1,39 +0,0 @@
|
||||
---
|
||||
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.
|
||||
|
@ -1,35 +0,0 @@
|
||||
---
|
||||
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
|
@ -1,46 +0,0 @@
|
||||
---
|
||||
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.
|
||||
|
||||
|
||||
|
@ -1,7 +0,0 @@
|
||||
{
|
||||
"label": "Network",
|
||||
"position": 4,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
}
|
@ -1,7 +0,0 @@
|
||||
{
|
||||
"label": "Storage",
|
||||
"position": 2,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
}
|
7
docs/geoaware/_category_.json
Normal file
@ -0,0 +1,7 @@
|
||||
{
|
||||
"label": "The Solution \"Geo Aware\"",
|
||||
"position": 3,
|
||||
"link": {
|
||||
"type": "generated-index"
|
||||
}
|
||||
}
|
32
docs/geoaware/geo_aware.md
Normal file
@ -0,0 +1,32 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
title: 'What is Geo Awareness'
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
![](img/geo_aware.png)
|
||||
|
||||
## What is Geo Awareness
|
||||
|
||||
**Geo-awareness** ensures that digital systems operate with respect to geographic and physical realities. This concept radically shifts how we approach storage, computation, and networking by enabling location-centric control and efficiency. Here's what it entails:
|
||||
|
||||
#### Key Features of Geo-Awareness:
|
||||
|
||||
1. **Shortest Physical Path for Communication**
|
||||
Communication between two parties happens through the shortest physical route, reducing latency and energy consumption while increasing efficiency.
|
||||
|
||||
2. **Data Sovereignty and Integrity**
|
||||
Users can decide where their data is stored. The data remains incorruptible and accessible only to the user or their personal AI agent, ensuring data privacy and sovereignty.
|
||||
|
||||
3. **Resilient Internet Functionality**
|
||||
Even in cases of internet outages or disasters, most apps and services remain operational, ensuring reliability and continuity.
|
||||
|
||||
4. **Control Over Applications and AI**
|
||||
Geo-awareness enables users to decide where their applications and personal AI agents operate, giving them full control over their digital footprint and reducing external vulnerabilities.
|
||||
|
||||
5. **Transparent Deployment of Code**
|
||||
Knowing exactly which code or app is deployed where ensures security and prevents tampering.
|
||||
|
||||
6. **Relevance for Nations and Public Infrastructure**
|
||||
Unlike public blockchains that lack geo-awareness, this model empowers countries with localized control, enhancing sovereignty and trust.
|
||||
|
BIN
docs/geoaware/img/geo_aware.png
Normal file
After Width: | Height: | Size: 792 KiB |
BIN
docs/geoaware/img/geo_aware2.png
Normal file
After Width: | Height: | Size: 884 KiB |
BIN
docs/geoaware/img/geo_aware3.png
Normal file
After Width: | Height: | Size: 648 KiB |
66
docs/geoaware/solution.md
Normal file
@ -0,0 +1,66 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
title: 'Solution For a Better Internet'
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
![](img/geo_aware3.png)
|
||||
|
||||
## Geo Awareness is the Solution for many of the Internet Problems
|
||||
|
||||
The problems:
|
||||
|
||||
- [Compare Electricity](../internet_today/compare_electricity.md) - Compares the inefficiency of relying on distant internet infrastructure to the absurdity of using electricity generated on the other side of the world.
|
||||
- [Internet Basics](../internet_today/internet_basics.md) - Explains the three fundamental layers of the internet: compute/AI/storage, network, and applications, highlighting current centralization issues.
|
||||
- [Centralization Risk](../internet_today/centralization_risk.md) - Details the dangers of relying on centralized infrastructure and services, using real-world examples like the Ukraine conflict.
|
||||
- [The Race For Intelligence](../internet_today/ai.md) - Discusses how AI agents will replace traditional apps within 2 years and the implications of centralized AI development.
|
||||
- [GDP Negative Impact](../internet_today/gdp_negative.md) - Reveals how the current internet structure causes economic losses for developing nations, with case studies showing billions in yearly losses.
|
||||
- [Internet Protocol Is Broken](../internet_today/internet_risk.md) - Explains why TCP/IP's outdated design is inadequate for modern internet needs and explores RINA as a potential solution.
|
||||
- [Painkillers Approach](../internet_today/onion_analogy.md) - Uses an onion analogy to illustrate how adding layers to internet infrastructure masks symptoms rather than solving core problems.
|
||||
|
||||
|
||||
**The following table shows how the problems as listed above are fixed because of geo awareness.**
|
||||
|
||||
|
||||
| **Problem Area** | **Web2** | **Web3** | **Web 0 = Geo-Aware** |
|
||||
| ---------------------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- |
|
||||
| **Centralization** | Dominated by a few corporations; creates fragility and dependency. | Often more Decentralized, but lacks local autonomy; often relies on centralized validators and still datacenters. | Fully decentralized and location-specific, empowering local infrastructure and sovereignty. |
|
||||
| **Data Sovereignty** | Data stored in centralized data centers controlled by corporations. | Decentralized storage, but users often lack control over physical location. | Users choose specific locations for data storage, ensuring sovereignty and privacy. |
|
||||
| **Infrastructure Resilience** | Vulnerable to disasters, geopolitical issues, and single points of failure. | Often less resilient compared to Web2 (^1) | Shortest physical paths and local redundancies ensure continued operation during disruptions. New paths are found when needed even by using nodes from your friends |
|
||||
| **Economic Impact (GDP Negative)** | High costs for infrastructure; revenue flows to global platforms. | The validators are still too centralized and often hosted in centralized datanceters. Too complicated and too early days to help right now. | Localized infrastructure boosts regional economies, keeping revenue within countries. |
|
||||
| **Internet Efficiency** | Long data routes; underutilized hardware; inefficient layers. | Reliant on outdated protocols, vulnerable because of used ledger tech (^1) and layered inefficiencies. | Shortest paths reduce latency and cost; full hardware optimization ensures efficiency. |
|
||||
| **Security and Transparency** | Complex, security by smart employees of the corporations. | Smart contracts improve security, but issues remain as code upgrade path. | Transparent and tamper-proof deployments ensure security and resilience. |
|
||||
| **Layer Complexity** | Redundant layers create inefficiencies and fragility. | Often web3 is more complex compared to web 2. | Simplifies architecture by localizing compute, storage, and networking. 10x less development effort is possible |
|
||||
| **Application Hosting** | Hosted in large centralized data centers, increasing latency and cost. | Sometimes, decentralized hosting but not geographically optimized. | Applications can be hosted locally, reducing latency and ensuring autonomy. |
|
||||
| **Access Inequality** | Over 50% of the world lacks reliable access. | Expands access but without addressing local infrastructure challenges. | Geo-aware systems build localized, affordable infrastructure to improve access. |
|
||||
| **Session Management** | Breaks under interruptions; no native continuity. | Some continuity improvements via decentralized protocols. | Built-in session management ensures reliability even during disruptions. |
|
||||
|
||||
|
||||
|
||||
### Challenges in the Current Depin (Decentralized Internet) World
|
||||
|
||||
Despite advancements in decentralized technology, geo-awareness remains under-prioritized.
|
||||
|
||||
Current Web3 solutions focus on decentralization without accounting for the geographic efficiency or sovereignty that geo-awareness offers.
|
||||
|
||||
---
|
||||
|
||||
### Comparison Table: Current Web3 Solutions vs. Geo-Aware Systems
|
||||
|
||||
|
||||
| **Feature** | **Current Web3 Solutions** | **Geo-Awareness** |
|
||||
| ----------------------- | ------------------------------------------------------- | -------------------------------------------------------- |
|
||||
| **Storage** | Global, often randomly distributed without user control | Users choose storage locations; data remains sovereign |
|
||||
| **Compute** | Decentralized but lacks location-specific optimization | Compute occurs at chosen locations; optimized for region |
|
||||
| **Network** | Relies on global, non-optimized routing | Shortest physical path for communication |
|
||||
| **Ledger** | Public blockchains are unreliable in case of network issues | Location-aware sovereign ledgers for national and local control |
|
||||
| **Resilience** | Vulnerable to global internet disruptions | Independent operation during outages |
|
||||
| **Application Control** | Limited transparency on app deployment locations and upgrade paths. | Full control and visibility of app deployment |
|
||||
| **Data Integrity** | Prone to distributed risks and complexities | Tamper-proof, user-controlled data access |
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Why Geo-Awareness Matters
|
||||
|
||||
The current centralized and globalized digital architecture exacerbates inefficiencies, compromises sovereignty, and creates economic dependencies. Geo-awareness addresses these problems by creating a decentralized yet location-sensitive framework. This ensures that infrastructure is resilient, secure, and operates in harmony with the physical realities of the world, ultimately empowering users and nations alike.
|
@ -1,6 +1,6 @@
|
||||
{
|
||||
"label": "Internet Re-Invented",
|
||||
"position": 3,
|
||||
"position": 4,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
|
@ -2,7 +2,7 @@
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Architecture
|
||||
# Threefold Architecture
|
||||
|
||||
![](img/architecture_high_level.png)
|
||||
|
||||
|
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Internet Re-Invented
|
||||
title: Internet Natural Progression
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
|
@ -21,7 +21,8 @@ In the decentralized infrastructure (DePIN) space, establishing trust and reliab
|
||||
|
||||
Customers often prefer to pay a higher price for cloud, AI, Internet 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.
|
||||
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 op
|
||||
erations.
|
||||
|
||||
### Service Level Agreements (SLAs)
|
||||
|
||||
|
@ -1,12 +1,9 @@
|
||||
---
|
||||
title: Decentralized Cloud Technology
|
||||
sidebar_position: 1
|
||||
title: Geo-Aware Cloud
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
|
||||
# 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)
|
||||
|
14
docs/key_innovations_overview/compute_inno/for_everyone.md
Normal file
@ -0,0 +1,14 @@
|
||||
---
|
||||
title: 'For Everyone'
|
||||
sidebar_position: 2
|
||||
description: 'Everyone can build on top of the ThreeFold new internet'
|
||||
# hide_title: true
|
||||
---
|
||||
|
||||
## Zero-OS is easy to dploy
|
||||
|
||||
![](img/zos_simple.png)
|
||||
|
||||
## Everyone Can Build
|
||||
|
||||
![](img/for_everyone.png)
|
BIN
docs/key_innovations_overview/compute_inno/img/deterministic.png
Normal file
After Width: | Height: | Size: 70 KiB |
BIN
docs/key_innovations_overview/compute_inno/img/for_everyone.png
Normal file
After Width: | Height: | Size: 233 KiB |
After Width: | Height: | Size: 142 KiB |
BIN
docs/key_innovations_overview/compute_inno/img/superhub.png
Normal file
After Width: | Height: | Size: 481 KiB |
BIN
docs/key_innovations_overview/compute_inno/img/zos_intro.png
Normal file
After Width: | Height: | Size: 134 KiB |
BIN
docs/key_innovations_overview/compute_inno/img/zos_simple.png
Normal file
After Width: | Height: | Size: 307 KiB |
16
docs/key_innovations_overview/compute_inno/super_hub.md
Normal file
@ -0,0 +1,16 @@
|
||||
---
|
||||
title: 'Super HUB'
|
||||
sidebar_position: 20
|
||||
description: 'Ultra scalable architecture.'
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
|
||||
## Superhub Architecture
|
||||
|
||||
|
||||
![](img/superhub.png)
|
||||
|
||||
|
||||
|
||||
|
@ -1,13 +1,15 @@
|
||||
---
|
||||
title: Deterministic Deploy
|
||||
sidebar_position: 3
|
||||
sidebar_position: 5
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
|
||||
![Smart Contract Deployment](../../img/smartcontract_deploy.png)
|
||||
# Deterministic Deployment
|
||||
|
||||
|
||||
![](img/deterministic.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.
|
||||
@ -15,24 +17,28 @@ The concept of Zero-Deploy is a key component of the **Smart Contract for IT** f
|
||||
### Process
|
||||
|
||||
1. **Build Your Code**
|
||||
Develop and prepare your application code.
|
||||
2.
|
||||
Develop and prepare your application (AI agents, web 2, web 3) 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. **Convert to Zero-Image**
|
||||
|
||||
Use a CI/CD solution to convert your Docker build (or other format) into a Zero-Image format. The 3Bot will do this on behalf of the user in the future.
|
||||
|
||||
4. **Define the Workload**
|
||||
|
||||
3. **Define the Workload**
|
||||
Specify all the details of your workload, including network bridges, web gateways, required machines, and more.
|
||||
|
||||
4. **Register and Sign**
|
||||
5. **Register and Sign**
|
||||
|
||||
Register the workload and sign it with your private key.
|
||||
|
||||
5. **Automatic Detection**
|
||||
6. **Automatic Detection**
|
||||
All necessary Zero-OS nodes (our infrastructure) will detect that a new workload needs to be deployed.
|
||||
|
||||
6. **Deployment Process**
|
||||
7. **Deployment Process**
|
||||
The nodes will pull down the formal workload descriptions and initiate the deployment process.
|
||||
|
||||
7. **Validation**
|
||||
8. **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
|
||||
@ -40,3 +46,5 @@ The concept of Zero-Deploy is a key component of the **Smart Contract for IT** f
|
||||
- **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.
|
||||
|
||||
|
||||
|
||||
|
@ -1,11 +1,68 @@
|
||||
---
|
||||
title: 'ZOS - geo-aware OS'
|
||||
sidebar_position: 1
|
||||
description: The computer layer of the grid
|
||||
description: The computer layer
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
# Compute Layer
|
||||
|
||||
| | Compute Layer | Default |
|
||||
![](img/zos_intro.png)
|
||||
|
||||
# ZOS - geo-aware OS
|
||||
|
||||
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.
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
## 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**
|
||||
|
||||
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
|
||||
|
||||
## benefits
|
||||
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
| | Zos Compute Layer Benefits | 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 |
|
||||
@ -15,50 +72,14 @@ description: The computer layer of the grid
|
||||
| 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 |
|
||||
| Sovereign | Yes | Mostly not. |
|
||||
| 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)
|
||||
|
||||
|
@ -0,0 +1,35 @@
|
||||
---
|
||||
title: 'Smart Contract for IT'
|
||||
sidebar_position: 3
|
||||
description: 'How smart contract tech can be used to deploy IT workloads.'
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
|
||||
## Deployment of Workloads Using Secure Smart IT Contracts
|
||||
|
||||
|
||||
![](img/smart_contract_it.png)
|
||||
|
||||
|
||||
|
||||
Workloads can be deployed through a secure and decentralized system enabled by **smart IT contracts**.
|
||||
|
||||
|
||||
These contracts ensure the following:
|
||||
|
||||
1. **Multi-Signature Authorization**
|
||||
Before a workload is deployed, multiple authorized individuals must sign off on the deployment contract. This ensures a consensus-driven process, adding a layer of security and accountability. No single individual has unilateral control over the process.
|
||||
|
||||
2. **Immutable and Autonomous Deployment**
|
||||
Once the deployment is signed and approved, the workload is executed as defined in the smart IT contract. The system ensures that:
|
||||
- No party, including the signers, can alter the deployed workload or access the stored data.
|
||||
- The deployment process is verified, authenticated, and recorded immutably on the blockchain, guaranteeing transparency and trust.
|
||||
|
||||
3. **Managed by Virtual Administrators (3BOTs)**
|
||||
The workloads can optionally be autonomously managed by virtual administrators, known as **3BOTs**. These bots operate as trustworthy system administrators and ensure the deployed solution adheres strictly to the agreed-upon parameters.
|
||||
|
||||
4. **Registered on a Decentralized Geo-Aware Ledger**
|
||||
Once the contract is finalized and deployment occurs, the details are permanently registered in the **TFChain blockchain**, providing an immutable record of the transaction. This further enhances security and transparency.
|
||||
|
||||
By leveraging these mechanisms, the system ensures that IT workloads are deployed securely, remain tamper-proof, and operate in a decentralized, autonomous manner. This approach eliminates risks of unauthorized changes and protects the integrity of deployed solutions.
|
BIN
docs/key_innovations_overview/network_inno/img/how_network.png
Normal file
After Width: | Height: | Size: 116 KiB |
After Width: | Height: | Size: 106 KiB |
After Width: | Height: | Size: 260 KiB |
@ -5,6 +5,16 @@ sidebar_position: 2
|
||||
|
||||
![](../../img/peer2peer_network.jpg)
|
||||
|
||||
# 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'
|
||||
|
||||
## Mycelium: A New Network Layer for the Internet
|
||||
|
||||
![](../../img/mycelium00.png)
|
||||
|
@ -1,76 +0,0 @@
|
||||
---
|
||||
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.
|
@ -3,7 +3,7 @@ title: FungiStor
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
## FungiStor (End 2024)
|
||||
## FungiStor (H2 2025)
|
||||
|
||||
### The Problem
|
||||
|
||||
|
BIN
docs/key_innovations_overview/storage_inno/img/how_data.png
Normal file
After Width: | Height: | Size: 104 KiB |
BIN
docs/key_innovations_overview/storage_inno/img/storage_old.png
Normal file
After Width: | Height: | Size: 140 KiB |
BIN
docs/key_innovations_overview/storage_inno/img/unbreakable2.png
Normal file
After Width: | Height: | Size: 271 KiB |
After Width: | Height: | Size: 569 KiB |
@ -4,7 +4,7 @@ sidebar_position: 3
|
||||
---
|
||||
|
||||
|
||||
## Zero-Stor : A Quantum Safe Backend Storage System
|
||||
## Zero-Stor : An Unbreakable Backend Storage System
|
||||
|
||||
Zeros-Stor is a quantum safe backend storage system that use efficient algorithms to ensure maximal use of storage.
|
||||
|
||||
|