It has been nearly two years since the Proof of Scan consensus protocol was launched, featuring a hybrid consensus model combining Proof of Work (PoW), based on recognition technology, and Proof of Authority (PoA). While the PoA component has been developed smoothly, the community has continually faced challenges with persistent attempts to monopolize the network through the PoW entry point.
In order to address the challenge, as well as to ensure the extraordinary level of decentralization required for 3DPRC-2** tokenization standard, this advanced PoW v2 component has been developed and released on The Ledger of Things mainnet. This new version is designed to provide robust resistance against ASIC and FPGA devices.
In this article I would like to make some overview on “what’s under the hood” of PoW v2 and why it is capable of maintaining the mining process at distributed around the network.
Prohibiting the reverse method of calculation
For most of well-known PoW consensus protocols there couldn’t have been such an exploit around, as the reverse method of calculation of nonce representing just a few bytes. However, it makes a huge difference when 3D object shape is leveraged as nonce instead, which is decidedly fair to say about 3DPass.
To be more specific, the reverse method of calculation is the way to compute the block hash first and then get 3D model recovered out of it, which is the way easy to do, than to tackle picking up random 3D objects and get each of them scanned every loop afterwards. Due to the strict requirement for every miner to be able to handle the user objects submitted through the 3DPRC-2, this shortcut became the subject number one to get rid out of.
How it works in PoW v2:
- In order to prove 3D object exists at the beginning of the mining loop the bock author first must get random 3D object scanned with no rotation angle (μ = 0) resulting as Grid2d** output 1 (top 10 hashes). The second component is time_hash, which must timestamp upon the block header and impact the pre_hash (main block identifier), as well.
2. That is ensured by the rotation_bytes (by which the target rotation angle is defined) calculated out of a combination of both the pre_hash and the topest Grid2d zero-angled hash (μ = 0). So that any modification made on either of them will inevitably impact on the rest.
3. It wasn’t until having the object scanned with zero angle the target rotation angle (μ = x) could be calculated. The same as usual the block author would be challenged with picking up some 3D object shape and get it scanned with the target rotation angle (μ = x) until the pre_hash meets the current difficulty number.
4. Both of the outputs of Grid2d μ = 0 and μ = x are getting processed by the RandomX** hashing algorithm to equalize CPU and GPU in terms of velocity of mining even further.
The entire cycle of the object processing would look like this:
Random 3D model in obj → Grid2d (3D model μ = 0) output → Random X (Grid2d μ = 0) blake2b hash → rotation_bytes x = 4 bytes out of pre_hash + 4 bytes out of RandomX (Grid2d μ = 0) blake2b hash → Grid2d (3D model μ = x) output → Random X (Grid2d μ = xo) blake2b hash
The exact number of historical block steps required is being provided and managed by runtime
5. There is a rule on new block import, which requires: Grid2d output 1 ≠ Grid2d output 2. Therefore, the object shape must be complex enough to entirely avoid the Grid2d recognition error that is most likely to face with, especially, when it comes to scanning some regular- shaped objects (ex. a sphere).
1 Node = 1 Vote rule
There will be an additional “proof of context” task to solve, having the access to the full blockchain db is required for. Depending on the pre_hash calculated, there is going to be a directed sequence of N pseudo randomly chosen blocks to pick up (ex. 104786 → 476673 → 219964 → 891987 → 12897) and prove its availability for the mining loop. Every mining loop will require another one different sequence to prove.
This will ensue the block author has calculated the block themselves while on the node running (without having a third party for the outsourcing), and, therefore, gets responsible for the user objects processing as much as for his own block. Now he must handle the user’s object from the queue, unless he wants to lose the block rewards.
Block structure
I hope you’ve picked up something new and enjoyed reading the article. I’ll post a few useful links down below, so that you can dive down into technical depth even deeper:
**
- The implementation of The Ledger of Things Node: https://github.com/3Dpass/3DP
- 3Dpass White Paper v2 : https://github.com/3Dpass/whitepaper/blob/main/3DPass_white_paper_v2.pdf
- Grid2d recognition algorithm description: https://3dpass.org/grid2d
- RandomX hashing https://github.com/tevador/RandomX/blob/master/doc/design.md
- 3DPRC-2 tokenizaton standard paper: https://github.com/3Dpass/whitepaper/blob/main/3DPRC-2.md
- Mining guidelines: https://3dpass.org/mainnet#linux-mac
