💻 computer science

Hermes: Low Tail-Latency Via Prefix Consensus

हर्मिस (Hermes) $n=5f+1$ प्रक्रियाओं के लिए एक दो-चरणों वाला रोटेटिंग-लीडर बीएफटी (BFT) प्रोटोकॉल है जो किसी भी $n-f$ मतों से सबसे भारी सामान्य प्रीफिक्स (heaviest common prefix) को अंतिम रूप देने के लिए प्रीफिक्स कंसेंसस (prefix consensus) का उपयोग करके धीमे या क्रैश हुए लीडरों के कारण होने वाले टेल-लेटेंसी स्टॉल (tail-latency stalls) को समाप्त करता है, जिससे यह सुनिश्चित होता है कि व्यू एक्सपायर (views expire) होने पर भी प्रगति बनी रहे।

मूल लेखक: Alejandro Ranchal-Pedrosa, Dakai Kang, Neil Giridharan, Dahlia Malkhi, Mohammad Sadoghi, Ben Marsh

प्रकाशित 2026-07-29

📖 8 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Alejandro Ranchal-Pedrosa, Dakai Kang, Neil Giridharan, Dahlia Malkhi, Mohammad Sadoghi, Ben Marsh

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि दोस्तों का एक समूह एक फिल्म देखने का निर्णय लेने की कोशिश कर रहा है, लेकिन वे दुनिया के अलग-अलग कोनों में बिखरे हुए हैं, कुछ का इंटरनेट बहुत धीमा है, और कुछ शरारती दोस्त गलत लिंक भेजकर या ऑफलाइन होने का नाटक करके निर्णय लेने की प्रक्रिया में बाधा डालने की कोशिश कर रहे हैं। यह बाइजेंटाइन फॉल्ट टॉलरेंट (BFT) कंसेंसस (सहमति) की दुनिया है। कंप्यूटर विज्ञान में, यह इस बारे में है कि कैसे नेटवर्क के कंप्यूटर—जैसे कि ब्लॉकचेन में लेनदेन का क्रम—एक एकल सत्य पर सहमत होते हैं, जबकि वे किसी एक केंद्रीय बॉस पर भरोसा नहीं करते। लक्ष्य यह है कि कुछ कंप्यूटरों के क्रैश होने या दुर्भावनापूर्ण व्यवहार करने के बावजूद तेजी से (कम लेटेंसी के साथ) सहमति बनाई जा सके।

वर्षों से, ये सिस्टम एक "लीडर" (नेता) पर निर्भर रहे हैं जो अगले कदम का प्रस्ताव रखता है। यदि लीडर तेज और ईमानदार है, तो सभी जल्दी सहमत हो जाते हैं। लेकिन यदि लीडर धीमा है या क्रैश हो जाता है, तो पूरे समूह को एक टाइमर खत्म होने का इंतजार करना पड़ता है, उस लीडर को त्याग देना पड़ता है, और एक नया लीडर चुनना पड़ता है। यह एक कष्टदायक समझौता पैदा करता है: यदि आप टाइमर लंबा रखते हैं, तो आप एक टूटे हुए लीडर के लिए अनंत काल तक प्रतीक्षा करते हैं; यदि आप इसे छोटा रखते हैं, तो आप उन लीडरों को छोड़ने में समय बर्बाद करते हैं जो केवल थोड़े धीमे थे। यह "टाइमआउट डिलेमा" (समय सीमा का संकट) ही वह बाधा है जो सिस्टम के अंतिम छोर (टेल एंड) को धीमा कर देती है, जिससे सबसे धीमी रिक्वेस्ट को पूरा होने में बहुत समय लगता है।

यह पेपर हर्मीस (Hermes) पेश करता है, जो इस विशिष्ट सिरदर्द को हल करने के लिए डिज़ाइन किया गया एक नया प्रोटोकॉल है। एक धीमे लीडर को छोड़ने के बजाय, हर्मीस समूह को उस काम को पूरा करने की अनुमति देता है जिस पर वे सहमत हो सकते हैं, भले ही लीडर विफल हो जाए। यह एक बर्बाद हुए टाइमआउट को एक उत्पादक निर्णय में बदल देता है, यह सुनिश्चित करता है कि जो कुछ भी हो, सिस्टम अपनी प्रगति खोए बिना आगे बढ़ता रहे।

समस्या: "टाइमआउट ट्रैप" (समय सीमा का जाल)

एक रिले रेस की कल्पना करें जहाँ टीम कप्तान (लीडर) को अगले धावक को बैटन सौंपना होता है। यदि कप्तान तेज है, तो दौड़ सुचारू रूप से चलती है। लेकिन यदि कप्तान लड़खड़ा जाता है या बैटन गिरा देता है, तो पूरी टीम को एक नए कप्तान को चुनने और फिर से शुरू करने से पहले एक रेफरी की सीटी (टाइमआउट) का इंतजार करना पड़ता है।

पारंपरिक प्रणालियों में, यह सीटी एक जुआ है। यदि रेफरी इसे बहुत जल्दी बजा देता है, तो वे एक ऐसे कप्तान को रोक सकते हैं जो केवल थोड़ा धीमा था लेकिन दौड़ पूरी कर लेता। यदि वे बहुत अधिक इंतजार करते हैं, तो टीम एक टूटे हुए कप्तान के ठीक होने के इंतजार में खाली बैठी रहती है। दोनों ही मामलों में, खर्च किया गया समय "मृत समय" (डेड टाइम) है—कोई प्रगति नहीं होती है, और दौड़ रुक जाती है। यह "टेल लेटेंसी" की समस्या है: सबसे खराब परिदृश्य पूरे सिस्टम को नीचे खींच लेते हैं।

समाधान: हर्मीस और "कॉमन ग्राउंड" (साझा आधार)

हर्मीस खेल के नियमों को बदल देता है। एक धीमे लीडर को पूर्ण विफलता मानने के बजाय, हर्मीस समूह की आंशिक सहमति को एक जीत मानता है।

यह कैसे काम करता है, इसके लिए एक रचनात्मक उपमा देखें: कल्पना कीजिए कि टीम ब्लॉक्स (blocks) से एक लंबा टावर बनाने की कोशिश कर रही है।

पुराना तरीका: लीडर एक ब्लॉक रखता है। हर कोई इंतजार करता है। यदि लीडर रुक जाता है, तो टीम टाइमआउट का इंतजार करती है, फिर पूरे टावर को फेंक देती है और एक नए लीडर के साथ नया टावर बनाना शुरू कर देती है।
हर्मीस का तरीका: लीडर ब्लॉक्स रखना शुरू करता है, लेकिन हर कोई भी साथ-साथ अपने स्वयं के ब्लॉक्स रखना शुरू कर देता है। यदि लीडर तेज है, तो टीम लीडर के टावर को पूरी तरह से बनाती है। यदि लीडर अटक जाता है, तो टीम टावर को नहीं फेंकती। इसके बजाय, वे देखते हैं कि सभी ने कौन से ब्लॉक्स रखे हैं, उस सबसे लंबे हिस्से को ढूंढते हैं जिस पर सभी ब्लॉक्स के क्रम पर सहमत हैं, और उस हिस्से को "पूर्ण" घोषित कर देते हैं।

यही मुख्य नवाचार है: प्रिफिक्स कंसेंसस (Prefix Consensus)। पुराने दिनों में, यदि दो लोग थोड़े अलग टावरों के लिए वोट करते थे, तो उनके वोटों को असहमति माना जाता था और खारिज कर दिया जाता था। हर्मीस कहता है, "रुको, वे टावर के निचले 90% हिस्से पर सहमत हैं! आइए इसे लॉक करें और आगे बढ़ें।"

हर्मीस कैसे काम करता है: दो चरणों वाला नृत्य

हर्मीस "व्यूज़" (राउंड्स) में काम करता है, प्रत्येक में एक नामित लीडर होता है। यह एक चतुर दो-चरणीय नृत्य का उपयोग करता है:

राउंड 1 (प्रस्ताव): हर कोई टावर के अगले भाग को कैसा दिखना चाहिए, इसके बारे में अपना विचार प्रसारित करता है। लीडर का विचार कई विचारों में से एक है।
राउंड 2 (वोट):
- यदि लीडर तेज है: हर कोई लीडर के प्रस्ताव को देखता है, सहमत होता है, और उसके लिए वोट करता है। टावर केवल दो संदेश विलंब (2δ) में लीडर के पूर्ण ब्लॉक के साथ बढ़ता है।
- यदि लीडर धीमा है या क्रैश हो जाता है: टाइमर समाप्त हो जाता है। राउंड को "रद्द" करने के लिए वोट करने के बजाय, हर कोई उन प्रस्तावों में से सर्वश्रेष्ठ संभव सहमति के लिए वोट करता है जो उन्हें प्राप्त हुए हैं। वे "हेवीएस्ट कॉमन प्रिफिक्स" (HCP) को खोजते हैं—ब्लॉक्स का वह सबसे लंबा क्रम जिस पर सभी सहमत हैं, भले ही उनके प्रस्ताव अंत में अलग हो गए हों।

इसका मतलब है कि भले ही लीडर विफल हो जाए, समूह अपना 'व्यू' नहीं खोता है। वे टावर के साझा हिस्से को अंतिम रूप देते हैं और तुरंत अगला राउंड शुरू करते हैं। "टाइमआउट" वाला रास्ता, जो पहले एक डेड एंड (बंद रास्ता) था, अब एक परिणाम देता है।

"प्रिफिक्स" और "स्किप्स" का जादू

डेटा के कई लेन (जैसे ट्रैफिक के कई लेन वाला हाईवे) के साथ काम करने के लिए, हर्मीस पैरेंट-रिलेटिव डेल्टा टिपकट्स (parent-relative delta tipcuts) नामक एक विशेष एन्कोडिंग का उपयोग करता है।

इसे एक "चूज़ योर ओन एडवेंचर" (अपनी पसंद का रोमांच चुनें) पुस्तक की तरह समझें जहाँ हर पृष्ठ पिछले पृष्ठ का संदर्भ देता है। यदि ट्रैफिक का एक लेन एक कार (ब्लॉक) को मिस करता है, तो हर्मीस "त्रुटि" नहीं कहता। यह स्पष्ट रूप से उस स्थान को "स्किप्ड" (छोड़ा हुआ) के रूप में चिह्नित करता है और अगले कार पर चला जाता है। यह सिस्टम को विभिन्न प्रस्तावों की तुलना करने की अनुमति देता है भले ही उनमें अलग-अलग हिस्से गायब हों। यह दो कहानियों की तुलना करने जैसा है: भले ही एक कहानी एक पैराग्राफ छोड़ देती है और दूसरी उसे शामिल करती है, वे फिर भी शुरुआत और अंत पर सहमत हो सकते हैं, और सिस्टम उस सहमति को लॉक कर देता है।

परिणाम: गति और सुरक्षा

पेपर गणितीय रूप से सिद्ध करता है कि हर्मीस सुरक्षित है (दो ईमानदार लोग कभी भी अंतिम रूप दिए गए हिस्से पर असहमत नहीं होंगे) और जीवंत (लिवली) है (सिस्टम हमेशा आगे बढ़ता रहेगा)।

अच्छा मामला: यदि लीडर ईमानदार और तेज है, तो हर्मीस मौजूदा सर्वोत्तम सिस्टम जितना ही तेज है, जो 2δ (दो संदेश विलंब) में अंतिम रूप देता है।
बुरा मामला: यदि लीडर धीमा है या क्रैश हो जाता है, तो हर्मीस साझा सहमति को 2∆ + δ (जहाँ ∆ टाइमआउट है और δ नेटवर्क विलंब है) में अंतिम रूप देता है। महत्वपूर्ण रूप से, यह पुराने तरीके से तेज है जिसमें व्यू बदलने (view change) के लिए इंतजार करना पड़ता था, क्योंकि यह व्यू को छोड़ने के "बर्बाद" समय को छोड़ देता है।

लेखक दिखाते हैं कि इरेज़र कोडिंग (डेटा को टुकड़ों में तोड़ने का एक तरीका ताकि कुछ टुकड़े खो जाने पर भी इसे पुनर्गठित किया जा सके) का उपयोग करके, हर्मीस डेटा के कई लेन के साथ काम करते समय भी संचार लागत को कम रखता है।

यह क्यों मायने रखता है

हर्मीस "टाइमआउट डिलेमा" को यह बनाकर हल करता है कि टाइमआउट स्वयं उत्पादक बन जाए। यह विफलता के क्षण को प्रगति के क्षण में बदल देता है। यह पूछने के बजाय कि, "क्या लीडर पहुँच गया?" और देखने का इंतजार करने के बजाय, हर्मीस पूछता है, "हम सब किस बात पर सहमत हैं?" और आगे बढ़ता है।

एक जिज्ञासु किशोर के लिए, इसे एक ग्रुप चैट की तरह सोचें जहाँ सभी एक योजना पर सहमत होने की कोशिश कर रहे हैं। यदि वह व्यक्ति जो आमतौर पर योजना का सुझाव देता है, अटक जाता है, तो पुराना तरीका यह है कि उनके जवाब देने का इंतजार किया जाए या एक नए लीडर के साथ एक नई चैट शुरू की जाए। हर्मीस यह कहने जैसा है, "ठीक है, उन्होंने जवाब नहीं दिया, लेकिन देखो हमने जो विचार भेजे हैं। हम पहले तीन चरणों पर सहमत हैं। आइए उन्हें लॉक करें और चौथे चरण की योजना बनाना शुरू करें।" यह समूह को आगे बढ़ाने का एक स्मार्टर और अधिक लचीला तरीका है, चाहे कोई भी गेंद छोड़ दे।

तकनीकी सारांश: हेर्मिस (Hermes): लो टेल-लेटेंसी वाया प्रिफिक्स कंसेंसस

1. समस्या विवरण (Problem Statement)

लीडर-आधारित बायज़ेंटाइन फॉल्ट टॉलरेंट (BFT) प्रोटोकॉल आमतौर पर लेनदेन को केवल तभी अंतिम रूप (finalize) देते हैं जब एक निर्दिष्ट लीडर समय पर उपलब्ध हो। यदि कोई लीडर क्रैश हो जाता है या धीमा होता है, तो व्यू (view) को टाइमआउट के माध्यम से समाप्त करना पड़ता है, जिसके परिणामस्वरूप एक "बर्बाद" (wasted) व्यू प्राप्त होता है जहाँ कोई प्रगति नहीं हो पाती। यह टाइमआउट कॉन्फ़िगरेशन में एक मौलिक ट्रेड-ऑफ (trade-off) पैदा करता है:

रूढ़िवादी टाइमआउट (Conservative timeouts): धीमे लीडरों को सहन करते हैं लेकिन प्रत्येक क्रैश हुए लीडर को एक लंबे ठहराव (stall) में बदल देते हैं।
आक्रामक टाइमआउट (Aggressive timeouts): क्रैश हुए लीडरों को जल्दी स्किप करते हैं लेकिन उन लीडरों के व्यू को भी शून्य कर देते हैं जो केवल धीमे थे (जो जियो-डिस्ट्रीब्यूटेड सिस्टम में एक सामान्य घटना है)।

