tokenized-generative-assets

The supply chain of tokenized generative assets can involve several steps, which may include the following:

• Data extraction: The process of collecting data from various sources, such as weather data, social media data, or financial data, to be used as input for the generative algorithm.
• Data providers: The companies or organizations that provide the data, such as weather services, social media platforms, or financial institutions.
• Generative algorithm: The computer program or algorithm that uses the input data to generate the artwork.
• Creation: The generative artwork is created using the algorithm, and the digital artwork is stored on a computer or server.
• Tokenization: The digital artwork is converted into a non-fungible token (NFT) that is recorded on a blockchain. The NFT serves as a digital certificate of ownership for the artwork, and it can be bought, sold, and traded on various online marketplaces.
• Listing: The NFT is listed for sale on various online marketplaces, such as OpenSea, SuperRare, or Nifty Gateway. The listing includes information about the artwork, such as the artist, the number of copies available, and any special features or attributes.
• Sale: The NFT is purchased by a buyer, who receives the digital certificate of ownership for the artwork. The buyer may keep the artwork or resell it on a secondary market.
• Storage and delivery: The digital artwork and the NFT are stored in a digital wallet, which can be accessed by the owner using a private key. If the artwork is physical, it may need to be stored or delivered to the buyer.
• Royalty payments: If the artwork is sold again in the future, the original artist may be entitled to a percentage of the sale price as a royalty payment, which can be automatically programmed into the smart contract associated with the NFT.
• Impact investors who invest in NFTs can generate monetized digital assets through the purchase of tokenized generative artworks. Institutions that buy these NFTs may use the resulting profits to invest in activities that support the initial philanthropic cause, such as environmental or social initiatives. Examples of such institutions include museums, galleries, or private collectors who may choose to display the artwork or keep it as an investment. By investing in NFTs, these institutions can not only support philanthropic causes, but also potentially benefit financially from their investment.

The exact supply chain may vary depending on the specific platform or marketplace used for the sale of the tokenized generative asset, as well as the specific data sources and generative algorithms used to create the artwork.

Code explained

• dataprovider.sol contract allows authorized data providers to provide geographic data of food supply by calling the provideData function and sending the specified amount of ether as payment. The contract owner can set the price per data using the setPricePerData function and add or remove authorized providers using the addAuthorizedProvider and removeAuthorizedProvider functions. The withdraw function allows the owner to withdraw the balance of ether stored in the contract. The DataProvided event is emitted when data is successfully provided by an authorized provider.

• generativeartist.sol contract allows the creation of ERC721 tokens that represent generative art maps based on geographic data of food supply. The mint function can be used to create a new token and assign ownership to a specified address. The getArtworkData and getArtworkAuthor functions can be used to retrieve the data and author of the artwork associated with a specific token ID.

To use this contract, you would first need to deploy it to a blockchain network such as Ethereum. Once deployed, you could interact with the contract using a wallet application that supports ERC721 tokens, such as MetaMask. You would then be able to create new tokens by calling the mint function and passing in the necessary data and author information. These tokens could then be sold or traded on various online marketplaces.

• royalties.sol contract implements the IERC2981 interface, which defines a standard way to retrieve information about royalty payments for a given NFT.

The Royalty struct represents a single recipient and their corresponding percentage of the royalty value. The _royalties mapping stores an array of Royalty structs for each token ID.

The royaltyInfo function retrieves the list of royalty recipients and their corresponding amounts for a given token ID and sale value. It calculates the amounts based on the percentage value stored in the _royalties mapping.

The addRoyalty and removeRoyalty functions can be used to add or remove royalty recipients for a given token ID.

To use this smart contract, you can import the Royalties.sol file into your main contract and create a new instance of the Royalties contract. You can then call the addRoyalty function to add recipients and their corresponding percentage values, and the removeRoyalty function to remove recipients. When the NFT is sold, the royalty amounts will be automatically distributed to the recipients based on their percentage values.

• supplychain.sol contract extends the Royalties contract to handle the distribution of royalties to the data provider and the generative artist for a tokenized generative artwork. The contract includes several features to support the supply chain of the artwork, including the tracking of spending proposals and the execution of approved proposals.

