manual removed files
This commit is contained in:
@@ -1,20 +0,0 @@
|
||||
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
**More info:**
|
||||
|
||||
- QSSS
|
||||
- QSFS
|
||||
- [Quantum Safe Network Concept](sdk:archi_qsnetwork)
|
||||
- [Zero-OS Network](sdk:capacity_network)
|
||||
- [ThreeFold Network = Planetary Network](sdk:archi_psnw)
|
||||
- [Web Gateway](sdk:archi_webgateway)
|
||||
- TFGrid
|
||||
- [3Node](3node)
|
||||
- [ThreeFold Connect](tfconnect)
|
||||
|
||||
<!--
|
||||
These are outdated, need to change links
|
||||
- Payments - AutoPay twinautopay - no links found
|
||||
TFGrid Walletcloud_wallet no link found-->
|
||||
@@ -1,43 +0,0 @@
|
||||
# Wallet on Stellar Network
|
||||
|
||||
|
||||
|
||||
### Prepaid Wallets
|
||||
|
||||
The VDC has a built-in __prepaid wallet__, which is the wallet used for paying the capacity requested in the VDC. This wallet expresses in TFT the remaining balance available for ensuring the operational continuity of the reserved capacity.
|
||||
|
||||
This wallet is registered on the Stellar network, and is exclusively used for capacity reservation aligned with the chosen VDC size.
|
||||
Both the TFGrid testnet and mainnet are connected to the Stellar mainnet, so TFTs used are the same. Testnet prices are substantially lower than mainnet prices, though there's no guarantee about continuity of operation: testnet is reset at regular times, and available capacity is also lower than on mainnet.
|
||||
|
||||
### A public key and a shared private key
|
||||
|
||||
The wallet is characterized by 2 strings:
|
||||
- A public address, starting with a 'G', is the address that can be shared with anyone, as it the address to be mentioned when transferring tokens TO the wallet.
|
||||
- A private key, starting with an 'S', is the secret that gives control over the wallet, and which is needed to generate outgoing transfers.
|
||||
|
||||
### Payment for Capacity Process
|
||||
|
||||
The Prepaid Wallet which is setup within your VDC is exclusively used for this purpose. The private key of this wallet is shared between you and the VDC provider :
|
||||
- The VDC provider needs the private key to pay the farmer on a rolling basis : every hour an amount is transferred to the farmer(s) that owns the reserved hardware capacity, so it stays reserved for the next 2 weeks. These 2 weeks are meant as a 'grace period' : when the balance of the prepaid wallet becomes zero, you have 2 weeks to top up the wallet. You will get notified for this, while the workload remains operational.
|
||||
In case after these 2 weeks grace period the wallet hasn't been topped up again, the workload will be removed and the capacity will be made available again for new reservations.
|
||||
|
||||
## Top-up a Wallet
|
||||
|
||||
Please read the [Top-up](evdc_wallet_topup) page for instructions.
|
||||
|
||||
## Viewing Your Balance
|
||||
|
||||
Simply click on one of your existing wallet see the details of the wallet.
|
||||
|
||||
|
||||
|
||||
## Withdraw TFTs from the wallet
|
||||
|
||||
The private key is available to transfer tokens from the prepaid wallet to your personal TFT wallet. Evidently, transferring tokens has a direct impact on the expiration date of your VDC.
|
||||
|
||||
### Your VDC Wallet Details
|
||||
|
||||
- The Network is the Stellar mainnet network (indicated with `STD` on the wallet information)
|
||||
- [Trustlines](https://www.stellar.org/developers/guides/concepts/assets.html) are specific to the Stellar network to indicate that a user is 'trusting' the asset / crypto issuer, in our case trusting ThreeFold Dubai as issuer of TFT.
|
||||
Trustlines are specific to the network, so it needs to be established both on testnet and mainnet and for all the tokens that someone intends to hold. Without a trustline, a wallet address can't be fed with tokens.
|
||||
In order to make it easier for the user, trustlines are being established automatically when creating a wallet for TFT in the admin panel as well as in ThreeFold Connect app. However, if you use a third party Stellar wallet for your tokens, you need to create the trustlines yourself.
|
||||
@@ -1,79 +0,0 @@
|
||||
## Getting started
|
||||
|
||||
Any Quantum-Safe File System has 4 storage layers :
|
||||
- An etcd metadata storage layer
|
||||
- Local storage
|
||||
- ZDB-FS fuse layer
|
||||
- ZSTOR for the dispersed storage
|
||||
|
||||
Now, there are 2 ways to run the zstor filesystem:
|
||||
- In self-management mode for the metadata;
|
||||
- A 'Quantum Storage Enabled' mode.
|
||||
|
||||
The first mode combines the local storage, ZDB-FS and ZSTOR, but requires an etcd metadata layer to be manually run and managed.
|
||||
The second mode is enabled by the `ENABLE QUANTUM STORAGE` button and provisions etcd to manage the metadata. Here the 4 layers are available (hence it will consume slightly more storage from your VDC).
|
||||
|
||||
### Manually Managed Metadata Mode
|
||||
|
||||
This Planetary Secure File System uses a ThreeFold VDC's storage nodes to back data up to the ThreeFold Grid. Below you'll find instructions for using an executable bootstrap file that runs on Linux or in a Linux Docker container to set up the complete environment necessary to use the file system.
|
||||
|
||||
Please note that this solution is currently for testing only, and some important features are still under development.
|
||||
|
||||
#### VDC and Z-Stor Config
|
||||
|
||||
If you haven't already, go ahead and [deploy a VDC](evdc_deploy). Then download the Z-Stor config file, found in the upper right corner of the `VDC Storage Nodes` screen. Unless you know that IPv6 works on your machine and within Docker, choose the IPv4 version of the file.
|
||||
|
||||
|
||||
|
||||
As described in [Manage Storage Nodes](evdc_storage), this file contains the necessary information to connect with the 0-DBs running on the storage nodes in your VDC. It also includes an encryption key used to encrypt data that's uploaded and a field to specify your etcd endpoints. Using the defaults here is fine.
|
||||
|
||||
#### Bootstrap Executable
|
||||
|
||||
Download now the zstor filesystem bootstrap, available [here](https://github.com/threefoldtech/quantum-storage/releases/download/v0.0.1/planetaryfs-bootstrap-linux-amd64).
|
||||
|
||||
|
||||
> __Remark__:
|
||||
For now, the bootstrap executable is only available for Linux. We'll cover how to use it within an Ubuntu container in Docker, which will also work on MacOS.
|
||||
First, we'll start an Ubuntu container with Docker, enabling fuse file system capabilities. In a terminal window,
|
||||
|
||||
`docker run -it --name zdbfs --cap-add SYS_ADMIN --device /dev/fuse ubuntu:20.04`
|
||||
|
||||
Next, we'll copy the Z-Stor config file and the bootstrap executable into the running container. In a separate terminal window, navigate to where you downloaded the files and run:
|
||||
|
||||
`docker cp planetaryfs-bootstrap-linux-amd64 zdbfs:/root/`
|
||||
`docker cp <yourzstorconfig.toml> zdbfs:/root/`
|
||||
|
||||
Back in the container's terminal window, `cd /root` and confirm that the two files are there with `ls`. Then run the bootstrap executable, specifying your config file:
|
||||
|
||||
`chmod u+x planetaryfs-bootstrap-linux-amd64`
|
||||
`./planetaryfs-bootstrap-linux-amd64 <yourzstorconfig.toml>`
|
||||
|
||||
This bootstrap's execution will start up all necessary components and show you that the back-end is ready for dispersing the data.
|
||||
|
||||
|
||||
|
||||
After that, your Planetary Secure File System will be mounted at `/root/.threefold/mnt/zdbfs`. Files copied there will automatically be stored on the grid incrementally as fragments of a certain size are filled, by default 32Mb. In a future release, this will no longer be a limitation.
|
||||
|
||||
### Provisioned Metadata Mode
|
||||
|
||||
Users that intend to have also the metadata out-of-the-box available, and have it used in the Kubernetes cluster, need to push the `ENABLE QUANTUM STORAGE` button. This will allow to use etcd key-value stores in the VDC, and can be used within a Kubernetes cluster.
|
||||
|
||||
|
||||
|
||||
Once Quantum Storage mode is enabled, you get an etcd for free.
|
||||
|
||||
**Remark**: this action can't be undone in your VDC : the etcd stores can be filled immediately, and deletion of them could result in data loss. This is why the 'Disable Quantum Storage' is considered as too risky and is not available.
|
||||
|
||||
### Add node
|
||||
|
||||
Adding storage nodes manually is simple: press the `+ ADD NODE` button.
|
||||
|
||||
|
||||
|
||||
You'll be asked to deploy this storage node either on the same farm or on another one. The choice is a balance between security (have the data in multiple locations makes it more resilient against disaster).
|
||||
|
||||
|
||||
|
||||
If you choose `Yes`, select the farm of your choice, and then pay for the extra capacity.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 247 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 222 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 170 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 137 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 293 KiB |
@@ -1,34 +0,0 @@
|
||||
|
||||
|
||||
# ThreeFold zstor filesystem (zstor)
|
||||
|
||||
Part of the eVDC is a set of Storage Nodes, which can be used as a storage infrastructure for files in any format.
|
||||
|
||||
## 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 relies on 3 primitives of the ThreeFold technology :
|
||||
|
||||
- [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 keeping the history 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 this 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's 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
|
||||
- ...
|
||||
|
||||
|
||||
|
||||
@@ -1,32 +0,0 @@
|
||||
|
||||
|
||||
# Buying and Storing TFTs
|
||||
|
||||
If you're looking to navigate the [TFT Ecosystem](https://library.threefold.me/info/manual/#/tokens/threefold__tft_ecosystem), this collection of tutorials and manuals is here to help. Learn how to purchase, trade, and securely store your TFTs with ease.
|
||||
|
||||
For a comprehensive introduction to TFT, we recommend exploring the [TFT Home Section in the ThreeFold Library](https://library.threefold.me/info/threefold#/tokens/threefold__tokens_home).
|
||||
|
||||
## Manuals on How to Buy TFT
|
||||
Discover step-by-step instructions on buying and storing TFTs across different platforms. Our manuals cover:
|
||||
|
||||
- [BSC - Pancake Swap](https://library.threefold.me/info/manual/#/tokens/threefold__tft_binance_defi)
|
||||
- [BSC - 1inch.io](https://library.threefold.me/info/manual/#/tokens/threefold__tft_1inch)
|
||||
- [GetTFT.com](https://gettft.com/gettft/#how-it-works)
|
||||
- [Albedo Wallet](https://library.threefold.me/info/manual/#/tokens/threefold__albedo)
|
||||
- [Solar Wallet](https://library.threefold.me/info/manual/#/tokens/threefold__solar_wallet)
|
||||
- [Lobstr Wallet](https://library.threefold.me/info/manual/#/tokens/threefold__lobstr_wallet)
|
||||
- [StellarTerm](https://library.threefold.me/info/manual/#/tokens/threefold__tft_stellarterm)
|
||||
- [Interstellar](https://library.threefold.me/info/manual/#/tokens/threefold__tft_interstellar)
|
||||
- [BTC-Alpha Exchange](https://library.threefold.me/info/manual/#/tokens/threefold__tft_btc_alpha)
|
||||
- [StellarX Exchange](https://library.threefold.me/info/manual/#/tokens/threefold__tft_stellarx)
|
||||
- [TF Live Desk (OTC)](https://library.threefold.me/info/manual/#/tokens/threefold__tft_otc)
|
||||
- [Mazraa (Farmers)](https://library.threefold.me/info/manual/#/tokens/threefold__tft_mazraa)
|
||||
- [Bettertoken (Farmers)](https://library.threefold.me/info/manual/#/tokens/threefold__tft_bettertoken)
|
||||
|
||||
## Other Related Manuals on TFT
|
||||
- [Store TFTs on Hardware Wallets](../threefold_token/storing_tft/hardware_wallet.md)
|
||||
- [Storing TFTs on TF Connect App](../threefold_token/storing_tft/tf_connect_app.md)
|
||||
- [TFT Bridges](../threefold_token/tft_bridges/tft_bridges.md)
|
||||
- [TFChain-Stellar Bridge](../threefold_token/tft_bridges/tfchain_stellar_bridge.md)
|
||||
- [BSC-Stellar Bridge](../threefold_token/tft_bridges/bsc_stellar_bridge.md)
|
||||
- [Ethereum-Stellar Bridge](../threefold_token/tft_bridges/tft_ethereum/tft_ethereum.md)
|
||||
@@ -1,19 +0,0 @@
|
||||
# ThreeFold Grid Concepts
|
||||
|
||||
On this section we will explore the fundamental principles and concepts behind the ThreeFold Grid. This comprehensive resource will take you on a journey through the core technologies that underpin the ThreeFold Grid, empowering you to understand and leverage the decentralized nature of this groundbreaking infrastructure.
|
||||
|
||||
## Learn the Basics
|
||||
|
||||
- [TFGrid Primitives](./grid_primitives.md)
|
||||
- [TFGrid Component List](./grid3_components.md)
|
||||
- [ThreeFold's Infrastructure as Code (IaC)](./grid3_iac.md)
|
||||
- [Proof of Utilization](./proof_of_utilization.md)
|
||||
- [Contract Grace Period](./contract_grace_period.md)
|
||||
- [What's New on TFGrid v3.x](./grid3_whatsnew.md)
|
||||
- [TFChain](./tfchain.md)
|
||||
- [TFGrid by Design](./tfgrid_by_design.md)
|
||||
|
||||
## Take an In-Depth Looks
|
||||
|
||||
- [TF Technology](../technology_toc.md)
|
||||
- [What's New on TFGrid v3.x](./grid3_whatsnew.md)
|
||||
@@ -1,37 +0,0 @@
|
||||
<h1> ThreeFold Chain </h1>
|
||||
|
||||
<h2>Table of Contents </h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Overview](#overview)
|
||||
- [Key Functionalities](#key-functionalities)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
__TFChain__, also known as __ThreeFold Chain__, is the blockchain at the core of managing the ThreeFold Grid, which operates as a decentralized autonomous organization (DAO). Built on Substrate, TFChain provides the infrastructure to support the seamless functioning of the ThreeFold Grid ecosystem.
|
||||
|
||||
## Overview
|
||||
|
||||
One of the key features of TFChain is its __compatibility with multiple blockchains__. The native token of the ThreeFold ecosystem, TFT, can be utilized across different blockchain networks including TFChain, Stellar, and Binance Smart Chain. This compatibility enables users to transfer their TFT tokens seamlessly between these blockchains, providing flexibility and convenience.
|
||||
|
||||
To leverage the Internet Capacity available on the ThreeFold Grid, users are required to transfer funds to their TFChain account. This ensures that users have the necessary financial resources to access and utilize the storage, compute, and network services offered by the ThreeFold Grid. By transferring money to their TFChain account, users can seamlessly tap into the vast potential of the decentralized Internet Capacity provided by the ThreeFold Grid.
|
||||
|
||||
TFChain serves as the backbone of the ThreeFold ecosystem, facilitating efficient transactions, secure transfers of value, and the management of user accounts. It plays a vital role in supporting the seamless interaction between users and the ThreeFold Grid, enabling them to leverage the available Internet Capacity and contribute to the growth of the decentralized network.
|
||||
|
||||
## Key Functionalities
|
||||
|
||||
__TFChain (Threefold Chain)__ is a powerful blockchain that orchestrates the interactions within the ThreeFold Grid ecosystem, providing users with a range of key functions. Let's explore some of these user-friendly functions:
|
||||
|
||||
- __Users Registration__: TFChain allows seamless registration for users to join the ThreeFold Grid. By creating an account, users can easily become part of the decentralized network and access the various resources and services available.
|
||||
|
||||
- __Farms Management__: TFChain simplifies the process of managing node farms within the ThreeFold Grid. It provides a streamlined registration system, enabling farmers to register their nodes and effectively contribute to the grid. Additionally, TFChain facilitates IP management, allowing farmers to efficiently manage and allocate IP addresses to their nodes.
|
||||
|
||||
- __Fund Transfers__: TFChain supports secure and efficient fund transfers within the ThreeFold ecosystem. Users can seamlessly transfer funds, including the native TFT token, between accounts on TFChain. This feature enables easy financial transactions and fosters a thriving economy within the ThreeFold Grid.
|
||||
|
||||
- __Billing and Consumption Reports__: TFChain offers detailed billing and consumption reports, providing users with insights into their resource usage and associated costs. Users can easily track their consumption, monitor usage patterns, and access comprehensive reports, ensuring transparency and accountability in resource management.
|
||||
|
||||
And More: TFChain is continuously evolving and expanding its functionality. In addition to the key functions mentioned above, TFChain provides a robust foundation for other essential features within the ThreeFold Grid. This includes __facilitating secure transactions, maintaining a transparent ledger, enabling governance mechanisms,__ and supporting various interactions and operations within the decentralized ecosystem.
|
||||
|
||||
TFChain's user-friendly functions empower users to participate actively in the ThreeFold Grid, seamlessly manage their resources, and engage in secure and efficient transactions.
|
||||
@@ -1,89 +0,0 @@
|
||||
<h1> Grace Period: Ensuring Seamless Operations </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [What is the Grace Period?](#what-is-the-grace-period)
|
||||
- [How does it work?](#how-does-it-work)
|
||||
- [When does the Grace Period kick in?](#when-does-the-grace-period-kick-in)
|
||||
- [How to resume your workloads:](#how-to-resume-your-workloads)
|
||||
- [Grace Period Contract State: Easily Accessible Information](#grace-period-contract-state-easily-accessible-information)
|
||||
- [Grid Weblets:](#grid-weblets)
|
||||
- [ThreeFold Grid Proxy:](#threefold-grid-proxy)
|
||||
- [TFChain GraphQL:](#tfchain-graphql)
|
||||
- [Node Contract](#node-contract)
|
||||
- [Rent Contract](#rent-contract)
|
||||
- [PolkadotJS UI:](#polkadotjs-ui)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
__The Grace Period__ serves as a crucial aspect of the ThreeFold ecosystem, providing a safety net for users when their funds run low. Let's explore the key details in a user-friendly manner:
|
||||
|
||||
## What is the Grace Period?
|
||||
|
||||
When a contract owner exhausts their wallet funds required for their deployment, the contract enters a Grace Period. During this time, the deployment becomes temporarily inaccessible to the user. However, once the wallet is replenished with TFT (ThreeFold Tokens), the contract resumes normal operation.
|
||||
|
||||
It's important to note that if the Grace Period expires (typically after 2 weeks), the user's deployment and data will be deleted from the node.
|
||||
|
||||
## How does it work?
|
||||
|
||||
When a ``twin`` (a user account) depletes its funds, all linked contracts enter a Grace Period during the next billing cycle.
|
||||
By default, the Grace Period lasts for 14 days. Throughout this period, users cannot utilize any deployments associated with the twin.
|
||||
|
||||
Additionally, users cannot delete contracts during the Grace Period, whether they are related to nodes, names, or rent.
|
||||
Workloads become usable again when the twin is funded with the required amount of TFT.
|
||||
|
||||
If the twin is not funded during the Grace Period, the contracts will be automatically deleted after this period.
|
||||
|
||||
## When does the Grace Period kick in?
|
||||
The Grace Period commences when the twin balance falls below the minimum required for the respective deployments or workloads.
|
||||
|
||||
## How to resume your workloads:
|
||||
To regain access to workloads within the Grace Period, it is essential to fund your twin with sufficient TFT tokens. This action ensures the resumption of operations and allows you to continue your work seamlessly.
|
||||
|
||||
The Grace Period feature acts as a safeguard, providing users with the opportunity to manage their funds effectively and maintain uninterrupted operations within the ThreeFold ecosystem.
|
||||
|
||||
## Grace Period Contract State: Easily Accessible Information
|
||||
|
||||
Checking the state of your contracts within the ``Grace Period`` is simple and convenient. Here's how you can do it:
|
||||
|
||||
### Grid Weblets:
|
||||
The Contracts tab on the Dashboard provides an easy way to monitor your contracts. Here, you can find comprehensive details about the desired ``contract``, including its ``State`` and ``Expiration date`` if the node is in the Grace Period.
|
||||
|
||||
|
||||
|
||||
### ThreeFold Grid Proxy:
|
||||
Access the Grace Period contracts through the following endpoint:
|
||||
|
||||
``https://gridproxy.grid.tf/contracts?state=GracePeriod&twin_id=<YOUR_TWIN_ID>``
|
||||
|
||||
|
||||
|
||||
This allows you to retrieve information about contracts that are currently in the Grace Period.
|
||||
|
||||
## TFChain GraphQL:
|
||||
You can also check the Contract State using [__GraphQL queries__](https://graphql.grid.tf/graphql). Depending on the contract type, utilize the appropriate queries available for ``Node Contract`` and ``Rent Contract``.
|
||||
|
||||
### Node Contract
|
||||
|
||||
|
||||
### Rent Contract
|
||||
These queries provide insights into the status and details of the contracts.
|
||||
|
||||
|
||||
|
||||
## PolkadotJS UI:
|
||||
Another option is to check the Contract state using the [__PolkadotJS UI__](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Ftfchain.grid.tf#/chainstate). Simply navigate to ``chainstate`` -> ``SmartContractModule`` -> ``Contracts(ID_OF_CONTRACT)`` to view the relevant contract information.
|
||||
|
||||
|
||||
|
||||
With these user-friendly options at your disposal, you can effortlessly track and monitor the state of your contracts within the Grace Period.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,351 +0,0 @@
|
||||
<h1> TFGrid Component List (Last Updated May 2023) </h1>
|
||||
|
||||
<h2> Table of Contents </h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [TFGrid Components (Alphabetical Orders)](#tfgrid-components-alphabetical-orders)
|
||||
- [TF Admin Portal](#tf-admin-portal)
|
||||
- [AtomicSwap](#atomicswap)
|
||||
- [Builders](#builders)
|
||||
- [TF Capacity Explorer](#tf-capacity-explorer)
|
||||
- [Cloud Container](#cloud-container)
|
||||
- [Cloud Console](#cloud-console)
|
||||
- [TF Dashboard](#tf-dashboard)
|
||||
- [Farm Management](#farm-management)
|
||||
- [TF Farming Calculator](#tf-farming-calculator)
|
||||
- [Farmerbot](#farmerbot)
|
||||
- [Freeflow Twin Main App or Freeflow Connect (previously Uhuru)](#freeflow-twin-main-app-or-freeflow-connect-previously-uhuru)
|
||||
- [GetTFT Shop](#gettft-shop)
|
||||
- [TF Grid3 Client TS](#tf-grid3-client-ts)
|
||||
- [TF Grid Proxy](#tf-grid-proxy)
|
||||
- [TF Grid-SDK-Go](#tf-grid-sdk-go)
|
||||
- [TF Grid-SDK-TS](#tf-grid-sdk-ts)
|
||||
- [TF Grid Simulator](#tf-grid-simulator)
|
||||
- [TF Grid Stats](#tf-grid-stats)
|
||||
- [JS-SDK](#js-sdk)
|
||||
- [JS-NG](#js-ng)
|
||||
- [Itenv\_TFGridv2](#itenv_tfgridv2)
|
||||
- [Libp2p-relay](#libp2p-relay)
|
||||
- [Minting v3](#minting-v3)
|
||||
- [Node-Pilot](#node-pilot)
|
||||
- [Oauth-Proxy](#oauth-proxy)
|
||||
- [TF Planetary Network Tool](#tf-planetary-network-tool)
|
||||
- [TF Dashboard and Weblets](#tf-Dashboard-and-weblets)
|
||||
- [QSFS](#qsfs)
|
||||
- [Reliable Message Bus Relay (RMB-RS)](#reliable-message-bus-relay-rmb-rs)
|
||||
- [RMB-SDK-Go](#rmb-sdk-go)
|
||||
- [Terraform Provider](#terraform-provider)
|
||||
- [TCP-Router](#tcp-router)
|
||||
- [TFChain](#tfchain)
|
||||
- [TFChain Activation Service](#tfchain-activation-service)
|
||||
- [TFChain Explorer](#tfchain-explorer)
|
||||
- [TFChain Block Explorer](#tfchain-block-explorer)
|
||||
- [TFChain-GraphQL](#tfchain-graphql)
|
||||
- [TFChain TFT Bridge](#tfchain-tft-bridge)
|
||||
- [3Bot or Threebot](#3bot-or-threebot)
|
||||
- [Threebot-deployer or 3Bot Deployer](#threebot-deployer-or-3bot-deployer)
|
||||
- [ThreeFold Wallet](#threefold-wallet)
|
||||
- [ThreeFold Connect App](#threefold-connect-app)
|
||||
- [Zinit](#zinit)
|
||||
- [0-OS or ZOS](#0-os-or-zos)
|
||||
- [0-bootstrap](#0-bootstrap)
|
||||
- [0-Bus or ZBus](#0-bus-or-zbus)
|
||||
- [0-DB](#0-db)
|
||||
- [0-DB-FS](#0-db-fs)
|
||||
- [0-Flist](#0-flist)
|
||||
- [0-Hub](#0-hub)
|
||||
- [0-InitramFS](#0-initramfs)
|
||||
- [0-stor\_v2](#0-stor_v2)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
This list serves as a comprehensive glossary that provides an overview of the various components and tools within the ThreeFold Grid ecosystem. It serves as a valuable reference for developers, stakeholders, and enthusiasts who want to gain a deeper understanding of the building blocks that power the ThreeFold Grid.
|
||||
|
||||
The glossary covers a wide range of components, including infrastructure elements, software tools, protocols, and services that are integral to the functioning and expansion of the grid. From blockchain-based technologies like TFChain and TFGrid Explorer to networking components like RMB-RS and Zinit, the TFGrid Component List offers concise explanations of each component's purpose and functionality.
|
||||
|
||||
***
|
||||
|
||||
## TFGrid Components (Alphabetical Orders)
|
||||
|
||||
### TF Admin Portal
|
||||
A tool within TF Dashboard provided by ThreeFold for administrators to manage and monitor various aspects of the ThreeFold Grid ecosystem. It serves as a central hub where administrators can access and control different components of the grid, including nodes, capacity, workloads, and user management.
|
||||
|
||||
The TF Admin Portal provides a comprehensive set of tools and features to configure, deploy, and monitor resources within the grid, ensuring efficient management and utilization of the decentralized infrastructure. Through the portal, administrators can track the performance and health of the grid, allocate resources, manage user permissions, and gain insights into the grid's utilization and usage patterns.
|
||||
|
||||
> [Component Repository on Github (Archived)](https://github.com/threefoldtech/tfgrid_dashboard)
|
||||
|
||||
### AtomicSwap
|
||||
A component within the ThreeFold ecosystem that refers to Atomic Swaps, a cryptographic technology that enables the peer-to-peer exchange of cryptocurrencies or digital assets between different blockchain networks without the need for intermediaries. Atomic swaps use smart contracts to facilitate trustless and secure transactions, ensuring that both parties involved in the swap fulfill their obligations. By leveraging atomic swaps, users can seamlessly exchange digital assets across different blockchains, fostering interoperability and eliminating the reliance on centralized exchanges.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/atomicswap)
|
||||
|
||||
### Builders
|
||||
A Docker-based component within the ThreeFold Grid ecosystem. This particular aspect of Builders involves leveraging Docker containers to package and deploy applications and services on the ThreeFold Grid. Docker is an open-source platform that enables developers to build, package, and distribute applications as lightweight, portable containers.
|
||||
|
||||
By using Builders as a Docker-based component, developers can easily containerize their applications, ensuring consistency and compatibility across different environments. This approach simplifies the deployment process, allowing developers to quickly deploy their applications on the ThreeFold Grid with minimal configuration and setup. The Builders component takes care of managing the underlying infrastructure and orchestrating the deployment of Docker containers, making it an efficient and convenient way to leverage the capabilities of the ThreeFold Grid for hosting and running applications.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/builders)
|
||||
|
||||
### TF Capacity Explorer
|
||||
A tool within the TF Dashboard provided by ThreeFold that allows users to explore and analyze the available capacity within the ThreeFold Grid. It provides insights into the distributed computing resources, including storage, processing power, and network bandwidth, that are available for utilization within the ThreeFold network.
|
||||
|
||||
The TF Capacity Explorer enables users to discover and assess the capacity of different nodes and data centers within the ThreeFold Grid, helping them make informed decisions when deploying their workloads or applications.
|
||||
|
||||
> [Component Repository on Github (Archived)](https://github.com/threefoldtech/tfgrid_dashboard)
|
||||
|
||||
### Cloud Container
|
||||
A containerization technology provided by ThreeFold that enables the deployment and management of applications and services in a cloud environment. It offers a lightweight and isolated execution environment for running applications, ensuring scalability, portability, and efficient resource utilization.
|
||||
|
||||
With ThreeFold's Cloud Container, developers and organizations can package their applications along with their dependencies and configurations, making it easier to deploy and manage them in a cloud-native manner. The Cloud Container technology provides features such as automated scaling, load balancing, and resource allocation, allowing for efficient utilization of computing resources and optimal performance of applications.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/cloud-container)
|
||||
|
||||
### Cloud Console
|
||||
A web-based graphical user interface (GUI) provided by ThreeFold that allows users to manage and control their cloud infrastructure and resources. It serves as a central hub for managing various aspects of the cloud environment, including virtual machines, storage, networking, and other services.
|
||||
|
||||
Through the cloud console, users can perform a wide range of tasks, such as provisioning and configuring virtual machines, managing storage volumes, creating and managing networks, monitoring resource usage, and accessing logs and metrics. It provides an intuitive and user-friendly interface that simplifies the management and administration of the cloud infrastructure.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/cloud-console)
|
||||
|
||||
### TF Dashboard
|
||||
A Graphical user interface (GUI) provided by ThreeFold for users to access and manage their ThreeFold Grid resources. It serves as a centralized control panel where users can monitor and control various aspects of their infrastructure, including their deployed workloads, storage capacity, network connectivity, and overall system health. The TF Dashboard provides real-time statistics, logs, and metrics to help users gain insights into the performance and utilization of their resources. It also offers tools for managing user accounts, configuring security settings, and accessing support and documentation.
|
||||
|
||||
> [Component Repository on Github (Archived)](https://github.com/threefoldtech/tfgrid_dashboard)
|
||||
|
||||
### Farm Management
|
||||
A set of tools, processes, and functionalities provided by ThreeFold to manage and operate farms within the ThreeFold Grid. Farms are the physical locations where ThreeFold Farmers deploy and maintain the infrastructure that powers the decentralized network. TF Farm Management offers a comprehensive suite of features that enable farmers to efficiently manage their resources, monitor the health and performance of their infrastructure, and handle various administrative tasks. This includes functionalities such as capacity allocation, monitoring and reporting tools, farmer reputation management, billing and invoicing systems, and overall farm administration.
|
||||
|
||||
Note: This is a feature that involves multiple component repositories. It is listed here to give a complete picture of ThreeFold's component list.
|
||||
|
||||
### TF Farming Calculator
|
||||
A tool provided by ThreeFold that allows users to estimate and calculate potential earnings from farming on the ThreeFold Grid. Farming refers to the process of providing computing resources, such as storage and processing power, to the ThreeFold Grid and earning tokens in return. The tf-farming-calculator takes into account various factors, including the amount of resources contributed, the duration of farming, and the current market conditions, to provide users with an estimate of their potential earnings in terms of ThreeFold Tokens (TFT).
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tf-farming-calculator)
|
||||
|
||||
### Farmerbot
|
||||
A software tool developed by ThreeFold that serves as a management and monitoring system for ThreeFold farmers. It is designed to automate various tasks related to operating and managing the ThreeFold Grid infrastructure. The TF Farmerbot helps farmers to efficiently manage their resources, including storage capacity, compute power, and network bandwidth. It provides real-time monitoring of the farmer's nodes, ensuring optimal performance and availability.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/farmerbot)
|
||||
|
||||
### Freeflow Twin Main App or Freeflow Connect (previously Uhuru)
|
||||
FFTwin is a component of the ThreeFold ecosystem that serves as the main interface for users to access and utilize the features of Freeflow Twin. Freeflow Twin is a decentralized communication and collaboration platform developed by ThreeFold.
|
||||
|
||||
The Twin Main App allows users to securely communicate, share files, and collaborate with others in a decentralized manner, ensuring privacy and data sovereignty. Users can create chat channels, join communities, and engage in real-time messaging with end-to-end encryption. The app also supports file sharing, voice and video calls, and other collaborative features. With the Freeflow Twin Main App, users can experience a decentralized and secure communication platform that empowers them to connect and collaborate with others while maintaining control over their data.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/freeflow_twin_main_app)
|
||||
|
||||
### GetTFT Shop
|
||||
An official, online platform provided by ThreeFold where users can purchase ThreeFold Tokens (TFT) directly. It serves as a dedicated marketplace for individuals and organizations to buy TFT tokens using various payment methods. The GetTFT Shop ensures a seamless and user-friendly experience for acquiring TFT, which is the native cryptocurrency of the ThreeFold ecosystem.
|
||||
|
||||
Note: This repository is private. You can visit the GetTFT Shop [here](https://gettft.com/gettft/shop/).
|
||||
|
||||
### TF Grid3 Client TS
|
||||
A software component that serves as a client library for interacting with the Grid3 platform. It provides developers with a set of tools, functions, and interfaces to communicate with the ThreeFold Grid and utilize its resources. The Grid3 Client TS allows users to perform various operations, such as creating and managing virtual machines, deploying applications, accessing storage services, and interacting with the decentralized network. It acts as a bridge between developers and the ThreeFold Grid, enabling them to leverage the platform's decentralized infrastructure and harness its capabilities programmatically.
|
||||
|
||||
### TF Grid Proxy
|
||||
A fundamental component which serves as a gateway that allows external applications and users to interact with the grid. Acting as a bridge between the decentralized infrastructure of the ThreeFold Grid and external networks, GridProxy facilitates seamless communication and integration. It provides a standardized interface for accessing and managing resources within the grid, enabling developers, businesses, and users to leverage the power and scalability of the ThreeFold Grid in their applications and workflows. By abstracting the complexities of the grid infrastructure, GridProxy simplifies the process of interacting with the grid, making it more accessible and user-friendly.
|
||||
|
||||
> [Component Repository on Github (Archived)](https://github.com/threefoldtech/tfgridclient_proxy)
|
||||
|
||||
### TF Grid-SDK-Go
|
||||
ThreeFold Grid Software Development Kit (SDK) for the Go programming language. It is a collection of tools, libraries, and APIs provided by ThreeFold to facilitate the development and integration of applications with the ThreeFold Grid. The TFGrid-SDK-Go allows developers to interact with the ThreeFold Grid infrastructure, such as provisioning and managing compute resources, accessing storage, and interacting with blockchain-based services. It provides a standardized and efficient way to leverage the features and capabilities of the ThreeFold Grid within Go applications.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfgrid-sdk-go)
|
||||
|
||||
### TF Grid-SDK-TS
|
||||
ThreeFold Grid Software Development Kit (SDK) for TypeScript. It is a set of tools, libraries, and APIs provided by ThreeFold to simplify the development and integration of applications with the ThreeFold Grid. The TFGrid-SDK-TS enables developers to interact with the ThreeFold Grid infrastructure, such as provisioning and managing compute resources, accessing storage, and interacting with the blockchain-based services. It provides a standardized and convenient way to leverage the features and capabilities of the ThreeFold Grid within TypeScript applications.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfgrid-sdk-ts)
|
||||
|
||||
### TF Grid Simulator
|
||||
A component or tool within the ThreeFold ecosystem that allows for the simulation of the ThreeFold Grid infrastructure. It provides a simulated environment where users can test and evaluate the behavior and performance of the grid without the need for actual hardware or network resources. The tfgrid_simulator mimics the functionalities of the real ThreeFold Grid, enabling users to experiment with various configurations, scenarios, and workloads. This simulation tool is valuable for developers, administrators, and users who want to understand and optimize the behavior of the ThreeFold Grid, test applications, and evaluate the impact of different factors on grid performance. It helps in fine-tuning the grid setup and ensuring optimal resource allocation and utilization.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfgrid_simulator)
|
||||
|
||||
### TF Grid Stats
|
||||
A component or tool within the ThreeFold ecosystem that is designed to gather and provide statistics and metrics related to the ThreeFold Grid. It collects data on various aspects of the grid, such as the number of active nodes, their capacities, network performance, usage patterns, and other relevant information. tfgrid_stats allows users and administrators to monitor the health and performance of the grid, track its growth and utilization, and make informed decisions based on the collected data.
|
||||
|
||||
> [Component Repository on Github (Archived)](https://github.com/threefoldtech/tfgrid_stats)
|
||||
|
||||
### JS-SDK
|
||||
A software development kit (SDK) provided by ThreeFold that enables developers to interact with and utilize the ThreeFold Grid infrastructure using JavaScript. It provides a set of libraries, tools, and APIs that simplify the integration and interaction with various ThreeFold services and functionalities.
|
||||
|
||||
With the JS-SDK, developers can programmatically manage and deploy resources, interact with the ThreeFold Grid's decentralized storage, perform transactions on the ThreeFold Chain blockchain, and access other platform features. The JS-SDK empowers developers to build decentralized applications (dApps), create custom automation scripts, and leverage the capabilities of the ThreeFold Grid using the familiar JavaScript programming language.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/js-sdk)
|
||||
|
||||
### JS-NG
|
||||
JavaScript Next-Generation (js-ng) framework, which is a modern and advanced framework for building web applications using JavaScript. It provides developers with a set of tools, libraries, and utilities to streamline the development process and create high-performance, scalable, and maintainable web applications. The js-ng framework incorporates the latest features and best practices of JavaScript, allowing developers to write clean and efficient code. It offers a modular architecture, allowing for easy integration of third-party libraries and extensions.
|
||||
|
||||
With js-ng, developers can build interactive user interfaces, handle data management, perform client-server communication, and implement various functionalities required for robust web applications. The framework promotes code reusability, testability, and code organization, making it an ideal choice for developing modern web applications.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/js-ng)
|
||||
|
||||
### Itenv_TFGridv2
|
||||
The development and testing environment for the TFGrid v2, which is the second version of the ThreeFold Grid. It is a comprehensive set of tools, configurations, and resources that enable developers to create, test, and deploy applications on the ThreeFold Grid infrastructure. The itenv_tfgridv2 environment provides developers with the necessary tools and utilities to set up a local development environment that closely resembles the production environment of the ThreeFold Grid. It includes various components such as virtual machines, containers, networking configurations, and monitoring tools, all specifically tailored for the development and testing of applications on the ThreeFold Grid.
|
||||
|
||||
Note: This repository is private.
|
||||
|
||||
### Libp2p-relay
|
||||
A component within the ThreeFold ecosystem that refers to the libp2p relay functionality. libp2p is a modular networking stack that allows peer-to-peer communication and data transfer between nodes in a decentralized network. The libp2p-relay component specifically focuses on providing relay services, which enable nodes that are behind firewalls or NATs (Network Address Translators) to establish direct connections with other nodes in the network. This relaying functionality helps overcome network obstacles and facilitates seamless communication between nodes, ensuring that the ThreeFold Grid operates efficiently and nodes can interact with each other effectively.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/libp2p-relay)
|
||||
|
||||
### Minting v3
|
||||
The third version of the ThreeFold Token (TFT) minting process. It is a protocol implemented by ThreeFold to create new TFT tokens and manage the token supply. TF Minting v3 incorporates various features and improvements over its previous versions to enhance the functionality and security of token creation. It involves the issuance of new TFT tokens according to predefined rules and algorithms, such as token distribution, inflation rates, and token unlocking schedules. TF Minting v3 ensures a fair and transparent distribution of tokens while maintaining the integrity and stability of the ThreeFold ecosystem.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/minting_v3)
|
||||
|
||||
### Node-Pilot
|
||||
A software package provided by ThreeFold for running and managing individual nodes on the ThreeFold Grid. It is designed to enable users to set up and operate their own decentralized infrastructure nodes. TFNode-Pilot provides the necessary tools and functionality to deploy, configure, and monitor nodes, allowing users to contribute their computing resources to the ThreeFold Grid and participate in the decentralized ecosystem.
|
||||
|
||||
With TFNode-Pilot, users can easily transform their hardware into powerful nodes that contribute to the storage, compute, and networking capabilities of the ThreeFold Grid. The software package includes features such as node management, resource monitoring, security measures, and integration with other components of the ThreeFold ecosystem.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/node-pilot-light)
|
||||
|
||||
### Oauth-Proxy
|
||||
A component specifically developed by ThreeFold to enhance security and facilitate the authentication process for accessing ThreeFold services and resources. It acts as a middleware between users, applications, and the ThreeFold infrastructure, implementing the OAuth protocol. By using the oauth-proxy, applications can securely obtain authorization to access protected resources on the ThreeFold network without directly handling user credentials. The oauth-proxy handles the authentication flow, obtaining consent from users, and issuing access tokens to authorized applications. This helps ensure that access to ThreeFold's services and resources is controlled and secure, protecting user data and privacy.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/oauth-proxy)
|
||||
|
||||
### TF Planetary Network Tool
|
||||
A software application or platform that provides users with the necessary tools and functionalities to interact with and utilize the ThreeFold Planetary Network. The ThreeFold Planetary Network is a decentralized and distributed infrastructure network that spans across the globe. It is built on the principles of autonomy, neutrality, and sustainability. The network consists of a vast number of interconnected computing resources, including servers, storage devices, and networking equipment, which are owned and operated by individuals and organizations called farmers.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/planetary_network)
|
||||
|
||||
### TF Dashboard and Weblets
|
||||
TF Dashboard and TF Weblets are two interconnected components of the ThreeFold ecosystem. TF Dashboard is a user-friendly web-based interface that serves as a sandbox environment for developers, allowing them to experiment, test, and deploy their applications on the ThreeFold Grid. It provides an intuitive interface where users can write, compile, and execute code, explore various programming languages and frameworks, and interact with the ThreeFold infrastructure.
|
||||
|
||||
TF Weblets, on the other hand, are modular, lightweight applications that run on the ThreeFold Grid. They are designed to be decentralized, secure, and easily deployable, enabling users to create and deploy their own web-based services and applications on the ThreeFold network.
|
||||
|
||||
> [Component Repository on Github (Archived)](https://github.com/threefoldtech/grid_weblets)
|
||||
|
||||
### QSFS
|
||||
It is ThreeFold's innovative storage solution designed to address the security challenges posed by quantum computing. QSFS employs advanced cryptographic techniques that are resistant to attacks from quantum computers, ensuring the confidentiality and integrity of stored data. By utilizing quantum-resistant algorithms, QSFS offers long-term data protection, even in the face of quantum threats. This technology is crucial in a future where quantum computers could potentially break traditional encryption methods. With ThreeFold's QSFS, users can have peace of mind knowing that their data is safeguarded against emerging quantum computing risks, reinforcing the security and resilience of the ThreeFold ecosystem.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/quantum-storage)
|
||||
|
||||
### Reliable Message Bus Relay (RMB-RS)
|
||||
A component or system that facilitates the reliable and secure transfer of messages between different entities or systems within the ThreeFold ecosystem. It acts as a relay or intermediary, ensuring that messages are delivered accurately and efficiently, even in the presence of network disruptions or failures. The RMB-RS employs robust protocols and mechanisms to guarantee message reliability, integrity, and confidentiality. It plays a crucial role in enabling seamless communication and data exchange between various components, applications, or nodes within the ThreeFold network, enhancing the overall reliability and performance of the system.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/rmb-rs)
|
||||
|
||||
### RMB-SDK-Go
|
||||
Software development kit (SDK) for interacting with the Reliable Message Bus (RMB) in the Go programming language. The Reliable Message Bus is a messaging system used within the ThreeFold ecosystem to enable reliable and secure communication between different components and services. The rmb-sdk-go provides a set of tools, libraries, and APIs that developers can use to integrate their Go applications with the RMB infrastructure. It simplifies the process of sending and receiving messages, managing subscriptions, and handling the reliability and security aspects of messaging within the ThreeFold environment.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/rmb-sdk-go)
|
||||
|
||||
### Terraform Provider
|
||||
A software tool that integrates with the popular infrastructure-as-code platform, Terraform. It enables users to provision and manage resources on the ThreeFold Grid using Terraform's declarative configuration language. The provider acts as a bridge between Terraform and the ThreeFold Grid, allowing users to define and deploy infrastructure components such as virtual machines, storage, and networking resources with ease. This integration simplifies the process of building and managing infrastructure on the ThreeFold Grid, offering users the familiar and powerful capabilities of Terraform while leveraging the decentralized and scalable nature of the ThreeFold technology.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/terraform-provider-grid)
|
||||
|
||||
### TCP-Router
|
||||
A component of the ThreeFold technology stack that acts as a TCP (Transmission Control Protocol) router and load balancer. It serves as a network gateway for incoming TCP connections, routing them to the appropriate destinations based on predefined rules and configurations. The TCP-Router component is responsible for distributing incoming network traffic across multiple backend services or nodes, ensuring efficient load balancing and high availability. It helps optimize network performance by evenly distributing the workload and preventing any single node from being overwhelmed. By managing and balancing TCP connections, tcprouter contributes to the overall scalability, reliability, and performance of applications running on the ThreeFold Grid.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tcprouter)
|
||||
|
||||
### TFChain
|
||||
A blockchain developed by the ThreeFold Foundation. It serves as the underlying technology for managing the ThreeFold Grid. TFChain is built on Parity Substrate. It is responsible for storing information related to the ThreeFold Grid, including identity information of entities, 3Node and farmer details, reputation information, digital twin registry, and more. TFChain also acts as the backend for the TFChain database and supports smart contracts for provisioning workloads on top of the ThreeFold Grid.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfchain)
|
||||
|
||||
### TFChain Activation Service
|
||||
A component within the ThreeFold ecosystem that facilitates the activation of TFChain accounts. TFChain is a blockchain developed by ThreeFold that serves as the backbone of the ThreeFold Grid. The Activation Service provides the necessary infrastructure and processes to activate and onboard users onto the TFChain network. It ensures that users can securely create and manage their TFChain accounts, including generating cryptographic keys, validating user identities, and enabling the activation of TFChain functionalities.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfchain_activation_service)
|
||||
|
||||
### TFChain Explorer
|
||||
A web-based tool that allows users to explore and interact with the TFChain blockchain. It provides a graphical interface where users can view transaction history, account balances, smart contracts, and other blockchain-related information. The TFChain Explorer offers transparency and visibility into the TFChain ecosystem, enabling users to track transactions, verify balances, and monitor the overall health of the network.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfchain_explorer)
|
||||
|
||||
### TFChain Block Explorer
|
||||
A web-based tool provided by ThreeFold that allows users to explore and interact with the TFChain blockchain. It provides a user-friendly interface to browse through blocks, transactions, and addresses on the TFChain network. Users can view detailed information about individual blocks and transactions, including timestamps, transaction amounts, and involved addresses. The block explorer also enables searching for specific transactions or addresses, making it easier to track and verify transactions on the TFChain blockchain. With the TFChain Block Explorer, users can gain transparency and visibility into the TFChain network, facilitating better understanding and analysis of blockchain activities.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfchain_block_explorer)
|
||||
|
||||
### TFChain-GraphQL
|
||||
The integration of GraphQL, a query language for APIs, with TFChain, the blockchain technology used by ThreeFold. It enables developers and users to interact with the TFChain blockchain using GraphQL queries and mutations. GraphQL provides a flexible and efficient way to retrieve and manipulate data from the TFChain blockchain, allowing for customized and precise data retrieval. With TFChain-GraphQL, users can easily query blockchain information, such as transaction details, account balances, or smart contract data, and perform mutations, such as submitting transactions or updating contract states.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfchain_graphql)
|
||||
|
||||
### TFChain TFT Bridge
|
||||
The bridge mechanism that enables the conversion of TFT tokens between different blockchain networks, specifically between the ThreeFold Chain (TFChain) and other blockchain networks such as Ethereum or Stellar. The TFChain TFT Bridge allows TFT tokens to be transferred seamlessly and securely across different blockchain platforms, maintaining their value and integrity. This bridge plays a crucial role in interoperability, enabling users to leverage TFT tokens on multiple blockchain networks, unlocking new possibilities for decentralized applications and token ecosystems.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/tfchain_tft_bridge)
|
||||
|
||||
### 3Bot or Threebot
|
||||
3Bot is a component of the ThreeFold ecosystem that refers to a personal digital assistant. It is a software entity that acts as a virtual representation of an individual or organization, providing various services and performing tasks on their behalf. The 3Bot is designed to be decentralized and secure, running on the ThreeFold Grid infrastructure. It can handle functions such as managing personal data, interacting with other digital entities, executing transactions, and offering a range of services through its customizable capabilities. The 3Bot component enables individuals and organizations to have their own private and secure digital assistant, tailored to their specific needs and preferences.
|
||||
|
||||
Note: This is a feature that involves multiple component repositories. It is listed here to give a complete picture of ThreeFold's component list.
|
||||
|
||||
### Threebot-deployer or 3Bot Deployer
|
||||
A tool provided by ThreeFold that facilitates the deployment of ThreeFold's ThreeBot applications. A ThreeBot is a personal digital assistant that can perform various tasks and provide services to users. The threebot-deployer simplifies the process of setting up and configuring a ThreeBot instance by automating many of the steps involved. It allows users to specify the desired configuration and parameters for their ThreeBot, such as the domain name, authentication settings, and available services. The threebot-deployer then handles the deployment process, ensuring that the ThreeBot is properly installed and configured according to the specified parameters. This tool streamlines the deployment process and enables users to quickly and easily set up their own personalized ThreeBot instances.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/threebot-deployer)
|
||||
|
||||
### ThreeFold Wallet
|
||||
A digital wallet designed to securely store and manage ThreeFold Tokens (TFT) and other digital assets inside the ThreeFold Connect App (TFConnect App). It provides users with a convenient and user-friendly interface to interact with their tokens, perform transactions, and track their token balances. The ThreeFold Wallet offers features such as wallet creation, private key management, token transfers, and transaction history. It ensures the security of users' assets through encryption and various authentication methods. The wallet serves as a gateway for users to access and engage with the ThreeFold ecosystem, enabling them to participate in token transactions, staking, and other activities.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/threefold_connect_wallet)
|
||||
|
||||
### ThreeFold Connect App
|
||||
Mobile application developed by ThreeFold that serves as a gateway to the ThreeFold Grid. It provides users with a secure and user-friendly wallet interface to access and manage their digital assets, such as ThreeFold Tokens (TFT), and interact with various services and applications within the ThreeFold ecosystem. The ThreeFold Connect App also provides an authenticator feature that ensures secure access and authentication to various services within the ThreeFold ecosystem. As an authenticator, it verifies the identity of users and provides them with secure access to their accounts and associated resources.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/threefold_connect)
|
||||
|
||||
### Zinit
|
||||
A lightweight, fast, and versatile package manager designed to simplify the installation and management of software components within the ThreeFold ecosystem. It provides a user-friendly interface for developers and system administrators to easily install, update, and remove software packages on their ThreeFold nodes. Zinit supports various package sources, including remote repositories, local files, and even directly from Git repositories, allowing users to easily fetch and install the desired software components. It also supports dependency resolution, ensuring that all required dependencies are installed correctly.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/zinit)
|
||||
|
||||
### 0-OS or ZOS
|
||||
ZOS (Zero Operating System) is a lightweight and secure operating system designed specifically for running workloads on the ThreeFold Grid. ZOS provides a minimalistic and containerized environment for applications, enabling efficient resource allocation and management. With ZOS, developers can deploy their applications easily and take advantage of the scalability and resilience offered by the ThreeFold Grid.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/zos)
|
||||
|
||||
### 0-bootstrap
|
||||
Also known as Zero-Bootstrap, is a component of the ThreeFold Grid infrastructure. It serves as the initial bootstrap mechanism for setting up and initializing the ThreeFold Grid network. 0-bootstrap provides the necessary tools and processes to deploy the core components of the ThreeFold Grid, including the Zero-OS operating system and other essential services. It helps in establishing the foundational layer of the grid network, enabling the deployment and management of compute resources, storage, and other decentralized services.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-bootstrap)
|
||||
|
||||
### 0-Bus or ZBus
|
||||
A component that facilitates interprocess communication (IPC) within the ThreeFold technology stack. It provides a lightweight and efficient messaging system that allows different software components or services to communicate with each other in a distributed environment. zbus implements a message bus architecture, where components can publish messages to topics and subscribe to receive messages from those topics. It enables decoupled and asynchronous communication between various parts of the system, promoting modularity and scalability. zbus plays a crucial role in enabling communication and coordination between different components of the ThreeFold infrastructure, such as the ThreeBot, ThreeFold Chain, and storage services, allowing them to work together seamlessly to deliver the desired functionality.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/zbus)
|
||||
|
||||
### 0-DB
|
||||
a distributed key-value database system. It is designed to provide efficient and secure storage for data in a decentralized environment.
|
||||
In 0-db, data is stored as key-value pairs, allowing for fast and efficient retrieval of information. It provides high-performance read and write operations, making it suitable for applications that require quick access to data. The distributed nature of 0-db ensures that data is replicated and stored across multiple nodes, enhancing data availability and durability.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-db)
|
||||
|
||||
### 0-DB-FS
|
||||
A storage system that allows for efficient and secure storage of files on the ThreeFold Grid. 0-db-fs is built on top of 0-db, which is a key-value store optimized for high performance and scalability. It provides a decentralized and distributed approach to file storage, ensuring data redundancy and availability. With 0-db-fs, users can securely store and retrieve files, benefiting from the decentralized nature of the ThreeFold Grid, which enhances data privacy, security, and resilience.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-db-fs)
|
||||
|
||||
### 0-Flist
|
||||
Also known as Zero-Flist, is a file system image format used in the ThreeFold Grid infrastructure. It represents a compressed and immutable snapshot of a specific file system configuration or application stack. 0-Flist files are used to package and distribute software, data, and configurations within the ThreeFold Grid. They contain all the necessary files and dependencies required to run an application or service. 0-Flist files are lightweight, portable, and easy to distribute, making them ideal for deploying applications across the decentralized network.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-flist)
|
||||
|
||||
### 0-Hub
|
||||
Also known as Zero-Hub, is a key component of the ThreeFold Grid infrastructure. It serves as the central hub or entry point for users and applications to connect with the decentralized network. 0-hub provides a user-friendly interface and API endpoints that allow users to interact with the ThreeFold Grid and access its resources. It acts as a bridge between the users and the underlying infrastructure, enabling them to deploy and manage their workloads, access decentralized storage, and utilize other services provided by the ThreeFold Grid. 0-hub also plays a crucial role in facilitating peer-to-peer communication and collaboration within the network, connecting users and allowing them to share and exchange resources securely.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-hub)
|
||||
|
||||
### 0-InitramFS
|
||||
Initial RAM file system used in the ThreeFold ecosystem. An initramfs is a temporary file system that is loaded into memory during the boot process before the root file system is mounted. It contains essential files and utilities needed to initialize the system and prepare it for the boot process. In the context of ThreeFold, the 0-initramfs is a customized initial RAM file system specifically designed for the ThreeFold Grid infrastructure. It includes necessary components and configurations to ensure a smooth and efficient boot process for ThreeFold nodes. By utilizing the 0-initramfs, the ThreeFold ecosystem can optimize the boot sequence and ensure the proper initialization of the system components before transitioning to the main operating system.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-initramfs)
|
||||
|
||||
### 0-stor_v2
|
||||
A component of the ThreeFold technology stack that refers to the second version of the 0-stor storage system. 0-stor_v2 is a distributed and decentralized storage solution that enables data storage and retrieval on the ThreeFold Grid. It utilizes erasure coding and sharding techniques to distribute data across multiple storage nodes, ensuring high availability and data redundancy. The 0-stor_v2 component provides an efficient and secure way to store data on the ThreeFold Grid, with features such as data encryption, replication, and integrity checks. It is designed to be scalable and fault-tolerant, allowing for the seamless expansion of storage capacity as needed. Developers and users can leverage 0-stor_v2 to store and manage their data in a decentralized and resilient manner, ensuring data privacy and accessibility on the ThreeFold Grid.
|
||||
|
||||
> [Component Repository on Github](https://github.com/threefoldtech/0-stor_v2)
|
||||
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
<h1> Infrastructure as Code (IaC) </h1>
|
||||
|
||||
<h2> Table of Contents </h2>
|
||||
|
||||
- [What is IaC?](#what-is-iac)
|
||||
- [Benefits of IaC](#benefits-of-iac)
|
||||
- [ThreeFold's IaC](#threefolds-iac)
|
||||
- [How it Works](#how-it-works)
|
||||
- [Dive Deeper](#dive-deeper)
|
||||
- [Manuals](#manuals)
|
||||
|
||||
***
|
||||
|
||||
## What is IaC?
|
||||
Infrastructure as Code (IaC) is a concept that revolutionizes the way infrastructure is provisioned and managed in the world of IT. It involves the use of declarative scripts or configuration files to define and automate the deployment, configuration, and management of infrastructure resources. With IaC, organizations can treat infrastructure provisioning as code, applying software development principles and practices to infrastructure management. This approach brings numerous benefits, such as increased efficiency, consistency, scalability, and reproducibility.
|
||||
|
||||
## Benefits of IaC
|
||||
Using IaC in the ThreeFold ecosystem brings several benefits.
|
||||
|
||||
- __Streamlined operations and increased efficiency__: One of the key benefits of Infrastructure as Code (IaC) is the significant improvement in speed and consistency. By eliminating manual processes and automating infrastructure provisioning through code, tasks can be completed faster and with greater accuracy. There is no longer a need to wait for IT administrators to manually perform tasks or worry about their availability. This allows for quicker iterations and faster deployments, enabling organizations to be more agile in their development processes. Consistency is also enhanced as infrastructure configurations are defined in code, ensuring that the same setup is replicated across environments and reducing the risk of configuration drift.
|
||||
|
||||
- __Empowered software development lifecycle__: IaC places more control in the hands of developers, enabling them to focus on application development rather than spending time on infrastructure management. With reliable and consistent infrastructure provisioning, developers can leverage reusable code scripts to deploy and manage resources efficiently. This streamlines the software development lifecycle, enabling faster development cycles and reducing the time and effort spent on manual infrastructure tasks. Developers can quickly spin up development and testing environments, experiment with different configurations, and roll out changes with ease.
|
||||
|
||||
- __Reduced management overhead__: IaC eliminates the need for multiple roles dedicated to managing different layers of hardware and middleware in traditional data center environments. With IaC, the management overhead is significantly reduced as infrastructure is defined and managed through code. This frees up administrators to focus on exploring and implementing new technologies and innovations, rather than being tied down by routine maintenance tasks. It simplifies the operational structure and allows for a more efficient allocation of resources, ultimately leading to cost savings and increased productivity.
|
||||
|
||||
Overall, IaC brings faster speed, improved consistency, efficient software development, and reduced management overhead. It empowers organizations to accelerate their deployment processes, enhance collaboration between development and operations teams, and optimize resource utilization. By adopting IaC practices, organizations can achieve greater agility, scalability, and cost efficiency in their infrastructure management, enabling them to stay competitive in today's fast-paced digital landscape.
|
||||
|
||||
## ThreeFold's IaC
|
||||
At ThreeFold, IaC plays a crucial role in the deployment and management of the ThreeFold Grid infrastructure. ThreeFold leverages popular IaC tools and methodologies to enable users to define and manage their infrastructure resources in a programmatic and scalable way. The IaC mechanism in ThreeFold involves components like __Terraform__, __TypeScript Client__, __GraphQL Client__, and __Grid Proxy REST API__.
|
||||
|
||||
__Terraform__ acts as the foundation for infrastructure provisioning, allowing users to define their desired infrastructure state using declarative configuration files. __The TypeScript and GraphQL clients__ provide interfaces for interacting with the ThreeFold Grid and managing resources programmatically, while the__ Grid Proxy REST API__ enables integration with external systems and applications.
|
||||
|
||||
## How it Works
|
||||
Firstly, __Terraform__ acts as the primary infrastructure provisioning tool. It provides a declarative language for defining infrastructure resources and their configurations, enabling users to express their infrastructure requirements in a human-readable and version-controlled manner.
|
||||
|
||||
__TypeScript Client and GraphQL Client__ serve as interfaces for interacting with the ThreeFold Grid, allowing users to create, update, and manage their infrastructure resources programmatically. These clients offer rich functionality and flexibility for managing various aspects of the ThreeFold Grid, including node deployment, capacity allocation, networking, and more.
|
||||
|
||||
__Grid Proxy REST API__ further enhances the extensibility of the IaC mechanism by enabling integration with external systems and applications, allowing for seamless automation and orchestration of infrastructure tasks. Together, these components form a robust and efficient IaC framework within the ThreeFold ecosystem, empowering users to manage their infrastructure as code with ease and precision.
|
||||
|
||||
## Dive Deeper
|
||||
- [How the Grid Works](../grid3_howitworks.md)
|
||||
- [ThreeFold's Component List](./grid3_components.md)
|
||||
- [Grace Periods](./contract_grace_period.md)
|
||||
|
||||
## Manuals
|
||||
- [Terraform](../../../documentation/system_administrators/terraform/terraform_toc.md)
|
||||
- [Typescript Client](../../../documentation/developers/javascript/grid3_javascript_readme.md)
|
||||
@@ -1,61 +0,0 @@
|
||||
<h1> What's New on ThreeFold Grid v3.x </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [TFChain v3.x](#tfchain-v3x)
|
||||
- [Key Features of TFChain v3.x:](#key-features-of--tfchain-v3x)
|
||||
- [Proof of Utilization: Enhancing Your Cloud Experience](#proof-of-utilization-enhancing-your-cloud-experience)
|
||||
- [Key Features:](#key-features)
|
||||
- [New TFGrid Explorer UI](#new-tfgrid-explorer-ui)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
The ThreeFold Grid v3.x is packed with exciting new features and enhancements. This marks a significant milestone in the evolution of our decentralized grid infrastructure, bringing even more power, flexibility, and innovation to our users. In this introduction, we will highlight some of the key new features that make ThreeFold Grid v3.x a game-changer in the world of decentralized technologies.
|
||||
|
||||
> Click [here](../concepts/grid3_components.md) to see the complete TFGrid Component List
|
||||
|
||||
## TFChain v3.x
|
||||
|
||||
[__TFChain v3.x__](../concepts/tfchain.md) is a decentralized chain that holds all the information about the entities comprising the ThreeFold Grid. It operates on the Parity Substrate blockchain infrastructure.
|
||||
|
||||
### Key Features of TFChain v3.x:
|
||||
|
||||
- Your identity and proofs/reputation are stored on our blockchain.
|
||||
- All information about TFGrid, including nodes and farmers, is made available.
|
||||
- A GraphQL interface that allows easy querying of the blockchain.
|
||||
- Provide Side chains supports, enabling unlimited scalability and allowing others to run their own blockchains.
|
||||
- TFT now exists on TFChain, addressing scalability issues with Stellar.
|
||||
- A bridge facilitates the transfer of TFT between Stellar and TFChain.
|
||||
- Blockchain-based provisioning process/
|
||||
- TFChain API that is available in JavaScript, Golang, and Vlang.
|
||||
- 'Infrastructure as Code' (IAC) framework support for:
|
||||
- Terraform
|
||||
- Kubernetes, Helm, Kubernetes
|
||||
- Ansible (planned)
|
||||
- Support for App deployment using CapRover
|
||||
- The use of RMB (Reliable Message Bus) that ensures secure peer-to-peer communication with Zero-OS.
|
||||
|
||||
Please note that the above list summarizes the key features introduced in TFChain v3.0.
|
||||
|
||||
## Proof of Utilization: Enhancing Your Cloud Experience
|
||||
|
||||
Experience the benefits of Proof of Utilization, a user-friendly feature that optimizes your cloud usage and rewards your pre-purchases. Here are the key features:
|
||||
|
||||
### Key Features:
|
||||
|
||||
- __Hourly Resource Utilization__: Your resource utilization is accurately captured and calculated on an hourly basis, ensuring transparency and precision in tracking your cloud usage.
|
||||
|
||||
- __Secure Storage on TFChain__: Your resource utilization data is securely stored in TFChain, our dedicated blockchain, providing a reliable and tamper-proof record of your usage history.
|
||||
|
||||
- __Automated Discount System__: Our innovative automated discount system acknowledges your pre-purchased cloud needs. Based on the amount of TFT (ThreeFold Tokens) you hold in your account and the duration you maintain these tokens, you can enjoy significant price discounts.
|
||||
|
||||
- __Personalized Discounts__: The discount you receive is customized to your TFT holdings and usage patterns. For instance, if you hold TFT tokens equivalent to 12 months' worth of usage, you receive a generous 40% discount. Holding TFT tokens for 36 months unlocks an impressive 60% discount on your cloud services.
|
||||
|
||||
|
||||
### New TFGrid Explorer UI
|
||||
|
||||
- The TFGrid Explorer v3.x has an updated user interface that is now nicer and easier to use.
|
||||
- It utilizes the GraphQL layer of TFChain.
|
||||
@@ -1,60 +0,0 @@
|
||||
<h1> ThreeFold Grid Primitives: Empowering Your Solutions </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Compute](#compute)
|
||||
- [Storage](#storage)
|
||||
- [Network](#network)
|
||||
- [Zero-OS Advantages](#zero-os-advantages)
|
||||
- [Conclusion](#conclusion)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
Within the ThreeFold Grid, we offer a range of __low-level constructs known as Primitives__. These powerful functionalities enable you to create diverse and customized solutions atop the grid, opening up a world of possibilities. It's important to note that any application compatible with Linux can seamlessly run on the ThreeFold Grid, ensuring maximum flexibility.
|
||||
|
||||
## Compute
|
||||
|
||||
Harness the power of computation with our compute primitives, measured in [compute units](../../cloud/cloudunits.md) (CU).
|
||||
|
||||
- [ZKube](../../technology/primitives/compute/zkube.md): Deploy and manage Kubernetes clusters effortlessly.
|
||||
- [ZMachine](../../technology/primitives/compute/zmachine.md): Run your applications within containers or virtual machines powered by the Zero-OS operating system.
|
||||
- [CoreX](../../technology/primitives/compute/corex.md) (optional): Gain remote access to your ZMachine by utilizing the CoreX process manager.
|
||||
|
||||
## Storage
|
||||
|
||||
Leverage our robust storage Primitives, measured in [storage units](../../cloud/cloudunits.md) (SU), to meet your data storage requirements efficiently.
|
||||
|
||||
- [ZOS Filesystem](../../technology/primitives/storage/zos_fs.md): Enjoy a deduplicated and immutable filesystem for secure and reliable data storage.
|
||||
- [ZOS Mount](../../technology/primitives/storage/zmount.md): Utilize a portion of a high-speed SSD (Solid State Drive) as a mounted disk directly accessible within your ZMachine.
|
||||
- [Quantum Safe Filesystem](../../technology/primitives/storage/qsfs.md): Secure your data with an unbreakable storage system, ideal for secondary storage needs.
|
||||
- [Zero-DB](../../technology/primitives/storage/zdb.md): Experience a powerful key-value storage mechanism that serves as the foundation for other storage mechanisms.
|
||||
- [Zero-Disk](../../technology/primitives/storage/zdisk.md) (OEM only): Employ a virtual disk format designed exclusively for original equipment manufacturers.
|
||||
|
||||
## Network
|
||||
|
||||
Harness our network Primitives, measured in [network units](../../cloud/cloudunits.md) (CU), to enable seamless communication and connectivity.
|
||||
|
||||
- [ZNET](../../technology/primitives/network/znet.md): Establish private networks between ZMachines, ensuring secure and efficient communication.
|
||||
- [ZNIC](../../technology/primitives/network/znic.md): Access and manage network interfaces within the Planetary Network, enabling efficient data transfer and communication.
|
||||
- [WebGateway](../../technology/primitives/network/webgw3.md): Connect your ZNET to the internet with ease, facilitating seamless integration with the wider network.
|
||||
|
||||
## Zero-OS Advantages
|
||||
|
||||
Enjoy the [numerous advantages](../../technology/zos/benefits/zos_advantages.md) that Zero-OS brings to the table.
|
||||
|
||||
- [Zero Install](../../technology/zos/benefits/zos_advantages.md#zero-os-installation): Experience hassle-free deployment without the need for complex installations.
|
||||
- [Unbreakable Storage](../../technology/zos/benefits/zos_advantages.md#unbreakable-storage): Ensure the integrity and security of your data with our robust storage mechanisms.
|
||||
- [Zero Hacking Surface](../../technology/zos/benefits/zos_advantages.md#zero-hacking-surface): Benefit from a minimized attack surface, bolstering the security of your infrastructure.
|
||||
- [Zero Boot](../../technology/zos/benefits/zos_advantages.md#zero-boot): Enjoy lightning-fast boot times, allowing for swift and efficient system initialization.
|
||||
- [Deterministic Deployment](../../technology/zos/benefits/zos_advantages.md#deterministic-deployment): Achieve consistent and predictable deployments, streamlining your development process.
|
||||
- [ZOS Protect](../../technology/zos/benefits/zos_advantages.md#zero-os-protect): Experience enhanced protection and security measures to safeguard your infrastructure.
|
||||
|
||||
## Conclusion
|
||||
|
||||
With these powerful Primitives and Zero-OS advantages, the ThreeFold Grid empowers you to build, scale, and secure your solutions with ease. Unleash your creativity and unlock limitless possibilities within the ThreeFold ecosystem.
|
||||
|
||||
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
tft.png
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 290 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 100 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 229 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 390 KiB |
@@ -1,29 +0,0 @@
|
||||
<h1> Proof of Utilization </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Overview](#overview)
|
||||
- [CU, SU, NU](#cu-su-nu)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
The ThreeFold Grid employs a unique mechanism called __Proof of Utilization__ to track and measure resource utilization within its decentralized network. We provide here an overview of this mechanism.
|
||||
|
||||
## Overview
|
||||
|
||||
Proof of Utilization is a system that records resource usage on an hourly basis and serves as a transparent and reliable way to validate and verify the utilization of various components of the grid.
|
||||
|
||||
The Proof of Utilization concept encompasses the monitoring and tracking of three key types of resources within the ThreeFold Grid:__Compute Resources (CU)__, __Storage Resources (SU)__, and __Network resources (NU)__. These resources are essential for supporting the diverse needs of users and applications on the grid.
|
||||
|
||||
## CU, SU, NU
|
||||
|
||||
__Compute resources (CU)__ refer to the computational power and processing capabilities provided by the ThreeFold Grid. This includes the ability to run applications, execute tasks, and perform complex computations in a distributed and decentralized manner.
|
||||
|
||||
__Storage resources (SU)__ encompass the capacity to store and manage data within the ThreeFold Grid. It enables users to securely store and retrieve their data, ensuring reliable and scalable data management solutions.
|
||||
|
||||
__Network resources (NU)__ focus on the network connectivity and bandwidth available within the ThreeFold Grid. This includes the transmission of data, communication between nodes, and facilitating the seamless flow of information across the decentralized network.
|
||||
|
||||
In addition to the resources mentioned above, the Proof of Utilization system also tracks network utilization parameters such as __IPv4 addresses__, __DNS services__, and __name-on-web gateways__. These elements play a crucial role in enabling effective communication and accessibility within the ThreeFold Grid.
|
||||
@@ -1,152 +0,0 @@
|
||||
<h1>TFGrid by Design: Deployment Architectures and Solution Categories</h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [TFGrid by Design](#tfgrid-by-design)
|
||||
- [Capacity and Connectivity](#capacity-and-connectivity)
|
||||
- [TFGrid Main Components Overview and Examples](#tfgrid-main-components-overview-and-examples)
|
||||
- [Storage Units](#storage-units)
|
||||
- [0-DB-FS](#0-db-fs)
|
||||
- [0-stor\_v2](#0-stor_v2)
|
||||
- [QSFS](#qsfs)
|
||||
- [Compute Units](#compute-units)
|
||||
- [Virtual CPUs (vCPUs)](#virtual-cpus-vcpus)
|
||||
- [Kubernetes](#kubernetes)
|
||||
- [TF Grid-SDK-Go and TF Grid-SDK-TS](#tf-grid-sdk-go-and-tf-grid-sdk-ts)
|
||||
- [Network Units](#network-units)
|
||||
- [Reliable Message Bus Relay (RMB-RS)](#reliable-message-bus-relay-rmb-rs)
|
||||
- [TCP-Router](#tcp-router)
|
||||
- [Solution Categories](#solution-categories)
|
||||
- [DIY Workloads](#diy-workloads)
|
||||
- [Independent Commercial Offerings](#independent-commercial-offerings)
|
||||
- [ThreeFold Commercial Offerings](#threefold-commercial-offerings)
|
||||
- [Best Practices](#best-practices)
|
||||
- [Questions and Feedback](#questions-and-feedback)
|
||||
|
||||
***
|
||||
|
||||
# Introduction
|
||||
|
||||
Before starting a project on the TFGrid, it can be good idea to consider the overall design of the grid itself, and to ponder the potential solution designs you can come up with to ensure reliable and resilient deployments. This text will explore some of the main components of the TFGrid as well as its inherent design in order to provide sufficient information for system administrators to deploy effective and reliable solutions. We will also cover the three main solution categories that can be built on top of the TFGrid.
|
||||
|
||||
## TFGrid by Design
|
||||
|
||||
At its core, the TFGrid is composed of thousands of 3Nodes. 3Nodes provide storage, compute and network units to the TFGrid. By design, 3Nodes are not reliable in themselves, in the sense that a 3Node online today could be offline tomorrow if hardware or connection failures arise. This reality is inherent to any cloud enterprises. But this does not mean that reliability is not possible on the TFGrid. To the contrary, the TFGrid is composed of different components that can be utilized to provide reliability in all aspects of the grid: storage, compute and network. It is the role of system administrators to develop solutions that will be reliable in themselves.
|
||||
|
||||
A myriad of possibilities and configurations are possible within the TFGrid ecosystem and, by understanding the interconnectedness between the grid components, one can knowingly build a solid deployment that will respond to the needs of a given project.
|
||||
|
||||
## Capacity and Connectivity
|
||||
|
||||
When it comes to deployments, we must consider two major aspects of the Internet infrastructure: capacity and connectivity. While capacity can be thought as the individual 3Nodes composing the TFGrid, where information is processed and stored within the 3Nodes, connectivity can be thought as the links and information transfers between the 3Nodes and the public Internet.
|
||||
|
||||
As a general consideration, the TFGrid works mostly on the capacity side, whereas a 3Node will always be connected to the Internet by ways of different Internet Service Providers (ISP) depending on the farmer's location and resources. The 3Nodes provide storage and compute units where users can store information on SSD and HDD disks and where they can generate compute processes with CPUs. Another major component of the TFGrid would be network units. While, as said before, the TFGrid does not provide directly connectivity as per the traditional ISP services, elements such as gateways and Wireguard VPNs are further related to network units than compute or storage units.
|
||||
|
||||
To build a reliable deployment on the TFGrid, you need to take into consideration the three different types of unit on the TFGrid: storage, compute and network. Let's delve into these a little bit more.
|
||||
|
||||
# TFGrid Main Components Overview and Examples
|
||||
|
||||
We provide here an overview of some of the main components of the TFGrid. We also provide examples for each of those components in order for the reader to obtain a clear understanding of the TF Ecosystem. By understanding the different components of the TFGrid, system administrators will be able to deploy resilient, redundant and reliable solutions on the grid.
|
||||
|
||||
For a complete list of the TFGrid components, read [this documentation](./grid3_components.md).
|
||||
|
||||
## Storage Units
|
||||
|
||||
Storage units are related to the data stored in SSD and HDD disks. The Quantum Safe Filesystem (QSFS) technology developed by ThreeFold ensures redundancy and resilience in storage units. If one disk of the QSFS array goes offline, the rest of the system can still function properly. To the contrary, if a user stores information on one single 3Node and this 3Node has a drastic disk failure, the user will lose the data. Another way to achieve redundancy in the storage category would be to deploy a solution with real-time synced databases of two or more 3nodes connected via a wireguard VPN. Note that other configurations offering reliability and redundancy are possible.
|
||||
|
||||
Let's explore some storage components of the ThreeFold Grid.
|
||||
|
||||
### 0-DB-FS
|
||||
|
||||
[0-DB-FS](./grid3_components.md#0-db-fs) is storage system that allows for efficient and secure storage of files on the ThreeFold Grid. 0-DB-FS is built on top of 0-DB, which is a key-value store optimized for high performance and scalability. It provides a decentralized and distributed approach to file storage, ensuring data redundancy and availability.
|
||||
|
||||
### 0-stor_v2
|
||||
|
||||
[0-stor_v2](./grid3_components.md#0-stor_v2) is a distributed and decentralized storage solution that enables data storage and retrieval on the ThreeFold Grid.
|
||||
|
||||
### QSFS
|
||||
|
||||
[Quantum Safe Filesystem (QSFS)](./grid3_components.md#qsfs) is ThreeFold's innovative storage solution designed to address the security challenges posed by quantum computing. QSFS employs advanced cryptographic techniques that are resistant to attacks from quantum computers, ensuring the confidentiality and integrity of stored data. By its design, QSFS also offers a high level of redundancy.
|
||||
|
||||
## Compute Units
|
||||
|
||||
Compute units are related to the CPUs doing calculations during the deployment. If a user deploys on a 3Node and uses the CPUs of the units while those CPUs experience failure, the user will lose compute power. as a main example, a way to achieve redundancy in the compute category would be to deploy a solution via Kubernetes. In this case, the CPU workload is balanced between the different 3Nodes of the Kubernetes cluster and if one 3Node fails, the deployment can still function properly.
|
||||
|
||||
Let's explore some compute components of the ThreeFold Grid.
|
||||
|
||||
### Virtual CPUs (vCPUs)
|
||||
|
||||
Virtual CPUs (vCPUs) are virtual representations of physical CPUs that allow multiple virtual machines (VMs) to run concurrently on a single physical server or host. Virtualization platforms allocate vCPUs to each VM, enabling them to execute tasks and run applications as if they were running on dedicated physical hardware. The number of vCPUs assigned to a VM determines its processing power and capacity to handle workloads. On the TFGrid, the number of vCPUs is limited to the physical number of CPUs on the host (i.e. the 3Node). Since this limitation is done per VM, this means that a node with 8 cores can still have 2 VMs each with 8 vCPUs.
|
||||
|
||||
### Kubernetes
|
||||
|
||||
[Kubernetes](../../../documentation/dashboard/solutions/k8s.md) is an open-source container orchestration system for automating software deployment, scaling, and management. On the TFGrid, Kubernetes clusters can be deployed out of the box. Thus, system administrators can seamlessly deploy solutions on the TFGrid that are reliable in terms of compute units.
|
||||
|
||||
### TF Grid-SDK-Go and TF Grid-SDK-TS
|
||||
|
||||
The [TFGrid-SDK-Go](./grid3_components.md#tf-grid-sdk-go) and [TFGrid-SDK-TS](./grid3_components.md#tf-grid-sdk-ts) enable developers to interact with the ThreeFold Grid infrastructure, such as provisioning and managing compute resources, accessing storage, and interacting with the blockchain-based services. They provide a standardized and convenient way to leverage the features and capabilities of the ThreeFold Grid within Go and Typescript applications.
|
||||
|
||||
## Network Units
|
||||
|
||||
Network units are related to the data transmitted over the Internet. While TFGrid does not provide direct ISP services, elements such as gateways are clearly related to the network. [Gateways](../../../documentation/system_administrators/terraform/resources/terraform_vm_gateway.md) can be used to balance network workloads. A deployment could consist of two different gateways with a master node gateway and a worker node gateway. If the master gateway would fail, the worker gateway would take the lead and become the master gateway. Deploying solutions with several gateways can help system administrators build reliable solutions.
|
||||
|
||||
Note that it is also possible to deploy a Wireguard virtual private network (VPN) between different 3Nodes and synchronize their databases. This provides resilience and redundancy. Read more on VPN and synced databases [here](../../../documentation/system_administrators/terraform/advanced/terraform_mariadb_synced_databases.md).
|
||||
|
||||
Let's explore some network components of the ThreeFold Grid.
|
||||
|
||||
### Reliable Message Bus Relay (RMB-RS)
|
||||
|
||||
[Reliable Message Bus Relay (RMB-RS)](./grid3_components.md#reliable-message-bus-relay-rmb-rs) is a component or system that facilitates the reliable and secure transfer of messages between different entities or systems within the ThreeFold ecosystem. It acts as a relay or intermediary, ensuring that messages are delivered accurately and efficiently, even in the presence of network disruptions or failures. The RMB-RS employs robust protocols and mechanisms to guarantee message reliability, integrity, and confidentiality.
|
||||
|
||||
### TCP-Router
|
||||
|
||||
[TCP-Router](./grid3_components.md#tcp-router) is a component of the ThreeFold technology stack that acts as a TCP (Transmission Control Protocol) router and load balancer. It serves as a network gateway for incoming TCP connections, routing them to the appropriate destinations based on predefined rules and configurations. The TCP-Router component is responsible for distributing incoming network traffic across multiple backend services or nodes, ensuring efficient load balancing and high availability.
|
||||
|
||||
# Solution Categories
|
||||
|
||||
There are three main solution categories on the TFGrid: DIY workloads, independent commercial offerings, and ThreeFold commercial offerings. Let's take a look at them and discuss their basic properties.
|
||||
|
||||
## DIY Workloads
|
||||
|
||||
Out-of-the-box applications are available on the [TF Dashboard](../../../documentation/dashboard/deploy/applications.md) and [Terraform](../../../documentation/system_administrators/terraform/terraform_toc.md), where anyone can [buy TFTs](../../../documentation/threefold_token/buy_sell_tft/buy_sell_tft.md) and deploy on the decentralized and open-source grid. The reliability of those deployments depend on the capacity and resources of each DIY system administrator.
|
||||
|
||||
In essence, when you deploy on the decentralized and open-source TFGrid, you act as a centralized entity building the solution architecture. You must design the solution in a way that it can be reliable with high-availability and resilience levels that suit the needs of your project.
|
||||
|
||||
Note that when you deploy on the ThreeFold Grid, you are doing so in accordance with the [ThreeFold Terms and Conditions](../../legal/terms_conditions_all3.md).
|
||||
|
||||
## Independent Commercial Offerings
|
||||
|
||||
Since the TFGrid is open-source, anyone could decide to build a commercial offering on top of the grid. In this case, it would be recommended for the commercial offering to provide Terms and Conditions, clear support, a website to advertise the product and a marketing strategy to obtain customers.
|
||||
|
||||
In this case, the commercial offering is the centralized entity and if the company makes a mistake, it would be liable to the users to the extent discussed in the T&C.
|
||||
|
||||
The ThreeFold Manual already contains a lot of resourceful information on how to [deploy applications](../../../documentation/dashboard/deploy/applications.md) on the TFGrid. We invite everyone to develop independent commercial offerings on top of the ThreeFold Grid.
|
||||
|
||||
## ThreeFold Commercial Offerings
|
||||
|
||||
ThreeFold is building commercial offerings on top of the TFGrid. Those commercial offerings are for-profit organizations. Each of those organizations would function as a centralized entity.
|
||||
|
||||
ThreeFold Ventures will be the branch exploring this aspect of the TF Ecosystem. A major project on the way is [ThreeFold Cloud](https://cloud.threefold.io/). ThreeFold Cloud is thus a centralized entity that will generate its own Terms and Conditions, support, marketing and website strategy. Furthermore, ThreeFold Cloud will be liable to its users to the extent developed in the ThreeFold Cloud Terms and Conditions.
|
||||
|
||||
# Best Practices
|
||||
|
||||
This text provided an introduction to some deployment architectures and solution categories possible on the TFGrid. In the future, we will expand on some of the main TFGrid best practices. Stay tuned for more on this topic.
|
||||
|
||||
Some of the best practices to be covered are the following:
|
||||
|
||||
* Use Kubernetes to deploy redundant workloads
|
||||
* Use multi-gateways deployments for redundancy
|
||||
* Deploy manually two VMs
|
||||
* Use two webgateways to access the VMs
|
||||
* Choose a data replication strategy to have content on both places (e.g. syncing databases)
|
||||
* Use continous deployment and integration workloads
|
||||
* Deploy on 2 different VMs
|
||||
* Ensure continuous deployment and integration when changes occur
|
||||
* Use DNS with redundancy
|
||||
* Use QSFS for storage resilience and redundancy
|
||||
|
||||
These are only a few of the many possibilities that the TFGrid offers. We invite everyone to explore the TFGrid and share their experience and learning.
|
||||
|
||||
# Questions and Feedback
|
||||
|
||||
If you have any questions or feedback, we invite you to discuss with the ThreeFold community on the [ThreeFold Forum](http://forum.threefold.io/) or on the [ThreeFold Grid Tester Community](https://t.me/threefoldtesting) chat on Telegram.
|
||||
@@ -1,19 +0,0 @@
|
||||
|
||||
|
||||
# DAO Consensus Engine
|
||||
|
||||
!!!include:dao_info
|
||||
|
||||
## DAO Engine
|
||||
|
||||
On TFGrid 3.0 ThreeFold has implemented a DAO consensus engine using Polkadot/Substrate blockchain technology.
|
||||
|
||||
This is a powerful blockchain construct which allows us to run our TFGrid and maintain consensus on global scale.
|
||||
|
||||
This system has been designed to be compatible with multiple blockchains.
|
||||
|
||||
!!!include:consensus3_overview_graph
|
||||
|
||||
!!!include:consensus3_toc
|
||||
|
||||
!!!def alias:consensus3,consensus_engine
|
||||
@@ -1,17 +0,0 @@
|
||||
|
||||
|
||||
### consensus engine in relation to TFT Farming Rewards in TFGrid 3.0
|
||||
|
||||
!!!include:consensus3_overview_graph
|
||||
|
||||
The consensus engine checks the farming rules as defined in
|
||||
|
||||
- [farming logic 3.0](farming_reward)
|
||||
- [farming reward calculator](farming_calculator)
|
||||
|
||||
- if uptime + 98% per month then the TFT will be rewarded to the farmer (for TFGrid 3.0, can change later).
|
||||
|
||||
All the data of the farmer and the 3nodes are registered on TFChain
|
||||
|
||||
|
||||
!!!include:consensus3_toc
|
||||
@@ -1,44 +0,0 @@
|
||||
|
||||
## Consensus 3.X Oracles used
|
||||
|
||||
Oracles are external resources of information.
|
||||
|
||||
The TFChain captures and holds that information so we get more certainty about the accuracy.
|
||||
|
||||
We have oracles for price & reputation for e.g. TF Farmers and 3Nodes.
|
||||
|
||||
These oracles are implemented on TF_CHAIN for TFGrid 3.0.
|
||||
|
||||
```mermaid
|
||||
|
||||
|
||||
graph TB
|
||||
subgraph Digital Currency Ecosystem
|
||||
money_blockchain[Money Blockchain Explorers]
|
||||
Exch1[Money Blockchain Decentralized Exchange]
|
||||
OracleEngine --> Exch1[Polkadot]
|
||||
OracleEngine --> Exch1[Money Blockchain Exchange]
|
||||
OracleEngine --> Exch2[Binance Exchange]
|
||||
OracleEngine --> Exch3[other... exchanges]
|
||||
end
|
||||
subgraph ThreeFold Grid
|
||||
Monitor_Engine --> 3Node1
|
||||
Monitor_Engine --> 3Node2
|
||||
Monitor_Engine --> 3Node3
|
||||
end
|
||||
subgraph TFChainNode1[TFGrid Blockchain Node]
|
||||
Monitor_Engine
|
||||
Explorers[TFChain Explorers]-->TFGridDB --> BCNode
|
||||
Explorers --> BCNode
|
||||
ConsensusEngine1-->BCNode[Blockchain Validator Node]
|
||||
ConsensusEngine1 --> money_blockchain[Money Blockchain]
|
||||
ConsensusEngine1 --> ReputationEngine[Reputation Engine]
|
||||
ReputationEngine --> Monitor_Engine[Monitor Engine]
|
||||
ConsensusEngine1 --> OracleEngine[Oracle For Pricing Digital Currencies]
|
||||
end
|
||||
|
||||
```
|
||||
|
||||
> TODO: outdated info
|
||||
|
||||
!!!include:consensus3_toc
|
||||
@@ -1,51 +0,0 @@
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph Money Blockchain
|
||||
money_blockchain --> account1
|
||||
money_blockchain --> account2
|
||||
money_blockchain --> account3
|
||||
click money_blockchain "/threefold/#money_blockchain"
|
||||
end
|
||||
subgraph TFChainNode1[TFChain BCNode]
|
||||
Explorer1-->BCNode1
|
||||
ConsensusEngine1-->BCNode1
|
||||
ConsensusEngine1 --> money_blockchain
|
||||
ConsensusEngine1 --> ReputationEngine1
|
||||
ReputationEngine1 --> Monitor_Engine1
|
||||
click ReputationEngine1 "/info/threefold/#reputationengine"
|
||||
click ConsensusEngine1 "/info/threefold/#consensusengine"
|
||||
click BCNode1 "/info/threefold/#bcnode"
|
||||
click Explorer1 "/info/threefold/#tfexplorer"
|
||||
end
|
||||
subgraph TFChainNode2[TFChain BCNode]
|
||||
Explorer2-->BCNode2
|
||||
ConsensusEngine2-->BCNode2
|
||||
ConsensusEngine2 --> money_blockchain
|
||||
ConsensusEngine2 --> ReputationEngine2
|
||||
ReputationEngine2 --> Monitor_Engine2
|
||||
click ReputationEngine2 "/info/threefold/#reputationengine"
|
||||
click ConsensusEngine2 "/info/threefold/#consensusengine"
|
||||
click BCNoBCNode2de1 "/info/threefold/#bcnode"
|
||||
click Explorer2 "/info/threefold/#tfexplorer"
|
||||
|
||||
end
|
||||
Monitor_Engine1 --> 3Node1
|
||||
Monitor_Engine1 --> 3Node2
|
||||
Monitor_Engine1 --> 3Node3
|
||||
Monitor_Engine2 --> 3Node1
|
||||
Monitor_Engine2 --> 3Node2
|
||||
Monitor_Engine2 --> 3Node3
|
||||
click 3Node1 "/info/threefold/#3node"
|
||||
click 3Node2 "/info/threefold/#3node"
|
||||
click 3Node3 "/info/threefold/#3node"
|
||||
click Monitor_Engine1 "/info/threefold/#monitorengine"
|
||||
click Monitor_Engine2 "/info/threefold/#monitorengine"
|
||||
|
||||
|
||||
```
|
||||
|
||||
*click on the parts of the image, they will go to more info*
|
||||
|
||||
> TODO: outdated info
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
# Consensus Mechanism
|
||||
|
||||
## Blockchain node components
|
||||
|
||||
!!!include:consensus3_overview_graph
|
||||
|
||||
- A Blockchain node (= Substrate node) called TF-Chain, containing all entities interacting with each other on the TF-Grid
|
||||
- An explorer = a Rest + GraphQL interface to TF-Chain (Graphql is a nice query language to make it easy for everyone to query for info)
|
||||
- Consensus Engine
|
||||
- is a Multisignature Engine running on TF-Chain
|
||||
- The multisignature is done for the Money BlockchainAccounts
|
||||
- It checks the AccountMetadata versus reality and if ok, will sign, which allows transactions to happen after validation of the "smart contract"
|
||||
- SLA & reputation engine
|
||||
- Each node uptime is being checked by Monitor_Engine
|
||||
- Also bandwidth will be checked in the future (starting 3.x)
|
||||
|
||||
### Remarks
|
||||
|
||||
- Each Monitor_Engine checks uptime of X nr of nodes (in beginning it can do all nodes), and stores the info in local DB (to keep history of check)
|
||||
|
||||
## Principle
|
||||
|
||||
- We keep things as simple as we can
|
||||
- Money Blockchain blockchain used to hold the money
|
||||
- Money Blockchain has all required features to allow users to manage their money like wallet support, decentralized exchange, good reporting, low transaction fees, ...
|
||||
- Substrate based TFChain is holding the metadata for the accounts which express what we need to know per account to allow the start contracts to execute.
|
||||
- Smart Contracts are implemented using multisignature feature on Money Blockchain in combination with Multi Signature done by Consensus_Engine.
|
||||
- on money_blockchain:
|
||||
- each user has Money BlockchainAccounts (each of them holds money)
|
||||
- there are normal Accounts (means people can freely transfer money from these accounts) as well as RestrictedAccounts. Money cannot be transfered out of RestrictedAccounts unless consensus has been achieved from ConsensusEngine.
|
||||
- Restricted_Account
|
||||
- On stellar we use the multisignature feature to make sure that locked/vesting or FarmingPool cannot transfer money unless consensus is achieved by the ConsensusEngine
|
||||
|
||||
- Each account on money_blockchain (Money BlockchainAccount) has account record in TFChain who needs advanced features like:
|
||||
- lockup
|
||||
- vesting
|
||||
- minting (rewards to farmers)
|
||||
- tfta to tft conversion
|
||||
|
||||
- The Account record in TFGrid_DB is called AccountMetadata.
|
||||
- The AccountMetadata describes all info required to be able for consensus engine to define what to do for advanced features like vesting, locking, ...
|
||||
|
||||
> TODO: outdated info
|
||||
|
||||
!!!include:consensus3_toc
|
||||
@@ -1,13 +0,0 @@
|
||||
|
||||
## Consensus Engine Information
|
||||
|
||||
- [Consensus Engine Homepage](consensus3)
|
||||
- [Principles TFChain 3.0 Consensus](consensus3_principles)
|
||||
- [Consensus Engine Farming 3.0](consensus3_engine_farming)
|
||||
- [TFGrid 3.0 wallets](tfgrid3_wallets)
|
||||
- Architecture:
|
||||
- [Money Blockchains/Substrate architecture](money_blockchain_partity_link)
|
||||
<!-- - [Consensus Engine Weight System](consensus3_weights) -->
|
||||
|
||||
> implemented in TFGrid 3.0
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 64 KiB |
@@ -1,53 +0,0 @@
|
||||
|
||||
## Link between different Money Blockchain & TFChain
|
||||
|
||||
TF-Chain is the ThreeFold blockchain infrastructure, set up in the Substrate framework.
|
||||
|
||||
We are building a consensus layer which allows us to easily bridge between different money blockchains.
|
||||
|
||||
Main blockchain for TFT remains the Stellar network for now. A secure bridging mechanism exists, able to transfer TFT between the different blockchains.
|
||||
Active bridges as from TFGrid 3.0 release:
|
||||
- Stellar <> Binance Smart Chain
|
||||
- Stellar <> Parity Substrate
|
||||
More bridges are under development.
|
||||
|
||||
```mermaid
|
||||
|
||||
|
||||
graph TB
|
||||
subgraph Money Blockchain
|
||||
money_blockchain --- account1a
|
||||
money_blockchain --- account2a
|
||||
money_blockchain --- account3a
|
||||
account1a --> money_user_1
|
||||
account2a --> money_user_2
|
||||
account3a --> money_user_3
|
||||
click money_blockchain "/info/threefold/#money_blockchain"
|
||||
end
|
||||
subgraph ThreeFold Blockchain On Parity
|
||||
TFBlockchain --- account1b[account 1]
|
||||
TFBlockchain --- account2b[account 2]
|
||||
TFBlockchain --- account3b[account 3]
|
||||
account1b --- smart_contract_data_1
|
||||
account2b --- smart_contract_data_2
|
||||
account3b --- smart_contract_data_3
|
||||
click TFBlockchain "/info/threefold/#tfchain"
|
||||
end
|
||||
account1b ---- account1a[account 1]
|
||||
account2b ---- account2a[account 2]
|
||||
account3b ---- account3a[account 3]
|
||||
|
||||
consensus_engine --> smart_contract_data_1[fa:fa-ban smart contract metadata]
|
||||
consensus_engine --> smart_contract_data_2[fa:fa-ban smart contract metadata ]
|
||||
consensus_engine --> smart_contract_data_3[fa:fa-ban smart contract metadata]
|
||||
consensus_engine --> account1a
|
||||
consensus_engine --> account2a
|
||||
consensus_engine --> account3a
|
||||
click consensus_engine "/info/threefold/#consensus_engine"
|
||||
|
||||
|
||||
```
|
||||
|
||||
Above diagram shows how our consensus engine can deal with Substrate and multiple Money Blockchains at same time.
|
||||
|
||||
!!!include:consensus3_toc
|
||||
@@ -1,52 +0,0 @@
|
||||
|
||||
# Roadmap For our TFCHain and ThreeFold DAO
|
||||
|
||||
|
||||
|
||||
## TFChain / DAO 3.0.2
|
||||
|
||||
For this phase our TFChain and TFDAO has been implemented using parity/substrate.
|
||||
|
||||
Features
|
||||
|
||||
- poc
|
||||
- pou
|
||||
- identity management
|
||||
- consensus for upgrades of DAO and TFChain (code)
|
||||
- capacity tracking (how much capacity used)
|
||||
- uptime achieved
|
||||
- capacity utization
|
||||
- smart contract for IT
|
||||
- storage of value = TFT
|
||||
- request/approval for adding a validator
|
||||
|
||||
Basically all basic DAO concepts are in place
|
||||
|
||||
## TFChain / DAO 3.0.x
|
||||
|
||||
TBD version nr, planned Q1 2022
|
||||
|
||||
NEW
|
||||
|
||||
- proposals for TFChain/DAO/TFGrid changes (request for change) = we call them TFCRP (ThreeFold Change Request Proposal)
|
||||
- voting on proposals = we call them TFCRV (ThreeFold Change Request Vote)
|
||||
|
||||
|
||||
## TFChain / DAO 3.1.x
|
||||
|
||||
TBD version nr, planned Q1 2022
|
||||
|
||||
This version adds more layers to our existing DAO and prepares for an even more scalable future.
|
||||
|
||||
NEW
|
||||
|
||||
- Cosmos based chain on L2
|
||||
- Validator Nodes for TFGrid and TFChain.
|
||||
- Cosmos based HUB = security for all TFChains
|
||||
|
||||
> More info about our DAO strategy see TFDAO.
|
||||
|
||||
|
||||
|
||||
!!!def alias:tfchain_roadmap,dao_roadmap,tfdao_roadmap
|
||||
|
||||
@@ -1,73 +0,0 @@
|
||||
|
||||
# TFGrid 3.0 Wallets
|
||||
|
||||
ThreeFold has a mobile wallet which will allow to be used on the TFChain backend (Substrate) as well as any other Money Blockchain it supports.
|
||||
|
||||
This provides for a very secure digital currency infrastructure with lots of advantages.
|
||||
|
||||
- [X] ultra flexible smart contracts possible
|
||||
- [X] super safe
|
||||
- [X] compatible with multiple blockchains (money blockchains)
|
||||
- [X] ultra scalable
|
||||
|
||||
```mermaid
|
||||
|
||||
|
||||
graph TB
|
||||
|
||||
subgraph Money Blockchain
|
||||
money_blockchain[Money Blockchain Explorers]
|
||||
money_blockchain --- money_blockchain_node_1 & money_blockchain_node_2
|
||||
money_blockchain_node_1
|
||||
money_blockchain_node_2
|
||||
end
|
||||
|
||||
subgraph ThreeFold Wallets
|
||||
mobile_wallet[Mobile Wallet]
|
||||
desktop_wallet[Desktop Wallet]
|
||||
mobile_wallet & desktop_wallet --> money_blockchain
|
||||
mobile_wallet & desktop_wallet --> Explorers
|
||||
money_blockchain_wallet[Any Money Blockchain Wallet] --> money_blockchain
|
||||
end
|
||||
|
||||
|
||||
subgraph TFChain[TFGrid Blockchain on Substrate]
|
||||
Explorers[TFChain Explorers]-->TFGridDB --> BCNode
|
||||
Explorers --> BCNode
|
||||
end
|
||||
|
||||
|
||||
```
|
||||
|
||||
Generic overview:
|
||||
|
||||
```mermaid
|
||||
|
||||
graph TB
|
||||
|
||||
subgraph TFChain[TFGrid Chain]
|
||||
guardian1[TFChain Node 1]
|
||||
guardian2[TFChain Node 2]
|
||||
guardian3[TFChain Node 3...9]
|
||||
end
|
||||
|
||||
User_wallet[User Wallet] --> money_blockchain_account
|
||||
User_wallet[User Wallet] --> money_blockchain_restricted_account
|
||||
|
||||
subgraph Money Blockchain Ecosystem
|
||||
money_blockchain_account
|
||||
money_blockchain_restricted_account --- guardian1 & guardian2 & guardian3
|
||||
end
|
||||
|
||||
subgraph consensus[Consensus Layer on Substrate]
|
||||
guardian1 --> ReputationEngine & PricingOracle
|
||||
guardian1 --> contract1[Smart Contract Vesting]
|
||||
guardian1 --> contract2[Smart Contract Minting/Farming]
|
||||
end
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
!!!include:consensus3_toc
|
||||
@@ -1,52 +0,0 @@
|
||||
|
||||
// - vesting
|
||||
// - startdate: epoch
|
||||
// - currency: USD
|
||||
// - [[$month_nr,$minprice_unlock,$TFT_to_vest],...]
|
||||
// - if 48 months then list will have 48 parts
|
||||
// - month 0 = first month
|
||||
// - e.g. [[0,0.11,10000],[1,0.12,10000],[2,0.13,10000],[3,0.14,10000]...]
|
||||
|
||||
//information stored at account level in TFGridDB
|
||||
struct AccountMeta{
|
||||
//corresponds to unique address on money_blockchain
|
||||
money_blockchain_address string
|
||||
vesting Vesting[]
|
||||
unlocked_TFT int
|
||||
}
|
||||
|
||||
struct Vesting{
|
||||
startdate int
|
||||
//which currency is used to execute on the acceleration in the vesting
|
||||
//if price above certain level (which is currency + amount of that currency) the auto unlock
|
||||
currency CurrencyEnum
|
||||
months []VestingMonth
|
||||
}
|
||||
|
||||
struct VestingMonth{
|
||||
month_nr int
|
||||
//if 0 then will not unlock based on price
|
||||
unlock_price f32
|
||||
tft_amount int
|
||||
}
|
||||
|
||||
enum CurrencyEnum{
|
||||
usd
|
||||
eur
|
||||
egp
|
||||
gbp
|
||||
aed
|
||||
}
|
||||
|
||||
//this is stored in the TFGridDB
|
||||
fn (mut v AccountMeta) serialize() string{
|
||||
//todo code which does serialization see above
|
||||
return ""
|
||||
}
|
||||
|
||||
|
||||
//write minting pool
|
||||
|
||||
|
||||
//REMARKS
|
||||
// if unlock triggered because of month or price then that record in the VestingMonth[] goes away and TFT go to unlocked_TFT
|
||||
@@ -1,33 +0,0 @@
|
||||
<h1> How It Works </h1>
|
||||
|
||||
Welcome to the ThreeFold ecosystem, your gateway to a global and sustainable network!
|
||||
|
||||
## TFGrid in a Nutshell
|
||||
|
||||
The ThreeFold Grid is a remarkable network sustained by dedicated individuals, known as **ThreeFold farmers**, who offer network, storage and compute (CPU, GPU) resources to users via 3Nodes, specialized computers that run the innovative Zero-OS software.
|
||||
|
||||
> [Become a ThreeFold farmer](../../documentation/farmers/farmers.md)
|
||||
|
||||
## If it runs on Linux, it runs on the Grid!
|
||||
|
||||
The ThreeFold Grid supports any application that can run on Linux, guaranteeing compatibility and flexibility. Moreover, it offers additional benefits, including enhanced privacy, security, proximity to end-users, and a significantly lower cost compared to traditional alternatives.
|
||||
|
||||
> [Deploy on the TFGrid](../../documentation/system_administrators/getstarted/tfgrid3_getstarted.md)
|
||||
|
||||
## Internet as a Resource
|
||||
|
||||
In a similar manner to purchasing electricity or other utilities, the internet capacity provided by the ThreeFold Grid is produced and allocated locally. This decentralized approach empowers digital service and application providers to host their offerings closer to end-users, resulting in exceptional performance, competitive pricing, and improved profit margins. The TFGrid is fueled by the ThreeFold Token.
|
||||
|
||||
> [Learn more about TFT](../about/token_overview/token_overview.md)
|
||||
|
||||
## TFChain: The Backbone Blockchain Infrastructure
|
||||
|
||||
__TFChain__, also known as __ThreeFold Chain__, is the powerful blockchain that orchestrates the interactions within the ThreeFold Grid ecosystem. TFChain is like the control center of the ThreeFold Grid, providing users and farmers with a wide range of key functionalities.
|
||||
|
||||
> [Learn more about TFChain](../technology/concepts/tfchain.md)
|
||||
|
||||
## ThreeFold Dashboard
|
||||
|
||||
The [**ThreeFold Dashboard**](https://dashboard.grid.tf/) serves as an indispensable tool for farmers and users of the ThreeFold Grid, facilitating node registration, resource management, workload deployments and much more.
|
||||
|
||||
> [Learn more about the ThreeFold Dashboard](../../documentation/dashboard/dashboard.md)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 290 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 241 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 128 KiB |
@@ -1,12 +0,0 @@
|
||||
## Autonomous Layer
|
||||
|
||||
### Digital Twin
|
||||
|
||||
>TODO:
|
||||
|
||||
### 3Bot
|
||||
|
||||
3Bot is a virtual system administrator that manages the user's IT workloads under a private key. This ensures an immutable record of any workload as well as a self-healing functionality to restore these workloads if/when needed. Also, all 3Bot IDs are registered on a modern type of phone book that uses blockchain technology. This phone book, also referred to as the Threefold Grid Blockchain, allows all 3Bots to find each other, connect and exchange information or resources in a fully end-to-end encrypted way. Here as well, there are "zero people involved, as 3Bots operate autonomously in the network, and only under the user's commands.
|
||||
|
||||
3Bot is equipped with a cryptographic 2-factor authentication mechanism. You can log in to your 3Bot via the ThreeFold Connect app on your device which contains your private key. The 3Bot is a very powerful tool that allows you to automate & manage thousands of virtual workloads on the ThreeFold_Grid.
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
## Capacity Layer
|
||||
|
||||
### Zero-OS
|
||||
|
||||
ThreeFold has build its own operating system called, Zero-OS which was based starting from a Linux Kernel with as purpose to remove all the unnecessary complexity found on contemporary OS's.
|
||||
|
||||
Zero-OS supports a small number of primitives, and performs low-level functions natively.
|
||||
|
||||
It delivers 3 primitive functions:
|
||||
- storage capacity
|
||||
- compute capacity
|
||||
- network capacity
|
||||
|
||||
There is no shell, local nor remote attached to Zero-OS. It does not allow for inbound network connections to happen to the core. Also, given its shell-less nature, the people and organizations, called farmers, that run 3nodes cannot issue any commands nor access its features. In that sense, Zero-OS enables a "zero people" (autonomous) Internet, meaning hackers cannot get in, while also eliminating human error from the paradigm.
|
||||
|
||||
### 3Node
|
||||
|
||||
The ThreeFold_Grid needs hardware/servers to function. Servers of all shapes and sizes can be added to the grid by anyone, anywhere in the world. The production of Internet Capacity on the Threefold Grid is called Farming and people who add these servers to the grid are called Farmers. This is a fully decentralized process and they get rewarded by the means of TFT.
|
||||
|
||||
Farmers download the Zero-OS operating system and boot their servers themselves. Once booted, these servers become 3Nodes. The 3Nodes will register themselves in a database called the TF_Explorer. Once registered in the TF_Explorer, the capacity of the 3Nodes will become available on the TF Grid Explorer. Also, given the autonomous nature of the ThreeFold_Grid, there is no need for any intermediaries between the user and 3Nodes.
|
||||
|
||||
This enables a complete peer-to-peer environment for people to reserve their Internet Capacity directly from the hardware.
|
||||
|
||||
### Smart Contract for IT
|
||||
|
||||
The purpose of the smart contract for IT is to create and enable autonomous IT. Autonomous self-driving IT is possible when we adhere to two principles from start:
|
||||
|
||||
1. Information technology architectures are configured and installed by bots (a ‘smart contract agent’), not people.
|
||||
2. Human beings cannot have access to these architectures and change things.
|
||||
|
||||
While sticking to these principles, it provides the basis to consider and describe everything in a contract type format and to deploy any self-driving and self-healing application on the ThreeFold_Grid.
|
||||
|
||||
Once the smart contract for IT is created, it will be registered in the Blockchain Database in a complete end-to-end process. It will also leave instructions for the 3Nodes in a digital notary system for them to grab the necessary instructions and complete the smart contract.
|
||||
|
||||
Learn more about smart contract for IT [here](smartcontract_it).
|
||||
|
||||
### TFChain
|
||||
|
||||
A blockchain running on the TFGrid stores following information (TFGrid 3.0)
|
||||
|
||||
- registry for all digital twins (identity system, aka phonebook)
|
||||
- registry for all farmers & 3nodes
|
||||
- registry for our reputation system
|
||||
- info as required for the Smart Contract for IT
|
||||
|
||||
This is the hart of our operational system of the TFGrid
|
||||
|
||||
### Peer-to-Peer Network
|
||||
|
||||
The peer-to-peer network allows any zmachine or user to connect with other zmachine or users on the TF Grid securely and creates a private shortest path peer-to-peer network.
|
||||
|
||||
### Web Gateway
|
||||
|
||||
The Web Gateway is a mechanism to connect the private (overlay) networks to the open Internet. By not providing an open and direct path in to the private network, a lot of malicious phishing and hacking attempts are stopped at the Web Gateway level for container applications.
|
||||
@@ -1 +0,0 @@
|
||||
## Experience Layer
|
||||
@@ -1,7 +0,0 @@
|
||||
|
||||
!!!include:capacity_layer_intro
|
||||
|
||||
!!!include:autonomous_layer_intro
|
||||
|
||||
!!!include:experience_layer_intro
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
## Beyond Containers
|
||||
|
||||
|
||||
|
||||
|
||||
Default features:
|
||||
|
||||
- compatible with Docker
|
||||
- compatible with any Linux workload
|
||||
|
||||
We have 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: zos_net.
|
||||
- the containers can use web_gw to allow users on the internet connect to the applications as running in their secure containers.
|
||||
- can use core-x to manage the workload.
|
||||
@@ -1,7 +0,0 @@
|
||||
# Compute
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [ZKube](./zkube.md)
|
||||
- [ZMachine](./zmachine.md)
|
||||
- [CoreX](./corex.md)
|
||||
@@ -1,21 +0,0 @@
|
||||
|
||||
<h1> CoreX </h1>
|
||||
|
||||
<h2>Table of Contents </h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [ZMachine Process Manager](#zmachine-process-manager)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
CoreX allows you to manage your ZMachine over web remotely.
|
||||
|
||||
## ZMachine Process Manager
|
||||
|
||||
- Provide a web interface and a REST API to control your processes.
|
||||
- Allow to watch the logs of your processes.
|
||||
- Or use it as a web terminal (access over https to your terminal)!
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 177 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 349 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 272 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 304 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 333 KiB |
@@ -1,25 +0,0 @@
|
||||
|
||||
## TFGrid Compute Layer
|
||||
|
||||
|
||||
|
||||
We are more than just Container or VM technology, see [our Beyond Container Document](beyond_containers).
|
||||
|
||||
A 3Node is a Zero-OS enabled computer which is hosted with any of the TF_Farmers.
|
||||
|
||||
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.
|
||||
- QSFS, 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.
|
||||
|
||||
- Planetary_network : is a planetary scalable network, we have clients for windows, osx, android and iphone.
|
||||
- zos_net : is a fast end2end encrypted network technology, keep your traffic between your z_machines 100% private.
|
||||
- zos_bridge: connection to a public ipaddress
|
||||
- web_gw: web gateway, a secure way to allow internet traffic reach your secure Z-Machine.
|
||||
|
||||
|
||||
|
||||
@@ -1,40 +0,0 @@
|
||||
<h1> ZKube </h1>
|
||||
|
||||
<h2>Table of Contents </h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Unique for our Kubernetes implementation](#unique-for-our-kubernetes-implementation)
|
||||
- [Features](#features)
|
||||
- [ZMachine Benefits](#zmachine-benefits)
|
||||
- [Architecture](#architecture)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
TFGrid is compatible with Kubernetes Technology.
|
||||
|
||||
Each eVDC as shown above is a full blown Kubernetes deployment.
|
||||
|
||||
## Unique for our Kubernetes implementation
|
||||
|
||||
- The Kubernetes networks are on top of our [ZNet](../network/znet.md) technology which means all traffic between containers and kubernetes hosts is end2end encrypted independent of where your Kubernetes nodes are deployed.
|
||||
- You can mount a QSFS underneath a Kubernetes Node (VM), which means that you can deploy containers on top of QSFS to host unlimited amounts of storage in a super safe way.
|
||||
- You Kubernetes environment is for sure 100% decentralized, you define where you want to deploy your Kubernetes nodes and only you have access to the deployed workloads on the TFGrid.
|
||||
|
||||
## Features
|
||||
|
||||
* integration with znet (efficient, secure encrypted network between the zmachines)
|
||||
* can be easily deployed at the edge
|
||||
* single-tenant!
|
||||
|
||||
## ZMachine Benefits
|
||||
|
||||
* [ZOS Protect](../../zos/benefits/zos_advantages.md#zero-os-protect): no hacking surface to the Zero-Nodes, integrate silicon route of trust
|
||||
|
||||
|
||||
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
@@ -1,30 +0,0 @@
|
||||
<h1> ZMachine </h1>
|
||||
|
||||
<h2>Table of Contents </h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Features](#features)
|
||||
- [Architecture](#architecture)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
ZMachine is a unified container/virtual machine type. This can be used to start a virtual machine on a zos node.
|
||||
|
||||
## Features
|
||||
|
||||
* import from docker (market std for containers)
|
||||
* can be easily deployed at the edge (edge cloud)
|
||||
* single-tenant, fully decentralized!
|
||||
* can deploy unlimited amounts of storage using our qsfs.
|
||||
* [ZOS Protect](../../zos/benefits/zos_advantages.md#zero-os-protect): no hacking surface to the Zero-Nodes, integrate silicon route of trust
|
||||
* [ZOS Filesystem](../storage/qsfs.md): dedupe, zero-install, hacker-proof
|
||||
* [WebGateway](../network/webgw3.md:) intelligent connection between web (internet) and container services
|
||||
* integration with [ZNet](../network/znet.md) (efficient, secure encrypted network between the zmachines)
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
|
||||
A ZMachine is running as a virtual machine on top of Zero-OS.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 202 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 267 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 188 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 122 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 175 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 163 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 156 KiB |
@@ -1,7 +0,0 @@
|
||||
# Network
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [ZNET](./znet.md)
|
||||
- [ZNIC](./znic.md)
|
||||
- [WebGateway](./webgw3.md)
|
||||
@@ -1,5 +0,0 @@
|
||||
# Peer2Peer Agent
|
||||
|
||||
>TODO
|
||||
|
||||
!!!include:zos_toc
|
||||
@@ -1,54 +0,0 @@
|
||||
|
||||
|
||||
# Planetary Network
|
||||
|
||||
|
||||
|
||||
|
||||
The planetary network is an overlay network which lives on top of the existing internet or other peer2peer networks created. In this network, everyone is connected to everyone. End-to-end encryption between users of an app and the app running behind the network wall.
|
||||
|
||||
Each user end network point is strongly authenticated and uniquely identified, independent of the network carrier used. There is no need for a centralized firewall or VPN solutions, as there is a circle based networking security in place.
|
||||
|
||||
Benefits :
|
||||
- It finds shortest possible paths between peers
|
||||
- There's full security through end-to-end encrypted messaging
|
||||
- It allows for peer2peer links like meshed wireless
|
||||
- It can survive broken internet links and re-route when needed
|
||||
- It resolves the shortage of IPV4 addresses
|
||||
|
||||
|
||||
Whereas current computer networks depend heavily on very centralized design and configuration, this networking concept breaks this mould by making use of a global spanning tree to form a scalable IPv6 encrypted mesh network. This is a peer2peer implementation of a networking protocol.
|
||||
|
||||
The following table illustrates high-level differences between traditional networks like the internet, and the planetary threefold network:
|
||||
|
||||
| Characteristic | Traditional | Planetary Network |
|
||||
| --------------------------------------------------------------- | ----------- | ----------------- |
|
||||
| End-to-end encryption for all traffic across the network | No | Yes |
|
||||
| Decentralized routing information shared using a DHT | No | Yes |
|
||||
| Cryptographically-bound IPv6 addresses | No | Yes |
|
||||
| Node is aware of its relative location to other nodes | No | Yes |
|
||||
| IPv6 address remains with the device even if moved | No | Yes |
|
||||
| Topology extends gracefully across different mediums, i.e. mesh | No | Yes |
|
||||
|
||||
## What are the problems solved here?
|
||||
|
||||
The internet as we know it today doesn’t conform to a well-defined topology. This has largely happened over time - as the internet has grown, more and more networks have been “bolted together”. The lack of defined topology gives us some unavoidable problems:
|
||||
|
||||
- The routing tables that hold a “map” of the internet are huge and inefficient
|
||||
- There isn’t really any way for a computer to know where it is located on the internet relative to anything else
|
||||
- It’s difficult to examine where a packet will go on its journey from source to destination without actually sending it
|
||||
- It’s very difficult to install reliable networks into locations that change often or are non-static, i.e. wireless mesh networks
|
||||
|
||||
These problems have been partially mitigated (but not really solved) through centralization - rather than your computers at home holding a copy of the global routing table, your ISP does it for you. Your computers and network devices are configured just to “send it upstream” and to let your ISP decide where it goes from there, but this does leave you entirely at the mercy of your ISP who can redirect your traffic anywhere they like and to inspect, manipulate or intercept it.
|
||||
|
||||
In addition, wireless meshing requires you to know a lot about the network around you, which would not typically be the case when you have outsourced this knowledge to your ISP. Many existing wireless mesh routing schemes are not scalable or efficient, and do not bridge well with existing networks.
|
||||
|
||||
|
||||
|
||||
The planetary network is a continuation & implementation of the [Yggdrasil](https://yggdrasil-network.github.io/about.html) network initiative. This technology is in beta but has been proven to work already quite well.
|
||||
|
||||
!!!def alias:planet_net,planetary_net,planetary_network,pan
|
||||
|
||||
!!!include:zos_toc
|
||||
|
||||
> Click [here](manual:planetary_network_connector) to read more about Planetary Network Connector Installation. Click [here](manual:yggdrasil_client) to read more about Planetary Network Installation (advanced).
|
||||
@@ -1,7 +0,0 @@
|
||||
# TFGrid networking
|
||||
|
||||
- znet : private network between zmachines
|
||||
- [Planetary Network](planetary_network) : peer2peer end2end encrypted global network
|
||||
- znic : interface to planetary network
|
||||
- [WebGateway](webgw) : interface between internet and znet
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
|
||||
|
||||
# WebGW 2.0
|
||||
|
||||
The Web Gateway is a mechanism to connect the private networks to the open Internet, in such a way that there is no direct connection between internet and the secure workloads running in the ZMachines.
|
||||
|
||||
|
||||
|
||||
|
||||
- Separation between where compute workloads are and where services are exposed.
|
||||
- Better Security
|
||||
- Redundant
|
||||
- Each app can be exposed on multiple webgateways at once.
|
||||
- Support for many interfaces...
|
||||
- Helps resolve shortage of IPv4 addresses
|
||||
|
||||
If (parts of) this private overlay network need to be reachable from the Internet, the zmachines initiate a secure connection *to* the web Gateway.
|
||||
|
||||
### Implementation
|
||||
|
||||
It is important to mention that this connection is not a standard network connection, it is a [network socket](https://en.wikipedia.org/wiki/Network_socket) initiated by the container or VM to the web gateway. The container calls out to one or more web gateways and sets up a secure & private socket connection to the web gateway. The type of connection required is defined on the smart contract for IT layer and as such is very secure. There is no IP (TCP/UDP) coming from the internet towards the containers providing more security.
|
||||
|
||||
Up to the Web Gateway Internet traffic follows the same route as for any other network end point: A DNS entry tells the consumers client to what IP address to send traffic to. This endpoint is the public interface of the Web Gateway. That interface accepts the HTTP(s) (or any other TCP) packets and forward the packet payload over the secure socket connection (initiated by the container) to the container.
|
||||
|
||||
No open pipe (NAT plus port forwarding) from the public internet to specific containers in the private (overlay) network exists.
|
||||
|
||||
Web Gateways are created by so called network farmers. Network farmers are people and companies that have access to good connectivity and have a large number of public IP routable IP networks. They provide the facilities (hardware) for Web Gateways to run and terminate a lot of the public inbound and output traffic for the TF Grid. Examples of network farmers are ISP's and (regional, national and international Telcos, internet exchanges etc.
|
||||
|
||||
### Security
|
||||
|
||||
Buy not providing an open and direct path in to the private network a lot of malicious phishing and hacking attempts are stopped at the Web Gateway. By design any private network is meant to have multiple webgateways and by design these Web Gateways exist on different infrastructure in a different location. Sniffing around and finding out what can be done with a Web Gateway might (and will happen) but it will not compromise the containers in your private network.
|
||||
|
||||
### 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 the 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 enterprise and this demand side is exponentially growing for data processing and storage use cases.
|
||||
|
||||
### Network Wall (future)
|
||||
|
||||
see [Network Wall](network_wall)
|
||||
|
||||
## Roadmap
|
||||
|
||||
Above described Web Gateway is for 2.0.
|
||||
|
||||
For 3.0 we start with a HTTP(S) proxy over Planetary network connection. Not all features from WebGW 2.0 have been ported.
|
||||
|
||||
Further future, we envisage support for many other protocols: sql, redis, udp, ...
|
||||
|
||||
!!!def alias:web_gw,zos_web_gateway
|
||||
|
||||
!!!include:zos_toc
|
||||
|
||||
@@ -1,50 +0,0 @@
|
||||
<h1> WebGW 2.0 </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Implementation](#implementation)
|
||||
- [Security](#security)
|
||||
- [Redundant Network Connection](#redundant-network-connection)
|
||||
- [Unlimited Scale](#unlimited-scale)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
The Web Gateway is a mechanism to connect the private networks to the open Internet, in such a way that there is no direct connection between internet and the secure workloads running in the ZMachines.
|
||||
|
||||
|
||||
|
||||
|
||||
- Separation between where compute workloads are and where services are exposed.
|
||||
- Redundant
|
||||
- Each app can be exposed on multiple webgateways at once.
|
||||
- Support for many interfaces...
|
||||
- Helps resolve shortage of IPv4 addresses
|
||||
|
||||
## Implementation
|
||||
|
||||
Some 3nodes supports gateway functionality (configured by the farmers). A 3node with gateway config can then accept gateway workloads and then forward traffic to ZMachines that only has yggdrasil (planetary network) or Ipv6 addresses.
|
||||
|
||||
The gateway workloads consists of a name (prefix) that need to be reserved on the block chain first. Then the list of backend IPs. There are other flags that can be set to control automatic TLS (please check terraform documentations for the exact details of a reservation)
|
||||
|
||||
Once the 3node receives this workloads, the network configure proxy for this name and the yggdrasil ips.
|
||||
|
||||
## Security
|
||||
|
||||
ZMachines has to have an yggdrasil IP or any other IPv6 (also IPv4 are accepted) but it means that any person who is connected to the yggdrasil network, can also reach the ZMachine without the need for a proxy.
|
||||
|
||||
So ti's up to the ZMachine owner/maintainer to make sure it is secured and only have the required ports 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 the 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 enterprise and this demand side is exponentially growing for data processing and storage use cases.
|
||||
@@ -1,39 +0,0 @@
|
||||
<h1> ZNET </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Secure mesh overlay network (peer2peer)](#secure-mesh-overlay-network-peer2peer)
|
||||
- [Redundancy](#redundancy)
|
||||
- [Interfaces in Zero-OS](#interfaces-in-zero-os)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
Decentralized networking platform allowing any compute and storage workload to be connected together on a private (overlay) network and exposed to the existing internet network. The Peer2Peer network platform allows any workload to be connected over secure encrypted networks which will look for the shortest path between the nodes.
|
||||
|
||||
|
||||
|
||||
## Secure mesh overlay network (peer2peer)
|
||||
|
||||
Z_NET is the foundation of any architecture running on the TF Grid. It can be seen as a virtual private datacenter and the network allows all of the *N* containers to connected to all of the *(N-1)* other containers. Any network connection is a secure network connection between your containers and creates peer 2 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 allows for public access if and when required.
|
||||
|
||||
## Redundancy
|
||||
|
||||
As integrated with [WebGW](./webgw3.md):
|
||||
|
||||
|
||||
|
||||
- Any app can get (securely) connected to the internet by any chosen IP address made available by ThreeFold network farmers through WebGW.
|
||||
- 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.
|
||||
|
||||
## Interfaces in Zero-OS
|
||||
|
||||
|
||||
@@ -1,24 +0,0 @@
|
||||
<h1> ZNIC </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Use Cases](#use-cases)
|
||||
- [Overview](#overview)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
ZNIC is the network interface which is connected to Z_Machine.
|
||||
|
||||
## Use Cases
|
||||
|
||||
Can be implemented as interface to
|
||||
|
||||
- planetary_network.
|
||||
- public ip address on a Zero-OS.
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
@@ -1,19 +0,0 @@
|
||||
# Primitives
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Compute](./compute/compute_toc.md)
|
||||
- [ZKube](./compute/zkube.md)
|
||||
- [ZMachine](./compute/zmachine.md)
|
||||
- [CoreX](./compute/corex.md)
|
||||
- [Storage](./storage/storage_toc.md)
|
||||
- [ZOS Filesystem](./storage/zos_fs.md)
|
||||
- [ZOS Mount](./storage/zmount.md)
|
||||
- [Quantum Safe File System](./storage/qsfs.md)
|
||||
- [Zero-DB](./storage/zdb.md)
|
||||
- [Zero-Disk](./storage/zdisk.md)
|
||||
- [Network](./network/network_toc.md)
|
||||
- [ZNET](./network/znet.md)
|
||||
- [ZNIC](./network/znic.md)
|
||||
- [WebGateway](./network/webgw3.md)
|
||||
- [Zero-OS Advantages](../zos/benefits/zos_advantages.md)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 118 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 99 KiB |
@@ -1,34 +0,0 @@
|
||||
<h1> Quantum Safe Filesystem </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Benefits](#benefits)
|
||||
- [Use Cases](#use-cases)
|
||||
- [Implementation](#implementation)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
Quantum safe filesystem presents itself as a filesystem to the ZMachine.
|
||||
|
||||
### Benefits
|
||||
|
||||
- Safe
|
||||
- Hacker Proof
|
||||
- Ultra Reliable
|
||||
- Low Overhead
|
||||
- Ultra Scalable
|
||||
- Self Healing = recovers service automatically in the event of outage with no human
|
||||
|
||||
|
||||
|
||||
### Use Cases
|
||||
|
||||
- Backup and archive system
|
||||
- Blockchain Storage Backend (OEM ONLY)
|
||||
|
||||
### Implementation
|
||||
|
||||
> QSFS is using QSSS inside.
|
||||
@@ -1,9 +0,0 @@
|
||||
# Storage
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [ZOS Filesystem](./zos_fs.md)
|
||||
- [ZOS Mount](./zmount.md)
|
||||
- [Quantum Safe File System](./qsfs.md)
|
||||
- [Zero-DB](./zdb.md)
|
||||
- [Zero-Disk](./zdisk.md)
|
||||
@@ -1,21 +0,0 @@
|
||||
<h1> ZOS-DB (ZDB) </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Use Cases](#use-cases)
|
||||
- [Overview](#overview)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
0-db is a fast and efficient key-value store redis-protocol compatible, which makes data persistent inside an always append datafile, with namespaces support.
|
||||
|
||||
## Use Cases
|
||||
|
||||
> ZDB is being used as backend storage for [Quantum Safe Filesystem](./qsfs.md).
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
<h1> ZOS Disk </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Roadmap](#roadmap)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
Virtual disk creates the possibility to create and use virtual disks which can be attached to containers (and virtual machines).
|
||||
|
||||
The technology is designed to be redundant without having to do anything.
|
||||
|
||||
## Roadmap
|
||||
|
||||
- The virtual disk technology is available for OEM's only, contact TF_Tech.
|
||||
@@ -1,18 +0,0 @@
|
||||
<h1> ZOS Mount </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Overview](#overview)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
ZOS mount is an SSD storage location on which can be written upon inside a VMachine and VKube.
|
||||
|
||||
## Overview
|
||||
|
||||
The SSD storage location is mounted on a chosen path inside your Z-Machine.
|
||||
|
||||
|
||||
@@ -1,39 +0,0 @@
|
||||
|
||||
<h1> ZOS FileSystem (ZOS-FS) </h1>
|
||||
|
||||
<h2>Table of Contents</h2>
|
||||
|
||||
- [Introduction](#introduction)
|
||||
- [Uses Flist Inside](#uses-flist-inside)
|
||||
- [Why this ZFlist Concept](#why-this-zflist-concept)
|
||||
- [Benefits](#benefits)
|
||||
|
||||
***
|
||||
|
||||
## Introduction
|
||||
|
||||
A deduped filesystem which is more efficient compared to images as used in other Virtual Machine technology.
|
||||
|
||||
## Uses Flist Inside
|
||||
|
||||
In Zero-OS, `flist` is the format used to store zmachine images. This format is made to provide
|
||||
a complete mountable remote filesystem but downloading only the files contents that you actually needs.
|
||||
|
||||
In practice, Flist itself is a small database which contains metadata about files and directories and file payload are stored on a tfgrid hub. You only need to download payload when you need it, this dramatically reduce zmachine boot time, bandwidth and disk overhead.
|
||||
|
||||
### Why this ZFlist Concept
|
||||
|
||||
Have you ever been in the following situation: you need two small files but they are embedded in a large archive. How to get to those 2 files in an efficient way? What a disappointment when you see this archive is 4 GB large and you only need 4 files of 2 MB inside. You'll need to download the full archive, store it somewhere to extract only what you need. Time, effort and bandwidth wasted.
|
||||
|
||||
You want to start a Docker container and the base image you want to use is 2 GB. What do you need to do before being able to use your container ? Waiting to get the 2 GB downloaded. This problem exists everywhere but in Europe and the US the bandwidth speeds are such that this does not present a real problem anymore, hence none of the leading (current) tech companies are looking for solutions for this.
|
||||
|
||||
We believe that there should a smarter way of dealing with this then simply throwing larger bandwidth at the problem: What if you could only download the files you actually want and not the full blob (archive, image, whatever...).
|
||||
|
||||
ZFList is splitting metadata and data. Metadata is referential information about everything you need to know about content of the archive, but without the payload. Payload is the content of the referred files. The ZFList is exactly that: it consists of metadata with references that point to where to get the payload itself. So if you don't need it you won't get it.
|
||||
|
||||
As soon as you have the flist mounted, you can see the full directory tree, and walk around it. The files are only downloaded and presented at moment that you try to access them. In other words, every time you want to read a file, or modify it, Zero FS will download it, so that the data is available too. You only download on-the-fly what you need which reduces dramatically the bandwidth requirement.
|
||||
|
||||
|
||||
## Benefits
|
||||
|
||||
- Efficient usage of bandwidth makes this service perform with and without (much) bandwidth
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 315 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user