Can a farmer manipulate the farming rules?
possibility 1: reverse engineer zero-os
How would this work:
- change the code of zero-os
- build your own version of zero-os
- build your own bootloader
- then use this to boot your custom version of zero-os
- you could change the reporting of capacity to the blockchain to try and get more farming rewards by faking the size of your box
Below is only valid starting TFGrid 3.0.X, X to be defined. Planned oct 2021.
Threefold has implemented following solutions:
part 1: make sure we can authenticate / verify info from each 3node
- Zero-OS is using TPM which is an encryption module available on most motherboards these days, from 3.0 onwards new Zero-OS nodes will have to support TPM to have a secure private key available.
- TPM is used by Zero-OS to sign the proof of capacity reports as well as its own registration.
- Because of TPM signing TFChain can verify identity of this node and authenticity of the information sent.
- A malicious user can reset the bios (if HW not locked) but this would result in loosing the private key on the TPM module which means following requests (registration,information) would not be linked back to this hardware, the user could only re-register the node with rules and farming reward at this point.
- TPM is an industry standard how secure signing can be done on hardware level.
part 2: register the information on regular times
- Each zero OS at registration time will report capacity in HRU,SRU,NRU,CRU (see resource units on wiki) to the blockchain. TFChain will calculate the CU/SU (cloudunits) out of this.
- Every X time (at least once a week), zero-os will inform the blockchain called TFChain and sign using TPM (see above)
- we keep history of these registration, if weird behaviour happens e.g. abnormal changes then the node will be invalidated and the locked up farming rewards will not be released.
part 3: secure bios & boot process
- each certified node is bios locked which means users cannot boot the 3Node using another operating system (through USB stick or network boot), to reverse engineer or check what is on the node.
- combination of TPM signing and checking that the bios has been locked + checking validity of the bootloader (hashing) can make it hopefully impossible for hackers to change the Zero-OS system which is reponsible for offering security for our workloads as well as for IT capacity reporting.
- This should make it super hard (hopefully impossible) for a hacker to boot a custom version of Zero-OS see above.
part 4: anti fraud module (Q1 2022)
- this is the most crazy of our measurements
- on TFGrid blockchain level a blockchain piece of code is writing a computer program
- this code written is custom auditing code (code writing code)
- This blockchain driven code = our antifraud module called “sherlock”
- Sherlock creates custom code, this custom code is
- custom generated per 3node
- changes all the time
- measures the resource units: HRU,SRU,NRU,CRU
- verifies the certification status
- verifies the TPM signing and fact its active
- verifies validity of zero-os core files like boot loader
- verifies there are no weird processes running
- a custom public key is embedded in the custom code to sign the information gathered
- the custom code will send gathered info back to the blockchain and sign in blockchain
- Sherlock generated code gets compiled to a binary in the blockchain TFChain.
- Sherlock runs at random intervals couple of times per month per 3node.
- 3Nodes will pick up this binary and execute it.
- If TFChain sees that Sherlock has not been used in expected intervals or the information did not come back in time (imagine someone is trying to reverse engineer) then the node will be put in “untrusted mode” and farming will stop
- Sherlock runs from random blockchain nodes, to make sure hackers cannot intervene the generation of the code.
- The custom code will also validate with the TPM and report if issues found.
This is very safe because, reverse engineering is not possible because even of the hacker knows how it all works he/she would have to reverse engineer the custom code in less than a minute which is not possible. Its already quite impossible anyhow because the custom code gets delivered as an obfuscate binary which is hard to reverse engineer and for sure not in 1 minute.
If a malicious user would have change Zero-OS to report wrong information, we would still spot this and the node becomes disabled. Even if a user would succeed now and in Q1 2022 we would see this because of the timing buffer the hacker gets no rewards.
part 5: 2 years lock in or till 30% utilisation gives timing buffer
All farming rewards are staked per 3node and only given at 30% utilisation or 2 years.
This gives enough time for TFChain to make sure the 3Node is trustworthy.
part 6: reputation
At threefold we believe in reputation driven systems, each farmer, 3node gets a reputation and this is kept on a blockchain. If a farmer or 3node which links to a farmer does something wrong your reputation will be harmed, letting others know.
WE BELIEVE ALL OF ABOVE DESCRIBED MEASUREMENTS GIVE US A QUITE GOOD WAY HOW TO PROTECT SECURITY AND FARMING CORRECTNESS OF ZERO-OS NODES.
possibility 2: manipulate the blockchain
- blockchain is running over X nr of nodes using substrate
- unless serious bugs are in the software it should be impossible for anyone to change those rules
possibility 3: network traffic generation
We didn’t think about this but a community member recently brought this to our attention.
What if you buy a cheap node and use as much bandwidth as you can, can’t you generate an income that way getting network farming rewards.
We thing we should be ok for following reasons.
- bandwidth costs money and it needs to be public traffic so there is a cost
- customers need to pay for the bandwidth as well, so its possible to generate traffic but you would need to be a customer from something deployed on TFGrid which means you need to pay, this payment should always be higher than what you can earn by faking, so in other words there is no economic incentive.
- we have the reputation system, see above
- if ever needed, we can always implement something, to validate workloads running on 3Node against traffic used, some sort of auditing of patterns which aren’t ok. But no plans right now.
If you know or suspect any other mechanism, please let us know.