Do you need a blockchain? Supply chain management

Hi Habr! I bring to your attention the translation of the article "Do you need a Blockchain"

Part 1 (Supply Chain Management)

Blockchain was presented as a technological innovation that could lead to a revolution in public relations and trade. This reputation partly refers to its properties that allow non-trusting parties to interact and change financial assets without relying on a trusted third party.

In this article, we will critically analyze whether a blockchain is really the best solution for a specific use case.

We distinguish between public (permissionless) Bitcoin \ Ethereum and private (permissioned) Hyperledger \ Corda blockchains and contrast their properties with properties of centrally managed databases. we will show a structured methodology for determining the optimal technical approaches for solving specific applied problems. We will analyze three cases - Supply Chain Management (Supply Chain Management), Interbank and International Payments (Interbank and International Payments), and Decentralized Autonomous Organizations (Decentralized Autonomous Organizations).

1. History blockchain
   
   The name blockchain comes from a chain of blocks. Each block is connected to the previous one through a cryptographic hash. A block is a data structure that allows you to store a list of transactions. Blockchain network nodes create and exchange transactions and change the state of the blockchain. transactions can make sense of monetary amounts, but are not limited to this application, and can, for example, execute user programs called smart contracts.
   
   The following differences are characteristic of the participants in the networks under consideration. As in any database, a “writer” (“writer”) is an entity that records a state in a database. In the blockchain, this refers to the participant involved in the consensus protocol and participating in filling the blockchain with data. The writer accumulates transactions in blocks and appends blocks in the blockchain. A writer may also be called a "validator." A “reader” is an entity that does not participate in filling the blockchain, but can participate either in the process of creating transactions, or simply reading, analyzing, or auditing the blockchain.
   
   Public blockchain systems
   
   Bitcoin and Ethereum are examples of public networks that are open and decentralized. Any node can join and leave the network and become a validator or reader at any time. There is no central government governing membership or restricting readers or writers. This openness implies the availability of records for reading by any node. The use of cryptographic primitives, however, makes it technically possible to create a public blockchain network with hidden private information (Zerocash)
   
   Private blockchain systems
   
   To limit the number of participants, the so-called private blockchain systems were proposed. Here the central authority distributes the rights and attributes of read and write operations to the blockchain. To ensure isolation and privacy, readers and writers may have separate parallel block chains linked together. The most widely known systems are the Hyperledger and Corda R3 products.
   
2. Properties
   
   Public Verifiability allows everyone to ensure that the current state of the system is correct. In distributed registries, each state is coordinated by validators, it being a limited subset from all users. Any observer, however, can make sure that the state of the registry changes in accordance with the protocol, and all observers will have the same type of registry. In centralized systems, different observers may have different kinds of state. Therefore, they cannot determine the correctness of the execution of transactions. Instead, they should trust the central authority.
   
   Transparency of data and the state update process is a requirement for public verifiability. However, the amount of information available to the browser can vary, and not every participant needs access to every piece of information.
   
   Confidentiality is an important part of any system. There is an internal contradiction between confidentiality and transparency. Confidentiality is certainly easier to achieve in a centralized system, because it does not require transparency and public verifiability.
   
   The integrity of the information ensures that the information is protected from unauthorized changes, i.e. that the data obtained is correct. Information integrity is closely related to public verifiability. If the system provides publicly verifiable, anyone can verify the integrity of the data; otherwise, integrity can only be maintained if the centralized system is not compromised.
   
   Data redundancy is important for many use cases. In blockchain systems, redundancy is inherently provided through replication on nodes. In centralized systems, redundancy is usually achieved by replicating to different physical servers and by creating backups.
   
   Trust Anchor determines who represents the highest authority.
   in this system, which has the right to grant and revoke permissions to read
   and write access to the system.
   
   The contradiction between transparency and confidentiality . There is an inherent compromise between transparency and confidentiality. A completely transparent system allows anyone to see any part of the information, i.e. confidentiality is not provided. Similarly, in a fully private system, it does not provide any transparency. However, the system can provide guaranteed confidentiality without leaking information about the status of each individual participant. Confidentiality in the public system can be achieved using cryptographic methods, but usually comes at the expense of lower efficiency. The Zerocash cryptocurrency, for example, uses computationally expensive cryptography to ensure complete anonymity, while also providing sufficient transparency for publicly checking the status of the registry.
   
