Advise on Contract Spec

[caseywescott]

Here is the Rough Spec Idea:

#4 (comment)

It would be great for you to look at the data types for each field and see if they are consistent with the popular patterns seen in NFT series.

I'd also like to know if the structure of the contract looks robust. Specifically if the:
(Storage (Series (ArtistMetadata, SVG data))) is the best way to structure things.

Basically red pen any weaknesses and make recommendations for a better implementation for implementing a contract that manages Series of SVG NFTs

[ptisserand]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I'm part of Starknet ecosystem since around 2 years as a developer/contributor on several projects (starknet.dart, kakarot, madara, ark project).
I know cairo development.

How I plan on tackling this issue

I will review the proposal for contract and check if there is some standard or pattern from OZ which can be usefull.

[ShantelPeters]

Hi @caseywescott please can I be assigned to this issue

[ShantelPeters]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I am a blockchain developer please assign me and i will come up with a PR immediately

How I plan on tackling this issue

I will approach the problem with the following:

1. Data Type Consistency

• ArtistMetadata: Ensure the metadata fields such as name, bio, website, etc., are stored in data types that minimize gas costs. For example, storing a URL as bytes or string is common, but using bytes32 can be more gas-efficient if the data fits within that limit.
• SVG Data: SVG data should be stored in a string or bytes type, but consider compressing the SVG data to reduce storage costs. You could also explore off-chain storage for large SVG data with a hash reference on-chain.

2. Storage Structure

• Series: Structuring your contract with Series holding ArtistMetadata and SVG data is a reasonable approach, but ensure each series ID is a unique identifier (uint256 is typical). Also, consider how easy it is to extend or upgrade this structure in the future.
• Nested Mappings: If you’re using nested mappings, make sure they are justified. Mappings like SeriesID => ArtistMetadata and SeriesID => SVGData are efficient but consider separating concerns (e.g., different contracts for metadata and SVG storage) for modularity.
• Gas Efficiency: Nested structures can increase gas costs. You might want to flatten the storage structure or use a more gas-efficient design, such as storing metadata and SVG data in separate storage mappings rather than nesting them within Series.

3. Robustness

• Security: Ensure access control is in place, particularly for functions that modify ArtistMetadata and SVG data. Use onlyOwner or a similar pattern to restrict who can modify the series.
• Upgradeability: Consider implementing a proxy pattern if you anticipate needing to upgrade the contract in the future without redeploying.

Recommendations

• Gas Optimization: Compress SVGs, minimize the size of strings, and consider off-chain storage solutions with on-chain hashes to save gas.
• Modularity: Separate concerns by storing ArtistMetadata and SVG data in different contracts or storage locations, enabling easier upgrades and maintenance.
• Upgradeability: If future-proofing is a concern, implement a proxy pattern for contract upgrades

[onlydustapp]

The maintainer caseywescott has assigned ptisserand to this issue via OnlyDust Platform.
Good luck!