הסכמה

עסקאות נכנסות בתור לפני Sumeragi מציעה אותן בלוק. מבטיחים אישור באופן עצמאי ומבצעים את ההצעה, ולאחר מכן חותמים רק על המעבר של המדינה שהם יכולים להדפיס. בלוק מתחייב לאחר שהקוואורום המבטיח הנדרש מסכים על התוצאה הזאת והנטל המשיל המתאים זמין.

כל הרשתות Iroha 3 משתמשות בנתיבי זמינות נתונים ודרך שידור אמינה. אלה דרישות קונסנזוס, ולא תכונות הפעלת אופציונליות.

Sumeragi

Sumeragi הוא מנועי ההסכמה של Iroha עם סובלנות לטעויות ביזנטיות. זה לוקח עסקאות מהצורה, גורם לשכבי המבטיחים להסכים על אותו בלוק מאורר, ומסיים את הבלוק רק לאחר שמספר מבטינים משחזרו את אותה תוצאה וחתמו על תעודת ההתחייבות.

נתיב ההצעה וההתחייבויות

Sumeragi מפעיל את ההדף קדימה בגובה של בלוק אחד בכל פעם. בכל גובה, מבקש אחד פועל כמציע עבור המבטא הנוכחי. המבקש מסיר עסקאות זכיות מן השורה, בונה בלוק מועמד ומודיע על ההצעה לקבוצה הפעילה של מבקשים.

אותו צינור Sumeragi משמש בשני השיגורים עם רשות וביקורת רשמית (NPoS):

1. מוטיבציה מציעה חסימה של עסקאות בשורה.
2. מבטיחים מאשרים את ההצעה על ידי ביצוע העסקאות נגד אותה מדינה עולמית.
3. מבטיחים מחליפים קולות ותעודות קוורום על הגובה והצפית הנוכחיים.
4. ברגע שהקווורום הושג, עמיתים מחברים את הבלוק ומעודדים את מצבם העולמי.

מבטיחים חותמים רק על נתונים שהם יכולים לשחזר באופן מקומי. לפני ההצבעה, מבטיח בודק שההצעה שייכת לשרשרת צפויה, גובה ותצפית; כי החתימות והגבולות של העסקה הם תקפים; כי מסלול המסלול וביטחון המבצעים הם דטרמיסטיים; אם התוצאה המקומית שונה, המאשר דוחה את ההצעה במקום להצביע בעדה.

הצבעות הן מסרים קונצנזוס חתומים קטנים. הם מתייחסים לבלאק המוצע, הגובה, החזון והזהותו של המאשר. הקולקטורים מצטברים את ההצבעות האלה לתוך תעודת קוורום או תעודת מחויבות. האישור הוא הוכחה קבועה לכך שמספר מסכימים מצאו את אותה תוצאה עבור אותו בלוק.

קוורום, קולקטורים ומרגישים

ספירת מבקרי ההצבעה n מגדירה את תקציב הטעות הביזנטנית. עבור רשתות עם לפחות ארבעה מבקרי הצבע, התקציב הוא f = floor((n - 1) / 3) והקולורום של הקביעה הוא 2f + 1. עבור אחד עד שלושה מתוקנים, כל המתוקנים נדרשים להתחייב, אשר הוא שימושי לפיתוח אבל אין לו פנאי מקוון מעשית.

הקולקטורים הם אופטימיזציה מלאה. במקום שכל מבקש שולח כל קול לכל מבקש אחר, Sumeragi יכול לבחור קולקטור אחד או יותר לגובה. הקולקטורים אוספים קולות, פורסים את התקדמות הקוורום, ומצמצמצם את סכום תנועת קולות כפופים. GET /v1/sumeragi/collectors; ה- CLI זה... ops sumeragi telemetry תמונה מיידית מדווחת את מספר הקולקטורים הנוכחי.

עמידי המצפיעים יכולים להעברת בלוקים מחויבים, אבל הם לא מציעים, מצביעים, או אוספים קולות או סופרים לקוורום המחייב. השתמש במצפיעים כאשר פיתוח זקוק ליכולת חיפוש מקומית, אינדקסינג, מעקב, או כפיית בלוק אזורי מבלי להגביר את מספר המאשרים להצביע.

צפו בשינויים והתאוששות

תצפית היא ניסיון של Sumeragi לסיים גובה אחד עם מתכנן מסוים ותוכנית זמן. אם הצעה, עומס מועיל, הצבעה או ביצוע התקדמות מפסקות, מדד הקצב יכול להעביר את הגובה לתצפית מאוחר יותר. שינוי תצפיה לא כותב מחדש בלוק מחויבת. זה משנה את האופן שבו מבקשי אישור מנסים לסיים את הגובה הלא מחויבת, מעבירים קדימה את הקוורום הידוע ביותר או מקיימים ראיות כך שווים לא מסיימים בלוקים סותרים .