दोनों ही मामलों में, एक्सपायर्ड व्यू बर्बाद हो जाता है, और अनुरोध को फाइनल करने के लिए व्यू चेंज और अगले लीडर के राउंड ट्रिप की प्रतीक्षा करनी पड़ती है। यह ट्रेड-ऑफ, न कि "गुड केस" प्रदर्शन, सिस्टम की टेल-लेटेंसी (tail latency) को नियंत्रित करता है। इसके अलावा, आधुनिक आर्किटेक्चर अक्सर डेटा प्रसार (जैसे DAGs, लेन-आधारित डिज़ाइन) को कंसेंसस ऑर्डरिंग से अलग करते हैं। इन सेटिंग्स में, प्रस्ताव (proposals) एक स्ट्रीम के प्रिफिक्स (prefixes) होते हैं, और एक ही व्यू के भीतर ईमानदार प्रस्ताव नेटवर्क जिटर (jitter) के कारण केवल सफिक्स (suffix) में भिन्न हो सकते हैं। मौजूदा प्रोटोकॉल इन गैर-मिलान वाले वोटों को असहमति मानकर खारिज कर देते हैं, जिससे उनके बीच साझा किए गए कॉमन प्रिफिक्स का उपयोग करने में विफलता होती है।

2. कार्यप्रणाली (Methodology)

हेर्मिस एक दो-राउंड रोटेटिंग-लीडर प्रोटोकॉल है जिसे आंशिक सिंक्रोनिसिटी (partial synchrony) के तहत $n = 5f + 1$ प्रक्रियाओं के लिए डिज़ाइन किया गया है। यह प्रिफिक्स कंसेंसस (Prefix Consensus) पेश करता है, एक ऐसी व्यवस्था जहाँ वोट एक प्रिफिक्स संबंध ( $\preceq$ ) द्वारा क्रमबद्ध मूल्यों को ले जाते हैं, और क्वोरम (quorum) समानता के बजाय तुलनीयता (comparability) की मांग करते हैं।

मुख्य तंत्र (Core Mechanisms)

दो-राउंड संरचना (Two-Round Structure):
1. राउंड 1 (प्रस्ताव/Proposal): प्रत्येक प्रक्रिया एक जस्टिफाइड प्रस्ताव प्रसारित करती है। राउंड-रॉबिन लीडर का प्रस्ताव $n$ में से एक होता है।
2. राउंड 2 (मतदान/Voting): प्रत्येक प्रक्रिया एक एकल वोट डालती है।
  - यदि लीडर का प्रस्ताव समय पर डिलीवर हो जाता है, तो प्रक्रियाएं उसके लिए वोट करती हैं।
  - यदि एक टाइमआउट ( $2\Delta$ ) बीत जाता है और $n-f$ वैध प्रस्ताव प्राप्त होते हैं, तो प्रक्रियाएं उपलब्ध सेटों में से चुने गए एक फालबैक प्रस्ताव (fallback proposal) के लिए वोट करती हैं।
