Throughput-efficient and scalable byzantine fault tolerant blockchain protocols

Abstract

A method of operating a blockchain system with decentralized computing nodes includes determining an elected clan representing a. subset of the plurality of the decentralized computing nodes that are capable of approving addition of the block to the blockchain with less than or equal to a threshold probability of failure and performing a block approval process which includes determining a vertex comprising a digest of the block, communicating the vertex to each computing node, communicating the block only to the nodes in the elected, clan, while preventing communication of the block to the nodes that are not members of the elected clan, and receiving one or more messages indicating receipt of the vertex and / or receipt of both the vertex and the block.

Description

[0001] Docket No. UC-024-PCT

[0002] THROUGHPUT-EFFICIENT AND SCALABLE BYZANTINE FAULT

[0003] TOLERANT BLOCKCHAIN PROTOCOLS

[0004] CROSS-REFERENCE TO RELATED APPLICATIONS

[0005]

[0001] This application claims priority U.S. Provisional Patent Application No. 63 / 705,599, filed October 10, 2024, which is hereby incorporated in its entirety by reference.

[0006] TECHNICAL FIELD

[0007] [2| The present disclosure relates to blockchain and distributed computing systems. More particularly, in certain embodiments, the present disclosure relates to methods and systems for achieving consensus in decentralized blockchain networks using scalable, bandwidth-efficient Byzantine Fault Tolerant (BFT) protocols based on directed acyclic graphs (DAGs) and committee-based data dissemination.

[0008] BACKGROUND

[0009] |3| Distributed computing systems are increasingly used to provide services across a network of independent computing nodes. In such systems, it is desirable for a group of nodes to be able to reach agreement, or consensus, on the order and content of transactions or operations, even in the presence of faulty or malicious participants. Byzantine Fault Tolerant (BFT) state machine replication protocols have emerged as a foundational technology for achieving consensus in these environments, sometimes allowing networks to tolerate a subset of nodes that may behave arbitrarily or even maliciously.

[0010] [4| Blockchain technology leverages BFT consensus protocols to maintain a decentralized ledger of transactions that is resistant to tampering and censorship. Traditional BFT protocols, such as those based on a single leader or proposer, have demonstrated strong security and liveness properties but often suffer from limited throughput and scalability. These limitations become particularly pronounced as the number of participating nodes increases, due to the communication and bandwidth overhead required to replicate data and coordinate agreement among all nodes.

[0011] I Docket No. UC-024

[0012] |5j To address these challenges, recent research has explored the use of directed acyclic graph (DAG)-based consensus protocols. In DAG-based systems, multiple nodes can propose transactions concurrently. The resulting proposals are organized into a graph structure that captures dependencies and ordering relationships. While this approach can provide some benefits, existing DAG-based BFT protocols may still experience significant performance degradation as the size of the network grows because of the need to replicate large amounts of data across al l nodes.

[0013] |6| Ensuring both high throughput and strong security in large-scale, decentralized networks remains a significant technical challenge. The need to balance efficient data dissemination, robust fault tolerance, and low communication complexity continues to drive innovation in the design of consensus protocols for blockchain and other distributed ledger systems.

[0014] SUMMARY

[0015] |7| This disclosure addresses several technical challenges and drawbacks of previous technologies, including those described above. As a first example, traditional BFT and even state- of-the-art DAG-based BFT protocols experience a significant drop in throughput and increased bandwidth consumption as the number of participating nodes increases because large blocks of data must be replicated across all nodes. The present disclosure provides a technical solution to this problem by communicating the block of data only to an “elected clan” (i.e., a selected subset of all the nodes of the network), while the rest of the network receives only the vertex (metadata). This selective dissemination of the data to the elected clan reduces overall bandwidth usage and allows the system to scale to larger numbers of nodes without a corresponding drop in throughput.

[0016] |8| As a second example, the present disclosure may proactively address security issues which might otherwise result from decreasing the number of nodes to which the data is disseminated. To proactively resolve this possible technical problem, the elected clan is chosen such that it can approve the block with less than or equal to a threshold probability of failure. For example, security may be maintained with only a negligible probability of failure by employing specialized clan size and quorum requirements and / or by leveraging a tribe-assisted RBC protocol. For example, in some embodiments, the clan is selected using randomization or pseudo-randomization. Docket No. UC-024

[0017] Probabilistic analysis (e.g., hj'pergeometric distribution) during clan selection may be used to help ensure security.

[0018] [9j As a third example, existing reliable broadcast (RBC) primitives used in BFT protocols can be inefficient and require multiple rounds with high communication complexity, especially as the network grows in size. Embodiments of this disclosure provide solutions to this technical problem. For example, in some embodiments, a new tribe-assisted reliable broadcast primitive is used which leverages the entire network to assist the clan in achieving reliable broadcast. As another example, in some embodiments, round-optimal protocols (e.g., two-round or three-round R.BC, optionally with digital signatures) may be used to reduce communication complexity and latency.

[0019]

[0010] As a fourth example, embodiments of this disclosure may improve consensus determination in a sharded blockchain. In a sharded blockchain, the blockchain database is partitioned into smaller, independent segments called shards, allowing for parallel processing of transactions and significantly improving scalability, transaction speed, and network capacity compared to traditional, non-sharded blockchains. Existing consensus protocols may not efficiently support sharded blockchains or systems with multiple sequencers, which require partitioned data dissemination and execution. Embodiments of this disclosure use a multi-clan approach to sharded blockchains or shared sequencer systems to achieve efficient, secure, and scalable operation in these architectures.

[0020] [111 As a fi fth example, embodiments of this disclosure use disjointed clans (e.g., a multi-elan architecture), each independently handling data dissemination, approval, and execution for assigned blocks or transactions. This enables parallel processing and more efficient workload distribution across the network

[0021] [12J In one aspect, the disclosure provides a method of operating a blockchain system comprising a plurality of decentralized computing nodes. The method includes, by at least one of the decentralized computing nodes, receiving data to add as a block of a blockchain. The method further includes determining an elected clan, which represents a subset of the plurality of decentralized computing nodes, where the elected clan is capable of approving addition of the Docket No. UC-024 block to the blockchain with less than or equal to a threshold probability of failure (e.g., or a greater than or equal to a threshold probability that the elected clan satisfies a simple honest majority). The method also comprises performing a block approval process that includes a plurality of rounds. In each round, a vertex comprising a digest of the block is determined and communicated to each computing node of the blockchain system. The block itself is communicated only to the decentrali zed computing nodes in the elected c lan, while communication of the block to nodes not in the elected clan is prevented, thereby reducing bandwidth consumption by the blockchain system. The method further includes receiving one or more messages indicating receipt of the vertex and / or receipt of both the vertex and the block, determining that the block approval process is complete based on a number of messages received, and, after determining that the approval process is complete, adding the block to the blockchain.

[0022] 1131 In some embodiments, the block approval process further includes transmitting, by a sender node, a value comprising the block to each node of the elected clan and a digest of the block to nodes not in the elected clan. Upon receiving the value or the digest, each node transmits an ECHO message comprising the digest of the block to all nodes of the blockchain system. Upon receiving at least a threshold number of ECHO messages from nodes in the elected clan, each node transmits a READY message to all nodes of the blockchain system, and upon receiving at least a threshold number of READY messages, the block approval process is determined to be complete. In. some embodiments, if a node in the elected clan has not received the block but has received at least the threshold number of R EAD Y messages, the node is configured to download the block from another node in the elected clan.

[0023]

[0014] In some embodiments, the block approval process is performed using a round-optimal reliable broadcast protocol that completes in two rounds, and messages exchanged during the protocol are digitally signed by sending nodes. Alternatively, the block approval process may be performed using a reliable broadcast protocol that completes in three rounds, and the protocol does not require messages exchanged during the protocol to be digitally signed by sending nodes.

[0024]

[0015] In some embodiments, the method further includes partitioning the plurality of decentralized computing nodes into a plurality of elected clans, where each elected clan independently receives, disseminates, and approves a respective block according to the block Docket No. UC-024 approval process, hi some embodiments, the approval processes for the plurality of elected clans are performed in parallel, such that each clan concurrently receives, disseminates, and approves its respective block independently of the other clan.

[0025] |16| In some embodiments, the plurality of decentralized computing nodes are organized as a sharded blockchain, with each elected clan corresponding to a respective shard. In some embodiments, the plurality of decentralized computing nodes comprise a system with multiple sequencers, with each elected clan corresponding to a respective sequencer.

[0026]

[0017] In some embodiments, the elected clan is selected randomly or pseudo-randomly from the plurality of decentralized computing nodes. In some embodiments, the method further includes executing a transaction based on the received block by only the decentralized computing nodes in the elected clan.

[0027]

[0018] Ln another aspect, the disclosure provides a system for implementing a blockchain, the system comprising a plurality of decentralized computing nodes. At least one of the decentralized computing nodes comprises a processor configured to receive data to add as a block of a blockchain. The processor is further con figured to determine an elected clan representing a subset of the plurality of decentralized computing nodes that are capable of approving addition of the block to the blockchain with less than or equal to a threshold probabi l ity of fai lure. The processor is also configured to perform a block approval process comprising a plurality of rounds, wherein in each round at least a portion of the plurality of decentralized computing nodes is configured to determine a vertex comprising a digest of the block, communicate the vertex to each computing node of the blockchain system, communicate the block only to the decentralized computing nodes in the elected clan while preventing communication of the block to nodes not in the elected clan, receive one or more messages indicating receipt of the vertex and / or receipt of both the vertex and the block, determine that the block approval process is complete based on a number of messages received, and, after determining that the approval process is complete, add the block to the blockchain.

[0028]

[0019] In some embodiments, at least the portion of the plurality of computing nodes are further configured to perform the block approval process by transmitting, by a sender node, a value Docket No. UC-024 comprising the block to each node of the elected clan and a digest of the block io nodes not in the elected clan. Upon receiving the value or the digest, each node transmits an ECHO message comprising the digest of the block io all nodes of the blockchain system. Upon receiving at least a threshold number of ECHO messages from nodes in the elected clan, each node transmits a READY message to all nodes of the blockchain system, and upon receiving at least a threshold number of READY messages, the block approval process is determined to be complete.

[0029] [20J In some embodiments, if a node in the elected clan has not received the block but has received at least the threshold number of READY messages, the node is configured to download the block from another node in the elected clan.

[0030] 121 J In some embodiments, the processor is further configured to perform the block approval process using a round-optimal reliable broadcast protocol that completes in two rounds, and messages exchanged during the protocol are digitally signed by sending nodes. Alternatively, the processor may perform the block approval process using a reliable broadcast protocol that completes in three rounds, and the protocol does not require messages exchanged during the protocol to be digitally signed by sending nodes.

[0031] [221 In some embodiments, the plurality of decentralized computing nodes are partitioned into a plurality of elected clans, where each elected clan is configured to independently receive, disseminate, and approve a respective block according to the block approval process. In some embodiments, the processor is further configured to perform the approval processes for the plurality of elected clans in parallel, such that each clan concurrently receives, disseminates, and approves its respective block independently of the other clan.

[0032] 1231 In some embodiments, the plurality of decentralized computing nodes are organized as a sharded blockchain, with each elected clan corresponding to a respective shard. In some embodiments, the plurality of decentralized computing nodes comprise a system with multiple sequencers, with each elected clan corresponding to a respective sequencer.

[0033] (241 In some embodiments, the processor is further configured to determine the elected clan randomly or pseudo-randomly from the plurality of decentralized computing nodes. In some Docket No. UC-024 embodiments, the processor is further configured to execute a transaction based on the received block by only the decentralized computing nodes in the elected clan.

[0034] BRIEF DESCRIPTION OF THE DRAWINGS

[0035]

[0025] Non-limiting and non-exhaustive examples are described with reference to the following figures.

[0036] [26| FIG. 1 is a plot of clan size versus the number of nodes in the network for an example implementation of the present disclosure.

[0037]

[0027] FIG. 2 is a diagram of an exemplary sy stem for implementing the improved blockchain protocols of this disclosure, according to an illustrative embodiment.

[0038]

[0028] FIG. 3 is a flowchart of an exemplary method for implementing the improved blockchain protocols of this disclosure, according to an illustrative embodiment.

[0039] |29[ FIGS. 4 A, 4B, and 4C are plots of latency versus throughput for different DAG-based BFT protocols for networks having different numbers of nodes (n ~ 50, 100, and 150. respectively) for example implementations of the present disclosure.

[0040]

[0030] FIG. 5 is a bar graph of throughput as a function of the number of inputs per transaction for different DAG-based BFT protocols at n::::150.

[0041] DETAILED DESCRI PTION

[0042] [311 The following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the present disclosure. Examples may be practiced as methods, systems or devices. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents. Docket No. UC-024

[0043]

[0032] As described above, existing DAG-based BFT protocols experience reduced performance as the system scales, primarily due to the bandwidth-intensive replication of data across all participating parties. This disclosure recognizes that it is sufficient to replicate data only to a subcommittee (referred to herein as a “clan”) with an honest majority. This disclosure also recognizes that relatively small committees, or clans, can be formed that maintain an honest majority with a sufficiently high probability of success.

[0044] [33| In embodiments, this disclosure provides a new primitive referred to as tribe-assisted reliable broadcast, which ensures RBC properties within a clan, which is an honest majority subcommittee of all network nodes, hi this disclosure, the entire set of nodes in the network is sometimes referred to as a tribe. The new primitive is used to replace the standard RBC primitives used in previous DAG-based BFT protocols. The disclosure includes a single-clan protocol, where a single clan is elected from the tribe and data is disseminated exclusively to this designated clan using tribe-assisted reliable broadcast. In other embodiments, a multi-clan approach is used in which multiple clans are elected, and data dissemination is confined to each respective dan using the same mechanism. As shown in the experimental examples of this disclosure, these improved protocols achieve significantly higher throughput compared to state-of-the-art DAG-based protocols, even at moderately large system sizes.

[0045]

[0034] Byzantine fault-tolerant state machine replication (BFT SMR) serves as a core building block for blockchain systems. BFT SMR allows a group of n parties to reach consensus on a sequence of values, even in the presence of up to / Byzantine parties, who may act in arbitrarily malicious ways. A Byzantine party is generally a participant (e.g., a network node) that may be malicious, faulty, or unreliable and can send conflicting information to different nodes to prevent consensus. As blockchain technology strives toward greater decentralization, it becomes critical for these protocols to scale to hundreds of nodes while maintaining high throughput, low latency, and efficient communication complexity.

[0046]

[0035] Traditional BFT SMR protocols in a partially synchronous network can achieve a commit latency of 36 (where 8 represents the actual network delay) and also achieve linear communication complexity. However, the throughput of traditional protocols is significantly constrained, achieving only around 3000 transactions per second (TPS). This limitation of previous technology Docket No, UC-024 is largely or at least partially due to a reliance on a single proposer design: a designated (rotating or fixed) leader proposes transactions and disseminates substantial amounts of data across the network, which creates a bottleneck and hinders throughput.

[0047] [36| To address these challenges, the DAG-based BFT protocol has recently emerged. This approach enables all participants to propose concurrently, thereby improving bandwidth utilization and resulting in improved throughput. Additionally, recent DAG-based BFT protocols such as Mysticeti, Sailfish, and Shoal++, have demonstrated a commit latency of 35, matching traditional BI T protocols while achieving higher throughput for moderate network sizes. Experimental analyses have demonstrated that multi-proposer DAG-based BFTs offer significantly better throughput without impacting latency. However, as the system scales beyond 100 geo-distributed nodes, these DAG-based BFT protocols suffer a significant drop in throughput. Notably, academic analyses of DAG-based BFTs generally only reach up to 100 nodes, and real-world blockchains like Sui (Proceedings of the 26th symposium on operating systems principles, pages 51—68, 2017) also operate with a similar number of nodes. This disclosure provides a solution to this decrease in throughput as the system size increases.

[0048] |37[ A technical challenge is that most DAG-based BFT SMR protocols rely on a reliable broadcast (RBC) primitive to disseminate their proposals (referred to as vertices), ensuring nonequivocation (i.e., ensuring that the sender cannot equivocate by convincing different honest parties to accept different messages) and guaranteed delivery of these proposed vertices to all parties. As a result, these protocols incur a communication complexity of at least Q( / r f + Kn’), where £ represents the size of input transactions and K is the security parameter. The proposed vertices typically contain a large number of transactions to promote good throughput (e.g., t > KH). Consequently, due to the bandwidth-heavy replication of large data across all parties, bottlenecks increase as the system size increases. Additionally, once ordered, every party must execute all transactions, further increasing the bottleneck as the system expands.

[0049] |3SJ This disclosure uniquely recognizes that only the consensus / ordcring phase requires a super-majority of honest parties with n > 3 / participating parlies with at most f < n / 3 (assuming partially synchrony ), where / is the number of faulty parties in the network. Once a total ordering of the proposed vertices is agreed upon , i t is not necessary for all parties to execute the transactions Docket No. UC-024 in these vertices. Equivocation is impossible after transactions are ordered, and the committee responsible for executing transactions only requires an honest majority to function correctly. Particularly, in a system or subsystem with ne< n parties and / < ntbeing faulty, a client only- needs consistent responses from f:+ 1 parties to ensure their transaction has been safely executed, where ni:is the number of parties in the subset of the network, or clan, selected to perform block approval, and / is the number of faulty parties in the clan. To address the possibility of up to / faulty parties failing to execute or sending inconsistent responses, n,:— / > fc+ 1 is needed, and thus nt> 2 fc + 1. As a result, this disclosure recognizes that it is sufficient to disseminate the transaction to a committee with n(:> 2 / + 1 parties, ensuring that at least / •+• 1 honest parties execute the transaction and respond to the client.

[0050] (39] Furthermore, this disclosure recognizes that, if parties are selected uniformly at random, significantly smaller committees, or clans, can be used while maintaining the honest majority assumption with only a negligible probability of statistical failure. For instance, in a system of n = 500 parties and f- 166 faulty parties, a committee of just MC= 184 members suffices to ensure an honest majority with a negligible failure probability of IO-9, based on the hypergeometric probability distribution. FIG. 1 shows a plot 100 of the clan size («<3 required to obtain a failure probability of 10-9for different network sizes ( / ?). As shown in FIG. 1, smaller committees are selected, and the dissemination of larger payloads is confined to these committees, thereby reducing bandwidth usage and enhancing throughput and scalability. As used herein, the entire set of n parties or network nodes is sometimes referred to as a “tribe”, while the honest majority with a committee of size ncis sometimes referred to as a “clan’’.

[0051] [401 As explained throughout this disclosure, once a clan is identified, it can be relatively straightforward to disseminate the data solely to the clan and collect proof of data availability (PoA), ensuring that at least one honest party has received the data with a high probability. This PoA can then be provided to any SMR protocol to establish a global ordering. Since consensus on metadata is generally less costly in terms of computing resources required, this method reduces overhead. However, this method may introduce additional latency due to its inherently sequential nature. Disseminating data and collecting the PoA takes at least 25, where 5 is the network delay. Even if the PoA is included in the next proposed consensus block, there is an average queuing Docket No. UC-024 delay of i d'. Finally, the commit latency for the proposed block is at least 3<5, resulting in a total latency of at least 66'.

[0052] [411 Previous state-of-the-art DAG-based consensus protocols can avoid additional latency by embedding transactions directly into vertices. By conducting data dissemination and consensus concurrently, these protocols decrease latency. However, most DAG-based BFT SMR protocols rely on an RBC primitive which delivers the proposed vertices to all parties in the network. As described above, this can be bandwidth intensive, making existing RBC mechanisms unsuitable for the clan-based protocols of this disclosure. Instead of relying on conventional RBC protocols, embodiments of this disclosure employ an improved tribe-assisted Byzantine RBC protocol which preserves the latency performance of current DAG-based BFT SMR protocols.

[0053] |42[ Tribe-assisted Byzantine RBC employs an asynchronous primitive that ensures agreement and eventual data delivery within a clan. For agreement under partial synchrony, f < n / 3 is necessary. This condition that cannot be satisfied within a clan that only has an honest majority. To achieve agreement within a clan, the support of the entire tribe is leveraged. Two example variations of tribe-based RBC are described briefly below and in greater detail with respect to the example implementations described herein. One protocol terminates in three rounds under an honest sender and is signature-free, while the other protocol reduces termination to just two rounds using signatures.

[0054] |43[ The block approval protocols of this disclosure may employ a single clan or multiple clans. Single-clan DAG-based BFT addresses the scalability challenges described above, by relying on a smaller clan of parties that retains an honest majority with high probability. By utilizing the tribe-assisted reliable broadcast (RBC), data dissemination is restricted to this designated clan while ensuring that consensus on metadata occurs across the entire network in parallel, thereby avoiding additional latency overhead. This approach combines an efficient data dissemination process with mechanisms providing for non-equivocation and guaranteed metadata delivery, achieving scalability without compromising consistency. To ensure transaction validation, only the parties in the clan are permited to act as proposers, enabling them to validate and propose transactions effectively. This method significantly reduces bandwidth consumption by limiting data dissemination to the designated clan, which improves throughput and scalability. Docket No. UC-024

[0055] Additionally, this approach is versatile and can be integrated into existing DAG-based BFT SMR protocols to enhance throughput and scalability while preserving security guarantees equivalent to systems where data dissemination and execution involve all parties.

[0056] [441 A similar approach can also be extended to a multi-clan setting, where the entire tribe is partitioned into multiple disjoint clans, each maintaining the honest majority assumption with negligible error probability. Each clan independently disseminates and executes proposed data and is responsible for responding to clients. This approach builds upon the single-clan approach by enabling more efficient bandwidth utilization across the system, thereby improving both throughput and scalability. The multi-clan protocol may be particularly well-suited for shared sequencers, which order transactions from independent applications, and can also enhance performance in state-sharded blockchains, as described further below'.

[0057] [45| FIG. 2 illustrates an example system 200 for implementing the improved blockchain protocols of this disclosure. The system includes a plurality of nodes 202a-f, which are communicatively connected to each other via a network 204. The example system 200 includes six nodes for explanatory' purposes only. The system 200 may include at least 50 and up to thousands of nodes 202a-f.

[0058] |46| Each node 202a-f may be a processing device. For example, each node 202a-f may include hardware resources, such as a processor, memory, and communication interface. The processor processes and / or executes code and / or other instructions stored in the memory. The processor may include one or more processors, which may be specialized processors configured to execute instruction-set-arehitecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming language. The processor may include one or more of central processing unit (GPU), graphics processing unit (GPU), accelerated processing unit (APU), arithmetic-logic unit (ALU), tensor processing unit (TPU), neural processing unit (NPU ). quantum computing-based processing unit, or any combination(s) thereof. The processor sends and receives data using the communication interface (e.g., of network 204). The communication interface may be a hard-wired connection or a wireless connection, such as for connection to a local area network (LAN), a wide area network (WAN). Docket No. UC-024

[0059] |47] As explained in greater detail below with respect io the method of FIG. 3 and the various example implementations, when a data block 206 is received to be stored on a blockchain, an elected clan 208 is determined. The clan 208 is a subset of all of the decentralized computing nodes 202a-f. As described herein, the clan is elected such that it is capable of approving addition of the block 206 to the blockchain with less than or equal to a threshold probability of failure. During the consensus- forming process, the block 206 is only disseminated or communicated to the nodes 202a-c in the clan 208. Communication of the block 206 to the other nodes 202d-f outside of the clan 208 may be prevented. This may reduce bandwidth consumption and data storage requirements of the system 200.

[0060] |48J FIG. 3 illustrates an example method 300 for implementing the improved blockchain protocols of this disclosure. For illustrative purposes, the method 300 is described being performed by the system 200 of FIG. 2. However, the method 300 may more generally be performed by another appropriate decentralized system capable of executing a blockchain. The method 300 may begin at step 302 where node 202a receives a block 206 of data to be stored on the blockchain. As an example, the data block 206 may include a list of transactions. However, the data block 206 may include additional or different information.

[0061] |49j At step 304, a clan 208 is determined or elected which includes nodes 202a-c. The nodes 202a-c in the clan 208 are selected such that they are capable of approving addition of the block 206 to the blockchain with less than or equal to a threshold probability of failure (e.g., of IO'9or another predefined threshold value - see FIG. 5 and corresponding description below). The clan 208 may be selected randomly or pseudo-randomly for example, using hypergeometric or combinatorial analysis as described with respect to the example implementations below.

[0062] [50| At step 306, a block approval process is performed in which the data block 206 is only communicated or disseminated (e.g., stored in memory of) the nodes 202a-c that are in the clan 208 (see FIG. 2). This disclosure provides various approaches to this clan-based approval process. The approval process may include multiple rounds. During the process, a vertex (e.g,. a digest of the block 206) may be determined and communicated to all the nodes 202a-f of the system 200. For example, the node 202a may create a vertex (e.g., a proposal) for the DAG and initiate its dissemination for the agreement process using a reliable broadcast protocol (e.g., the primitive). Docket No. UC-024 ensuring that the vertex is securely and consistently incorporated into the consensus process. The vertex is generally a data structure that represents a proposal by a node (e.g., a proposal to store the block 2(16 in the blockchain). Each vertex may include a digest of the block 206, references (edges) to vertices from previous rounds (e.g., to establish ordering and dependencies), and any appropriate metadata, such as the round number, the identity of the proposer, and possibly certificates or signatures. The vertex includes less data than the block 206 and thus requires less bandwidth for its dissemination and fewer computing resources for its storage and management. The vertex may be created for the current round, including the necessary references and block digest.

[0063]

[0051] A reliable broadcast primitive (e.g., standard RBC or tribe-assisted RBC - see further description below) may be used to disseminate the vertex and / or block 206 to the appropriate nodes 202a-f. As described in greater detail in the example implementations, the primitive used (e.g., one of the improved tribe-assisted RBCs described below) ensures that the vertex is properly propagated, acknowledged, and agreed upon according to the protocol’s rules. As also described further below with respect to the example implementations, the vertex may be disseminated in a way that ensures all honest nodes agree on its content (non-equivocation).

[0064] 1521 Still referring to the approval process of step 306, the block 206 is disseminated to (e.g., communicated and copied) only to the nodes 202a-c in the elected clan 208. Communication of the block 206 is prevented to the nodes 202d-f that are not members of the elected clan 208, thereby reducing bandwidth consumption by the blockchain system and preserving memory resources of the non-member nodes 202d-f. After the vertex is disseminated to all nodes 202a-f and the block 206 is disseminated only to the clan 208, one or more messages are generated and sent by the nodes to indicate receipt of the vertex (by non-member nodes 202d-f) or receipt of both the vertex and the block (by member nodes 202a-c).

[0065] 153] The messages may be ECHO messages, as described in the example implementations below. ECHO messages are a specific type of message used within the reliable broadcast (RBC) protocol, including the tribe-assisted reliable broadcast protocol of this disclosure. ECHO messages may play an important role in ensuring that data (such as a block 206 or vertex) is reliably disseminated and agreed upon by the participa ting nodes 202a-f, even in the presence of Byzantine Docket No. UC-024

[0066] (i.e., malicious or faulty) nodes. As an example, when a node 2O2a-f receives a value (such as a block 206 or a vertex including a digest of the block 206) as part of the RBC protocol, the node 202a-f may send an ECHO message to all other nodes. This ECHO message may serve as a confirmation that the node 202a-f has received the value and is prepared to help propagate it further in the network.

[0067]

[0054] In a multi-step approval process, the protocol may require that a node 202a-f collects a certain number of ECHO messages (from both the elan 208 and the broader network) before proceeding to the next step, such as sending a READY message or delivering the value (see example implementations below). This may help that enough nodes have received the value, which is critical for the protocol’s guarantees of agreement and validity.

[0068]

[0055] During an example approval process involving ECHO messages, the node 202a transmits the value (e.g., a block or vertex) to the members of the elected clan and a vertex ( e.g.. a digest of the value) to the rest of the network. The ECHO message is then “echoed” by the received nodes 202b-f. For example, upon receiving the value (or the vertex), each node 202b-f sends an ECHO message containing the digest of the value to all other nodes. A node 202a-f may wait until it has recei ved at least a specified number of ECHO messages ( e.g., 2f+ 1. as described above), including a minimum number from the dan 208, before a READY message is sent. The use of ECHO messages may help prevent equivocation (e.g., where the sender sends different values to different nodes ) and ensure that all honest nodes can eventually agree on the same value, even if some nodes are malicious.

[0069] [561 As another example, the block approval process may include transmitting, by a sender node

[0070] 202a, a value comprising the block 206 to each node 202b,c of the elected clan 208 and a digest of the block (e.g., a vertex) to nodes 202d~f not in the elected clan 208. Upon receiving the value or the digest, each node transmits an ECHO message that includes the digest of the block to all other nodes. After at least a threshold number of ECHO messages from nodes 202a-c in the dan 208 are received, each node transmits a READY message to all other nodes 202a-f After at least a threshold number of READY messages are received, the block approval process is complete. In some embodiments, if a node 202b or 202c in the clan 208 has not received the block 206 but has Docket No. UC-024 received the required number of READY messages, the node 202b or 202c may download the block 206 from another node in the clan 208.

[0071]

[0057] At step 308, the system 200 determines whether the block 206 is approved. For example, the block 206 may be approved if at least a threshold number of messages are received indicating receipt of the vertex or determining that the block approval process is complete based on a number of messages received indicating receipt of the vertex (by non-member nodes 202d-f) or receipt of both the vertex and the block (by member nodes 202a-e). If the block 206 is approved at step 308, the method 300 proceeds to step 310, and the block 206 is added to the blockchain at step 310. Otherwise, the method 300 ends. The nodes 202a-c in the clan may then execute one or more transactions based on the added block 206. The nodes 202d-f not part of the clan may not participate in executing the transaction(s) to further conserve resources and improve bandwidth utilization.

[0072] |58| As another example (also described further below with respect to the example implementations), the block approval process may be performed using a round-optimal reliable broadcast protocol that completes in two rounds in the case of an honest sender. In this process, messages exchanged during the protocol may be digitally signed by the sending nodes. As another example (also described further below with respect to the example implementations), the block approval process may be performed using a reliable broadcast protocol that completes in three rounds in the case of an honest sender. In this process, the protocol does not require messages exchanged during the protocol to be digitally signed by the sending nodes.

[0073] [59| In some embodiments, multiple (i.e., two or more) clans are elected. Each clan independently receives, disseminates, and approves a respective block according to the block approval process described above and elsewhere in this disclosure. The approval processes for clans may be performed in parallel, such that each clan concurrently receives, disseminates, and approves its respective block independently of the other clan(s).

[0074] [601 In some embodiments involving multiple elected clans, the nodes 202a-f are organized to implement a sharded blockchain, such that each of the clans corresponds to a respective shard of the blockchain, A sharded blockchain is a distributed ledger system in which the overall state and Docket No. UC-024 transaction processing are partitioned into multiple, independent groups called “shards.” Each shard is responsible for maintaining its own subset of the blockchain’s state and processing only the transactions relevant to that shard. A sharded blockchain divides the blockchain’s state and transaction processing among multiple shards, each with its own consensus and data, requiring cross-shard protocols for coordination.

[0075] |61] In some embodiments involving multiple elected clans, the system 200 includes multiple sequencers. Each elected elan corresponds and is handled by a respective sequencer. Multiple sequencers provide parallel or application -specific transaction ordering. A system 200 with multiple sequencers is a distributed system where multiple independent entities, called sequencers, are responsible for ordering transactions or batches of transactions. Sequencers do not necessarily partition the state. Instead, the sequencers may provide ordered transaction streams, e.g., for different applications or subnets.

[0076] Example Implementation and Evaluation of Improved D AG-based BFT Protocols

[0077] |62] The following describes the implementation and analysis of examples of both single-clan and multiclan protocols. These new protocols w'ere compared against the Sailfish protocol (Nibesh Shrestha, et al. “Towards improving the latency of dag-based bft”. 2025 IEEE Symposium on Security and Privacy (SP), IEEE, 2025), The results presented below are for a geo-distributed system and show that the single-clan DAG-based BFT SMR significantly outperforms Sailfish in terms of throughput across all system sizes, despite having fewer proposers. These improvements at least partially resulted from the reduced dissemination of data to fewer parties within the designated clan. Unexpectedly, despite having the same theoretical latency in terms of the number of rounds, the single-clan DAG-based BFT SMR also exhibited lower latency than Sailfish. Additionally, multi-clan DAG-based BFT SMR was found to outperform both the single-clan DAG-based BFT SMR and Sailfish in terms of throughput, benefiting from the efficient distribution of data across multiple clans.

[0078] |63| Section 1 below describes the system model used and other preliminary analyses. In Section 2, an example tribe-assisted reliable broadcast primitive and an example tribe-assisted RBC protocol are described. Section 3 demonstrates a round-efficient variation of the primitive. Docket No. UC-024

[0079] Sections 4 and 5 present examples of the single-clan and the multi-clan DAG-based BFT protocols, respectively. Section 6 describes the results obtained comparing both of these protocols to the Sailfish protocol.

[0080] L Preliminaries

[0081] |64| The example system is defined as P :■■■■ Pi, ..., Pn, consisting of / ? parties out of which up to / ~ L~~J parties can be Byzantine, meaning they can behave arbitrarily. The model of corruption is static (i.e., the adversary picks the corrupted parties before the start of protocol execution), A party that is not faulty throughout the execution is considered to be honest and executes the protocol as specified.

[0082]

[0065] A partial synchrony model was provided by Dwork et al. (“Consensus in the presence of partial synchrony”. Journal of the ACM (JACM), 35(2):288- 323, 1988). In this model, the network starts in an initial state of asynchrony during which the adversary may arbitrarily delay messages sent by honest parties. However, after an unknown time called the Global Stabilization Time (GST), the adversary must ensure that all messages sent by honest parties are delivered to their intended recipients within A time of being sent. The term d is used to characterize the actual (variable) transmission latencies of messages. After GST, 5 < A after GST. Additionally, the local clocks of the parties were assumed to have no clock drift and arbitrary clock skew.

[0083] |66] Digital signatures and a public-key infrastructure ( PKT) were employed to safeguard against spoofing and replay attacks, and to ensure message authenticity. A message x digitally signed by party P> using its private key is denoted as ( x )>, while ( x ) refers to an unsigned message x transmitted over an authenticated channel. Additional ly, the hash of an input x is represented by / ■ / (x), where H is the hash function. For simplicity, the same parameter K is used to denote both the hash size and the signature size.

[0084]

[0067] Tribe and clans. The entire system of n nodes is referred to as the tribe, where up to / < ?z / 3 nodes may exhibit Byzantine faults. A sub-committee within this system, where the honest Docket No. UC-024 majority assumption holds, is referred to as a elan. In a clan, the number of nodes is represented as tie, with at most / ) < nJ2 being Byzantine, except with a negligible probability of error.

[0085]

[0068] Problem definition. Evaluations focused on the Byzantine Atomic Broadcast (BAB) problem as defined below:

[0086]

[0069] Definition I - BAB. In a BAB, each honest parly P> 6 P can call a_bcasti(m,r) to propagate its input m in some round r e A. Each party Pi then outputs where Pk € P represents the sender of the message. A Byzantine atomic broadcast protocol satisfies the following properties;

[0087] • Agreement. If an honest party Pi outputs ajdelivenfyn^Pit), then every other honest party Pi eventually outputs a_deliverj(m,r,Pk).

[0088] • integrity. For every round r e A and party Pk G P, an honest party Pt outputs a_deliven at most once regardless of m.

[0089] • Validity. If an honest party Pk calls ci_bcastk(m,i') then every honest party eventually outp uts a_deli ver( m , rJPk) .

[0090] • Total order. If an honest party P,- outputs a_deliveri(rn,r,Pk) before a_deliver.ini ’.r ’,P\), then no honest party Pj outputs a_deliverj(m ’,r \Pt) before a_deliverj(m \r \Pk).

[0091] 2. Tribe-assisted Reliable Broadcast

[0092]

[0070] In this section, a primitive is introduced that ensures all honest parties within a elan reach agreement on a value and guarantees eventual delivery with the support of the entire tribe. This primitive as tribe-assisted reliable broadcast (RBC). The tribe-assisted reliable broadcast primitive is defined below. The parties in a clan are denoted by Pc, which has an honest majority (except with negligible error probability).

[0093]

[0071] Definition 2 - Tribe-assisted reliable broadcast. Let a designated sender A invoke r_ bcastk(?n, r) to propagate its input m in some round re / V. Each party Pt outputs r jleliveri(y,r, Pk), where m when Pi 6 Pt- and y = / / ( zzz) when Pt g Pc, Pk is the designated sender and r is the round number in which sender Pk sent the message m. The tribe-assisted reliable broadcast Docket No. UC-024 primitive satisfies the following properties, except with a negligible probability of error in / / where / / is the security parameter:

[0094] • Validity. If an honest party / fc calls r _hcastk(m, r) then each honest parly’ Pt eventually outputs r_deliveri(y. r. Pk) where y- z / zwhen P e Pc and y- P(m) when Pt gT’c.

[0095] • Agreement. If an honest party Ptoutputs r_delivert(y, r, Pk), then each honest party Pj eventually outputs r_deliverj (y, / ; Pk) where y~ m when A 6 Pc and y- / Am} when Pi 6? Pc.

[0096] • Integrity. For every round rG A’ and party Pk G P, an honest party P outputs r_del.iveri at most once regardless of m.

[0097] 1721 An example r_bcastk(m, r) candidate protocol is presented below which is signature-free and requires three rounds in the case when the sender is honest:

[0098] 1. The sender Pk sends (VAL, m, r) io each party Pi E Pcand (VAL, H(m), r) to party PiG Pc.

[0099] 2. Upon receiving the first (VAL, v, r), party Pi sends (ECHO, H(m), r) to all parties (where y = m when Pi E Pcand y - H(m) when Pi G Pc).

[0100] 3. Upon receiving 2f -r I distinct (ECHO, H(m), r) messages with at least fc + 1 (ECHO, H(m), r) messages from Pc, party Pi sends (READY, H(m), r) to all parties.

[0101] 4. Upon receiving f + I distinct (READY, H(rri), r) messages, if (READY, H(m), r) has not been sent, party Pi sends (READY, H(m), r) to all parties.

[0102] 5. Upon receiving 2 / + 1 distinct (READY, H(m), r) messages, party Pi performs the following: a. If party Pi E Pc and has received value m, invoke r deliveriim, r, fc); otherwise download value m from parlies in Pcand invoke r_deliveri(m, r, Pk\, b. If party Pi G Pc, invoke r_deliveri(H(m), r, Pk). Docket No, UC-024

[0103]

[0073] Protocol details. In this protocol, the sender / 7< with input value m sends (VAL, m, r) to each party Z? G Pt? for some round r, while it sends only the digest (i.e., / / ( / / ?)) to the parties outside the clan. Upon receiving the value m, each party Pi G Pc sends (ECHO, Zf w), / '). Parties outside the dan send (ECHO, / / ( / / <?), / ) upon receiving just the digest.

[0104]

[0074] An honest party then sends a READY message for the value m when it receives 2f + 1 distinct (ECHO, flm}, 0 messages, with at : least / c + I of those coming from parties in Pc. Note that the clan has at most / c' Byzantine parties (except with negligible error probability). Thus, waiting for at least / c * 1 ECHO messages from parties in Pc ensures that at least one honest party in Pc has received the value m. This allows other parties in Pc to download value zzzat a later point when required. Additionally, a party can also send a READY message if they receive / ’ ■?■ 1

[0105] READY messages for zzzand have not yet sent a READY message.

[0106] |75] I Jpon receiving 2 / ’+l (READY, ftm). n messages, an honest party Pt G Pc can deliver m if it has already received the value m. If it has not yet received the value, it can download m from other parties in Pc and then deliver it. As previously mentioned, if an honest party sends a (READY, r) message, it guarantees that at least one honest party in Pc has received the value zzz, making it possible to retrieve m at this stage. Finally, parties outside the clan deliver

[0107] / pci} upon receiving 2 / H- 1 (READY, r) messages.

[0108]

[0076] Pc and a A-bit digest to parties in P \ Pc, resulting in a communication complexity of Oinct + x{n — %)). The al1-to-all multicast of ECHO and READY messages incurs a complexity of <?VA7?). Therefore, the overall communication complexity is in the case when the sender is honest.

[0109] |77| However, when the sender is Byzantine, only a subset of honest parties in Pc may receive the value m, but all honest parties could still gather 2 / '+1 READY messages for m. In this scenario, the honest parties in Pc would need to download the value m from other honest parties who have received it. To expedite the retrieval, the honest parties may request the value from a linear number of parties, which could lead to an increase in communication complexity, reaching Docket No. UC-024

[0110]

[0078] Impact on communication complexity. The protocol of this disclosure allows parties to download or pull missing data. In theory, this feature could be exploited by Byzantine parties, who might repeatedly request the data, potentially leading to unbounded communication complexity. To mitigate such an attack, parties can be rate-limited, effectively bounding the communication complexity in practice.

[0111]

[0079] Theoretical RBC protocols typically only support data being pushed, without allowing parties to pull the data . Despite this, these protocols can still encounter unbounded communication in practice. The assumption is that parties communicate over reliable links, often implemented using the TCP protocol. In such setups, a sender continues transmitting data until it receives an acknowledgment from the receiver. If the receiver is Byzantine, it may never send an acknowledgment, causing the sender to continuously transmit the data, leading to unbounded communication. However, in practical systems, it is usually assumed that Byzantine parties do not disrupt the network layer to trigger such unbounded communication. Under this assumption, the protocol provides comparable communication complexity' guarantees in practice.

[0112]

[0080] Additionally, theoretical RBC protocols often leverage erasure and error-correcting codes to improve worst-case communication efficiency. While these techniques enhance communication in the worst-case scenarios, they also introduce overhead in terms of encoding, decoding, and verifying the erasure-coded chunks, which can degrade performance under normal conditions. Since most nodes in practice are honest, many practical implementations avoid using erasure codes. Instead, the sender multicasts the proposed value to all parties, and the parties exchange ECHO and READY messages on the digest of the value and download missing values at a later point. This approach offers better performance in typical scenarios. Moreover, in DAG-based BFT SMR protocols, where all parties propose, bandwidth utilization is inherently balanced. As a result, incorporating erasure-coded broadcast in DAG-based BFT would add unnecessary computational overhead, reducing efficiency. Consequently, embodiments of this disclosure include tribe-assisted RBC without erasure and error-correcting codes, prioritizing practical performance.

[0113] 2.1 Security Analysis Docket No. UC-024

[0114]

[0081] Lemma 1 (Validity). The example r_bcastk(m, r) candidate protocol satisfies Validity, except with a negligible error probability.

[0115] 1’82] Proof. Observe that an honest sender A sends (VAL, zzz, r) to all parties in P£. and (VAL, / / (zzz), r) to all parties in P 1 Pc. Consequently, all honest parties will eventually send (ECHO, / fim), / ). As a result, all honest parties will receive at least 2f + 1 distinct (ECHO, / fim), r) messages, including at least fc + 1 from the parties in Pc. Consequently, all honest parties will eventually send (READY, / fin?), r) to all parties, and all honest parties will receive 2fi + 1 (READY, / fim), r) messages. Furthermore, honest parties in Pc will receive zzz from the sender A. Therefore, all honest parties will invoke r_deliver(y, r, Pk), where y- m if Pi e Pc and >' = / fim) if A g Pc.

[0116]

[0083] Note that honest parties may fail to receive at least fc + 1 (ECHO, / fim), r) messages only in the rare case where the clan has a dishonest majority, which occurs with negligible probability. Therefore, the validity property is maintained except with a negligible probability of failure.

[0117] [841 Proposition 1. Art (wo honest parties will send READY message on conflicting values.

[0118] |85J Proof. Suppose an honest party A sends READY message for value m. This implies A must have received at least 2f+ I (ECHO, / fin?), r). A simple quorum intersection argument show that there cannot exist a set of at least 2 / + I ECHO messages on a conflicting value zzz'. Thus, no honest party sends a READY message for a conflicting message.

[0119]

[0086] Lemma 2 (Agreement). The example rfitcasb / fim, r) candidate protocol satisfies Agreement, except with a negligible error probability.

[0120]

[0087] Proof Suppose an honest party A outputs r_deliveri( / , z; A) (where y~ m when A G Pc / fim) when A g Pc). This implies A must have received at least 2 / 1- 7 (READY, / fim), r) messages, including at least / 'E I (READY, / fim),r) from honest parties. Since honest parties send (READY, / fim), r) to all parties, all honest parties will eventually receive at least f + I (READY, / fim), r). By Proposition I , no honest party sends READY message for a conflicting value. Thus, honest parties that have not. sent READY message will eventually send (READY, Docket No, UC-024

[0121] / / (m), r). Consequently, all honest parties will eventually receive 2f + / (READY, film), r) and honest parties in P '• ZVwi.ll invoke r jieliver(M(m), r, A).

[0122] |88| Moreover, observe that at least one honest party must have sent (READY, r) upon receiving 2f +l (ECHO, / / (m), r) messages, including at least fc + / (READY, r) messages from parties in Pc. This implies at least one honest party Pj 6 Pc must have received the value zzz. except with negligible error probability. Consequently, other honest parties in Pcwill download value m from Pj and invoke r_deliver(m, r. Pic), except with negligible error probability.

[0123]

[0089] Theorem 1. The example rf>castf(m, r) candidate protocol is a tribe-assisted reliable broadcast tolerating t < n / 3 Byzantine faults satisfying Definition 2, except for a negligible probability o f error.

[0124] [9O| Proof. The integrity property is straightforward from the protocol, as a party can deliver a value at most once. The validity and agreement property follows from Lemma 1 and Lemma 2, respectively.

[0125] 3. Two-Round Tribe-assisted Reliable Broadcast

[0126]

[0091] In this section, a tribe-assisted RBC protocol is described that completes in two rounds in the case with trusted senders. An example r_bcastk(m, r) protocol is:

[0127] 1. The sender P / c sends (VAL, m, rjX'to each party Pt EPcand (VAL, Htmfi rifita party Pi $ Pc.

[0128] 2. Upon receiving the first (VAL, y, r.iC, party P / sends (ECHO, H(m), ?y / to all parties (where y - m when Pi E Pcand y ~ H(m) when Pz £ Pc).

[0129] 3. Upon receiving 2f +1 distinct (ECHO, H(m), r)* messages with at least fc + 1 (ECHO, H(m). r)* messages from Pc( denoted by ECr(m)), party P / 'multicasts ECr(m) and performs the following: Docket No, UC-024 a. If party PZ E Pc and has received value m, invoke r_deli ver / (m, r, k); otherwise download value m from parties in p<? and invoke r deli ver din-, r, b. If party P / (£ Pc, invoke r_dellver / (H(m), r, Pty.

[0130] |921 Protocol details. All the messages exchanged in this protocol are signed. The sender A with input value m sends (VAL, m, r)k to each party A E Pc for some round r, while it sends only the digest (i.e., ff(mf) to the parties outside the clan. Upon receiving the value m, each party A E Pc multicasts (ECHO, H(m), tyi. Parties outside the clan send (ECHO, H(m), r ) upon receiving just the digest.

[0131]

[0093] Upon receiving If + I (ECHO, W(m), r) messages with at least fc + 1 of those coming from parties in Pc (denoted by ECr(m)), an honest party Pi E Pc multicasts the ECr (m). Pi can deliver m if it has already received the value m. If it hasn’t yet received the value, it can download m from other parties in Pc and then deliver it. Finally, parties outside the clan deliver H(m) upon receiving ECr (m).

[0132]

[0094] Communication complexity'. Let t represent the size of the value m. An honest sender transmits the f -bit message to parties in Pc and a / c-bit digest to parties in P \ Pc, resulting in a communication complexity of Ch' nd + Kin ~ nc}}. The all-to-all multicast of ECHO messages incurs a complexity of 0 (rcn2). When using the BLS multi-signature scheme, the size of ECr (m) becomes O(ic-rn), and the all-to-all multicast of the ECr (m) incurs 0(^112+113). Therefore, the overall communication complexity is O(nct + Kn?. 4- 713) in the good-case with all trusted senders. While there is a cubic term in the communication complexity, the linear term associated with the BLS multi-signature is merely a bit vector indicating who voted, so it does not impose significant communication overhead.

[0133]

[0095] In the worst case, if the sender is Byzantine, the communication complexity can increase to O(nc2C + K?I2 + n3) when the honest parties request the value from a linear number of parties.

[0134] 3.1 Security Analysis Docket No. UC-024

[0135] 1'96] Lemma 3 (Validity). The example rfocastAf m, r) protocol satisfies Validity, except with a negligible error probability.

[0136]

[0097] Proof. Observe that an honest sender Pk sends (V AL, m, r) to all parties in Pc and (VAL, H(m), r) to all parties in P \ Pc. Consequently, all honest parties will eventually send (ECHO, H(m), r). As a result, all honest parties will eventually receive at least 2 / ’ +1 distinct (ECHO, Him), r) messages, including at least fc + 1 from the parties in Pc. Furthermore, honest parties in Pc will receive m from the sender Pk. Therefore, all honest parties will invoke rfoeliverfy, r, Pk), where y = m if Pi e Pc and y = H(m) if Pi $ Pc.

[0137]

[0098] Note that honest parties may fail to receive at least fc + 1 (ECHO, H(m), r) messages on ly in the rare case where the dan has a dishonest majority, which occurs with negligible probability. Therefore, the validity property is maintained except with a negligible probability of failure.

[0138] [991 Lemma 4 (Agreement). The example rfocastfom, r) protocol satisfies Agreement, except with a negligible error probability.

[0139] [100J Proof Suppose an honest party Pt outputs r - deliver Ay, r, Pfi) (where y - m when Pt e Pc and y - H(m) when Ptfo / V). This implies P / niust have received 2 / ' + 1 (ECHO, H(m), r) messages, including at least fc + 1 from the parties in Pc. P / must have sent ECr (m) to all parties. Consequently, all honest parties will eventually receive ECrfm) and honest parties in P i Prwill invoke rfoeliver(H (m) , r, PA').

[0140] [101 | Moreover, observe that at least one honest party P / € Pc must have received the value m, except with negligible error probabi lity. Consequently, other honest parties in Pc will download value m from P / and invoke rfoeliverim, r, PAfi except with negligible error probability.

[0141] 11021 Theorem 2. The example rfocastkfm, r) protocol is a tribe-assisted reliable broadcast satisfying Definition 2, except for a negligible probability’ of error.

[0142]

[0103] Proof The integrity property is straightforward from the protocol, as a party can deliver a value at most once. The validity and agreement property follows from Lemma 3 and Lemma 4, respectively. Docket No. UC-024

[0143] 4. Single-clan DAG-based BFT SMR

[0144]

[0104] In this section, an efficient and sealable architecture for a DAG-based BFT SMR protocol is described that limits data dissemination and execution to a single designated clan of parties while maintaining security guarantees comparable to those of a system where transaction dissemination and execution occur across the entire network.

[0145] 1105] Structural overview of DAG-based BFT SMR. A DAG-based BFT SMR protocol progresses th rough a series of rounds. In each round r, each party proposes a single vertex using the RBC primitive to ensure non-equivocation and guarantee that all honest parties eventually deliver the vertex. Each vertex v contains a block of transactions, and references to at least 2f + 1 vertices from round r — 1 and up to f vertices from earlier rounds (i.e., rounds < r — 1 ), provided there is no path from v to these earlier vertices. These references form the edges in the DAG, with the references to 2f + I round r — 1 vertices serving as strong edges and references to earlier rounds as weak edges. A path from vertex vi- to vertex zy following the strong edges is called a strong path. The strong edges and strong paths are crucial for committing vertices within the DAG, while all edges contribute to the total ordering of the vertices. The commit and total ordering rules are specific to each protocol. The protocols in the following sources provide example information on these rules: Nibcsh Shrestha, ct al, “Towards improving the latency of dag-based bft”. 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025; Alexander Spiegelman, et al. “Shoal: “Improving dag-bft latency and robustness”. International Conference on Financial Cryptography and Data Security, 2024; and Alexander Spiegelman, et al. “Bullshark: Dag bft protocols made practical”. Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 2705-2718, 2022.

[0146] | J 06] The references, along with the edges and paths they create, are used for committing and totally ordering the vertices. Therefore, these references are propagated to all parties in the system. However, the block of transactions only needs to be reliably disseminated to a designated clan of parties, which will execute the transactions and respond to the client. This observation is fundamental to designing an efficient and scalable DAG-based BFT SMR. Docket No. UC-024

[0147]

[0107] Improving throughput with sealability. As previously mentioned, transaction blocks within a vertex are typically large, making their dissemination to all parties bandwidth-intensive and a key bottleneck for scalability and throughput. In contrast, the total size of references to vertices from earlier rounds are much smaller, especially in moderately-sized networks, and their dissemination introduces minimal overhead. Specifically, the pay load size / 'far exceeds the size of vertex references, i.e., f» ten, in such settings. To mitigate this bottleneck, a clan of parties is randomly selected with a high probability of maintaining an honest majority. The transaction block is then reliably disseminated only to this clan, significantly reducing overall bandwidth usage.

[0148] 1108] To further optimize the propagation of vertices, the vertex structure is modified to contain only the digest of the block of transactions. The updated data structures are:

[0149] Local variables: struct vertex v. < The struct of a vertex in the DAG i?. round- the round of rm the DAG u. source- the party that broadcast v v. block digest - the digest of the corresponding block of transactions v. strong Edges- a set of vertices in v, round — 1 that represent strong edges v. weakEdges- a set of vertices in rounds < K round — I that represent weak edges unvc- a no-vote certificate for v. round — 1 (if any) u.tc- a timeout certificate for v. round — 1 (if any ) struct block lr. b.txn- a list of transactions

[0150] 1109| The actual block of transactions is placed in a separate block structure, which is sent exclusively to the designated clan, while the vertex itself is propagated to the entire tribe. For Docket No. UC-024 block, dissemination, the tribe-assisted RBC protocol can be leveraged, while the standard RBC protocol is used to propagate the vertex. However, this approach increases message (and computation) complexity.

[0151] 1110| Efficiently propagating the vertex and the block. To more efficiently propagate both the vertex and block, the two RBC instances may be merged. Let p be a vertex, b be its associated block, and C be the designated clan. The sender broadcasts vertex zrto all parties in the tribe but sends block A only to members of C, Members of C send an ECHO message (as part of the RBC) only after receiving both v and A while parties outside C send an ECHO after receiving just p, which includes the digest of block A The READY message is sent upon receiving 2 / ’+ ] ECHO messages with at least fc + 1 from the clan C, or upon receiving f + 1 READY messages. This combined approach maintains the guarantees of standard R BC, as C always includes at least fc + 1 honest members, except with negligible error probability. It effectively integrates tribe-assisted RBC for block propagation with standard RBC for the vertex.

[0152] (Ill J Obtaining single-clan D AG-based BFT SMR. The scaling technique of this disclosure can be adapted to existing DAG-based BFT SMR protocols that rely on RBC, such as Bullshark, Shoal, Sailfish, Shoal++, and Sailfish-H-, with a few modifications. (Alexander Spicgehnan, ct al. “Bullshark: Dag bft protocols made practical”. Proceedings of the 2022 ACM SIGSA C Conference on Computer and Communications Security, pages 2705-2718, 2022; Alexander Spiegelman, et al. “Shoal: “Improving dag-bft latency and robustness”. International Conference on Financial Cryptography and Data Security, 2024; Nibesh Shrestha, et al. “Towards improving the latency of dag-based bft”. 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025; Balaji Aurn, Zekun Li, et al. “Shoal++: High throughput dag bft can be fast!” arXiv preprint 2405.20488, 2024; Nibesh Shrestha, et al. “Optimistic, signature-free reliable broadcast and its applications”. Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, 2025.) Existing protocols typically allow all parlies to propose both blocks and vertices. However, the single-clan technique limits block proposals to parties within the clan,

[0153] 1112] While theoretically, all parties could propose blocks (of transactions) and disseminate them only to the clan to improve throughput, this may be impractical. Block proposers are also responsible for validating transactions and ensuring sufficient resources are available for Docket No. UC-024 transaction execution. These tasks requite executing transactions and maintaining state, which only clan members can do. Thus, in the single-clan approach, only clan members can propose transaction blocks, while all parties must continue proposing vertices since these are essential for committing blocks and vertices. This feature does not limit the protocol’s applicability, as clients only need to send their transactions to the designated clan instead of all parties and will receive responses from the parties within the clan.

[0154] [113J Another feature involves separating the dissemination of vertices and blocks. Instead of broadcasting vertices and blocks together, they are propagated independently. Despite these adjustment, the DAG construction, commit, and ordering rules remain unchanged, adhering to the original protocol designs. After transactions are ordered, only the clan members execute them and respond to the client.

[0155] Iii4| Additionally, the enhanced protocol of this disclosure maintains the good-case commit latency of the original protocol. For example, in Bullshark, the protocol would still commit the leader vertex ( proposed by the round’s leader) with a latency of two RBCs. Similarly, in Sailfish, the leader vertex would be committed with a latency of one RBC, plus 13.

[0156] |115[ When using the tribe-assisted RBC of this disclosure to propagate vertices, parties may need to download missing blocks if the sender is Byzantine, which introduces additional latency. However, this does not affect the protocol’s progress or commit latency. In standard DAG-based BFT SMR protocols, the protocol advances to round r + 1 once a sufficient number of RBCs from round r have been delivered. In the enhanced protocol of this disclosure, the protocol proceeds to the next round upon receiving 2 / + 1 READY messages from a sufficient number of RBCs, even before downloading the associated blocks. This ensures the protocol’s progress remains unaffected.

[0157] [116| Moreover, parties can commit the vertex, which includes the block digest, even before the block itself has been delivered. Typically, transaction execution lags behind consensus. Parties can begin requesting the missing blocks as soon as they receive 2 / '+ 1 ECHO messages, including at least / c' i 1 from the clan C (i.e., before receiving 2 / ' ( 1 READY messages), ensuring that missing blocks are delivered before execution begins. Docket No, UC-024

[0158] | 117] Security of single-clan DAG-based BFT SMR. Existing D AG-based BFT SMR protocols rely on theoretical RBC primitives to propagate proposed vertices, which consist of both blocks of transactions and references. These RBC primitives guarantee validity, agreement, (eventual) guaranteed delivery, and eventual delivery (after GST), These properties are essential to ensure the security guarantees of the protocol, as outlined in Definition 1.

[0159] 1118] In the improved protocol of this disclosure, a tribe-assisted RBC to disseminate blocks exclusively to a designated clan. This mechanism retains the same validity, agreement, and guaranteed delivery' properties, except for a negligible probability-' of error. While parties may need to download missing blocks, introducing some additional latency, the missing blocks can be retrieved without affecting the overall progress of the protocol. Thus, tribe-assisted RBC does not compromise the security of protocols relying on it, except in the unlikely scenario of a dishonest majority forming within the clan, which has a negligible probability of occurring. In particular, the following result is obtained:

[0160]

[0119] Theorem 3 (Informal). The single-clan DAG-based BFT SMB implements Byzantine atomic broadcast and tolerates up to f< n / i Byzantine faults, except with negligible probability of error.

[0161]

[0120] Communication complexity. Let 12 denote the size of a block of transactions. Existing DAG-based BFT SM R protocols incur a communication overhead of at least f-A' f). By leveraging tribe-assisted RBC for block dissemination and restricting payload proposals to the clan, the protocol of this disclosure reduces this overhead to Kf) in the best-case scenario.

[0162]

[0121] Operating cost reduction. Disseminating large amounts of data across the entire network can be resource and cost expensive, e.g., due to higher data transfer fees between data centers. Additionally, machines with a larger number of cores are needed to execu te transactions in parallel and reduce latency. As a result, executing transactions and disseminating data across the entire network can become cost-prohibitive. The single-clan approach of this disclosure mitigates this by confining data dissemination and transaction execution to a smaller, designated clan. Only this clan needs high-capacity machines, reducing overall system costs and transaction fees. Docket No. UC-024

[0163]

[0122] Statistical security analysis. When a single clan of ncparlies is randomly selected from a system of n total parties, of which / 'are Byzantine, the probability of forming a dishonest majority within the clan is given by the hypergeometric cumulative distribution function (CDF). This function calculates the likelihood of selecting more than half of the / ?<■ parties as Byzantine. Specifically, the probability of a dishonest, majority, Pr(dishonest majority), is:

[0164] Prfdirihonest majority)

[0165]

[0123] The value of ?k must be chosen sufficiently large relative to the total number of parties n and the number of Byzantine parties / 'so that the probability of forming a dishonest majority within the clan is below the desired security threshold / / . Specifically, the following is required:

[0166] Pr(dishonest majority)

[0167] 1124] If a clan with a dishonest majority is formed, the validity and agreement properties of the tribe-assisted RBC may be compromised. As a result, this probability defines the failure probability of both the tribe-assisted RBC and the DAG-based BFT SMR protocols that depend on it. As shown in FIG. 1, the required clan size n(. necessary to ensure that the probability of forming a dishonest majority is below IO-9~ 2~'°.

[0168] Multi-clan DAG-based BFT SMR

[0169] 1125] In the approach described above, a single clan handled block proposals, received and disseminated the block, and executed transactions. This approach is effective for small systems where the clan size remains only marginally smaller than the tribe size. However, as the system increases in size (e,g., scales), the clan size does not grow proportionally, as illustrated in FIG. 1. This single clan design can restrict throughput in larger systems and may fail to fully utilize the bandwidth of the entire network. To address this, the tribe may be partitioned into multiple disjoint clans. Each clan independently disseminates, processes, and executes transactions within its Docket No. UC-024 group, while also responding to clients. This design maintains security guarantees equivalent to a system where transaction dissemination and execution are performed across the entire network.

[0170]

[0126] Obtaining multi-clan DAG-based BFT SMR. The tribe was partitioned into multiple clans, denoted as Cl, ... , Cq, where q is determined based on the desired error probability. Unlike the single-clan approach, which restricts block proposals to the designated clan, the multi-clan design may allow all parties to propose. Each proposer disseminates its pay load exclusively within its respective clan, evenly distributing bandwidth consumption across clans. Transaction execution is also handled independently within each clan, balancing the processing load.

[0171] [127| In the single-clan approach, only the designated clan members could propose transactions because parties outside the clan did not execute transactions, preventing proposers from val idating them. In contrast, the multi-clan design ensures that all parties belong to a clan, execute transactions specific to their clan, and can validate and propose transactions within their respective clans.

[0172]

[0128] As before, the modified data structure was adopted such that the block of transactions is separated from the vertex, and the vertex structure includes only the block’s digest (as depicted in the updated data structure presented above). Parties within a clan use tribe-assisted RBC to disseminate the block within their clan, while employing standard RBC to propagate the vertex to the entire tribe. These steps are integrated. A party in a clan sends an ECHO message only after receiving both the block and the vertex. As previously discussed, references to vertices are critical for committing proposed vertices and must be propagated to the entire tribe. Since these references are relatively small, disseminating this metadata to all parties introduces minimal overhead.

[0173] |129| The core components of the D AG-based BFT SMR protocol, such as DAG construction, vertex commitment, and ordering, remain unchanged. Although the block is disseminated exclusively within the respective clan, its vertex (and by extension, the block) is globally ordered, ensuring a consistent transaction sequence across the network. Once the protocol has ordered the vertices, the corresponding dan members execute the transactions and respond to the client.

[0174] |130] The security of the multi-clan DAG-based BFT SMR protocol builds on the guarantees of the underlying DAG-based BFT SMR, the tribe-assisted RBC, and the negligible probability of Docket No. UC-024 selecting a dishonest majority within any clan (as analyzed in Section 5.2 above). Since both the formation of a dishonest majority clan and the failure of tribe-assisted RBC occur only with negligible probability, the overall failure probability of the multi-clan DAG-based Bl T SMR. remains negligible. This leads to the following result.

[0175] 1131 ] Theorem 4 (Informal). Each clan in the multi-clan DA G-based BFT SMR protocol ensures Byzantine atomic broadcast properties, except w’ / t / z negligible probability of error.

[0176] 1132] Communication complexity. Let { represent the size of a block of transactions. By utilizing tribe-assisted RBC for block dissemination and allowing all parties to propose payloads within their respective clans, the improved protocol achieves communication overhead of Ofncni in the best-case scenario.

[0177] 5.1 Example Applications

[0178] [133J Shared-sequencers. The multi-clan DAG-based BFT SMR. design is especially well- suited for applications involving shared sequencers. Shared sequencers typically focus on ordering transactions from independent applications. Since these applications have no inter-dependencies, a designated clan can handle transactions for a specific application, processing and maintaining only the state relevant to that application. The recent surge in interest in shared sequencers highlights the potential of the multi-clan design as a promising solution.

[0179]

[0134] State-sharded blockchains. The multi-clan DAG-based BFT SMR is also applicable in state-sharded blockchains, where the user space of a blockchain is partitioned into multiple shards to group frequently interacting users within a shard. In such blockchains, each shard is managed by a dedicated clan. Intra-shard transactions are processed within the shard, while cross-shard transactions require synchronization across shards, handled by protocols like two-phase commit.

[0180] 5.2 Statistical Security Analysis.

[0181]

[0135] In this sub-section, the probability of forming a clan with a dishonest majority is calculated when the number of clans is 2 and 3. This analysis can be generalized to compute the error probability for a larger number of clans using the same principles. Docket No. UC-024

[0182]

[0136] Analysis for 2 clans. Let / ■= — ~ represent the maximum number of Byzantine parties, and kt zft = n — / 'denote the number of honest parties. When the tribe is divided into 2 clans. the total number of possible combinations to form two clans is given by:

[0183] 1137] 1 ,et wi and wa represent the number of Byzantine parties in clans Ci and Cs, respectively. To ensure an honest majority in both clans, the number of Byzantine parties in each clan must be between 0 and fc, where / (is the maximum number of Byzantine parties that a clan can tolerate and still maintain an honest majority, i,e., 0 < w5, W2 < fc. Given that there are f Byzantine parties in total, they must be split between Ci and Ca, meaning that wi + wj = f . Let W represent all possible pairs (wj, w?) such that 0 < ivj, wo < fcand ivi + W2 f . The total number of valid combinations where both clans maintain an honest majority is then given by;

[0184]

[0138] Accordingly, the probability of forming a clan with dishonest majority is given by:

[0185] Pr ( dishonest maj

[0186] 1139] Analysis for 3 clans. When the entire tribe is divided into 3 clans, the total number of possible combinations to form three clans is given by: Docket No. UC-024

[0187] |140] I ^et vvi, W2, and W3 represent the number of Byzantine parties in clans Ci, C2, and C? respectively. To ensure an honest majority in both clans, the number of Byzantine parties in each clan must be between 0 and fc, i.e., 0 < wi, W2, W3 < fc. Given that there are f Byzantine parties in total, they must be split between Cl , C2, and C3, meaning that w? + W2 + ~ f. Let W represent all possible pairs (wi, w?, w'3) such that 0 < wi, w?, 1V3 < fc, and w'j + w? + wo - f. The total number of valid combinations, s. where each clan maintains an honest majority is then given by:

[0188] |141] The probability of forming a clan with dishonest majority is obtained by substituting the value of N (from Equation (6)) and s (from Equation (7)) into Equation (5).

[0189] 1142] The value of nc must be chosen sufficiently large relative to the total number of parties n and the number of Byzantine parties f so that the probability of forming a dishonest majority within the clan is below the desired security threshold p. Specifically, the following is required:

[0190] Pr( dishonest majority

[0191] |143{ If a clan with a dishonest majority is formed, the validity' and agreement properties of the tribe-assisted RBC — and by extension, the multi-clan DAG-based BFT protocol — can be violated. Therefore, the probability Prjdishonest majority) directly" bounds the probability with which the validity and agreement properties of the multi-clan DAG-based BFT protocol may be compromised.

[0192] 1144] Concrete numbers. Based on the above analysis, when the network size is 150, the network can be partitioned into two clans, with the probability" of forming a clan with a dishonest majority being approximately 4.015 x Similarly, when the network size is 387, the network can be divided into three clans, with the probability of forming a elan with a dishonest majority being approximately 1.1 1 x J O"6. Docket No. UC-024

[0193] 6. Results

[0194]

[0145] T he performances of both the single-clan and multi-clan protocols were evaluated by comparing the throughput and latency with the state-of-the-art DAG-based BFT SMR protocol. Sailfish, which relies on RBC. .As discussed above, the tribe-assisted RBC of this disclosure can also be integrated into other DAG-based protocols that employ RBC, thereby enhancing their overall performance.

[0195]

[0146] Implementation details. Sailfish was used as the underlying DAG-based BFT SMR protocol. Sailfish commits leader vertices with a latency of 35 and non-leader vertices with 55. Multi-leader Sailfish supports multiple leaders per round, committing all leader vertices with 35 latency. The open-source Sailfish implementation (Nibesh Shrestha. Sailfish github repository, (github.com / nibeshrestha / sailfish). ; was modified to develop both the single-clan and multi-clan versions, which are referred to herein as single-clan Sailfish and multi-clan Sailfish, respectively.

[0196] 1147] To minimize latency, the round-optimal RBC protocol (Ittai Abraham et al, “Goodcase latency of byzantine broadcast: A complete categorization”. Proceedings of the 2021 ACM Symposium on Principles of Distributed Computing, pages 331-341 , 2021 ) was used for vertex propagation and a two-round tribe-assisted RBC protocol (see Section 3) for block propagation. For efficiency, these RBC processes were combined such that clan members send ECHO messages only after receiving both the vertex and block (see Section 4). Following Sailfish, this results in a commit latency of 1RBC + 15 (i.e., 35). In the implementation of the round-optimal RBC, forwarding of the sender’s proposal was avoided and instead missing proposals were downloaded off the critical path of consensus if needed, reducing communication overhead in failure-free cases. As noted above, retrieving missing vertices off the critical path does not slow down consensus or increase commit latency.

[0197] |148| RocksDB was used for persistent storage of the consensus data and BLS multi-signatures (Dan Boneh, et al, “Compact multi signatures for smaller blockchains”. International Conference on the Theory and Application o f Cryptology and Information Security, pages 435-464, 2018) for authentication, significantly reducing the size of signatures that need to be multicast. While BLS multi-signatures are computationally expensive to verify, this was optimized by aggregating Docket No. UC-024 individual signatures without upfront verification and verifying only the aggregated signature. In case the aggregated signature fails verification due to a Byzantine party’s incorrect signature, individual signatures are verified to identify and penalize the faulty party. This approach avoids the overhead of verifying individual signatures in the typical case where all nodes sign correctly.

[0198] 1149] Sailfish as the foundation protocol and generalization to other DAG-based protocols. DAG-based protocols that rely on RBC use it to disseminate proposed vertices in each round, while differing in how they drive progress and commit the proposed vertices. Sailfish was used as the foundation protocol in these examples because it appears to offer the lowest latency among such protocols. Sailfish was modified by integrating the new tribe-assisted RBC to propagate blocks of transactions and restricting proposal rights to clan nodes. These modifications enhance the protocol’s sealability and efficiency without altering its core consensus mechanism. The same approach can be applied to other DAG-based BFT protocols to achieve similar improvements.

[0199] Table 1: Ping latencies (in milliseconds (ms)) between GCP regions*

[0200] Source uus-e-1 uus-w-1 eeu-n- aas-ne-1 au-

[0201] 1 se-1 us-east 1 -a i 0.75 66.14 1 14.75 160.28 97.9

[0202] 8us-west 1 -a 66.15 0.66 158.13 89.56 38.3

[0203] 3europe-northl - 1 1 15.40 158.38 0.69 245.15 95.1 a | 3 asia- 159.89 90.05 246.01 0.66 105. northeast 1 -a 58 australia- 197.60 139.02 294.36 108.26 0.58 southeast! -a I

[0204] * Region names are abbreviated versions of the source regions. Docket No. UC-024

[0205] | J 50] Experimental setup. Evaluations were performed on the Google Cloud Platform (GCP), distributing nodes evenly across five distinct GCP regions: us-east I -b (South Carolina), us-west 1- a (Oregon), europe-northl-a (Hamina, Finland), asia-northeastl -a (Tokyo), and australia- southeastl-a (Sydney). Instances of e2-standard-32 were used, each featuring 32vCPUs, 128GB of memory, and up to 16Gbps network bandwidth. AH nodes ran on Ubuntu 20.04. Round-trip latencies are shown in Table 1.

[0206]

[0151] In these evaluations, each party generated a configurable number of transactions (512 random bytes each) for inclusion in its proposal, with a proposal containing up to 6000 transactions (i.e., 3 MB). Latency was measured as the average time between the creation of a transaction and its commit by all non-faulty nodes. Throughput was measured by the number of committed transactions per second. The evaluation excluded transaction execution, as it is orthogonal to consensus: execution must occur once consensus is achieved, regardless of the protocol used. The focus was on improving and assessing consensus performance metrics.

[0207] | .152] Methodology. In these evaluations, the number of input transactions per proposal was varied, selecting values from the set [1, 32, 63, 125, 250. 500, 1000, 1500, 2000, 3000, 4000, 5000, 6000], FIGS. 4A, 4B, and 4C show plots 400, 410, and 420, respectively of latency as a function of throughput for different protocols at n = 50, 100, and 150, respectively. The data points on the left of these plots 400, 410, 420 correspond to protocol performance with smaller numbers of input transactions, while those on the right reflect performance with larger numbers. As shown, throughput increases with load, accompanied by a modest increase in latency, until reaching a saturation point. Beyond this point, latency grows more sharply while throughput either plateaus or increases only marginally.

[0208] [153| Performance of single-clan Sailfish. Large-scale geo-distributed experiments are inherently costly. To reduce the expense of running these experiments, a slightly higher failure probability of 10~6« 2~20, which remains reasonable for many practical applications. With this failure probability, clans of nc~ 32, 60, and 80 nodes were determined for tested system sizes of n - 50, 100, and 150, respectively. Docket No. UC-024

[0209] 1154] C 'lan nodes were distributed evenly across GCP regions instead of randomly sampling them to produce more uniform output. The performance of Sailfish, single-clan Sailfish, and multi-clan Sailfish were evaluated for various system sizes. The corresponding throughput and latency results are shown in FIGS. 4A-C.

[0210] |155] S ailfish exhibited better throughput for the same number of input transactions due to its higher number of proposers. However, its throughput quickly saturated, even with a smaller number of input transactions. Tn contrast, single-clan Sailfish initially showed lower throughput for the same input transactions per proposer, as illustrated in FIG. 5.

[0211] |156] Nevertheless, single-clan Sailfish supported larger payload sizes and ultimately achieved higher throughput. As a result, single-clan Sailfish outperformed Sailfish in terms of throughput across all evaluated system sizes. This improvement was primarily attributed to the efficient dissemination of data only to the designated clan, significantly reducing bandwidth consumption. The difference in throughput becomes increasingly pronounced as the system scales, given that the clan size grows more slowly relative to the overall system size.

[0212] 1157] For a fixed system size, single-clan Sailfish showed lower commit latency compared to Sailfish. This may be because only the designated clan received the full block of transactions, while the rest of the parties received only the vertex, allowing quicker delivery. In tribe-assisted R.BC, only / c + 1 ECHO messages are needed from the clan, with the rest coming from the tribe. Since the vertex propagates faster, tribe-assisted RBC finishes sooner than standard RBC, leading to better latency in single-clan DAG-based BFT SMR.

[0213]

[0158] C ommit latency increased with system size for both protocols, likely due to a higher number of cryptographic operations and database reads. Specifically, for minimal pay loads, the latency was around 380ms at n = 50 and rose to approximately 1392ms at n 150. In this implementation, BLS signature aggregation was performed on a single thread, while the verification of aggregated signatures was parallelized. Additionally, for each newly delivered vertex, die system queries the database to verify delivery of its parents. These computationally intensive tasks significantly contributed to the latency at n = 150. These latencies can be further reduced with a more optimized implementation. Docket No. UC-024

[0214] 1159] Performance of multi-clan Sailfish. The perfonnance of multi-clan Sailfish was also evaluated. To form multiple clans with an acceptable failure probability, the system size must be sufficiently large. For n - 150, two clans were formed with a failure probability of 4.015 * 10-6« IO-6, as explained in Section 5.2. Therefore, the multi-clan protocol was only evaluated at n- 150. Only / ? = 150 was evaluated because of to the high cost of running these experiments. FIG. 4C compares the throughput and latency of multi-clan Sailfish with Sailfish and single-clan Sailfish, while the bar graph 5(10 of FIG. 5 shows the throughput relative to the number of input transactions per proposal. Sailfish’s throughput for 1500 transactions per proposal was not evaluated due to its significantly higher latency at 1000 transactions (as shown in FIG. 4C).

[0215] 1160] As shown in FIG. 5, multi-clan Sailfish achieved higher throughput for the same number of input transactions due to more efficient bandwidth use compared to Sailfish and single-clan Sailfish. In particular, the multi-clan Sailfish with two clans achieved roughly twice the throughput of single-clan Sailfish across all block sizes. This is believed to be because the size of a single clan in both protocols is comparable (80 vs. 75), making the data dissemination cost per clan nearly identical. With two clans operating in parallel, the throughput effectively doubles across block sizes. However, multi-clan Sailfish incurs higher latency at the same input rate because all parties need to process blocks, unlike single-clan Sailfish, where parties outside the designated clan propose and process only the vertex and can send ECHO messages more quickly.

