ایک دنیاایک معیشتایک لیجر

وائٹ پیپر پڑھیں
دریافت کے لیے اسکرول کریں
91%ان ⁨93⁩ مرکزی بینکوں میں سے جن کا ⁨BIS⁩ نے ⁨2024⁩ میں سروے کیا، خوردہ، تھوک یا دونوں استعمالات کے لیے مرکزی بینک کی ڈیجیٹل کرنسی (⁨CBDC⁩) پر کام کر رہے تھے۔ ⁨BIS Papers No 159 · 2024⁩ کا ⁨CBDC⁩ سروے
اب کیوں

ڈیجیٹل زر خودمختار ہو رہا ہے۔ ادائیگیاں الگ تھلگ نہیں رہ سکتیں۔

ہر دائرۂ اختیار کو اپنے زر پر کنٹرول چاہیے۔ ان نظاموں کے درمیان ادائیگیوں کے لیے مشترک پروٹوکول چاہیے جو ان کے مختلف قواعد، نجی ڈیٹا اور تصدیقی نیٹ ورکس کا احترام کرے۔ ⁨SORA Nexus⁩ ان دونوں ضرورتوں کو یکجا کرتا ہے۔

خودمختاری، بغیر الگ تھلگ ہوئے۔

ہر ادارہ ڈیٹا اسپیس میں کام کر سکتا ہے: اپنی پالیسی اور رسائی قواعد رکھنے والا ماحول۔ ایک مشترک، قابلِ پروگرام تصفیہ تہہ ان اسپیسز کو جوڑتی ہے تاکہ مجاز لین دین ایک منطقی لیجر پر منتقل ہو سکے۔

⁨01⁩ · باہمی مطابقت

خودمختار نظام جوڑیں

ایک مثالی تبادلہ دیکھیں: ایک دائرۂ اختیار کا ادارہ دوسرے کو اثاثے کی ادائیگی کرتا ہے۔ دونوں اپنے قواعد اور ڈیٹا رکھتے ہیں۔ مشترک پروٹوکول ان کی ڈیٹا اسپیسز میں ادائیگی اور فراہمی کو ہم آہنگ کرتا ہے۔

سوالآزاد ادارے ایک تبادلہ کیسے طے کرتے ہیں؟

ادائیگی اور اثاثے کی فراہمی ساتھ طے ہو سکتی ہیں، جبکہ ہر ادارہ اپنی پالیسی کی حد برقرار رکھتا ہے۔

01
ادائیگیاں

⁨ISO 20022⁩ گیٹ وے

ان ادائیگی پیغامات سے آغاز کریں جو ادارے پہلے ہی استعمال کرتے ہیں۔

ادائیگی ⁨Torii⁩ کے ذریعے ⁨Nexus⁩ میں داخل ہوتی ہے، جو آنے والی درخواستوں کے لیے ⁨Iroha⁩ کا انٹرفیس ہے۔ گیٹ وے معاون ⁨ISO 20022⁩ پیغامات، بشمول ⁨pacs.008⁩ اور ⁨pacs.009⁩، کی جانچ کرتا اور قابلِ اطلاق پالیسی کے تحت انہیں لیجر ہدایات میں تبدیل کرتا ہے۔

پروٹوکول کے اندر

⁨pacs.002⁩ حیثیت نتیجہ بھیجنے والے کو واپس دیتی ہے۔ یوں ادارہ جاتی نظاموں کو مانوس ادائیگی پیغام سے مشترک لیجر پر مجاز عمل تک ایک متعین راستہ ملتا ہے۔

مانوس پیغامات

ادارہ جاتی ادائیگی کا ارادہ ⁨pacs.008⁩ اور ⁨pacs.009⁩ ساختوں کے ذریعے آتا ہے۔

متعین عمل

جانچے ہوئے پیغامات مقامی پالیسی کے تحت واضح ⁨Iroha⁩ ہدایات بنتے ہیں۔

معیاری جواب

⁨pacs.002⁩ حیثیت درج کرتی ہے کہ درخواست قبول، مسترد یا تصفیہ ہوئی۔

پروٹوکول کا نقشہ

⁨ISO 20022⁩ گیٹ وے

⁨pacs.008⁩ اور ⁨pacs.009⁩ پیغامات جانچے اور نافذ کیے جاتے ہیں، اور متعین ⁨pacs.002⁩ نتیجے سے جواب دیا جاتا ہے۔

پیغام کی آمد سے متعین حیثیت تک ⁨ISO 20022⁩ بریج⁨pacs.008⁩ اور ⁨pacs.009⁩ جیسے ⁨ISO 20022⁩ ادائیگی پیغامات ⁨Torii⁩ سے داخل ہوتے ہیں؛ بریج شناخت اور حوالہ ڈیٹا جانچتا، لیجر کا ایک عمل بناتا اور ⁨ISO⁩ اینڈ پوائنٹ کے ذریعے متعین حیثیت ظاہر کرتا ہے۔ایک مشترک مالی زبان⁨ISO⁩پیغام⁨Torii⁩جانچیںلیجر عمل⁨ISO⁩ حیثیت موصول

⁨ISO 20022⁩ ادارہ جاتی ادائیگی پیغامات کو بلاک چین پر مبنی قابلِ پروگرام تصفیے اور ڈیجیٹل معیشت میں پہنچاتا ہے۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. ⁨pacs.008⁩ یا ⁨pacs.009⁩ پیغام ⁨Torii⁩ کے ذریعے داخل ہوتا ہے۔
  2. اسکیما اور پالیسی کی جانچ مطلوبہ عمل طے کرتی ہے۔
  3. ⁨Iroha⁩ متعلقہ لیجر ہدایت چلاتا ہے۔
  4. متعین ⁨pacs.002⁩ حیثیت بھیجنے والے کو واپس ملتی ہے۔
02
خودمختاری

خودمختار ڈیٹا اسپیسز

ادارے جوڑیں، جبکہ ہر ادارہ اپنے قواعد اور نجی ڈیٹا پر اختیار رکھے۔

درخواست پہنچنے پر اسے ذمہ دار ادارے کا احترام کرنا ہوگا۔ خودمختار ڈیٹا اسپیس یہ حد متعین کرتی ہے: اس کی حاکمیت، تصدیقی کمیٹی، مشاہدے کے قواعد اور لین دین قبول کرنے کی شرائط۔

پروٹوکول کے اندر

ہر اسپیس اپنی پالیسی نافذ کرتی ہے۔ اسپیسز کے درمیان مجاز تبادلے کے لیے ⁨Nexus⁩ ایک منطقی لیجر پر مطلوبہ قدر، التزامات اور ثبوت میں ہم آہنگی لاتا ہے، جبکہ نجی لین دین کا ڈیٹا اپنی حد میں رہتا ہے۔

مقامی پالیسی

ہر ادارہ اختیار، مشاہدے اور لین دین کے داخلے کے واضح قواعد برقرار رکھتا ہے۔

متعین تصدیقی کمیٹیاں

محدود کام غیر متعلقہ چین بنے بغیر اپنی کمیٹی استعمال کر سکتا ہے۔

مجاز باہمی مطابقت

صرف منظور شدہ قدر اور شواہد اسپیس کی حد پار کرتے ہیں؛ پوری نجی حالت نہیں۔

پروٹوکول کا نقشہ

خودمختار ڈیٹا اسپیسز

عوامی اور محدود اسپیسز مقامی پالیسی رکھتی ہیں، جبکہ واضح طور پر مجاز بہاؤ حد پار کرتا ہے۔

خودمختار ڈیٹا اسپیسز اور مشترک لیجر کی حدودخودمختار اور کھلی اسپیس مختلف اندرونی قواعد برقرار رکھتی ہیں۔ خودمختار فریق نجی ڈیٹا مقامی رکھتے ہوئے التزامات اور ثبوت بانٹتا ہے۔ کھلا فریق ڈیٹا اور ثبوت برآمد کر سکتا ہے۔ دونوں ایک مشترک لیجر میں التزامات ثبت کرتے ہیں جو اسپیس شناخت، روٹس، منشور اور کورم سرٹیفکیٹ درج کرتا ہے۔الگ قواعد۔ مشترک تاریخ۔خودمختارکھلامقامی ڈیٹا اندر رہتا ہےپالیسی کے تحت کھلاالتزامات+ ثبوتڈیٹا + ثبوتایک مشترک لیجر

کھلے اور خودمختار ماحول ایک انجن بانٹتے ہیں، جبکہ الگ حدود رکھتے ہیں۔

لین دین کا سفر دیکھیں⁨3⁩ مراحل
  1. عوامی اور محدود اسپیسز اپنی مقامی پالیسی نافذ کرتی ہیں۔
  2. واضح طور پر مجاز درخواست حد تک پہنچتی ہے۔
  3. صرف منظور شدہ شواہد اور قدر اسپیس کی حد پار کرتے ہیں۔
03
جوہری ہم آہنگی

ڈیٹا اسپیسز کے پار جوہری لین دین

ادائیگی اور اثاثے کی فراہمی میں ہم آہنگی لائیں تاکہ مختلف خودمختار نظاموں میں بھی دونوں ساتھ طے ہوں۔

