Enhancing Asynchronous Common Subset with Trusted Hardware
Explore the research on enhancing asynchronous common subset with trusted hardware for Byzantine Fault Tolerance protocols, addressing challenges in asynchrony and proposing solutions for scalability in distributed systems.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
MONASH INFORMATION TECHNOLOGY Janus: Enhancing Asynchronous Common Subset with Trusted Hardware Authors: Liangrong Zhao (Monash University) Hans Schmiedel (University of Sydney) Qing Wang (Data61, CSIRO) Jiangshan Yu (University of Sydney) Annual Computer Security Applications Conference (ACSAC) 2024
Background: Byzantine Fault Tolerance (BFT) Protocols BFT protocols: consensus algorithms are designed to enable a distributed system to reach agreement on a particular state or value. PBFT, Castro & Liskov 1999 MONASH INFORMATION TECHNOLOGY
Asynchrony: a more realistic assumption Partially synchronous there exists a Global Stabilization Time (GST), Asynchronous there is no time bound for messages to be delivered messages might be delayed arbitrarily after which all the messages are synchronized there is a time bound for all messages to be delivered but this time bound is unknown. Why we pick asynchronous A weaker network assumption makes the protocol design robust in real application scenarios MONASH INFORMATION TECHNOLOGY
Challenges in the asynchrony: correct processes with inconsistent inputs Cause: correct processes might not all be able to be fully synchronized at a time of a period Reason: the time for a message to be delivered is unpredictable and unbounded MONASH INFORMATION TECHNOLOGY
Asynchronous common subset: path to the asynchrony ACS Each process proposes a value All honest processes end up with the same set of values MONASH INFORMATION TECHNOLOGY
Asynchronous common subset: break into details Asynchronous Common Subset Merge Locally work out a deterministic order of proposals in ACS Broadcast Propagating a proposal in the Agreement Vote on each delivered proposal network MONASH INFORMATION TECHNOLOGY
Research question and challenges Scalability: To tolerate a larger network in high-throughput scenarios Proposed solution: Parallel design, but with only one consensus instance Network: To enable protocols to work in harsh network conditions Expected improvement: An asynchronous protocol Complexity: To minimize the amount of messages exchanged in the network Expected improvement: The general case is O(n3), we aim at O(n) per proposal Resilience: To tolerate more faults in a fix size network Expected improvement: The general case is 3f+1, we aim at 2f+1 MONASH INFORMATION TECHNOLOGY
Research question and challenges Scalability: To tolerate a larger network in high-throughput scenarios Proposed solution: Parallel design, but with only one consensus instance Network: To enable protocols to work in harsh network conditions Expected improvement: An asynchronous protocol Complexity: To minimize the amount of messages exchanged in the network Expected improvement: The general case is O(n3), we aim at O(n) per proposal Resilience: To tolerate more faults in a fix size network Expected improvement: The general case is 3f+1, we aim at 2f+1 MONASH INFORMATION TECHNOLOGY
Trusted hardware: solution to improve the resilience Trusted components: each process is equipped with the same configuration the trusted components can only be accessed via the preconfigured interfaces trusted components include: a counter and a small storage Secure storage: Monotonic counter: the secure storage is in the enclave and lightweight the size of the stored data is a n-size vector issue ever-growing numbers to messages messages from a process are sequential with unique non-decreasing identifiers MONASH INFORMATION TECHNOLOGY
Complexity reduction: from reliable broadcast to provable broadcast Reliable broadcast Linear broadcast Totality: A correct delivers m, all correct deliver m Consistency: A correct delivers m, all correct deliver m or nothing MONASH INFORMATION TECHNOLOGY
Complexity reduction: the issue of property loss Reliable broadcast Linear broadcast P0, P2and P3are at the same delivery state. P1 s message is delivered to P2, but not to P0or P3 MONASH INFORMATION TECHNOLOGY
Complexity reduction: Solution to the property loss Propose: the original value is yet received Endorse: the original value is received and returned Cert: the original value is delivered Propose: vote 0 Endorse: vote null Cert: vote 1 MONASH INFORMATION TECHNOLOGY
Merging rules: Solution to the property loss 1. Upon receiving a valid Propose message 2. Upon receiving a valid Cert message 3. Upon receiving n-f valid Vote messages 4. Upon receiving a valid vote message with its original Propose message attached 5. Upon receiving a valid Vote message with 0 and the common coin is 0 6. Upon receiving a valid Vote message with 1 7. Upon receiving n-f valid Vote messages with 1 and the common coin is 1 8. Upon receiving n-f valid Vote messages with 0 and the common coin is 0 MONASH INFORMATION TECHNOLOGY
Aggregated agreement: Pushing the agreement complexity to optimal Agreement protocol with vector inputs Each process broadcast a vector of votes instead of one vote All processes exchange the vote vector The final agreement outcome is a vector of binary values Each value of the final outputs is reached independently Each element of the input vectors is equivalent to a traditional binary agreement execution MONASH INFORMATION TECHNOLOGY
Janus: an ACS protocol that combines everything together Provable broadcast aggregated vector MONASH INFORMATION TECHNOLOGY
Juno: Performance Throughputs Latency MONASH INFORMATION TECHNOLOGY
Revisit research questions Scalability: To tolerate a larger network in high-throughput scenarios Proposed solution: Parallel design, but with only one consensus instance Network: To enable protocols to work in harsh network conditions Expected improvement: An asynchronous protocol Complexity: To minimize the amount of messages exchanged in the network Expected improvement: The general case is O(n3), we aim at O(n) per proposal Resilience: To tolerate more faults in a fix size network Expected improvement: The general case is 3f+1, we aim at 2f+1 MONASH INFORMATION TECHNOLOGY
MONASH INFORMATION TECHNOLOGY THANK YOU!
