## 3 Scheme Design
### Simulation Experiments  
The experiment consists of two parts: implementing the attribute encryption algorithm and smart contract to connect the user's account wallet. First, the Java Pairing-Based Cryptography Library (JPBC) is used in the attribute encryption algorithm. JPBC is a Java encapsulation of the Pairing-Based Cryptography Library (PBC), which is usually used for algorithm simulation of attribute-based encryption. Secret sharing is one of the core steps of attribute encryption. In the access tree, if the current node is not a leaf node, a random polynomial will be generated. The constant term of the polynomial is the secret value of the current node and this value will be used for sharing. The algorithm runs recursively and the secret continues to be shared, as shown in Figure 4.  
When the user authorizes the logistics personnel and meets the set attribute list, the encrypted address ciphertext will be decrypted, as shown in Figure 5. Other unauthorized employees will not be able to view the address ciphertext, thus enhancing privacy protection, as shown in Figure 6.  
The time cost of using different attribute nodes to test CP-ABE startup, key generation, encryption, and decryption functions is shown in Figure 7. The detailed configuration is shown in Table 3. This simulation experiment is written in Java and the encrypted data size is 128 bytes. The encryption module has a higher overhead. When testing with 10 attributes, the total time of CP-ABE does not exceed 1.5 s, of which the CP-ABE encryption operation performed by the logistics company management server takes less than 0.6 s and the CP-ABE decryption operation performed by the logistics company management server takes less than 0.2 s. In general logistics systems, the usage attributes are around 5. This can meet the needs of normal logistics and transportation processes. Figure 4: Secret sharing algorithm process. Figure 5: The result of ciphertext decryption when the attribute node is satisfied. Figure 6: The result of ciphertext decryption when any attribute node is not satisfied. \begin{table}
\begin{tabular}{c c} \hline \hline
**Software and Hardware Environment** & **Configure** \\ \hline CPU & 2.90 GHz Intel Core i5-10400 \\ RAM & 16 GB DDR4-3200 \\ System & Windows 10 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Software and hardware environment configuration. Smart contracts are utilized to automate the execution of predefined tasks in this project. Specifically, in the context of the smart contracts project, these contracts are employed to manage the ownership and transactions of digital assets. The smart contract code is composed using Solidity and is deployed and executed on the blockchain. Upon the deployment of the smart contract on the blockchain, a non-fungible token (NFT) in compliance with the NFT standard (e.g., ERC721 or ERC1155) can be created. For the purpose of simulating transactions, a local test chain is deployed to acquire a number of test Ether coins, as shown in Figure 8.  
The experimental process involves designing the scheme and integrating wallets to execute transactions. The scheme implements decentralized storage using the InterPlanetary File System (IPFS), a distributed file system that enables file storage and access through a decentralized network architecture. In the context of smart contract projects, IPFS stores immutable data, such as metadata associated with digital collections. Housing metadata on IPFS can ensure data security and integrity. It is important to note that, when using IPFS to store non-fungible token (NFT) metadata, the file itself is not directly stored on IPFS. Instead, a hash value of the file is stored. This hash value safeguards the file from modification or corruption during transit, and can be used to verify the file's contents.