جوہری لین دین (⁨AMX⁩) ہر متعلقہ ڈیٹا اسپیس اور اس حالت کو نام دیتی ہے جسے پڑھنا یا بدلنا ہو۔ ہر اسپیس مشترک اسنیپ شاٹ سے اپنا حصہ تیار کرتی ہے۔ ⁨Nexus⁩ تبدیلی صرف تب منظور کرتا ہے جب ہر مطلوبہ نتیجہ درست ہو۔

پروٹوکول کے اندر

کوئی اسپیس تیاری نہ کر سکے یا اس کے شواہد تصدیق میں ناکام ہوں تو پورا تبادلہ جزوی اثرات کے بغیر منسوخ ہوتا ہے۔ نجی اسپیسز اپنا لین دین ڈیٹا مقامی رکھتے ہوئے التزامات اور ثبوت دے سکتی ہیں۔

سب یا کچھ نہیں

ہر شریک اسپیس ساتھ منظور کرتی ہے، یا لین دین کوئی جزوی تصفیہ نہیں چھوڑتی۔

واضح دائرہ

منظوری سے پہلے شریک ڈیٹا اسپیسز اور مقصود پڑھنے اور لکھنے کے اعمال کا جائزہ لیا جا سکتا ہے۔

حدود میں محفوظ رازداری

محدود اسپیس خام نجی ڈیٹا کے بجائے حالت کے التزامات اور درستگی کے شواہد برآمد کر سکتی ہے۔

باہمی مطابقت

ڈیٹا اسپیسز کے پار جوہری لین دین

دو شریک کمیٹیاں اختیار کے ایک اسنیپ شاٹ کے مطابق تیاری کرتی، ⁨2⁩ میں سے ⁨2⁩ منظوریوں کے لاک کے تحت ادائیگی اور فراہمی بدلتی، پھر ساتھ منظور یا واپس پلٹتی ہیں۔

ڈیٹا اسپیسز کے پار جوہری لین دیندو شریک کمیٹیاں اختیار کے ایک اسنیپ شاٹ کے مطابق تیاری کرتی، ⁨2⁩ میں سے ⁨2⁩ منظوریوں کے لاک کے تحت ادائیگی اور فراہمی بدلتی، پھر ساتھ منظور یا واپس پلٹتی ہیں۔

دو مقامی تبدیلیاں ایک مشترک نتیجہ بنتی ہیں۔

لین دین کا سفر دیکھیں⁨5⁩ مراحل
  1. دونوں ڈیٹا اسپیسز، پڑھنے اور لکھنے کے مجموعے اور اختیار کے سیاق کا ایک اسنیپ شاٹ واضح کریں۔
  2. ⁨A₀ → A₁⁩ اور ⁨B₀ → B₁⁩ تیار کریں؛ دونوں کمیٹیاں ⁨Prepare⁩ کورم سرٹیفکیٹس (⁨QCs⁩) جاری کرتی ہیں۔
  3. دونوں ثبوت ⁨Nexus⁩ کو بھیجیں اور دونوں اسپیسز تیار ہونے تک انتظار کریں۔
  4. ایک جوہری لاک کے تحت ادائیگی اور فراہمی مخالف سمتوں میں منتقل کریں۔
  5. معیاری ⁨AMX⁩ رسید کے ساتھ دونوں حصے منظور کریں، یا جزوی حالت کے بغیر دونوں روٹس بحال کریں۔
04
تصفیہ

متعین تصفیہ روٹر

تبادلے کی مقامی واجب الادا رقوم کو ایسے تصفیہ نتائج میں بدلیں جنہیں آپریٹرز دوبارہ حساب اور مطابقت کر سکیں۔

تبادلے کی مطابقت کے لیے تصفیہ روٹر عین مقداری تبدیلی، مقررہ مارجن اور احتیاطی تخفیف، اور ہر اجرا لین کے ریزرو بفر قواعد سے واجب الادا رقم نکالتا ہے۔ یکساں ان پٹس اور قواعد ہمیشہ یکساں نتیجہ دیتے ہیں۔

پروٹوکول کے اندر

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

معیاری تبدیلی

عین مقداریں، اوریکل ان پٹس، مارجن اور گول کرنے کے قواعد قابلِ تکرار نتیجہ بناتے ہیں۔

ریزرو کے حفاظتی اصول

مقررہ بفر حالتیں تنبیہ دے، رفتار گھٹا، صرف ⁨XOR⁩ تصفیہ لازم کر یا تصفیہ روک سکتی ہیں۔

لین کے مطابق شواہد

تصفیے کے التزامات اور عملی ٹیلی میٹری ایک ہی لین اور ڈیٹا اسپیس کی شناخت رکھتے ہیں۔

ادائیگیاں

متعین تصفیہ روٹر

معیاری رقوم، پالیسی کے مطابق روٹنگ، لین التزام اور مطابقت کی رسید ایک قابلِ تکرار راستہ اختیار کرتے ہیں۔

متعین تصفیہ روٹرمعیاری رقوم، پالیسی کے مطابق روٹنگ، لین التزام اور مطابقت کی رسید ایک قابلِ تکرار راستہ اختیار کرتے ہیں۔

دوبارہ حساب کی جا سکنے والی واجب الادا رقم، واضح ریزرو حالت اور مطابقت کے لیے رسید۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. رقم، اوریکل ان پٹ، مارجن اور لیکویڈیٹی پالیسی جانچیں۔
  2. معیاری ⁨XOR⁩ واجب الادا رقم اور نافذ تخفیف کا حساب کریں۔
  3. لین تصفیہ بفر اور اس کی پالیسی حالت جانچیں۔
  4. لین کا التزام بند کریں اور مطابقت کی رسید جاری کریں۔
⁨02⁩ · اجرا

ہر نتیجہ قابلِ تصدیق بنائیں

اب اس تبادلے کا اجرا دیکھیں۔ نیٹ ورک کو اسے مستقل انداز میں پروسیس، استعمال ہونے والی گنجائش کو منظم اور حتمی نتیجے پر اتفاق کرنا ہوگا۔ وصول کنندہ ادارے کو ایسے شواہد درکار ہیں جن کی وہ آزادانہ تصدیق کر سکے۔

سوالدونوں فریق ایک حتمی نتیجے پر کیسے اعتماد کریں؟

دونوں فریق منظور شدہ نتیجے کی مطابقت کر سکتے ہیں، اور دوسرا نظام معتبر نقطۂ آغاز سے اس کی حتمیت جانچ سکتا ہے۔

05
انجن

⁨Hyperledger Iroha 3⁩ کور

ہر شریک تصدیق کنندہ کو لین دین چلانے کے یکساں قواعد دیں۔

اوپر بیان کردہ تبادلوں کو ایسا انجن چاہیے جسے شرکا جانچ سکیں۔ ⁨Hyperledger Iroha 3⁩ یہ دیتا ہے: ⁨Torii⁩ درخواستوں کا داخلی نقطہ ہے، ⁨Kotodama⁩ پروگرام کمپائل کرتا ہے اور ⁨Iroha⁩ ورچوئل مشین (⁨IVM⁩) ان کی منطق متعین انداز سے چلاتی ہے۔

پروٹوکول کے اندر

اجرا لینز متوازی کام کرتی ہیں۔ اتفاقِ رائے کا نظام ⁨Sumeragi⁩ نتیجے پر اتفاق کرتا ہے؛ ⁨Kura⁩ منظور شدہ بلاک محفوظ کرتا ہے۔ لینز شامل یا ریٹائر ہونے پر بھی دونوں ایک لیجر کی تاریخ برقرار رکھتے ہیں۔

ٹورنگ مکمل رن ٹائم

⁨Kotodama⁩ پروگراموں کو تصدیق کنندگان کے لیے محفوظ ⁨IVM⁩ بائٹ کوڈ میں کمپائل کرتا ہے، تاکہ ہر پیئر یکساں محدود منطق چلائے۔

رن ٹائم میں لین کا دورِ حیات

لین شامل یا ریٹائر ہونے پر روٹنگ، منشور اور ٹیلی میٹری ڈھلتے ہیں؛ نئی چین لازم نہیں ہوتی۔

ایک معیاری لیجر

متوازی لینز رفتار بڑھاتی ہیں، مگر ⁨Sumeragi⁩ حتمیت اور ⁨Kura⁩ کا مستقل ذخیرہ ایک مستند تاریخ میں یکجا رہتے ہیں۔

پروٹوکول کا نقشہ

⁨Iroha 3⁩ کور

⁨Torii⁩ داخلہ، ⁨Kotodama⁩ کمپائلیشن، متعین ⁨IVM⁩ اجرا، لین روٹنگ اور ایک معیاری منظوری۔