[0216]

[0161] Scalability. Both single-clan and multi-clan Sailfish demonstrate stable performance even at moderately large system sizes (e.g., n ~ 150), whereas the throughput of Sailfish quickly saturates. This stability is primarily due to more efficient bandwidth utilization in clan-based protocols. In this regard, the clan-based approach of this disclosure offers significantly better scalability, making it a promising solution for larger systems.

[0217] NON-LIMITING DEFINITIONS

[0218]

[0162] T he terms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Docket No. UC-024

[0219] 1163] The terms “comprises” and / or “comprising”, when used in this specification, specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0220] |164] Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,’'' “comprising,” and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of “including, but not limited to,” As used herein, the terms “connected,” “coupled,” or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof. Additionally, the words “herein,” “above,” “below,” and words of similar import, when used in this application, refer to this application as a whole and not to any portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word “or,” in reference to a list of two or more items, covers all the following interpretations of the word: any of the items in the list, all the items in the list, and any combination of the items in the list.

[0221] |165] Several implementations of the disclosed technology are described above in reference to the figures. The computing devices on which the described technology may be implemented can include one or more central processing units, memory, input devices, output devices (e.g., display devices), storage devices, and network devices (e.g., network interfaces). The memory and storage devices are computer-readable storage media that can store instructions that implement at least portions of the described technology. In addition, the data structures and message structures can be stored or transmitted via a data transmission medium, such as a signal on a communications link.

[0222] 1166] As used herein, the word “or” refers to any possible permutation of a set of items. For example, the phrase “A, B, or C” refers to at least one of A, B, C, or any combination thereof, such as any of: A; B; C; A and B; A and C; B and C; A, B, and C; or multiple of any item, such as A and A; B, B, and C; A, A, B, C, and C; etc. Docket No. UC-024

[0223] 1167] The above Detailed Description of examples of the technology is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific examples for the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the technology. For example, while processes are presented in a given order, alternative implementations may perform routines having steps in a different order, and some processes may be deleted, moved, added, subdivided, combined, and / or modified to provide alternative or sub-combinations. Each of these processes may be implemented in a variety of different ways. Also, while processes are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel or may be performed at different times. Further, any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.

[0224] 1168] The teachings of the technology provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various examples described above can be combined to provide further implementations of the technology. Some alternative implementations of the technology may include not only additional elements to those implementations noted above, but also may include fewer elements.

[0225] |169] The description and illustration of one or more aspects provided in this application are not intended to limit or restrict the scope of the disclosure as claimed in any way. The aspects, examples, and details provided in this application are considered sufficient to convey possession and enable others to make and use the best mode of claimed disclosure. The claimed disclosure should not be construed as being limited to any aspect, example, or detail provided in this application. Regardless of whether shown and described in combination or separately, the various features are intended to be selectively rearranged, included or omitted to produce an embodiment with a particular set of features. Having been provided with the description and illustration of the present application, one skilled in the art may envision variations, modifications, and alternate aspects falling within the spirit of the broader aspects of the general inventive concept embodied in this application that do not depart from the broader scope of the claimed disclosure.

