Public data gameplay (NFT inscription might be a good name?) rules darft

[waterflier]

I am preparing for the "public data gameplay" ，Can have some interaction with communities based on ERC721 NFTs.

a. Qualified storage suppliers: Only suppliers meeting certain criteria (time, a certain amount of data delivery size) are eligible to participate in the public data storage reward program.

b. Qualified suppliers actively store public data in a certain NFT contract.

c. In specific blocks under certain conditions, SHOW the designated Merkle path of public data is considered a successful storage, and successful storage SHOW will be rewarded. The reward comes from the system, and the owner of the public data can also contribute addition rewards.

d. In a settlement period (usually including multiple eligible reward blocks), the most showed public data (Top n? and possibly exceeding a certain base amount) will earn additional rewards for the author/owner and the suppliers of the public data.

[waterflier]

The main rules for the NFT inscription game mechanics:

1. The fundamental purpose of the NFT inscription mechanism design is to achieve decentralized storage of NFT data.

2. The Public Data Sponsor (Sponsor) calls the contract interface to create public data. An initial reward is deposited based on the data size. The minimum initial reward is 48 * data size.

3. Of the rewards deposited into the Public Data, 80% will enter the balance of the public data, and 20% will enter the Award Pool of the system.

4. After public data is created, anyone can make deposits. When a single deposit amount exceeds 110% of the historical maximum single deposit amount of the public data, the Sponsor will be replaced.

5. When creating public data, if an NFT contract address and TokenId are specified, the Owner of the Public Data can be further credibly determined. The rules are as follows:

a) If no contract is specified, the Owner of the data is the first creator.

b) If a contract is specified but no Index, the Owner is the Author of the contract.

c) If both contract and Index are specified, the Owner is the Owner of the NFT contract corresponding to the Index.

6. Storage Suppliers can choose to save any Public Data.

7. Storage Suppliers can call the SHOW Data interface, and each successful Show can get a reward. The reward amount is 20% of the Balance of the data displayed.

8. SHOW Data is the core mechanism of the system. A successful Show Data must meet the following conditions:

a) The Supplier has sufficient qualifications: at the minimum, its remaining space should be 16 times the space of the Public Data.

b) The current block.number meets certain conditions.

c) Storage challenge parameters are constructed based on the hash of the previous block. The Supplier must submit response data for the storage challenge according to the parameters.

d) The same Supplier can only SHOW one data in a block.

9. After a successful SHOW Data, the Data's Score will increase according to the DataSize.

10. After the end of a Winner cycle, the system will distribute rewards based on the final Score ranking of the top 16 (or 32) Show Data.

11. The rewards for this cycle's Winners are obtained proportionally by 3 parties: 50% to the Sponsor, 30% to the last 5 successful SHOW Suppliers, and 20% to the Data Owner.

The games encouraged by the above rules:

1. An obvious winner-takes-all game: Forming an alliance among the Sponsor, Owner, and Supplier to win the competition. This competition strategy will improve the reliability of storing popular NFT data and allow popular NFT Owners to benefit more.

2. Increasing the success rate of SHOW is a key tactical action. Appropriate thresholds will allow the system to have more Suppliers, and these Suppliers will store public data well.

3. The Sponsor's game: Snatching the Sponsor and Owner of a Public Data about to win is another battlefield. Our designed mechanism will allow popular Public Data to have more Balance, thereby attracting more miners to Show Data.

4. How miners choose which Data to SHOW is a complicated game: Choosing to SHOW popular data may not have a high success rate (everyone Shows in the same block, making endorsements difficult); choosing unpopular data makes it hard to win. But no matter how you choose, having sufficient ammunition is the prerequisite for executing different strategies.

Some economic logic:

The tokens involved in the above gameplay refer to GWT by default. GWT can be exchanged with the built-in DeFi and currencies we support. The existence of built-in DeFi further diversifies the game rules.

To be attractive, our gameplay still needs a get-rich myth: The final Award must be attractive. We should support high-value assets. This actually increases the leverage of our capital on hand.

[waterflier]

New ERC: Verified Public Owned Data

From Our rules above:

1. If no contract address is configured, the Owner of the public data cannot be changed.

2. NFT contract address configured but Index not specified:

   • If the contract has DataHash configured, the Owner is the Author and it is trusted data.

   • If the NFT contract has Author configured, the Owner is the Author.

   • If no Author is configured for the NFT contract, the Owner is all NFT holders. **A dedicated claim contract needs to be developed to simplify reward claims.

3. NFT contract address and Index specified:

   • If the NFT has DataHash configured, it is trusted data.

   • The Owner can be determined.

If a (NFT) Contract implement the following interface, it can be considered as a Verified Public Owned Data contract:

interface ERCXXXPublicData {
    //return the owner of the data
    function getDataOwner(bytes32 dataHash) public view returns (address);
    //return token data hash
    function tokenDataHash(uint256 _tokenId) external view returns (bytes32);
}