⁨Hyperledger Iroha 3⁩ ایک ٹورنگ مکمل لیجر کو کیسے وسعت دیتا ہے⁨Torii⁩ درخواستیں قبول کرتا ہے اور ⁨Kotodama⁩ پروگرام ⁨IVM⁩ رن ٹائم کے لیے کمپائل کرتا ہے۔ رن ٹائم کام متعدد لینز میں بھیجتا ہے، چلتے وقت نئی لینز شامل ہو سکتی ہیں، اور ⁨Sumeragi⁩ کے ساتھ ⁨Kura⁩ ایک معیاری لیجر منظور کرتے ہیں۔ایک انجن۔ ایک معیاری لیجر۔⁨Torii⁩لین دین قبول کریں⁨Kotodama⁩پروگرام کمپائل کریں⁨Iroha⁩ ورچوئل مشینمتعین اجرالینز⁨Sumeragi + Kura⁩ → منظور شدہ تاریخ

ایک رن ٹائم، کئی لینز، ایک لیجر۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. ⁨Torii⁩ دستخط شدہ درخواست قبول کرتا ہے۔
  2. ⁨Kotodama⁩ پروگرام متعین ⁨IVM⁩ اجرا کے لیے بائٹ کوڈ میں کمپائل ہوتے ہیں۔
  3. رن ٹائم نتیجہ اس کی مختص لین سے بھیجتا ہے۔
  4. ⁨Sumeragi⁩ اور ⁨Kura⁩ ایک معیاری منظوری ثبت کرتے ہیں۔
06
توسیع

لینز + مرج لیجر

ایک لیجر کی تاریخ برقرار رکھتے ہوئے زیادہ کام متوازی پروسیس کریں۔

ادائیگیوں کا حجم بڑھنے پر آزاد کام الگ اجرا لینز میں داخل ہو سکتے ہیں۔ ہر لین اپنا کام کرتی اور نتیجے کی حالت کا التزام بناتی ہے۔

پروٹوکول کے اندر

مرج لیجر ان التزامات کو ایک مرتب تاریخ میں جمع کرتا ہے۔ ادارے اجرا گنجائش بڑھا سکتے ہیں جبکہ ان کے صارفین اور اثاثے وہی لیجر بانٹتے رہتے ہیں۔

بنیادی طور پر متوازی

زیادہ کام ایک اجرا راستے میں رکاوٹ بننے کے بجائے لینز میں تقسیم ہوتا ہے۔

ایک مشترک تاریخ

مرج لیجر نیٹ ورک کو ایک واضح لیجر رکھتا ہے، بکھرے حصوں کا پیوند نہیں۔

بریجز کا کم پھیلاؤ

توسیع مزید چینز، ریپرز اور بریج منطق کے بجائے پروسیسنگ رفتار بڑھاتی ہے۔

پروٹوکول کا نقشہ

لینز + مرج لیجر

متوازی کام آزاد التزامات بناتے ہیں جو ایک معیاری مرج لیجر بلاک میں جمع ہوتے ہیں۔

متوازی لینز ایک لیجر میں ضم ہوتی ہیںہر لین اپنا بلاک اور حالت کی تبدیلیاں رکھتی، پھر التزامات ایک مرج لیجر میں بھیجتی ہے تاکہ مشترک تاریخ تقسیم کیے بغیر رفتار بڑھے۔متوازی کام۔ ایک تاریخ۔لین ⁨01⁩لین ⁨02⁩لین ⁨03⁩التزامات ضم کریںایک لیجر

متوازی لینز الگ چینز میں بٹنے کے بجائے ایک لیجر میں جمع ہوتی ہیں۔

لین دین کا سفر دیکھیں⁨3⁩ مراحل
  1. آزاد کام متوازی اجرا لینز میں داخل ہوتے ہیں۔
  2. ہر لین مصدقہ حالت کا التزام بناتی ہے۔
  3. مرج لیجر ان التزامات کو ایک بلاک میں ترتیب دیتا ہے۔
07
لچک دار ساخت

رن ٹائم میں لین کا دورِ حیات

اتفاقِ رائے سے منظور شدہ تبدیلی کے ذریعے اجرا کی گنجائش اداروں کے کام کے مطابق ڈھالیں۔

آپریٹر مجاز، دستخط شدہ لین دین کے ذریعے لین شامل، تبدیل یا ریٹائر کر سکتا ہے۔ منصوبہ اسی کیٹلاگ اور فعال لین صورتوں سے بندھا ہوتا ہے جن کا آپریٹر نے جائزہ لیا۔ پرانے کیٹلاگ، ناقص منصوبے اور غیر مجاز درخواستیں ساخت تبدیل نہیں کرتے۔

پروٹوکول کے اندر

اتفاقِ رائے سے تبدیلی منظور ہونے کے بعد ہر پیئر وہی کیٹلاگ نافذ کرتا، روٹنگ اور حدود تازہ کرتا اور ذخیرے کی مطابقت کرتا ہے۔ جب تک مصدقہ کام ضم یا نافذ ہونا باقی ہو، لین ریٹائر نہیں ہو سکتی۔

اتفاقِ رائے کے تابع

دورِ حیات کی تبدیلیاں عام دستخط شدہ لین دین استعمال کرتی ہیں اور صرف منظور شدہ بلاک کے ساتھ شائع ہوتی ہیں۔

موجودہ حالت کی جانچ

کیٹلاگ اور صورت کے التزامات تاخیر سے آنے والی درخواستوں کو مختلف ساخت بدلنے سے روکتے ہیں۔

ہم آہنگ صفائی

روٹنگ، منشور، ذخیرے کا لے آؤٹ، ڈیٹا دستیابی کی حالت اور ریلے کیش ساتھ تازہ ہوتے ہیں۔

توسیع

رن ٹائم میں لین کا دورِ حیات

گنجائش شامل، روٹ، مانیٹر اور ریٹائر ہو سکتی ہے جبکہ نیچے ایک معیاری لیجر جاری رہتا ہے۔

رن ٹائم میں لین کا دورِ حیاتگنجائش شامل، روٹ، مانیٹر اور ریٹائر ہو سکتی ہے جبکہ نیچے ایک معیاری لیجر جاری رہتا ہے۔

گنجائش ایک منظور شدہ منصوبے سے بدلتی ہے جس پر ہر پیئر عمل کرتا ہے۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. موجودہ کیٹلاگ دیکھیں اور لین کے دورِ حیات کے منصوبے پر دستخط کریں۔
  2. اختیار، کیٹلاگ التزام، صورت اور حفاظتی شرائط جانچیں۔
  3. ساخت کی تبدیلی منظور کریں اور قطار کی روٹنگ تازہ کریں۔
  4. لین فعال کریں، یا باقی کام مکمل ہونے کے بعد ریٹائر کریں۔
08
حتمیت

⁨Sumeragi⁩ اتفاقِ رائے

متوازی کام کو منظور شدہ نتیجہ بنائیں جس پر تصدیق کنندگان متفق ہوں۔

⁨Sumeragi⁩ اتفاقِ رائے کا نظام ہے جو تجویز کردہ بلاک حتمی بناتا ہے۔ تصدیق کنندگان دو مرحلوں، ⁨Prepare⁩ اور ⁨Commit⁩، میں اس کی توثیق کرتے ہیں۔ ہر کورم سرٹیفکیٹ (⁨QC⁩) ان کے ووٹ عین بلاک، اس کی بلندی، مقررہ تصدیقی فہرست اور حالت کی تبدیلی سے جوڑتا ہے۔

پروٹوکول کے اندر

تصدیق کنندگان ⁨Prepare⁩ سے پہلے بلاک جانچتے اور مستقل محفوظ کرتے، ⁨Commit⁩ سے پہلے لاک محفوظ کرتے اور ⁨Commit QC⁩ فیصلہ نافذ کرنے سے پہلے مستقل ثبت کرتے ہیں۔ متضاد ووٹ مسترد اور بطور شواہد درج ہوتے ہیں؛ وہ کبھی کورم میں شمار نہیں ہوتے۔

دو مصدقہ مرحلے

⁨Prepare⁩ اور ⁨Commit⁩ کورم سرٹیفکیٹ حتمیت تک راستہ واضح کرتے ہیں۔

دستخط سے پہلے مستقل ذخیرہ

پروٹوکول آگے بڑھنے سے پہلے مواد، ووٹ کا ارادہ، لاک اور فیصلہ مستقل ذخیرے کی حدود پار کرتے ہیں۔

قابلِ منتقلی شواہد

منظوری کے ریکارڈ نتیجے کے ساتھ منتقل ہو سکتے ہیں تاکہ ریلے اور آڈیٹرز آزادانہ حتمیت جانچ سکیں۔

پروٹوکول کا نقشہ

⁨Sumeragi⁩ اتفاقِ رائے

عین بلاک ⁨Prepare⁩ اور ⁨Commit⁩ کورم سرٹیفکیٹس سے گزرتا ہے، جبکہ متضاد ووٹ مسترد اور رپورٹ ہوتے ہیں۔

