کیوں ہر بیلنس کا ماخذ ڈبل انٹری لیجر ہونا چاہیے

ہر بینکنگ سسٹم میں ایک جدول ہوتا ہے جو پروڈکٹ کے سب سے اہم سوال کا جواب دیتا ہے: اس صارف کے پاس کتنی رقم ہے؟ قابلِ اعتماد کورز کو نازک کورز سے الگ کرنے والا ڈیزائن فیصلہ یہ ہے کہ وہ عدد محفوظ کیا گیا ہے — ایک کالم جسے کوئی اپ ڈیٹ کرتا ہے — یا اخذ کیا گیا ہے — ایک append-only لیجر کا مجموعہ۔ یہ نفاذ کی جزئیات جیسا لگتا ہے۔ درحقیقت یہ اس نظام کے درمیان فرق ہے جو اپنے بیلنس ثابت کر سکتا ہے اور اس نظام کے جو صرف ان کا دعویٰ کر سکتا ہے۔

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

انجینئرنگ کے تناظر میں ڈبل انٹری کا مطلب کیا ہے

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

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

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

محفوظ کیے گئے بیلنس کیسے بہکتے ہیں

بیلنس کالم والے ڈیزائن کی ناکامی ڈرامائی نہیں ہوتی۔ یہ ایک سست بہاؤ ہے جو معمول کے پروڈکشن ٹریفک سے پیدا ہوتا ہے:

• بیک وقت رسائی: دو نکاسیاں ایک ہی لمحے ایک ہی بیلنس پڑھتی ہیں، دونوں جانچ سے گزر جاتی ہیں، دونوں لکھ دیتی ہیں۔ لیجر کے بغیر اس کا کوئی ریکارڈ نہیں کہ بیلنس کیا ہونا چاہیے تھا۔
• دوبارہ کوششیں اور جزوی ناکامیاں: پیمنٹ فراہم کنندہ ٹائم آؤٹ ہو جاتا ہے، کلائنٹ دوبارہ کوشش کرتا ہے، اور کریڈٹ دو بار لگ جاتا ہے — یا "بیلنس اپ ڈیٹ کریں" اور "ٹرانزیکشن ریکارڈ کریں" کے درمیان کریش دونوں کو مستقل طور پر غیر مطابق چھوڑ دیتا ہے۔
• دستی آپریشنز: سپورٹ انجینئر ایک شکایت براہِ راست UPDATE سے حل کر دیتا ہے۔ صارف خوش ہے؛ جو رقم نمودار ہوئی اس کا کوئی ماخذ نہیں، اور کوئی رپورٹ اسے کبھی واضح نہیں کرے گی۔
• فیسیں اور راؤنڈنگ: ایک جگہ حساب کی گئی اور دوسری جگہ لاگو کی گئی فیس، ہر طرف مختلف طور پر راؤنڈ کی گئی کرنسی تبدیلی — سینٹ کے وہ اجزا جو جمع ہو کر حقیقی فرق بن جاتے ہیں۔

وہ قواعد جو لیجر آپ پر لاگو کرتا ہے — سب کے سب مفید

اخذ کردہ بیلنس سے وابستگی باقی کور پر نظم عائد کرتی ہے۔ یہ پابندیاں پہلے دن سخت لگتی ہیں اور تیسرے سال یہی وجہ نکلتی ہیں کہ نظام درست رہتا ہے:

• کم ترین اکائیوں میں عددِ صحیح رقوم — سینٹ، ساتوشی، wei — کبھی فلوٹنگ پوائنٹ نہیں۔ بائنری فلوٹس 0.10 کو بالکل درست ظاہر نہیں کر سکتے؛ جس لیجر کا مجموعہ صفر ہونا لازم ہے وہ ایسے اعداد پر نہیں بن سکتا جو تقریباً پورے ہوتے ہیں۔
• ناقابلِ تغیر اندراجات: درج شدہ اندراج نہ کبھی ترمیم ہوتا ہے نہ حذف۔ غلطیاں اسی طرح درست ہوتی ہیں جیسے بینک ہمیشہ کرتے آئے ہیں — ایک معکوس اندراج سے جو غلطی اور اصلاح دونوں کو ریکارڈ پر چھوڑ دیتا ہے۔
• آئیڈمپوٹینسی: ہر آپریشن ایک کلید رکھتا ہے، تاکہ دوبارہ بھیجی گئی درخواست صرف ایک بار درج ہو۔ لیجر نقول کو ظاہر کر دیتا ہے؛ آئیڈمپوٹینسی انہیں روکتی ہے۔
• اٹامیسٹی: ڈیبٹ، کریڈٹ اور کاروباری حالت کی تبدیلی یا تو اکٹھے کمٹ ہوتے ہیں یا بالکل نہیں۔ کوڈ کا کوئی راستہ لیجر ٹرانزیکشن کے باہر بیلنس اپ ڈیٹ نہیں کرتا — بشمول انتظامی ایڈجسٹمنٹس، جو خاموش اوور رائٹس کے بجائے عام، قابلِ انتساب اندراجات بن جاتی ہیں۔