- महत्वपूर्ण रूप से, इसमें कोई नलिफाई (nullify) वोट नहीं होते।
क्वोरम परिभाषाएँ (Quorum Definitions):
- M-नोटराइजेशन (M-notarization): $2f+1$ युग्मवार तुलनीय (pairwise comparable) वोटों का एक सेट। यह व्यू को अगले व्यू में आगे बढ़ने की अनुमति देता है।
- L-नोटराइजेशन (L-notarization): $n-f = 4f+1$ वैध वोटों का एक सेट (जिन्हें समान होने की आवश्यकता नहीं है)। यह वोटों के हैवीएस्ट कॉमन प्रिफिक्स (Heaviest Common Prefix - HCP) को फाइनलाइज करता है।
टाइमआउट को संभालना (Handling Timeouts):
धीमे लीडर के मामले में व्यू को शून्य करने के बजाय, हेर्मिस $n-f$ वोटों के HCP को फाइनलाइज करने के लिए टाइमआउट पथ का उपयोग करता है। एक आक्रामक टाइमआउट अब केवल उस सफिक्स (suffix) की लागत लेता है जहाँ वोट असहमत होते हैं, न कि पूरे व्यू की। HCP को $2\Delta + \delta$ पर फाइनलाइज किया जाता है।
वैल्यू स्पेस इंस्टेंशिएशन (Value Space Instantiations):
प्रोटोकॉल को एक एब्स्ट्रैक्ट प्रिफिक्स-ऑर्डर्ड स्पेस पर इंस्टेंशिएट किया गया है और इसे दो विशिष्ट परिदृश्यों पर लागू किया गया है:
1. सिंगल-लेन (Single-Lane/Finality Gadget): एक डायनेमिकली उपलब्ध चेन (जैसे Ethereum) पर। यहाँ वैल्यूज 'चेन टिप्स' हैं; प्रिफिक्स संबंध पूर्वज (ancestry) है।
2. मल्टी-लेन (Multi-Lane/Autobahn-style): यह समवर्ती लेन (concurrent lanes) के डेटा को ऑर्डर करता है। यह तीन विशिष्ट चुनौतियों को संबोधित करता है:
  - डिटरमिनिस्टिक इंटरलीविंग (Deterministic Interleaving): लेन पोजीशन के लिए एक वैश्विक क्रम।
  - पैरेंट-रिलेटिव डेल्टा टिपकट्स (Parent-Relative Delta Tipcuts): एक कॉम्पैक्ट प्रतिनिधित्व जो पैरेंट आइडेंटिफायर और स्पष्ट स्किप मार्कर्स का उपयोग करता है ताकि पूर्ण वैल्यू ट्रांसमिट किए बिना हेट्रोजेनियस लेन स्पीड को संभाला जा सके।
  - सेंडर-इंडेक्स्ड इरेज़र-कोडेड एम्प्लीफिकेशन (Sender-Indexed Erasure-Coded Amplification): यह सुनिश्चित करने के लिए कि संचार जटिलता को $O(n^3 \hat{m})$ तक बढ़ाए बिना उपलब्धता सुनिश्चित हो, प्रस्तावों को इरेज़र कोड के माध्यम से एम्प्लीफाई किया जाता है। जस्टिफिकेशन आइडेंटिफायर ले जाते हैं, और फ्रैगमेंट को आवश्यकतानुसार पुनर्गठित (reconstruct) किया जाता है।

3. मुख्य योगदान (Key Contributions)

हेर्मिस प्रोटोकॉल (Hermes Protocol): बिना किसी नलिफिकेशन पाथ के $n=5f+1$ $n = 5 f + 1$ वाला एक दो-राउंड रोटेटिंग-लीडर प्रोटोकॉल।
- गुड केस (Good Case): एक समय पर उपलब्ध ईमानदार लीडर के तहत $2\delta$ फाइनलाइजेशन।
- बैड केस (Bad Case): किसी भी $n-f$ वोटों के HCP का $2\Delta + \delta$ पर फाइनलाइजेशन।
- सेफ्टी और लाइवनेस (Safety & Liveness): एक एब्स्ट्रैक्ट प्रिफिक्स वैल्यू स्पेस पर सिद्ध।
सिंगल-लेन इंस्टेंशिएशन (Single-Lane Instantiation): उपलब्ध चेन्स के लिए एक फाइनलिटी गैजेट जहाँ वैल्यूज चेन टिप्स हैं।
मल्टी-लेन इंस्टेंशिएशन (Multi-Lane Instantiation): Autobahn-शैली की लेन्स के लिए एक डिज़ाइन जिसमें शामिल हैं:
- डिटरमिनिस्टिक इंटरलीविंग।
- स्पष्ट स्किप सर्टिफिकेशन के साथ पैरेंट-रिलेटिव डेल्टा टिपकट्स।
- सेंडर-इंडेक्स्ड इरेज़र-कोडेड एम्प्लीफिकेशन।
- जटिलता (Complexity): प्रति व्यू $O(n^2 \hat{m} + \lambda n^3)$ बिट्स और $O(n^2)$ संदेश (जहाँ $\hat{m}$ लेन की संख्या है और $\lambda$ सुरक्षा पैरामीटर है)।
कार्यान्वयन और मूल्यांकन (Implementation and Evaluation): पेपर में एक कार्यान्वयन और मूल्यांकन (सेक्शन 8) शामिल है, हालांकि विशिष्ट संख्यात्मक परिणाम दिए गए टेक्स्ट में "Add results" के रूप में चिह्नित हैं।

4. परिणाम और प्रदर्शन (Results and Performance)

