اتفاق رائے

ٹرانزیکشنز 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 پیرامیٹرز کی ضرورت ہے.

موڈ	بہترین فٹ	توثیق کرنے والا سیٹ	آپریشنل توجہ
اجازت ہے	نجی، کنسورشیم اور آپریٹرز کے زیر انتظام نیٹ ورک	توثیق کرنے والے deployment کی طرف سے اتفاق کیا گیا قابل اعتماد ہم مرتبہ ٹاپولوجی سے آتے ہیں	تمام تصدیق کاروں کو ایک ہی دستخط شدہ جینیس، قابل اعتماد ہم مرتبہ، ہم مرتبہ چابیاں، اور Sumeragi پیرامیٹرز پر رکھیں
NPOS	عوامی یا Nexus پر مبنی نیٹ ورک جہاں تصدیق نامزدگی اور اسٹیک پالیسی کے بعد ہوتی ہے	ویلیڈیٹرز کو این پی او ایس پروفائل کے مطابق منتخب کیا جاتا ہے، عام طور پر مختلف دوروں میں، اور BLS چابیاں پلس ثبوت کے مالک کی ضرورت ہوتی ہے	نیٹ ورک بھر میں اسٹیک کی سنیپ شاٹس، ایپوک پیرامیٹرز، ویلیڈیٹر PoPs، اور NPoS مرحلے کے ٹائم آؤٹ کو سیدھا رکھیں

اجازت شدہ موڈ

اجازت یافتہ موڈ کا استعمال کریں جب تصدیق کنندہ کی فہرست ایک واضح آپریشنل انتخاب ہو۔ یہ خود میزبان Iroha نیٹ ورکس کے لئے معمول کا نقطہ آغاز ہے کیونکہ رکنیت میں تبدیلیاں جان بوجھ کر گورننس یا ایڈمنسٹریٹر اقدامات ہیں۔ اہم آپریٹنگ اصول یہ ہے کہ ہر توثیق کنندہ کو پیدائش ، قابل اعتماد ہم مرتبہ ، BLS ثبوت مالکیت ، اور Sumeragi پیرامیٹرز کے ایک ہی نقطہ نظر کے ساتھ چلانے کی ضرورت ہے۔ مختلف ٹاپولوجی یا دستخط شدہ پیدائش والا ایک واحد ہم مرتبہ نیٹ ورک کو پابند ہونے سے روک سکتا ہے۔

این پی او ایس موڈ

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 کی حیثیت کے ذریعے سامنے آنے والے لین اور ڈیٹا سپیس کے مصروفیت کی اسنیپ شاٹس بن جاتے ہیں۔ اگر کسی بلاک میں لین سیٹمنٹ کی رسیدیں موجود ہیں تو، بلاک پروسیسنگ بھی لین سیٹমেন্ট کے وعدوں اور ریلے لفافے پیدا کرتی ہے جو بلاک ہیڈر کو پابند کرتی ہے، مصروفیت سرٹیفکیٹ، ڈیٹا دستیابی کا عہد hash، حل ثبوت، اور لین مفید بوجھ سائز.

قابل اعتماد نشریات (RBC)

قابل اعتماد نشریات (RBC) Sumeragi کا مفید بوجھ پھیلاؤ اور بازیافت کا راستہ ہے۔ یہ تصدیق کرنے والوں اور مبصرین کو بلاک جسم حاصل کرنے میں مدد کرتا ہے جو کسی تجویز سے تعلق رکھتا ہے یا سرٹیفکیٹ کا وعدہ کرتا ہے ، خاص طور پر جب ایک BlockCreated پیغام ، بلاک مطابقت پذیری اپ ڈیٹ ، یا براہ راست مفید بوجھ کی منتقلی تاخیر یا ضائع ہوجاتی ہے۔