The standard for the bytes32 dataHash:

The hash value based on the SHA256 algorithm, with the high 64 bits (8 bytes) being the data size, and the low 192 bits (24 bytes) being the low 192 bits of the SHA256 value of the Merkle tree root node.

The method to construct the dataHash for a given file:

1. Split the file into 1KB chunks. Pad zeros to the end of the last chunk if needed.

2. Calculate the SHA256 hash for each chunk and the low 128bits is the Merkle tree leaf value

3. Construct a Merkle tree , root node hash algorithm is SHA256, other node use low 128bits of the SHA256

4. Return the combination of the file size at high 64bits and the low 192 bits of the Merkle tree root node hash.

[waterflier]

Based on this gameplay, we can build some Web3 file sharing applications around the NFT inscription gameplay.

[weiqiushi]

The mechanism of SHOW Data may need to be refined, and on the Ether-compatible public chain, it's currently create a block event 15 seconds. This also means that a Miner:

• Discovers and synchronizes a new block
• Calculates and validation data
• Send the validation data as tx to a public node.
• Hope the node package it in the next block. All these processes should be completed within 15 seconds. Otherwise this SHOW Data will be invalid. This logic will make it very difficult to send correct SHOW Data for miner

[waterflier]

I hope SHOW has a certain degree of difficulty. This logic is sufficient for the block generation speed of the BTC network, but I don’t know whether the EVM ecosystem after the POS transformation will allow users to immediately create a TX that can enter the block based on the status of the previous block within 15 seconds. This step may be interfered by today's centralized miners, but I think we can give it a try.

[weiqiushi]

I wrote some code in a seperate sol file: public_data_storage.sol, at commit 0911002.

When the logic is mostly stabilized, I'll consider merging it with the main contract

it now implements:

• Create public data
• Deposit for an existed public data
• Some show data logic, incompleted

Missing:

• Data reward logic. How was it triggered? by Who?
• Reward withdraw logic.

[waterflier]

Amazing~ I will review that ~

[weiqiushi]

All logic code has finished at 0f157133. I will add testcode from tomorrow

[fulldecent]

I don't understand why the game requires the mechanics that storage must be verified within a 15 second block.

Proof of storage can be implemented as:

1. Wait until next BLOCK_NUMBER % 100 == 0
2. Select a 32-byte word from the storage file with SELECTED_WORD = BLOCK_HASH % LENGTH
3. Submit a tree witness that you have that word.

(EVM has the past 256 blockhashes available for smart contracts to use)

[waterflier]

A basic idea for proving public data storage is "To answer a unique, randomly presented question within a limited time." If answering this question (submitting storage proof) is sufficiently incentivized, then from the standpoint of maximizing benefits, users would tend to save this file locally. The current issue with the implementation is that the challenge question isn't necessarily unique, which is especially problematic for smaller files.

I've made a new improvement, which I'll post later.

[waterflier]

Proof of Public Data Storage

0. Users who can submit storage proofs to receive rewards are known as Suppliers. Suppliers need to prepare a certain amount of staking tokens.
1. For a block with block height n the block hash yields a 32-byte nonce value and an insertion position Pos ranging from 32 to 992. (because the leaf data size is 1024)
2. To generate a correct storage proof, the Supplier looking all leaf nodes, inserting the nonce at Pos, and selects the most suitable leaf nodem to minimize the Merkle tree root hash after insertion.
3. The Supplier calculates a 32-byte noise value before the insertion position, so that the new leaf_data allows the Merkle tree root hash to meet a difficulty condition (such as how many of the lowest bits are 0).
4. The Supplier submits the storage proof {n,m,path_to_m,leaf_data,noise} (size is 8+2+1024+1024+32 = 2090bytes） to the blockchain, If this proof is not challenged within a certain time, the Supplier is deemed to have successfully submitted the storage proof and can receive a reward.
5. The Chain cannot verify whether m is correct. However, other Suppliers who have the full data, if they discover that m is fabricated, can submit the real {m, path_to_m,leaf_m_data} to challenge the storage proof on the chain and win the Supplier's staking tokens after successful challenge.

[fulldecent]

But why is there a noise? Are multiple people competing for the same prize?

If yes, then this is actually proof-of-work.

If no, it is just increasing electricity cost, since the supplier already proved it has random access to the file.

Or is there no time limit? In that case it makes sense because you want them to avoid waiting for the blockhash to move to a block they control.

[waterflier]

The design of noise is reserved for PoW. I hope that the proof of storage can serve as a foundational protocol, adaptable to a variety of economic models.

For instance, in some economic systems, more rewards can be provided for an increased amount of PoW proofs of storage. Other economic systems might dynamically require a minimum PoW value based on the distance between the block submitting the storage proof and block n.