⁨Sumeragi⁩ اتفاقِ رائے حتمیت تک کیسے پہنچتا ہےرہنما بلاک کا عین مواد تجویز کرتا ہے۔ تصدیق کنندگان ⁨Prepare⁩ کورم سرٹیفکیٹ بنانے سے پہلے اسے جانچتے اور مستقل محفوظ کرتے ہیں۔ پھر وہ لاک محفوظ کرتے، ⁨Commit⁩ کورم سرٹیفکیٹ بناتے، فیصلہ مستقل محفوظ کرتے اور بلاک نافذ کرتے ہیں۔ متضاد ووٹ کو گننے کے بجائے مسترد کرکے بطور ثبوت رپورٹ کیا جاتا ہے۔ایک بلاک۔ ایک حتمی فیصلہ۔مواد تجویز کریں۔ ووٹوں کی توثیق کریں۔ فیصلہ محفوظ کریں۔بلندی + ویو⁨h · r⁩ · مقررہ فہرست + طاقت⁨02⁩ · جانچ اور ذخیرہ01تجویز کریں⁨b7e1…⁩مواد + منشورہیش · پے لوڈ · روٹسعینمواددرست + مستقل محفوظتضاد مسترد · شواہد محفوظ03⁨PREPARE QC⁩درست + دستیابکورم مکمل⁨04⁩ · مقفل05⁨COMMIT QC⁩مستقل فیصلہمجموعی ⁨BLS⁩⁨06⁩ · حتمیفیصلہ محفوظ⁨COMMIT QC⁩ + عین موضوععین مواد نافذمتعین اسٹیٹ روٹبلندی ⁨h+1⁩ شروعمعیاری تاریخ آگے بڑھتی ہے

تصدیق کنندگان ⁨Prepare⁩ اور ⁨Commit⁩ مرحلوں میں عین اسی مواد کی توثیق کرتے ہیں؛ ⁨Commit QC⁩ قابلِ منتقلی حتمیت کے شواہد بنتا ہے۔

لین دین کا سفر دیکھیں⁨6⁩ مراحل
  1. متوقع رہنما دستخط شدہ تجویز اور پے لوڈ منشور نشر کرتا ہے۔
  2. تصدیق کنندگان عین مواد دوبارہ بناتے، جانچتے اور مستقل محفوظ کرتے ہیں۔
  3. کافی تصدیق کنندگان اور ووٹنگ طاقت ⁨Prepare⁩ کی توثیق کرتے ہیں۔
  4. تصدیق کنندگان ⁨Commit⁩ ووٹ جاری کرنے سے پہلے عین لاک مستقل محفوظ کرتے ہیں۔
  5. ⁨Commit⁩ کورم سرٹیفکیٹ عین اسی بلاک کو حتمی بناتا ہے۔
  6. فیصلہ مستقل محفوظ ہوتا، عین مواد نافذ ہوتا اور اگلی بلندی شروع ہوتی ہے۔
09
آزاد تصدیق

حتمیت کے قابلِ تصدیق ثبوت

وصول کنندہ ادارے کو معتبر نقطۂ آغاز سے قابلِ جانچ شواہد دیں کہ لین دین حتمی ہے۔

قابلِ منتقلی ثبوت معیاری بلاک ہیڈر کو ⁨Sumeragi⁩ اتفاقِ رائے کے عین مستقل ریکارڈ کے ساتھ یکجا کرتا ہے۔ اس ریکارڈ میں ثابت شدہ بلندی کا سیاق، مصدقہ بلاک موضوع، اجرا کا کرپٹوگرافک التزام، ⁨Commit⁩ کورم سرٹیفکیٹ (⁨QC⁩) اور تصدیق کنندگان کی فہرست کے مطابق کلیدی ملکیت کے ثبوت شامل ہوتے ہیں۔

پروٹوکول کے اندر

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

عین شواہد

مصدقہ موضوع، اجرا روٹس، ⁨Commit⁩ سرٹیفکیٹ، مقررہ تصدیقی فہرست اور ملکیت کے ثبوت برقرار رکھیں۔

دوہرا کورم

دستخط کنندگان کے مجموعے کو الگ تصدیق کنندگان کی تعداد کی حد اور دو تہائی سے لازماً زیادہ ووٹنگ طاقت پوری کرنی ہوگی۔

اعتماد بیرونی رہتا ہے

ثبوت کے ساتھ آنے والی فہرست اپنی تصدیق خود نہیں کر سکتی؛ پہلا قبول شدہ سیاق ایک آزاد معتبر ذریعے سے مقرر کیا جاتا ہے۔

حتمیت

حتمیت کے قابلِ تصدیق ثبوت

معیاری ہیڈر اور ⁨Sumeragi⁩ کی حتمیت کا عین ریکارڈ قابلِ منتقلی شواہد بنتے ہیں، جنہیں تصدیق کنندہ آزادانہ طور پر معتبر چین کے سیاق کے مقابل جانچتا ہے۔

حتمیت کے قابلِ تصدیق ثبوتمعیاری ہیڈر اور ⁨Sumeragi⁩ کی حتمیت کا عین ریکارڈ قابلِ منتقلی شواہد بنتے ہیں، جنہیں تصدیق کنندہ آزادانہ طور پر معتبر چین کے سیاق کے مقابل جانچتا ہے۔

قابلِ منتقلی شواہد ایک نظام کے حتمی نتیجے کو دوسرے نظام کی جانچ سے جوڑتے ہیں۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. ہیڈر، مصدقہ موضوع، اجرا روٹس، ⁨Commit⁩ سرٹیفکیٹ، مقررہ فہرست اور ملکیت کے ثبوت جمع کریں۔
  2. عین ریکارڈ کو قابلِ منتقلی ⁨Norito⁩ ثبوت لفافے میں سربمہر کریں۔
  3. ثبوت کو متوقع چین اور الگ معتبر سیاق اینکر سے جوڑیں۔
  4. حتمیت قبول کرنے سے پہلے ساختی ربط، دونوں کورم حدیں، دستخط کنندگان کی ترتیب، کلیدی ملکیت اور مجموعی ⁨BLS⁩ دستخط جانچیں۔
⁨03⁩ · پروگرام پذیری

پالیسی کو عمل بنائیں

تبادلے کو واضح شرائط بھی چاہییں۔ طے کریں کون سے اکاؤنٹس عمل کر سکتے ہیں، ادائیگی اور فراہمی کی شرائط کوڈ کریں اور مجاز اعمال کے وقت کا فیصلہ کریں۔ مشترک ریکارڈ یہ قواعد آس پاس کی ایپلی کیشنز سے جوڑتے ہیں۔

سوالکون عمل کر سکتا ہے، کن شرائط پر اور کن حدود میں؟

پروگرام تبادلے کی شرائط بیان کرتے ہیں؛ اجازتیں بتاتی ہیں کہ انہیں کون نافذ کر سکتا ہے۔

10
معاہدے

⁨Kotodama⁩ پروگرام

بازار، ادائیگی یا ایپلی کیشن کے قواعد کوڈ میں لکھیں۔

مشترک اجرا اور حتمیت ماڈل موجود ہو تو ٹیمیں ایپلی کیشن کا رویہ متعین کر سکتی ہیں۔ ⁨Kotodama⁩ ایسے پروگرام لکھنے کی زبان ہے جو بازاری منطق، ادائیگی شرائط اور ادارہ جاتی پالیسی بیان کریں۔

پروٹوکول کے اندر

کمپائلر ان پروگراموں کو ⁨Iroha⁩ ورچوئل مشین (⁨IVM⁩) بائٹ کوڈ میں بدلتا ہے۔ تصدیق کنندگان رن ٹائم حدود میں یکساں منطق چلاتے اور حالت کی یکساں تبدیلی اخذ کرتے ہیں۔

اعلیٰ سطحی سورس

ڈویلپرز خام رن ٹائم تفصیلات کے بجائے قابلِ مطالعہ پروگرام لکھتے ہیں۔

ہر جگہ یکساں آؤٹ پٹ

کمپائلیشن ایک اجرا ماڈل کو ہدف بناتی ہے جو ہر تصدیق کنندہ میں مشترک ہے۔

پالیسی اور مصنوعات

یہی پروگرامنگ ماڈل بازاری منطق، خودکاری اور کنٹرول بیان کر سکتا ہے۔

پروٹوکول کا نقشہ

⁨Kotodama + IVM⁩

قابلِ مطالعہ سورس محدود بائٹ کوڈ میں کمپائل ہوتا اور ہر پیئر پر یکساں متعین حالت بناتا ہے۔

⁨Kotodama⁩ کمپائلر کا بہاؤمختصر ⁨Kotodama⁩ سورس پروگرام متعین ⁨IVM⁩ آؤٹ پٹ میں کمپائل ہوتا ہے۔ ہدف رن ٹائم ⁨IVM⁩ ہے، اجرا محدود رہتا ہے اور ہر تصدیق کنندہ کو وہی آؤٹ پٹ بائٹس ملتی ہیں۔قواعد لکھیں۔ نتیجہ دہرائیں۔⁨policy.ko⁩⁨Kotodama⁩ سورسکمپائل کریں⁨IVM⁩بائٹ کوڈہر نوڈ پر یکساں نتیجہ

اعلیٰ سطحی پروگرام نیٹ ورک میں مشترک ایک متعین رن ٹائم میں کمپائل ہوتے ہیں۔

