...
41
docs/key_innovations_overview/compute_inno/features.md
Normal file
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Geo-Aware Cloud
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
|
||||
|
||||

|
||||
|
||||
## 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.
|
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
|
||||
|
||||

|
||||
|
||||
## Everyone Can Build
|
||||
|
||||

|
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
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
|
@@ -1,13 +1,15 @@
|
||||
---
|
||||
title: Deterministic Deploy
|
||||
sidebar_position: 3
|
||||
sidebar_position: 5
|
||||
hide_title: true
|
||||
---
|
||||
|
||||
|
||||

|
||||
# Deterministic Deployment
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
## 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 |
|
||||

|
||||
|
||||
# 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
|
||||
|
||||

|
||||
|
||||
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,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
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
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 |
16
docs/key_innovations_overview/network_inno/mycelium.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
title: Mycelium
|
||||
description: Our Planetary Network
|
||||
---
|
||||
|
||||
|
||||
# Mycelium: Our Planetary Network
|
||||
|
||||

|
||||
|
||||
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'
|
@@ -5,6 +5,16 @@ sidebar_position: 2
|
||||
|
||||

|
||||
|
||||
# Mycelium: Our Planetary Network
|
||||
|
||||

|
||||
|
||||
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
|
||||
|
||||

|
||||
|
35
docs/key_innovations_overview/network_inno/networking.md
Normal file
@@ -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.
|
||||
|
||||

|
||||
|
||||
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
|
||||
|
||||

|
||||
|
||||
- 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
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
@@ -1,76 +0,0 @@
|
||||
---
|
||||
title: Virtual Browser
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||

|
||||
|
||||
## 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.
|
43
docs/key_innovations_overview/network_inno/webgw.md
Normal file
@@ -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.
|
||||
|
||||

|
||||
|
||||
### 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
|
||||
|
||||

|
||||
|
||||
### Unlimited Scale
|
||||
|
||||

|
||||
|
||||
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.
|
@@ -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 |
92
docs/key_innovations_overview/storage_inno/nft_storage.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
title: NFT Storage
|
||||
---
|
||||
|
||||
|
||||
# Quantum Safe Storage System for NFT
|
||||
|
||||
Our technology enables quantum safe storage for NFT.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
118
docs/key_innovations_overview/storage_inno/qss_algorithm.md
Normal file
@@ -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
|
||||
|
||||

|
||||
|
||||
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
|
||||
|
||||

|
||||
|
||||
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
|
||||
|
67
docs/key_innovations_overview/storage_inno/qss_filesystem.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Quantum Safe Filesystem
|
||||
|
||||
Our quantum safe filesystem technology has unique features.
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
Any storage workload can be deployed on top of the zstor.
|
||||
|
@@ -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.
|
||||
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
34
docs/key_innovations_overview/storage_inno/qsss_home.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Quantum Safe Storage System
|
||||
|
||||
Our storage architecture follows the true peer2peer design of the cecentralized cloud system.
|
||||
|
||||

|
||||
|
||||
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
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
@@ -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.
|
||||
|
||||
|