-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Public data gameplay (NFT inscription might be a good name?) rules darft #3
Comments
New ERC: Verified Public Owned DataFrom Our rules above:
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:
|
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: |
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. |
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:
Missing:
|
Amazing~ I will review that ~ |
All logic code has finished at 0f15713. |
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:
(EVM has the past 256 blockhashes available for smart contracts to use) |
A basic idea for proving public data storage is I've made a new improvement, which I'll post later. |
Proof of Public Data Storage
|
But why is there a 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. |
The design of For instance, in some economic systems, more rewards can be provided for an increased amount of PoW proofs of storage. |
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.
The text was updated successfully, but these errors were encountered: