Some basics:
translate:
Summary:
Blockchain's unique features, such as immutability, transparency, provenance, and authenticity, have been used by many large-scale data management systems to deploy a wide range of distributed applications, including supply chain management, healthcare, and crowdworking in permissioned environments . Unlike permissionless setups such as Bitcoin, the network is public and anyone can participate without a specific identity. A blockchain system consists of a known set of identified nodes, which may not fully trust each other. While the characteristics of permissioned blockchains are attractive to various large-scale data management systems, these systems must meet four main requirements: confidentiality, verifiability, performance, and scalability . Various methods have been developed by industry and academia to meet these requirements with different assumptions and costs. This tutorial focuses on introducing many of these techniques while highlighting the tradeoffs. We demonstrate the real-life utility of these techniques by presenting three different applications, supply chain management, large databases, and multi-platform crowdworker environments, and show how these techniques can be leveraged to meet the requirements of such applications.
introduce:
Blockchain is a distributed data structure for recording transactions maintained by multiple nodes without central authority. In a blockchain system, nodes agree on a shared state through a large network of untrusted participants. Blockchain was originally designed for the Bitcoin cryptocurrency, however, more recent systems have focused on its unique features such as transparency, provenance, fault tolerance, and authenticity to support a wide range of distributed applications. Bitcoin and other cryptocurrencies are permissionless blockchain systems. In a permissionless blockchain, the network is public and anyone can participate without a specific identity. Many other distributed applications, such as supply chain management and healthcare, are deployed on permissioned blockchain systems consisting of a known set of identified nodes that may still not fully trust each other. This tutorial focuses on a permissioned blockchain system that supports distributed applications across collaborative enterprises . However, these cooperative enterprises do not necessarily trust each other. We thus address four distinct challenges in the confidentiality, verifiability, performance, and scalability requirements of distributed applications in order to make permissioned blockchain systems practical in real life.
Data confidentiality is required in many collaborative distributed applications, such as supply chain management , where multiple enterprises collaborate to provide different services based on service-level agreements (SLAs). To deploy distributed applications across different collaborating enterprises, the blockchain system needs to support internal transactions within each enterprise as well as cross-enterprise transactions representing collaboration between enterprises. While data accessed by cross-enterprise transactions should be visible to all enterprises, internal data within each enterprise accessed by internal transactions may be kept private.
In addition to secrecy, in many cross-enterprise systems, such as crowdwork applications, participants need to verify transactions initiated by other enterprises to ensure that some pre-defined global constraints on the entire system are met. For example, under the Fair Labor Standards Act1 (FLSA), workers are limited to a total of 40 hours per week. So if a worker works for multiple crowdwork platforms, such as a driver working for Uber and Lyft, verifying such global restrictions requires access to data held by other businesses. Therefore, the system needs to support verifiability while maintaining the confidentiality of transactions.
In addition to confidentiality and verifiability, distributed applications (such as financial applications) require high performance in terms of throughput and latency , for example, the Visa payment service processes thousands of transactions per second, while a naive implementation of a permissioned blockchain Only handles hundreds of transactions per second. In general, "order" and "execution" are the two main phases in which permissioned chains process transactions. Permissioned blockchains need to parallelize the processing of different transactions at the order or execution stage to improve the overall performance of the system.
In the end, scalability is one of the main barriers to business adoption of blockchain systems . To support distributed applications, such as large databases, a blockchain system should be able to scale efficiently by adding more nodes to the system. Partitioning data into multiple shards maintained by different subsets of nodes is a proven way to enhance database scalability. In this approach, the performance of the database scales linearly with the number of nodes. While database systems use sharding techniques to improve the scalability of databases in crash-only node networks , blockchain systems cannot easily use this technique due to the potentially trustless nature of nodes in a network.
In this tutorial, our goal is to introduce to the database community a solid understanding of advanced solutions for designing efficient permissioned blockchain systems. We first discuss several large-scale data management applications that drive the increasing need for permissioned blockchains as infrastructure. We then provide a detailed description of the permissioned blockchain model and its fundamental cryptographic and distributed system components . Given the varying needs of different applications, we describe in detail various techniques behind the design of existing permissioned blockchain systems that address fundamental challenges such as confidentiality, verifiability, performance, and scalability . Each section of the tutorial discusses the trade-offs between the various techniques presented and the challenges that real systems face in supporting large data sets .
Tutorial overview
Confidentiality, verifiability, performance, and scalability are the main requirements for large-scale data management applications that need to be implemented through permissioned blockchain systems . While confidentiality and verifiability are required for cross-enterprise applications such as supply chain management and crowdwork (to maintain the confidentiality of enterprise data and to verify transactions initiated by other enterprises while preserving the confidentiality of their data), single-enterprise applications and cross-enterprise applications require performance and scalability.
In this section, we first introduce several practical large-scale data management applications to incentivize permissioned blockchains. Next, we introduce permissioned blockchains and introduce different techniques proposed by permissioned blockchain systems to meet the requirements of large-scale data management applications.
application
We now briefly discuss several large-scale data management applications to incentivize permissioned blockchains (permissioned chains).
supply chain management
Lack of trust between parties is one of the most important issues in supply chain management. To address such issues, permissioned blockchains can be used to monitor the execution of collaborative processes and check the consistency between execution and SLAs. The blockchain system used needs to support internal and cross-enterprise transactions , each enterprise's internal transactions are confidential compared to cross-enterprise transactions visible to all participants, for example, a manufacturer's internal transactions demonstrate its production Manufacturer Internal processes of a product that may be intended to be kept secret. Finally, blockchain systems must also address performance issues.
large scale database
Sharding technology is widely used in distributed databases, such as Google's Spanner and Facebook's Tao, to solve scalability problems. Such systems primarily employ a crash-failure model and rely on trusted coordinators to handle transactions across shards. In the presence of untrusted infrastructure (i.e. Byzan-tine nodes), blockchain systems can be used to achieve scalability while tolerating malicious failures. If confidentiality of data fragments is required, scalability technology should also be integrated with confidentiality technology.
Multi-platform Crowdwork
Crowdwork enables open collaboration on the Internet. A crowdwork system includes a platform, requesters, and workers, where requesters submit tasks and workers send task-specific contributions to the platform. Therefore, a crowdworker system may need to perform thousands of transactions per second, and thus must be highly performant . Additionally, multi-platform group work systems should scale appropriately as the number of platforms, employees, and requesters increases . Additionally, the system must provide verifiability of transactions against predetermined global limits . For example, workers who may work for multiple crowd work platforms are limited to a total of 40 hours per week under the Fair Labor Standards Act 2 (FLSA) or California Proposition 223, which imposes minimum hours on work for health benefits Developed their own set of regulations, for example, companies (i.e. platforms) had to subsidize healthcare if drivers worked at least 25 hours a week. In summary, a multi-platform swarm working system requires all four properties of confidentiality, verifiability, performance, and scalability.
permissioned blockchain
The blockchain system is a peer-to-peer system on a global scale that integrates many technologies and protocols in encryption, distributed systems, and databases . In a blockchain system, nodes agree on a shared state through a large network of potentially untrusted participants. Bitcoin and other cryptocurrencies are permissionless blockchain systems. A permissionless blockchain system is public, and computing nodes without a priori known identities can connect or leave the blockchain network at any time. On the other hand, permissioned blockchain systems use a network of a priori known and identified nodes to manage the blockchain . The main underlying data structure in a blockchain system is the blockchain ledger, an append-only fully replicated structure that is shared among all participants and guarantees a consistent view of all user transactions by all participants in the system . Each block in the blockchain ledger contains a batch of transactions, and the total order of transaction blocks in the blockchain ledger is captured by chain blocks together, that is, each block contains the cryptographic hash of the previous block. Figure 1 illustrates an example of a permissioned blockchain system consisting of five nodes, each of which maintains a copy of the blockchain ledger .
The blockchain architecture consists of a group of nodes in an asynchronous large distributed system. A node in the system may crash, i.e. when a node fails, it stops processing entirely, or it may behave maliciously, i.e. when a node fails, it may behave arbitrarily, often referred to as a Byzantine failure model . To ensure consistency between replicated data on different nodes, blockchain systems use the State Machine Replication (SMR) algorithm (in which nodes agree on the ordering of incoming transactions) to ensure that copies of the distributed ledger are identical. SMR oversees the deterministic execution of customer transactions on different nodes, so that every non-faulty node executes each transaction in the same order. In a permissioned blockchain system, nodes agree on a unique order in which transactions are appended to the blockchain ledger using an asynchronous fault-tolerant protocol such as Paxos or PBFT.
technology
Over the past few years, permissioned blockchain systems have proposed various technologies to address the four main requirements of large-scale data management systems. In this section, we discuss these techniques in detail and introduce systems that leverage them to meet four main requirements: confidentiality, verifiability, performance, and scalability.
2.3.1 Confidentiality
Confidentiality of data is required in many collaborative distributed applications, for example, supply chain management, where multiple enterprises collaborate to provide different services under service level agreements (SLAs). In order to deploy distributed applications across different collaborating enterprises, the blockchain system needs to support the internal transactions of each enterprise as well as cross-enterprise transactions representing the collaboration among enterprises. While data accessed across enterprise transactions should be visible to all enterprises, data within each enterprise (accessed by internal transactions) may be confidential. In particular, in collaborative distributed applications, each enterprise can maintain its own independent disjointed blockchain and use technologies such as atomic cross-chain transactions or the Interledger protocol to support cross-enterprise collaboration. These technologies are often costly, complex and primarily designed for permissionless blockchains. On the other hand, technologies that support collaborative enterprises on a single blockchain either do not support intra-enterprise transactions , or suffer from confidentiality issues since the entire ledger is visible to all enterprises, e.g., single channel Fabric.
To achieve confidentiality, encryption and view-based (i.e., shard-based) techniques have been proposed . In cryptography, data is encrypted or hashed so that it cannot be accessed by unrelated parties. Alternatively, view-based techniques have been used to achieve confidentiality, where each party (i.e., an enterprise or group of enterprises) maintains only its own view of the data (including records to which that party has access), and therefore, encryption is not necessary. We introduce Caper, the multi-channel Hyperledger Fabric
and private data collection (used in every channel of Hyperledger Fabric).
view-based approach. We first discuss the view-based approach. In Caper, each enterprise maintains two types of private and public data, and the system supports internal and cross-enterprise transactions, where internal transactions are executed by a single enterprise, while cross-enterprise transactions are executed by all enterprises . In Caper, each enterprise orders and executes its internal transactions locally, while cross-enterprise transactions are public and visible to each enterprise. In addition, Caper's blockchain ledger is a directed acyclic graph, including each enterprise's internal transactions and all cross-enterprise transactions . Nevertheless, for the sake of confidentiality, the blockchain ledger is not maintained by any nodes. In fact, each enterprise maintains its own local ledger view, including its internal and all cross-enterprise transactions. Since ordering cross-firm transactions requires a global agreement among all firms, Caper introduces a different consensus protocol to globally order cross-firm transactions.
Hyperledger Fabric introduces channels to preserve confidentiality. A multi-channel Hyperledger Fabric consists of multiple channels, each with its own set of businesses. In a channel, each enterprise has its own set of executor (i.e., endorser) nodes, where the enterprise's transactions are executed by its endorser nodes . Therefore, the business logic implemented in its smart contracts is private to other businesses. However, businesses within a channel share the same blockchain ledger and blockchain state (i.e. data storage), so any transaction in a channel will be replicated on the ledgers of all channel members (i.e. businesses). On the other hand, different channels are completely separate and have neither access to the blockchain ledger nor the blockchain state of other channels. Different channels may still share the same set of order nodes. The orderer agrees on the order of transactions for the channels. Since orderers have access to transaction data, all channel members should trust them. It should also be noted that firms may be members of different channels, for example, manufacturers participating in different supply chain management schemes. Furthermore, handling (public) transactions between two channels requires the use of trusted channels or an atomic commit protocol between participants.
Encryption Technology. Encryption can be used when, in a cross-enterprise application, a part of the enterprise wishes to conduct confidential transactions and keep the transaction data private. In Hyperledger Fabric specifically, if a subset of businesses on a channel need to keep data private from other businesses on the same channel, they can choose to create a new channel that includes only those businesses that need access to the data . However, creating separate channels causes additional management overhead and data integrity (between public and private data) issues. Hyperledger Fabric proposes private data collection to manage confidential data that two or more businesses on a single channel want to keep private from other businesses on the same channel. Private data collection uses hashing , which is an encryption technique. By defining private data collection, a subset of businesses on the channel store their confidential data in private databases replicated on each authorized peer . A hash of the private data is still appended to the blockchain ledger of every peer on the channel. Hashes are used as proof of transactions and for state verification. Using hashes, other businesses are still able to check for read-write collisions during the verification phase. An enterprise may involve different collections of private data, where each collection replicates a private database on its peers.
discuss. All in all, view-based techniques are costly in managing views , for example, configuring channels in Hyperledger Fabric. Furthermore, dealing with open transactions requires building consensus among all relevant opinions (eg, businesses, channels). Compared to Hyperledger Fabric, Caper preserves confidentiality (logic and data) at the enterprise level. On the other hand, cryptography, while reducing the cost of managing views, incurs the overhead of maintaining data in the blockchain ledger and blockchain state for unrelated businesses.
2.3.2 Verifiability
In many cross-enterprise systems, firms need to verify cross-sector actions initiated by other firms to ensure that global constraints are met in a privacy-preserving manner. This could happen in a crowdsourced work environment , where multiple distrusted platforms need to work together to enforce global regulations where, for example, a single worker can work up to 40 hours a week. Therefore, blockchain systems need to employ verifiable technologies while protecting the privacy of participants. Verifiability is also required in cryptocurrencies with enhanced privacy, such as Zcash, where transaction data is confidential and nodes need to verify transactions without knowing the sender, receiver, or transaction amount .
To achieve verifiability, cryptographic techniques (zero-knowledge proofs) have been proposed. In cryptography, a zero-knowledge proof is a method by which one party (the prover) can prove to another party (the verifier) that they know the value x, conveying no information other than that they know the value x. Verifiability can also be achieved using token-based techniques , where a centralized entity generates verifiable tokens based on global constraints and distributes them to the corresponding participants. We introduce Quorum and Separ, and discuss how to solve the verifiability problem in these two systems.
Encryption Technology. Quorum as a permissioned blockchain based on Ethereum introduces two consensus protocols: a Raft-based crash-fault-tolerant protocol and a Byzantine- fault-tolerant protocol called Istanbul BFT . Quorum supports public and private transactions, where both public and private transactions are ordered using the same consensus protocol. Quorum uses zero-knowledge proof technology to ensure the verifiability of private transactions . Zero-knowledge proofs allow digital assets to be transferred on a distributed ledger without revealing any information about the sender, receiver, or the amount of the asset, while ensuring that: the sender has the right to transfer ownership of the asset, the asset has not been previously spent (double spending) ), the transaction input is equal to its output (conservation of mass). Zero-knowledge proofs are also used in crowdwork platforms such as ZebraLancer, ZKCrowd, and Prio to provide verifiability in a single-platform environment.
Token-based technology. Separ is a blockchain-based multi-platform crowdwork system that uses token-based technology to ensure verifiability. In Separ, a centralized trusted authority models global regulations using anonymous tokens and distributes them to participants. For example, if a global constraint states that workers must not work more than 40 hours in total per week to comply with FLSA, the permissions will allocate 40 tokens to each worker, which workers can use whenever they participate in a task token. Separ consists of a privacy-preserving token-based system on top of a cross-platform shared blockchain ledger , where the global state of the system is managed across crowdwork platforms using a distributed consensus protocol.
discuss. In conclusion, cryptography is truly decentralized and, therefore, does not require a trusted entity. However, zero-knowledge proofs have considerable overhead. Using such techniques, especially in environments where most transactions are likely to be local, is not beneficial due to its overhead. On the other hand, token-based techniques require a centralized authority to generate tokens. A centralized authority must be trusted by all participants. However, there is no need to replicate all transactions on each node, improving performance.
2.3.3 Performance
Many large data management applications require high performance in terms of throughput and latency, such as financial applications. Permissioned blockchain systems process transactions using an optimistic or pessimistic approach. These methods provide trade-offs in performance based on the degree and frequency of contention and conflicts between transactions. In an optimistic approach, nodes execute transactions without running a consensus protocol to explicitly establish ordering, while in a pessimistic approach, transactions are first ordered and then executed.
From an architectural perspective, three main architectures have been proposed for permissioned blockchain systems. The Order Execution (OX) and Order Parallel Execution (OXII) architectures follow a pessimistic approach, while the Execution-Order Validation (XOV) architecture follows an optimistic approach. We show how Tendermint, ParBlocckhain, Hyperledger Fabric, Fast Fabric, Fabric++, FabricSharp, and XOX Fabric address the performance challenges of permissioned blockchain systems.
pessimistic attitude. In an OX permissioned chain, a group of nodes (i.e., orderers) establish agreement on the unique ordering of incoming transactions using a fault-tolerant protocol. Depending on the node's failure model, Byzantine, such as PBFT, Hotstuff, collapse, such as Paxos, Raft, or even hybrid, such as SeeMoRe, UpRight, fault-tolerant protocols can be used. The collator node then generates blocks and multicasts them to other nodes (i.e. executors). The executor nodes sequentially execute the block's transactions in the same order, append the transactions to the blockchain ledger, and update the blockchain state (i.e., data storage). Order Execution Architecture (OX) is widely used in different permissioned blockchain systems such as Tendermint, Quorum, Multichain, Chain Core, Hyperledger Iroha and Corda. In particular, Tendermint uses a PBFT-based consensus protocol that differs from the original PBFT in several ways. First, only a subset of nodes, called validators, participate in the consensus protocol, and to become a validator, a node needs to lock its coins. Second, Tendermint uses the leader rotation technique and switches the leader in a round-robin fashion after each round (i.e. each attempt to build a block). Third, Tendermint implements a proof-of-stake consensus mechanism. In fact, in Tendermint, validators do not have the same "weight" in the consensus protocol, a validator's voting power corresponds to its bounded number of coins. As a result, one-third or two-thirds of validators are defined as a proportion of total voting power rather than the number of validators .
The Order Parallel Execution (OXII) architecture is similar to the Order Parallel Architecture and follows a pessimistic approach. In the OXII architecture, a disjoint set of nodes (orderers) establishes agreement and builds blocks on the order of incoming transactions. Once a block is constructed, the orderer node generates a dependency graph for the transactions within the block. Dependency graphs give partial ordering based on conflicts between transactions and allow non-conflicting transactions to be executed in parallel. Transactions are then executed by executor nodes following the generated dependency graph . ParBlockchain follows the OXII architecture and can support multi-enterprise systems. In a multi-enterprise system, each enterprise has its own set of executor nodes, where the transactions of each enterprise are executed by the corresponding executor nodes.
optimistic approach. Finally, Hyperledger Fabric proposes the optimistic XOV architecture (first introduced by Eve in the context of Byzantine Fault Tolerant SMR) by switching the order of the "order" and "execution" phases. In Fabric, the transactions of different enterprises are first executed in parallel by each enterprise's executor node (ie endorser). Transactions are then ordered through a consensus protocol (currently a Raft-based protocol) and multicast to all endorsers. The endorser then verifies the transaction and appends it to the ledger.
While Fabric improves performance by executing transactions in parallel and supports non-deterministic execution of transactions , in the presence of any contention (i.e. conflicting transactions ) in the workload (which is common in distributed applications), it must Ignore the impact of conflicting transactions, which can negatively affect the performance of the blockchain . This happens because Fabric executes transactions in the first step and validates them in the last step, so if there is any read-write dependency between transactions of the same block, it will not be detected until the last step. Different techniques have been proposed to improve the performance of Fabric while still following its XOV architecture.
FastFabric parallelizes the transaction validation pipeline using different data structures and caching techniques to improve Fabric's throughput for conflict-free transaction workloads. Fabric++ employs concurrency control techniques from the database to abort transactions early or reorder transactions after the sort phase to reconcile potential conflicts. FabricSharp goes a step further and provides an algorithm for early filtering out transactions that can never be reordered, and a reordering technique that eliminates unnecessary aborts (due to Fabric++'s strong serializability guarantees, Whereas Fabric requires serializability guarantees). Finally, the XOX Fabric model consists of a pre-order and a post-order execution step, where order post-execution is added after the validation step to re-execute transactions that were invalidated due to read-write conflicts.
discuss. In summary, OX architecture has lower performance due to the sequential execution of all transactions, while both OXII and XOV architectures are able to execute transactions in parallel. OXII also supports contentious workloads by detecting conflicting transactions in the order phase and generating a dependency graph, while XOV verifies read-write conflicts, resulting in poor performance . On the other hand, XOV supports non-deterministic execution of transactions by executing them first and detecting any inconsistencies early on, whereas in OXII transactions are executed at the last step, so aborting a transaction would be costly if the result is inconsistent .
2.3.4 Scalability
Scalability is one of the main barriers to enterprise adoption of blockchain systems, especially in finance and large database systems. Permissioned blockchain systems primarily use clusters to improve scalability. In a clustering approach, such as Blockplane, nodes are partitioned into fault-tolerant clusters, where each cluster processes (or at least orders) a disjoint set of transactions. Permissioned blockchain systems use single ledger or sharded ledger technology to enhance scalability. In single ledger technology , the entire ledger is replicated across all clusters, and all nodes execute every transaction. On the other hand, in sharded ledger technology , the ledger is divided into multiple shards maintained by different clusters. The shard ledger allows the blockchain system to handle both intra-shard and cross-shard transactions . Cross-shard transactions can be handled centrally using a coordinator-based approach or decentralized using a flat approach . We discussed ResilientDB, AHL, SharpPer, Saguaro, and multi-channel Fabric in detail.
single ledger approach. ResilientDB uses a topology-aware clustering approach and partitions the network into local fault-tolerant clusters to minimize the cost of global communication. However, all clusters replicate the entire ledger on each node, and in each round, each cluster locally establishes consensus on a single transaction, and then multicasts the locally replicated transaction to other clusters. Then, all clusters, execute all transactions for that round in a predetermined order. Since all transactions are executed by all clusters, there is no concept of intra-shard and cross-shard transactions in ResilientDB.
Sharded ledger approach. AHL uses sharding to enhance scalability. In AHL, similar to permissionless blockchains Elastico, OmniLedger, and Rapidchain, nodes are randomly assigned to clusters (called committees). To ensure high-probability security, each committee must contain at least 80 nodes (instead of 600 nodes in OmniLedger). In order to reduce the number of nodes required in each committee, AHL employs trusted hardware (the technology provided in it) to limit the malicious behavior of nodes. With trusted hardware, malicious nodes cannot multicast inconsistent messages , e.g., messages with inconsistent sequence numbers, to different nodes. AHL acts as a coordinator by relying on an additional set of nodes called the Centralize the processing of cross-shard transactions . The reference committee handles cross-shard transactions across related clusters using the classic two-phase commit (2PC) and two-phase locking (2PL) protocols.
SharPer is another shard-permissioned blockchain system, where the system consists of a set of fault-tolerant clusters, each of which maintains a shard of the blockchain ledger. Compared with AHL, SharPer provides deterministic safety guarantees by considering a pre-determined fault-tolerant cluster or assuming that the number of nodes is much larger than the number of failures. SharPer uses a decentralized flat consensus protocol to process cross-shard transactions in a decentralized manner across the involved clusters (no reference committee required).
In Saguaro, nodes are organized in a hierarchical structure following the WAN infrastructure from edge devices to edge, fog, and cloud servers, where nodes at each level are further clustered into fault-tolerant clusters. At a lower level, Saguaro, similar to SharPer, maintains shards of the blockchain ledger on each cluster. However, Saguaro benefits from the network's hierarchical structure when processing cross-shard transactions . For each cross-shard transaction, the inner cluster with the smallest total distance to the related cluster, i.e., the lowest common ancestor among all participating clusters, is chosen as the coordinator, thereby reducing latency.
Finally, in a multi-channel fabric , channels are introduced primarily to enhance confidentiality, but they can also be used to shard the system and data. A channel is effectively a shard of the entire system , autonomously managed by a set of (logically) independent nodes, but still aware of the larger system it belongs to. Using channels, Fabric efficiently handles intra-shard transactions using a fault-tolerant protocol . Cross-shard transactions in a multi-channel Fabric are handled in a centralized manner and require trusted channels between participants to play the coordinator role or an atomic commit protocol.
discuss. The main difference between sharded ledger approaches is how they handle cross-shard transactions. Centralized processing of transactions across shards is simpler and closer to traditional two-phase commit, i.e., requires a coordinator cluster to tolerate Byzantine failures rather than a single coordinator node, however, requires a large number of inter- and cross-cluster communication phases. On the other hand, a decentralized approach does not require an additional set of nodes, processes transactions with a smaller number of stages in the involved clusters, and is able to process cross-shard transactions in parallel with non-overlapping clusters. However, establishing cross-shard consensus between related clusters requiring multiple rounds of message passing can result in high latency if the clusters involved are far apart . On the other hand, single-ledger approaches such as ResilientDB do not suffer from the latency of processing cross-shard transactions by replicating the entire data on each cluster. However, exchanging messages across all clusters still results in high latency for each transaction .
Tutorial information
This is a three-hour tutorial aimed at researchers, designers, and practitioners interested in permissioned blockchains and their applications to large-scale data management systems. Target audiences with a basic background in blockchain and distributed systems should benefit most from this tutorial. For general audiences and novices alike, this tutorial explains the design space of permissioned blockchains in large-scale data management systems.
This tutorial is different from previous tutorials that have covered the same topic at database conferences. The tutorial presented by Maiyya et al. at VLDB 2018 is mainly about permissionless blockchains, covering details of Bitcoin, PoW consensus, and several Bitcoin alternatives to increase the throughput of Bitcoin. The tutorial then introduces solutions such as atomic swaps and the Lightning Network to address the challenges posed by the rise of multiple blockchain systems. The next version of this tutorial, published at SIGMOD 2019 [44], partially covers permissioned blockchains, where several systems such as Hyperledger Fabric, ParBlockhain, and Caper are presented only as examples of permissioned blockchains. However, in this tutorial, more than 20 permissioned blockchains and their underlying technologies are introduced to meet the requirements of large-scale data management systems, and the different trade-offs between various technologies are discussed. This tutorial also differs from C. Mohan's tutorials at VLDB 2017 and ICDE 2018 [46], where he explicitly states that the scope of his tutorial is "generic in nature, without delving into cryptographic algorithms or distributed consensus protocols."
Details". Finally, this tutorial differs from the one presented at VLDB 2020 by Gupta et al., which focuses on exploring high-throughput consensus protocols for permissioned blockchains.