update tech book for docusaurus
This commit is contained in:
mik-tf
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"label": "Compute",
|
||||
"position": 1,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
}
|
||||
64
docs/key_innovations_overview/compute_inno/compute_inno.md
Normal file
64
docs/key_innovations_overview/compute_inno/compute_inno.md
Normal file
@@ -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
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
## Compatible with the world
|
||||
|
||||
|
||||
|
||||
|
||||
## 3Bots: The Autonomous Layer
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: Deterministic Deploy
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Zero-Images
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Zero-Install
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
|
||||
|
||||
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
|
||||
Reference in New Issue
Block a user