သဘောတူညီချက်

Sumeragi က ဘလော့ကတ်တစ်ခုမှာ အဆိုပြုမပေးခင် ငွေကြေးပူးပေါင်းမှုတွေဟာ တန်းစီဝင်ပါတယ်။ အတည်ပြုသူတွေက အဆိုကို သီးသန့်အတည်ပြုပြီး အကောင်အထည်ဖော်ပြီး သူတို့ပြန်လည်ဖန်တီးနိုင်တဲ့ ပြည်နယ်ကူးပြောင်းမှုကိုသာ လက်မှတ်ထိုးတယ်။ လိုအပ်တဲ့ အတည်ပြုသူများအရေအတွက်က ဒီရလဒ်နဲ့ သဘောတူပြီးနောက် ဘလော့က တာဝန်ယူပြီးနောက်နဲ့ ကိုက်ညီတဲ့ အသုံးဝင်မှုဝန်ပိုးရှိသည်။

Iroha 3 ကွန်ရက်အားလုံးမှာ ဒေတာရရှိနိုင်မှုနဲ့ ယုံကြည်ရတဲ့ ထုတ်လွှင့်မှု လမ်းကြောင်းတွေကို သုံးပါတယ်။ ဒါတွေဟာ သဘောတူညီချက် လိုအပ်ချက်တွေပါ၊ ရွေးချယ်စရာ ဖြန့်ချိရေး လက္ခဏာတွေ မဟုတ်ပါဘူး။

Sumeragi

Sumeragi သည် Iroha ၏ Byzantine-fault-tolerant consensus engine ဖြစ်သည်။ ၎င်းသည်အတန်းမှ ငွေပေးချေမှုများကိုယူပြီး validator အဖော်များကတစ်ခုတည်းသောသတ်မှတ်ထားသည့်ဘလော့ကိုသဘောတူစေပြီး လုံလောက်သော validators များက အလားတူရလဒ်ကိုပြန်လည်ထုတ်လုပ်ပြီး commit certificate ကိုလက်မှတ်ထိုးပြီးမှသာ ထိုဘလော့ကို အဆုံးသတ်သည်။

အဆိုပြုချက်နှင့် အမိန့်ချမှတ်ခြင်းလမ်းကြောင်း

Sumeragi သည် ledger ကို တစ်ကြိမ်မှာ ဘလော့ကုန်းတစ်ခုစီကို ရှေ့သို့ ပြသသည်။ အမြင့်တိုင်းတွင် validator တစ်ခုသည် လက်ရှိအမြင်အတွက် အဆိုပြုသူအဖြစ် လုပ်ဆောင်သည်။ အဆိုပြုသူသည် ထိပ်တန်းမှလက်ခံနိုင်သော ငွေပေးချေမှုများကို သယ်ယူပြီး ကိုယ်စားလှယ်လောင်းဘလော့ကို တည်ဆောက်ပြီး အဆိုပြုချက်ကို တက်ကြွတဲ့ validator set သို့ ကြေညာသည်။

Sumeragi ပိုက်လိုင်းကို ခွင့်ပြုချက်နှင့် NPoS (Nominated Proof-of-Stake) တပ်ဆင်မှု နှစ်ခုစလုံးတွင် အသုံးပြုသည်။

1. validator က queued transaction တွေကို တားဆီးဖို့ အကြံပြုတယ်။
2. အတည်ပြုသူတွေဟာ အလားတူ ကမ္ဘာ့နိုင်ငံကို ဆန့်ကျင်တဲ့ ငွေပေးချေမှုတွေကို အကောင်အထည်ဖော်ရင်း အဆိုပြုချက်ကို အတည်ပြုတယ်။
3. အတည်ပြုသူတွေဟာ လက်ရှိ အမြင့်နဲ့ ကြည့်ရှုမှုအတွက် မဲတွေနဲ့ ကော်မရွ်အမှတ်တမ်းတွေကို လဲလှယ်ကြတယ်။
4. Commit quorum ကို ရောက်သွားပြီဆိုတာနဲ့ အဖော်တွေက ပိတ်ပင်ပြီး သူတို့ရဲ့ ကမ္ဘာ့အခြေအနေကို update လုပ်ကြတယ်။

