Provenance Hash Questions

[ghost]

I have a questions about provenance hash.

Projects such as Bored Ape Yacht Club have a webpage like this. Picture:

I'm not sure how one would recreate this Bored Ape Yacht Club webpage when using this library. Some questions I have are:

1. How does one choose a starting index? Is this randomly chosen by us and set here in library as shown here with const startIndex = 0;? Some projects like Invisible Friends seem to do complicated things to get a starting index as shown in link.
2. Is this formula (tokenId + startingIndex) % 10000 → Initial Sequence Index used at all in this library? Not sure if this is something done somewhere else.
3. I generated the provenance hash with node utils/provenance.js using sample artwork. However, I don't see the hashes of individual images. Are these provided?
4. Is the Bored Ape Yacht Club webpage overkill?

[nftchef]

Hi, this is a more complex subject.

4. for most projects, yes. Attention to provenance and offset "true randomness" has fallen a bit out of popularity in the last couple of months. It's still a good practice to handle this in the contract from the beginning, but perhaps a page like this is best saved for after minting is closed and if the community asks for it (my opinion)

5. The start index is usually chosen in a single Chainlink VRF call to get a random number (in the smart contract)

6. This formula can be used in the smart contract for convenience, but it generally will happen off-chain on your metadata server (so you won't be using IPFS initially)

7. The generator will output individual hash for each image as long as the option is set to true in config.js. Then, after generation, when running the provenance hash script, it will output provenance.json containing the concatenated string (like BAYC) and the single provenance hash

Hope that helps! I am moving this to a discussion to preserve the conversation for others.

[ghost]

@nftchef Thanks for taking time to answer! I see now see the individual hashes for each image along with the concatenated/final provenance hash.

I'm still a little unsure how to use this library and a smart contract together for provenance hash. Meaning from beginning to launch.

Could you please outline the steps of how you would launch a collection with provenance hash properly using this library? (this could even be a new tutorial in readme docs).

For example, maybe listing out steps such as:

1. Create start index using Chainlink VRF call.
2. Change start index in art engine inside of config.js
3. Generate images with npm run generate
4. Generate provenance hash with node utils/provenance.js
5. Set start index in smart contract to the same one in art engine. This must match!
   Your documentation shows this for start index and says to match contract. Still unsure why start index is important for any of this?

6. Next step...
7. Next step...

Would you be able to outline correct steps? Above is just example. I could then help to create readme/docs to add to library based on this answer for others. Basically trying to create the best tutorial out there for provenance hash with best practices.

[nftchef]

This is a pretty good start! This would definitely be a longer tutorial and one I haven't seen yet

the on-chain part is very simple, you are just adding the provenance hash and offset number to the contract so it is on-chain, trackable if it changes, and publicly verifiable. The rest of the information is displayed offline, like BAYC does, or not depending on a project's interest level.

however you decide to store it, it would be good practice to document what it hashes, e.g., images, or metadata, or both, and note what hashing algorithm you used so others could reconstruct it.

    string public PROVENANCE_HASH; // keccak256

   function setProvenance(string memory _provenance) external onlyOwner {
        PROVENANCE_HASH = _provenance;
    }

Optionally, you can add a require statement to prevent mutating the provenance hash if it is already set.
Another option, if you are really prepared is to set it in the constructor

[ghost]

@nftchef In regards to your comment, the main thing I still don't understand is the starting index. Your library has this:

Notice it says "Be sure it matches your contract!"

BAYC has this in their contract which is weird:

uint256 public startingIndexBlock;
uint256 public startingIndex;
/**
    * Set the starting index for the collection
    */
function setStartingIndex() public {
    require(startingIndex == 0, "Starting index is already set");
    require(startingIndexBlock != 0, "Starting index block must be set");
    
    startingIndex = uint(blockhash(startingIndexBlock)) % MAX_APES;
    // Just a sanity case in the worst case if this function is called late (EVM only stores last 256 block hashes)
    if (block.number.sub(startingIndexBlock) > 255) {
        startingIndex = uint(blockhash(block.number - 1)) % MAX_APES;
    }
    // Prevent default sequence
    if (startingIndex == 0) {
        startingIndex = startingIndex.add(1);
    }
}

Not everyone has this from BAYC though. For example, Doodles contract and Invisible Friends contract don't have all this complex index code - in fact, they don't have anything in their contract about starting index from what I see. Doodle's provable fairness webpage and Invisible Friends provable fairness webpage is also more simple than BAYC. BAYC is overkill it seems.

Sorry if this is lots going back and forth, but since your art engine states starting index must match contract, just not sure how to do this correctly (also your example above with Solidity code doesn't have starting index). This is why I tried listing things out step-by-step like a small/quick tutorial above. You mentioned IPFS too, so tricky about steps. If you have time, could you clarify this?

[ghost]

@nftchef I know you prob have lots to do, but just wanted to see if you could update on starting index question I posted above?

thank you 🙂

[nftchef]

NP! sorry for the delay, sometimes I miss these.

Not all contracts inherit sequential token starting indices, from erc721 enumerable for example where the inherited contract implements the start index and keeps track with ++ on each mint for example.

The note in my generator is aimed (mostly) at people using the original Hashlips sample contract where the token index started at 1, and for anyone else who prefers the 1 vs. 0 start index. They would end up having issues where the first or last token was missing or greater than/equals operator issues for example.

The difference between the BAYC and doodle/invisible friends implementation is mostly around how and when the shuffling happens. (keeping in mind this is the first time I've looked at the provable fairness for those projects)

From doodles:

After the finalization of art assets, we shuffle all 10,000 Doodles metadata files
A provenance hash is calculated based on the final shuffled order of metadata files
32223239cec3be97780fd6a43717feee6dc7d7c2d50fa31ef44d6fcead1a3681
We send a transaction to the smart contract to commit the provenance hash to the blockchain.
https://etherscan.io/tx/0x7ec645bd154c1cdc2166867c0cdcee829b15d70aa4ed8f60319056de4f48f47b

In the Doodle/IF approach, they're getting the seed number from the community then shuffling the data off-chain, then generating and adding the provenance hash.

But, (unless I'm missing something) there's still an opportunity where the team knows the order pre-reveal, which is why they need the added step(s) for fairness:
From Doodles

Mint 504 founder's reserve tokens. Unrevealed metadata is also used here ...[In this order]
A signed attestation by Poopie, Burnt, and Tulip will be provided promising that the tokens will be distributed in this exact order. No cherry-distributing here!

From IF

Additionally no core team members will be allowed to shop tokens on secondary in the pre-reveal period.
Let list sale be open for 1 hour, then mint 78 tokens in one transaction

They both have to "promise" that there won't be any cheating.

Whereas with the BAYC approach, you first upload the provenance hash, presale (or pre-shuffle), then you are both generating and shuffling (offsetting) on-chain post-sale, so you have to do a little more work to unshuffle and prove the provenance, but then you don't need that layer of trust needed, or "signed promise statements" because it's all provably random on-chain.

You could also add the same layers of "the team will not buy unrevealed" kind of statements for extra trust/nicety.