1. Introduction
Every day, huge amounts of waste are generated by residential, commercial, and medical sources. Traditionally, the recycling process of this waste material is handled by government organizations, like municipalities, or private organizations. These entities use their resources, such as garbage trucks and employees, to collect waste from various locations, including houses, apartments, medical institutions, industries, etc. However, this process involves a leak of sensitive/personal information of users, such as names, addresses, payment information, and phone numbers. These data are accessible to employees, posing risks such as planned robberies and misuse of waste materials. Loss of materials, unscientific treatment, improper collection of waste, and ethical problems are just a few of the problems that these organizations face. In this case, the user is basically not aware of the whole process of waste management, does not have control over their data, and is unaware of the authenticity of the organization in charge. Such things erode trust between companies and users. Several organizations provide end-to-end waste management services like collection, segregation, transportation, recycling, composting, incineration, landfilling, hazardous waste treatment, regulatory compliance, and record keeping. Here, all the data generated during these processes are stored centrally. This has drawbacks, such as a single point of failure, scalability limitations, performance bottlenecks, data privacy concerns, etc. Moreover, the verification of waste recycling companies is also an issue. Organizational backdoor entries pose a major risk of cheating customers.
The advantages of using blockchain in waste management are transparency, traceability, efficiency, environmental impact, accountability, etc. The pros of the non-fungible token-based approach to waste management are traceability and transparency (including acting as a digital passport for waste, real-time tracking, preventing illegal dumping), incentivizing recycling and sustainable practices (including rewarding eco-conscious behavior, gamification of recycling, funding sustainable initiatives), ensuring ethical practice, fair trade (fair compensation for recyclers, verifying the origin of recycled materials) and environmental impact tracking, improved public engagement and trust, community-driven initiatives, reduced fraud and corruption, and optimized resource allocation.
To address these challenges, we propose Greenlink—a blockchain-based NFT waste management framework that streamlines waste recycling by connecting verified companies and organizations. The NFT tokens are accessible to all authorized stakeholders, and verified organizations are available to carry out the recycling process efficiently and securely. Dynamic trading refers to a real-time or near-real-time process in which an automated bidding system determines the price for a good, service, or advertisement slot. It is commonly used in online advertising, e-commerce, and auction platforms. Dynamic bidding optimizes pricing to reflect real-time market conditions, increases efficiency and ROI, and enhances competitiveness in the marketplace. The Walrasian equilibrium proposed in our model is a state in a market where supply equals demand, and every participant (buyer or seller) maximizes their utility at given prices. This concept is instrumental in dynamic trading systems for the efficient allocation of resources, real-time price discovery, maximizing platform revenue, stability and predictability, and multi-item auctions. By leveraging Walrasian equilibrium principles, dynamic trading systems enhance fairness, efficiency, and market effectiveness. The Walrasian equilibrium approach aims to find a price vector that balances supply and demand in a market. In this waste bidding model, prices are iteratively adjusted based on excess supply or demand until equilibrium is reached. The verification process is carried out using zero-knowledge proofs, which allows companies to be verified without revealing their private information to the administrator who sets the criteria. Zero-knowledge proofs are an efficient technique to minimize the information transferred between the prover and the verifier in a cryptographic protocol. The prover can prove through a cryptographic commitment scheme to another party, termed the verifier, without revealing how it is proven. Zero-knowledge proofs, or ZKPs, are a technique for one party to cryptographically prove to another that they know something about a piece of information without disclosing the underlying information. A ZKP in the context of blockchain networks may only disclose on-chain that a piece of secret information is legitimate and is known by the prover with high certainty. It operates when the verifier urges the prover to conduct activities that can only be completed correctly if the prover is aware of the fundamental information. If the one who proves is guessing about the outcome of these acts, the verifier’s test will almost certainly prove them incorrect with a degree of probability. Zero-knowledge proofs (ZKPs) are defined by key characteristics that make them a powerful, secure, and private verification tool. Accuracy ensures that a reliable prover can convince an honest verifier that they know the correct input if a claim is true. Stability guarantees that no unethical prover can deceive the verifier into believing they possess the correct information if the claim is false. Zero expertise means that if the claim is true, the verifier learns nothing more from the prover except that the claim is valid. These features make ZKPs a robust method for proving knowledge without revealing additional information. In interactive ZKPs, the prover and verifier communicate back and forth, allowing the verifier to validate the claim, while in non-interactive ZKPs, the prover generates a proof using an algorithm, which is then validated by another algorithm.
Using lightweight protocols like Mina and Polygon zkEVM greatly benefits GREENLINK, making the platform energy-efficient. The Mina protocol and Polygon zkEVM use lightweight zk-SNAKS and layer-2 blockchain scaling solutions. The design of the Mina protocol architecture is unique. It has proven to use less memory and CPU because the blockchain size is fixed at 22kb, regardless of the number of transactions. This is made possible by storing images instead of all transactions. This also eliminates the need to install huge storage systems for running the blockchains’ nodes and utilizes less power than POW or POS blockchains like Bitcoin. On the other hand, Polygon zkEVM uses the concept of zk-rollups, which follows the approach of winding or rolling multiple transactions into a single form and performing verifications using ZKPs. This approach reduces the computational power and energy costs associated with the transaction process and verification of the data. By performing the transaction computation operation off-chain, which makes the use of smart contracts less and using efficient cryptographic methods, Polygon zkEVM provides high scalability and lower energy consumption options. The performance benchmarks conducted using Hyperledger Caliper ensure that the framework operates efficiently, with low latency, high TPS (transactions per second), and reduced memory consumption translating to less energy use per transaction. By optimizing resource utilization, the framework minimizes its environmental impact during operation.
The proposed framework, Greenlink, includes scalable and efficient features to alleviate the worries about any bottlenecks the system may experience due to its dependence on smart contracts and zero-knowledge proofs using the following features. (A) Use of scalable blockchain infrastructure: For on-chain validation, the proposed framework, Greenlink, uses Polygon zkEVM, which collects data into a single forum and compresses many transactions into a single batch via zk-rollups. This preserves the system’s integrity and security while significantly lowering the strain on the main blockchain. Thanks to the use of zk-rollups, Greenlink can handle thousands of transactions per second (TPS), which makes it capable of handling large user traffic and performing operations even during heavy workloads. (B) The Mina protocol’s lightweight architecture: The 22 KB size of the Mina blockchain makes it highly efficient in handling the application’s memory usage compared to any other blockchain. The architecture guarantees that the system maintains effectiveness even with increased user demand. (C) Optimization of smart contracts: To reduce computing complexity and gas costs, the proposed framework’s smart contracts are designed to only use essential information required for a successful waste management process. The framework minimizes the risk of network congestion and maximizes the execution time by using the latest technologies. (D) Event-driven execution: Due to their event-driven nature, smart contracts save needless computing costs by only operating when certain criteria are satisfied. (E) Enhancements in zero-knowledge proofs (ZKPs): The proposed framework, Greenlink, makes sure that—even with high user loads—the ZKP process does not create a bottleneck by optimizing the timings for ZKP production and verification. Our approach aggregates and verifies ZKPs for several transactions together, significantly lowering the computational cost of the verification process. (F) Layer-2 integration: By enabling off-chain processing for most processes, layer-2 solutions, such as Polygon zkEVM, lessen dependency on the layer-1 blockchain and prevent congestion. (G) Performance benchmarking: Using Hyperledger Caliper, Greenlink tests metrics, including average latency, TPS, and memory usage, under simulated high loads to assess its performance. This guarantees that the system is highly scalable and offers information about any bottlenecks for future enhancements.
The organization of the paper is as follows:
Section 1 provides the introduction;
Section 2 includes a review of the literature;
Section 3 discusses blockchain-enabled NFT frameworks with zero-Knowledge proof (ZKP)-based verification for waste management;
Section 4 discusses their implementation and the results; and
Section 5 provides the conclusion.
2. Literature Review
This section reviews the latest work in different areas of non-fungible tokens and works, including OpenZeppelin in blockchain technology, zero-knowledge proofs (ZKPs), and the Mina protocol, which relates to the topic of waste management in some way, either directly or indirectly. Researchers worldwide have used these concepts in various areas such as waste management, supply chain management, healthcare, drug traceability, etc. This section briefly describes the research, diving into broader areas such as trading approach, traceability systems, NFT-based artworks, security, and auction methodology. The role of OpenZeppelin contracts is to define the NFTs’ buy, sell, and minting functionalities.
ZKP and blockchain technology have the potential to completely transform the waste management industry and the way the entire process is managed. In [
1], Khiem et al. proposed an innovative solution for medical waste management, integrating blockchain, smart contracts, and NFTs. In [
2,
3], Bulkowska et al. and Jiang et al. discussed and implemented blockchain in waste management. In [
4], Tian et al. discussed post-carbon footprint analysis in the art market, and in [
5], Mielcarek et al. showcased water nutrient management. In [
6], Chiacchio et al. discussed NFTs in the pharmaceutical sector, while in [
7], Chiquito et al. discussed waste management in aquaculture, and in [
8], Rayes et al. proposed a plastic waste management model. Triet et al. proposed a framework in [
9] that combined blockchain with circular economy principles to improve construction waste management. In [
10], Ahmed et al. developed a framework to examine Blockchain’s potential to enhance waste management in smart cities and discussed security. In [
11], Yuan et al. proposed an IoT-based solid waste management system for developing countries, utilizing blockchain-enabled VANETS, UHF technology, and geo-fencing for real-time tracking and communication. Steenmans et al., in [
12], examined blockchain’s role in plastic waste management, identifying key areas like payment, recycling rewards, waste tracking, and smart contracts.
Blockchain technology offers promising benefits to supply chain management by enhancing transparency, security, and efficiency through its decentralization feature and immutable ledger technology, which eliminates reliance on third-party dependencies. In [
13], Farsi et al. examined blockchain-based supply chain systems, highlighting their benefits and key requirements while identifying potential cyber threats and security challenges. Soori et al., in [
14], explored how integrating blockchain with IIoT in Industry 4.0 enhances sustainable supply chain management, offering real-time tracking and reduced intermediaries. Aslam et al. proposed a framework for evaluating whether a complex supply chain should adopt blockchain technology in [
15]. They empirically analyzed the supply chain practices of Pakistan’s oil industry and their impact on operational performance. In [
16,
17], Dietrich et al. and Duan et al. reviewed the most recent publications on blockchain in supply chain management, classifying them by complexity. They found that most blockchain projects focus on simple supply chains, with no examples yet addressing transparency and audibility in complex manufacturing supply chains. In [
18,
19], Dudczyk et al. and Marin et al. discussed blockchain platforms in global supply chain management and distributed technology, their industry applications, and existing solutions.
The adoption of blockchain technology in emerging trading and auctions seems promising and can help enhance efficiency, reduce scams, and form trust between trading parties. Mariia Rodinko et al., in [
20], proposed upgrading existing cryptocurrencies to new tokens without relying on external information sources to avoid KYC, ensuring a predicted supply and fair pricing based on decentralized auction simulations. In [
21], Cui et al. proposed a novel competition padding auction mechanism for peer-to-peer energy trading among renewable prosumers, addressing the budget deficit issue. In [
22], Kadadha et al. proposed AB Crowd, a fully decentralized crowdsourcing framework using the Ethereum blockchain and the repeated single-minded bidder auction mechanism. In [
23], Agarwal et al. explored a decentralized blockchain-based double auction mechanism for energy trading in a smart microgrid, allowing prosumers to sell surplus energy to consumers. In [
24], Liu et al. addressed computation offloading in mobile blockchain networks by proposing a smart contract-based double auction mechanism.
In [
25], Yang et al. proposed a blockchain-based digital identity management system using smart contracts, ZKPs, and a BZDIMS prototype for enhanced privacy. Wali et al., in [
26], discussed secure vehicle data management using blockchain and ZKPs. In [
27], Soewito et al. study combined AES and ZKPs for authentication, improving data transmission security and reducing authentication processing time. In [
28], Diro et al. discussed identity sharing with ZKPs and blockchain for secure identity sharing, addressing vulnerabilities. In [
29], Kuznetsov et al. proposed an innovative aggregation scheme for ZKPs within Merkle trees to enhance data verification efficiency in blockchain systems. Experimental results show significant reductions in proof size and computational requirements, offering a scalable and secure solution for various applications. In [
30], Xiao Xu et al. explored using blockchain-powered zero-knowledge proofs to create a privacy-preserving disability management system that enhances inclusivity.
The current paper proposes a model that integrates technologies like zero-knowledge proofs (ZKPs), blockchain, and the Mina protocol (a lightweight blockchain that only stores the image of a blockchain) to efficiently handle waste management using a novel dynamic or repeated bidding using Walrasian equilibrium for iterative price adjustments to sell waste and allot private organizations that are verified and genuine. After the ZKP-based verification method, private organizations can participate in the auction process to purchase waste from individuals or organizations in the NFT marketplace. Digital assets are stored via decentralized storage, i.e., NFT.storage, which is is a specialized service that provides decentralized functionalities for non-fungible tokens. We have used its API endpoint to successfully store the tokens in its storage. The Coinbase Wallet SDK enables users to connect to Greenlink through the Coinbase Wallet. The Web3Modal library makes connecting decentralized applications to different cryptocurrency wallets simple. The benchmarking tool—Hyperledger Caliper is used to calculate the throughput and efficiency of the entire platform (
Table 1).
3. Blockchain-Enabled NFT Framework
Waste management is a process and a set of actions that are required to manage waste, starting from its generation to its final disposal. Effective waste management helps reduce waste generation, increase recycling and reuse, minimize environmental impacts (e.g., pollution, climate change), protect public health and safety, and conserve natural resources. NFTs are paving the way to effectively help in waste management in the following ways: tracking and verification, waste ownership and responsibility, incentivizing recycling, supply chain optimization, carbon credit verification, digital twins for waste management, education and awareness, and decentralized waste management. The NFT blockchain-based waste management trading framework uses decentralized technology to improve waste buying, selling, and ownership. This framework ensures the organization’s verification using the zero-knowledge proof (ZKP) method. Provides secure, transparent transactions, reduces the risk of fraud, and enables seamless ownership transfers using smart contracts. The immutable nature of blockchain records each transaction, providing verifiable provenance for NFTs. The framework also provides an auction-based mechanism for purchasing goods by verified organizations, and financial transactions are stored securely on the blockchain.
3.1. Proposed Mathematical Model
To model a bidding process in which organizations and users purchase waste from companies, we can create a mathematical model involving the following components (
Table 2):
Assumption 1. 1. The allocation of waste quantity cannot exceed the available supply or budgetary limits.
2. Each organization maximizes its utility while each company maximizes its revenue.
3. Prices are determined based on bidding values and reserve prices.
Objective Functions:
- 1.
Company Objective: Maximize total revenue:
- 2.
Organization/User Objective: Maximize total utility:
The constraints of the mathematical model are as follows.
- 1.
Quantity Constraint for Companies:
- 2.
Budget Constraint for Organizations/Users:
- 3.
- 4.
Assuming that the problem involves dynamic or repeated bidding, iteratively adjust prices and allocations to clear the market (i.e., supply equals demand). The Walrasian equilibrium approach seeks a price vector that balances supply and demand in a market. We iteratively adjust prices based on excess demand or supply for this waste bidding model until equilibrium is achieved.
3.2. Mathematical Modelling of the Dynamic Bidding Using Walrasian Equilibrium
- 1.
Initialization: Set an initial price vector
where
is the price for each pair for company-buyer
.
- 2.
Excess Demand Calculation: At each iteration
t, compute the excess demand for each company
i based on the current price
:
where
is the demand from buyer j for waste from company i
, computed as follows:
subject to
- 3.
Price Adjustment: Update prices iteratively based on excess demand
where
is a step size controlling the rate of price adjustment.
- 4.
Stopping Criterion: Continue iterations until
where
is a small threshold indicating equilibrium (i.e., supply equals demand).
- 5.
Final allocation: Once equilibrium prices
are found, allocate waste quantities:
At equilibrium: Prices: equilibrium prices
and Quantities
satisfy
(Supply equals demand for each company).
3.3. Proposed Framework/Approach—Greenlink
We have proposed a blockchain-based approach for waste management called Greenlink. Greenlink exclusively facilitates waste recycling among verified companies and organizations. Using the zero-knowledge proof method; we ensure the authenticity of the participants. Recyclable waste is auctioned off to interested organizations. The highest bidder purchases the waste, which is then sold through our marketplace. The proposed framework uses the Mina protocol, a lightweight blockchain, as it stores only the image of the blockchain. The architecture of the proposed model is shown in
Figure 1.
The functionality of the proposed framework—Greenlink—is divided into two parts. The primary functionality is to help people recycle their waste safely and securely through the use of the decentralized marketplace, where users can upload detailed information about waste, such as category, weight, address, etc. The other functionality is to let only valid waste management organizations participate in the decentralized marketplace. Organizations are verified using the zero-knowledge proof (ZKP) method. The proposed marketplace facilitates the sale of recyclable waste with auctions, ensuring competitive pricing and secure transactions for verified participants. The NFT tokens are accessible to all authorized stakeholders, and verified organizations will be available to carry out the recycling process efficiently and securely. Polygon zkEVM provides a scalable environment in which the EVM compatibility and zk-rollups are grouped for the efficient running of smart contracts with Ethereum. A cryptographic primitive known as zero-knowledge proof (ZKP) is used by the Polygon zkEVM for validating the state transitions. It scales up Ethereum. Transaction confirmations are quicker, and the fees are lower when compared to Ethereum MainNet, which helps design complex blockchain applications.
3.4. Proposed Framework’s Algorithms
In our currently developed model, NFT token trading operations were implemented using smart contracts. The following algorithms were developed and used in our framework.
Algorithm 1 shows the minting operation of waste materials and its listing in NFT marketplace.
Algorithm 2 shows the creation of a market item.
Algorithm 3 reflects the transfer of ownership of items and funds between parties.
Algorithm 4 depicts the fetching of unsold market items.
Algorithm 5 shows the fetching operation of items the user has purchased.
Algorithm 6 shows the process of zero-knowledge proof.
Algorithm 7 shows dynamic or repetitive bidding using the Walrasian equilibrium approach.
Algorithm 1 Minting waste and listing in marketplace |
- 1:
function createToken(tokenURI (String), price (Integer)) Integer - 2:
Increment the token ID counter: - 3:
_tokenIds.increment() - 4:
Get the current token ID and assign it to newTokenId: - 5:
newTokenId = _tokenIds.current() - 6:
Mint a new token to the sender with the new token ID: - 7:
_mint(msg.sender, newTokenId) - 8:
Set the token URI for the new token ID to the provided tokenURI: - 9:
_setTokenURI(newTokenId, tokenURI) - 10:
Create a market item with the new token ID and the provided price: - 11:
createMarketItem(newTokenId, price) - 12:
Return the new token ID: - 13:
return newTokenId - 14:
end function
|
Algorithm 2 Creating a market item |
- 1:
function createMarketItem(tokenId: Integer, price: Integer) - 2:
if price < 0 then - 3:
Raise error “Price must be at least 0 wei” - 4:
end if - 5:
newMarketItem ← Create MarketItem with: - 6:
tokenId = tokenId - 7:
seller = sender’s address - 8:
owner = contract’s address - 9:
price = price - 10:
sold = false - 11:
idToMarketItem[tokenId] ← newMarketItem - 12:
end function
|
Algorithm 3 Transferring ownership of the item, as well as funds between parties |
- 1:
function createMarketSale(tokenId) - 2:
idToMarketItem[tokenId].price - 3:
idToMarketItem[tokenId].seller - 4:
if then - 5:
Raise error “Please submit the asking price to complete the purchase.” - 6:
end if - 7:
idToMarketItem[tokenId].owner ← sender’s address - 8:
idToMarketItem[tokenId].recycled ← true - 9:
idToMarketItem[tokenId].seller ← null address - 10:
Increment the itemsRecycled counter - 11:
Transfer the token from contract’s address to sender’s address - 12:
Transfer the payment to the seller - 13:
end function
|
Algorithm 4 Fetching all unsold market items |
- 1:
function
fetchMarketItems - 2:
return array of MarketItem - 3:
current value of _tokenIds - 4:
current value of _tokenIds - current value of _itemsRecycled - 5:
- 6:
Create a new array of type MarketItem with length - 7:
for i from 0 to do - 8:
if owner of is equal to contract’s address then - 9:
- 10:
- 11:
- 12:
- 13:
end if - 14:
end for - 15:
return - 16:
end function
|
Algorithm 5 Fetching items that a user has purchased |
- 1:
function
fetchMyNFTs - 2:
Returns array of MarketItem - 3:
current value of - 4:
- 5:
- 6:
for to do - 7:
if owner of is equal to sender’s address then - 8:
- 9:
end if - 10:
end for - 11:
Create a new array of type MarketItem with length - 12:
for to do - 13:
if owner of is equal to sender’s address then - 14:
- 15:
- 16:
- 17:
- 18:
end if - 19:
end for - 20:
return - 21:
end function
|
Algorithm 6 Zero-knowledge proof |
- 1:
Struct Report: OrgID, validUntil, RedeableAmt, hasCondA, hasCondB, hasCondC - 2:
Struct Requirements: OrgID, verifyTime, minRedeableAmt, maxRedeableAmt, allowCondA, allowCondB, allowCondC - 3:
- 4:
function hashReport(report, reqToCheck) - 5:
return hash(report.OrgID, report.validUntil, report.RedeableAmt, - 6:
report.hasCondA, report.hasCondB, report.hasCondC, - 7:
reqToCheck.OrgID, reqToCheck.verifyTime, - 8:
reqToCheck.minRedeableAmt, reqToCheck.maxRedeableAmt, - 9:
reqToCheck.allowCondA, reqToCheck.allowCondB, - 10:
reqToCheck.allowCondC) - 11:
end function - 12:
- 13:
procedure VERIFYORGANIZATION(report, reqToCheck) - 14:
Step 1: Verify OrgID - 15:
Assert report.OrgID == reqToCheck.OrgID - 16:
Step 2: Verify validUntil - 17:
Assert currentTime ≤ report.validUntil - 18:
Assert reqToCheck.verifyTime ≤ report.validUntil - 19:
Step 3: Verify RedeableAmt - 20:
Assert report.RedeableAmt ≥ reqToCheck.minRedeableAmt - 21:
Assert report.RedeableAmt ≤ reqToCheck.maxRedeableAmt - 22:
Step 4: Verify Conditions - 23:
if reqToCheck.allowCondA then - 24:
Assert report.hasCondA == TRUE - 25:
end if - 26:
if reqToCheck.allowCondB then - 27:
Assert report.hasCondB == TRUE - 28:
end if - 29:
if reqToCheck.allowCondC then - 30:
Assert report.hasCondC == TRUE - 31:
end if - 32:
Step 5: Generate Verification Hash - 33:
verificationHash = hashReport(report, reqToCheck) - 34:
Step 6: Store Verification Status - 35:
State.verifiedReqHash[verificationHash] = TRUE - 36:
return verificationHash - 37:
end procedure
|
The description of the algorithms developed in our framework is given below:
Algorithm 1 is about minting waste and listing it in the marketplace. It creates a token and returns the token ID and the price. Based on this, the createMarketItem function is called upon, as discussed in Algorithm 2.
Algorithm 2 creates a market item with the following information: tokenID, sender’s address, contract’s address, and price.
Algorithm 3 transfers ownership of the item as well as funds between the parties. This function, named createmarketSale, stores the sender’s address and transfers the token from the contract’s address to the sender’s address. It transfers the payment to the seller.
Algorithm 4 fetches the unsold marketItems function and keeps track of the unsold items in the marketplace. Here, if the owner of the marketItem is equal to the contract’s address, then the counter is increased, and the item is fetched based on the ID.
Algorithm 5 fetches the items that the user has purchased. Here, if the owner of the marketItem is verified with the sender’s address, then the item is fetched.
Algorithm 6 shows the zero-knowledge proof (ZKP) algorithm.
Algorithm 7 Dynamic or repetative bidding using Walrasian equilibrium. |
function AUCTION Input: N = Number of companies and M = Number of buyers = Supply for each company = Budgets for each buyer = Reserve prices for each company = Utility function for buyer j = Step size for price adjustment and = Convergence threshold = Maximum number of iterations
Output: = Final price matrix and = Final allocation matrix Steps:
Step 1: Initialization
Initialize price matrix with reserve prices :
Initialize iteration counter:
Initialize excess demand (size N)
Step 2: Iterative Adjustment
Repeat until convergence or maximum iterations:
- 1.
Compute demand for each buyer j and company i: - 2.
Calculate excess demand for each company i: - 3.
Update prices for all i, j: - 4.
- 5.
Increment iteration counter:
Step 3: Final Allocation
For each :
For each :
Step 4: Output Results Return final price matrix and allocation matrix end function |
The verification process is carried out using the process of zero-knowledge proofs, which allows companies to be verified without revealing their private information to administrators, who set the criteria. Zero-knowledge proofs are an efficient technique to minimize the amount of information transferred between the prover and the verifier in a cryptographic protocol. The ZKP algorithm has a struct report with the following fields: OrgID (organization ID), valid until (expiry or validation time), RedeableAmt (redeemable amount), hasCondA, hasCondB, hasCondC (conditions or flags for additional constraints). The constraints are as follows: OrgID (organization ID to check against), verifyTime (time of verification), minRedeableAmt and maxRedeableAmt (limits on the redeemable amount), and allowCondA, allowCondB, allowCondC (allowed conditions for flexibility in validation).
Functions: hashReport(report: Report): Computes a hash value based on the contents of a report. The hash serves as an immutable, verifiable representation of the report.
VERIFYORGANIZATION (report: Report, reqToCheck: Requirements): Validates whether a report satisfies a set of requirements using a zero-knowledge proof approach.
Validates the report using the requirements by:
- 1.
Asserting conditions like matching OrgID (OrgID field in the report matches the OrgID specified in the requirements (reqToCheck)), validUntil time constraints (ensures that the report is not expired and is valid for the requested verification period), and redeemable amount ranges (ensures that only reports with an acceptable amount of redeemable value are validated).
- 2.
Three conditional checks verify whether the specific conditions in the report align with the allowable conditions in the requirements (hasCondA, hasCondB, hasCondC). This ensures that any extra conditions required for validation (e.g., specific certifications, flags) are satisfied.
- 3.
Computing a final verification hash of both the report and the requirements. The hash acts as a unique proof of verification, encapsulating all the validated constraints without exposing the raw data. This is critical for privacy in a zero-knowledge proof system.
- 4.
Storing the hash in State.verifiedReqHash to mark the request as verified.
In Algorithm 7, the verified organizations participate in the auction process. In our framework, a Walrasian equilibrium is used for iterative price adjustments in dynamic bidding within an auction-based waste trading system. The algorithm is given here.
4. Implementation and Result Discussion
4.1. Implementation
The utilization of zkEVM blockchain technology has enabled the process of waste management and the involvement of private organizations in recycling the waste generated, while prioritizing security measures. The proposed architectural framework is developed through the use of zkEVM, Node.Js, Ether.Js, Web3Modal, Wallet Connect SDK, and NFT.storage API endpoints. The development of decentralized applications requires the implementation of Ethereum, a secure, open-source, scalable, and programmable blockchain platform that offers smart contract development functionalities. The designed and implemented Greenlink framework represents the process of user-generated waste management by verified companies through NFTs. It also adds a layer of security by keeping users, administrators (who set criteria), and organizational identities private. This framework has the potential to introduce a new way of waste management, where trust and privacy are backed up by auction-based NFT trading.
The integration of the various tools and technologies used and their integration within our proposed framework is listed here:
- 1.
Ether.js: Interacts with the Ethereum blockchain. It also provides functionalities to manage wallets, handle transactions, etc.
- 2.
zkEVM: The proposed architectural framework is developed using zkEVM. It facilitates cost-effectiveness and scalability in blockchain transactions and enhances waste management operations. Quicker transaction processing is facilitated by the duo zero-knowledge rollups (zk-rollups) and the Ethereum Virtual Machine (EVM), ensuring lower fees and that security is also not compromised. The zk-rollups further help in waste management transaction confirmation. The zkEVM and EVM efficiently handle dynamic bidding and NFT issuance for waste-tracking operations.
- 3.
Wallet Connect allows decentralized applications to connect and interact with cryptocurrency wallets securely.
- 4.
Web3Modal is a library that makes connecting decentralized applications to different cryptocurrency wallets simple.
- 5.
NFT.storage: The decentralized storage functionalities for NFT metadata are provided by the NFT’s highly dependable storage service. It also helps in tamper-proof record storage for waste management (like origin and recycling history). This enables the stakeholders to confirm the waste sources (i.e., traceability) and the process of recycling. NFT.storage is a specialized service designed to provide decentralized storage functionalities for non-fungible tokens. This also makes for very cost-effective data management.
- 6.
Coinbase Wallet SDK enables users to connect the Coinbase Wallet to Greenlink.
- 7.
Hyperledger Caliper is a performance evaluation benchmarking tool.
For deployment on the blockchain, the address of the current model’s contract owner is used. The private key is given in checksum form. To access and use it, the user can mint the token. The Ethereum nodes hold the private key. In the caliper, the signed transactions and the data are sent to the node when the private key is available for the address of the model’s contract owner.The address of the benchmark invokes the methods in the contract. The network_config file accesses the from_address and its private_key with a password to invoke the methods in the caliper benchmark.
The caliper adapter hosts the successful transactions over the network along with the block count. The JSON object is given by the config_list to be deployed on the network prior to executing the caliper benchmark. JSON entries for the createMarketItem, createMarketSale, createToken, fetchItemListed smart contracts of our model are specified, and this enables the invocation of the methods on the contracts.
4.2. Result Discussion
The proposed NFT marketplace model’s performance is evaluated using the Hyperledger Caliper, and the Polygon blockchain is used over Ethereum network. The OS is Ubuntu 18.04. The various tools are listed in
Table 3.
Performance metrics like the speed of transactions, tokenization (which ensures precision and reliability), and consumption of resources (CPU and memory usage) are monitored. These are evaluated based on the transaction rates for the network’s scalability and efficiency measurement. This helps us to evaluate and assess the real-world performance of our proposed model.
The benchmarking of each step is performed by providing an input size (load) of around 5000 transactions.
Table 4 shows the overall performance of the proposed model by Hyperledger Caliper, which reflects the fact that every transaction was successfully performed over the Ethereum network. This table shows the send rate, latency, and throughput of the proposed model’s four essential smart contracts.
The current model’s performance is tested with a total transaction count of 5000. The input transaction rates are 1000, 2000, 3000, 4000, and 5000 per second. The CreateMarketItem, createMarketSale, createToken, and fetchItemListed functions’ performance is noted. The number of workers varied from 1–5. A total of 15 evaluation runs were conducted (i.e., for workers 1–5 for every transaction rate, i.e., 1000, 2000, 3000, 4000, and 5000 per second). The performance data are summarized in
Table 4 and
Table 5. The various performance metrics like latency, throughput, memory usage, CPU usage, traffic in/out, and disk read/write are plotted in the graphs in the results subsection. The utilization of resources like CPU, memory, throughput, and traffic flowing in and out are shown in
Table 5.
Table 5 represents the analysis of the latency for operations like createMarketItem, createMArketSale, createToken, and fetchItemListed, respectively. These functions were measured at 1000, 2000, 3000, 4000, and 5000 transactions per second (TPS), respectively. The latency details in
Table 4 are plotted in
Figure 2a, which reveals that average latency is relatively high for the CreateToken function (deep blue color), whereas it is lower for the createMarketItem function (light blue color). Another trend also reveals that as the send rate (transactions per second) increases, the average latency gradually decreases. The average latency reaches 8.71 s when the workers are set at 3. The average latency reaches a maximum of 8.76 s when the no. of workers = 4 for the CreateMarketItem function. Similarly, the average latency ranges from a maximum of 10.37 s to a minimum of 9.84 s. The createToken function’s average latency range ranges from a minimum of 10.89 s to a maximum of 11.05 s. For the function fetchItemListed, the maximum average latency is 10.51 s and the minimum is 10.07 s.
The graph in
Figure 2b shows the throughput for createMarketItem, createMArketSale, createToken, and fetchItemListed, respectively, when the transaction per second is varied from 1000 to 5000, as shown in
Table 4. In
Figure 2b, the createToken function has a lower throughput compared to the other three tokens (deep red color in Figure), and the createMarketItem has the highest throughput (light blue color) of all the functions for all the rates of transactions (1000 to 5000). The graphs in
Figure 2a,b have been drawn with different color codes to differentiate the four functions, and they are grouped together for each of the transaction rates 1000–5000 TPS, respectively.
Figure 3a shows the graph of the memory utilization in MB versus the send rate (1000–5000 TPS) of the createMarketItem function. The graph shows that the maximum memory utilization is 791 MB when the send rate is 1000 TPS, and it is 988 MB when the send rate is 5000 TPS. For the createMarketSale function,
Figure 3b shows the maximum memory utilization is 989 MB when the send rate is 1000 TPS, and it is 991 MB when the send rate is 5000 TPS. For the createToken function, as shown in
Figure 3c, the maximum memory utilization is 22.0 MB when the send rate is 1000 TPS, and it is at 24.0 MB when the send rate is 5000 TPS. In the fetchItemListed function, the graph in
Figure 3d shows the maximum memory utilization is 22.8 MB when the send rate is 1000 TPS, and it is 23.5 MB when the send rate is 5000 TPS. The maximum memory consumption for the createToken and fetchItemListed functions is low for all the transaction rates in the range of 1000–5000 TPS (22.0 MB to 24.0 MB for both functions).
Figure 4a shows the graph of the CPU utilization in % versus the send rate (1000–5000 TPS). For the createMarketItem function, the graph shows that the maximum CPU utilization ranges from 90.90% (4000 TPS) up to 93.95% (1000 TPS). For the createMarketSale function,
Figure 4b shows the maximum memory utilization is in the range of 26.58% (2000 TPS) up to 29.98% (5000 TPS). For the function createToken,
Figure 4c shows the maximum memory utilization ranges from 28.0% (1000 TPS) up to 29.8% (5000 TPS). For the fetchItemListed function,
Figure 4d shows the maximum memory utilization ranges from 23.2% (1000 TPS) up to 28.4% (5000 TPS). In summary, the memory utilization function is highest for createMarketItem, within the range of 90.9–93.9%. However, for the other three functions—createMarketSale, createToken, and fetchItemListed—the CPU utilization is low, within the range of 25.7–29.9%.
The memory utilization graph shown in
Figure 3 shows that for the createMarketItem and createMarketSale functions, memory utilization remains high as the send rate increases. Both maximum and average memory utilization are within the range of 800–1000 MB, indicating that this function is resource-intensive and incurs significant processing tasks. The createToken and fetchItemListed functions have much lower memory usage, with a maximum memory of 25 MB and an average memory of 5 MB, which indicates efficiency in creating tokens with low resource demand, as token creation and tracking waste units is a lighter task. The CPU utilization graph, as shown in
Figure 4, depicts that for the createMarketItem function, the maximum CPU utilization percentage is high, nearing 90–100%, regardless of the send rate. Average CPU consumption is significantly lower at around 40–50%, which indicates that creating market items for NFTs is CPU-intensive, as it handles complex processes like minting NFTs for waste management and recording metadata. However, the load cannotbe sustained continuously. The CPU utilization of the createMarketSale and createToken functions shows that the minimum CPU consumption is around 25–30%, with an average CPU utilization % below 10%, which suggests that facilitating market sales of NFTs is less CPU-demanding compared to the createMarketItem function. In addition, the creation of tokens (representing unique identifiers for waste items) appears to be lightweight, requiring relatively few CPU resources, while the fetchItemListed function also requires minimal CPU resources; this makes the system efficient in token generation and retrieving data, which is critical for large-scale waste management scenarios. The proposed model design is scalable, and this is shown by the fact that, for all the function designs, CPU utilization and memory consumption remain consistent across the send rates, which is vital for blockchain-based waste management systems as the volume of transactions increases. The memory utilization and CPU utilization graphs for the the createMarketItem function show high resource utilization, as the MarketItem is likely a struct with multiple fields and, as we assign a new MarketItem to the mapping, it consumes memory (storage) for each of these fields. The id-market item is a key value pair in the mapping and requires additional storage. The storage consumption increases significantly as the mapping grows with more entries. Payable addresses, like payable(msg.sender) and payable(address(this)), are stored in the struct, called MarketItem, which adds additional data to the structure, increasing memory usage. For many token listings, if this function is called multiple times, the storage usage increases.
As a result of the above-mentioned processing, it impacts scalability by gas cost, throughput reduction, and network congestion. Hence, off-chain data storage, sharding, and lazy minting will be preferred in our future work.
5. Conclusions
In this article, we have proposed a blockchain-enabled non-fungible token and dynamic bidding using a Walrasian equilibrium to achieve iterative price adjustments for sustainable waste management. We used the ZKP validity mechanism, an innovative framework based on NFTs that facilitates the minting of waste and listing it in the marketplace, as well as the creation of the market item, transferring ownership of funds and items between parties, fetching NFTs, and returning items listed by users. With a seamless interaction, an elegant GUI was developed, with the features of reliability, transparency, and security. Additionally, we conducted a comparative analysis, evaluating performance using the Hyperledger Caliper tool, examining transaction rates, and analyzing the resulting metrics. Analysis of the latency and throughput was performed for the token operations—CreateMarketItem, createMarketSale, createToken, and fetchItemListed. A detailed performance evaluation of our built model was also conducted based on the maximum and minimum CPU utilization, memory utilization, and traffic in/out of each of the token operations (CreateMarketItem, createMarketSale, createToken, fetchItemListed) for each of the send rates from 1000 TPS to 5000 TPS. The results are plotted, proving the efficacy of the current proposed model. The results show that the maximum average latencies of CreateMarketItem, createMarketSale, createToken, and fetchItemListed are 8.76 s, 10.37 s, 11.09 s, and 10.51 s, respectively, and the minimum average latencies are 8.71 s, 9.84 s, 10.89 s, and 10.51 s, respectively. Average latency is relatively high for the CreateToken function, whereas it is lower for the createMarketItem function. Another trend also reveals that as the send rate (transactions per second) increases, the average latency comes down gradually. createMarketItem has the highest throughput, averaging at 251.5 s, and the createToken function has the lowest throughput, averaging at 32.5 s. The average memory consumption of createMarketItem and createMarketSale lies within the range of 772–872 MB for the range of TPS from 1000 to 5000. The average memory consumption of createToken and fetchItemListed lies within the range of 4.6 MB to 5.01 MB for the range of TPS from 1000 to 5000. The traffic in lies within the range of 9.93 to 13.01 and the traffic out ranges from 28.1 MB to 32.6 MB for all the four tokens analyzed. The % maximum CPU utilization of the four functions lies in the range of 23.2 MB to 29.9 MB for the three functions createMarketSale, createToken, and fetchItemListed, and for the createMarketItem, it is 92.95 MB. This is a new dimension in the performance aspect of non-fungible token-enabled sustainable waste management approaches using the zero-knowledge proof (ZKP) validity mechanism. Sustainable waste management is very important, and the advantages of the NFT technology of blockchain, which has also been integrated with the based verification of parties method, have paved the way for a unique dimension in this arena. This promises to bring new developments in waste management and asset ownership through NFTs with the advantages of blockchain.
The limitations of the proposed research would be in providing the participants with real-time data on the environmental impact of their contributions, such as the amount of CO2 saved or resources recycled. This gives a sense of purpose and also motivates further engagement. Another limitation would be the dynamic adjustment of resource allocation using a load balancer based on real-time network activity, which ensures smooth operation during peak loads. Future work for this research should aim to expand the Greenlink framework’s applicability to adjacent domains, like supply chain management, recycling, and carbon trading, to demonstrate its versatility and further validate its utility. Another ongoing work will aim to developa dynamic load balancer for dynamically adjusting the resource allocation.
Assumption 2. The allocation of the waste quantity cannot exceed available supply or budgetary limits. Each organization maximizes its utility, while each company maximizes its revenue. Prices are determined based on bidding values and reserve prices.