refactor
This commit is contained in:
28
docs/main/key_innovations_overview/storage/1_storage.md
Normal file
28
docs/main/key_innovations_overview/storage/1_storage.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Unbreakable Storage
|
||||
|
||||
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)
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
|
20
docs/main/key_innovations_overview/storage/20_compare.md
Normal file
20
docs/main/key_innovations_overview/storage/20_compare.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Compare
|
||||
sidebar_position: 20
|
||||
description: 'compare how its dont in other overlay network systems.'
|
||||
---
|
||||
|
||||
|
||||
|
||||
| | ThreeFold Storage Layer | Overlay Storage Systems |
|
||||
|-----------------------------|------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------|
|
||||
| Unbreakable | Yes, novel encoding system (not encryption based) makes impossible to hack data. | No |
|
||||
| Post Quantum | Possible (ask us) | No |
|
||||
| Scalability | Yes, this system exists +10 years, is being used by large orgs for zetabytes. | Some systems, most not, but centralized. |
|
||||
| Compatibility | Yes thanks to filesystem approach | Depends, often not |
|
||||
| Backdoors | NO, all is based on opensource | ? |
|
||||
| Performance | Is not a super fast system but good for most cases, +- 100 MB / sec per content creator. | Variable, hard to say, some are |
|
||||
| Efficiency for redundancy | Ultra efficient, only 20% overhead to allow 4 locations to go down | NO, sometimes +5 copies = 500% |
|
||||
| Fully integrated in compute | Yes | Lots of different solutions |
|
||||
| Management | Full P2P, done by 3bot Agents, blockchain IT contract | Centralized leading to security issues |
|
||||
| Locality | Data can be local and sovereign, full control by the the user (data creator) | Based on centralized control mechanisms or inefficient algorithms that route traffic indiscriminately across the globe. |
|
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: File System
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
### The Problem
|
||||
|
||||
There is a growing need for more accessible and user-friendly solutions to store and manage large volumes of data efficiently.
|
||||
|
||||
While Zero-Stor addresses numerous storage challenges effectively, it may not be accessible or user-friendly for typical developers or system administrators. QSFS has been developed to bridge this gap and provide a more approachable storage solution.
|
||||
|
||||
### Introducing QSFS
|
||||
|
||||
A filesystem utilizing Zero-Stor as its backend. Metadata is safeguarded to prevent loss, inheriting Zero-Stor's benefits and simplifying usage for developers and system administrators.
|
||||
|
||||
The filesystem is always deployed in one location, data is distributed (using zero-stor) across multiple sites for unparalleled reliability.
|
||||
|
||||
Metadata redundancy is included. While not consistently synchronized in real-time, the system allows configuration of consistency levels. Typically, the decentralized state may lag by up to 15 minutes.
|
||||
|
||||
This filesystem can be mounted under various storage-aware applications, such as backup servers, file servers, or S3 servers, enhancing versatility.
|
||||
|
||||
### Benefits
|
||||
|
||||
- Inherits the advantages of Zero-Stor, including enhanced data security, efficiency, and scalability.
|
||||
- Provides a user-friendly interface for seamless integration with a wide range of applications.
|
||||
- Offers considerable scalability capabilities, although not unlimited in scale.
|
||||
- Achieves reasonable performance data transfer rates of up to 50 MB/sec, particularly for larger files.
|
||||
- Can scale to about 2 million files per filesystem.
|
||||
|
||||
|
||||
## Details
|
||||
|
||||
Our Unbreakable filesystem technology has unique features.
|
||||
|
||||
|
||||
A redundant filesystem, can store PB's (millions of gigabytes) of information.
|
||||
|
||||
Unique features:
|
||||
|
||||
- Unlimited scalability (many petabytes)
|
||||
- Unbreakable:
|
||||
- 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 Unbreakable Storage System.
|
||||
|
118
docs/main/key_innovations_overview/storage/3_qss_algorithm.md
Normal file
118
docs/main/key_innovations_overview/storage/3_qss_algorithm.md
Normal file
@@ -0,0 +1,118 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Algoritm
|
||||
|
||||
The UnbreakableStorage 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 UnbreakableStorage 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 UnbreakableStorage 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
|
||||
|
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"label": "Storage",
|
||||
"position": 7,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
}
|
||||
}
|
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: FungiStor
|
||||
sidebar_position: 19
|
||||
---
|
||||
|
||||
## FungiStor (H2 2025)
|
||||
|
||||
### The Problem
|
||||
|
||||
Existing blockchain, internet, and P2P content delivery and storage systems suffer from sluggish performance and are too expensive. Content retrieval is often slow, and the overhead for ensuring redundancy is excessive. We require innovative approaches to facilitate efficient information sharing among users.
|
||||
|
||||
Content delivery frequently represents the most significant expense for social networks. Running a basic social video network for 10 million users currently costs approximately $2 million per month using traditional cloud providers. We have the potential to reduce this cost by several orders of magnitude.
|
||||
|
||||
|
||||
### Introducing FungiStor
|
||||
|
||||
FungiStor is a peer-to-peer (P2P) content delivery layer designed to store and distribute an extensive range of objects, including images, videos, files, and more. It has the capability to handle trillions of objects and files efficiently. FungiStor serves as an excellent solution for content delivery networks (CDNs), significantly reducing costs for organizations seeking to stream or deliver substantial data volumes to their user base.
|
||||
|
||||
|
||||
### The Benefits
|
||||
|
||||
- **Global scalability, sub-50ms lookups:** FungiStor scales worldwide with ultra-fast data retrieval under 50 milliseconds.
|
||||
- **Localized content delivery:** prioritizes local data access for optimized speed and efficiency.
|
||||
- **Quantum-Safe security:** incorporates robust quantum security measures.
|
||||
- **Interoperability:** works seamlessly with IPFS, Torrent, and more.
|
||||
- **Cost efficiency:** offers significant cost savings, potentially 10 to 100 times less than conventional solutions.
|
||||
|
||||
### Status
|
||||
|
||||
Planned for the end of 2024
|
||||
|
||||
Remark, FungiStor will act as the backend infrastructure for the Flists within our own system. It is versatile and can be utilized by anyone in need of a global-level content delivery system for files, objects, and images.
|
BIN
docs/main/key_innovations_overview/storage/img/how_data.png
Normal file
BIN
docs/main/key_innovations_overview/storage/img/how_data.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 104 KiB |
BIN
docs/main/key_innovations_overview/storage/img/storage_old.png
Normal file
BIN
docs/main/key_innovations_overview/storage/img/storage_old.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 169 KiB |
BIN
docs/main/key_innovations_overview/storage/img/unbreakable2.png
Normal file
BIN
docs/main/key_innovations_overview/storage/img/unbreakable2.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 271 KiB |
Binary file not shown.
After Width: | Height: | Size: 569 KiB |
89
docs/main/key_innovations_overview/storage/nft_storage.md
Normal file
89
docs/main/key_innovations_overview/storage/nft_storage.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
sidebar_position: 18
|
||||
title: NFT Storage
|
||||
---
|
||||
|
||||
# Unbreakable Storage System for NFT
|
||||
|
||||
Our technology enables Unbreakable 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 Unbreakable 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.
|
||||
|
||||
|
@@ -0,0 +1,13 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
title: Zero Knowledge Proof
|
||||
---
|
||||
|
||||
# Zero Knowledge Proof Storage System
|
||||
|
||||
The Unbreakable 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 Unbreakable 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 Unbreakable 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.
|
||||
|
||||
|
Reference in New Issue
Block a user