लेटेंसी (Latency):
- समय पर उपलब्ध लीडर (Timely Leader): $2\delta$ में फाइनलाइज करता है।
- धीमा/क्रैश हुआ लीडर (Slow/Crashed Leader): HCP को $2\Delta + \delta$ में फाइनलाइज करता है। यह पारंपरिक प्रोटोकॉल की तुलना में एक महत्वपूर्ण सुधार है जहाँ एक धीमा लीडर पूर्ण व्यू चेंज और उसके बाद के $2\delta$ राउंड का कारण बनता है, जिससे पहले फाइनलाइजेशन से पहले $2\Delta + 3\delta$ या अधिक का समय लगता है।
कम्युनिकेशन (Communication):
- एम्प्लीफिकेशन के साथ मल्टी-लेन सेटिंग में, प्रोटोकॉल फुल वैल्यू फॉरवर्ड करने से जुड़ी चतुर्थांश जटिलता ( $O(n^3 \hat{m})$ ) से बचता है।
- गुड केस में $O(n^2)$ संदेश बने रहते हैं। दोषों (faults) के तहत, एम्प्लीफिकेशन ट्रैफिक के कारण मैसेज कॉम्प्लेक्सिटी $O(n^3)$ तक बढ़ सकती है, लेकिन बिट कॉम्प्लेक्सिटी नियंत्रित रहती है।
टेल-लेटेंसी (Tail Latency): टाइमआउट पथ को उत्पादक बनाकर, हेर्मिस "बर्बाद व्यू" (wasted view) पेनल्टी को समाप्त करता है। एक अनुरोध जो खराब व्यू में आता है, वह केवल टाइमआउट और HCP फाइनलाइजेशन का भुगतान करता है, न कि पूर्ण व्यू चेंज चक्र की प्रतीक्षा करता है।

5. महत्व (Significance)

पेपर का दावा है कि हेर्मिस रिस्पॉन्सिवनेस (व्यू कितनी तेज़ी से बदलता है) और स्थिरता (कितने व्यू चेंज प्रगति उत्पन्न करते हैं) के बीच के ट्रेड-ऑफ को मौलिक रूप से बदल देता है।

उत्पादक टाइमआउट (Productive Timeouts): पिछले डिज़ाइनों के विपरीत जहाँ टाइमआउट का अर्थ एक शून्य (voided) व्यू होता है, हेर्मिस यह सुनिश्चित करता है कि विफल लीडर वाला व्यू भी डेटा स्ट्रीम के एक उपयोगी प्रिफिक्स को फाइनलाइज करता है।
आधुनिक आर्किटेक्चर के साथ अनुकूलता (Compatibility with Modern Architectures): यह उपलब्ध डेटा प्रसार परतों (जैसे DAGs या लेन-आधारित सिस्टम) और कंसेंसस के बीच के अंतर को पाटता है, जिससे फाइनलिटी गैजेट उन ब्लॉक्स को ऑर्डर कर सकता है जो पहले ही प्रसारित हो चुके हैं लेकिन प्रसार परत में थोड़ा भिन्न हो सकते हैं।
इष्टतमता (Optimality): हेर्मिस गुड केस के लिए सैद्धांतिक निचली सीमा $2\delta$ प्राप्त करता है और साथ ही टेल-लेटेंसी की समस्या को हल करता है जो लीडर-आधारित BFT में बनी हुई थी, इसके लिए किसी अलग रिकवरी प्रोटोकॉल या रेसिंग मैकेनिज्म की आवश्यकता नहीं है।

हेर्मिस को अपने वर्ग का एकमात्र प्रोटोकॉल के रूप में प्रस्तुत किया गया है जहाँ विफल लीडर का व्यू स्वयं फाइनलाइज होता है, जो Minimmit (जो ऐसे व्यू को शून्य करता है) और Raptr (जो उपलब्धता के लिए प्रिफिक्स वोटिंग का उपयोग करता है लेकिन एक ही लीडर के प्रस्ताव के भीतर) जैसे प्रोटोकॉल के विपरीत है।