Claims

Docket No. UC-024CLAIMSWhat is claimed:

1. A method of operating a blockchain system comprising a plurality of decentralized computing nodes, the method comprising, by at least one of the decentralized computing nodes: receivine data to add as a block of a blockchain: determining an elected clan representing a subset of the plurality of the decentralized computing nodes that are capable of approving addition of the block to the blockchain with less than or equal to a threshold probability of failure; performing a block approval process comprising a plurality of rounds, wherein each round comprises: determining a vertex comprising a digest of the block; communicating the vertex to each computing node of the plurality of computing nodes of the blockchain system; communicating the block only to the decentralized computing nodes in the elected clan, while preventing communication of the block to the decentralized computing nodes that are not members of t he elected clan, thereby reducing bandwidth consumption by the blockchain system; recei ving one or more messages indicating receipt of the vertex and / or receipt of both the vertex and the block; determining that the block approval process is complete based on a number of messages received; and alter determining that the approval process is complete, adding the block to the blockchain.

2. The method of claim 1 , wherein the block approval process further comprises: transmitting, by a sender node, a value comprising the block to each node of the elected clan and a digest of the block to nodes not in the elected clan; upon receiving the value or the digest, transmitting, by each node, an ECHO message comprising the digest of the block to all nodes of the blockchain system;Docket No, UC-024 upon receiving at least a threshold number of ECHO messages from nodes in the elected clan, transmitting, by each node, a READY message to all nodes of the blockchain system; and upon receiving at least a threshold number of READY messages, determining that the block approval process is complete.