3. Where the blockchain makes sense In general, the use of an open or closed blockchain makes sense when several mutually untrusting entities want to interact and change the state of the system, and not even use a trusted third party. To facilitate the decision making process, we provide the diagram in fig. 1. One or several parties are considered who write the state of the system, that is, the writer, this is an entity with the right to write to a typical database or consensus participant in the blockchain system.
   
   
   If there is no need to store data, the database is not required at all, that is, the blockchain, as a form of the database, is useless. Similarly, if there is only one writer, the blockchain does not provide additional guarantees and the usual base is better suited because it provides better performance in terms of throughput and latency. If a trusted third party (DTS) is available, there are two options. The first option is, if the DTS is always online, write operations can be transferred to it and it can function as a verifier for state transitions. Secondly, if the TPA is usually offline, it can function as a certification authority in setting the allowed blockchain, i.e., where all system writers are known. If all writers mutually trust each other, that is, they assume that no one participant is malicious, the write-access database is probably the best solution. If they do not trust each other, the use of a private blockchain makes sense.
   
   Depending on whether public verifiability is required, anyone may be allowed to read a state (public blockchain with rights delimitation) or readers may also be limited (private blockchain with rights delimitation) If the set of authors is not fixed and unknown to participants, as in the case of many cryptocurrencies, such as Bitcoin, a public blockchain is a suitable solution:
   
   
   
   In Table 1, we compare some properties of public and private blockchains and centralized databases. In a centralized system, performance in terms of latency and throughput is much better than in blockchain systems, since blockchain systems have additional complexity (communicative and computational) due to the consensus mechanism. For example, Bitcoin currently supports approximately 7 transactions per second (which could be expanded to about 66 without sacrificing security), while a centralized system such as Visa can process more than fifty thousand transactions at a peak. There is a trade-off between decentralization, i.e., how well the system scales up to writers without mutual trust and bandwidth, i.e. how many update states the system can handle at a given time. When deciding whether to use the blockchain system, this compromise should also be taken into account.
4. Use cases
   
   Supply chain management
   
   In supply chain management (SCM), the flow of materials and services required to produce this product includes various intermediate storage and production cycles up to the point of delivery to the end point of consumption. Typically, multiple companies interact and trade on the global market within a given supply chain. Because of this complexity, the associated costs of managing assets, processes, and failover are particularly expensive.
   
   Several companies (for example, Skuchain, Provenance, Walmart, Everledger) advertise blockchain-based solutions to improve the efficiency of supply chain management solutions. Some even argue that blockchain technology paves the way for a supply chain, instead of supply chains, where businesses will benefit from greater flexibility in interacting with different markets and balancing price risks. Traditional SCM is managed by scheduling and communications. Future demand is estimated based on past and current demand, information is sent to interested parties who hope to receive up-to-date information in time to respond to changes, delays or errors. Companies decide which product will be released to the market at what time, and customers indirectly manage demand.
   
   In managing the demand chain (DCM), customer interest is at the core — reduced prices, fast customer service, and faster market entry with an idea or minimally viable product (MVP) are just a few examples. DCM will increase flexibility by requiring all stakeholders to have real-time data to see what consumers want and buy. Thus, all participants in the demand chain should be closely connected to the network. Contrary to SCM, which “streamlines” and can be based on incomplete and inaccurate market assessments, DCM requires companies to have a complete and accurate view of the market and actively select the optimal production solutions. Thus, the information flow in DCM is of the pull type, not the push type: the interested parties do not need to wait for notifications, they can actively query the state of the system.
   
   
   
   SCM members vary greatly across different supply chains and the same participants can play different roles in different supply chains. The basis of segmentation for different actors in the supply chain, as a rule, is determined by their property in the proportion of the product that is produced. This means that for each supply chain in which the participant is involved, a separate blockchain is required - which clearly degrades the performance of the final solution.
   
   Following our methodology from Section 3, SCM, of course, data storage is required. Several validators are involved, that is, different SCM members owning a certain share of the final product. Skuchain is designed to use a single source of trust, which, however, eliminates the decentralized component of the blockchain, and thus will be equivalent to a trusted central server. Continuing our methodology, SCM is technically likely to always use online TTP. If this is not possible, at least all validators will be known, which leaves us the choice between a public or private blockchain. This reasoning leaves us with the question whether all validators can be trusted. Supply chain management has an inherent problem
   
   interface between the digital and physical world. One person, or some machine running one validator, as a rule, is required to register that a certain product has arrived at the warehouse, and, for example, its quality is appropriate. If there is no trust in the work of these employees, then the entire supply chain is technically compromised, since any data can be provided by the attacker. If, on the other hand, all validators are trusted, the blockchain is not needed - a regular shared database for writing will suit you.
   
   Please note that if in some way the connection between the digital and the physical world will be implemented in a safe way, then the previous reasoning should be revised.
   
   Interbank and international payments
   see continuation
   
   Decentralized autonomous organizations
   see continuation