# Decentralized Storage with Access Control and Data Persistence for e-Book Stores
## 4 Proposed System
### Decentralized Access Control to the Stored Data
#### 4.2.1 Access Control Contract (ACC)  
An ACC provides three fundamental functions used for access management: register, which registers books, mint, which issues NFTs corresponding to access rights, and hasAccessRight, which checks whether a user has access rights to a book. The relationship between ACCs, authors, and readers is shown in Figure 3.  
First, the authors register e-book metadata using the register function, but this registration must be performed before the e-book data are uploaded to the d-book-repository. The register function is given the book title, price, and Merkle root of the e-book data as  
Figure 1: The flow of uploading e-book data. Figure 2: The flow of downloading e-book data. arguments, and the price, Merkle root, and author's Ethereum address are recorded on the blockchain as mappings keyed to the book title. After registration is complete, readers can use the \(\mathtt{mint}\) function to publish NFTs associated with the book. The \(\mathtt{mint}\) function issues new NFTs by paying a cryptographic asset equal to the price set by the author, and the paid cryptographic asset is transferred directly to the author. At that time, the token ID of the issued NFT is associated with the purchased book, this mapping is also recorded in the blockchain. Only books registered with the \(\mathtt{register}\) function can be associated with NFTs, but there is no upper limit to the number of NFTs that can be issued per book. The \(\mathtt{hasAccessRight}\) function is used to check whether a given account has access rights to a given book. This function is called by a storage node when the node receives a request to upload a shard to a reader, and the requested shard will not be uploaded if it finds that the user does not hold access rights. Note that since this function only refers to data on an ACC, no gas cost is required to execute it. Although it is possible to implement a similar system on a smaller scale by simply mapping books to their purchasers without utilizing NFTs, the adoption of NFT standards is believed to facilitate more active utilization through third-party services such as OpenSea. The code for the \(\mathtt{register}\) Listing 1, \(\mathtt{mint}\) Listing 2, and \(\mathtt{hasAccessRight}\) Listing 3 functions is as follows:  
```
functionregister(uintprice,stringmemorytitle,stringmemorymerkleRoot) ->public{ require(bytes(_contentMerkleRoots[title]).length==0); _authors[title]=msg.sender; _prices[title]=price; _contentMerkleRoots[title]=merkleRoot; _content_title_list.push(title); }
```  
Listing 1: Solidity code for the register function. ```
functionmin(stringmemorytitle,addressto)payableexternal{ require(_prices[title]==msg.value); payable(_authors[title]).transfer(msg.value); _contents[nextTokenId]=title; _safeMint(to,nextTokenId,'); nextTokenId++; } //Thisfunctioniscalledwheminting. function_beforeTokenTransfer(addressfrom,addressto,uinttokenId) internaloverride{ if(from!=address(0))_accessRights[_contents[tokenId]][from]--; _accessRights[_contents[tokenId]][to]++; }

Figure 3: The relationship between an ACC, an author, and a reader. ```
functionhasAccessRight(addressaccount,stringmemorytitle)publicview returns(bool){ return_accessRights[title][account]!=0||_authors[title]==account; }
```
Listing 3: Solidity code for the hasAccessRight function. #### 4.2.2 Distributed Storage of Shards in Node Groups

Storage nodes participating in the d-book-repository are assigned unique PeerIDs generated from their secret keys, similar to existing distributed storage systems like the IPFS. However, in the proposed system, these storage nodes are organized into \(k\) groups based on the remainder of their PeerID when divided by \(k\). The number of groups, \(k\), is specified at the time of ACC deployment and cannot be changed thereafter. The number of groups can be determined by taking into account the persistence strength, as described in Section 5.3.