 Sajad Rahmana from the University of California, Davis, who will be discussing Ring BFT, Resilient Consensus Over Sharded Ring Technology. Thanks, Jonathan, for introduction, and thanks for your interesting talk. I'm Sajad Rahmana. Today I'm going to talk about Ring BFT, Resilient Consensus Over the Sharded Ring Topology. This work has been done with my colleagues, Suyash Rohan Dhruvan Mohamed Sathwani from the Exploratory System Lab at University of California, Davis. Let me get a little bit of background and chronology of consensus for you. The first practical Byzantine consensus protocol was PBFT that relied on three phases of communication came out in 1999. We tried to use a speculative execution to reduce a phase in our previous work called PoE. And after that, we even moved a scalability filter with paralyzing the consensus with our RCC protocol. The next step, we did GOVFT to scale even to the VAN area with the global consensus. And the question would be, what would be the next step? One open avenue would be moving from a costly, fully replicated consensus protocol to a sharded consensus protocol. In a replicated system, in a replicated consensus protocol, communication among all the nodes are required mostly. But in the sharded consensus environment, there are two types of consensus. The first one would be a single shard consensus, which would be the common between most sharding consensus protocol, which is cheap and paralyzed. And the next one, which is the focus of this work would be the multi-sharder cross-shard transaction, which is the main challenges of sharding consensus protocols and also expensive and required expensive communication among the shards. For our related work, there are several interesting sharding consensus protocol in Byzantine environment. We picked two recent related to the database community to compare with that work. The first one, it attests a hyperledger or AHL, which has been published in Sigma 19, which relied on a reference committee to handle and run and coordinate cross-shard transaction. When a request from the client comes, reference committee is responsible to coordinate with the all-involved shard and requires multiple rounds of all-to-all communication between the reference committee and all denotes. The next related work would be the sharder that has been published in Sigma 21, which runs an instance of PDFD among all the involved shard and also requires multiple rounds of all-to-all communication, like PDFD among all replicas in the system. In the previous work, there's a might be overlooked problem when it comes to the multi-region or van area. When there are different shards in different areas in the world, we all know there's a limited bandwidth between these shards and this bandwidth would be kind of bottlenecked. And when the number of messages grows and there are all-to-all communication in the cross-shard transaction, queuing delay and message processing will also be a kind of bottleneck for the cross-shard transaction. Our protocol called RingBFT is a topology of sharding consensus protocol which relies on three easy and simple steps. Process, forward, retransmit, and do this in all involved shards going around the rings without any all-to-all communication. The first phase of our RingBFT protocol which called process is actually running an instance of PDFD locally with ordered the cross-shard transaction in the first shard in the ring. And after doing that, the next step would be forwarding the results of PDFD or the consensus of the previous shard to the next shard and going through the ring and in the next round executing the transaction, the cross-shard transaction in the next shard. Now let's dive deep into our RingBFT protocol and its architecture. Imagine that we have four shards in four different regions in the world and there's a cross-shard transaction that touches data in all of the four shards. A client sends a request in the first involved shard in the ring with the order. First, the primary of first shard will run a BF, an instance of PDFD or a consensus protocol to order the transaction in the first shard and after doing the consensus, the replicas inside the first shard will forward the results of consensus with a minimal intercluster communication that I will be explaining later to the next shard. And after that, the next shard would do an instance of consensus to order a transaction locally, going to the next shard and going all the involved shard through the ring. And after it reaches to the final shard in the ring, the decision has been made. And in the next round through the ring, execution can happen in all the involved shards. As Yele described the cluster sending solution for the intercluster communication in this environment, we use the minimal global linear communication between our shards. So for example, if we have two shards here and we want to send the results of local agreement, PBSD in the previous shard to the next shard, we use the linear pattern of communication which is one-to-one communication between the first shard to the next shard. And this communication would be the results or commit certificate of the consensus instance in the previous shard. So after this phase of global linear communication in order to make sure that everybody in the second shard has gotten the results of previous shard, we do another local cheap round of communication. So in comparison between this round and previous round, this local round is cheap communication. And after that, they wait for the commit certificate. So now let's get into the recovery scenarios. What would we do if bad things happen, if the failure happened? We have three recovery scenarios. The first one would be local timer or local failure. If for any reason, the primary of each shard in handling cross shard transaction failed to replicate or order the transaction locally in their cluster, the local timer will expire and the nodes inside that shard, inside that cluster will do a view change to replace the primary. The next recovery scenario is when there is no communication between two shards. This can happen for a lot of reasons, for a network being bad or for any other, for faulty nodes or any other. If there is no communication between two shards for sending commit certificate or results of the consensus protocol, the transmit timer expires and the nodes inside shard run after reaching the commit estate, they keep retransmitting the results of their consensus to the next shard when the transmit timer expires. The last recovery scenario is when there's a partial communication. The partial communication will also can happen for multiple reasons. First would be the communication is lost, the primary, the nodes inside the first shard are faulty, they are preventing to send messages to the next shard or any other reason. In that case, if there is not enough certificate in the second shard, the remote timer in the second shard will expire and they will ask for a remote view change in the previous shard. With this one, with this scenario, which is the last recovery scenario, we can initiate a view change in the previous shard. One very interesting aspects of our ring gift protocol is to handle interdependent transaction. There are a few, or I can say a few, a number of sharding consensus protocol that looks at interdependent transaction. But in the dependent transaction, we mean when the execution, the partial execution of the transaction, multi-shard transaction in different shards requires partial data from the previous shard. Ring BFT allows you to do that. As I explained before in the first round, the consensus happens in each shard and in the second round, the execution happens. And in the second round, when we are going through the ring, we can execute our partial, each shard can do their partial execution and send the required data to the next shard and going through the ring, all the data would be available for our shard to execute partially. So we can handle interdependent transaction. We have implemented our ring BFT protocol in a resilient DB, which is open source permissioned blockchain fabric. You can take a look at resilientdb.com. The resilient DB architecture has two-part interface in the blockchain core. We have implemented the ring BFT protocol inside the blockchain core, which has a very sophisticated parallel and multi-sharded structure with having different input threads, batching consensus threads and execution threads and also output threads, having underlying different storage layers for our resilientdb. We have evaluated ring BFT resilientdb deploying on Google Cloud, scaling up to 540 replicas. Each of them has 16 COVID-16 GB memory. The reason that we didn't go up more than 540 nodes was that the Google Cloud wouldn't give us the quota to do so. We have deployed resilientdb on 15 different regions, as you can see the names of the regions on the right side. And we fixed the fitting to 20 replicas per region with 15 regions. And we also shuffled the charts to prevent chart proximity. The first evaluation would be the impact of the number of charts. We fixed the number of nodes in each chart and we kept increasing the number of charts. And as you can see in the left graph, that's showing the throughput of three protocols, ring BFT, sharper and hL. As you can see, the throughput of ring BFT is not decreasing at all. And that's because the level of replication and the communication in each chart is not changing when you increase the number of chart. And that does not apply to, as a typology or sharper because by increasing the number of chart, the pattern of communication grows quadratically. And it would be bottleneck. And the reason that hL is the least one is that the reference committee is a bottleneck for a dataset hyper legend. Our next evaluation would be on the impact of cross chart workload. How, when we increasing the cross chart workload, how would be the performance of these three protocols? And as you can see, when we have zero cross chart throughput, we have reached a one million transaction per second on 540 nodes in 15 different regions. And as we increase the cross chart workload, all three protocols goes down. But as you can see, we have ring BFT is doing 20 times better than hL and four times better than sharper. Up to now, we scaled our BFT consensus to the charted consensus even more using the ring BFT protocol. The next step for scaling Byzantine consensus to even more could be high reach consensus, reconfigurable consensus or SGX accelerated consensus. Thanks everybody for listening. And yeah, that's it for me. Thank you. You can take it over Jonathan.