Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update CESS.md #755

Merged
merged 1 commit into from
Dec 28, 2021
Merged

Update CESS.md #755

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions applications/CESS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ Documentation of core components, protocols, architecture, etc. to be deployed
* Data storage workflow: When a client requests to store a data file, the CESS platform pre-processes the data file to obtain and store its meta-data and data fingerprints. The pre-process software also performs data file replication and fault tolerant erasure coding. The meta-data includes info of data owner, data keywords, and etc. The data fingerprints are for subsequent data rights confirmation.
<div align=center><img width="72%" height="72%" src="https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img5.png"/></div>

* CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via on-chain smart contract. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Miners’ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clients’ data. Any malicious behavior will be punished (CESS token deduction).
* CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via extrinsics on blockchain. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Miners’ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clients’ data. Any malicious behavior will be punished (CESS token deduction).
<div align=center><img width="65%" height="65%" src="https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img6.png"/></div>

* Overall system architecture: CESS adopts a layered and loosely coupled system architecture, which is divided into blockchain service layer, distributed storage resource layer, distributed content delivery layer and application layer.
Expand Down Expand Up @@ -147,8 +147,8 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera
| 0d. | Article/Tutorial | We will publish an article and a tutorial that explains the work done as part of the grant. |
| 1a. | Stacked DRG Library | We will create a library for proving and verifying transactions, compatible with the substrate pallet. |
| 1b. | zk-SNARK proofs | We will implement the algorithm to process the proof results from stacked DRG library. |
| 2. | CESS Contracts | Develop CESS contract implement function of storage mining. |
| 3. | Miner Client | Interactive with contract to implement mining supporting services. |
| 2. | Substrate module: Segment Book | Develop pallet implement function of storage mining. |
| 3. | Miner Client | Interactive with pallet for storage mining to implement mining supporting services. |


### Milestone 3: Implement and Integrate CESS Applications
Expand Down