အတည်ပြုသူများက ဒေသတွင်းတွင် ပြန်လည်ဖန်တီးနိုင်သော အချက်အလက်များကိုသာ လက်မှတ်ထိုးကြသည်။ မဲမပေးမီ အဆိုပြုချက်သည် မျှော်မှန်းထားသည့် ကွင်းဆက်၊ အမြင့်နှင့် ရှုထောင့်သို့ သက်ဆိုင်ကြောင်း၊ ငွေလဲလှယ်မှုလက်မှတ်များနှင့် အကန့်အသတ်များ မှန်ကန်ကြောင်း၊ လမ်းကြောင်းလမ်းညွှန်ခြင်းနှင့် အကောင်အထည်ဖော်သူအား အတည်ပြုခြင်းသည် သတ်မှတ်ချက်ဖြစ်သည်ကို အတည်ပြုသူစစ်ဆေးသည်။ ဒေသတွင်း ရလဒ်က ကွဲပြားတယ်ဆိုရင် validator က အဆိုကို မဲပေးမယ့်အစား ပယ်ချပါတယ်။

မဲပေးခြင်းသည် လက်မှတ်ရေးထိုးထားသော သဘောတူညီချက် စာတိုငယ်များဖြစ်သည်။ ၎င်းတို့က အဆိုပြုထားတဲ့ ဘလော့၊ အမြင့်၊ ရှုထောင့်နှင့် အတည်ပြုသူရဲ့ ကိုယ်ပိုင်လက္ခဏာကို ရည်ညွှန်းသည်။ ကောက်ခံသူများက ထိုမဲများကို quorum စက္တီမီတက်တစ်ခုသို့ (သို့) commit certificate တစ်ခုအဖြစ် စုစည်းကြသည်။ ဒီလိုင်စင်ဟာ တူညီတဲ့ ဘလော့အတွက် လုံလောက်တဲ့ validators တွေက တူညီတဲ့ ရလဒ်ကို တွေ့ရှိခဲ့တယ်ဆိုတာရဲ့ တည်တံ့တဲ့ အထောက်အထားပါ။

ကော်မတီ၊ စုဆောင်းသူများနှင့် လေ့လာသူများ

မဲပေးသူအတည်ပြုသူစာရင်း n သည် Byzantine fault ဘတ်ဂျက်ကိုသတ်မှတ်သည်။ အနည်းဆုံး validator လေးခုရှိသောကွန်ရက်များအတွက်ဘတ်ဂျက်သည် f = floor((n - 1) / 3) နှင့် commit quorum သည် 2f + 1 ဖြစ်သည်။ တစ်ခုမှ သုံးခုအထိ validator တွေအတွက် commit အတွက် validator အားလုံးလိုအပ်ပါတယ်၊ ဒါက ဖွံ့ဖြိုးတိုးတက်ဖို့ အသုံးဝင်ပေမဲ့ offline လုပ်စရာမရှိပါဘူး။

စုဆောင်းသူတွေဟာ အထင်ကရ အပြုသဘောဆောင်မှုပါ။ အတည်ပြုသူတိုင်းက အခြားအတည်ပြုသူအားလုံးကို မဲပေးတာအစား Sumeragi သည်အမြင့်တစ်ခုအတွက် စုဆောင်းသူတစ်ဦး (သို့) ပိုမိုရွေးချယ်နိုင်သည်။ အစုလိုက်အပြုံလိုက် မဲဆန္ဒရှင်တွေဟာ မဲတွေ စုစည်းကြတယ်၊ ကော်မတီရဲ့ တိုးတက်မှုကို ထုတ်ပြန်ကြတယ်၊ ပြီးတော့ နှစ်ထပ် မဲပေးပို့မှု ပမာဏကို လျှော့ချကြတယ် ထိရောက်တဲ့ ကောက်ခံမှု setting တွေကို GET /v1/sumeragi/collectors; ကော်မတီ CLI ဒါက ops sumeragi telemetry snapshot က လက်ရှိကို ဖော်ပြတယ်။ စုဆောင်းသူ ရေတွက်ချက်ပါ။