RBC مفید بوجھ کی سطح پر کام کرتا ہے۔ تجویز کنندہ بلاک اونچائی ، نظارہ اور مفید بوجھ ہیش کے لئے ایک RBC سیشن کا اعلان کرتا ہے ، پھر کمیٹ ٹاپولوجی میں مفید بوجھ کے ٹکڑے بھیجتا ہے۔ پیئرز ٹکڑے ٹکڑے کی رسید کو ٹریک کرتے ہیں، اشتہار کردہ ہیش کے مقابلے میں بازیافت شدہ مفید بوجھ کی توثیق کرتے ہیں، اور READY اور DELIVER سگنل کا تبادلہ کرتے ہیں ایک بار جب کافی توثیق کرنے والوں نے ایک ہی مفید بوجھ کا مشاہدہ کیا ہے. سیشنز TTL، ٹکڑا، fanout، pending-stash، اور برقرار اسٹور کی حدود سے محدود ہیں لہذا بازیابی ٹریفک بغیر کسی حد کے بڑھ نہیں سکتا.

RBC علیحدہ اتفاق رائے کا فیصلہ نہیں ہے اور یہ کمیٹ سرٹیفکیٹ کی جگہ نہیں لیتا ہے۔ ایک بلاک اب بھی صرف اس صورت میں حتمی ہوتا ہے جب ہم مرتبہ کے پاس ایک درست کمیٹ سرਟੀفکیٹ اور مقامی طور پر مماثل مفید بوجھ ہو۔ RBC لازمی دستیابی کا ثبوت اور مفید بوجھ کی بازیابی میں حصہ لیتا ہے ، جبکہ کمیٹ پیش رفت کو کمیٹ سرٹیفکیٹ کے علاوہ مقامی فائدہ مند بوجھ کی طرف سے چلایا جاتا ہے۔ اگر سرٹیفکیشن کام لوڈ سے پہلے پہنچتا ہے تو ، ہم مرتبہ RBC یا بلاک مطابقت پذیری کے ذریعہ فائدہ مند بوجھ کو بازیافت کرسکتا ہے اور پھر کمیٹ کر سکتا ہے۔

آپریشنل طور پر، RBC گمشدہ مفید بوجھ اور ڈیٹا کی دستیابی کے گلے میں تشخیص کے لئے مفید ہے:

• iroha --output-format text ops sumeragi telemetry مجموعی طور پر دستیاب ووٹوں، موجودہ جمع کرنے والوں کی تعداد اور زیر التواء RBC سیشن دکھاتا ہے۔
• GET /v1/sumeragi/rbc اور GET /v1/sumeragi/rbc/sessions تفصیلی مجموعی اور فعال سیشن کے اعداد و شمار کو ظاہر کرنا Torii, اس میں ٹکڑے ٹکڑے کی پیش رفت ، تیاری ، ترسیل کی حالت ، اور لین یا ڈیٹا اسپیس بیک لوگ شامل ہیں۔ دیکھیں Torii اختتامی مقامات.
• پرومیٹیوس سگنل جیسے sumeragi_rbc_store_pressure ، sumeragi_rbc_backpressure_deferrals_total، اور فی لین یا فی ڈیٹا اسپیس RBC بیکلاگ میگرز نیٹ ورک کے نقصان، ٹکڑے ٹکڑے کی بازیابی، اور اسٹوریج دباؤ کو الگ کرنے میں مدد کرتے ہیں؛ دیکھیں کارکردگی اور میٹرکس .

Kura اسٹوریج ترتیب کے لئے مشتق لین ترتیب کا استعمال کرتا ہے۔ ہر لین کو تعیناتی اسٹوریج نام جیسے blocks/lane_000_core اور merge_ledger/lane_000_core_merge.log ملتے ہیں۔ لین لائف سائیکل کی تبدیلیاں عالمی بلاک آرڈر کو تبدیل کیے بغیر ان حصوں کو فراہم ، ریٹائر یا دوبارہ لیبل لگاسکتی ہیں۔