مطابقت: بیرونی دنیا کے مقابل ثبوت

اندرونی انویریئنٹ ثابت کرتا ہے کہ نظام خود اپنے ساتھ مطابق ہے۔ مطابقت (reconciliation) ثابت کرتی ہے کہ وہ حقیقت سے مطابق ہے۔ فن ٹیک کور بیرونی فریقوں کے ساتھ پوزیشنیں رکھتا ہے — بینکنگ ریلز، کارڈ پروسیسرز، بلاک چین نیٹ ورکس — اور ہر ایک سچائی کا اپنا نسخہ رکھتا ہے۔ روزانہ مطابقت ہر فراہم کنندہ کے گوشوارے اور ہر آن چین پوزیشن کا موازنہ متعلقہ لیجر اکاؤنٹس سے کرتی ہے اور ہر فرق کی وضاحت پر مجبور کرتی ہے: راستے میں موجود کوئی تصفیہ، ابھی درج نہ ہونے والی فراہم کنندہ کی فیس، یا کوئی حقیقی فرق جسے اسی دن ایک عبوری اندراج اور ایک ذمہ دار مل جاتا ہے۔

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

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

آڈیٹرز اور ریگولیٹرز اصل میں کیا پوچھتے ہیں

دیر یا بدیر ایک ریگولیٹڈ فن ٹیک کو اسی سوال کی کوئی صورت درپیش ہوتی ہے: ثابت کریں کہ صارفین کے بیلنس درست ہیں۔ عملی جواب شواہد کی ایک زنجیر ہے — ہر بیلنس ایک append-only لیجر سے اخذ ہوتا ہے؛ لیجر کا مجموعہ صفر ہے؛ وہ روزانہ ہر بیرونی پوزیشن سے مطابقت کرتا ہے؛ اور ایک ناقابلِ تبدیلی، ہیش چین سے جڑا آڈٹ ٹریل ریکارڈ کرتا ہے کہ ہر حرکت کس نے شروع کی، کس ڈیوائس سے، کس منظوری کے تحت۔

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

وہ ٹیسٹ جو ہر کور بینکنگ پلیٹ فارم پر چلانا چاہیے

اگر آپ کسی پلیٹ فارم کا جائزہ لے رہے ہیں — یا اپنے بنائے ہوئے پر نظرثانی کر رہے ہیں — تو یہ سوال پوچھنے میں پانچ منٹ لگتے ہیں اور جوابات کا جعل مشکل ہے:

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

Coreza کہاں کھڑا ہے

Coreza اسی ڈیزائن کے سخت نسخے پر بنایا گیا ہے: ہر بیلنس — فیاٹ اور کرپٹو — ڈبل انٹری لیجر سے اخذ ہوتا ہے؛ رقوم ہر جگہ کم ترین اکائیوں میں عددِ صحیح ہیں؛ درج شدہ اندراجات ناقابلِ تغیر ہیں، اور اصلاحات میکر-چیکر منظوری کے پیچھے معکوس اندراجات کی صورت ہوتی ہیں؛ اور ہر انسٹینس روزانہ ہر منسلک فراہم کنندہ اور ہر اس چین سے مطابقت کرتا ہے جس پر وہ کام کرتا ہے۔ آڈٹ ٹریل append-only اور ہیش چین سے جڑا ہے — ہر حرکت کا کون، کب اور کہاں سے ریکارڈ کرتا ہے۔

ان میں سے کچھ بھی پروڈکٹ ڈیمو میں نظر نہیں آتا، اور یہی اس مضمون کا اصل نکتہ ہے: لیجر کور بینکنگ پلیٹ فارم کا وہ حصہ ہے جس کا جائزہ اسکرینیں دیکھ کر نہیں لیا جا سکتا۔ اس کور کا ایک ورژن 2024 سے ایک ریگولیٹڈ یورپی فن ٹیک میں حقیقی صارفین اور حقیقی رقم پروسیس کر رہا ہے — اور اوپر کے پانچ سوال وہی ہیں جو ہم آپ کو ہر پلیٹ فارم سے پوچھنے کی تجویز دیتے ہیں، ہمارے سمیت۔