Observer peers များသည် committed blocks များကို synchronize လုပ်နိုင်သော်လည်း မဲပေးခြင်း၊ မဲကောက်ခြင်း သို့မဟုတ် commit quorum သို့ မရေတွက်ခြင်းမရှိပါ။ မဲချမှတ်သူများ၏အရေအတွက်မတိုးစေဘဲ ဒေသတွင်း မေးမြန်းမှု အရည်အချင်း၊ ညွှန်ပြမှု၊ စောင့်ကြည့်ခြင်း (သို့) တိုင်းဒေသကြီး block replication ကိုလိုအပ်သည့်နေရာတွင် လေ့လာသူများကို အသုံးပြုသည်။

အပြောင်းအလဲများနှင့် ပြန်လည်ထူထောင်ခြင်းများကို ကြည့်ရှုရန်

View သည် Sumeragi ၏ အတိုင်းအတာတစ်ခုကို သတ်မှတ်သော အဆိုပြုသူနှင့် အချိန်ဆွဲမှု အစီအစဉ်ဖြင့် အဆုံးသတ်ရန်ကြိုးပမ်းခြင်းဖြစ်သည်။ အဆိုပြုချက်၊ အသုံးဝင်ချိန်၊ မဲပေးခြင်း သို့မဟုတ် တိုးတက်မှု စတိုင်များရှိပါက နှလုံးခုန်နှုန်းသတ်မှတ်စက်သည် အမြင့်ကို နောက်တစ်ကြိမ်သို့ ရွှေ့နိုင်သည်။ ရှုထောင့်ပြောင်းလဲမှုက ကတိပြုထားတဲ့ ဘလော့ကို ပြန်မရေးသားပါ။ ဒါက validators တွေက ကတိမပြုထားတဲ့ အမြင့်ကို အဆုံးသတ်ဖို့ကြိုးစားပုံကို ပြောင်းလဲစေတယ်၊ သိသိသာတဲ့ အမြင့်ဆုံး quorum ကို ဆောင်ရွက်ခြင်း (သို့) သက်သေခံတာဝန်ပေးခြင်းပါ။ ဒီတော့ တူညီသူတွေဟာ ပဋိပက္ခဖြစ်နေတဲ့ ဘလော့တွေကို နောက်ဆုံး မပြီးစီးဘူး။

Payload Recovery သည်အဆုံးသတ်ချက်နှင့် သီးခြားဖြစ်သည်။ peer သည် block အပြည့်အဝ payload ရှိမလာမီ quorum သို့မဟုတ် commit certificate ကိုရယူနိုင်သည်။ ထိုကိစ္စတွင် peer သည် trusted broadcast (RBC) သို့မဟုတ် block sync ကိုအသုံးပြု၍ payload ကိုပြန်လည်ရရှိစေပြီး ကြော်ငြာထားသော hash များအားစစ်ဆေးသည်။ ဒီနောက်ပဲ ဘလော့က ကမ္ဘာ့နိုင်ငံနဲ့ Kura ကို သက်ရောက်ပါတယ်။

သဘောတူညီမှုပုံစံများ

ရွေးချယ်ထားသော mode သည် validator set ကိုဘယ်လိုဖွဲ့စည်းပြီးလုပ်ဆောင်သည်ကိုထိန်းချုပ်သည်။ consensus_mode မှတစ်ဆင့်ဖြစ်စဉ်တွင်ကြေညာထားသည်နှင့် sumeragi.consensus_mode မှတစ်ဆင့် peer configuration တွင်ကြေညာသည်။ ဒါကို ကွန်ရက်တစ်ခုလုံးအခြေအနေအဖြစ် ဆက်ဆံပါ။ validators တွေဟာ လက်မှတ်ထိုးထားတဲ့ မျိုးဆက်၊ topology, ယုံကြည်မှုရှိတဲ့ အဖော်ဒေတာတွေနဲ့ ထိရောက်တဲ့ Sumeragi ပမာဏတွေလိုတယ်။

