C CML mining in epoch6 #89
kevingzhang
announced in
Announcements
Replies: 1 comment
-
If there is less than 4 B CML mining, the reporting verification won't work. so we have to keep more than 4 B CML and 1 C CML mining all the time. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is one of the major features we added into epoch6.
Local machine, no public IP required
The C CML can be plant into a local ubuntu machine and start mining.
The word local means that you do not have to have a public IP usually rent from a cloud service provider. You can run a ubuntu machine in your home network, or even a ubuntu virtual machine on top of Windows or Mac.
C CML won't provide service to other users, but a monitor and report service
Because C CML doesn't need a public IP, it is not possible to provide host services as B CML does. What C CML mining is actually does is that it monitor those mining B CML, verify their integrity and availability. If C found any B is out of service, C will report to any other B CML. After those B CML confirm this report is validated, the out-of-service B will be set offline.
This set to offline action was done by a temporary centralized service in epoch5. it causes many false positive. I hope this C mining may fix this issue
In epoch6, the C CML only run the Availability Attestation (AA for short) to detect any out-of-service B CML. In the future, C will also run a Proof of Timestamp consensus to detect any B CML did not provide correct timestamp from GPS atomic clock.
How the AA runs
Availability Attestation (AA) is running in C CML. At any block, a few C CML is selected to run the AA algorithm. The algorithm will send AA request to a B CML and wait for a response. If there is no response after a predefined timeout, the C CML will report Out-of-service to other B CML.
When a B CML (we call verifier) received the out-of-service report, it will verify by sending the same AA request to the suspect offline B CML. If there is actually no response, this B verifier will send tx to layer1 and confirm the report.
As long as there are a certain amount of B CML send the tx to layer1 to confirm the report. Layer 1 will run a blockchain logic to set the suspect B CML to offline mode. Also slashes the deposit.
In order to make the verification works, at least 4 B CMLs need to presents and verify.
The reporting C will get rewarded by reporting and verified.
What if the C CML report false alarm?
Currently we do not give any penalty to C CML who report false positive. Because C cannot report at any time. Only if it waits to its turns (random by block hash) to report. So far we did not see the DDoS possibility. We can run this for a few epochs, if there is potential DDoS, we will change the algorithm to add penalty later.
What if the C did not report?
There is no penalty if C does not report any out-of-service B CML. But the C won't get any reward if it does not report.
What if no B CML get offline, will C CML works without any reward in a long run?
If all B CML is honest and high availability. The C CML has nothing to report. To avoid C CML give up monitoring, we designed the fisherman algorithm.
Fisherman
Randomly, some B CML will be selected to be fisherman. It indeed not to response the Availability Attestation request. So C CML will report to other B CML. When other B CML to send request to confirm, it can response an evidence of fishing. So the other B verifier will not send tx to layer1 to confirm the report validation, but it send another tx to layer1 to confirm that the C CML reporting fishing was correct.
Layer 1 will issue reward in case of fishing activity.
Because the fishing is happening randomly and continuously. The C CML can always get some reward. So they should not give up.
Beta Was this translation helpful? Give feedback.
All reactions