Blockchain's tamper-proof, decentralized qualities make it perfect for running shared provenance applications in a distributed setting, such as auditing data sharing or monitoring supply chains. However, blockchain presents challenges when it comes to storing sensitive provenance data, including the data records themselves and their connection, because (1) records cannot be modified due to tamper-proofness, (2) efficient graph tracking/tracing is required for a provenance system on the blockchain, and (3) the linkages between records should be kept from unauthorized users, including the blockchain maintainers. Existing methods either lack sufficient privacy protection, only support simple structures, or inadvertently reveal linkage volume with the UTXO model. We present \(\text{Trac}^{2}\) ZChain, which is based on our previous work Trac \({}^{2}\) Chain[57], a framework that provides complete linkage privacy (i.e., no leakages from record sizes) and full tracking/tracing functions for blockchain-stored provenance graphs. The innovative graph storage architecture presented in [57] enables the generation of provenance dependencies for arbitrary graph structures while maintaining the tamper-proofness of blockchain. However, the previous work does not provide the blockchain with the ability to verify the authenticity of the provenance record, which should be an essential property of any blockchain-based system. In \(\text{Trac}^{2}\) ZChain, we modified the original Trac \({}^{2}\) Chain protocols to make it feasible to apply zero-knowledge proof, which allows blockchain peers to verify the correctness of the on-chain provenance functions without learning private information. The evaluation and comparison demonstrate that \(\text{Trac}^{2}\) ZChain achieves efficient provenance functions, verification of records, and linkage privacy protections, and has reasonable overhead compared to the state-of-the-art approaches.
Smart contract deployment costs constitute an economic consideration in blockchain ecosystems, yet existing gas optimization approaches primarily focus on execution efficiency while neglecting deployment gas reduction. We analyze Solidity storage internals and identify that conventional variable packing–despite reducing storage slots–often increases deployment costs due to compiler-generated masking and shifting operations. This finding motivates State Variable Mutation , the first systematic approach designed to reduce smart contract deployment costs through guided reordering of state variable declarations. Our approach explores variable orderings to identify layouts that minimize gas-expensive storage operations while preserving semantic equivalence and storage efficiency. We implement our approach in DGRed , an open-source tool, and evaluate it on 300 real-world smart contracts. Results demonstrate deployment gas reductions of up to 32.72%, with an average reduction of 15.65% (52,850 gas units per contract), translating to total savings of 15,854,883 gas units across all contracts. Under high network congestion (200 gwei), these savings correspond to $12,381.4. Compared with state-of-the-art gas optimization tools, DGRed achieves superior deployment gas reductions (15.65% average vs. 4.91% for GasSaver and 2.83% for GASOL) while maintaining 100% semantic preservation and producing valid bytecode for all 300 contracts. In contrast, GasSaver introduces compilation errors in 148 contracts, while GASOL generates invalid bytecode in 234. DGRed 's state variable mutation produces identical execution gas to the original contract in all 100 contracts evaluated for execution gas impact, confirming that deployment optimization does not affect runtime efficiency. Additionally, DGRed 's 15.65% reduction is over 8 \(\times\) larger than the best achievable through Solidity compiler flag tuning alone, demonstrating that the two approaches are complementary. DGRed provides developers with a practical, semantic-preserving solution for deployment cost optimization without modifying contract logic or functionality. Because DGRed only reorders state variable declarations, it introduces no runtime trade-off, and entails no risk of behavioral regression.