لین دین کا سفر دیکھیں⁨3⁩ مراحل
  1. قابلِ مطالعہ ⁨Kotodama⁩ سورس ⁨IVM⁩ بائٹ کوڈ میں کمپائل ہوتا ہے۔
  2. اجرا محدود سائیکل بجٹ استعمال کرتا ہے۔
  3. ہر تصدیق کنندہ حالت کی یکساں تبدیلی اخذ کرتا ہے۔
11
بنیادی اجزا

⁨Iroha⁩ خصوصی ہدایات

لیجر کے مانوس آپریشنز سے روزمرہ اثاثہ بہاؤ بنائیں۔

بہت سی ایپلی کیشنز وہی بنیادی اعمال استعمال کرتی ہیں: اثاثہ رجسٹر کرنا، اکائیاں بنانا، منتقل کرنا، اجازت دینا یا رسد ختم کرنا۔ ⁨Iroha⁩ انہیں اندرونی، متعین نوع کی ہدایات کے طور پر دیتا ہے۔

پروٹوکول کے اندر

ہر ہدایت مطلوبہ اختیار اور پالیسی جانچتی ہے۔ مرتب بیچ متعدد باہم منحصر اعمال تیار کرکے ساتھ منظور کر سکتا ہے۔ کسی بھی ہدایت کی ناکامی پر تمام تیار شدہ اثرات خارج ہو جاتے ہیں۔

بلٹ اِن اعمال

لیجر کے عام آپریشنز خود پلیٹ فارم میں موجود ہیں۔

تیز مصنوعات سازی

ٹیمیں وہی بہاؤ نئے سرے سے بنانے کے بجائے مشترک بنیادی اجزا جوڑتی ہیں۔

آسان آڈٹ

آڈیٹرز بہت سی قریباً یکساں نقلوں کے بجائے ایک قواعد نامہ سمجھ سکتے ہیں۔

پروٹوکول کا نقشہ

⁨Iroha⁩ خصوصی ہدایات

رجسٹریشن، تخلیق، منتقلی، اجازت اور خاتمے کی متعین نوع کی ہدایات کا مرتب بیچ واضح اختیار کے تحت لیجر کی متعین حالت تیار کرتا ہے۔

حالت کی اندرونی تبدیلیوں کے طور پر ⁨Iroha⁩ خصوصی ہدایاتدستخط شدہ مرتب بیچ اثاثے کی تعریف رجسٹر کرتا، سو اکائیاں بناتا، تیس منتقل کرتا، اجازت دیتا اور دس ختم کرتا ہے۔ ہر متعین نوع کی ہدایت اختیار اور پالیسی کی جانچ سے گزرتی، لیجر کی متعین تبدیلی تیار کرتی اور ایک منظور شدہ حتمی حالت میں حصہ ڈالتی ہے۔پانچ ہدایات۔ حالت کی ایک تبدیلی۔اندرونی آپریشنز، ترتیب سے نافذ۔دستخط شدہ ⁨ISI⁩ بیچہر مرحلے کا اختیار + پالیسیتیار شدہ لیجر حالتمرتب · ناکامی پر تمام تیار اثرات خارجاثاثہ رجسٹر کریں⁨iroha.register⁩رجسٹرڈ⁨CREDIT#CBDC⁩رسد ⁨0⁩⁨100⁩ بنائیں⁨iroha.mint⁩⁨+100⁩ بنےرسد ⁨100⁩جاری کنندہ ⁨100⁩⁨30⁩ منتقل کریں⁨iroha.transfer⁩⁨30⁩ منتقل ہوئےجاری کنندہ ⁨70⁩وصول کنندہ ⁨30⁩ · رسد ⁨100⁩رسائی دیں⁨iroha.grant⁩اختیار یافتہاجازت ⁨+1⁩بیلنس برقرار⁨10⁩ ختم کریں⁨iroha.burn⁩⁨10⁩ ختم ہوئےرسد ⁨90⁩جاری کنندہ ⁨60⁩حالت منظورمرتب ⁨ISI⁩ بیچرسد ⁨90⁩ · جاری کنندہ ⁨60⁩ · وصول کنندہ ⁨30⁩ · اجازت ⁨+1⁩

متعین نوع کی ہدایات کا مرتب بیچ ایک منظور شدہ حالت سے پہلے لیجر کی متعین تبدیلیاں تیار کرتا ہے۔

لین دین کا سفر دیکھیں⁨5⁩ مراحل
  1. صفر رسد کے ساتھ ⁨CREDIT#CBDC⁩ رجسٹر کریں۔
  2. اختیار اور پالیسی کی جانچ کے بعد جاری کنندہ کے لیے ⁨100⁩ اکائیاں بنائیں۔
  3. کل رسد بدلے بغیر وصول کنندہ کو ⁨30⁩ اکائیاں منتقل کریں۔
  4. بیلنس برقرار رکھتے ہوئے ایک اجازت دیں۔
  5. جاری کنندہ کی ⁨10⁩ اکائیاں ختم کریں اور حتمی رسد ⁨90⁩ منظور کریں۔
12
پالیسی

اختیارات کے منشور

ہر شریک کے اکاؤنٹ کو متعین مدت کے لیے بالکل اتنا اختیار دیں جتنا اسے درکار ہے۔

اختیارات کا منشور درج کرتا ہے کہ ایک یونیورسل اکاؤنٹ کسی ڈیٹا اسپیس میں کیا کر سکتا ہے۔ اس میں مجاز پروگرام، طریقے، اثاثے اور جوہری لین دین میں اختیاری کردار متعین ہوتے ہیں۔ فعالیت اور میعاد کے ادوار طے کرتے ہیں کہ یہ اختیار کب نافذ ہوگا۔

پروٹوکول کے اندر

اختیاری زیادہ سے زیادہ رقم موجودہ درخواست کو محدود کرتی ہے۔ کامیاب اجازت اپنے استعمال کی مدت بطور میٹاڈیٹا بھی واپس کرتی ہے۔ متعلقہ انکاری قواعد کو ترجیح حاصل ہے، اور آپریٹرز لائف سائیکل واقعات سے فعالیت، میعاد اور منسوخی کی نگرانی کر سکتے ہیں۔

کم سے کم اختیار

اختیار نامزد ڈیٹا اسپیس، پروگرام، طریقوں، اثاثوں اور کرداروں تک محدود ہے۔

متعین حدود

موجودہ رقم کو مقررہ حد سے جانچیں اور اجازت کے ساتھ فی سلاٹ، فی منٹ یا فی دن استعمال کی مدت واپس کریں۔

انکار کو فوقیت

مطابقت رکھنے والا واضح انکار ممکنہ اجازت پر فوقیت رکھتا ہے اور منظم وجہ واپس کرتا ہے۔

پالیسی

اختیارات کے منشور

ڈیٹا اسپیس تک محدود درخواست کو واضح دائرے، موجودہ درخواست کی زیادہ سے زیادہ رقم اور انکار کو ترجیح دینے والی پالیسی کے مطابق جانچا جاتا ہے۔

اختیارات کے منشورڈیٹا اسپیس تک محدود درخواست کو واضح دائرے، موجودہ درخواست کی زیادہ سے زیادہ رقم اور انکار کو ترجیح دینے والی پالیسی کے مطابق جانچا جاتا ہے۔

ہر اجازت مخصوص اکاؤنٹ، عمل اور ڈیٹا اسپیس سے جڑی ہے۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. متعلقہ اکاؤنٹ کو اس کے یونیورسل اکاؤنٹ اور فعال منشور سے ملائیں۔
  2. مطلوبہ ڈیٹا اسپیس، پروگرام، طریقہ، اثاثہ اور کردار جانچیں۔
  3. درخواست کے دور اور موجودہ رقم کو منشور کی حد سے جانچیں۔
  4. متعلقہ انکاری قواعد جانچیں، پھر اجازت یا منظم انکار واپس کریں۔
13
خودکاری

آن چین خودکاری

رجسٹرڈ واقعہ آنے پر مجاز عمل چلائیں۔

اجازتیں بتاتی ہیں کہ عمل کیا کر سکتا ہے؛ ٹرگر بتاتا ہے کہ کب چلے گا۔ ہر ٹرگر قابلِ اجرا پروگرام، ایک واقعہ فلٹر، اپنا اختیار اور تکرار پالیسی محفوظ کرتا ہے۔ فلٹر شیڈول، منظور شدہ پائپ لائن واقعہ جیسے عین بلاک بلندی، لیجر ڈیٹا واقعہ یا مجاز کال کی درخواست سے مل سکتا ہے۔

پروٹوکول کے اندر

فلٹر ملنے پر ⁨Iroha⁩ رجسٹرڈ اختیار اور عام اجرا پالیسی کے تحت عمل چلاتا ہے۔ اجازتیں، تکرار کی حدود، فیول یا سائیکلز، گیس اور اجرا کی گہرائی کام محدود کرتے ہیں۔ درج نتیجہ ٹرگر، اجرا ہیش اور مرحلے کی شناخت کرتا ہے۔

نیٹ ورک کی اندرونی شیڈولنگ