The contract defines the addresses of the data provider and generative artist, as well as the token ID and URI for the artwork. It also defines a struct to represent a spending proposal, which includes the recipient address, the amount of ether requested, and a flag indicating whether the proposal has been approved.

The contract includes a function to add a spending proposal to the array, which can only be called by the data provider or the generative artist. It also includes a function for recipients to approve a spending proposal, and a function to execute an approved proposal.

In addition, the contract overrides the _transfer function to distribute royalties to the data provider and generative artist, and the tokenURI function to return the custom token URI for the artwork.

By incorporating these features into the smart contract, the supply chain for the tokenized generative artwork can be managed more effectively, with clear rules for the distribution of royalties and the allocation of funds for other goods.

• aimodels.sol added a new property to the GenerativeArt contract, which is the address of an AI model contract. When a transfer occurs, the royalties are distributed to the data provider, generative artist, and the AI model contract.

The calculation of the royalties is done in the _transfer function, where the total amount of royalties is divided equally between the three parties. Then, the corresponding amounts are transferred to each party.

Note that this code assumes that the AI model contract has a payable fallback function to receive the royalties. If the AI model contract does not have a payable fallback function, you may need to modify the code accordingly.

• global_model.cpp implementation of the GlobalModel class defined in global_model.h in the previous example.

The constructor of the class takes an integer argument num_weights and initializes the member variable m_weights to a vector of size num_weights with all elements set to 0.0f.

The update_weights function takes a std::vector argument delta_weights, which represents the update to be made to the global model's weights. The function loops over the elements of the delta_weights vector and adds each element to the corresponding element of the m_weights vector.

The get_weights function returns a constant reference to the m_weights vector, which allows external code to access the weights of the global model without modifying them.

Together, these functions allow the global model to be initialized with a specific number of weights, and to be updated and accessed by other components of a federated learning system.

• global_model.h defines a class called GlobalModel, which is used to represent the global model in a federated learning system. The GlobalModel class contains three member functions and one private member variable.

The GlobalModel constructor is defined to take an int argument num_weights, which specifies the number of weights in the model. When the constructor is called, it initializes the m_weights vector with num_weights float elements with initial value of 0.

The update_weights function is used to update the weights of the GlobalModel. It takes a const std::vector& argument delta_weights, which represents the changes in the weights that need to be added to the current model. The function iterates through the delta_weights vector and adds each value to the corresponding weight in the m_weights vector.

The get_weights function is used to return the current weights of the model. It returns a const std::vector& reference to the m_weights vector, so that the weights can be read without being copied.

Finally, the m_weights vector is a private member variable of the GlobalModel class, which is used to store the current weights of the model.

• local_model.cpp implementation of the LocalModel class for federated learning. The class takes a GlobalModel object and the number of samples as inputs in the constructor, and initializes the weights of the local model with the weights of the global model plus a bias term of 0.0.

The train() function trains the local model by iterating through the samples, computing a prediction based on the current weights and adding a bias term to each sample. Then, it computes the gradient of the loss function with respect to the weights and updates the weights based on the gradient using the specified learning rate.

The get_weights() function simply returns the current weights of the local model.

The evaluate() function evaluates the performance of the local model on the given set of samples and labels. It computes a prediction for each sample, checks the prediction against the true label, and computes the percentage of correct predictions. The function returns this percentage as a floating point value.

• local_model.h defines a LocalModel class in C++ for use in federated learning. The class takes in a reference to a GlobalModel object in the constructor as well as an integer representing the number of samples that the local model should use for training. The LocalModel class has the following member functions:

train: This function is used to train the local model using the samples and labels passed as arguments. The learning rate is also provided as an argument to update the weights of the model.

get_weights: This function returns the weights of the local model.

evaluate: This function is used to evaluate the performance of the local model on the provided samples and labels.

The LocalModel class is defined in a header file and the GlobalModel class is included as a separate header file. The #pragma once directive is used to ensure that the header file is included only once in the compilation process.