3. The method of claim 2, wherein, if a node in the elected clan has not received, the block but has received at least the threshold number of READY messages, the node is configured to download the block from another node in the elected clan.

4. The method of claim 1 , wherein; the block approval process is performed using a round-optimal reliable broadcast protocol that completes in two rounds, and wherein messages exchanged during the protocol are digitally signed by sending nodes; or the block approval process is performed using a reliable broadcast protocol that completes in three rounds, and wherein the protocol does not require messages exchanged during the protocol to be digitally signed by sending nodes.

5. The method of claim 1 , further comprising partitioning the plurality of decentralized computing nodes into a plurality of elected clans, wherein each elected clan independently receives, disseminates, and approves a respective block according to the block approval process.

6. The method of claim 5, wherein the approval processes for the plurality of elected clans are performed in parallel, such that each clan concurrently receives, disseminates, and approves its respective block independently of the other clan7. The method of claim 5, wherein the plurality of decentralized computing nodes are organized as a sharded blockchain, each elected clan corresponding to a respecti ve shard, orDocket No. UC-0248. The method of claim 5, wherein the plurality of decentralized computing nodes comprise a system with multiple sequencers, each elected clan corresponding to a respective sequencer.

9. The method of claim 1 , wherein the elected clan is selected randomly or pseudo- randomly from the plurality of decentralized computing nodes.