شیڈول شدہ اور واقعات سے چلنے والے بہاؤ الگ بوٹ یا ⁨cron⁩ خدمت پر منحصر نہیں۔

ایک عین فلٹر

رجسٹرڈ ٹرگر ایک متعین واقعہ فلٹر سنتا ہے، بیک وقت ہر ذریعے کو نہیں۔

محدود اجرا

اجازتیں، تکرار، فیول یا سائیکلز، گیس اور اجرا کی گہرائی خودکار کام کو محدود کرتے ہیں۔

پروٹوکول کا نقشہ

آن چین خودکاری

ایک رجسٹرڈ واقعہ فلٹر اعلان کردہ اختیار کے تحت محدود پروگرام چلاتا، پھر اس کی تکمیل کا نتیجہ درج کرتا ہے۔

آن چین خودکاری کا کنٹرول چکرشیڈول، عین بلاک بلندی کا واقعہ، لیجر ڈیٹا کا واقعہ یا مجاز دستی کال رجسٹرڈ ٹرگر سے مطابقت رکھ سکتی ہے۔ ⁨Iroha⁩ ٹرگر فلٹر طے کرتا، رجسٹرڈ اختیار اور اجرا بجٹ کے تحت اس کا پروگرام چلاتا، حالت میں تبدیلی مرحلہ وار تیار کرتا اور ⁨TriggerCompleted⁩ نتیجہ درج کرتا ہے۔

ایک رجسٹرڈ واقعہ فلٹر محدود عمل چلاتا اور اس کی تکمیل کا نتیجہ درج کرتا ہے۔

لین دین کا سفر دیکھیں⁨5⁩ مراحل
  1. ایک عین منظور شدہ بلاک کے فلٹر والا ٹرگر منتخب کریں۔
  2. مطابقت رکھنے والا واقعہ اپنا رجسٹرڈ پروگرام، اختیار اور باقی تکرار لوڈ کرتا ہے۔
  3. فلٹر، فعال حالت، اختیار اور اجرا حدود جانچیں۔
  4. حالت کی تبدیلی تیار کریں اور کامیابی پر محدود تکرار میں سے ایک استعمال کریں۔
  5. ⁨TriggerCompleted⁩ ٹرگر شناخت، اجرا ہیش، مرحلہ اور نتیجہ درج کرتا ہے۔
14
کوڈیک

⁨Norito⁩ کوڈیک

ہر شریک کو ایک ہی ڈیٹا پڑھنے کا غیر مبہم طریقہ دیں۔

پروگرام، ہدایات اور ثبوت مشترک ڈیٹا فارمیٹ چاہتے ہیں۔ ⁨Norito⁩ متعین نوع کی قدریں مقررہ فیلڈ ترتیب میں انکوڈ کرتا ہے۔ ⁨40⁩ بائٹ ⁨NRT0⁩ ہیڈر ورژن، متوقع اسکیما، کمپریشن موڈ، لمبائی، چیک سم اور لے آؤٹ بتاتا ہے۔

پروٹوکول کے اندر

ریڈر قدر دوبارہ بنانے سے پہلے ان فیلڈز اور ⁨CRC64-XZ⁩ سالمیت چیک سم کو جانچتا ہے۔ یکساں اسکیما اور واضح غیر کمپریس شدہ لے آؤٹ کے ساتھ یکساں قدر یکساں بائٹس بناتی ہے۔ اختیاری کمپریشن ڈی کوڈ شدہ مواد برقرار رکھتی ہے؛ مختلف بیک اینڈز میں کمپریس شدہ بائٹس مختلف ہو سکتی ہیں۔

اسکیما سے منسلک فریم

⁨16⁩ بائٹ کا اسکیما ہیش پے لوڈ کو اس نوع سے جوڑتا ہے جس کی ڈی کوڈر توقع کرتا ہے۔

اسٹریمنگ جانچ

ریڈر اعلان کردہ پے لوڈ پڑھتا، پھر اس کی ⁨CRC64-XZ⁩ سالمیت چیک سم جانچتا ہے۔

عین ازسرنو تشکیل

معیاری فیلڈ ترتیب اور واضح لے آؤٹ قواعد آمد و رفت سے ابہام دور کرتے ہیں۔

پروٹوکول کا نقشہ

⁨Norito⁩ کوڈیک

متعین نوع کی قدر اسکیما سے منسلک ⁨NRT0⁩ فریم بنتی، حصوں میں پڑھنے والے ریڈر سے گزرتی، فارمیٹ اور سالمیت کی جانچ پاس کرتی اور عین دوبارہ بنتی ہے۔

⁨Norito⁩ معیاری انکوڈ اور ڈی کوڈ چکرمتعین نوع کا منتقلی ریکارڈ ⁨40⁩ بائٹ ⁨NRT0⁩ فریم میں معیاری پے لوڈ بنتا ہے۔ اسٹریمنگ ریڈر اسی نوع کی قدر دوبارہ بنانے سے پہلے ورژن، لے آؤٹ فلیگز، اسکیما ہیش، اعلان کردہ لمبائی اور ⁨CRC64-XZ⁩ سالمیت چیک سم کی جانچ کرتا ہے۔

متعین نوع کی قدر جانچا ہوا ⁨NRT0⁩ فریم بنتی اور بغیر ابہام دوبارہ تشکیل پاتی ہے۔

لین دین کا سفر دیکھیں⁨5⁩ مراحل
  1. مرتب فیلڈز ایک معیاری پے لوڈ میں سیریلائز ہوتی ہیں۔
  2. اسکیما، لمبائی، چیک سم، کمپریشن اور لے آؤٹ میٹاڈیٹا کے ساتھ ⁨NRT0⁩ ہیڈر شامل کریں۔
  3. ریڈر ہیڈر اور پے لوڈ حصوں میں وصول کرتا ہے۔
  4. فارمیٹ نشان، ورژن، لے آؤٹ فلیگز، اسکیما، اعلان کردہ لمبائی اور ⁨CRC64-XZ⁩ ترتیب سے جانچے جاتے ہیں۔
  5. جانچے ہوئے پے لوڈ سے اصل متعین نوع کی قدر دوبارہ بنائیں۔
15
ایکو سسٹم کی توسیع

⁨SoraNet + SoraFS⁩

ایپلی کیشنز کو مواد حاصل کرنے اور موصولہ مواد جانچنے کا طریقہ دیں۔

ایپلی کیشنز کو لین دین سے باہر کا ڈیٹا بھی چاہیے۔ ⁨SoraNet⁩ درخواست لے جاتا ہے: سخت ریلے موڈ میں مخفی مواد کی درخواست داخلی، درمیانی اور خارجی ریلے سے گزرتی ہے۔ ⁨SoraFS⁩ اس منشور کی مدد سے مواد حاصل کرتا ہے جو روٹ، حصوں کی ترتیب، لمبائی اور متوقع ڈائجسٹس متعین کرتا ہے۔

پروٹوکول کے اندر

مواد دوبارہ بننے اور حصول کے شواہد کے ساتھ واپس ہونے سے پہلے فراہم کنندہ کے حصے جانچے جاتے ہیں۔ لیجر پر مجاز ادائیگی الگ عمل رہتی ہے۔ یہ اجزا ایسے سافٹ ویئر کی مدد کر سکتے ہیں جو خدمت مانگے، فراہم شدہ نتیجہ جانچے اور واضح پالیسی کے تحت ادائیگی کرے۔

منتخب ریلے سرکٹ

مخفی درخواست منتخب داخلی، درمیانی اور خارجی راستے سے گزرتی ہے۔

منشور سے منسلک حصول

منشور حصول کے لیے لازم عین حصے، ترتیب، لمبائی اور ڈائجسٹس متعین کرتا ہے۔

تصدیق، پھر فراہمی

شے واپس ہونے سے پہلے فراہم کنندہ کے حصے جانچے اور دوبارہ جوڑے جاتے ہیں؛ مجاز ادائیگی الگ ترکیب پا سکتی ہے۔

پروٹوکول کا نقشہ

⁨SoraNet + SoraFS⁩

مخفی مواد کی درخواست منتخب تین مرحلوں والے ⁨SoraNet⁩ سرکٹ سے گزرتی ہے۔ ⁨SoraFS⁩ اس کا منشور تلاش کرتا، متعدد فراہم کنندگان سے حصے حاصل کرکے تصدیق کرتا، پے لوڈ دوبارہ بناتا اور تصدیق شدہ شے کو حصول کے شواہد کے ساتھ واپس کرتا ہے۔

⁨SoraNet⁩ نقل و حمل اور ⁨SoraFS⁩ حصولمواد کے پتے پر مبنی درخواست مخفی کلید بنتی ہے، منتخب تین مرحلوں والے ⁨SoraNet⁩ سرکٹ سے گزر کر ⁨SoraFS⁩ پہنچتی ہے۔ ⁨SoraFS⁩ منشور تلاش کرتا، متعدد فراہم کنندگان سے حصے حاصل کرتا، ہر حصے کی تصدیق کرتا، پے لوڈ دوبارہ بناتا اور تصدیق شدہ شے کو حصول کے شواہد کے ساتھ واپس کرتا ہے۔

