# Innovative Application of Blockchain Technology for Digital Recipe Copyright Protection
## 3 Schematic Design
### System Design
#### 3.2.2 Blockchain Data Upload and Download  
The user interaction of a digital copyright protection system consists of two main aspects: uploading and downloading data. The design and realization of these two key processes are described in detail below, as shown in Figure 2.  
In our Ethereum-based digital copyright protection system for blockchain recipes, first, a user registers, and the system automatically generates a public/private key pair. The public key is used for external data encryption, while the private key, known only to the user, is employed to decrypt received data. Furthermore, the private key's storage on the server is encrypted, offering dual-layer protection. The system also allows users to easily update or revoke their keys if they suspect their key's security is compromised. Through this method, we ensure the integrity and security of user credentials.A creator (e.g., [PERSON]) uploads their recipe by invoking a smart contract [17], i.e., \"RecipeUploadContract\" (as described in Algorithm 1). [PERSON] creates a new recipe, such as \"Delicious Pasta\", and uses her private key (\(Priv_{\text{alice}}\)) [18] to sign the content, then encrypts the recipe using her public key (\(Pub_{\text{alice}}\)) [19]. In this way, the integrity and authenticity of the recipe are guaranteed. This process is called a transaction in the Ethereum blockchain, and [PERSON]'s signature ensures the non-repudiation of the transaction. Next, the encrypted recipe and signature are sent to the main chain node responsible for duplicate recipe detection. This smart contract determines if there is a duplicate by comparing the newly uploaded recipe to the existing recipes on the blockchain. If a copy exists, then the recipe will not be accepted. If the recipe passes duplicate detection, it is sent to an IPFS [20] node, which stores the recipe in a distributed file system and generates a hash address based on its contents. This hash address is then sent to the master chain node. The master chain node runs a smart contract called \"DataStorageContract\" that stores the hash address, [PERSON]'s public key, the recipe's signature, a timestamp, and other metadata (\(Meta_{\text{data}}\)) (e.g., the title of the recipe, [PERSON]'s name, the type of recipe, etc.) on the blockchain. This way, recipes are assigned unique data credentials, and copyrights are protected. When a user (e.g., [PERSON]) wants to download a recipe, he calls the \"RecipeDownloadContract\" smart contract (as described in Algorithm 2) and provides his public key and the ID of the recipe (\(ID_{\text{recipe}}\)) he wants to download; then, the smart contract validates [PERSON]'s request. First, it checks if [PERSON] has permission to download the recipe. If [PERSON] has the license (\(Cert_{\text{requester}}\)), the smart contract obtains the hash address of the recipe from the blockchain and sends it to a specialized intermediate node. The intermediate node uses this hash address to download the recipes encrypted with [PERSON]'s public key from the IPFS node. The intermediate node contacts [PERSON] and asks her to generate a re-encryption key for [PERSON] [21]. The intermediate node uses this key to transform the recipes encrypted with [PERSON]'s public key into one with [PERSON]'s public key. The intermediate node sends the recipes encrypted with [PERSON]'s public key (\(Pub_{\text{requester}}\)) back to [PERSON]'s node. After [PERSON]'s node receives this ciphertext, he can decrypt it using his private key to obtain the recipe's contents. When [PERSON] successfully downloads the recipe, this transaction needs to be recorded. The smart contract encapsulates the details of this download transaction, including the ID of the recipe, [PERSON]'s public key, [PERSON]'s public key, and the time when the transaction occurred, into a transaction record. This transaction record is then sent to the side chain for storage.