Mode ကို	အကောင်းဆုံးအဆင်ပြေတယ်။	Validator ကို Set	လုပ်ငန်းဆိုင်ရာ အာရုံစိုက်မှု
ခွင့်ပြုချက်	ပုဂ္ဂလိက၊ ကွန်ဆာစီယမ်များနှင့် လုပ်ငန်းရှင်များမှ စီမံခန့်ခွဲသော ကွန်ရက်များ	Validators တွေဟာ deployment က သဘောတူထားတဲ့ trusted peer topology ထဲက လာတာပါ။	validator တွေအားလုံးကို လက်မှတ်ထိုးထားတဲ့ genesis, trusted peers, peer keys နဲ့ Sumeragi parameters ကိုပဲ ထားပါ။
NPOS	အများပြည်သူ သို့မဟုတ် Nexus ဦးစားပေးကွန်ရက်များတွင် မှတ်ပုံတင်ခြင်းနှင့် ပါဝင်မှု မူဝါဒကို လိုက်နာသည့် အတည်ပြုချက်များ	Validator တွေကို NPoS profile ကနေ ရွေးချယ်ထားပြီး အများအားဖြင့် ခေတ်အလိုက် ဖြစ်ပြီး BLS key နဲ့ Proof-of-Possession ကို လိုအပ်ပါတယ်။	NPoS phase timeouts တွေကို ကွန်ရက်တစ်ခုလုံးမှာ အချိန်ကာလသတ်မှတ်ချက်တွေ၊ validator PoPs နဲ့ အချိန်သတ်မှတ်ချက်တွေကို ချိတ်ဆက်ထားပါ။

ခွင့်ပြုထားသော mode

validator roster က တိကျတဲ့ လုပ်ဆောင်မှု ရွေးချယ်မှုတစ်ခုဖြစ်တဲ့အခါ ခွင့်ပြုထားသော mode ကိုအသုံးပြုပါ။ ဒါက ကိုယ်တိုင် တည်းခိုထားတဲ့ Iroha ကွန်ရက်တွေအတွက် ပုံမှန်စတင်ချက်ပါ၊ အကြောင်းက အဖွဲ့ဝင် ပြောင်းလဲမှုဟာ ကြံဆထားတဲ့ အုပ်ချုပ်မှု (သို့) စီမံအုပ်ချုပ်ရေး လုပ်ဆောင်ချက်တွေပါ။ အရေးပါသော လုပ်ငန်းစည်းကမ်းသည် validator တစ်ခုစီသည် genesis, trusted peers, BLS Proof-of-Possession နှင့် Sumeragi သတ်မှတ်ချက်များအပေါ်တူညီသည့်အမြင်နှင့် run လုပ်ရမည်ဖြစ်ပါသည်။ မတူညီသော topology သို့မဟုတ် လက်မှတ်ထိုး genesis ရှိသော peer တစ်ခုတည်းသည်ကွန်ရက်ကို commit မလုပ်စေနိုင်သည်။

NPOS mode ကို

NPoS mode ကိုအသုံးပြုပါ deployment profile က validator ပါ၀င်မှုကို nomination နဲ့ stake state တွေက တွန်းအားပေးမယ်လို့ မျှော်လင့်တဲ့အခါမှာ SORA Nexus NPoS ကိုသုံးပြီး သူတို့ဖန်တီးတဲ့ Profiles တွေမှာ BLS အတည်ပြုသူရဲ့ ကိုယ်ပိုင်လက္ခဏာတွေ၊ ပိုင်ဆိုင်မှု အထောက်အထားတွေ၊ ခေတ်အလိုက် သတ်မှတ်ချက်တွေ၊ Sumeragi Epoch ပြောင်းလဲမှုတွေက သတ်မှတ်ထားတဲ့ အမြင့်တွေမှာ သတ်မှတ်ထားတဲ့ Active Validator ကို အစားထိုးနိုင်ပါတယ်။ ဒီတော့ လုပ်ငန်းရှင်တွေဟာ သဘောတူညီချက်ရဲ့ ကျန်းမာရေးနဲ့ နောက်စာရင်းကို ကျွေးမွေးတဲ့ အခန်းကဏ္ဍ (သို့) အဆိုပြုမှု အခြေအနေ နှစ်ခုစလုံးကို စောင့်ကြည့်ဖို့လိုပါတယ်။