⁨SoraNet⁩ ریلے راستہ منتخب کرتا ہے۔ ⁨SoraFS⁩ مواد حاصل، تصدیق اور دوبارہ تشکیل کرتا ہے۔

لین دین کا سفر دیکھیں⁨8⁩ مراحل
  1. مواد کے پتے پر مبنی درخواست مخفی کلید بن جاتی ہے۔
  2. کردار، ورژن اور سخت نقل و حمل پالیسی ⁨SoraNet⁩ کا راستہ منتخب کرتے ہیں۔
  3. درخواست داخلی، درمیانی اور خارجی ریلے کرداروں سے گزرتی ہے۔
  4. ⁨SoraFS⁩ منشور اور اس میں متوقع حصوں کے ڈائجسٹس تلاش کرتا ہے۔
  5. اہل فراہم کنندگان حصے مرتب ازسرنو تشکیل کے بفر میں واپس کرتے ہیں۔
  6. ہر حصہ اور مکمل پے لوڈ منشور کے التزامات سے مطابقت رکھتے ہیں۔
  7. تصدیق شدہ شے اور حصول کے شواہد منتخب سرکٹ سے واپس آتے ہیں۔
  8. فراہمی مکمل ہوتی ہے؛ لیجر پر کوئی مجاز ادائیگی الگ، قابلِ ترکیب عمل رہتی ہے۔
⁨04⁩ · ایجنٹ معیشت

معیشت ⁨AI⁩ ایجنٹس تک بڑھائیں

یہی تبادلہ نمونہ ادارے کی جانب سے حسابی وسائل یا دوسری خدمت خریدنے والے سافٹ ویئر ایجنٹ تک بڑھ سکتا ہے۔ یہ مستقبل کا استعمال ہے: اکاؤنٹس، اجازتیں اور خرچ کے اختیارات انسان ہی متعین کرتے ہیں جنہیں ایجنٹ استعمال کر سکتا ہے۔

سوالکیا مجاز سافٹ ویئر ایجنٹ حصہ لے سکتا ہے؟

ممکنہ ایجنٹ معیشت تصفیے کے یہی بنیادی اجزا استعمال کرتی ہے، جبکہ اختیار انسان اور ادارے تفویض کرتے ہیں۔

16
مستقبل کا استعمال

⁨AI⁩ ایجنٹس کے لیے مشترک معیشت

مستقبل کا استعمال · ⁨Iroha⁩ اکاؤنٹ، اثاثہ، پالیسی اور تصفیے کے بنیادی اجزا دیتا ہے۔ ⁨AI⁩ ماڈلز پروٹوکول سے باہر چلتے ہیں۔

تبادلے کا نمونہ ممکنہ خدماتی معیشت تک بڑھائیں: ⁨AI⁩ ایجنٹس انہی اکاؤنٹ، اجازت اور تصفیہ قواعد کے تحت خدمات کی ادائیگی کر سکتے ہیں۔

فرض کریں ایک ادارہ ایجنٹ کو دوسرے فراہم کنندہ سے حسابی وسائل خریدنے کا اختیار دیتا ہے۔ ایجنٹ عام کلید سے کنٹرول ہونے والے ⁨Iroha⁩ اکاؤنٹ کے ذریعے کام کرے گا۔ انسان اور ادارے اس کے کردار، اجازتیں، بجٹ، خرچ کی حدود اور لین دین کے اختیارات مقرر کریں گے۔

پروٹوکول کے اندر

مجاز اکاؤنٹس اثاثہ رجسٹریشن، تخلیق، منتقلی اور تبادلے کی ہدایات ملا سکتے ہیں۔ یہ اجزا حسابی کریڈٹ، ڈیٹا سیٹ تک رسائی، ماڈل لائسنس، ذخیرہ گنجائش، توانائی اکائیاں، کام کی رسیدیں اور ڈیجیٹل پیداوار کے حقوق کی نمائندگی کر سکتے ہیں۔

⁨Iroha⁩ ورچوئل مشین (⁨IVM⁩) میں چلنے والے ⁨Kotodama⁩ پروگرام اور آن چین ٹرگر ادائیگیاں، فراہمی کی شرائط، متواتر کام اور رسیدیں خودکار بنا سکتے ہیں۔ جوہری لین دین ڈیٹا اسپیسز کے پار ادائیگی اور اثاثے کی فراہمی کو ساتھ کامیاب یا واپس پلٹنے کے قابل بناتی ہے۔ معیاری ⁨Norito⁩ ریکارڈ اور ⁨Sumeragi⁩ حتمیت مجاز اور طے شدہ امور کی قابلِ آڈٹ تاریخ دے سکتے ہیں۔

یہ ⁨Iroha⁩ کے معاشی، خودکاری اور پالیسی اجزا کا مستقبل کا استعمال ہے۔ یہ ⁨AI⁩ ماڈل نہیں چلاتا، یہ نہیں طے کرتا کہ اکاؤنٹ ⁨AI⁩ کے کنٹرول میں ہے یا نہیں، اور کسی ایجنٹ کو غیر محدود خودمختاری نہیں دیتا۔

مشین کے لیے قابلِ مطالعہ قدر

مجاز اکاؤنٹس قابلِ تبادلہ اثاثے، ⁨NFTs⁩ اور خدمات کے حقوق بنا اور تبادلہ کر سکتے ہیں۔

جوہری تبادلہ

ادائیگی اور ڈیجیٹل فراہمی ساتھ منظور ہو سکتی ہیں، یا کسی فریق کو جزوی نتیجہ نہیں چھوڑتیں۔

انسان کا مقرر کردہ اختیار

کردار، اختیارات، بجٹ، حدود اور آڈٹ ریکارڈ ایجنٹ کے عمل کا دائرہ متعین کرتے ہیں۔

مستقبل کا استعمال

⁨AI⁩ ایجنٹس کے لیے مشترک معیشت

مجاز سافٹ ویئر ایجنٹس ادائیگی اور ڈیجیٹل حقوق جوہری طور پر بدل سکتے، معیاری رسیدیں چھوڑ سکتے یا جزوی منتقلی کے بغیر واپس پلٹ سکتے ہیں۔

⁨AI⁩ ایجنٹس کے لیے مشترک معیشتمجاز سافٹ ویئر ایجنٹس ادائیگی اور ڈیجیٹل حقوق جوہری طور پر بدل سکتے، معیاری رسیدیں چھوڑ سکتے یا جزوی منتقلی کے بغیر واپس پلٹ سکتے ہیں۔

اکاؤنٹس، اثاثوں اور انسانی وضع کردہ قواعد سے بنی ممکنہ خدماتی معیشت۔

لین دین کا سفر دیکھیں⁨8⁩ مراحل
  1. خریدار کا اکاؤنٹ ڈیٹا، حسابی وسائل، ذخیرے یا کسی اور مشین کے لیے قابلِ مطالعہ خدمت کی درخواست کرتا ہے۔
  2. اکاؤنٹ اختیار، بیلنس اور خرچ کی حد کی جانچ پاس کرتا ہے۔
  3. مجاز فراہم کنندہ اکاؤنٹ خدمت کا اثاثہ رجسٹر یا تخلیق کرتا ہے۔
  4. ادائیگی اور اثاثے کی فراہمی ڈیٹا اسپیسز کے پار ایک جوہری لین دین میں داخل ہوتی ہیں۔
  5. قدر فراہم کنندہ کو منتقل ہوتی ہے جبکہ خدمت کا حق خریدار کو جاتا ہے۔
  6. دونوں فریق ساتھ منظور کرتے ہیں یا دونوں واضح طور پر واپس پلٹتے ہیں۔
  7. آن چین ٹرگر آپریٹرز کے آڈٹ کے لیے معیاری رسیدیں جاری کرتا ہے۔
  8. تیسرا مجاز اکاؤنٹ اپنی پالیسی کے تحت اثاثہ حاصل یا تبادلہ کر سکتا ہے۔
⁨05⁩ · رازداری

لین دین کے پسِ پشت ڈیٹا محفوظ رکھیں

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

سوالکیا ثابت کرنا ضروری ہے، اور کیا نجی رہ سکتا ہے؟

شرکا مطلوبہ شواہد جانچ سکتے ہیں، جبکہ محفوظ حالت مقامی اور ملتزم معلومات قابلِ بازیابی رہتی ہیں۔

17
نجی شواہد

⁨FASTPQ⁩ ثبوت کا سلسلہ

نجی اجرا کا ٹریس ڈیٹا اسپیس میں رکھتے ہوئے اس کے شواہد جانچیں۔

ادارہ جاتی ادائیگیوں اور خودکار خدمات، دونوں میں حساس سرگرمی ہو سکتی ہے۔ ⁨FASTPQ⁩ خفیہ اجرا کے لیے ثبوت کا سلسلہ دیتا ہے: نجی اجرا ٹریس کے التزامات ثبوت کے ان پٹ بنتے ہیں جبکہ ٹریس اپنی ڈیٹا اسپیس کے اندر رہتا ہے۔