השיקום של עומס תועלת הוא נפרד מההחלטה הסופית. עמית יכול לקבל קוורום או תעודת מחויבות לפני שהוא יש את המטען המשמעותי של הבלוק המלא. במקרה זה, העמית משתמש בשידור אמין (RBC) או סינכרון בלוק כדי לשחזר את המטען הפועל, מאשר אותו נגד ההשפים המפורסם, ורק לאחר מכן ישתמש בלוק למדינה העולמית ו Kura.

אמצעי הסכמה

המופע הנבחר שולט כיצד קבוצת האישור נוצרת ומפעלת. הוא מוצהר בראשית דרך consensus_mode ובספירה של עמיתים באמצעות sumeragi.consensus_mode. התייחסו לזה כמצב ברשת כוללת: מבקרי ההסכמה זקוקים לאותו הגנזה חתומה, טופולוגיה, נתונים משותפים אמינים, ופרמטרים יעילים Sumeragi.

מצב	מתאים הכי טוב.	קישור אישור	התמקדות הפעילות
מותר.	רשתות פרטיות, קונסורציוניות ומנהלות על ידי מפעילים	הממתקים באים מהטופולוגיה הנאמנת של השותפים שהוסכמה על ידי הפעלת	שמרו על כל המאשרים על אותו מקור חתום, עמיתים אמינים, מפתחות עמיתים, ופרמטרים Sumeragi.
NPOS	רשתות ציבוריות או המכוונות Nexus שבהן אישור עוקב אחרי מדיניות המינוי וההחייבות	מתוארים נבחרים על פי הפרופיל של NPoS, בדרך כלל בין ע époques, ודורשים BLS מפתחות ועוד ראיות-הכפייה	שמרו על תמונות הזיכרון, פרמטרים של תקופה, מתוקן PoPs, וזמנים של שלבים NPoS מאוזנים בכל רחבי הרשת

מצב מקובל

השתמשו במצב הרשות כאשר רשימת המאשרים היא בחירה מבצעת. זהו נקודת ההתחלה הרגילה עבור רשתות Iroha מאוחזות עצמית, מכיוון שינויים בכירות הם פעולות של ממשל מכוונות או מנהלים. הכלל הפועל החשוב הוא שכל מבדיק חייב לפעול עם אותו השקפה של הגנז, עמיתים אמינים, BLS הוכחות רכוש, ופרמטרים Sumeragi. עמית בודד עם טופולוגיה אחרת או גנז חתום יכול למנוע את הרשת להתחייב.

מצב NPOS

השתמשו במצב NPoS כאשר הפרופיל של ההפצה מצפה כי השתתפותם של מבטיחים ינהלו על ידי מועמדות ומדינת ההימור. פיתוחים ציבוריים SORA Nexus משתמשים ב- NPoS, והפרופילים שנוצרו שלהם כוללים את זהויות המבטיחים BLS, הוכחות רכוש, הגדרות התקופה, ו Sumeragi פרמטרים NPoS נדרשים בעת ההתחלה. שינויים בתקופה יכולים להחליף את המאשר הפעיל המוגדר בגובה מוגדר, כך שמפעילים צריכים לעקוב אחרי בריאות הקונצנזוס ואת מצב ההימור או המינוי המזין את רוסטר הבא.

הסכמה מרובה

מסלול ההסכמה של Iroha ממוקם באמצעות הגדרת Nexus לכיוון ומרחב נתונים. הוא לא מתחיל אינסטנציה של הסכמה נפרדת עבור כל לכיוון. Sumeragi עדיין מסיימת זרם בלוק אחד מאורר; קווי מתארים כיצד עסקאות נשלחות, מתוכנן, נחשבות והוחסנות בתוך זרם זה.

הקונפיגורציה של זמן ההפעלה יוצרת שלושה חלקים של מצב המסלול:

• lane_catalog: קווי הקונפיגרציה, כל אחד עם צבע LaneId, שם לוי, חלל נתונים, נראות, פרופיל אחסון, תוכנית הוכחה ונתונים מטאטא.
• dataspace_catalog: חלקי הנתונים המוגדרים, כל אחד מהם עם מספר DataSpaceId וערך סבולת שגיאות המשמש לצורך גודל ועדת הרחוב.
• routing_policy: זוג המסלול הנדרש/מרחב נתונים וחוקים של כיוון מסודר שיכולים להתאים חשבונות או דרכי הוראות.

כאשר עסקה נכנסת לקו, מרכז המסלול פותר אותו ל RoutingDecision { lane_id, dataspace_id }. במצב של מסלול אחד זה תמיד מסלול 0 ומרחב נתונים אוניברסלי. במצב Nexus, המעבדה המוגדרת מיישמת כללים בעלי גודל של מרחבי נתונים, מסלול הספירה, כללי חשבונות, כללי מסלול מפורשים, ובסופו של דבר מסלול הנדל"ן. קווי הנתונים המוגדרים ומרחבי נתונים המוגברים חייבים להתקיים בקייטלוגים שלהם, ומרחב הנתונים חייב להיות מחובר למרחבי הנתונים המתגבר; אחרת העסקה נדחתה לפני שהיא מופיעה בתור. .