အများပြည်သူ သဘောတူညီချက်

Iroha ရဲ့ multi-lane consensus path ကို Nexus lane နဲ့ data space configuration တွေကနေ အကောင်အထည်ဖော်ပါတယ်။ ဒါက lane တစ်ခုစီအတွက် သီးခြား consensus instance ကို မစတင်ပါဘူး။ Sumeragi သည် ညွှန်ကြားထားသော ဘလော့ခ်စီးကြောင်းတစ်ခုကို အဆုံးသတ်နေဆဲဖြစ်သည်; လိုင်းများက ထိုစီးကြောင်းအတွင်းမှာ ငွေပေးချေမှုများကို ဘယ်လို လမ်းညွှန်ခြင်း၊ အစီအစဉ်ချခြင်း၊ မှတ်ပုံတင်ခြင်းနှင့် သိုလှောင်ခြင်းတို့ကို ဖော်ပြသည်။

Runtime configuration က lane state ကို သုံးခု တည်ဆောက်တယ်။

• lane_catalog: ပုံသွင်းထားသောလမ်းကြောင်းများ၊ တစ်ခုစီမှာ နံပါတ် LaneId၊ အမည်မဖော်လိုသူ၊ ဒေတာနေရာ၊ မြင်နိုင်မှု၊ သိုလှောင်ရေးပရိုဖိုင်း၊ သက်သေပြချက် အစီအစဉ်နှင့် မီတာဒေတာရှိသည်။
• dataspace_catalog: ရေလွှမ်းတင်ကော်မတီအရွယ်အစားအတွက် အသုံးပြုသော ကိန်းဂဏန်း DataSpaceId နှင့် အမှားခံနိုင်ရည်တန်ဖိုးရှိ configured data spaces များ။
• routing_policy: အလိုအလျောက်လမ်းကြောင်း/ဒေတာနေရာ နှစ်စုံနှင့် အကောင့်များ (သို့) ညွှန်ကြားချက်လမ်းကြောင်းများနှင့် ကိုက်ညီနိုင်သော လမ်းညွှန်စည်းမျဉ်းများကို စီစဉ်ထားသည်။

Transaction တစ်ခုဟာ queue ထဲကို ဝင်လာတဲ့အခါ lane router က RoutingDecision { lane_id, dataspace_id } သို့ ဖြေရှင်းပေးပါတယ်။ single-lane mode မှာတော့ အမြဲတမ်း lane 0 နဲ့ universal data space ဖြစ်တယ်။ Nexus mode မှာ configured router က dataspace scope စည်းမျဉ်းတွေ၊ settlement routing၊ account စည်းမျဉ်း၊ explicit routing စည်းမျဉ်းတွေနဲ့ နောက်ဆုံးတော့ default route ကို သုံးပါတယ်။ ပြေလည်သောလမ်းကြောင်းနှင့် ဒေတာနေရာသည် ၎င်းတို့၏စာရင်းများတွင် တည်ရှိရမည်ဖြစ်ပြီး လမ်းကြောင်းသည် ပြေလည်သည့်ဒေတာနေရာနှင့် ချိတ်ဆက်ထားရမည်။ မဟုတ်လျှင် ငွေပေးချေမှုသည် အတန်းမဝင်ခင် ပယ်ဖျက်ခံရမည်။