پروٹوکول کے اندر

وصول کنندہ نتیجہ قبول کرنے کا فیصلہ کرنے سے پہلے مطلوبہ شواہد جانچتا ہے۔ وہ مکمل نجی ٹریس لیے بغیر یہ شواہد جانچ سکتا ہے۔

نجی ٹریس

حساس اجرا اسی ڈیٹا اسپیس میں رہتا ہے جس نے اسے پیدا کیا۔

عوامی التزام

معیاری التزامات نتیجہ شائع کیے بغیر ثبوت کو نجی نتیجے سے جوڑتے ہیں۔

تصدیق شدہ داخلہ

مطلوبہ ثبوت قطار میں داخل ہونے سے پہلے عوامی داخلہ قاعدہ پاس یا ناکام کر سکتا ہے۔

پروٹوکول کا نقشہ

⁨FASTPQ⁩ ثبوت کا سلسلہ

نجی ٹریس کے التزامات ٹریس ظاہر کیے بغیر عوامی ثبوت ان پٹس اور تصدیق شدہ فیصلہ بنتے ہیں۔

⁨FASTPQ⁩ ثبوت کا سلسلہ⁨FASTPQ⁩ قطاری ٹریس اور سلیکٹر کالم استعمال کرتا، ⁨Poseidon2⁩ اور اسٹیٹ پاتھ کے ذریعے التزام بناتا اور ڈیٹا اسپیس شناخت، سلاٹ اور روٹس جیسے عوامی ان پٹس کے مقابل تصدیق کرتا ہے۔نجی اجرا۔ عوامی تصدیق۔نجی ٹریس⁨Poseidon2⁩کرپٹوگرافک التزامثبوتتصدیق شدہعوامی ان پٹساسپیس · سلاٹ · روٹس

نجی ٹریس مقامی رہتا ہے؛ وصول کنندہ اس کے ثبوت کے شواہد جانچتا ہے۔

لین دین کا سفر دیکھیں⁨3⁩ مراحل
  1. نجی اجرا کا ٹریس اپنی ڈیٹا اسپیس میں رہتا ہے۔
  2. ٹریس مقامی رکھتے ہوئے التزام اور ثبوت کے ان پٹس شائع کریں۔
  3. تصدیق ٹریس ظاہر کیے بغیر داخلہ طے کرتی ہے۔
18
ثبوت سے مشروط پالیسی

رازداری ثبوت کا داخلہ

نجی لین دین کو اجرا کی قطار میں داخل کرنے سے پہلے منظور شدہ شواہد لازم کریں۔

نجی تبادلے کے لیے بھی قابلِ تصدیق شواہد ضروری ہیں۔ ہر لین کا منشور اس کے کام کے لیے منظور شدہ رازداری کے التزامات، مثلاً ⁨Merkle⁩ روٹس یا ثبوت کی تفصیلات، درج کرتا ہے۔ لین دین اس التزام کے شواہد منسلک کر سکتا ہے جبکہ محفوظ حالت کو عوامی بہاؤ سے باہر رکھتا ہے۔

پروٹوکول کے اندر

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

منشور سے منسلک روٹس

حاکمیت مستقل التزام شناخت اور منظور شدہ تصدیقی پیرامیٹر شائع کرتی ہے۔

داخلے کا ایک راستہ

رن ٹائم اور آڈٹ اوزار ایک ہی معیاری ثبوت ربط جانچتے ہیں۔

ناکامی پر رسائی بند

ثبوت کی محتاج لین دین قابلِ قبول شواہد نہ ہونے پر قطار میں داخل ہونے سے پہلے مسترد ہوتی ہے۔

رازداری

رازداری ثبوت کا داخلہ

نجی لین بنیادی خودمختار سرگرمی ظاہر کیے بغیر منظور شدہ روٹ کے مقابل اپنا التزام ثابت کرتی ہے۔

رازداری ثبوت کا داخلہنجی لین بنیادی خودمختار سرگرمی ظاہر کیے بغیر منظور شدہ روٹ کے مقابل اپنا التزام ثابت کرتی ہے۔

محفوظ حالت مقامی رہتی ہے؛ داخلہ منظور شدہ شواہد پر منحصر ہے۔

لین دین کا سفر دیکھیں⁨4⁩ مراحل
  1. لین دین کو اس کی لین میں بھیجیں اور موجودہ التزام رجسٹری لوڈ کریں۔
  2. منسلک ثبوت کو رجسٹرڈ التزام کی شناخت سے ملائیں۔
  3. گواہ کی تصدیق کریں اور لین کی تعمیلی شرط جانچیں۔
  4. درست شواہد قبول کریں اور ثبوت نہ ہونے والا راستہ واضح طور پر مسترد کریں۔
19
ثبوت

ڈیٹا کی دستیابی اور ثبوت

منظور شدہ تاریخ کا بنیادی ڈیٹا بازیابی کے لیے دستیاب رکھیں۔

نتیجے کی تصدیق اعتماد کا ایک حصہ ہے۔ لین دین مکمل ہونے کے بعد بھی نیٹ ورک کو اپنے التزامات کے پیچھے ڈیٹا بازیافت کرنا ہوتا ہے۔

پروٹوکول کے اندر

ملتزم ڈیٹا قابلِ بازیابی حصوں میں انکوڈ ہوتا ہے۔ دستیابی کی نمونہ جانچ دیکھتی ہے کہ حصے حاصل ہو سکتے ہیں یا نہیں، اور ازسرنو تشکیل مطلوبہ حد کے حصوں سے اصل ڈیٹا بحال کرتی ہے۔

قابلِ بازیابی تاریخ

ملتزم ڈیٹا لکھے جانے کے بہت بعد بھی دوبارہ تشکیل کے قابل رہنا چاہیے۔

حصول سے تقویت یافتہ ثبوت

دستیابی کی جانچ اعتماد کو بنیادی ڈیٹا سے منسلک رکھتی ہے۔

طویل العمر ریکارڈ

یہ نظام ان جگہوں کے لیے بنا ہے جہاں ریکارڈ برسوں مفید رہنا ضروری ہیں۔

پروٹوکول کا نقشہ

ڈیٹا کی دستیابی

حصوں میں بٹے ڈیٹا کے نمونے جانچے جاتے ہیں، وہ جزوی نقصان برداشت کرتا اور باقی حصوں سے دوبارہ بنتا ہے۔

ڈیٹا دستیابی کی نمونہ جانچ اور بازیابیمنشور ملتزم حصوں کا مجموعہ بتاتا ہے۔ دستیابی کی بے ترتیب جانچ منتخب حصوں کو آزماتی ہے، اور کافی حصے باقی ہوں تو نیٹ ورک التزام کے پیچھے پورا ڈیٹا بحال کر سکتا ہے۔حصوں کے نمونے جانچیں۔ پورا ڈیٹا بحال کریں۔ملتزم حصےبے ترتیب جانچبازیافتہ ڈیٹابازیابی کے لیے کافی دستیاب حصے ضروری ہیں۔

نمونہ جانچ اور بازیابی کے راستے نیٹ ورک کی یادداشت سلامت رکھتے ہیں۔

لین دین کا سفر دیکھیں⁨3⁩ مراحل
  1. ملتزم ڈیٹا قابلِ بازیابی حصوں میں انکوڈ ہوتا ہے۔
  2. تصدیق کنندگان دستیابی جانچنے کے لیے حصوں کے نمونے لیتے ہیں، تب بھی جب بعض حصے غائب ہوں۔
  3. باقی حصے مطلوبہ حد پوری کرکے اصل ڈیٹا دوبارہ بناتے ہیں۔
خودمختار زر۔ مجاز سافٹ ویئر۔ ایک پروٹوکول۔

⁨Nexus⁩ میں آئیں

اس تبادلے سے آغاز کریں جس کی آپ کے ادارے کو ضرورت ہے۔

ساخت کا جائزہ لیں، نفاذ دیکھیں یا ⁨SORA⁩ کمیونٹی سے اپنے استعمال پر گفتگو کریں۔

01 · ساخت

وائٹ پیپر ڈاؤن لوڈ کریں

جانچیں کہ ڈیٹا اسپیسز، تصفیہ اور تصدیق آپ کے ادارے کی ضرورتوں سے کیسے مطابقت رکھتے ہیں۔

وائٹ پیپر حاصل کریں 02 · نفاذ

⁨Hyperledger Iroha 3⁩ دریافت کریں

⁨Hyperledger Iroha⁩ ریپوزٹری میں پروٹوکول کا کوڈ اور دستاویزات دیکھیں۔

ریپوزٹری کھولیں 03 · کمیونٹی

اپنے استعمال پر گفتگو کریں

اپنی ضرورتیں بتانے اور سوال پوچھنے کے لیے ⁨Telegram⁩ پر ⁨SORA⁩ کمیونٹی میں شامل ہوں۔

گفتگو میں شامل ہوں

کئی دنیائیں۔ ایک معیشت۔

© 2026

اس ویب سائٹ کی دیکھ بھال ⁨SORA⁩ کمیونٹی کرتی ہے