crustio / crust-sworker Goto Github PK

Add single process mode, at the same time use sgx seal and unseal to store and read previous data.

Use this mechanism to avoid 'restart attack'. This mechanism shows that after you restart tee, there will be an era that cannot report workload

logic:
1. Hard disk space reserves at least 50G
2. Under the condition of 1, the SRD capacity is dynamically reached the specified target

To ensure that users do not cheat, the current restart implementation mode is re-plot empty disk. This will have a huge impact on performance and program startup time.
Now consider a scheme that allows the empty disk information to be continuously and reliably stored in a certain location.

Some connections to TEE cannot be close expectedly.

User can feed back research result by reporting signed proof.

Currently, If TEE restart at 340 block, it won't report 300-slot work report anymore(because it only recognize the 300n block).
However, if we need do the TEE forkless-upgrade, it should report works anyway to avoid fake offline.

Log like:
[Mar 26 2020 16:11:25] [INFO] -----Meaningful Validation-----
[Mar 26 2020 16:11:25] [INFO] -----Empty Validation-----
[Mar 26 2020 16:11:25] [INFO] -----Validation Waiting-----
[Mar 26 2020 16:11:25] [INFO] Empty root hash: 7b231d786cbd17124fc0619bd51cf75b4b1ef10ab708b052b55154a97c8f35ee
[Mar 26 2020 16:11:25] [INFO] Empty capacity: 4G
[Mar 26 2020 16:11:25] [INFO] Meaningful work is:
[Mar 26 2020 16:11:25] [INFO] Store enclave data successfully!
[Mar 26 2020 16:11:25] [ERROR] Send to IAS failed! Trying again...(1)
[Mar 26 2020 16:11:27] [INFO] Block height:84622 is not enough!
[Mar 26 2020 16:11:30] [INFO] Sending quote to IAS service successfully!
[Mar 26 2020 16:11:30] [INFO] Verify IAS report in enclave successfully!

Currently work report include all the file root hash. If one node stores 10000 files. Them the work report will be very big

Problem

When get 300n block hash, it will get forked block hash H1, but the final reorged hash is H3. This will failed timing check on-chain.

Proposal

We get 300n block after 300n+10(reorged block).

Waiting for crust chain finish genesis validator

• Environment setup and operation logic
  • Dependent installation script (sgx, cpprest, sgx-ssl, ipfs etc.)
  • Realize '.app init' command (create base config, start ipfs)
• Signature report and network access information
• Deal http error
• Readme, help documentation and command
• Use log file
• Call the post interface to send information to chain
  • Network access information
  • Root of empty disk and meaningful files
• Multi-node logic test

The problem occurs in the logical position of the p disk, which may be due to a null pointer or a memory leak.

'Development launch' needs to cooperate with the crust chain to start all processes, this is not convenient for testing, we need offline mode.

Preliminary solution ideas: Only one report is produced per workload cycle

Unknown error during sgx dependencies installation, reinstalling can solve the problem.

Error: /opt/sgxsdk/bin/x64/sgx_sign: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory. (ps: Preliminary research finds correlation with environmental variables for different user types)

Now TEE report workloads all in same pace, this will cause N validators num reports in 1 block, add randomness in N ~ N*100 to reduce this performance issue

When TEE executing srd to plot disk, multithreading mechanism leads to srd failed!