နောက်ပိုင်းအဆင့်များတွင် ထပ်မံဆုံးဖြတ်ရန်မလိုအောင် စာတန်းသည် ဤလမ်းညွှန် ဆုံးဖြတ်ချက်ကို ငွေပေးချေမှု ဟက်ရှ်နှင့်အတူ ထိန်းသိမ်းထားသည်။ အဆိုပြုချက် တည်ဆောက်မှုနောက်မှာ လမ်းကြောင်း metadata ကိုနည်းလမ်းနှစ်မျိုးဖြင့်အသုံးပြုသည် -

• ၎င်းသည် लेनအလိုက် ငွေလဲလှယ်မှုများကို ချိတ်ဆက်ထားသည့်ကြောင့် တစ်ခုတည်းသော လိုင်းက ဘလော့ကို လွှမ်းမိုးခြင်းမရှိပေ။
• TEU သတ်မှတ်ထားသော လိုင်းအလိုက် ငွေပေးချေမှု အကောင်အထည်ဖော်မှု ယူနစ်များ (per-lane transaction execution unit [PH000000) ] ကန့်သတ်ချက်များကို ချမှတ်သည်။ လိုင်းတစ်ခုအတွက် ပထမဦးဆုံး အလေးချိန်လွန်တဲ့ ငွေပေးချေးမှုကို သက်တမ်းပိတ်ဆို့ခြင်းကို ရှောင်ရှားရန် ခွင့်ပြုနိုင်ခြင်းမှလွဲ၍ လိုင်းတစ်ခု၏ ညှိနှိုင်းထားသည့် အရည်အသွေးထက် ပိုမိုမြင့်မားသော ငွေလဲလှယ်မှုများကို ရွှေ့ဆိုင်းပြီး ပြန်လည်သိမ်းဆည်းရမိသည်။

ယုံကြည်စိတ်ချရတဲ့ ထုတ်လွှင့်မှုအတွင်းမှာ Sumeragi က အဆိုပြုထားတဲ့ အသုံးဝင် ဝန်ဆောင်မှုကို လမ်းကြောင်းနှင့် ဒေတာနေရာအလိုက် စုစည်းပေးပါတယ်။ မှတ်တမ်းတင်ထားသော စုစုပေါင်းများတွင် ငွေလဲလှယ်မှုအရေအတွက်၊ ထုတ်လွှင့်ခြင်း အပိုင်းများ၊ အသုံးဝင်ဝန်ဆောင်မှု ဘိုက်များနှင့် TEU တို့ပါဝင်သည်။ ချုပ်ဆိုပြီးနောက်, ဒီစုစုပေါင်းတွေဟာ Sumeragi အခြေအနေမှတစ်ဆင့် ဖော်ပြထားသည့်လမ်းကြောင်းနဲ့ ဒေတာနေရာဆိုင်ရာ တာဝန်ယူမှု snapshots များဖြစ်လာသည်။ ဘလော့ကွင်းတစ်ခုမှာ လိုင်နိုး settlement လက်မှတ်တွေ ပါရှိတယ်ဆိုရင် Block Processing ကလည်း လိုင်နို settlement commitments နဲ့ relay envelopes တွေကို ဖန်တီးပေးပြီး block header, commit certificate, data availability commitment hash, settlement proof and lane payload size တွေကို ချိတ်ဆက်ပေးပါတယ်။

ယုံကြည်မှုရှိသော ထုတ်လွှင့်ခြင်း (RBC)

စိတ်ချရတဲ့ ထုတ်လွှင့်မှု (RBC) သည် Sumeragi ၏ အသုံးဝင် ဝန်ဆောင်မှု ဖြန့်ဝေခြင်းနှင့် ပြန်လည်ထူထောင်ရေးလမ်းကြောင်းဖြစ်သည်။ ၎င်းသည် အဆိုပြုချက်တစ်ခုသို့ သက်ဆိုင်သည့် ဘလော့ကော်မတီကိုရရှိရန် သို့မဟုတ် အမိန့်ချမှတ်စာရွက်စာတမ်းတစ်စောင်၊ အထူးသဖြင့် BlockCreated သတင်းအချက်အလက်၊ ဘလော့ကုန်း sync update သို့မဟုတ် တိုက်ရိုက် အသုံးဝင်ဝန်ဆောင်မှု လွှဲပြောင်းမှုကို နှောင့်နှေးခြင်း၊ ပျောက်ဆုံးခြင်းတို့တွင် ကူညီပေးသည်။

