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 ofer. 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 afordable for that sector.
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 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 diferently. 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 [
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 dificulties to convey to the final consumer information about the quality of their
products. This situation is known to be unfavorable to high quality producers [
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 [
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.
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 [
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 ofer, which cannot be obtained by big producers with large scale industrial processes.
Any market is more or less afected by an asymmetry of information between the
consumer/buyer and the producer/seller. This was the topic of very well-known studies in
economics (see for example [
The lack of accurate information along the chain also spreads from the consumers to the producers. This can cause the so-called bullwhip efect . The bullwhip efect is a distribution channel event that refers to shifts in inventory levels due to changes in consumers demand. Demand expectations succumb to supply chain ineficiencies 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’ raw material order is 70 units to reduce costs. The bullwhip efect 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. Ineficiency. 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 efect. 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.
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 [
For the craft beer sector, Yhop [
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. 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
experiment 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 [
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 [
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 [
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 particularly efective remedy to problems such as the above mentioned bullwhip efect. Smart contracts targeted to optimize supply chains are dealt with in [7, 8].
Yhop [
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 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 software, 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.
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.
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 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.
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 eficient 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.
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
Name
* PERMISSION
Name *
*
ACTION Name Parameters 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.
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
EOSIO ACCOUNT TRACKING SYSTEM
Blockchain Part
Permissions
ACTIVE
The Managin Operator
(PK) TRACKING
All Breweries (PK's) Action add(B,b, hb, de) Breweries Table ID, Pk
Tracking Records Brewery ID Batch ID Hash Expiratio Date Submission Timestamp a smart contract and can be queried by an of-chain client using standard node REST API.
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 of-chain system for storage.
with the secret key of the brewery and send it to the 5 signs the transaction
Tracking Support Service . 6 stores signed . 7 checks that parameters in are coherent with the corresponding batch description already stored in the of-chain systems and that this request was not already processing (case of repeated unintended submissions). Brewery Client (C) (web or mobile app) 4 Transaction
Creation add(B, b, hb, de, ts) 2
3 Hash Canonization
JSON skB
5 Signature exp Date
1 Batch Description
Brewery Owner Managing operator Tracking Support
Service
(S) Bu ering Filtering 6 7 Submitting 8
Storage System 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).
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 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.
In this paper, we show how it is possible to design a tracking system based on the EOSIO blockchain that is afordable 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 collaboration 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.
We would like to thank you Lorenzo Cannella for working on an early version of this project. 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 Rafaele Giafreda.
Blockchain-based traceability in Agri-Food supply chain management: A practical implementation. 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 technology 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-powerupmodel-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-valueapi/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, https://github.com/EOSIO/eos/blob/11d35f0f934402321853119d36caeb7022813743/ libraries/chain/include/eosio/chain/config.hpp#L51 last viewed 30 April 2022. [19] EOSIO. Oficial 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/#systemresources-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/senzacategoria/beerlife-grazie-alla-blockchain-tutta-la-vita-della-birra-che-si-sta-gustando-aportata-di-click/. [23] Indeed. What Is a Fragmented Market? | Indeed.com. https://www.indeed.com/careeradvice/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-eyopschain-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