Blockchain-Based Tracking of the Supply Chain of the Italian Craft Beer Sector⋆ Lorenzo Ariemma1 , Niccolò De Carlo3 , Diego Pennino1 , Maurizio Pizzonia1 , Andrea Vitaletti2 and Marco Zecchini2 1 Università degli Studi Roma Tre, Dipartimento di Ingegneria, Sezione Informatica e Automazione, Via della Vasca Navale 79, 00146 Rome, Italy; 2 Sapienza Università di Roma, Dipartimento di Ingegneria Informatica, Automatica e Gestionale, Via Ariosto 25, 00185 Rome, Italy; 3 Taggo srl, Viale Giulio Cesare 14, 00192, Rome, Italy; Abstract In the Italian craft beer market, many small breweries and pubs propose a large number of products to beerlovers. In this highly fragmented market, it is hard for the beerlovers to assess the quality of a beer and it is hard for breweries and pubs to inform the beerlover of the quality of their offer. Supply chain tracking is an interesting tool to improve transparency of food markets. However, standard tracking approaches are challenging in highly fragmented contexts for several reasons. In this paper, we show how it is possible to realize a blockchain-based supply chain tracking tailored for the highly fragmented sector of the Italian craft beer. We collaborated with one of the players of that market to analyze the specific problems of that context and we report the results of this analysis. We show a design that addresses those problems and might be generalized to support tracking in other highly fragmented sectors. We estimate costs and that turn out to be affordable for that sector. 1. Introduction In the agriculture and food contexts, the quality of the products is paramount for the final consumer for obvious reasons. However, the consumer has very little means to assess the quality of a product in advance. For this reason auditing and certifications play a crucial role in this context [27]. These approaches rely on the trust that final consumers and market operators pose on a (usually small) number of subjects that perform the auditing. There are two drawbacks to this: the rising of costs, which may put out of market small players, and the undue power given DLT 2022: 4th Distributed Ledger Technology Workshop, June 20, 2022, Rome, Italy ⋆ This research was partially funded by POR FESR LAZIO 2014 – 2020, call for “Gruppi di ricerca 2020”. Det. n. G04052 of Apr. 4th, 2019, under the “LazioChain” project, CUP F85F21001550009 - POR project code A0375E0116. This research was partially funded by Sapienza Ateneo Research grant “La disintermediazione della Pubblica Amministrazione: il ruolo della tecnologia blockchain e le sue implicazioni nei processi e nei ruoli della PA”. $ lorenzo.ariemma@uniroma3.it (L. Ariemma); niccolo.decarlo@taggo.io (N. De Carlo); pennino@ing.uniroma3.it (D. Pennino); pizzonia@ing.uniroma3.it (M. Pizzonia); vitaletti@diag.uniroma1.it (A. Vitaletti); zecchini@diag.uniroma1.it (M. Zecchini)  0000-0001-8009-4702 (L. Ariemma); 0000-0001-5339-4531 (D. Pennino); 0000-0001-8758-3437 (M. Pizzonia); 0000-0003-1074-5068 (A. Vitaletti); 0000-0002-2280-9543 (M. Zecchini) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) 130 to the auditors, which may improperly change market rules with their decisions and which may be the targets of corruption attempts. Blockchain technologies provide an opportunity to address this problem differently. These technologies have proven themselves to be valuable tools to address a variety of problems. They are especially useful when a wide number of actors have competing interests but have to cooperate to agree on a common view of some kind of shared data. Historically, the first application of blockchain was cryptocurrency where actors are whoever intend to use the cryptocurrency (e.g., to buy or sell goods) and shared data are the balances of all accounts. Blockchain applications flourished in the last ten years in many contexts [3], like finance, healthcare, logistics, manufacturing, energy, and also agriculture and food. A large part of the efforts in these last two sectors, focused on the adoption of blockchain with the purpose of tracking all the production steps of a supply chain in a decentralized manner [36]. In this paper, we focus on the Italian craft beer sector. A highly fragmented context with a large number of actors and products, and many enthusiast final consumers (beerlovers). Since craft producers are by definition small, they can hardly comply with costly certifications and may have difficulties to convey to the final consumer information about the quality of their products. This situation is known to be unfavorable to high quality producers [2] and, hence, detrimental for the whole sector, which ends up with an offer with homogeneously low quality. The objective of this paper is to report our experience in designing a blockchain-based tracking system for the craft beer supply chain. Since craft beer sector is very fragmented, approaches that can be applied in more consolidated sectors might fail. For example, we cannot ask small breweries an investment to host a node of a dedicated private blockchain. Our analysis was performed with the collaboration of Yhop [39], an Italian startup company that aims to provide tools to improve visibility and product quality awareness for all the actors in the craft beer supply chain, in Italy. The challenges we faced in our work were mostly related to costs. Besides not being able to convince small companies to host nodes, it is equally unaffordable for them to pay the high fees that a common public blockchain may have [31]. Our solution is based on the EOSIO public blockchain. A blockchain that, under certain conditions, can greatly reduce usage costs, and also charge them on a subject that is different from the transaction submitter. Our design is able to leverage EOSIO peculiar features to provide a solution that is affordable for the craft beer sector. We think that the same approach might be adopted in other fragmented sectors, like in the sectors of automotive maintenance, baked food production, or software production. In Section 2, we present some definitions about the supply chain of craft beer and its problems. In Section 3, we provide the current state of the art involved in our scenario, in particular, in Section 3.1 we show the main approaches for the craft beer market in Italy and in Section 3.2 we provide some information about the adoptions of the blockchain technology for the supply chain. In Section 4, we highlight our objectives to improve the tracking system. In Section 5, we discuss the threat model we face. In Section 6, we present our solution supported by cost analysis. Finally, in Section 7, we provide some conclusions and discuss some future works. 131 2. The Supply Chain of Craft Beer In this section, we describe the structure of the supply chain of craft beer with information about involved stakeholders and some of its problems that are relevant for this paper. Like all products in today’s world, beer is driven by new trends. Consumer behavior and pressure, as well as industry consolidation and restructuring, the growth of third-party services providers, and technological developments are also changing the beer supply chain. However, for the sake of simplicity, we can generalize and say that the craft beer supply chain consists of four main stakeholders. Growers. The chain start from the growers of raw materials (e.g., hop, malt and yeast). In Italy, it is estimated about 100 hectares [1] cultivated with hops and 2 malt houses [5]. Breweries. The raw materials are then used in the breweries. Currently, about 1600 small breweries operates in Italy [28]. Yhop offer services to about 300 of them. Depending on their size, each of them can produce from about 40 to 150 batches each year. Pubs. All these batches, are then distributed to the dense network of pubs throughout the country. Beerlovers. The last step of the supply chain are represented by the final consumers, i.e., the beerlovers. The craft beer market is fragmented [23] and it cannot be otherwise. In fact, its very definition implies that a multitude of small breweries exists, with scarcely automated production processes. Further, consumers of craft beer are attracted by the variety of offer, which cannot be obtained by big producers with large scale industrial processes. Any market is more or less affected by an asymmetry of information between the con- sumer/buyer and the producer/seller. This was the topic of very well-known studies in eco- nomics (see for example [2]). Those studies pointed out that when the buyers do not have enough information to perform their choice also the producer is not motivated to propose high quality offers. For big producers, this is mitigated by consumers that can gather and exchange their opinions. This is especially true if products do not change over time and consumers have some way to let know their opinion to other consumers (and are motivated to do that). In the case of highly fragmented markets, as it is the case for the craft beer market, each player is very small and the number of products available to the consumer is very large. Further, products may change frequently due to the enthusiast experimental attitude of each brewer or depending on the availability of ingredients on the market. For this reason, improving the visibility that a consumer may have upfront over the quality of the production is important in the craft beer market. The lack of accurate information along the chain also spreads from the consumers to the producers. This can cause the so-called bullwhip effect. The bullwhip effect is a distribution channel event that refers to shifts in inventory levels due to changes in consumers demand. Demand expectations succumb to supply chain inefficiencies as you go up the supply chain. For example, consumer forecast demand is 25 units, a retail order that includes safety stock becomes 40 units, wholesale order 60 units to gain wholesale purchasing advantages, and manufacturers’ 132 raw material order is 70 units to reduce costs. The bullwhip effect in this scenario creates 45 units more than expected consumer demand. By increasing producer visibility across the entire chain, it can greatly reduce waste, again benefiting the quality of the final product. Currently, the craft beer production and distribution chain has 3 main limitations. Inefficiency. Breweries have no tools to manage the production of beer: it can happen that they produce less beer that what is requested or vice versa. In addition, they have no data about the consumption of their products and there are no tools to monitor what beer is preferred by consumers. This may cause the above mentioned bullwhip effect. On the other side, distributors have no tools to manage their inventory; this leads to the risk to lose some barrels due to their expiration. No guarantees of freshness. Breweries have no possibility to track their barrel. Once they leave the barrels to the distributors, they do not know when and where it is going to be delivered to the pubs/shops. They have no idea how long the beer is going to remain in stock to the distributors and have no guarantee of freshness maintenance during the distribution process. No product traceability. Currently, there are no systems to track beers’ production. Pubs/shops receive the products from the distributors, but they have no information about some important production parameters, such as when it has been produced and how long it stayed to the distributor before its delivery. By informal discussion with craft beer market operators, supply chain tracking may be perceived as a significant value added. 3. State of the Art 3.1. Tracking in the Craft Beer Sector in Italy At least part of the breweries feel that the perceived quality of the product may be improved by adopting some supply chain tracking. This is a very common motivation for tracking and especially for tracking by using blockchain (see Section 3.2). In Italy, some experiences are already started from big and small players. Currently, a big Italian player [24] has an experimental project to track the national origin of malt using the Ethereum [42] blockchain. A small brewery [22] is focusing on a centralized tracking of its production batches. Users can access data about the batches on the web by specifying the batch number or by scanning a QR-code on the beer. For the craft beer sector, Yhop [39] has set up a form of centralized supply chain tracking. It involves breweries and pubs that have signed up with Yhop and allows them to provide information for the beerlovers through the Yhop mobile app. Breweries can provide information about batch productions. Pubs can provide information about what beers they offer and what beers they currently have attached to the taps. Consumers can express their appreciation for the products by highlighting their consumption habits. Institutions are taking steps to build the Italian brewing chain. The sudden development of this sector made it necessary to fill a regulatory gap in the definition of beer and craft brewery. 133 With Art. 35 of Law no. 154 of 28 July 2016, a legislative definition of craft beer was provided, thus integrating Law no. 1354 of 16 August 1962, identified as “the product obtained from alcoholic fermentation with Saccharomyces carlbergensins or Saccharomyces Cerevisiae strains of a must prepared with malt, whether or not roasted, of barley or wheat or their mixtures and water, amaricated with hops or its derivatives or with both ". Art. 35 defines craft beer “beer produced by small independent breweries and not subjected, during the production phase, to pasteurization and microfiltration processes". The purpose of the request for Italian raw materials, especially from craft beer producers, is to promote a path that leads to the production of 100% Made in Italy beer, which for the consumer is synonymous with quality, transparency and identity bond with the product. Furthermore, compared to what happens for industrial beer, the consumer of craft products wants to exper- iment with new aromas, new taste experiences and textures [6]. At the same time, it wishes to rediscover the authenticity of raw materials and establish a link with the territory [37, 4]. Therefore, the area of origin of the product has an identity value and a sense of belonging. This translates into the opening of market niches as many as the preferences expressed by the consumer. Craft beer, with its highly differentiated raw materials, lends itself well to this new trend. 3.2. Blockchain for Supply Chains Tracking in supply chains is one of the most widespread applications of blockchains. Several systematic literature reviews exist [10, 12, 13, 26, 33]. Further, a number of research works also address the specific problem of food supply chain, see for example [9, 11, 25, 34, 38, 40, 41]. Most of the approaches adopt permissioned blockchains. However, this implies to have • a number of entities that are willing to provide resources to operate the nodes of the blockchain, and • a central authority (likely a consortium) that recognizes those subjects as entitled to do that. This is possible and convenient only in structured ecosystems where some sort of consortium is already present or when the number of involved subjects is small and can coordinate for this purpose. In certain sectors, only a handful of big players can meet the above conditions which may lead to a quite centralized tracking. On the other hand, solutions that rely on public blockchains (like [24]) have to face cost problems. In fact, public blockchain costs may unexpectedly rise due to the adoption of the same blockchain by other applications or communities for reasons that are completely unrelated with the supply chain and are very hard to predict. This is a typical issue when adopting a public blockchain to support a specific business or task. An analysis of these and other problems concerning the interplay of technical and economical aspects can be found in [31]. Further, transaction costs are usually charged on the actor who send the transaction (like in Ethereum [42]). This might be economically inconvenient, since the cost of tracking might be too high, discouraging the supply chain actors to use the tracking service. It might also be unpractical since each actor have to keep an account on the blockchain for the tracking expenses and periodically replenish it. 134 Some newer unpermissioned blockchains try to lower the fee costs with diverse approaches. Nano [29] is feeless and assumes that nodes operators have other motivation besides revenues for operating the node. However, Nano does not support smart contracts. IOTA [32] asks the users to participate in transaction confirmation. EOSIO [16] adopts an innovative cost model combined with a staking approach, based on paying only for the maximum amount of resources that can be used in a period of time (i.e., memory/RAM, CPU and network), instead of charging for each transaction. It supports smart contracts and adds the possibility of charging to the contract creator the costs of the resources used by contract-related transactions. Other approaches achieve low fees for most transactions (e.g., NEO [30]). It is worth noting that transforming supply contracts into smart contracts could be a particu- larly effective remedy to problems such as the above mentioned bullwhip effect. Smart contracts targeted to optimize supply chains are dealt with in [7, 8]. 4. Objectives: from Centralized to Blockchan-Based Yhop [39] operates a centralized platform to connect all stakeholders in the craft beer supply chain, enable them to exchange information efficiently and create an active community around the theme of craft beer. The Yhop platform is the starting point of the solution presented in this paper. Centralized tracking has some drawbacks. The first and obvious one is that centralized tracking may be considered not secure (see Section 5). However, this may not be the primary concern for the beer sector. Nevertheless, any centralized tracker is responsible for the data that it shows, which may not be desirable for any organization proposing or managing a supply chain tracking system. Currently, Yhop can centrally track craft beer supply chain starting from breweries. A brewery kegs the product and makes it available for distribution or directly to the sales premises to the public. Throughout the supply chain, the information related to the keg up to the consumption of the beer can be recorded. The objective of the project presented in this paper is to use the blockchain to certify this information by cryptographic means and make the actors involved in the process responsible for it. Once the supply chain has been traced in certified form, it will be possible to trace the authenticity of the information presented for each barrel sold at any time and the correctness of the time elapsed between the various stages from production to sale. In addition to giving a guarantee on the authenticity and freshness of the product, this model also guarantees consumers from fraud on the originality of the product itself with respect to counterfeits. Our first objective is to support blockchain-based tracking in the craft beer supply chain with a reasonable level of security and decentralization. Since the context is made of a large number of small players, our intent is to make tracking adoption as easy and economically convenient as possible. Breweries, beerlovers, and pubs should be able to use the system transparently without the need to explicitly create or manage any blockchain account and without the need to buy cryptocurrency to pay for transactions. At the same time, it should be possible to get enough details to be sure of the integrity of the tracked information, even if this is expected to be asked by a minority of technically-skilled users. Currently, we intend to focus on the breweries production tracking, but the design should be 135 compatible with a future involvement of pubs and raw material producers (primarily malt and hop). We also intend to make technology choices that may be used for supporting other services involving tokens targeted to that specific supply chain (e.g., discount coupons or complementary currency). Our solution should be managed by a subject that decides the architecture, develops the soft- ware, deploys it, enrols users, and supports them so that they can easily perform all operations. We call it the managing operator. In our case, the managing operator is Yhop. Currently, the only kind of users involved are breweries, entitled to enter tracking records, and beerlovers, entitled to query tracking records. While enrolment is needed for breweries (and in the future also pubs and raw material producers), beerlovers do not need enrolment, since tracking records are public. 5. Security Goals We assume the integrity of tracking data to be paramount: the beerlover should be able to get a cryptographic proof that guarantees that data comes directly from the breweries, for the batch that (s)he is interested in. In fact, in this context, data corruption may lead to a serious reputational damage or improper competitive advantage. For this reason, it is important for the data to be cryptographically linked with the brewery so that the brewery is liable for it, both legally and ethically. The managing operator should not be involved in the security aspects related to data integrity. In this sense, all the users should consider the managing operator as untrusted and the system should allow any user to check the integrity of tracking data at any time. Further, we assume users do not trust any single subject in the supply chain. However, they can trust subjects that are not involved in the supply chain and unlikely to collude with any subject involved in a supply chain, like the nodes of a public blockchain. Note that, although breweries are legally responsible for stored data, we can not ignore the possibility of a DoS attack. Even non-malicious breweries may inadvertently deplete resources by mistake, for example by re-submitting the same record several times. To prevent this type of attack, we prefer the submission of transactions for the tracking records to be performed by the managing operator (see Section 6), screening our system by misbehaving breweries. Note that, the managing operator still cannot tamper the tracking records, since they are signed by the corresponding brewery, and there is no advantage for the managing operator to stop the submission of tracking records. A possible evolution of the system might include a protocol in which the managing operator commits itself to submit one tracking record at least once, so that a brewery can demonstrate potential malicious behavior by the managing operator. However, this is not dealt with in this paper. 6. A Practical Design To meet the goals stated in Section 4, we decided to opt for a public blockchain. This allows us to avoid the problem to deploy private nodes. In fact, as described in Section 2, it would be very hard to motivate several small breweries to host nodes. However, as cited in Section 3.2, this 136 choice has some drawbacks. In particular, the costs of a public blockchain are hard to control and may depend on the load of the system. We opted for the EOSIO blockchain [16] for its peculiar cost and charging model. 6.1. EOSIO Basics EOSIO (with native token EOS) was started in 2018 by a company named block.one. Its objectives are to provide a platform supporting the development of efficient and cheap-to-execute smart contracts. While it is mostly famous for its very short block time (0.5 seconds), for our application, the most interesting feature is the transaction payment and accounting models. Users put at stake a certain amount of EOS tokens to reserve CPU and NET resources for the execution of transactions, comprising calls to smart contracts. EOSIO automatically replenish the available resources favoring accounts showing lower frequency of transactions [21]. The available resrouce (CPU or NET) is the resource still available for consumption supposing no replenish is going to be performed. Persistent memory (called RAM in EOSIO jargon) used by smart contracts have to be bought on a free market but can be sold when not needed. Essentially, resources for EOSIO usage follow the CAPEX model. This means that if smart contract calls are performed at a constant frequency and if smart contracts are designed so that their storage consumption is bounded, the use of EOSIO has no direct operational costs. Further, in EOSIO, more users (i.e., public keys) can be associated with an account where each user can be assigned specific permissions. Since resources are bound to the account, all users consume resources of that account. The managing operator is also a special user of that account, which can control the available amount of resources for running the smart contract and provision more of them when needed, i.e., in case tracking activity increases. The permission system of EOSIO works as follows (see Figure 1). We limit this description to what is strictly needed in this paper. Further details can be found in [14]. Each account is associated with many permissions. Each permission is associated with many public keys, which in EOSIO jargon are called authorities. One smart contract method is called action in EOSIO jargon and it is associated with one permission. When an action 𝐴 is associated to a permission 𝑃 , only an authority 𝑢 associated with 𝑃 can call 𝐴. EOSIO natively performs this check by verifying that the transaction containing the call to 𝐴 is signed by the public key of 𝑢. This check is performed before charging available resources. Clearly, a smart contract can perform further checks, but their execution impacts on available resources. 6.2. The Data to Be Tracked Essentially, our tracking system allows a number of breweries to store in the RAM of a smart contract in the public EOSIO blockchain, a record for each batch of beer they produced. First, we note that we can delete from RAM records for batches that are too old, since there is no point in tracking batches beyond their expiration date. Hence, in a stationary condition, where the number of breweries and their batch production rate is constant over time, the amount of storage needed in blockchain is bounded. To further reduce storage, our tracking records are the 5-tuple ⟨𝐵, 𝑏, ℎ𝑏 , 𝑑𝑒 , 𝑡𝑠 ⟩, where 𝐵 is the identifier of the brewery that has submitted the tracking record, 𝑏 is the identifier of the batch to track among the batches produced by 𝐵, ℎ𝑏 is 137 ACCOUNT 1 SMART CONTRACT Name * * PERMISSION Execute only under ACTION 1 * Name Name Parameters * * Authority Figure 1: EOSIO Permissions model. a cryptographic hash of the record describing the batch, 𝑑𝑒 is the expiration date of the batch, 𝑡𝑠 is the timestamp of the submission of this tracking record. As breweries identifiers, we can choose its public key or we can assign smaller integer numbers to them. Each batch is described by a batch description, which is a json-represented record containing all data specified by the brewery. Yhop already collects batch description and stores them in its systems. The hash ℎ𝑏 should be a hash of the batch description. Unfortunately, a json representation is not unique. For this reason, a canonicalization scheme, like the one described in [35], should be adopted before applying the cryptographic hash function. 6.3. The Architecture The architecture is shown in Figures 2 and 3. Since the only subject that have to pay for resource consumption is the managing operator, breweries have not specific accounts. They are just represented by their public keys that are associated with the tracking permission. The active permission is the default EOSIO permission which is dedicated to the managing operator. The smart contract has an action add, which can be called by breweries to add tracking records. This call could be in principle be performed by clients used by breweries by directly submitting the corresponding transaction to the blockchain nodes. However, even non malicious users may inadvertently deplete resources by mistake, for example, by repeatedly clicking on the submit button and hence re-submitting the same record multiple times. To filter out these kinds of mistakes, we prefer to make the managing operator servers to actually perform the submission of the transaction. We call this service tracking support, also denoted 𝑆 in the following. Note that, since the transaction is signed by a brewery, the tracking support service cannot modify it. In principle, the managing operator can block the submission, but this is not in its interest unless it is a repeated submission. The tracking support service also performs further checks to be sure that submitted tracking records are consistent with the corresponding batch description, in particular regarding expiration date and hash. The smart contract stores tracking records in a so-called kv-table [17], whose size is accounted as occupied RAM. In EOSIO, a kv-table is made of rows indexed by a key. A kv-table belongs to 138 EOSIO ACCOUNT SMART CONTRACT TRACKING SYSTEM Blockchain Part Action add(B,b, hb , de ) Breweries Table ID, Pk Permissions Tracking Records ACTIVE The Managin Operator (PK) Brewery ID Batch ID TRACKING Hash All Breweries Expiratio Date (PK’s) Submission Timestamp Figure 2: Architecture: on-chain part. a smart contract and can be queried by an off-chain client using standard node REST API. 6.4. Lifecycle of a Tracking Record Submission The steps to submit a tracking record for a batch into our blockchain-based system are the following. Please refer to Figure 3. 1 The brewery owner (whose brewery has ID 𝐵) has a batch description for a (new) batch (with ID 𝑏). 2 The Brewery Client 𝐶 represents the batch description in a canonized json and send it to off-chain system for storage. 3 𝐶 obtains a cryptographic hash ℎ𝑏 from the canonized json. 4 𝐶 creates the transaction 𝑡𝑥 for the call of the add action. 5 𝐶 signs the transaction 𝑡𝑥 with the secret key 𝑠𝑘𝐵 of the brewery and send it to the Tracking Support Service 𝑆. 6 𝑆 stores signed 𝑡𝑥. 7 𝑆 checks that parameters in 𝑡𝑥 are coherent with the corresponding batch description already stored in the off-chain systems and that this request was not already processing (case of repeated unintended submissions). 139 EOSIO Blockchain Managing operator Brewery Client (C) (web or mobile app) Tracking Support Service (S) Transaction 4 Creation Buffering 6 Filtering 7 add(B, b, hb , de , ts ) Submitting 8 5 Signature skB 3 Hash Storage System Canonization 2 JSON exp Date 1 Batch Description Brewery Owner Figure 3: Architecture: off-chain part. 8 𝑆 submits 𝑡𝑥 to any public EOSIO nodes. 9 𝑆 checks 𝑡𝑥 for confirmation. 10 𝑆 provides the user with feedback on the result of the add action. This is made by any asynchronous communication mean (e.g., by email). 140 6.5. Cost Estimation We performed some preliminary experiments to estimate the resources needed to run the system and to devise a methodology to make this estimation when the final version of smart contract will be ready for production. We created a very simple smart contract that have a multi-index kv-table, and an action insert to insert a preliminary form of tracking records in it. For this experiment, our tracking record has the following structure ⟨𝑖𝑑1 , 𝑖𝑑2 , ℎ⟩, where 𝑖𝑑1 is an integer, 𝑖𝑑2 is a 7 character string, and ℎ is a 32 character string. In our experiment, each insertion takes 156 bytes of RAM and 300𝜇𝑠 of CPU to execute the insert action. Following the number given in Section 2, we suppose to have 300 breweries managed by Yhop, each inserting at most 150 tracking records per year, which gives a maximum frequency of 45,000 insertions of tracking records per year. Since the expiration time of a batch of beer is 1 year, and we do not need to track expired batches, 45,000 is also a good upper bound of the maximum number of tracking records that our smart contract will need to store to support tracking for the current breweries coverage of Yhop. We estimate storage costs as follows. The total storage consumption (RAM) is of about 7020Kbytes. At the time of writing the RAM costs about 0.029 EOS per Kbyte [19], for a total cost of 203 EOS, currently corresponding to about 400 euro. Note that these are CAPEX. NET and CPU resources are managed in a similar way in EOSIO. In the following, we focus on the CPU cost (NET cost turns out to be negligible). As we describe in the following, the CAPEX model is viable form a theoretic point of view but very expensive in practice and for the CPU resource we need to choose an OPEX approach supported by the EOS powerup tool [15]. EOSIO keeps an amount of available CPU for each account that is regularly replenished. The description of the replenishing algorithm given in the EOSIO documentation [21] is not very clear. However, we checked it with the code [18] and we observed that it takes 24 hours (called window) to fully replenish the available CPU (and NET) resources. Following what we stated above, we assume 45,000 tracking records per year and 200 working days per year. Further, assuming tracking transactions to be homogeneously distributed, we obtain 45, 000/200 = 225 transactions per day. Assuming tracking activity to be uniformly distributed within 10 hours of work for each day, we obtain a transaction every about 2.6 minutes, on average and a rest period of 14 hours. The transaction frequency during working hours is very high, so we cannot expect any notable replenishment there, and the rest hours are not enough for completely replenishing the CPU (or NET) resource. Further, the replenish rate is not dependent on the staked amount of resources. Hence, as far as we can tell, there is no way to take advantage of the EOSIO staking model to support our transaction frequency with a single account. To work around this oddity, we might tweak the architecture shown in Section 6, so that transactions are originated from three distinct accounts, which are equally configured regarding permissions and authorities. We might use each of them to send transactions for more than 12 hours (e.g., 13 hours) in a round robin fashion. In this way, one account can completely rest for more than 24 hours, to be completely replenished, while the other two work. This makes the CAPEX approach theoretically viable also for CPU and NET resources. In practice, each of the three accounts should stake CPU time to execute 225 transactions, corresponding totally to about 200ms of CPU currently costing about 80,000 euros. Even if these are capital expenses, this is 141 clearly a very high cost. Recently EOSIO has introduced a way to rent unused staked resources called powerup model [15]. Form the point of view of the managing operator, the powerup model is essentially a way to buy resources under the traditional OPEX model, which is currently very cheap (0.0002 EOS for each millisecond of CPU [20]). In this model, 225 transactions per day can be executed by spending about 0.10 EUR (at current exchange rates), for a cost of less than 40 euro per year. In conclusion, for the CPU resource the OPEX model using powerup is definitely more advisable. The same approach can be adopted for the NET resource, with even lower costs. 7. Conclusions and Future Work In this paper, we show how it is possible to design a tracking system based on the EOSIO blockchain that is affordable for the fragmented sector of the Italian craft beer. To assess the truthfulness and integrity of the tracking information, and to give responsibility to the actors that created the data, the blockchain is used to store the hashes of the records that describe production batches. The batch descriptions are stored in a centralized way on the servers of the managing operator (i.e., Yhop in our use case). We give a cost estimation of our solution and we show that, at current prices, mixing CAPEX and OPEX cost models is the most convenient approach. As a future work, we plan to realize the system and to perform a proof-of-concept in col- laboration with Yhop and with more than twenty breweries that already have declared their availability to participate. We plan to extend the functionalities of the system to include pubs and growers. We also intend to study how to use blockchain in the same context to support discount coupons or a complementary currency. 8. Acknowledgements We would like to thank you Lorenzo Cannella for working on an early version of this project. References [1] Agronotizie. Luppolo made in italy un panorama produttivo vivace ma frammentato. [on- line]. https://agronotizie.imagelinenetwork.com/agricoltura-economia-politica/2020/08/ 31/luppolo-made-in-italy-un-panorama-produttivo-vivace-ma-frammentato/67793, last viewed April 2022. [2] George A. Akerlof. The Market for “Lemons”: Quality Uncertainty and the Market Mechanism. In Peter Diamond and Michael Rothschild, editors, Uncertainty in Economics, pages 235–251. Academic Press, January 1978. [3] Jameela Al-Jaroodi and Nader Mohamed. Blockchain in industries: A survey. IEEE Access, 7:36500–36515, 2019. [4] Tiziana Amoriello, Katya Carbone, Alessandro Monteleone, Mauro Pagano, and Serena Tarangiol. Criticità e opportunità per lo sviluppo sostenibile della filiera brassicola. [on- line]. https://www.academia.edu/30444023/CRITICIT%C3%80_E_OPPORTUNIT%C3%80_ 142 PER_LO_SVILUPPO_SOSTENIBILE_DELLA_FILIERA_BRASSICOLA, last viewed May 2022. [5] AssoBirra. Annualreport 2020 june 2021. [online]. https://www.assobirra.it/wp-content/ uploads/2021/06/AssoBirra_AnnualReport_2020_giugno2021_DEF.pdf, last viewed April 2022. [6] Bram Berkhout, Lianne Bertling, Yannick Bleeker, Walter de Wit, Geerten Kruis, Robin Stokkel, and Ri-janne Theuws. The Contribution made by Beer to the European Economy | FullReport. [online]. https://brewersofeurope.org/uploads/mycms-files/documents/ archives/publications/2013/FullReport20140123.pdf, last viewed May 2022. [7] Paolo Bottoni, Claudio Di Ciccio, Remo Pareschi, Nicola Gessa, and Gilda Massa. Variants in managing supply chains on distributed ledgers. arXiv preprint arXiv:2205.06766, 2022. [8] Paolo Bottoni, Nicola Gessa, Gilda Massa, Remo Pareschi, Hesham Selim, and Enrico Arcuri. Intelligent smart contracts for innovative supply chain management. Frontiers in Blockchain, 3:52, 2020. [9] Miguel Pincheira Caro, Muhammad Salek Ali, Massimo Vecchio, and Raffaele Giaffreda. Blockchain-based traceability in Agri-Food supply chain management: A practical imple- mentation. In 2018 IoT Vertical and Topical Summit on Agriculture-Tuscany (IOT Tuscany), pages 1–4. IEEE, 2018. [10] Shuchih E. Chang and Yichian Chen. When blockchain meets supply chain: A systematic literature review on current development and potential applications. IEEE Access, 8:62478– 62494, 2020. [11] Jiang Duan, Chen Zhang, Yu Gong, Steve Brown, and Zhi Li. A content-analysis based literature review in blockchain adoption within food supply chain. International journal of environmental research and public health, 17(5):1784, 2020. [12] Davor Dujak and Domagoj Sajter. Blockchain applications in supply chain. In SMART supply network, pages 21–46. Springer, 2019. [13] Pankaj Dutta, Tsan-Ming Choi, Surabhi Somani, and Richa Butala. Blockchain technol- ogy in supply chain operations: Applications, challenges and research opportunities. Transportation research part e: Logistics and transportation review, 142:102067, 2020. [14] EOSIO. Accounts And Permissions | EOSIO Developer Docs. https://developers.eos.io/welcome/latest/protocol-guides/accounts_and_permissions. [15] EOSIO. The EOS PowerUp Model Explained – EOSIO. https://eos.io/news/eos-powerup- model-explained. [16] EOSIO. Eosio Documentation. [online]. https://github.com/EOSIO/Documentation/blob/ master/TechnicalWhitePaper.md, last viewed April 2022. [17] EOSIO. How-To Use Key-Value Table | EOSIO Developer Docs. https://developers.eos.io/manuals/eosio.cdt/latest/how-to-guides/key-value- api/kv_table/how-to-use-kv-table. [18] EOSIO. Nodeos code, master branch at 30 april 2022. [online]. https: //github.com/EOSIO/eos/blob/11d35f0f934402321853119d36caeb7022813743/ libraries/chain/include/eosio/chain/resource_limits_private.hpp#L110, https: //github.com/EOSIO/eos/blob/11d35f0f934402321853119d36caeb7022813743/ libraries/chain/resource_limits.cpp#L166, https://github.com/EOSIO/eos/blob/ 11d35f0f934402321853119d36caeb7022813743/libraries/chain/resource_limits.cpp#L185, 143 https://github.com/EOSIO/eos/blob/11d35f0f934402321853119d36caeb7022813743/ libraries/chain/include/eosio/chain/config.hpp#L51 last viewed 30 April 2022. [19] EOSIO. Official EOS Explorer and Wallet of EOS Authority | EOS Authority. https://eosauthority.com/. [20] EOSIO. PowerUp Calculator | EOS Authority. https://eosauthority.com/power/calculator?network=eos. [21] EOSIO. Staking on EOSIO-based blockchains | EOSIO Developer Docs. https://developers.eos.io/manuals/eosio.contracts/latest/key-concepts/stake/#system- resources-replenish-algorithm. [22] Giornale della Birra. BeerLife: grazie alla blockchain, tutta la vita della birra che si sta gustando a portata di click! - Giornale della Birra. https://www.giornaledellabirra.it/senza- categoria/beerlife-grazie-alla-blockchain-tutta-la-vita-della-birra-che-si-sta-gustando-a- portata-di-click/. [23] Indeed. What Is a Fragmented Market? | Indeed.com. https://www.indeed.com/career- advice/career-development/fragmented-market. [24] Ledger Insights. Birra Peroni uses EY OpsChain, NFTs for beer traceability - Ledger Insights - enterprise blockchain. https://www.ledgerinsights.com/birra-peroni-uses-ey- opschain-nfts-for-beer-traceability/. [25] Andreas Kamilaris, Agusti Fonts, and Francesc X. Prenafeta-Bold$\acute\nu$. The rise of blockchain technology in agriculture and food supply chains. Trends in Food Science & Technology, 91:640–652, 2019. [26] Kari Korpela, Jukka Hallikas, and Tomi Dahlberg. Digital supply chain transformation toward blockchain integration. In proceedings of the 50th Hawaii international conference on system sciences, 2017. [27] Konstantinos V. Kotsanopoulos and Ioannis S. Arvanitoyannis. The role of auditing, food safety, and food quality standards in the food industry: A review. Comprehensive Reviews in Food Science and Food Safety, 16(5):760–775, 2017. [28] Microbirrifici. map of active producers. [online]. https://www.microbirrifici.org/beer_ italy_maps.aspx, last viewed April 2022. [29] Nano. Eco-friendly and feeless digital currency. [online]. https://nano.org/, last viewed January 2022. [30] Neo. Whitepaper. [online]. https://docs.neo.org/v2/docs/en-us/basic/whitepaper.html, last viewed January 2022. [31] Diego Pennino, Maurizio Pizzonia, Andrea Vitaletti, and Marco Zecchini. Blockchain as IoT Economy Enabler: A Review of Architectural Aspects. Journal of Sensor and Actuator Networks, 11(2):20, 2022. [32] Serguei Popov. The tangle. White paper, 1(3), 2018. [33] Maciel M. Queiroz, Renato Telles, and Silvia H. Bonilla. Blockchain and supply chain management integration: a systematic review of the literature. Supply Chain Management: An International Journal, 2019. [34] Michael Rogerson and Glenn C. Parry. Blockchain: case studies in food supply chain visibility. Supply Chain Management: An International Journal, 2020. [35] Anders Rundgren, Bret Jordan, and Samuel Erdtman. JSON Canonicalization Scheme (JCS). Request for Comments RFC 8785, Internet Engineering Task Force, June 2020. [36] Samant Saurabh and Kushankur Dey. Blockchain technology adoption, architecture, and 144 sustainable agri-food supply chains. Journal of Cleaner Production, 284:124731, 2021. [37] Steven M. Schnell and Joseph F. Reese. Microbreweries as tools of local identity. Journal of cultural geography, 21(1):45–69, 2003. [38] Affaf Shahid, Ahmad Almogren, Nadeem Javaid, Fahad Ahmad Al-Zahrani, Mansour Zuair, and Masoom Alam. Blockchain-based agri-food supply chain: A complete solution. IEEE Access, 8:69230–69243, 2020. [39] Taggo srl. Yhop. [online]. https://www.yhop.beer/, last viewed April 2022. [40] Bowen Tan, Jiaqi Yan, Si Chen, and Xingchen Liu. The impact of blockchain on food supply chain: The case of walmart. In International Conference on Smart Blockchain, pages 167–177. Springer, 2018. [41] Feng Tian. An agri-food supply chain traceability system for China based on RFID & blockchain technology. In 2016 13th international conference on service systems and service management (ICSSSM), pages 1–6. IEEE, 2016. [42] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151(2014):1–32, 2014. 145