RBC သည် payload အဆင့်တွင် အလုပ်လုပ်သည်။ အဆိုပြုသူသည် block height, view နှင့် payload hash အတွက် RBC session ကိုကြေညာပြီး commit topology တစ်လျှောက်မှာ payload chunks များကိုပို့သည်။ Peers တွေက အပိုင်းအစ လက်ခံရရှိမှုကို ခြေရာခံပြီး ကြော်ငြာထားတဲ့ hash နဲ့ ပြန်လည်ရှာဖွေတဲ့ အသုံးဝင်လစာကို validate လုပ်ကာ READY နှင့် DELIVER အချက်ပြမှုတွေကို validators များစွာက တူညီတဲ့ အသုံးဝင် လစာကို သတိထားမိတဲ့အခါမှာ လဲလှယ်ကြတယ်။ အစည်းအဝေးများကို TTL၊ chunk, fanout, pending-stash နှင့် persistent-store ကန့်သတ်ချက်များဖြင့် ကန့်သတ်ထားသည်ဖြစ်၍ ပြန်လည်ထူထောင်ရေးသယ်ယူပို့ဆောင်မှုသည် အကန့်အသတ်မရှိ ကြီးထွားနိုင်ခြင်းမရှိပါ။

RBC သည် သီးခြားသဘောတူညီချက်ချမှတ်မှုမဟုတ်ဘဲ commit certification ကိုအစားထိုးခြင်းမရှိပါ။ အချိုးအစားတစ်ခုသည် လက်ရှိတွင် သက်ဝင်သော commit certification နှင့် ယှဉ်တွဲသည့်အကျိုးစီးပွားကို ဒေသတွင်းရှိလျှင်သာ ပြီးဆုံးစေသည်။ RBC သည်လိုအပ်သောရရှိနိုင်မှု အထောက်အထားများနှင့် အသုံးဝင်ဝန်ဆောင်မှုကိုပြန်လည်ထူထောင်ပေးပြီး commit တိုးတက်မှုကို commit certification plus local payload မှသက်သာစေသည်။ အကယ်၍ certificate သည် payload မတိုင်မီရောက်ရှိပါက peer က RBC သို့မဟုတ် block sync မှတစ်ဆင့် payload ကိုပြန်လည်ထူထပ်နိုင်ပြီးနောက် commit လုပ်နိုင်သည်။

လုပ်ငန်းစဉ်အရ 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 backlog gauges တွေက net loss, chunk recovery နဲ့ storage pressure တွေကို ခွဲခြားဖို့ ကူညီပေးတယ် စွမ်းဆောင်ရည်နှင့် မက်ထရစ်များ.

Kura သည် သိုလှောင်ခြင်းအစီအစဉ်အတွက် ရယူထားသောလမ်းကြောင်းစည်းကမ်းကိုအသုံးပြုသည်။လမ်းကြောင်းတစ်ခုစီသည် deterministic သိုလှောင်မှုနာမည်များကိုရသည် blocks/lane_000_core နှင့် merge_ledger/lane_000_core_merge.log; လမ်းကြောင်းသက်တမ်းပတ်လည်ပြောင်းလဲမှုများသည်ကမ္ဘာလုံးဆိုင်ရာဘလော့ခ်အစီအစဉ်ကိုမပြောင်းဘဲ ထိုအပိုင်းများအားပေးသွင်းနိုင်ခြင်း၊ အငြိမ်းစားပေးခြင်း သို့မဟုတ် အမှတ်တံဆိပ်သစ်တပ်ဆင်ခြင်း။