10. The method of claim 1, further comprising executing a transaction based on the received block by only the decentralized computing nodes in the elected clan.1 1. A system for implementing a blockchain, the system comprising: a plurality of decentralized computing nodes, wherein at least one of the decentralized computing nodes comprises a processor configured to: receive data to add as a block of a blockchain; determine an elected clan representing a subset of the plurality of the decentralized computing nodes that are capable of approving addition of the block to the blockchain with less than or equal to a threshold probability of failure; perform a block approval process comprising a plurality of rounds, wherein in each round at least a portion of the plurality of decentralized computing nodes is configured to: determine a vertex comprising a digest of the block; communicate the vertex to each computing node of the plurality of computing nodes of the blockchain system: communicate the block only to the decentralized computing nodes in the elected clan, while preventing communication of the block to the decentralized computing nodes that are not members of the elected clan, thereby reducing bandwidth consumption by the blockchain system; receive one or more messages indicating receipt of the vertex and / or receipt of both the vertex and the block; determine that the block approval process is complete based on a number of messages received; and after determining that the approval process is complete, add the block to the blockchain.Docket No. UC-02412. The system of claim 11, wherein the at least the portion of the plurality of computing nodes are further configured to perform the block approval process by: transmitting, by a sender node, a value comprising the block to each node of the elected clan and a digest of the block to nodes not in the elected clan; upon receiving the value or the digest, transmitting, by each node, an ECHO message comprising the digest of the block to all nodes of the blockchain system; upon receiving at least a threshold number of ECHO messages from nodes in the elected clan, transmitting, by each node, a READY message to all nodes of the blockchain system; and upon receiving at least a threshold number of READY messages, determining that the block approval process is complete.

13. The system of claim 12, wherein, if a node in the elected clan has not received the block but has received at least the threshold number of READY messages, the node is configured to download the block from another node in the elected clan.

14. The system of claim 11, wherein the processor is further configured to: perform block approval process using a round-optimal reliable broadcast protocol that completes in two rounds, and wherein messages exchanged during the protocol are digitally signed by sending nodes; or perform block approval process using a reliable broadcast protocol that completes in three rounds, and wherein the protocol does not require messages exchanged during the protocol to be digitally signed by sending nodes.

15. The system of claim 1 1 , wherein the plurality of decentralized computing nodes are partitioned into a plurality of elected clans, wherein each elected clan is configured to independently receive, disseminate, and approve a respective block according to the block approval process.Docket No. UC-02416. The system of claim 15, wherein processor is further configured to perform the approval processes for the plurality of elected clans in parallel, such that each clan concurrently receives, disseminates, and approves its respective block independently of the other clan17. The system of claim 15, wherein the plurality of decentralized computing nodes are organized as a sharded blockchain, each elected clan corresponding to a respecti ve shard, or18. The system of claim 15, wherein the plurality'' of decentralized computing nodes comprise a system with multiple sequencers, each elected clan corresponding to a respective sequencer.

19. The system of claim 11, wherein the processor is further con figured to determine the elected clan randomly or pseudo-randomly from the plurality of decentralized computing nodes.

20. The system of claim 1 1 , wherein the processor is further configured to execute a transaction based on the received block by only the decentralized computing nodes in the elected clan.

Images