השורה שומרת את ההחלטה זו של מסלול עם האש העסקה כך שבשלבים מאוחר יותר לא צריך להסיק אותה שוב. בניית הצעה משמשת לאחר מכן את הנתונים המטאטאניים של המסלול בשתי דרכים:

• הוא מחליף עסקאות על ידי שורה כך ששרדה אחת לא תכבוש את הבלוק רק בגלל שהעסקות שלו היו בתור ראשון.
• הוא מיישם גבולות של יחידת ביצוע העסקאות לכל שדה (TEU). העסקים שיגברו את היכולת המוגדרת של שדה משוחכים ומוציאים, למעט כי ניתן לאפשר את העסקה הראשונה עם יתר המשקל עבור שדה כדי להימנע ממעצר חיים.

במהלך שידור אמין, Sumeragi הוא מצטבר את המטען הפועל הנקרא על פי קו המסלול ומרחב הנתונים. בייטים של עומס מועיל, ו TEU. לאחר ההתחייבות, סכומים אלה הופכים לקלפים של התחייבות במרחב נתונים Sumeragi מצב. אם בלוק מכיל רישומים של הסדרות, עיבוד הבלוק יוצר גם התחייבויות של סדרות וסדרה חותמות שמקשרות את כותרת הבלוק, תעודת מחויבות, האש בהתחייבויות זמינות נתונים, הוכחת הסדר, ואת גודל המטען הפועל של המסלול.

שידור אמין (RBC)

שידור אמין (RBC) הוא מסלול התפשטות והשיקום של המטען הפועל של Sumeragi. זה עוזר לאמתנים ולצופים להשיג את גוף הבלוק שייך להצעה או לקבל תעודת מחויבות, במיוחד כאשר הודעה של BlockCreated, עדכון סינכרון בלוק, או העברה ישירה של מטען פועל נדחה או נעלמה.

RBC עובד ברמה של המטען הפועל. המציע מודיע על פגישה RBC לגובה בלוק, תצוגה וטעינה משמשת, ולאחר מכן שולח חתיכות מטען מועיל ברחבי טופולוגיית commit. עמיתים לעקוב אחר קבלת חתיכות, לאשר את המשאב הפועל שהתאושש נגד האשיץ המפורסם, ולהחלף אותות READY ו DELIVER ברגע שמסמכים מספיק צפו באותו מטען. הפגישות מוגבלות על ידי TTL, חתיכה, fanout, מחזיקים-חבילה, ומקשיבים-מחסנים גבולות כך תנועת ההתאוששות לא יכולה לצמוח ללא הגבלה.

RBC אינו החלטה קונזנטית נפרדת ואינה מחליפה את תעודת ההתחייבות. בלוק עדיין מסתיים רק כאשר השותף יש תעודת התחייבות תקופה בתוקף ואת המשאב הפועל המתאים מקומו. RBC מספקת הוכחות חיוביות של זמינות וחיזוק מטען מועיל, בעוד התקדמות ההתחייבויות מנוהלת על ידי תעודת ההתחייבות בתוספת המטען המקומי. אם התעודה מגיעה לפני המטען המשפטי, העמית יכול להחזיר את המטען המשופטי באמצעות RBC או סינכרון בלוק ולאחר מכן מחייב.

מבחינה תפעולית, RBC הוא שימושי לדיאגנזציה של קלעים במשאבים חסרי תועלת ובתאפשרות מידע:

• iroha --output-format text ops sumeragi telemetry מראה קולות זמינות משולבים, מספר הקבלנים הנוכחי והפגישות המתמשכות של RBC.
• GET /v1/sumeragi/rbc ו GET /v1/sumeragi/rbc/sessions חושפים נתונים מפורטים של הפגישה המאוחדת והפעילה על פני Torii, כולל התקדמות בחלקים, הכנות, מצב ההספקה, ותחזית המסלול או חלקי הנתונים; ראה את נקודות הסיום Torii .
• סימנים של Prometheus כגון sumeragi_rbc_store_pressure, sumeragi_rbc_backpressure_deferrals_total, ומדגלי אחזקה לכל מסלול או כל מרחב נתונים RBC עוזרים להפריד את אובדן הרשת, התאוששות בחלקים וללחץ אחסון; ראה ביצועים ומטריקות.

Kura משתמשת בקונפיגוריית המסלול המיוצרת עבור תכנון אחסון. כל מסלול מקבל שמות אחסון דטרמיסטיים כגון blocks/lane_000_core ו merge_ledger/lane_000_core_merge.log; שינויים במחזור חיי המסלול יכולים לספק, לפרוש או לסמן מחדש את החלקים הללו מבלי לשנות את סדר הבלוק הגלובלי.