The project is aimed at designing a blockchain application for waste tracking. We decided to rely on the Ethereum environment to track the amount of waste collected, who produced it, who collected it and how it is managed by the disposal stations. In this way, the application that we have envisioned would help in reducing the number of ecological crimes related to waste treatment.
Even though industrial waste is a central issue in this context, this application focuses on citizens’ private waste production. In this first and basic implementation, the whole project is developed to suit the door-to-door waste collection. In this regard, the trade-off was whether to design a blockchain application for shared waste bins or to focus on individual residents’ collection.
In the end, we opted for the second alternative due to some of its features. Indeed, considering a door-to-door waste collection system makes it easier to clearly identify the waste producers and to design a straightforward mechanism for the functioning of the waste collection process. In fact, it is possible to employ a check on almost every rubbish bag, which helps in weighting and inspecting what has been produced. Nonetheless, an initial and not-refined prototype of a smart contract dealing with the case of shared waste bins can be found in the GitHub repository (old_code/rubbishBlockchain.sol).
Given our idea, it is important to underline that the code stored in this repository clearly needs some improvements, both in terms of real-life adjustment and programmability.
Concerning time matters, the rubbish blockchain is designed to work on a yearly basis: the Municipality deploys the smart contracts at the beginning of each year, and then destroys them at the end of each year. In this way, it is possible to greatly reduce data storage problems, since, for example, there would be no need to keep updating the state variables year after year.
There are four main actors involved in the waste chain: citizens, trucks, stations and the municipality.
-
Municipality: central authority
In the final smart contracts, i.e.contracts/agents.solandcontracts/trashlife.sol, the Municipality plays the role of the central authority controlling the creation and deletion of the agents from the chain. In our first prototype (old_code/GarbageTaxes.sol), it was actually the citizens who had to invoke the smart contracts, so that their personal information would be stored in them. However, this would have required a great effort from citizens, and would have also increased the risk of unfair behavious. As a result, after discussing this topic, we realized that taking the point of view of the Municipality rather than the one of the single citizens would be a better approach, and we thus developed a sketch of the new contract, i.e.old_code/MunicipalityWasteTaxes.sol, on the basis of this idea.
At this point, what we still missing from the smart contract was the incorporation of the exclusive ability of the Municipality to assign roles to the different agents taking part in the waste chain. We indeed wanted the Municipality to be the only actor able to assign the "role" of citizen, truck or station to given Ethereum addresses, and to then include new citizens, trucks and stations in the blockchain. Bothold_code/MunicipalityWasteTaxesRBAC.solandold_code/rubbishBlockchain.solinclude this new functionality. In particular, the former uses the OpenZeppelin libraryRoles.solfor this purpose, while the latter relies on mappings. In our final implementation, i.e.contracts/agents.sol, we decided to use mappings instead of the library provided by OpenZeppelin. -
Waste productors: citizens generating waste
Each citizen has two bins (one for recyclable waste, and one for non-recyclable) with a barcode storing their name and a public Ethereum address. At the beginning, we thought about incorporating such information in each rubbish bag. However, since we then decided to focus on a door-to-door waste collection system instead of relying on shared waste bins, placing the barcodes on the bins instead that on the single bags appeared as the easiest and least expensive solution that would still ensure the trackability of waste. Once citizens have produced some trash bags, they throw them in their personal bins, and then place the bins outside of their houses, waiting for the trucks to come and collect the generated waste.
Waste productors are represented in the blockchain with a structure, and the collection of all citizens is then stored in a mapping, which maps a citizens’ Ethereum address to its structure. The structure contains the citizen’s full name (this could be substituted with the citizen’s fiscal code), the number of household members, the size of the house, the total weight of waste produced in the previous year, the amount of TARI due, a variable signalling whether the citizen has already paid the TARI or not, and the total weight of recyclable and non-recyclable waste produced by the citizen during the year. We believe these are the minimum variables needed to ensure both the trackability of waste and a fair tax-incentive mechanism, without incurring in scalability issues. Indeed, since the structs are saved in the blockchain and the Municipality is the only actor allowed to modify their content, citizens are not able to modify the amount and type of waste they have produced (which determines the reimbursement that are going to get at the end of the year), the amount of TARI they have to pay and whether they have already paid it or not. Moreover, the “role” of citizen can only be assigned by the municipality, a factor which prevents citizens from creating multiple and fake accounts or performing other unfair behaviours. -
Waste collectors: collect waste using garbage trucks
The garbage collection is organized according to a schedule provided by the Municipality, such that recyclable and non-recyclable waste is collected on different days. Therefore, during “recyclable days”, the trucks’ drivers appointed to the collection of recyclable waste scan the barcodes of all the bins they find in the streets, weight their content with a scale which is integrated in each truck, and invoke the “pick( )” function to register the information of the bags on the blockchain. The same happens during “non-recyclable days” with “non-recyclable trucks’ drivers”. In this way, it is possible to keep track of the amount of recyclable and non-recyclable waste produced by each citizen.
It is important to note that the single trash bags are weighted by trucks and not by the individual citizens who produce them, because, besides from being an unnecessary burden for them, citizens would also have the incentive to lie. They would indeed be motivated to declare that their trash bags are lighter than they actually are, or that they contain a type of waste that is recyclable in order to pay less taxes.
Once they have collected all the trash bags in a particular area, the trucks head to the disposal station to dump their content. Before actually dumping their content, trucks need to invoke the “drop( )” function, so that an initial check is performed. The aim of such check is to ensure that the location of a given truck corresponds to the location of a real disposal station, and that type of waste that the truck is carrying is coherent with the type of waste that the station disposes. In particular, the location of each truck is automatically determined by the GPS system that is installed in the truck itself. This GPS system also allows to monitor the route of the truck throughout the day, so that it is possible to verify whether the gargabe collector has actually collected all the bins that were initially assigned to him. As with citizens, garbage collectors are represented in the blockchain with a structure, and the collection of all garbage collectors is then stored in a mapping, which maps a garbage collector’s Ethereum address to its structure. The structure contains the type of waste that a truck’s driver is in charge of collecting, and the total weight of trash that the truck is currently carrying. Moreover, the “role” of truck can only be assigned by the municipality, a factor which prevents unlawful vehicles to act as if they were authorized entities. -
Disposal Station: receive waste
Once verified that a truck has arrived at the appropriate station, the truck dumps its content, and at this point a further check is performed. The station has indeed to verify whether there is coherence between the amount of waste that a truck declares to have collected during the day, and the amount of waste that is actually dumped at the station. This check ensures that no rubbish is lost “on the way”.
Disposal stations are represented in the blockchain with a structure, and the collection of all disposal stations is then stored in a mapping, which maps a station’s Ethereum address to its structure. The structure contains information about the GPS coordinates of the station, the type of waste it disposes and the total amount of weight it has received over time. The Municipality is the only actor who can assign the “role” of station, thus preventing unauthorized entities to act as approved stations.
One important aspect that needs to be taken into account when considering how to manage the numerous trash bags is scalability. Initially, we tried to store all the relevant data regarding all the trash bags in a dedicated struct. This first implementation can be found in old_code/TrashChain.sol. However, we soon realized that we would not be able to store on the blockchain all the data relative to every single trash bag. In order to overcome this problem, we decided to rely on events (old_code/MunicipalityWasteTaxesRBAC.sol). In particular, when an event is emitted, the transaction logs are stored on blockchain and are externally accessible using the address of the contract. We therefore decided to emit various events for the different stages of the life cycle of a trash bag, listen to these events using Python and web3, and store the relative information in a database outside the blockchain, thus avoiding the need to saving all these data directly on the blockchain.
Nonetheless, relaying on events can also pose some challenges. Someone may argue that storing important data outside the blockchain may be subject to potential manipulation. However, this is only partially true. Even though the municipality can temper with the data stored in the database at a later time, the logs of the events emitted throughout the year will still be stored in the blockchain and thus anyone would be able to verify the authenticity of the data in the database.
In the contract trashlife.sol, the function withdraw allows the Municipality to withdraw some funds from the contract before the end of the year. Given that the citizens have to pay the TARI at the beginning of the year, but the refunds only happen at the end of the year, it may not be ideal to keep all the money in the contract for this whole time, thus preventing the Municipality from using a free and immediately available source of liquidity. On the other hand, it is also important to assure that, at the end of the year, the Municipality will be able to re-pay what they owe to all citizens. This trade-off between freezing funds and default risk can be partially solved by allowing the municipality to withdraw once a year 88% of the total funds stored in the contract. In this way, the Municipality can enjoy some immediate liquidity while at the same time guaranteeing to be solvent at the end of the year. Indeed, even assuming that all citizens recycled more than 75% of their waste, the maximum amount that the Municipality would have to pay to citizens is 10% of the total funds coming from the TARI payments. An additional 2% of the funds is kept in the contract to also take into account eventual transaction costs.
It is important to stress that this is just one of the potential solutions to the above-mentioned trade-off, and it is open to future improvements and modifications. For example, it could be possible to change the frequency and the way through which the Municipality is allowed to withdraw the funds, while also always ensuring that the Municipality is able to perform the pay-out operations at the end of each year.