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

ایتھیریم وائٹ پیپر

اگلی نسل کا اسمارٹ کانٹریکٹ اور ڈی سینٹرلائزڈ ایپلیکیشن پلیٹ فارم

2009 میں ستوشی ناکاموتو کی جانب سے Bitcoin کی ڈیولپمنٹ کو اکثر رقم اور کرنسی کی دنیا میں ایک انقلابی پیش رفت قرار دیا جاتا ہے، کیونکہ یہ ایک ایسے ڈیجیٹل اثاثے کی پہلی مثال ہے جس کی بیک وقت نہ تو کوئی پشت پناہی یا "اندرونی قدر (opens in a new tab)" ہے اور نہ ہی کوئی سینٹرلائزڈ جاری کنندہ یا کنٹرولر ہے۔ تاہم، Bitcoin کے تجربے کا ایک اور، اور ممکنہ طور پر زیادہ اہم حصہ، ڈسٹری بیوٹڈ کنسینسس (distributed consensus) کے ایک ٹول کے طور پر اس کی بنیادی بلاک چین ٹیکنالوجی ہے، اور اب تیزی سے توجہ Bitcoin کے اس دوسرے پہلو کی طرف مبذول ہو رہی ہے۔ بلاک چین ٹیکنالوجی کی عام طور پر بیان کی جانے والی متبادل ایپلی کیشنز میں کسٹم کرنسیوں اور مالیاتی آلات کی نمائندگی کے لیے آن-بلاک چین ڈیجیٹل اثاثوں کا استعمال ("کلرڈ کوائنز (opens in a new tab)")، کسی بنیادی فزیکل ڈیوائس کی ملکیت ("اسمارٹ پراپرٹی (opens in a new tab)")، نان-فنجیبل اثاثے جیسے کہ ڈومین نیمز ("Namecoin (opens in a new tab)")، نیز ایسی مزید پیچیدہ ایپلی کیشنز شامل ہیں جن میں ڈیجیٹل اثاثوں کو براہ راست کوڈ کے ایک ایسے ٹکڑے کے ذریعے کنٹرول کیا جاتا ہے جو من مانے اصولوں کو نافذ کرتا ہے ("اسمارٹ کانٹریکٹس (opens in a new tab)") یا یہاں تک کہ بلاک چین پر مبنی "ڈی سینٹرلائزڈ خود مختار تنظیمیں (opens in a new tab)" (DAOs)۔ Ethereum جو کچھ فراہم کرنے کا ارادہ رکھتا ہے وہ ایک ایسی بلاک چین ہے جس میں ایک بلٹ ان، مکمل طور پر فعال ٹیورنگ-کمپلیٹ (Turing-complete) پروگرامنگ زبان موجود ہو، جسے ایسے "کانٹریکٹس" بنانے کے لیے استعمال کیا جا سکے جو من مانے اسٹیٹ ٹرانزیشن فنکشنز (state transition functions) کو انکوڈ کر سکیں، جس سے صارفین کو اوپر بیان کردہ کسی بھی سسٹم کے ساتھ ساتھ بہت سے دوسرے سسٹمز جن کا ہم نے ابھی تک تصور بھی نہیں کیا ہے، محض چند لائنوں کے کوڈ میں لاجک لکھ کر بنانے کی سہولت ملے۔

بٹ کوائن اور موجودہ تصورات کا تعارف

تاریخ

ڈی سینٹرلائزڈ ڈیجیٹل کرنسی کا تصور، نیز پراپرٹی رجسٹری جیسی متبادل ایپلی کیشنز، دہائیوں سے موجود ہیں۔ 1980 اور 1990 کی دہائی کے گمنام ای-کیش (e-cash) پروٹوکولز، جو زیادہ تر Chaumian blinding نامی کرپٹوگرافک پرائمیٹو پر انحصار کرتے تھے، نے اعلیٰ درجے کی پرائیویسی کے ساتھ ایک کرنسی فراہم کی، لیکن یہ پروٹوکولز ایک سینٹرلائزڈ ثالث پر انحصار کی وجہ سے زیادہ مقبولیت حاصل کرنے میں ناکام رہے۔ 1998 میں، Wei Dai کا b-money (opens in a new tab) پہلا پروپوزل بن گیا جس نے کمپیوٹیشنل پہیلیاں حل کرنے کے ساتھ ساتھ ڈی سینٹرلائزڈ کنسینسس (decentralized consensus) کے ذریعے پیسہ بنانے کا خیال پیش کیا، لیکن اس پروپوزل میں اس بات کی تفصیلات کم تھیں کہ ڈی سینٹرلائزڈ کنسینسس کو حقیقت میں کیسے نافذ کیا جا سکتا ہے۔ 2005 میں، Hal Finney نے "reusable proofs of work (opens in a new tab)" کا تصور متعارف کرایا، ایک ایسا سسٹم جو b-money کے خیالات کو Adam Back کی کمپیوٹیشنل طور پر مشکل Hashcash پہیلیوں کے ساتھ ملا کر کریپٹو کرنسی کا تصور بناتا ہے، لیکن ایک بار پھر بیک اینڈ کے طور پر ٹرسٹڈ کمپیوٹنگ پر انحصار کر کے مثالی معیار سے پیچھے رہ گیا۔ 2009 میں، پہلی بار Satoshi Nakamoto کی جانب سے ایک ڈی سینٹرلائزڈ کرنسی کو عملی طور پر نافذ کیا گیا، جس میں پبلک کی (public key) کرپٹوگرافی کے ذریعے ملکیت کے انتظام کے لیے قائم شدہ پرائمیٹوز کو ایک کنسینسس الگورتھم کے ساتھ ملایا گیا تاکہ یہ ٹریک رکھا جا سکے کہ کوائنز کا مالک کون ہے، جسے "پروف-آف-ورک" (proof-of-work) کہا جاتا ہے۔

پروف-آف-ورک کے پیچھے موجود میکانزم اس فیلڈ میں ایک بڑی کامیابی تھی کیونکہ اس نے بیک وقت دو مسائل حل کیے۔ پہلا، اس نے ایک سادہ اور معتدل حد تک موثر کنسینسس الگورتھم فراہم کیا، جس سے نیٹ ورک میں موجود نوڈز کو بٹ کوائن لیجر کی اسٹیٹ (state) میں کینونیکل اپ ڈیٹس کے ایک سیٹ پر اجتماعی طور پر متفق ہونے کی اجازت ملی۔ دوسرا، اس نے کنسینسس کے عمل میں آزادانہ داخلے کی اجازت دینے کا ایک میکانزم فراہم کیا، جس نے یہ فیصلہ کرنے کا سیاسی مسئلہ حل کر دیا کہ کنسینسس پر اثر انداز ہونے کا حق کسے ملتا ہے، جبکہ بیک وقت sybil حملوں کو بھی روکا۔ یہ شرکت میں ایک رسمی رکاوٹ، جیسے کسی خاص فہرست میں ایک منفرد ہستی کے طور پر رجسٹر ہونے کی ضرورت، کو ایک اقتصادی رکاوٹ سے بدل کر ایسا کرتا ہے - کنسینسس ووٹنگ کے عمل میں ایک نوڈ کا وزن براہ راست اس کمپیوٹنگ پاور کے متناسب ہوتا ہے جو وہ نوڈ لاتا ہے۔ اس کے بعد سے، ایک متبادل طریقہ کار تجویز کیا گیا ہے جسے پروف-آف-اسٹیک (proof-of-stake) کہا جاتا ہے، جو کسی نوڈ کے وزن کا حساب اس کی کرنسی ہولڈنگز کے متناسب لگاتا ہے نہ کہ کمپیوٹیشنل وسائل کے؛ ان دونوں طریقوں کی متعلقہ خوبیوں پر بحث اس پیپر کے دائرہ کار سے باہر ہے لیکن یہ نوٹ کیا جانا چاہیے کہ دونوں طریقوں کو کریپٹو کرنسی کی ریڑھ کی ہڈی کے طور پر استعمال کیا جا سکتا ہے۔

بٹ کوائن بطور اسٹیٹ ٹرانزیشن سسٹم

تکنیکی نقطہ نظر سے، بٹ کوائن جیسی کریپٹو کرنسی کے لیجر کو ایک اسٹیٹ ٹرانزیشن سسٹم (state transition system) کے طور پر سمجھا جا سکتا ہے، جہاں ایک "اسٹیٹ" (state) ہوتی ہے جو تمام موجودہ بٹ کوائنز کی ملکیت کی حیثیت پر مشتمل ہوتی ہے اور ایک "اسٹیٹ ٹرانزیشن فنکشن" ہوتا ہے جو ایک اسٹیٹ اور ایک ٹرانزیکشن کو لیتا ہے اور نتیجے کے طور پر ایک نئی اسٹیٹ آؤٹ پٹ کرتا ہے۔ مثال کے طور پر، ایک معیاری بینکنگ سسٹم میں، اسٹیٹ ایک بیلنس شیٹ ہوتی ہے، ٹرانزیکشن A سے B میں $X منتقل کرنے کی درخواست ہوتی ہے، اور اسٹیٹ ٹرانزیشن فنکشن A کے اکاؤنٹ میں $X کی کمی کرتا ہے اور B کے اکاؤنٹ میں $X کا اضافہ کرتا ہے۔ اگر A کے اکاؤنٹ میں پہلے ہی $X سے کم رقم ہو، تو اسٹیٹ ٹرانزیشن فنکشن ایک ایرر (error) لوٹاتا ہے۔ لہذا، کوئی بھی اسے باقاعدہ طور پر یوں بیان کر سکتا ہے:

APPLY(S,TX) -> S' or ERROR

اوپر بیان کردہ بینکنگ سسٹم میں:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

لیکن:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

بٹ کوائن میں "اسٹیٹ" ان تمام کوائنز کا مجموعہ ہے (تکنیکی طور پر، "unspent transaction outputs" یا UTXO) جو بنائے (mint) جا چکے ہیں اور ابھی تک خرچ نہیں ہوئے، ہر UTXO کی ایک مالیت اور ایک مالک ہوتا ہے (جسے 20-بائٹ ایڈریس سے ظاہر کیا جاتا ہے جو بنیادی طور پر ایک کرپٹوگرافک پبلک کی ہے^fn1)۔ ایک ٹرانزیکشن میں ایک یا زیادہ ان پٹس ہوتے ہیں، ہر ان پٹ میں موجودہ UTXO کا حوالہ اور مالک کے ایڈریس سے وابستہ پرائیویٹ کی (private key) کے ذریعے تیار کردہ کرپٹوگرافک دستخط شامل ہوتے ہیں، اور ایک یا زیادہ آؤٹ پٹس ہوتے ہیں، ہر آؤٹ پٹ میں اسٹیٹ میں شامل کیے جانے والے ایک نئے UTXO کو رکھا جاتا ہے۔

اسٹیٹ ٹرانزیشن فنکشن APPLY(S,TX) -> S' کو تقریباً اس طرح بیان کیا جا سکتا ہے:

1. TX میں ہر ان پٹ کے لیے:

   • اگر حوالہ دیا گیا UTXO S میں نہیں ہے، تو ایک ایرر لوٹائیں۔
   • اگر فراہم کردہ دستخط UTXO کے مالک سے میل نہیں کھاتا، تو ایک ایرر لوٹائیں۔
2. اگر تمام ان پٹ UTXO کی مالیت کا مجموعہ تمام آؤٹ پٹ UTXO کی مالیت کے مجموعے سے کم ہے، تو ایک ایرر لوٹائیں۔
3. تمام ان پٹ UTXO کو ہٹا کر اور تمام آؤٹ پٹ UTXO کو شامل کر کے S لوٹائیں۔

پہلے قدم کا پہلا حصہ ٹرانزیکشن بھیجنے والوں کو وہ کوائنز خرچ کرنے سے روکتا ہے جو موجود نہیں ہیں، پہلے قدم کا دوسرا حصہ ٹرانزیکشن بھیجنے والوں کو دوسرے لوگوں کے کوائنز خرچ کرنے سے روکتا ہے، اور دوسرا قدم قدر کے تحفظ (conservation of value) کو نافذ کرتا ہے۔ اسے ادائیگی کے لیے استعمال کرنے کی غرض سے، پروٹوکول کچھ یوں ہے۔ فرض کریں کہ Alice، Bob کو 11.7 BTC بھیجنا چاہتی ہے۔ سب سے پہلے، Alice اپنے پاس موجود دستیاب UTXO کا ایک سیٹ تلاش کرے گی جس کا کل مجموعہ کم از کم 11.7 BTC ہو۔ حقیقت پسندانہ طور پر، Alice کو بالکل 11.7 BTC نہیں مل پائیں گے؛ فرض کریں کہ وہ کم از کم جو حاصل کر سکتی ہے وہ 6+4+2=12 ہے۔ پھر وہ ان تین ان پٹس اور دو آؤٹ پٹس کے ساتھ ایک ٹرانزیکشن بناتی ہے۔ پہلا آؤٹ پٹ 11.7 BTC کا ہوگا جس کا مالک Bob کا ایڈریس ہوگا، اور دوسرا آؤٹ پٹ باقی 0.3 BTC "بقیہ" (change) ہوگا، جس کی مالک خود Alice ہوگی۔

مائننگ

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

یہ چیک کرنے کا الگورتھم کہ آیا کوئی بلاک درست ہے، اس پیراڈائم میں اس طرح بیان کیا گیا ہے:

1. چیک کریں کہ آیا بلاک کے ذریعے حوالہ دیا گیا پچھلا بلاک موجود ہے اور درست ہے۔
2. چیک کریں کہ بلاک کا ٹائم اسٹیمپ پچھلے بلاک کے ٹائم اسٹیمپ سے زیادہ ہے^fn2 اور مستقبل میں 2 گھنٹے سے کم ہے۔
3. چیک کریں کہ بلاک پر پروف-آف-ورک درست ہے۔
4. فرض کریں کہ S[0] پچھلے بلاک کے اختتام پر اسٹیٹ ہے۔
5. فرض کریں کہ TX بلاک کی ٹرانزیکشن لسٹ ہے جس میں n ٹرانزیکشنز ہیں۔ 0...n-1 میں تمام i کے لیے، S[i+1] = APPLY(S[i],TX[i]) سیٹ کریں۔ اگر کوئی بھی ایپلیکیشن ایرر لوٹاتی ہے، تو باہر نکلیں اور false لوٹائیں۔
6. true لوٹائیں، اور اس بلاک کے اختتام پر S[n] کو اسٹیٹ کے طور پر رجسٹر کریں۔

بنیادی طور پر، بلاک میں موجود ہر ٹرانزیکشن کو ٹرانزیکشن کے ایگزیکیوٹ ہونے سے پہلے کی کینونیکل اسٹیٹ سے کسی نئی اسٹیٹ میں ایک درست اسٹیٹ ٹرانزیشن فراہم کرنی چاہیے۔ نوٹ کریں کہ اسٹیٹ کو کسی بھی طرح سے بلاک میں انکوڈ نہیں کیا گیا ہے؛ یہ خالصتاً ایک تجرید (abstraction) ہے جسے درست ثابت کرنے والے نوڈ کو یاد رکھنا ہوتا ہے اور اسے کسی بھی بلاک کے لیے صرف جینیسس اسٹیٹ (genesis state) سے شروع کر کے اور ہر بلاک میں ہر ٹرانزیکشن کو ترتیب وار لاگو کر کے (محفوظ طریقے سے) کمپیوٹ کیا جا سکتا ہے۔ مزید برآں، نوٹ کریں کہ مائنر جس ترتیب سے ٹرانزیکشنز کو بلاک میں شامل کرتا ہے وہ اہمیت رکھتی ہے؛ اگر کسی بلاک میں دو ٹرانزیکشنز A اور B اس طرح ہیں کہ B، A کے بنائے گئے UTXO کو خرچ کرتی ہے، تو بلاک تبھی درست ہوگا جب A، B سے پہلے آئے، بصورت دیگر نہیں۔

مندرجہ بالا فہرست میں موجود ایک درستگی کی شرط جو دوسرے سسٹمز میں نہیں پائی جاتی وہ "پروف-آف-ورک" کی ضرورت ہے۔ قطعی شرط یہ ہے کہ ہر بلاک کا ڈبل-SHA256 ہیش، جسے 256-بٹ نمبر کے طور پر سمجھا جاتا ہے، ایک متحرک طور پر ایڈجسٹ کیے گئے ہدف سے کم ہونا چاہیے، جو اس تحریر کے وقت تقریباً 2¹⁸⁷ ہے۔ اس کا مقصد بلاک کی تخلیق کو کمپیوٹیشنل طور پر "مشکل" بنانا ہے، اس طرح sybil حملہ آوروں کو پوری بلاک چین کو اپنے حق میں دوبارہ بنانے سے روکنا ہے۔ چونکہ SHA256 کو مکمل طور پر غیر متوقع سیوڈو-رینڈم (pseudo-random) فنکشن کے طور پر ڈیزائن کیا گیا ہے، اس لیے ایک درست بلاک بنانے کا واحد طریقہ صرف ٹرائل اینڈ ایرر (trial and error) ہے، یعنی بار بار نانس (nonce) میں اضافہ کرنا اور یہ دیکھنا کہ آیا نیا ہیش میل کھاتا ہے۔

~2¹⁸⁷ کے موجودہ ہدف پر، ایک درست بلاک ملنے سے پہلے نیٹ ورک کو اوسطاً ~2⁶⁹ کوششیں کرنی پڑتی ہیں؛ عام طور پر، نیٹ ورک کی طرف سے ہر 2016 بلاکس کے بعد ہدف کو دوبارہ کیلیبریٹ کیا جاتا ہے تاکہ اوسطاً ہر دس منٹ میں نیٹ ورک میں کسی نوڈ کے ذریعے ایک نیا بلاک تیار کیا جائے۔ مائنرز کو اس کمپیوٹیشنل کام کا معاوضہ دینے کے لیے، ہر بلاک کا مائنر ایک ایسی ٹرانزیکشن شامل کرنے کا حقدار ہے جو انہیں کہیں سے بھی 25 BTC دے دے۔ مزید برآں، اگر کسی ٹرانزیکشن کے ان پٹس میں اس کے آؤٹ پٹس کی نسبت زیادہ کل مالیت ہے، تو یہ فرق بھی مائنر کو "ٹرانزیکشن فیس" کے طور پر ملتا ہے۔ اتفاق سے، یہ وہ واحد میکانزم بھی ہے جس کے ذریعے BTC جاری کیے جاتے ہیں؛ جینیسس اسٹیٹ میں بالکل کوئی کوائنز نہیں تھے۔

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

1. کسی پروڈکٹ (ترجیحاً تیزی سے ڈیلیور ہونے والی ڈیجیٹل چیز) کے بدلے کسی مرچنٹ کو 100 BTC بھیجیں۔
2. پروڈکٹ کی ڈیلیوری کا انتظار کریں۔
3. وہی 100 BTC خود کو بھیجنے کی ایک اور ٹرانزیکشن بنائیں۔
4. نیٹ ورک کو یہ باور کرانے کی کوشش کریں کہ اس کی خود کو کی گئی ٹرانزیکشن وہ تھی جو پہلے آئی تھی۔

ایک بار جب قدم (1) ہو جاتا ہے، تو چند منٹوں کے بعد کوئی مائنر اس ٹرانزیکشن کو ایک بلاک میں شامل کر لے گا، فرض کریں بلاک نمبر 270000۔ تقریباً ایک گھنٹے کے بعد، اس بلاک کے بعد چین میں مزید پانچ بلاکس شامل ہو چکے ہوں گے، جن میں سے ہر ایک بلاک بالواسطہ طور پر اس ٹرانزیکشن کی طرف اشارہ کر رہا ہوگا اور اس طرح اس کی "تصدیق" کر رہا ہوگا۔ اس مقام پر، مرچنٹ ادائیگی کو حتمی تسلیم کر لے گا اور پروڈکٹ ڈیلیور کر دے گا؛ چونکہ ہم فرض کر رہے ہیں کہ یہ ایک ڈیجیٹل چیز ہے، اس لیے ڈیلیوری فوری ہوتی ہے۔ اب، حملہ آور 100 BTC خود کو بھیجنے کی ایک اور ٹرانزیکشن بناتا ہے۔ اگر حملہ آور اسے یونہی جاری کر دیتا ہے، تو ٹرانزیکشن پروسیس نہیں ہوگی؛ مائنرز APPLY(S,TX) چلانے کی کوشش کریں گے اور دیکھیں گے کہ TX ایک ایسا UTXO استعمال کرتا ہے جو اب اسٹیٹ میں نہیں ہے۔ لہذا اس کے بجائے، حملہ آور بلاک چین کا ایک "فورک" (fork) بناتا ہے، جس کی شروعات بلاک 270000 کا ایک اور ورژن مائن کر کے ہوتی ہے جو اسی بلاک 269999 کو پیرنٹ کے طور پر اشارہ کرتا ہے لیکن پرانی ٹرانزیکشن کی جگہ نئی ٹرانزیکشن کے ساتھ۔ چونکہ بلاک کا ڈیٹا مختلف ہے، اس لیے اس کے لیے پروف-آف-ورک کو دوبارہ کرنے کی ضرورت ہوتی ہے۔ مزید برآں، حملہ آور کے بلاک 270000 کے نئے ورژن کا ہیش مختلف ہے، اس لیے اصل بلاکس 270001 سے 270005 اس کی طرف "اشارہ" نہیں کرتے؛ اس طرح، اصل چین اور حملہ آور کی نئی چین بالکل الگ ہو جاتی ہیں۔ اصول یہ ہے کہ فورک میں سب سے لمبی بلاک چین کو سچ مانا جاتا ہے، اور اس لیے جائز مائنرز 270005 چین پر کام کریں گے جبکہ حملہ آور اکیلا 270000 چین پر کام کر رہا ہوگا۔ حملہ آور کو اپنی بلاک چین کو سب سے لمبا بنانے کے لیے، اسے باقی تمام نیٹ ورک کے مجموعے سے زیادہ کمپیوٹیشنل پاور کی ضرورت ہوگی تاکہ وہ ان تک پہنچ سکے (اسی لیے اسے "51% حملہ" کہا جاتا ہے)۔

مرکل ٹریز (Merkle Trees)

بائیں: کسی برانچ کی درستگی کا ثبوت دینے کے لیے مرکل ٹری میں صرف چند نوڈز پیش کرنا کافی ہے۔

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

بٹ کوائن کی اسکیل ایبلٹی (scalability) کی ایک اہم خصوصیت یہ ہے کہ بلاک کو ملٹی لیول ڈیٹا اسٹرکچر میں اسٹور کیا جاتا ہے۔ کسی بلاک کا "ہیش" دراصل صرف بلاک ہیڈر کا ہیش ہوتا ہے، جو تقریباً 200 بائٹ کا ڈیٹا ہوتا ہے جس میں ٹائم اسٹیمپ، نانس، پچھلے بلاک کا ہیش اور مرکل ٹری کہلانے والے ڈیٹا اسٹرکچر کا روٹ ہیش شامل ہوتا ہے جو بلاک کی تمام ٹرانزیکشنز کو اسٹور کرتا ہے۔ مرکل ٹری بائنری ٹری کی ایک قسم ہے، جو نوڈز کے ایک سیٹ پر مشتمل ہوتی ہے جس میں ٹری کے نچلے حصے میں بڑی تعداد میں لیف نوڈز (leaf nodes) ہوتے ہیں جن میں بنیادی ڈیٹا ہوتا ہے، درمیانی نوڈز کا ایک سیٹ ہوتا ہے جہاں ہر نوڈ اپنے دو چلڈرن (children) کا ہیش ہوتا ہے، اور آخر میں ایک واحد روٹ نوڈ ہوتا ہے، جو اپنے دو چلڈرن کے ہیش سے بھی بنتا ہے، اور ٹری کے "اوپری حصے" کی نمائندگی کرتا ہے۔ مرکل ٹری کا مقصد بلاک میں موجود ڈیٹا کو ٹکڑوں میں ڈیلیور کرنے کی اجازت دینا ہے: ایک نوڈ ایک ذریعے سے صرف بلاک کا ہیڈر ڈاؤن لوڈ کر سکتا ہے، دوسرے ذریعے سے ٹری کا وہ چھوٹا حصہ جو اس سے متعلق ہو، اور پھر بھی اسے یقین دہانی ہو سکتی ہے کہ تمام ڈیٹا درست ہے۔ اس کے کام کرنے کی وجہ یہ ہے کہ ہیشز اوپر کی طرف پھیلتے ہیں: اگر کوئی بدنیتی پر مبنی صارف مرکل ٹری کے نچلے حصے میں جعلی ٹرانزیکشن کو تبدیل کرنے کی کوشش کرتا ہے، تو یہ تبدیلی اوپر والے نوڈ میں تبدیلی کا سبب بنے گی، اور پھر اس سے اوپر والے نوڈ میں تبدیلی کا سبب بنے گی، بالآخر ٹری کے روٹ کو اور اس طرح بلاک کے ہیش کو تبدیل کر دے گی، جس کی وجہ سے پروٹوکول اسے بالکل مختلف بلاک کے طور پر رجسٹر کرے گا (تقریباً یقینی طور پر ایک غلط پروف-آف-ورک کے ساتھ)۔

مرکل ٹری پروٹوکول طویل مدتی پائیداری کے لیے بلاشبہ ضروری ہے۔ بٹ کوائن نیٹ ورک میں ایک "فل نوڈ" (full node)، جو ہر بلاک کو مکمل طور پر اسٹور اور پروسیس کرتا ہے، اپریل 2014 تک بٹ کوائن نیٹ ورک میں تقریباً 15 GB ڈسک اسپیس لیتا ہے، اور ہر ماہ ایک گیگا بائٹ سے زیادہ بڑھ رہا ہے۔ فی الحال، یہ کچھ ڈیسک ٹاپ کمپیوٹرز کے لیے قابل عمل ہے اور فونز کے لیے نہیں، اور مستقبل میں صرف کاروبار اور شوقین افراد ہی اس میں حصہ لے سکیں گے۔ "سمپلیفائیڈ پیمنٹ ویریفکیشن" (SPV) کے نام سے جانا جانے والا ایک پروٹوکول نوڈز کی ایک اور کلاس کو وجود میں لانے کی اجازت دیتا ہے، جسے "لائٹ نوڈز" (light nodes) کہا جاتا ہے، جو بلاک ہیڈرز ڈاؤن لوڈ کرتے ہیں، بلاک ہیڈرز پر پروف-آف-ورک کی تصدیق کرتے ہیں، اور پھر صرف ان "برانچز" کو ڈاؤن لوڈ کرتے ہیں جو ان سے متعلقہ ٹرانزیکشنز سے وابستہ ہوتی ہیں۔ یہ لائٹ نوڈز کو سیکیورٹی کی مضبوط گارنٹی کے ساتھ یہ تعین کرنے کی اجازت دیتا ہے کہ کسی بھی بٹ کوائن ٹرانزیکشن کی حیثیت، اور ان کا موجودہ بیلنس کیا ہے، جبکہ وہ پوری بلاک چین کا صرف ایک بہت چھوٹا حصہ ڈاؤن لوڈ کرتے ہیں۔

متبادل بلاک چین ایپلی کیشنز

بنیادی بلاک چین کے خیال کو لے کر اسے دوسرے تصورات پر لاگو کرنے کے خیال کی بھی ایک طویل تاریخ ہے۔ 2005 میں، Nick Szabo نے "secure property titles with owner authority (opens in a new tab)" کا تصور پیش کیا، ایک دستاویز جس میں بتایا گیا ہے کہ کس طرح "ریپلیکیٹڈ ڈیٹا بیس ٹیکنالوجی میں نئی پیشرفت" ایک بلاک چین پر مبنی سسٹم کی اجازت دے گی جو اس بات کی رجسٹری اسٹور کرے گا کہ کون کس زمین کا مالک ہے، جس سے ہومسٹیڈنگ (homesteading)، ایڈورس پوزیشن (adverse possession) اور جارجین لینڈ ٹیکس (Georgian land tax) جیسے تصورات سمیت ایک وسیع فریم ورک تیار ہوگا۔ تاہم، بدقسمتی سے اس وقت کوئی موثر ریپلیکیٹڈ ڈیٹا بیس سسٹم دستیاب نہیں تھا، اور اس لیے اس پروٹوکول کو کبھی عملی طور پر نافذ نہیں کیا گیا۔ تاہم، 2009 کے بعد، ایک بار جب بٹ کوائن کا ڈی سینٹرلائزڈ کنسینسس تیار ہو گیا تو تیزی سے کئی متبادل ایپلی کیشنز ابھرنا شروع ہو گئیں۔

• Namecoin - 2010 میں بنایا گیا، Namecoin (opens in a new tab) کو بہترین طور پر ایک ڈی سینٹرلائزڈ نام رجسٹریشن ڈیٹا بیس کے طور پر بیان کیا جا سکتا ہے۔ Tor، Bitcoin اور BitMessage جیسے ڈی سینٹرلائزڈ پروٹوکولز میں، اکاؤنٹس کی شناخت کا کوئی طریقہ ہونا چاہیے تاکہ دوسرے لوگ ان کے ساتھ بات چیت کر سکیں، لیکن تمام موجودہ حلوں میں دستیاب واحد شناخت کنندہ ایک سیوڈو-رینڈم ہیش ہے جیسے 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy۔ مثالی طور پر، کوئی بھی چاہے گا کہ اس کا اکاؤنٹ "george" جیسے نام کے ساتھ ہو۔ تاہم، مسئلہ یہ ہے کہ اگر ایک شخص "george" کے نام سے اکاؤنٹ بنا سکتا ہے تو کوئی اور بھی اسی عمل کو استعمال کر کے اپنے لیے "george" رجسٹر کر سکتا ہے اور ان کا روپ دھار سکتا ہے۔ اس کا واحد حل فرسٹ-ٹو-فائل (first-to-file) پیراڈائم ہے، جہاں پہلا رجسٹر کرنے والا کامیاب ہوتا ہے اور دوسرا ناکام ہو جاتا ہے - یہ ایک ایسا مسئلہ ہے جو بٹ کوائن کنسینسس پروٹوکول کے لیے بالکل موزوں ہے۔ Namecoin اس طرح کے خیال کو استعمال کرنے والے نام رجسٹریشن سسٹم کا سب سے پرانا، اور سب سے کامیاب نفاذ ہے۔
• Colored coins - colored coins (opens in a new tab) کا مقصد ایک ایسے پروٹوکول کے طور پر کام کرنا ہے جو لوگوں کو اپنی ڈیجیٹل کرنسیاں بنانے کی اجازت دے - یا، ایک یونٹ والی کرنسی کے اہم معمولی معاملے میں، بٹ کوائن بلاک چین پر ڈیجیٹل ٹوکنز بنانے کی اجازت دے۔ colored coins پروٹوکول میں، کوئی شخص کسی مخصوص بٹ کوائن UTXO کو عوامی طور پر ایک رنگ تفویض کر کے ایک نئی کرنسی "جاری" کرتا ہے، اور پروٹوکول ریکرسیولی (recursively) دوسرے UTXO کے رنگ کو ان ان پٹس کے رنگ جیسا ہی قرار دیتا ہے جو انہیں بنانے والی ٹرانزیکشن نے خرچ کیے تھے (مکسڈ کلر ان پٹس کی صورت میں کچھ خاص اصول لاگو ہوتے ہیں)۔ یہ صارفین کو ایسے والٹس برقرار رکھنے کی اجازت دیتا ہے جن میں صرف ایک مخصوص رنگ کے UTXO ہوں اور انہیں عام بٹ کوائنز کی طرح بھیج سکیں، اور بلاک چین کے ذریعے بیک ٹریک (backtrack) کر کے کسی بھی موصول ہونے والے UTXO کے رنگ کا تعین کر سکیں۔
• Metacoins - metacoin کے پیچھے خیال یہ ہے کہ ایک ایسا پروٹوکول ہو جو بٹ کوائن کے اوپر موجود ہو، جو metacoin ٹرانزیکشنز کو اسٹور کرنے کے لیے بٹ کوائن ٹرانزیکشنز کا استعمال کرے لیکن اس کا اسٹیٹ ٹرانزیشن فنکشن مختلف ہو، APPLY'۔ چونکہ metacoin پروٹوکول غلط metacoin ٹرانزیکشنز کو بٹ کوائن بلاک چین میں ظاہر ہونے سے نہیں روک سکتا، اس لیے ایک اصول شامل کیا گیا ہے کہ اگر APPLY'(S,TX) کوئی ایرر لوٹاتا ہے، تو پروٹوکول ڈیفالٹ کے طور پر APPLY'(S,TX) = S پر چلا جاتا ہے۔ یہ ایک صوابدیدی (arbitrary) کریپٹو کرنسی پروٹوکول بنانے کے لیے ایک آسان میکانزم فراہم کرتا ہے، ممکنہ طور پر ایسی جدید خصوصیات کے ساتھ جنہیں خود بٹ کوائن کے اندر نافذ نہیں کیا جا سکتا، لیکن بہت کم ڈیولپمنٹ لاگت کے ساتھ کیونکہ مائننگ اور نیٹ ورکنگ کی پیچیدگیوں کو بٹ کوائن پروٹوکول پہلے ہی سنبھال لیتا ہے۔ Metacoins کو مالیاتی معاہدوں کی کچھ کلاسز، نام کی رجسٹریشن اور ڈی سینٹرلائزڈ ایکسچینج کو نافذ کرنے کے لیے استعمال کیا گیا ہے۔

اس طرح، عام طور پر، کنسینسس پروٹوکول بنانے کے دو طریقے ہیں: ایک آزاد نیٹ ورک بنانا، اور بٹ کوائن کے اوپر ایک پروٹوکول بنانا۔ پہلا طریقہ، اگرچہ Namecoin جیسی ایپلی کیشنز کے معاملے میں معقول حد تک کامیاب ہے، لیکن اسے نافذ کرنا مشکل ہے؛ ہر انفرادی نفاذ کو ایک آزاد بلاک چین کو بوٹ اسٹریپ (bootstrap) کرنے کے ساتھ ساتھ تمام ضروری اسٹیٹ ٹرانزیشن اور نیٹ ورکنگ کوڈ بنانے اور ٹیسٹ کرنے کی ضرورت ہوتی ہے۔ مزید برآں، ہم پیش گوئی کرتے ہیں کہ ڈی سینٹرلائزڈ کنسینسس ٹیکنالوجی کے لیے ایپلی کیشنز کا سیٹ پاور لاء ڈسٹری بیوشن (power law distribution) کی پیروی کرے گا جہاں ایپلی کیشنز کی اکثریت اتنی چھوٹی ہوگی کہ ان کی اپنی بلاک چین کا جواز نہیں بن پائے گا، اور ہم نوٹ کرتے ہیں کہ ڈی سینٹرلائزڈ ایپلی کیشنز کی بڑی کلاسز موجود ہیں، خاص طور پر ڈی سینٹرلائزڈ خود مختار تنظیمیں (decentralized autonomous organizations)، جنہیں ایک دوسرے کے ساتھ بات چیت کرنے کی ضرورت ہوتی ہے۔

دوسری طرف، بٹ کوائن پر مبنی نقطہ نظر میں یہ خامی ہے کہ اسے بٹ کوائن کی سمپلیفائیڈ پیمنٹ ویریفکیشن (SPV) کی خصوصیات وراثت میں نہیں ملتیں۔ SPV بٹ کوائن کے لیے کام کرتا ہے کیونکہ یہ بلاک چین کی گہرائی کو درستگی کے پراکسی کے طور پر استعمال کر سکتا ہے؛ کسی موڑ پر، جب کسی ٹرانزیکشن کے آباؤ اجداد کافی پیچھے چلے جاتے ہیں، تو یہ کہنا محفوظ ہوتا ہے کہ وہ جائز طور پر اسٹیٹ کا حصہ تھے۔ دوسری طرف، بلاک چین پر مبنی میٹا-پروٹوکولز بلاک چین کو مجبور نہیں کر سکتے کہ وہ ایسی ٹرانزیکشنز کو شامل نہ کرے جو ان کے اپنے پروٹوکولز کے تناظر میں درست نہیں ہیں۔ لہذا، ایک مکمل طور پر محفوظ SPV میٹا-پروٹوکول کے نفاذ کو یہ تعین کرنے کے لیے کہ آیا کچھ ٹرانزیکشنز درست ہیں یا نہیں، بٹ کوائن بلاک چین کے آغاز تک بیک ورڈ اسکین (backward scan) کرنے کی ضرورت ہوگی۔ فی الحال، بٹ کوائن پر مبنی میٹا-پروٹوکولز کے تمام "لائٹ" نفاذ ڈیٹا فراہم کرنے کے لیے ایک قابل اعتماد سرور پر انحصار کرتے ہیں، جو بلاشبہ ایک انتہائی غیر تسلی بخش نتیجہ ہے خاص طور پر جب کریپٹو کرنسی کے بنیادی مقاصد میں سے ایک اعتماد کی ضرورت کو ختم کرنا ہے۔

اسکرپٹنگ (Scripting)

یہاں تک کہ کسی بھی ایکسٹینشن کے بغیر، بٹ کوائن پروٹوکول دراصل "اسمارٹ کانٹریکٹس" کے تصور کے ایک کمزور ورژن کی سہولت فراہم کرتا ہے۔ بٹ کوائن میں UTXO کی ملکیت نہ صرف ایک پبلک کی کے پاس ہو سکتی ہے، بلکہ ایک سادہ اسٹیک پر مبنی پروگرامنگ زبان میں ظاہر کیے گئے زیادہ پیچیدہ اسکرپٹ کے پاس بھی ہو سکتی ہے۔ اس پیراڈائم میں، اس UTXO کو خرچ کرنے والی ٹرانزیکشن کو ایسا ڈیٹا فراہم کرنا چاہیے جو اسکرپٹ کو مطمئن کرے۔ درحقیقت، بنیادی پبلک کی ملکیت کا میکانزم بھی ایک اسکرپٹ کے ذریعے نافذ کیا جاتا ہے: اسکرپٹ ایک ایلیپٹک کرو (elliptic curve) دستخط کو ان پٹ کے طور پر لیتا ہے، ٹرانزیکشن اور UTXO کے مالک ایڈریس کے خلاف اس کی تصدیق کرتا ہے، اور اگر تصدیق کامیاب ہو جاتی ہے تو 1 لوٹاتا ہے اور بصورت دیگر 0۔ مختلف اضافی یوز کیسز کے لیے دیگر، زیادہ پیچیدہ، اسکرپٹس موجود ہیں۔ مثال کے طور پر، کوئی ایک ایسا اسکرپٹ بنا سکتا ہے جسے درست ثابت کرنے کے لیے دی گئی تین پرائیویٹ کیز میں سے دو کے دستخط درکار ہوں ("multisig")، یہ سیٹ اپ کارپوریٹ اکاؤنٹس، محفوظ سیونگ اکاؤنٹس اور کچھ مرچنٹ ایسکرو (escrow) حالات کے لیے مفید ہے۔ اسکرپٹس کو کمپیوٹیشنل مسائل کے حل کے لیے باؤنٹیز (bounties) ادا کرنے کے لیے بھی استعمال کیا جا سکتا ہے، اور کوئی ایک ایسا اسکرپٹ بھی بنا سکتا ہے جو کچھ یوں کہے "یہ بٹ کوائن UTXO آپ کا ہے اگر آپ SPV ثبوت فراہم کر سکیں کہ آپ نے مجھے اس مالیت کی Dogecoin ٹرانزیکشن بھیجی ہے"، جو بنیادی طور پر ڈی سینٹرلائزڈ کراس-کریپٹو کرنسی ایکسچینج کی اجازت دیتا ہے۔

تاہم، بٹ کوائن میں نافذ کردہ اسکرپٹنگ زبان کی کئی اہم حدود ہیں:

• ٹیورنگ-کمپلیٹنس (Turing-completeness) کی کمی - یعنی، اگرچہ کمپیوٹیشن کا ایک بڑا سب سیٹ ہے جسے بٹ کوائن اسکرپٹنگ زبان سپورٹ کرتی ہے، لیکن یہ تقریباً ہر چیز کو سپورٹ نہیں کرتی۔ جو اہم کیٹیگری غائب ہے وہ لوپس (loops) ہیں۔ یہ ٹرانزیکشن کی تصدیق کے دوران لامحدود لوپس سے بچنے کے لیے کیا جاتا ہے؛ نظریاتی طور پر یہ اسکرپٹ پروگرامرز کے لیے ایک قابل عبور رکاوٹ ہے، کیونکہ کسی بھی لوپ کو if اسٹیٹمنٹ کے ساتھ بنیادی کوڈ کو کئی بار دہرا کر نقل کیا جا سکتا ہے، لیکن اس سے ایسے اسکرپٹس بنتے ہیں جو اسپیس کے لحاظ سے بہت غیر موثر ہوتے ہیں۔ مثال کے طور پر، ایک متبادل ایلیپٹک کرو دستخطی الگورتھم کو نافذ کرنے کے لیے ممکنہ طور پر 256 بار بار ضرب کے راؤنڈز کی ضرورت ہوگی جو سب انفرادی طور پر کوڈ میں شامل ہوں۔
• ویلیو-بلائنڈنیس (Value-blindness) - UTXO اسکرپٹ کے لیے نکالی جانے والی رقم پر باریک بینی سے کنٹرول فراہم کرنے کا کوئی طریقہ نہیں ہے۔ مثال کے طور پر، اوریکل (oracle) کانٹریکٹ کا ایک طاقتور یوز کیس ہیجنگ (hedging) کانٹریکٹ ہوگا، جہاں A اور B $1000 مالیت کے BTC ڈالتے ہیں اور 30 دنوں کے بعد اسکرپٹ $1000 مالیت کے BTC، A کو اور باقی B کو بھیج دیتا ہے۔ اس کے لیے USD میں 1 BTC کی قدر کا تعین کرنے کے لیے ایک اوریکل کی ضرورت ہوگی، لیکن پھر بھی یہ اب دستیاب مکمل طور پر سینٹرلائزڈ حلوں کے مقابلے میں اعتماد اور انفراسٹرکچر کی ضرورت کے لحاظ سے ایک بہت بڑی بہتری ہے۔ تاہم، چونکہ UTXO آل-آر-نوتھنگ (all-or-nothing) ہوتے ہیں، اس لیے اسے حاصل کرنے کا واحد طریقہ یہ ہے کہ مختلف مالیت کے بہت سے UTXO (مثلاً، 30 تک ہر k کے لیے 2^k کا ایک UTXO) رکھنے کا انتہائی غیر موثر ہیک استعمال کیا جائے اور اوریکل یہ منتخب کرے کہ کون سا UTXO، A کو بھیجنا ہے اور کون سا B کو۔
• اسٹیٹ کی کمی - UTXO یا تو خرچ کیے جا سکتے ہیں یا غیر خرچ شدہ رہ سکتے ہیں؛ ملٹی اسٹیج کانٹریکٹس یا اسکرپٹس کے لیے کوئی موقع نہیں ہے جو اس سے آگے کوئی اور اندرونی اسٹیٹ رکھیں۔ اس سے ملٹی اسٹیج آپشنز کانٹریکٹس، ڈی سینٹرلائزڈ ایکسچینج آفرز یا ٹو-اسٹیج کرپٹوگرافک کمٹمنٹ پروٹوکولز (محفوظ کمپیوٹیشنل باؤنٹیز کے لیے ضروری) بنانا مشکل ہو جاتا ہے۔ اس کا مطلب یہ بھی ہے کہ UTXO کو صرف سادہ، ون-آف (one-off) کانٹریکٹس بنانے کے لیے استعمال کیا جا سکتا ہے نہ کہ زیادہ پیچیدہ "اسٹیٹ فل" (stateful) کانٹریکٹس جیسے ڈی سینٹرلائزڈ تنظیمیں، اور یہ میٹا-پروٹوکولز کو نافذ کرنا مشکل بناتا ہے۔ بائنری اسٹیٹ کے ساتھ ویلیو-بلائنڈنیس کا مطلب یہ بھی ہے کہ ایک اور اہم ایپلی کیشن، رقم نکالنے کی حد (withdrawal limits)، ناممکن ہے۔
• بلاک چین-بلائنڈنیس (Blockchain-blindness) - UTXO بلاک چین ڈیٹا جیسے نانس، ٹائم اسٹیمپ اور پچھلے بلاک ہیش سے ناواقف ہوتے ہیں۔ یہ اسکرپٹنگ زبان کو رینڈمنیس (randomness) کے ممکنہ طور پر قیمتی ذریعہ سے محروم کر کے جوئے، اور کئی دوسری کیٹیگریز میں ایپلی کیشنز کو سختی سے محدود کرتا ہے۔

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

ایتھیریم

ایتھیریم کا مقصد ڈی سینٹرلائزڈ ایپلی کیشنز بنانے کے لیے ایک متبادل پروٹوکول تیار کرنا ہے، جو ٹریڈ آف کا ایک مختلف سیٹ فراہم کرتا ہے جس کے بارے میں ہمارا ماننا ہے کہ یہ ڈی سینٹرلائزڈ ایپلی کیشنز کی ایک بڑی کلاس کے لیے بہت مفید ثابت ہوگا، خاص طور پر ان حالات پر زور دیتے ہوئے جہاں تیز رفتار ڈیولپمنٹ کا وقت، چھوٹی اور شاذ و نادر ہی استعمال ہونے والی ایپلی کیشنز کے لیے سیکیورٹی، اور مختلف ایپلی کیشنز کی انتہائی موثر انداز میں بات چیت کرنے کی صلاحیت اہم ہے۔ ایتھیریم یہ کام ایک ایسی چیز بنا کر کرتا ہے جو بنیادی طور پر حتمی تجریدی (abstract) بنیادی تہہ ہے: ایک بلٹ ان ٹیورنگ-کمپلیٹ (Turing-complete) پروگرامنگ زبان کے ساتھ ایک بلاک چین، جو کسی کو بھی اسمارٹ کانٹریکٹس اور ڈی سینٹرلائزڈ ایپلی کیشنز لکھنے کی اجازت دیتی ہے جہاں وہ ملکیت، ٹرانزیکشن فارمیٹس اور اسٹیٹ ٹرانزیشن فنکشنز کے لیے اپنے من مانے اصول بنا سکتے ہیں۔ Namecoin کا ایک بنیادی ورژن کوڈ کی دو لائنوں میں لکھا جا سکتا ہے، اور کرنسیوں اور ریپوٹیشن سسٹمز جیسے دیگر پروٹوکولز بیس سے کم لائنوں میں بنائے جا سکتے ہیں۔ اسمارٹ کانٹریکٹس، کرپٹوگرافک "باکسز" جن میں ویلیو ہوتی ہے اور وہ اسے صرف اسی صورت میں ان لاک کرتے ہیں جب کچھ شرائط پوری ہوں، انہیں بھی پلیٹ فارم کے اوپر بنایا جا سکتا ہے، جس میں Bitcoin اسکرپٹنگ کی پیش کردہ طاقت سے کہیں زیادہ طاقت ہوتی ہے کیونکہ اس میں ٹیورنگ-کمپلیٹنس، ویلیو-اویئرنس، بلاک چین-اویئرنس اور اسٹیٹ کی اضافی طاقتیں شامل ہوتی ہیں۔

ایتھیریم اکاؤنٹس

ایتھیریم میں، اسٹیٹ "اکاؤنٹس" کہلانے والے آبجیکٹس پر مشتمل ہوتی ہے، جس میں ہر اکاؤنٹ کا 20-بائٹ کا ایڈریس ہوتا ہے اور اسٹیٹ ٹرانزیشنز اکاؤنٹس کے درمیان ویلیو اور معلومات کی براہ راست منتقلی ہوتی ہیں۔ ایک ایتھیریم اکاؤنٹ میں چار فیلڈز ہوتی ہیں:

• nonce، ایک کاؤنٹر جو اس بات کو یقینی بنانے کے لیے استعمال ہوتا ہے کہ ہر ٹرانزیکشن پر صرف ایک بار کارروائی کی جا سکے
• اکاؤنٹ کا موجودہ ایتھر بیلنس
• اکاؤنٹ کا کانٹریکٹ کوڈ، اگر موجود ہو
• اکاؤنٹ کی اسٹوریج (بائی ڈیفالٹ خالی ہوتی ہے)

"ایتھر" ایتھیریم کا بنیادی اندرونی کرپٹو-فیول ہے، اور اسے ٹرانزیکشن فیس ادا کرنے کے لیے استعمال کیا جاتا ہے۔ عام طور پر، اکاؤنٹس کی دو اقسام ہوتی ہیں: ایکسٹرنلی اونڈ اکاؤنٹس (externally owned accounts)، جو پرائیویٹ کیز کے ذریعے کنٹرول کیے جاتے ہیں، اور کانٹریکٹ اکاؤنٹس، جو ان کے کانٹریکٹ کوڈ کے ذریعے کنٹرول کیے جاتے ہیں۔ ایک ایکسٹرنلی اونڈ اکاؤنٹ میں کوئی کوڈ نہیں ہوتا، اور کوئی بھی ٹرانزیکشن بنا کر اور اس پر دستخط کر کے ایکسٹرنلی اونڈ اکاؤنٹ سے پیغامات بھیج سکتا ہے؛ ایک کانٹریکٹ اکاؤنٹ میں، جب بھی کانٹریکٹ اکاؤنٹ کو کوئی پیغام موصول ہوتا ہے تو اس کا کوڈ ایکٹیویٹ ہو جاتا ہے، جس سے وہ اندرونی اسٹوریج کو پڑھنے اور لکھنے اور بدلے میں دوسرے پیغامات بھیجنے یا کانٹریکٹس بنانے کے قابل ہو جاتا ہے۔

واضح رہے کہ ایتھیریم میں "کانٹریکٹس" کو ایسی چیز کے طور پر نہیں دیکھا جانا چاہیے جسے "پورا" کیا جانا چاہیے یا جس کی "تعمیل" کی جانی چاہیے؛ بلکہ، وہ "خودمختار ایجنٹس (autonomous agents)" کی طرح ہیں جو ایتھیریم ایگزیکیوشن انوائرنمنٹ کے اندر رہتے ہیں، جب بھی کسی پیغام یا ٹرانزیکشن کے ذریعے انہیں "پوک (poke)" کیا جاتا ہے تو وہ ہمیشہ کوڈ کا ایک مخصوص حصہ چلاتے ہیں، اور مستقل ویری ایبلز کا ٹریک رکھنے کے لیے ان کا اپنے ایتھر بیلنس اور اپنے کی/ویلیو (key/value) اسٹور پر براہ راست کنٹرول ہوتا ہے۔

پیغامات اور ٹرانزیکشنز

ایتھیریم میں "ٹرانزیکشن" کی اصطلاح اس دستخط شدہ ڈیٹا پیکج کے لیے استعمال ہوتی ہے جو کسی ایکسٹرنلی اونڈ اکاؤنٹ سے بھیجے جانے والے پیغام کو اسٹور کرتا ہے۔ ٹرانزیکشنز میں درج ذیل شامل ہوتے ہیں:

• پیغام وصول کرنے والا
• بھیجنے والے کی شناخت کرنے والا دستخط
• بھیجنے والے سے وصول کنندہ کو منتقل کیے جانے والے ایتھر کی مقدار
• ایک اختیاری ڈیٹا فیلڈ
• ایک STARTGAS ویلیو، جو ان کمپیوٹیشنل مراحل کی زیادہ سے زیادہ تعداد کو ظاہر کرتی ہے جو ٹرانزیکشن کے ایگزیکیوشن کو لینے کی اجازت ہے
• ایک GASPRICE ویلیو، جو اس فیس کو ظاہر کرتی ہے جو بھیجنے والا فی کمپیوٹیشنل مرحلے کے لیے ادا کرتا ہے

پہلی تین معیاری فیلڈز ہیں جن کی کسی بھی کریپٹو کرنسی میں توقع کی جاتی ہے۔ ڈیٹا فیلڈ کا بائی ڈیفالٹ کوئی فنکشن نہیں ہوتا، لیکن ورچوئل مشین میں ایک اوپ کوڈ (opcode) ہوتا ہے جس کا استعمال کرتے ہوئے ایک کانٹریکٹ ڈیٹا تک رسائی حاصل کر سکتا ہے؛ مثال کے طور پر، اگر کوئی کانٹریکٹ آن-بلاک چین ڈومین رجسٹریشن سروس کے طور پر کام کر رہا ہے، تو وہ اسے پاس کیے جانے والے ڈیٹا کی تشریح اس طرح کر سکتا ہے کہ اس میں دو "فیلڈز" شامل ہیں، پہلی فیلڈ رجسٹر کرنے کے لیے ایک ڈومین ہے اور دوسری فیلڈ وہ IP ایڈریس ہے جس پر اسے رجسٹر کرنا ہے۔ کانٹریکٹ پیغام کے ڈیٹا سے ان ویلیوز کو پڑھے گا اور انہیں مناسب طریقے سے اسٹوریج میں رکھے گا۔

STARTGAS اور GASPRICE فیلڈز ایتھیریم کے اینٹی-ڈینائل آف سروس (anti-denial of service) ماڈل کے لیے انتہائی اہم ہیں۔ کوڈ میں حادثاتی یا مخالفانہ لامحدود لوپس (infinite loops) یا دیگر کمپیوٹیشنل ضیاع کو روکنے کے لیے، ہر ٹرانزیکشن کے لیے یہ حد مقرر کرنا ضروری ہے کہ وہ کوڈ ایگزیکیوشن کے کتنے کمپیوٹیشنل مراحل استعمال کر سکتی ہے۔ کمپیوٹیشن کی بنیادی اکائی "گیس (gas)" ہے؛ عام طور پر، ایک کمپیوٹیشنل مرحلے کی قیمت 1 گیس ہوتی ہے، لیکن کچھ آپریشنز پر زیادہ گیس خرچ ہوتی ہے کیونکہ وہ کمپیوٹیشنل طور پر زیادہ مہنگے ہوتے ہیں، یا اس ڈیٹا کی مقدار کو بڑھاتے ہیں جسے اسٹیٹ کے حصے کے طور پر اسٹور کیا جانا چاہیے۔ ٹرانزیکشن ڈیٹا میں ہر بائٹ کے لیے 5 گیس کی فیس بھی ہوتی ہے۔ فیس سسٹم کا مقصد حملہ آور کو ان کے استعمال کردہ ہر وسائل کے لیے متناسب طور پر ادائیگی کرنے کا پابند بنانا ہے، بشمول کمپیوٹیشن، بینڈوتھ اور اسٹوریج؛ لہذا، کوئی بھی ٹرانزیکشن جو نیٹ ورک کو ان میں سے کسی بھی وسائل کی زیادہ مقدار استعمال کرنے کا سبب بنتی ہے، اس کی گیس فیس اس اضافے کے تقریباً متناسب ہونی چاہیے۔

پیغامات

کانٹریکٹس میں دوسرے کانٹریکٹس کو "پیغامات" بھیجنے کی صلاحیت ہوتی ہے۔ پیغامات ورچوئل آبجیکٹس ہوتے ہیں جنہیں کبھی سیریلائز (serialize) نہیں کیا جاتا اور یہ صرف ایتھیریم ایگزیکیوشن انوائرنمنٹ میں موجود ہوتے ہیں۔ ایک پیغام میں درج ذیل شامل ہوتے ہیں:

• پیغام بھیجنے والا (پوشیدہ/implicit)
• پیغام وصول کرنے والا
• پیغام کے ساتھ منتقل کیے جانے والے ایتھر کی مقدار
• ایک اختیاری ڈیٹا فیلڈ
• ایک STARTGAS ویلیو

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

واضح رہے کہ کسی ٹرانزیکشن یا کانٹریکٹ کے ذریعے تفویض کردہ گیس الاؤنس اس ٹرانزیکشن اور تمام ذیلی ایگزیکیوشنز کے ذریعے استعمال ہونے والی کل گیس پر لاگو ہوتا ہے۔ مثال کے طور پر، اگر ایک بیرونی ایکٹر A، 1000 گیس کے ساتھ B کو ٹرانزیکشن بھیجتا ہے، اور B، C کو پیغام بھیجنے سے پہلے 600 گیس استعمال کرتا ہے، اور C کا اندرونی ایگزیکیوشن واپس آنے سے پہلے 300 گیس استعمال کرتا ہے، تو B گیس ختم ہونے سے پہلے مزید 100 گیس خرچ کر سکتا ہے۔

ایتھیریم اسٹیٹ ٹرانزیشن فنکشن

ایتھیریم اسٹیٹ ٹرانزیشن فنکشن، APPLY(S,TX) -> S' کی تعریف اس طرح کی جا سکتی ہے:

1. چیک کریں کہ آیا ٹرانزیکشن درست طریقے سے بنی ہے (یعنی اس میں ویلیوز کی صحیح تعداد ہے)، دستخط درست ہے، اور nonce بھیجنے والے کے اکاؤنٹ میں موجود nonce سے میل کھاتا ہے۔ اگر نہیں، تو ایک ایرر (error) واپس کریں۔
2. ٹرانزیکشن فیس کا حساب STARTGAS * GASPRICE کے طور پر لگائیں، اور دستخط سے بھیجنے والے کا ایڈریس معلوم کریں۔ بھیجنے والے کے اکاؤنٹ بیلنس سے فیس منہا کریں اور بھیجنے والے کے nonce میں اضافہ کریں۔ اگر خرچ کرنے کے لیے کافی بیلنس نہیں ہے، تو ایک ایرر واپس کریں۔
3. GAS = STARTGAS کو انیشلائز (initialize) کریں، اور ٹرانزیکشن میں بائٹس کی ادائیگی کے لیے فی بائٹ گیس کی ایک خاص مقدار نکال لیں۔
4. ٹرانزیکشن ویلیو کو بھیجنے والے کے اکاؤنٹ سے وصول کرنے والے اکاؤنٹ میں منتقل کریں۔ اگر وصول کرنے والا اکاؤنٹ ابھی تک موجود نہیں ہے، تو اسے بنائیں۔ اگر وصول کرنے والا اکاؤنٹ ایک کانٹریکٹ ہے، تو کانٹریکٹ کا کوڈ یا تو مکمل ہونے تک چلائیں یا اس وقت تک چلائیں جب تک کہ ایگزیکیوشن کی گیس ختم نہ ہو جائے۔
5. اگر ویلیو کی منتقلی ناکام ہو گئی کیونکہ بھیجنے والے کے پاس کافی رقم نہیں تھی، یا کوڈ ایگزیکیوشن کی گیس ختم ہو گئی، تو فیس کی ادائیگی کے علاوہ تمام اسٹیٹ تبدیلیوں کو ریورٹ (revert) کر دیں، اور فیس کو مائنر کے اکاؤنٹ میں شامل کریں۔
6. بصورت دیگر، تمام باقی ماندہ گیس کی فیس بھیجنے والے کو واپس کر دیں، اور استعمال شدہ گیس کے لیے ادا کی گئی فیس مائنر کو بھیج دیں۔

مثال کے طور پر، فرض کریں کہ کانٹریکٹ کا کوڈ یہ ہے:

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

واضح رہے کہ حقیقت میں کانٹریکٹ کوڈ لو-لیول EVM کوڈ میں لکھا جاتا ہے؛ یہ مثال وضاحت کے لیے ہماری ہائی-لیول زبانوں میں سے ایک، Serpent میں لکھی گئی ہے، اور اسے EVM کوڈ میں کمپائل کیا جا سکتا ہے۔ فرض کریں کہ کانٹریکٹ کی اسٹوریج خالی شروع ہوتی ہے، اور ایک ٹرانزیکشن 10 ایتھر ویلیو، 2000 گیس، 0.001 ایتھر گیس پرائس، اور 64 بائٹس ڈیٹا کے ساتھ بھیجی جاتی ہے، جس میں بائٹس 0-31 نمبر 2 کی نمائندگی کرتے ہیں اور بائٹس 32-63 اسٹرنگ CHARLIE کی نمائندگی کرتے ہیں۔ اس صورت میں اسٹیٹ ٹرانزیشن فنکشن کا عمل درج ذیل ہے:

1. چیک کریں کہ ٹرانزیکشن درست اور صحیح طریقے سے بنی ہے۔
2. چیک کریں کہ ٹرانزیکشن بھیجنے والے کے پاس کم از کم 2000 * 0.001 = 2 ایتھر ہیں۔ اگر ایسا ہے، تو بھیجنے والے کے اکاؤنٹ سے 2 ایتھر منہا کریں۔
3. gas = 2000 کو انیشلائز کریں؛ یہ فرض کرتے ہوئے کہ ٹرانزیکشن 170 بائٹس طویل ہے اور بائٹ-فیس 5 ہے، 850 منہا کریں تاکہ 1150 گیس باقی بچے۔
4. بھیجنے والے کے اکاؤنٹ سے مزید 10 ایتھر منہا کریں، اور اسے کانٹریکٹ کے اکاؤنٹ میں شامل کریں۔
5. کوڈ چلائیں۔ اس صورت میں، یہ آسان ہے: یہ چیک کرتا ہے کہ آیا انڈیکس 2 پر کانٹریکٹ کی اسٹوریج استعمال ہوئی ہے، دیکھتا ہے کہ ایسا نہیں ہے، اور اس لیے یہ انڈیکس 2 پر اسٹوریج کو CHARLIE ویلیو پر سیٹ کر دیتا ہے۔ فرض کریں کہ اس میں 187 گیس لگتی ہے، لہذا گیس کی باقی ماندہ مقدار 1150 - 187 = 963 ہے۔
6. بھیجنے والے کے اکاؤنٹ میں 963 * 0.001 = 0.963 ایتھر واپس شامل کریں، اور نتیجے میں آنے والی اسٹیٹ واپس کریں۔

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

واضح رہے کہ پیغامات ریورٹس (reverts) کے لحاظ سے ٹرانزیکشنز کے مساوی کام کرتے ہیں: اگر کسی پیغام کے ایگزیکیوشن کی گیس ختم ہو جاتی ہے، تو اس پیغام کا ایگزیکیوشن، اور اس ایگزیکیوشن کے ذریعے متحرک ہونے والے دیگر تمام ایگزیکیوشنز ریورٹ ہو جاتے ہیں، لیکن پیرنٹ (parent) ایگزیکیوشنز کو ریورٹ ہونے کی ضرورت نہیں ہوتی۔ اس کا مطلب ہے کہ ایک کانٹریکٹ کے لیے دوسرے کانٹریکٹ کو کال کرنا "محفوظ" ہے، کیونکہ اگر A، G گیس کے ساتھ B کو کال کرتا ہے تو A کے ایگزیکیوشن میں زیادہ سے زیادہ G گیس ضائع ہونے کی ضمانت ہوتی ہے۔ آخر میں، واضح رہے کہ ایک اوپ کوڈ، CREATE ہے، جو ایک کانٹریکٹ بناتا ہے؛ اس کے ایگزیکیوشن کا طریقہ کار عام طور پر CALL سے ملتا جلتا ہے، سوائے اس کے کہ ایگزیکیوشن کا آؤٹ پٹ نئے بنائے گئے کانٹریکٹ کے کوڈ کا تعین کرتا ہے۔

کوڈ ایگزیکیوشن

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

• اسٹیک (stack)، ایک لاسٹ-ان-فرسٹ-آؤٹ (last-in-first-out) کنٹینر جس میں ویلیوز کو پش (push) اور پاپ (pop) کیا جا سکتا ہے
• میموری (Memory)، ایک لامحدود طور پر قابل توسیع بائٹ سرنی (byte array)
• کانٹریکٹ کی طویل مدتی اسٹوریج، ایک کی/ویلیو (key/value) اسٹور۔ اسٹیک اور میموری کے برعکس، جو کمپیوٹیشن ختم ہونے کے بعد ری سیٹ ہو جاتے ہیں، اسٹوریج طویل مدت تک برقرار رہتی ہے۔

کوڈ آنے والے پیغام کی ویلیو، بھیجنے والے اور ڈیٹا کے ساتھ ساتھ بلاک ہیڈر ڈیٹا تک بھی رسائی حاصل کر سکتا ہے، اور کوڈ آؤٹ پٹ کے طور پر ڈیٹا کی بائٹ سرنی (byte array) بھی واپس کر سکتا ہے۔

EVM کوڈ کا رسمی ایگزیکیوشن ماڈل حیران کن حد تک آسان ہے۔ جب ایتھیریم ورچوئل مشین چل رہی ہوتی ہے، تو اس کی مکمل کمپیوٹیشنل اسٹیٹ کی تعریف ٹوپل (tuple) (block_state, transaction, message, code, memory, stack, pc, gas) کے ذریعے کی جا سکتی ہے، جہاں block_state وہ عالمی اسٹیٹ ہے جس میں تمام اکاؤنٹس شامل ہوتے ہیں اور اس میں بیلنس اور اسٹوریج شامل ہوتی ہے۔ ایگزیکیوشن کے ہر راؤنڈ کے آغاز میں، موجودہ ہدایت code کا pcواں بائٹ لے کر تلاش کی جاتی ہے (یا 0 اگر pc >= len(code) ہو)، اور ہر ہدایت کی اپنی تعریف ہوتی ہے کہ یہ ٹوپل کو کیسے متاثر کرتی ہے۔ مثال کے طور پر، ADD اسٹیک سے دو آئٹمز کو پاپ کرتا ہے اور ان کے مجموعے کو پش کرتا ہے، gas کو 1 سے کم کرتا ہے اور pc میں 1 کا اضافہ کرتا ہے، اور SSTORE اسٹیک سے اوپر والے دو آئٹمز کو پاپ کرتا ہے اور دوسرے آئٹم کو پہلے آئٹم کے ذریعے بتائے گئے انڈیکس پر کانٹریکٹ کی اسٹوریج میں داخل کرتا ہے۔ اگرچہ جسٹ-ان-ٹائم (just-in-time) کمپائلیشن کے ذریعے ایتھیریم ورچوئل مشین کے ایگزیکیوشن کو بہتر بنانے کے بہت سے طریقے ہیں، لیکن ایتھیریم کا بنیادی نفاذ کوڈ کی چند سو لائنوں میں کیا جا سکتا ہے۔

بلاک چین اور مائننگ

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

1. چیک کریں کہ آیا حوالہ دیا گیا پچھلا بلاک موجود ہے اور درست ہے۔
2. چیک کریں کہ بلاک کا ٹائم اسٹیمپ حوالہ دیے گئے پچھلے بلاک سے زیادہ ہے اور مستقبل میں 15 منٹ سے کم ہے۔
3. چیک کریں کہ بلاک نمبر، مشکل، ٹرانزیکشن روٹ، انکل روٹ (uncle root) اور گیس کی حد (مختلف لو-لیول ایتھیریم کے مخصوص تصورات) درست ہیں۔
4. چیک کریں کہ بلاک پر پروف-آف-ورک (proof-of-work) درست ہے۔
5. فرض کریں کہ S[0] پچھلے بلاک کے اختتام پر اسٹیٹ ہے۔
6. فرض کریں کہ TX بلاک کی ٹرانزیکشن لسٹ ہے، جس میں n ٹرانزیکشنز ہیں۔ 0...n-1 میں تمام i کے لیے، S[i+1] = APPLY(S[i],TX[i]) سیٹ کریں۔ اگر کوئی ایپلی کیشن ایرر واپس کرتی ہے، یا اگر اس مقام تک بلاک میں استعمال ہونے والی کل گیس GASLIMIT سے تجاوز کر جاتی ہے، تو ایک ایرر واپس کریں۔
7. فرض کریں کہ S_FINAL، S[n] ہے، لیکن اس میں مائنر کو ادا کیا جانے والا بلاک انعام شامل ہے۔
8. چیک کریں کہ آیا اسٹیٹ S_FINAL کا مرکل ٹری روٹ (Merkle tree root) بلاک ہیڈر میں فراہم کردہ حتمی اسٹیٹ روٹ کے برابر ہے۔ اگر ایسا ہے، تو بلاک درست ہے؛ بصورت دیگر، یہ درست نہیں ہے۔

یہ نقطہ نظر پہلی نظر میں انتہائی غیر موثر لگ سکتا ہے، کیونکہ اسے ہر بلاک کے ساتھ پوری اسٹیٹ کو اسٹور کرنے کی ضرورت ہوتی ہے، لیکن حقیقت میں کارکردگی Bitcoin کے مقابلے کی ہونی چاہیے۔ اس کی وجہ یہ ہے کہ اسٹیٹ کو ٹری (tree) کے ڈھانچے میں اسٹور کیا جاتا ہے، اور ہر بلاک کے بعد ٹری کے صرف ایک چھوٹے سے حصے کو تبدیل کرنے کی ضرورت ہوتی ہے۔ اس طرح، عام طور پر، دو ملحقہ بلاکس کے درمیان ٹری کی اکثریت یکساں ہونی چاہیے، اور اس لیے ڈیٹا کو ایک بار اسٹور کیا جا سکتا ہے اور پوائنٹرز (یعنی ذیلی ٹریز کے ہیشز) کا استعمال کرتے ہوئے دو بار حوالہ دیا جا سکتا ہے۔ اسے پورا کرنے کے لیے ایک خاص قسم کا ٹری جسے "پیٹریشیا ٹری (Patricia tree)" کہا جاتا ہے استعمال کیا جاتا ہے، جس میں مرکل ٹری کے تصور میں ایک ترمیم شامل ہے جو نوڈس کو موثر طریقے سے داخل کرنے اور حذف کرنے کی اجازت دیتی ہے، نہ کہ صرف تبدیل کرنے کی۔ مزید برآں، چونکہ اسٹیٹ کی تمام معلومات آخری بلاک کا حصہ ہوتی ہیں، اس لیے پوری بلاک چین کی تاریخ کو اسٹور کرنے کی ضرورت نہیں ہے - ایک ایسی حکمت عملی جس کا اگر Bitcoin پر اطلاق کیا جا سکے، تو حساب لگایا جا سکتا ہے کہ یہ جگہ میں 5-20 گنا بچت فراہم کرے گی۔

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

ایپلی کیشنز

عام طور پر، Ethereum کے اوپر تین قسم کی ایپلی کیشنز ہوتی ہیں۔ پہلی کیٹیگری مالیاتی ایپلی کیشنز کی ہے، جو صارفین کو اپنے پیسوں کا استعمال کرتے ہوئے معاہدوں کا انتظام کرنے اور ان میں داخل ہونے کے زیادہ طاقتور طریقے فراہم کرتی ہے۔ اس میں ذیلی کرنسیاں (sub-currencies)، مالیاتی مشتقات (financial derivatives)، ہیجنگ معاہدے (hedging contracts)، بچت کے بٹوے (savings wallets)، وصیتیں، اور بالآخر مکمل روزگار کے معاہدوں کی کچھ کلاسیں بھی شامل ہیں۔ دوسری کیٹیگری نیم مالیاتی ایپلی کیشنز کی ہے، جہاں پیسہ شامل ہوتا ہے لیکن جو کچھ کیا جا رہا ہے اس کا ایک بھاری غیر مالیاتی پہلو بھی ہوتا ہے؛ اس کی ایک بہترین مثال کمپیوٹیشنل مسائل کے حل کے لیے خودکار نفاذ والے انعامات (self-enforcing bounties) ہیں۔ آخر میں، آن لائن ووٹنگ اور ڈی سینٹرلائزڈ گورننس جیسی ایپلی کیشنز ہیں جو بالکل بھی مالیاتی نہیں ہیں۔

ٹوکن سسٹمز

آن-بلاک چین ٹوکن سسٹمز کی بہت سی ایپلی کیشنز ہیں جن میں USD یا سونے جیسے اثاثوں کی نمائندگی کرنے والی ذیلی کرنسیوں سے لے کر کمپنی کے اسٹاکس، سمارٹ پراپرٹی کی نمائندگی کرنے والے انفرادی ٹوکنز، محفوظ ناقابلِ جعل سازی کوپنز، اور یہاں تک کہ ایسے ٹوکن سسٹمز بھی شامل ہیں جن کا روایتی قدر سے کوئی تعلق نہیں ہوتا، اور انہیں ترغیب دینے کے لیے پوائنٹ سسٹمز کے طور پر استعمال کیا جاتا ہے۔ Ethereum میں ٹوکن سسٹمز کو نافذ کرنا حیرت انگیز طور پر آسان ہے۔ سمجھنے کا اہم نکتہ یہ ہے کہ ایک کرنسی، یا ٹوکن سسٹم، بنیادی طور پر صرف ایک ڈیٹا بیس ہے جس میں ایک آپریشن ہوتا ہے: A سے X یونٹس کو منہا کریں اور B کو X یونٹس دیں، اس شرط کے ساتھ کہ (i) ٹرانزیکشن سے پہلے A کے پاس کم از کم X یونٹس تھے اور (2) ٹرانزیکشن A کی طرف سے منظور شدہ ہے۔ ٹوکن سسٹم کو نافذ کرنے کے لیے بس اس لاجک کو ایک سمارٹ کنٹریکٹ میں نافذ کرنے کی ضرورت ہوتی ہے۔

Serpent میں ٹوکن سسٹم کو نافذ کرنے کا بنیادی کوڈ کچھ یوں نظر آتا ہے:

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

یہ بنیادی طور پر اس دستاویز میں اوپر بیان کردہ "بینکنگ سسٹم" کے سٹیٹ ٹرانزیشن فنکشن (state transition function) کا لفظی نفاذ ہے۔ کرنسی یونٹس کو تقسیم کرنے کے ابتدائی مرحلے اور کچھ دیگر ایج کیسز (edge cases) کے لیے کوڈ کی چند اضافی لائنیں شامل کرنے کی ضرورت ہے، اور مثالی طور پر ایک فنکشن شامل کیا جائے گا تاکہ دیگر کنٹریکٹس کسی ایڈریس کے بیلنس کے بارے میں استفسار کر سکیں۔ لیکن بس اتنا ہی کرنا ہوتا ہے۔ نظریاتی طور پر، ذیلی کرنسیوں کے طور پر کام کرنے والے Ethereum پر مبنی ٹوکن سسٹمز میں ممکنہ طور پر ایک اور اہم خصوصیت شامل ہو سکتی ہے جس کی آن چین Bitcoin پر مبنی میٹا کرنسیوں میں کمی ہے: ٹرانزیکشن فیس براہ راست اسی کرنسی میں ادا کرنے کی صلاحیت۔ اس کو نافذ کرنے کا طریقہ یہ ہوگا کہ کنٹریکٹ ایک ether بیلنس برقرار رکھے گا جس کے ساتھ وہ بھیجنے والے کو فیس ادا کرنے کے لیے استعمال ہونے والے ether کو ریفنڈ کرے گا، اور یہ فیس میں لی جانے والی اندرونی کرنسی یونٹس کو جمع کر کے اور انہیں مسلسل چلنے والی نیلامی میں دوبارہ فروخت کر کے اس بیلنس کو دوبارہ بھرے گا۔ اس طرح صارفین کو اپنے اکاؤنٹس کو ether کے ساتھ "ایکٹیویٹ" کرنے کی ضرورت ہوگی، لیکن ایک بار جب ether وہاں موجود ہو تو یہ دوبارہ قابل استعمال ہوگا کیونکہ کنٹریکٹ اسے ہر بار ریفنڈ کر دے گا۔

مالیاتی مشتقات اور مستحکم قدر والی کرنسیاں

مالیاتی مشتقات (Financial derivatives) "سمارٹ کنٹریکٹ" کی سب سے عام ایپلی کیشن ہیں، اور کوڈ میں نافذ کرنے کے لیے سب سے آسان میں سے ایک ہیں۔ مالیاتی کنٹریکٹس کو نافذ کرنے میں سب سے بڑا چیلنج یہ ہے کہ ان میں سے اکثریت کو بیرونی پرائس ٹکر (price ticker) کے حوالے کی ضرورت ہوتی ہے؛ مثال کے طور پر، ایک انتہائی مطلوبہ ایپلی کیشن ایک ایسا سمارٹ کنٹریکٹ ہے جو امریکی ڈالر کے مقابلے میں ether (یا کسی اور کریپٹو کرنسی) کے اتار چڑھاؤ کے خلاف ہیج (hedge) کرتا ہے، لیکن ایسا کرنے کے لیے کنٹریکٹ کو یہ جاننے کی ضرورت ہوتی ہے کہ ETH/USD کی قدر کیا ہے۔ ایسا کرنے کا سب سے آسان طریقہ ایک مخصوص فریق (جیسے، NASDAQ) کے زیر انتظام "ڈیٹا فیڈ" کنٹریکٹ کے ذریعے ہے جسے اس طرح ڈیزائن کیا گیا ہو کہ اس فریق کے پاس ضرورت کے مطابق کنٹریکٹ کو اپ ڈیٹ کرنے کی صلاحیت ہو، اور ایک ایسا انٹرفیس فراہم کیا جائے جو دوسرے کنٹریکٹس کو اس کنٹریکٹ کو پیغام بھیجنے اور قیمت فراہم کرنے والا جواب واپس حاصل کرنے کی اجازت دے۔

اس اہم جزو کو مدنظر رکھتے ہوئے، ہیجنگ کنٹریکٹ کچھ یوں نظر آئے گا:

1. فریق A کی طرف سے 1000 ether داخل کرنے کا انتظار کریں۔
2. فریق B کی طرف سے 1000 ether داخل کرنے کا انتظار کریں۔
3. 1000 ether کی USD قدر کو سٹوریج میں ریکارڈ کریں، جس کا حساب ڈیٹا فیڈ کنٹریکٹ سے استفسار کر کے لگایا گیا ہو، فرض کریں کہ یہ $x ہے۔
4. 30 دنوں کے بعد، A یا B کو کنٹریکٹ کو "دوبارہ فعال" کرنے کی اجازت دیں تاکہ A کو $x مالیت کا ether (نئی قیمت حاصل کرنے کے لیے ڈیٹا فیڈ کنٹریکٹ سے دوبارہ استفسار کر کے حساب لگایا گیا) اور باقی B کو بھیجا جا سکے۔

اس طرح کے کنٹریکٹ میں کریپٹو کامرس میں نمایاں صلاحیت ہوگی۔ کریپٹو کرنسی کے بارے میں بتائے گئے اہم مسائل میں سے ایک یہ حقیقت ہے کہ یہ غیر مستحکم (volatile) ہے؛ اگرچہ بہت سے صارفین اور تاجر کرپٹوگرافک اثاثوں کے ساتھ لین دین کی سیکیورٹی اور سہولت چاہ سکتے ہیں، لیکن وہ ایک ہی دن میں اپنے فنڈز کی قدر کا 23% کھونے کے امکان کا سامنا نہیں کرنا چاہیں گے۔ اب تک، سب سے زیادہ تجویز کردہ حل جاری کنندہ کی حمایت یافتہ اثاثے (issuer-backed assets) رہا ہے؛ خیال یہ ہے کہ ایک جاری کنندہ ایک ذیلی کرنسی بناتا ہے جس میں اسے یونٹس جاری کرنے اور منسوخ کرنے کا حق حاصل ہوتا ہے، اور وہ کرنسی کا ایک یونٹ ہر اس شخص کو فراہم کرتا ہے جو انہیں (آف لائن) ایک مخصوص بنیادی اثاثے (جیسے، سونا، USD) کا ایک یونٹ فراہم کرتا ہے۔ پھر جاری کنندہ ہر اس شخص کو بنیادی اثاثے کا ایک یونٹ فراہم کرنے کا وعدہ کرتا ہے جو کرپٹو اثاثے کا ایک یونٹ واپس بھیجتا ہے۔ یہ طریقہ کار کسی بھی غیر کرپٹوگرافک اثاثے کو کرپٹوگرافک اثاثے میں "اپ لفٹ" کرنے کی اجازت دیتا ہے، بشرطیکہ جاری کنندہ پر بھروسہ کیا جا سکے۔

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

شناخت اور ساکھ کے سسٹمز

سب سے ابتدائی متبادل کریپٹو کرنسی، Namecoin (opens in a new tab)، نے نام کے اندراج کا نظام فراہم کرنے کے لیے Bitcoin جیسی بلاک چین استعمال کرنے کی کوشش کی، جہاں صارفین دیگر ڈیٹا کے ساتھ ایک عوامی ڈیٹا بیس میں اپنے نام رجسٹر کر سکتے ہیں۔ اس کا سب سے بڑا استعمال DNS (opens in a new tab) سسٹم کے لیے بتایا گیا ہے، جو "bitcoin.org" (یا، Namecoin کے معاملے میں، "bitcoin.bit") جیسے ڈومین ناموں کو IP ایڈریس سے میپ کرتا ہے۔ دیگر استعمالات میں ای میل کی تصدیق اور ممکنہ طور پر زیادہ جدید ساکھ کے سسٹمز (reputation systems) شامل ہیں۔ Ethereum پر Namecoin جیسا نام کے اندراج کا نظام فراہم کرنے کے لیے بنیادی کنٹریکٹ یہ ہے:

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

یہ کنٹریکٹ بہت سادہ ہے؛ یہ Ethereum نیٹ ورک کے اندر صرف ایک ڈیٹا بیس ہے جس میں اضافہ کیا جا سکتا ہے، لیکن اس میں ترمیم یا اسے ہٹایا نہیں جا سکتا۔ کوئی بھی شخص کسی قدر کے ساتھ نام رجسٹر کر سکتا ہے، اور پھر وہ رجسٹریشن ہمیشہ کے لیے قائم رہتی ہے۔ ایک زیادہ نفیس نام کے اندراج کے کنٹریکٹ میں ایک "فنکشن کلاز" بھی ہوگی جو دوسرے کنٹریکٹس کو اس سے استفسار کرنے کی اجازت دے گی، نیز کسی نام کے "مالک" (یعنی پہلا رجسٹر کرنے والا) کے لیے ڈیٹا کو تبدیل کرنے یا ملکیت منتقل کرنے کا طریقہ کار بھی ہوگا۔ کوئی بھی اس کے اوپر ساکھ اور ویب آف ٹرسٹ (web-of-trust) کی فعالیت بھی شامل کر سکتا ہے۔

ڈی سینٹرلائزڈ فائل سٹوریج

پچھلے چند سالوں کے دوران، کئی مقبول آن لائن فائل سٹوریج سٹارٹ اپس ابھرے ہیں، جن میں سب سے نمایاں Dropbox ہے، جو صارفین کو اپنی ہارڈ ڈرائیو کا بیک اپ اپ لوڈ کرنے کی اجازت دینے کی کوشش کر رہے ہیں اور سروس اس بیک اپ کو سٹور کرتی ہے اور ماہانہ فیس کے بدلے صارف کو اس تک رسائی کی اجازت دیتی ہے۔ تاہم، اس وقت فائل سٹوریج مارکیٹ بعض اوقات نسبتاً غیر موثر ہوتی ہے؛ مختلف موجودہ حلوں پر ایک سرسری نظر ڈالنے سے پتہ چلتا ہے کہ، خاص طور پر "uncanny valley" 20-200 GB کی سطح پر جہاں نہ تو مفت کوٹہ اور نہ ہی انٹرپرائز لیول کی چھوٹ لاگو ہوتی ہے، مین اسٹریم فائل سٹوریج کے اخراجات کی ماہانہ قیمتیں ایسی ہیں کہ آپ ایک ہی مہینے میں پوری ہارڈ ڈرائیو کی قیمت سے زیادہ ادائیگی کر رہے ہوتے ہیں۔ Ethereum کنٹریکٹس ایک ڈی سینٹرلائزڈ فائل سٹوریج ایکو سسٹم کی ترقی کی اجازت دے سکتے ہیں، جہاں انفرادی صارفین اپنی ہارڈ ڈرائیوز کرائے پر دے کر تھوڑی مقدار میں پیسہ کما سکتے ہیں اور غیر استعمال شدہ جگہ کو فائل سٹوریج کے اخراجات کو مزید کم کرنے کے لیے استعمال کیا جا سکتا ہے۔

اس طرح کے آلے کا کلیدی بنیادی حصہ وہ ہوگا جسے ہم نے "ڈی سینٹرلائزڈ ڈراپ باکس کنٹریکٹ" کا نام دیا ہے۔ یہ کنٹریکٹ اس طرح کام کرتا ہے۔ سب سے پہلے، مطلوبہ ڈیٹا کو بلاکس میں تقسیم کیا جاتا ہے، پرائیویسی کے لیے ہر بلاک کو انکرپٹ کیا جاتا ہے، اور اس سے ایک Merkle ٹری بنایا جاتا ہے۔ پھر ایک کنٹریکٹ اس اصول کے ساتھ بنایا جاتا ہے کہ، ہر N بلاکس کے بعد، کنٹریکٹ Merkle ٹری میں ایک بے ترتیب انڈیکس کا انتخاب کرے گا (پچھلے بلاک ہیش کا استعمال کرتے ہوئے، جو کنٹریکٹ کوڈ سے قابل رسائی ہے، بے ترتیب پن کے ذریعہ کے طور پر)، اور اس پہلی ہستی کو X ether دے گا جو ٹری میں اس مخصوص انڈیکس پر بلاک کی ملکیت کا آسان ادائیگی کی تصدیق (simplified payment verification) جیسا ثبوت فراہم کرے۔ جب کوئی صارف اپنی فائل کو دوبارہ ڈاؤن لوڈ کرنا چاہتا ہے، تو وہ فائل کو بازیافت کرنے کے لیے مائیکرو پیمنٹ چینل پروٹوکول (مثلاً، 32 کلو بائٹس کے لیے 1 szabo ادا کریں) استعمال کر سکتا ہے؛ فیس کے لحاظ سے سب سے موثر طریقہ یہ ہے کہ ادائیگی کرنے والا ٹرانزیکشن کو آخر تک شائع نہ کرے، بلکہ ہر 32 کلو بائٹس کے بعد اسی نانس (nonce) کے ساتھ ٹرانزیکشن کو قدرے زیادہ منافع بخش ٹرانزیکشن سے بدل دے۔

پروٹوکول کی ایک اہم خصوصیت یہ ہے کہ، اگرچہ ایسا لگ سکتا ہے کہ کوئی بہت سے بے ترتیب نوڈس پر بھروسہ کر رہا ہے کہ وہ فائل کو بھولنے کا فیصلہ نہیں کریں گے، لیکن کوئی بھی شخص خفیہ شیئرنگ (secret sharing) کے ذریعے فائل کو کئی ٹکڑوں میں تقسیم کر کے، اور کنٹریکٹس کو دیکھ کر کہ ہر ٹکڑا اب بھی کسی نوڈ کے قبضے میں ہے، اس خطرے کو تقریباً صفر تک کم کر سکتا ہے۔ اگر کوئی کنٹریکٹ اب بھی پیسے ادا کر رہا ہے، تو یہ ایک کرپٹوگرافک ثبوت فراہم کرتا ہے کہ کوئی نہ کوئی اب بھی فائل کو سٹور کر رہا ہے۔

ڈی سینٹرلائزڈ خود مختار تنظیمیں

"ڈی سینٹرلائزڈ خود مختار تنظیم" (DAO) کا عمومی تصور ایک ایسی ورچوئل ہستی کا ہے جس کے اراکین یا شیئر ہولڈرز کا ایک مخصوص سیٹ ہوتا ہے جنہیں، شاید 67% اکثریت کے ساتھ، ہستی کے فنڈز خرچ کرنے اور اس کے کوڈ میں ترمیم کرنے کا حق حاصل ہوتا ہے۔ اراکین اجتماعی طور پر فیصلہ کریں گے کہ تنظیم کو اپنے فنڈز کیسے مختص کرنے چاہئیں۔ DAO کے فنڈز مختص کرنے کے طریقوں میں انعامات، تنخواہوں سے لے کر کام کا صلہ دینے کے لیے اندرونی کرنسی جیسے مزید غیر معمولی طریقہ کار شامل ہو سکتے ہیں۔ یہ بنیادی طور پر ایک روایتی کمپنی یا غیر منافع بخش تنظیم کے قانونی ڈھانچے کی نقل کرتا ہے لیکن نفاذ کے لیے صرف کرپٹوگرافک بلاک چین ٹیکنالوجی کا استعمال کرتا ہے۔ اب تک DAOs کے بارے میں زیادہ تر بات چیت منافع وصول کرنے والے شیئر ہولڈرز اور قابلِ تجارت حصص کے ساتھ "ڈی سینٹرلائزڈ خود مختار کارپوریشن" (DAC) کے "سرمایہ دارانہ" ماڈل کے گرد گھومتی رہی ہے؛ ایک متبادل، جسے شاید "ڈی سینٹرلائزڈ خود مختار کمیونٹی" کے طور پر بیان کیا جا سکتا ہے، اس میں تمام اراکین کا فیصلہ سازی میں مساوی حصہ ہوگا اور کسی رکن کو شامل کرنے یا ہٹانے کے لیے موجودہ اراکین کے 67% کی رضامندی درکار ہوگی۔ یہ شرط کہ ایک شخص کے پاس صرف ایک رکنیت ہو سکتی ہے، پھر گروپ کی طرف سے اجتماعی طور پر نافذ کرنے کی ضرورت ہوگی۔

DAO کو کوڈ کرنے کے طریقہ کار کا عمومی خاکہ کچھ یوں ہے۔ سب سے آسان ڈیزائن محض خودکار ترمیم کرنے والے کوڈ کا ایک ٹکڑا ہے جو اس وقت تبدیل ہوتا ہے جب دو تہائی اراکین کسی تبدیلی پر متفق ہوں۔ اگرچہ کوڈ نظریاتی طور پر ناقابلِ تغیر (immutable) ہے، لیکن کوئی بھی آسانی سے اس سے بچ سکتا ہے اور کوڈ کے حصوں کو الگ الگ کنٹریکٹس میں رکھ کر، اور کن کنٹریکٹس کو کال کرنا ہے ان کا ایڈریس قابلِ ترمیم سٹوریج میں محفوظ کر کے ڈی فیکٹو (de-facto) تغیر پذیری حاصل کر سکتا ہے۔ اس طرح کے DAO کنٹریکٹ کے ایک سادہ نفاذ میں، ٹرانزیکشن میں فراہم کردہ ڈیٹا کی بنیاد پر ممتاز، تین قسم کی ٹرانزیکشنز ہوں گی:

• [0,i,K,V] سٹوریج انڈیکس K پر ایڈریس کو ویلیو V میں تبدیل کرنے کے لیے انڈیکس i کے ساتھ ایک تجویز رجسٹر کرنے کے لیے
• [1,i] تجویز i کے حق میں ووٹ رجسٹر کرنے کے لیے
• [2,i] اگر کافی ووٹ ڈالے جا چکے ہوں تو تجویز i کو حتمی شکل دینے کے لیے

پھر کنٹریکٹ میں ان میں سے ہر ایک کے لیے شقیں ہوں گی۔ یہ تمام کھلی سٹوریج تبدیلیوں کا ریکارڈ برقرار رکھے گا، اس فہرست کے ساتھ کہ کس نے ان کے لیے ووٹ دیا۔ اس میں تمام اراکین کی فہرست بھی ہوگی۔ جب کسی بھی سٹوریج کی تبدیلی کو دو تہائی اراکین کا ووٹ مل جاتا ہے، تو ایک حتمی ٹرانزیکشن اس تبدیلی کو نافذ کر سکتی ہے۔ ایک زیادہ نفیس ڈھانچے میں ٹرانزیکشن بھیجنے، اراکین کو شامل کرنے اور اراکین کو ہٹانے جیسی خصوصیات کے لیے بلٹ ان ووٹنگ کی صلاحیت بھی ہوگی، اور یہاں تک کہ Liquid Democracy (opens in a new tab) طرز کی ووٹ کی تفویض (یعنی، کوئی بھی شخص کسی کو اپنی طرف سے ووٹ دینے کے لیے مقرر کر سکتا ہے، اور یہ تفویض متعدی (transitive) ہے لہذا اگر A، B کو مقرر کرتا ہے اور B، C کو مقرر کرتا ہے تو C، A کے ووٹ کا تعین کرتا ہے) بھی فراہم کر سکتا ہے۔ یہ ڈیزائن DAO کو ایک ڈی سینٹرلائزڈ کمیونٹی کے طور پر باقاعدہ طور پر بڑھنے کی اجازت دے گا، جس سے لوگ بالآخر یہ فلٹر کرنے کا کام ماہرین کو سونپ سکیں گے کہ کون رکن ہے، اگرچہ "موجودہ نظام" کے برعکس ماہرین وقت کے ساتھ ساتھ آسانی سے وجود میں آ اور جا سکتے ہیں کیونکہ انفرادی کمیونٹی کے اراکین اپنی وابستگیاں تبدیل کرتے ہیں۔

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

مزید ایپلی کیشنز

1. بچت کے بٹوے (Savings wallets)۔ فرض کریں کہ Alice اپنے فنڈز کو محفوظ رکھنا چاہتی ہے، لیکن اسے فکر ہے کہ وہ اپنی پرائیویٹ کی (private key) کھو دے گی یا کوئی اسے ہیک کر لے گا۔ وہ ایک بینک، Bob کے ساتھ ایک کنٹریکٹ میں ether اس طرح رکھتی ہے:

• اکیلی Alice روزانہ زیادہ سے زیادہ 1% فنڈز نکال سکتی ہے۔
• اکیلا Bob روزانہ زیادہ سے زیادہ 1% فنڈز نکال سکتا ہے، لیکن Alice کے پاس اپنی کی (key) کے ساتھ ایک ٹرانزیکشن کرنے کی صلاحیت ہے جو اس صلاحیت کو بند کر سکتی ہے۔
• Alice اور Bob مل کر کچھ بھی نکال سکتے ہیں۔

عام طور پر، Alice کے لیے روزانہ 1% کافی ہوتا ہے، اور اگر Alice مزید نکالنا چاہتی ہے تو وہ مدد کے لیے Bob سے رابطہ کر سکتی ہے۔ اگر Alice کی کی (key) ہیک ہو جاتی ہے، تو وہ فنڈز کو نئے کنٹریکٹ میں منتقل کرنے کے لیے Bob کے پاس بھاگتی ہے۔ اگر وہ اپنی کی (key) کھو دیتی ہے، تو Bob بالآخر فنڈز نکال لے گا۔ اگر Bob بدنیتی پر مبنی ثابت ہوتا ہے، تو وہ اس کے نکالنے کی صلاحیت کو بند کر سکتی ہے۔

2. فصل کی انشورنس۔ کوئی بھی شخص آسانی سے مالیاتی مشتقات کا کنٹریکٹ بنا سکتا ہے لیکن کسی بھی پرائس انڈیکس کے بجائے موسم کی ڈیٹا فیڈ کا استعمال کرتے ہوئے۔ اگر Iowa میں ایک کسان ایک ایسا مشتق (derivative) خریدتا ہے جو Iowa میں بارش کی بنیاد پر الٹا ادائیگی کرتا ہے، تو اگر خشک سالی ہوتی ہے، تو کسان کو خود بخود رقم مل جائے گی اور اگر کافی بارش ہوتی ہے تو کسان خوش ہوگا کیونکہ ان کی فصلیں اچھی ہوں گی۔ اسے عام طور پر قدرتی آفت کی انشورنس تک بڑھایا جا سکتا ہے۔

3. ایک ڈی سینٹرلائزڈ ڈیٹا فیڈ۔ فرق کے مالیاتی کنٹریکٹس (financial contracts for difference) کے لیے، درحقیقت "SchellingCoin (opens in a new tab)" نامی پروٹوکول کے ذریعے ڈیٹا فیڈ کو ڈی سینٹرلائز کرنا ممکن ہو سکتا ہے۔ SchellingCoin بنیادی طور پر اس طرح کام کرتا ہے: N پارٹیاں سبھی سسٹم میں دیے گئے ڈیٹم (datum) کی قدر (جیسے، ETH/USD قیمت) ڈالتی ہیں، قدروں کو ترتیب دیا جاتا ہے، اور 25 ویں اور 75 ویں پرسنٹائل (percentile) کے درمیان ہر ایک کو انعام کے طور پر ایک ٹوکن ملتا ہے۔ ہر ایک کو وہ جواب فراہم کرنے کی ترغیب ہوتی ہے جو باقی سب فراہم کریں گے، اور واحد قدر جس پر کھلاڑیوں کی ایک بڑی تعداد حقیقت پسندانہ طور پر متفق ہو سکتی ہے وہ واضح ڈیفالٹ ہے: سچائی۔ یہ ایک ڈی سینٹرلائزڈ پروٹوکول بناتا ہے جو نظریاتی طور پر کسی بھی تعداد میں قدریں فراہم کر سکتا ہے، بشمول ETH/USD قیمت، برلن کا درجہ حرارت یا یہاں تک کہ کسی خاص مشکل کمپیوٹیشن کا نتیجہ۔

4. سمارٹ ملٹی سگنیچر ایسکرو (Smart multisignature escrow)۔ Bitcoin ملٹی سگنیچر ٹرانزیکشن کنٹریکٹس کی اجازت دیتا ہے جہاں، مثال کے طور پر، دی گئی پانچ میں سے تین کیز (keys) فنڈز خرچ کر سکتی ہیں۔ Ethereum زیادہ باریکی (granularity) کی اجازت دیتا ہے؛ مثال کے طور پر، پانچ میں سے چار سب کچھ خرچ کر سکتے ہیں، پانچ میں سے تین روزانہ 10% تک خرچ کر سکتے ہیں، اور پانچ میں سے دو روزانہ 0.5% تک خرچ کر سکتے ہیں۔ مزید برآں، Ethereum ملٹی سگ (multisig) غیر مطابقت پذیر (asynchronous) ہے - دو پارٹیاں مختلف اوقات میں بلاک چین پر اپنے دستخط رجسٹر کر سکتی ہیں اور آخری دستخط خود بخود ٹرانزیکشن بھیج دے گا۔

5. کلاؤڈ کمپیوٹنگ۔ EVM ٹیکنالوجی کو ایک قابلِ تصدیق کمپیوٹنگ ماحول بنانے کے لیے بھی استعمال کیا جا سکتا ہے، جس سے صارفین دوسروں سے کمپیوٹیشنز انجام دینے کے لیے کہہ سکتے ہیں اور پھر اختیاری طور پر اس بات کے ثبوت مانگ سکتے ہیں کہ کچھ تصادفی طور پر منتخب کردہ چیک پوائنٹس پر کمپیوٹیشنز درست طریقے سے کی گئی تھیں۔ یہ کلاؤڈ کمپیوٹنگ مارکیٹ بنانے کی اجازت دیتا ہے جہاں کوئی بھی صارف اپنے ڈیسک ٹاپ، لیپ ٹاپ یا خصوصی سرور کے ساتھ حصہ لے سکتا ہے، اور سیکیورٹی ڈپازٹس کے ساتھ مل کر سپاٹ چیکنگ (spot-checking) کا استعمال اس بات کو یقینی بنانے کے لیے کیا جا سکتا ہے کہ سسٹم قابلِ اعتماد ہے (یعنی، نوڈس منافع بخش طریقے سے دھوکہ نہیں دے سکتے)۔ اگرچہ ایسا سسٹم تمام کاموں کے لیے موزوں نہیں ہو سکتا؛ مثال کے طور پر، وہ کام جن کے لیے اعلیٰ سطح کے انٹر پروسیس کمیونیکیشن کی ضرورت ہوتی ہے، نوڈس کے بڑے کلاؤڈ پر آسانی سے نہیں کیے جا سکتے۔ تاہم، دیگر کاموں کو متوازی (parallelize) کرنا بہت آسان ہے؛ SETI@home، folding@home اور جینیاتی الگورتھم (genetic algorithms) جیسے پروجیکٹس کو ایسے پلیٹ فارم کے اوپر آسانی سے نافذ کیا جا سکتا ہے۔

6. پیئر ٹو پیئر جوا (Peer-to-peer gambling)۔ کسی بھی تعداد میں پیئر ٹو پیئر جوئے کے پروٹوکولز، جیسے Frank Stajano اور Richard Clayton کا Cyberdice (opens in a new tab)، Ethereum بلاک چین پر نافذ کیے جا سکتے ہیں۔ جوئے کا سب سے آسان پروٹوکول دراصل اگلے بلاک ہیش پر فرق کا ایک کنٹریکٹ ہے، اور وہاں سے مزید جدید پروٹوکول بنائے جا سکتے ہیں، جس سے تقریباً صفر فیس کے ساتھ جوئے کی خدمات تخلیق ہوتی ہیں جن میں دھوکہ دینے کی کوئی صلاحیت نہیں ہوتی۔

7. پیشین گوئی کی مارکیٹس (Prediction markets)۔ اگر ایک اوریکل (oracle) یا SchellingCoin فراہم کیا جائے، تو پیشین گوئی کی مارکیٹس کو نافذ کرنا بھی آسان ہے، اور SchellingCoin کے ساتھ مل کر پیشین گوئی کی مارکیٹس ڈی سینٹرلائزڈ تنظیموں کے لیے گورننس پروٹوکول کے طور پر futarchy (opens in a new tab) کی پہلی مین اسٹریم ایپلی کیشن ثابت ہو سکتی ہیں۔

8. آن چین ڈی سینٹرلائزڈ مارکیٹ پلیسز، شناخت اور ساکھ کے سسٹم کو بنیاد کے طور پر استعمال کرتے ہوئے۔

متفرق امور اور خدشات

ترمیم شدہ GHOST کا نفاذ

"Greedy Heaviest Observed Subtree" (GHOST) پروٹوکول ایک جدت ہے جسے پہلی بار یوناتن سومپولنسکی (Yonatan Sompolinsky) اور اویو زوہر (Aviv Zohar) نے دسمبر 2013 (opens in a new tab) میں متعارف کرایا تھا۔ GHOST کے پیچھے محرک یہ ہے کہ تیز کنفرمیشن ٹائم والی بلاک چینز فی الحال ہائی اسٹیل ریٹ (stale rate) کی وجہ سے کم سیکیورٹی کا شکار ہیں - چونکہ بلاکس کو نیٹ ورک میں پھیلنے میں کچھ وقت لگتا ہے، اگر مائنر A ایک بلاک مائن کرتا ہے اور پھر مائنر B اتفاقاً ایک اور بلاک مائن کر لیتا ہے اس سے پہلے کہ مائنر A کا بلاک B تک پہنچے، تو مائنر B کا بلاک ضائع ہو جائے گا اور نیٹ ورک کی سیکیورٹی میں کوئی حصہ نہیں ڈالے گا۔ مزید برآں، سینٹرلائزیشن (مرکزیت) کا ایک مسئلہ ہے: اگر مائنر A ایک مائننگ پول ہے جس کے پاس 30% ہیش پاور ہے اور B کے پاس 10% ہیش پاور ہے، تو A کو 70% وقت اسٹیل بلاک پیدا کرنے کا خطرہ ہوگا (کیونکہ باقی 30% وقت A نے پچھلا بلاک پیدا کیا تھا اور اس لیے اسے مائننگ کا ڈیٹا فوراً مل جائے گا) جبکہ B کو 90% وقت اسٹیل بلاک پیدا کرنے کا خطرہ ہوگا۔ اس طرح، اگر بلاک کا وقفہ اتنا کم ہو کہ اسٹیل ریٹ زیادہ ہو جائے، تو A محض اپنے سائز کی وجہ سے نمایاں طور پر زیادہ کارآمد ہوگا۔ ان دونوں اثرات کے ملنے سے، وہ بلاک چینز جو تیزی سے بلاکس پیدا کرتی ہیں، ان میں اس بات کا بہت امکان ہوتا ہے کہ ایک مائننگ پول کے پاس نیٹ ورک کی ہیش پاور کا اتنا بڑا حصہ آ جائے کہ وہ مائننگ کے عمل پر عملی طور پر کنٹرول حاصل کر لے۔

جیسا کہ سومپولنسکی اور زوہر نے بیان کیا ہے، GHOST نیٹ ورک سیکیورٹی کے نقصان کے پہلے مسئلے کو اس حساب میں اسٹیل بلاکس کو شامل کر کے حل کرتا ہے کہ کون سی چین "سب سے طویل" ہے؛ یعنی، نہ صرف ایک بلاک کے پیرنٹ (parent) اور مزید آباؤ اجداد، بلکہ بلاک کے آباؤ اجداد کی اسٹیل اولاد (Ethereum کی اصطلاح میں، "انکلز" (uncles)) کو بھی اس حساب میں شامل کیا جاتا ہے کہ کس بلاک کے پیچھے سب سے زیادہ کل پروف آف ورک (proof-of-work) موجود ہے۔ سینٹرلائزیشن کے تعصب کے دوسرے مسئلے کو حل کرنے کے لیے، ہم سومپولنسکی اور زوہر کے بیان کردہ پروٹوکول سے آگے بڑھتے ہیں، اور اسٹیل بلاکس کو بھی بلاک ریوارڈ فراہم کرتے ہیں: ایک اسٹیل بلاک کو اس کے بنیادی انعام کا 87.5% ملتا ہے، اور وہ بھتیجا (nephew) جو اسٹیل بلاک کو شامل کرتا ہے اسے باقی 12.5% ملتا ہے۔ تاہم، ٹرانزیکشن فیس انکلز کو نہیں دی جاتی۔

Ethereum GHOST کا ایک سادہ ورژن نافذ کرتا ہے جو صرف سات لیولز تک نیچے جاتا ہے۔ خاص طور پر، اس کی تعریف اس طرح کی گئی ہے:

• ایک بلاک کو ایک پیرنٹ (parent) کی وضاحت کرنی چاہیے، اور اسے 0 یا اس سے زیادہ انکلز کی وضاحت کرنی چاہیے۔
• بلاک B میں شامل ایک انکل میں درج ذیل خصوصیات ہونی چاہئیں:
  • اسے B کے k-ویں جنریشن کے آباؤ اجداد کا براہ راست بچہ ہونا چاہیے، جہاں 2 <= k <= 7 ہو۔
  • یہ B کا جد امجد (ancestor) نہیں ہو سکتا۔
  • ایک انکل کا درست بلاک ہیڈر ہونا ضروری ہے، لیکن اس کا پہلے سے تصدیق شدہ یا درست بلاک ہونا ضروری نہیں ہے۔
  • ایک انکل کو پچھلے بلاکس میں شامل تمام انکلز اور اسی بلاک میں شامل دیگر تمام انکلز سے مختلف ہونا چاہیے (نان-ڈبل-انکلوژن)۔
• بلاک B میں ہر انکل U کے لیے، B کے مائنر کو اس کے کوائن بیس (coinbase) انعام میں اضافی 3.125% ملتا ہے اور U کے مائنر کو معیاری کوائن بیس انعام کا 93.75% ملتا ہے۔

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

فیسیں

چونکہ بلاک چین میں شائع ہونے والی ہر ٹرانزیکشن نیٹ ورک پر اسے ڈاؤن لوڈ اور تصدیق کرنے کی لاگت عائد کرتی ہے، اس لیے غلط استعمال کو روکنے کے لیے کسی ریگولیٹری میکانزم کی ضرورت ہوتی ہے، جس میں عام طور پر ٹرانزیکشن فیس شامل ہوتی ہے۔ Bitcoin میں استعمال ہونے والا ڈیفالٹ طریقہ کار یہ ہے کہ خالصتاً رضاکارانہ فیسیں ہوں، جس میں مائنرز پر انحصار کیا جاتا ہے کہ وہ گیٹ کیپرز کے طور پر کام کریں اور ڈائنامک کم از کم حد مقرر کریں۔ اس نقطہ نظر کو Bitcoin کمیونٹی میں بہت سازگار انداز میں قبول کیا گیا ہے خاص طور پر اس لیے کہ یہ "مارکیٹ پر مبنی" ہے، جو مائنرز اور ٹرانزیکشن بھیجنے والوں کے درمیان طلب اور رسد کو قیمت کا تعین کرنے کی اجازت دیتا ہے۔ تاہم، اس استدلال کے ساتھ مسئلہ یہ ہے کہ ٹرانزیکشن پروسیسنگ کوئی مارکیٹ نہیں ہے؛ اگرچہ ٹرانزیکشن پروسیسنگ کو ایک ایسی سروس کے طور پر سمجھنا بدیہی طور پر پرکشش ہے جو مائنر بھیجنے والے کو پیش کر رہا ہے، حقیقت میں ہر وہ ٹرانزیکشن جسے مائنر شامل کرتا ہے اسے نیٹ ورک کے ہر نوڈ کے ذریعے پروسیس کرنے کی ضرورت ہوگی، لہذا ٹرانزیکشن پروسیسنگ کی لاگت کی اکثریت تیسرے فریق برداشت کرتے ہیں نہ کہ وہ مائنر جو اسے شامل کرنے یا نہ کرنے کا فیصلہ کر رہا ہے۔ لہذا، ٹریجڈی آف دی کامنز (tragedy-of-the-commons) کے مسائل پیدا ہونے کا بہت امکان ہے۔

تاہم، جیسا کہ ظاہر ہوتا ہے کہ مارکیٹ پر مبنی میکانزم میں یہ خامی، جب ایک خاص غلط سادہ مفروضہ دیا جاتا ہے، تو جادوئی طور پر خود کو منسوخ کر دیتی ہے۔ دلیل کچھ یوں ہے۔ فرض کریں کہ:

1. ایک ٹرانزیکشن k آپریشنز کا باعث بنتی ہے، جو اسے شامل کرنے والے کسی بھی مائنر کو kR انعام پیش کرتی ہے جہاں R بھیجنے والے کے ذریعے سیٹ کیا جاتا ہے اور k اور R مائنر کو پہلے سے (تقریباً) نظر آتے ہیں۔
2. کسی بھی نوڈ کے لیے ایک آپریشن کی پروسیسنگ لاگت C ہوتی ہے (یعنی، تمام نوڈز کی کارکردگی برابر ہے)
3. N مائننگ نوڈز ہیں، جن میں سے ہر ایک کی پروسیسنگ پاور بالکل برابر ہے (یعنی، کل کا 1/N)
4. کوئی نان-مائننگ فل نوڈز موجود نہیں ہیں۔

ایک مائنر ٹرانزیکشن پروسیس کرنے کے لیے تیار ہوگا اگر متوقع انعام لاگت سے زیادہ ہو۔ اس طرح، متوقع انعام kR/N ہے کیونکہ مائنر کے پاس اگلا بلاک پروسیس کرنے کا 1/N موقع ہوتا ہے، اور مائنر کے لیے پروسیسنگ لاگت محض kC ہے۔ لہذا، مائنرز ان ٹرانزیکشنز کو شامل کریں گے جہاں kR/N > kC، یا R > NC ہو۔ نوٹ کریں کہ R بھیجنے والے کی طرف سے فراہم کردہ فی-آپریشن فیس ہے، اور اس طرح یہ اس فائدے کی نچلی حد ہے جو بھیجنے والا ٹرانزیکشن سے حاصل کرتا ہے، اور NC ایک آپریشن کو پروسیس کرنے کے لیے پورے نیٹ ورک کی مجموعی لاگت ہے۔ لہذا، مائنرز کے پاس صرف ان ٹرانزیکشنز کو شامل کرنے کی ترغیب ہوتی ہے جن کے لیے کل افادی فائدہ لاگت سے زیادہ ہو۔

تاہم، حقیقت میں ان مفروضوں سے کئی اہم انحرافات ہیں:

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

(1) مائنر کے لیے کم ٹرانزیکشنز شامل کرنے کا رجحان فراہم کرتا ہے، اور (2) NC کو بڑھاتا ہے؛ لہذا، یہ دونوں اثرات کم از کم جزوی طور پر ایک دوسرے کو منسوخ کر دیتے ہیں۔^{کیسے؟ (opens in a new tab)} (3) اور (4) بڑے مسائل ہیں؛ انہیں حل کرنے کے لیے ہم محض ایک فلوٹنگ کیپ (floating cap) قائم کرتے ہیں: کسی بھی بلاک میں طویل مدتی ایکسپونینشل موونگ ایوریج (exponential moving average) کے BLK_LIMIT_FACTOR گنا سے زیادہ آپریشنز نہیں ہو سکتے۔ خاص طور پر:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR اور EMA_FACTOR ایسے مستقل (constants) ہیں جنہیں فی الحال 65536 اور 1.5 پر سیٹ کیا جائے گا، لیکن مزید تجزیے کے بعد ان میں تبدیلی کا امکان ہے۔

Bitcoin میں بڑے بلاک سائز کی حوصلہ شکنی کرنے والا ایک اور عنصر ہے: جو بلاکس بڑے ہوتے ہیں انہیں پھیلنے میں زیادہ وقت لگے گا، اور اس طرح ان کے اسٹیل ہونے کا امکان زیادہ ہوتا ہے۔ Ethereum میں، زیادہ گیس استعمال کرنے والے بلاکس کو پھیلنے میں بھی زیادہ وقت لگ سکتا ہے کیونکہ وہ جسمانی طور پر بڑے ہوتے ہیں اور اس لیے بھی کہ انہیں توثیق کرنے کے لیے ٹرانزیکشن اسٹیٹ ٹرانزیشنز کو پروسیس کرنے میں زیادہ وقت لگتا ہے۔ تاخیر کی یہ حوصلہ شکنی Bitcoin میں ایک اہم غور طلب بات ہے، لیکن GHOST پروٹوکول کی وجہ سے Ethereum میں کم ہے؛ لہذا، ریگولیٹڈ بلاک کی حدود پر انحصار کرنا ایک زیادہ مستحکم بنیاد فراہم کرتا ہے۔

کمپیوٹیشن اور ٹیورنگ-کمپلیٹنس

ایک اہم بات یہ ہے کہ Ethereum ورچوئل مشین ٹیورنگ-کمپلیٹ (Turing-complete) ہے؛ اس کا مطلب ہے کہ EVM کوڈ کسی بھی ایسی کمپیوٹیشن کو انکوڈ کر سکتا ہے جسے تصوراتی طور پر انجام دیا جا سکتا ہے، بشمول لامحدود لوپس (infinite loops)۔ EVM کوڈ دو طریقوں سے لوپنگ کی اجازت دیتا ہے۔ پہلا، ایک JUMP انسٹرکشن ہے جو پروگرام کو کوڈ میں پچھلی جگہ پر واپس جانے کی اجازت دیتی ہے، اور مشروط جمپنگ کرنے کے لیے ایک JUMPI انسٹرکشن ہے، جو while x < 27: x = x * 2 جیسے بیانات کی اجازت دیتی ہے۔ دوسرا، کانٹریکٹس دوسرے کانٹریکٹس کو کال کر سکتے ہیں، جو ممکنہ طور پر تکرار (recursion) کے ذریعے لوپنگ کی اجازت دیتے ہیں۔ یہ فطری طور پر ایک مسئلے کی طرف لے جاتا ہے: کیا بدنیتی پر مبنی صارفین مائنرز اور فل نوڈز کو لامحدود لوپ میں داخل ہونے پر مجبور کر کے انہیں بنیادی طور پر بند کر سکتے ہیں؟ یہ مسئلہ کمپیوٹر سائنس میں ہالٹنگ پرابلم (halting problem) کے نام سے جانے جانے والے ایک مسئلے کی وجہ سے پیدا ہوتا ہے: عام صورت میں، یہ بتانے کا کوئی طریقہ نہیں ہے کہ آیا کوئی دیا گیا پروگرام کبھی رکے گا یا نہیں۔

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

• ایک حملہ آور ایک کانٹریکٹ بناتا ہے جو ایک لامحدود لوپ چلاتا ہے، اور پھر مائنر کو اس لوپ کو فعال کرنے والی ٹرانزیکشن بھیجتا ہے۔ مائنر ٹرانزیکشن کو پروسیس کرے گا، لامحدود لوپ چلائے گا، اور اس کی گیس ختم ہونے کا انتظار کرے گا۔ اگرچہ عمل درآمد کے دوران گیس ختم ہو جاتی ہے اور یہ آدھے راستے میں رک جاتا ہے، ٹرانزیکشن اب بھی درست ہے اور مائنر اب بھی ہر کمپیوٹیشنل قدم کے لیے حملہ آور سے فیس کا دعویٰ کرتا ہے۔
• ایک حملہ آور اس ارادے کے ساتھ ایک بہت طویل لامحدود لوپ بناتا ہے کہ مائنر کو اتنے لمبے عرصے تک کمپیوٹنگ جاری رکھنے پر مجبور کیا جائے کہ جب تک کمپیوٹیشن ختم ہو، کچھ اور بلاکس سامنے آ چکے ہوں گے اور مائنر کے لیے فیس کا دعویٰ کرنے کے لیے ٹرانزیکشن کو شامل کرنا ممکن نہیں ہوگا۔ تاہم، حملہ آور کو STARTGAS کے لیے ایک قدر جمع کرانے کی ضرورت ہوگی جو ان کمپیوٹیشنل مراحل کی تعداد کو محدود کرے گی جو عمل درآمد لے سکتا ہے، لہذا مائنر کو پہلے سے معلوم ہو جائے گا کہ کمپیوٹیشن میں بہت زیادہ مراحل لگیں گے۔
• ایک حملہ آور کسی شکل کے کوڈ کے ساتھ ایک کانٹریکٹ دیکھتا ہے جیسے send(A,contract.storage[A]); contract.storage[A] = 0، اور صرف اتنی گیس کے ساتھ ایک ٹرانزیکشن بھیجتا ہے جو پہلا قدم چلانے کے لیے کافی ہو لیکن دوسرا نہیں (یعنی، رقم نکالنا لیکن بیلنس کو کم نہ ہونے دینا)۔ کانٹریکٹ کے مصنف کو اس طرح کے حملوں سے بچانے کے بارے میں فکر کرنے کی ضرورت نہیں ہے، کیونکہ اگر عمل درآمد آدھے راستے میں رک جاتا ہے تو تبدیلیاں واپس ہو جاتی ہیں۔
• ایک مالیاتی کانٹریکٹ خطرے کو کم کرنے کے لیے نو ملکیتی ڈیٹا فیڈز کا اوسط (median) لے کر کام کرتا ہے۔ ایک حملہ آور ڈیٹا فیڈز میں سے ایک پر قبضہ کر لیتا ہے، جسے DAOs کے سیکشن میں بیان کردہ متغیر-ایڈریس-کال (variable-address-call) میکانزم کے ذریعے قابل ترمیم ہونے کے لیے ڈیزائن کیا گیا ہے، اور اسے لامحدود لوپ چلانے کے لیے تبدیل کر دیتا ہے، اس طرح مالیاتی کانٹریکٹ سے فنڈز کا دعویٰ کرنے کی کسی بھی کوشش کو گیس ختم ہونے پر مجبور کرنے کی کوشش کرتا ہے۔ تاہم، مالیاتی کانٹریکٹ اس مسئلے کو روکنے کے لیے پیغام پر گیس کی حد مقرر کر سکتا ہے۔

ٹیورنگ-کمپلیٹنس کا متبادل ٹیورنگ-انکمپلیٹنس (Turing-incompleteness) ہے، جہاں JUMP اور JUMPI موجود نہیں ہوتے اور کسی بھی وقت کال اسٹیک میں ہر کانٹریکٹ کی صرف ایک کاپی موجود ہونے کی اجازت ہوتی ہے۔ اس سسٹم کے ساتھ، بیان کردہ فیس سسٹم اور ہمارے حل کی تاثیر کے بارے میں غیر یقینی صورتحال ضروری نہیں ہو سکتی، کیونکہ کانٹریکٹ کو انجام دینے کی لاگت اس کے سائز کے لحاظ سے اوپر سے محدود ہوگی۔ مزید برآں، ٹیورنگ-انکمپلیٹنس اتنی بڑی حد بھی نہیں ہے؛ ان تمام کانٹریکٹ کی مثالوں میں سے جو ہم نے اندرونی طور پر سوچی ہیں، اب تک صرف ایک کو لوپ کی ضرورت تھی، اور اس لوپ کو بھی ایک لائن کے کوڈ کی 26 تکرار بنا کر ہٹایا جا سکتا تھا۔ ٹیورنگ-کمپلیٹنس کے سنگین مضمرات، اور محدود فائدے کو دیکھتے ہوئے، کیوں نہ محض ایک ٹیورنگ-انکمپلیٹ زبان رکھی جائے؟ تاہم، حقیقت میں، ٹیورنگ-انکمپلیٹنس اس مسئلے کا کوئی صاف ستھرا حل نہیں ہے۔ یہ دیکھنے کے لیے کہ کیوں، درج ذیل کانٹریکٹس پر غور کریں:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

اب، A کو ایک ٹرانزیکشن بھیجیں۔ اس طرح، 51 ٹرانزیکشنز میں، ہمارے پاس ایک کانٹریکٹ ہے جو 2⁵⁰ کمپیوٹیشنل مراحل لیتا ہے۔ مائنرز ہر کانٹریکٹ کے ساتھ ایک قدر کو برقرار رکھ کر وقت سے پہلے ایسے لاجک بموں (logic bombs) کا پتہ لگانے کی کوشش کر سکتے ہیں جو ان کمپیوٹیشنل مراحل کی زیادہ سے زیادہ تعداد کی وضاحت کرتی ہے جو یہ لے سکتا ہے، اور دوسرے کانٹریکٹس کو بار بار کال کرنے والے کانٹریکٹس کے لیے اس کا حساب لگا سکتے ہیں، لیکن اس کے لیے مائنرز کو ان کانٹریکٹس کو منع کرنے کی ضرورت ہوگی جو دوسرے کانٹریکٹس بناتے ہیں (کیونکہ اوپر دیے گئے تمام 26 کانٹریکٹس کی تخلیق اور عمل درآمد کو آسانی سے ایک ہی کانٹریکٹ میں رول کیا جا سکتا ہے)۔ ایک اور مسئلہ یہ ہے کہ پیغام کا ایڈریس فیلڈ ایک متغیر (variable) ہے، لہذا عام طور پر یہ بتانا بھی ممکن نہیں ہو سکتا کہ کوئی دیا گیا کانٹریکٹ وقت سے پہلے کن دوسرے کانٹریکٹس کو کال کرے گا۔ لہذا، مجموعی طور پر، ہمارے پاس ایک حیران کن نتیجہ ہے: ٹیورنگ-کمپلیٹنس کا انتظام کرنا حیران کن طور پر آسان ہے، اور ٹیورنگ-کمپلیٹنس کی کمی کا انتظام کرنا بھی اتنا ہی حیران کن طور پر مشکل ہے جب تک کہ بالکل وہی کنٹرولز موجود نہ ہوں - لیکن اس صورت میں کیوں نہ پروٹوکول کو ٹیورنگ-کمپلیٹ رہنے دیا جائے؟

کرنسی اور اجراء

Ethereum نیٹ ورک میں اس کی اپنی بلٹ ان کرنسی، ether شامل ہے، جو مختلف قسم کے ڈیجیٹل اثاثوں کے درمیان موثر تبادلے کی اجازت دینے کے لیے ایک بنیادی لیکویڈیٹی لیئر فراہم کرنے اور، اس سے بھی اہم بات، ٹرانزیکشن فیس ادا کرنے کے لیے ایک میکانزم فراہم کرنے کا دوہرا مقصد پورا کرتی ہے۔ سہولت کے لیے اور مستقبل کی بحث سے بچنے کے لیے (Bitcoin میں موجودہ mBTC/uBTC/satoshi بحث دیکھیں)، مالیتوں (denominations) کو پہلے سے لیبل کیا جائے گا:

• 1: wei
• 10¹²: szabo
• 10¹⁵: finney
• 10¹⁸: ether

اسے "ڈالر" اور "سینٹ" یا "BTC" اور "satoshi" کے تصور کے توسیع شدہ ورژن کے طور پر لیا جانا چاہیے۔ مستقبل قریب میں، ہم توقع کرتے ہیں کہ "ether" عام ٹرانزیکشنز کے لیے، "finney" مائیکرو ٹرانزیکشنز کے لیے اور "szabo" اور "wei" فیسوں اور پروٹوکول کے نفاذ کے بارے میں تکنیکی بات چیت کے لیے استعمال ہوں گے؛ باقی مالیتیں بعد میں کارآمد ہو سکتی ہیں اور اس وقت انہیں کلائنٹس میں شامل نہیں کیا جانا چاہیے۔

اجراء کا ماڈل درج ذیل ہوگا:

• Ether کو کرنسی سیل میں 1000-2000 ether فی BTC کی قیمت پر جاری کیا جائے گا، یہ ایک ایسا میکانزم ہے جس کا مقصد Ethereum تنظیم کو فنڈ دینا اور ترقی کی ادائیگی کرنا ہے جسے Mastercoin اور NXT جیسے دیگر پلیٹ فارمز نے کامیابی کے ساتھ استعمال کیا ہے۔ پہلے خریداروں کو بڑی چھوٹ سے فائدہ ہوگا۔ فروخت سے حاصل ہونے والے BTC کو مکمل طور پر ڈیولپرز کو تنخواہوں اور باؤنٹیز کی ادائیگی کے لیے استعمال کیا جائے گا اور Ethereum اور کریپٹو کرنسی ایکو سسٹم میں مختلف منافع بخش اور غیر منافع بخش پروجیکٹس میں سرمایہ کاری کی جائے گی۔
• فروخت شدہ کل رقم کا 0.099x (60102216 ETH) تنظیم کو ابتدائی تعاون کنندگان کو معاوضہ دینے اور جینیسس بلاک (genesis block) سے پہلے ETH پر مبنی اخراجات ادا کرنے کے لیے مختص کیا جائے گا۔
• فروخت شدہ کل رقم کا 0.099x طویل مدتی ریزرو کے طور پر برقرار رکھا جائے گا۔
• اس کے بعد ہمیشہ کے لیے ہر سال فروخت شدہ کل رقم کا 0.26x مائنرز کو مختص کیا جائے گا۔

طویل مدتی سپلائی کی شرح نمو (فیصد)

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

مندرجہ بالا ماڈل میں دو اہم انتخاب یہ ہیں (1) انڈوومنٹ پول (endowment pool) کی موجودگی اور سائز، اور (2) مستقل طور پر بڑھتی ہوئی لینیئر سپلائی کی موجودگی، جیسا کہ Bitcoin میں کیپڈ سپلائی (capped supply) کے برعکس ہے۔ انڈوومنٹ پول کا جواز درج ذیل ہے۔ اگر انڈوومنٹ پول موجود نہ ہوتا، اور لینیئر اجراء اسی افراط زر کی شرح فراہم کرنے کے لیے کم ہو کر 0.217x رہ جاتا، تو ether کی کل مقدار 16.5% کم ہوتی اور اس طرح ہر یونٹ 19.8% زیادہ قیمتی ہوتا۔ لہذا، توازن میں فروخت میں 19.8% زیادہ ether خریدا جائے گا، لہذا ہر یونٹ ایک بار پھر بالکل پہلے جتنا ہی قیمتی ہوگا۔ اس کے بعد تنظیم کے پاس 1.198x جتنا BTC بھی ہوگا، جسے دو حصوں میں تقسیم کیا جا سکتا ہے: اصل BTC، اور اضافی 0.198x۔ لہذا، یہ صورتحال انڈوومنٹ کے بالکل مساوی ہے، لیکن ایک اہم فرق کے ساتھ: تنظیم خالصتاً BTC رکھتی ہے، اور اس لیے اسے ether یونٹ کی قدر کو سپورٹ کرنے کی ترغیب نہیں ملتی۔

مستقل لینیئر سپلائی گروتھ ماڈل اس خطرے کو کم کرتا ہے جسے کچھ لوگ Bitcoin میں دولت کے ضرورت سے زیادہ ارتکاز کے طور پر دیکھتے ہیں، اور موجودہ اور مستقبل کے ادوار میں رہنے والے افراد کو کرنسی یونٹس حاصل کرنے کا مناسب موقع فراہم کرتا ہے، جبکہ ایک ہی وقت میں ether حاصل کرنے اور رکھنے کی ایک مضبوط ترغیب برقرار رکھتا ہے کیونکہ فیصد کے طور پر "سپلائی کی شرح نمو" اب بھی وقت کے ساتھ صفر کی طرف مائل ہوتی ہے۔ ہم یہ نظریہ بھی پیش کرتے ہیں کہ چونکہ لاپرواہی، موت وغیرہ کی وجہ سے وقت کے ساتھ سکے ہمیشہ ضائع ہو جاتے ہیں، اور سکے کے نقصان کو ہر سال کل سپلائی کے فیصد کے طور پر ماڈل کیا جا سکتا ہے، اس لیے گردش میں کل کرنسی کی سپلائی درحقیقت بالآخر سالانہ اجراء کو نقصان کی شرح سے تقسیم کرنے کے برابر قدر پر مستحکم ہو جائے گی (مثال کے طور پر، 1% کے نقصان کی شرح پر، ایک بار جب سپلائی 26X تک پہنچ جائے گی تو ہر سال 0.26X مائن کیا جائے گا اور 0.26X ضائع ہو جائے گا، جس سے ایک توازن پیدا ہوگا)۔

نوٹ کریں کہ مستقبل میں، اس بات کا امکان ہے کہ Ethereum سیکیورٹی کے لیے پروف آف اسٹیک (proof-of-stake) ماڈل پر منتقل ہو جائے گا، جس سے اجراء کی ضرورت صفر اور 0.05X فی سال کے درمیان کم ہو جائے گی۔ اس صورت میں کہ Ethereum تنظیم فنڈنگ کھو دیتی ہے یا کسی اور وجہ سے غائب ہو جاتی ہے، ہم ایک "سماجی معاہدہ" (social contract) کھلا چھوڑتے ہیں: کسی کو بھی Ethereum کا مستقبل کا امیدوار ورژن بنانے کا حق حاصل ہے، جس کی واحد شرط یہ ہے کہ ether کی مقدار زیادہ سے زیادہ 60102216 * (1.198 + 0.26 * n) کے برابر ہونی چاہیے جہاں n جینیسس بلاک کے بعد سالوں کی تعداد ہے۔ تخلیق کار ترقی کی ادائیگی کے لیے PoS سے چلنے والی سپلائی کی توسیع اور زیادہ سے زیادہ قابل اجازت سپلائی کی توسیع کے درمیان فرق کا کچھ حصہ یا تمام حصہ کراؤڈ سیل (crowd-sell) کرنے یا بصورت دیگر تفویض کرنے کے لیے آزاد ہیں۔ امیدوار اپ گریڈز جو سماجی معاہدے کی تعمیل نہیں کرتے ہیں انہیں جائز طور پر تعمیل کرنے والے ورژنز میں فورک (fork) کیا جا سکتا ہے۔

مائننگ سینٹرلائزیشن

Bitcoin مائننگ الگورتھم اس طرح کام کرتا ہے کہ مائنرز بلاک ہیڈر کے قدرے تبدیل شدہ ورژنز پر لاکھوں بار بار بار SHA256 کا حساب لگاتے ہیں، یہاں تک کہ بالآخر ایک نوڈ ایک ایسا ورژن لے کر آتا ہے جس کا ہیش ہدف سے کم ہوتا ہے (فی الحال تقریباً 2¹⁹²)۔ تاہم، یہ مائننگ الگورتھم سینٹرلائزیشن کی دو شکلوں کے لیے کمزور ہے۔ پہلا، مائننگ ایکو سسٹم پر ASICs (ایپلیکیشن-اسپیسیفک انٹیگریٹڈ سرکٹس) کا غلبہ ہو گیا ہے، جو کمپیوٹر چپس ہیں جنہیں خاص طور پر Bitcoin مائننگ کے کام کے لیے ڈیزائن کیا گیا ہے، اور اس لیے وہ اس میں ہزاروں گنا زیادہ کارآمد ہیں۔ اس کا مطلب یہ ہے کہ Bitcoin مائننگ اب کوئی انتہائی ڈی سینٹرلائزڈ اور مساوی مشغلہ نہیں رہا، جس میں مؤثر طریقے سے حصہ لینے کے لیے لاکھوں ڈالر کے سرمائے کی ضرورت ہوتی ہے۔ دوسرا، زیادہ تر Bitcoin مائنرز دراصل مقامی طور پر بلاک کی توثیق نہیں کرتے؛ اس کے بجائے، وہ بلاک ہیڈرز فراہم کرنے کے لیے ایک سینٹرلائزڈ مائننگ پول پر انحصار کرتے ہیں۔ یہ مسئلہ ممکنہ طور پر بدتر ہے: اس تحریر کے وقت تک، سرفہرست تین مائننگ پولز بالواسطہ طور پر Bitcoin نیٹ ورک میں تقریباً 50% پروسیسنگ پاور کو کنٹرول کرتے ہیں، حالانکہ اس حقیقت سے اس میں کمی آتی ہے کہ اگر کوئی پول یا اتحاد 51% حملے کی کوشش کرتا ہے تو مائنرز دوسرے مائننگ پولز میں جا سکتے ہیں۔

Ethereum میں موجودہ ارادہ ایک ایسا مائننگ الگورتھم استعمال کرنے کا ہے جہاں مائنرز کو اسٹیٹ سے بے ترتیب ڈیٹا لانے، بلاک چین میں پچھلے N بلاکس سے کچھ تصادفی طور پر منتخب کردہ ٹرانزیکشنز کا حساب لگانے، اور نتیجے کا ہیش واپس کرنے کی ضرورت ہوتی ہے۔ اس کے دو اہم فوائد ہیں۔ پہلا، Ethereum کانٹریکٹس میں کسی بھی قسم کی کمپیوٹیشن شامل ہو سکتی ہے، لہذا ایک Ethereum ASIC بنیادی طور پر عام کمپیوٹیشن کے لیے ایک ASIC ہوگا - یعنی، ایک بہتر CPU۔ دوسرا، مائننگ کے لیے پوری بلاک چین تک رسائی کی ضرورت ہوتی ہے، جو مائنرز کو پوری بلاک چین کو اسٹور کرنے اور کم از کم ہر ٹرانزیکشن کی تصدیق کرنے کے قابل ہونے پر مجبور کرتی ہے۔ یہ سینٹرلائزڈ مائننگ پولز کی ضرورت کو ختم کرتا ہے؛ اگرچہ مائننگ پولز اب بھی انعام کی تقسیم کی بے ترتیبی کو ہموار کرنے کا جائز کردار ادا کر سکتے ہیں، لیکن یہ کام پیئر-ٹو-پیئر (peer-to-peer) پولز کے ذریعے بھی اتنی ہی اچھی طرح انجام دیا جا سکتا ہے جن پر کوئی مرکزی کنٹرول نہ ہو۔

یہ ماڈل غیر آزمودہ ہے، اور کانٹریکٹ پر عمل درآمد کو مائننگ الگورتھم کے طور پر استعمال کرتے وقت کچھ چالاک آپٹیمائزیشنز سے بچنے میں راستے میں مشکلات پیش آ سکتی ہیں۔ تاہم، اس الگورتھم کی ایک خاص طور پر دلچسپ خصوصیت یہ ہے کہ یہ کسی کو بھی "کنویں میں زہر ملانے" (poison the well) کی اجازت دیتا ہے، بلاک چین میں بڑی تعداد میں ایسے کانٹریکٹس متعارف کروا کر جو خاص طور پر کچھ ASICs کو روکنے کے لیے ڈیزائن کیے گئے ہوں۔ ASIC مینوفیکچررز کے لیے ایک دوسرے پر حملہ کرنے کے لیے ایسی چال استعمال کرنے کی معاشی ترغیبات موجود ہیں۔ اس طرح، جو حل ہم تیار کر رہے ہیں وہ بالآخر خالصتاً تکنیکی حل کے بجائے ایک موافق معاشی انسانی حل ہے۔

اسکیل ایبلٹی

Ethereum کے بارے میں ایک عام تشویش اسکیل ایبلٹی (scalability) کا مسئلہ ہے۔ Bitcoin کی طرح، Ethereum بھی اس خامی کا شکار ہے کہ ہر ٹرانزیکشن کو نیٹ ورک کے ہر نوڈ کے ذریعے پروسیس کرنے کی ضرورت ہوتی ہے۔ Bitcoin کے ساتھ، موجودہ بلاک چین کا سائز تقریباً 15 GB ہے، جو تقریباً 1 MB فی گھنٹہ کی رفتار سے بڑھ رہا ہے۔ اگر Bitcoin نیٹ ورک Visa کی 2000 ٹرانزیکشنز فی سیکنڈ پروسیس کرتا، تو یہ 1 MB فی تین سیکنڈ (1 GB فی گھنٹہ، 8 TB فی سال) کی رفتار سے بڑھتا۔ Ethereum کے بھی اسی طرح کے ترقی کے پیٹرن کا شکار ہونے کا امکان ہے، جو اس حقیقت سے مزید خراب ہو جاتا ہے کہ Ethereum بلاک چین کے اوپر صرف ایک کرنسی کے بجائے بہت سی ایپلی کیشنز ہوں گی جیسا کہ Bitcoin کے معاملے میں ہے، لیکن اس حقیقت سے بہتری آتی ہے کہ Ethereum فل نوڈز کو پوری بلاک چین ہسٹری کے بجائے صرف اسٹیٹ کو اسٹور کرنے کی ضرورت ہوتی ہے۔

اتنے بڑے بلاک چین سائز کے ساتھ مسئلہ سینٹرلائزیشن کا خطرہ ہے۔ اگر بلاک چین کا سائز بڑھ کر، فرض کریں، 100 TB ہو جاتا ہے، تو ممکنہ صورتحال یہ ہوگی کہ صرف بہت کم تعداد میں بڑے کاروبار فل نوڈز چلائیں گے، جبکہ تمام باقاعدہ صارفین لائٹ SPV نوڈز استعمال کریں گے۔ ایسی صورتحال میں، یہ ممکنہ تشویش پیدا ہوتی ہے کہ فل نوڈز اکٹھے ہو سکتے ہیں اور سب کسی منافع بخش انداز میں دھوکہ دینے پر متفق ہو سکتے ہیں (مثال کے طور پر، بلاک ریوارڈ تبدیل کرنا، خود کو BTC دینا)۔ لائٹ نوڈز کے پاس فوری طور پر اس کا پتہ لگانے کا کوئی طریقہ نہیں ہوگا۔ یقیناً، کم از کم ایک ایماندار فل نوڈ کے موجود ہونے کا امکان ہوگا، اور چند گھنٹوں کے بعد Reddit جیسے چینلز کے ذریعے دھوکہ دہی کے بارے میں معلومات سامنے آ جائیں گی، لیکن اس وقت تک بہت دیر ہو چکی ہوگی: یہ عام صارفین پر منحصر ہوگا کہ وہ دیے گئے بلاکس کو بلیک لسٹ کرنے کی کوشش کو منظم کریں، جو کہ ایک کامیاب 51% حملے کو انجام دینے کے پیمانے پر ایک بڑے اور ممکنہ طور پر ناقابل عمل کوآرڈینیشن کا مسئلہ ہے۔ Bitcoin کے معاملے میں، یہ فی الحال ایک مسئلہ ہے، لیکن ایک بلاک چین ترمیم موجود ہے جو پیٹر ٹوڈ (Peter Todd) کی طرف سے تجویز کردہ (opens in a new tab) ہے جو اس مسئلے کو کم کر دے گی۔

مستقبل قریب میں، Ethereum اس مسئلے سے نمٹنے کے لیے دو اضافی حکمت عملی استعمال کرے گا۔ پہلا، بلاک چین پر مبنی مائننگ الگورتھمز کی وجہ سے، کم از کم ہر مائنر کو فل نوڈ بننے پر مجبور کیا جائے گا، جس سے فل نوڈز کی تعداد پر ایک نچلی حد پیدا ہوگی۔ دوسرا اور اس سے بھی اہم بات، تاہم، ہم ہر ٹرانزیکشن کو پروسیس کرنے کے بعد بلاک چین میں ایک درمیانی اسٹیٹ ٹری روٹ (intermediate state tree root) شامل کریں گے۔ یہاں تک کہ اگر بلاک کی توثیق سینٹرلائزڈ ہے، جب تک ایک ایماندار تصدیق کرنے والا نوڈ موجود ہے، سینٹرلائزیشن کے مسئلے کو تصدیقی پروٹوکول کے ذریعے روکا جا سکتا ہے۔ اگر کوئی مائنر ایک غلط بلاک شائع کرتا ہے، تو وہ بلاک یا تو بری طرح فارمیٹ کیا گیا ہوگا، یا اسٹیٹ S[n] غلط ہوگی۔ چونکہ S[0] کا درست ہونا معلوم ہے، اس لیے کوئی پہلی اسٹیٹ S[i] ہونی چاہیے جو غلط ہو جہاں S[i-1] درست ہو۔ تصدیق کرنے والا نوڈ انڈیکس i فراہم کرے گا، اس کے ساتھ "غلط ہونے کا ثبوت" (proof of invalidity) بھی ہوگا جو پیٹریشیا ٹری (Patricia tree) نوڈز کے سب سیٹ پر مشتمل ہوگا جنہیں APPLY(S[i-1],TX[i]) -> S[i] کو پروسیس کرنے کی ضرورت ہے۔ نوڈز ان نوڈز کو کمپیوٹیشن کے اس حصے کو چلانے کے لیے استعمال کر سکیں گے، اور دیکھیں گے کہ تیار کردہ S[i] فراہم کردہ S[i] سے میل نہیں کھاتی۔

ایک اور، زیادہ نفیس، حملے میں بدنیتی پر مبنی مائنرز کا نامکمل بلاکس شائع کرنا شامل ہوگا، لہذا یہ تعین کرنے کے لیے مکمل معلومات بھی موجود نہیں ہوں گی کہ آیا بلاکس درست ہیں یا نہیں۔ اس کا حل ایک چیلنج-رسپانس (challenge-response) پروٹوکول ہے: تصدیقی نوڈز ہدف ٹرانزیکشن انڈیکس کی شکل میں "چیلنجز" جاری کرتے ہیں، اور ایک نوڈ موصول ہونے پر ایک لائٹ نوڈ بلاک کو اس وقت تک ناقابل اعتبار سمجھتا ہے جب تک کہ کوئی دوسرا نوڈ، چاہے وہ مائنر ہو یا کوئی اور تصدیق کنندہ، درستگی کے ثبوت کے طور پر پیٹریشیا نوڈز کا سب سیٹ فراہم نہ کرے۔

نتیجہ

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

ایک صوابدیدی حالت کی تبدیلی کے فنکشن (arbitrary state transition function) کا تصور، جیسا کہ ایتھیریم پروٹوکول کے ذریعے نافذ کیا گیا ہے، ایک منفرد صلاحیت والے پلیٹ فارم کی فراہمی کرتا ہے؛ ڈیٹا اسٹوریج، جوئے یا فنانس میں ایپلیکیشنز کے ایک مخصوص سیٹ کے لیے بنائے گئے کلوزڈ-اینڈڈ، واحد مقصد والے پروٹوکول ہونے کے بجائے، ایتھیریم اپنے ڈیزائن کے لحاظ سے اوپن-اینڈڈ ہے، اور ہمارا ماننا ہے کہ یہ آنے والے سالوں میں بہت بڑی تعداد میں مالیاتی اور غیر مالیاتی دونوں پروٹوکولز کے لیے ایک بنیادی تہہ کے طور پر کام کرنے کے لیے انتہائی موزوں ہے۔

نوٹس اور مزید مطالعہ

نوٹس

1. ایک سمجھدار قاری یہ محسوس کر سکتا ہے کہ درحقیقت Bitcoin ایڈریس ایلیپٹک کرو (elliptic curve) پبلک کی (public key) کا ہیش (hash) ہوتا ہے، نہ کہ خود پبلک کی۔ تاہم، کرپٹوگرافک اصطلاح میں پب کی (pubkey) ہیش کو خود پبلک کی کے طور پر حوالہ دینا بالکل درست ہے۔ اس کی وجہ یہ ہے کہ Bitcoin کی کرپٹوگرافی کو ایک کسٹم ڈیجیٹل سگنیچر الگورتھم سمجھا جا سکتا ہے، جہاں پبلک کی ECC پب کی کے ہیش پر مشتمل ہوتی ہے، سگنیچر ECC پب کی اور ECC سگنیچر کے ملاپ پر مشتمل ہوتا ہے، اور تصدیقی الگورتھم میں سگنیچر میں موجود ECC پب کی کو پبلک کی کے طور پر فراہم کردہ ECC پب کی ہیش کے خلاف چیک کرنا اور پھر ECC پب کی کے خلاف ECC سگنیچر کی تصدیق کرنا شامل ہے۔
2. تکنیکی طور پر، پچھلے 11 بلاکس کا میڈین (median)۔
3. اندرونی طور پر، 2 اور "CHARLIE" دونوں نمبرز ہیں^fn3، جن میں سے مؤخر الذکر big-endian base 256 کی نمائندگی میں ہے۔ نمبرز کم از کم 0 اور زیادہ سے زیادہ 2²⁵⁶-1 ہو سکتے ہیں۔

مزید مطالعہ

1. انٹرینزک ویلیو (Intrinsic value) (opens in a new tab)
2. اسمارٹ پراپرٹی (opens in a new tab)
3. اسمارٹ کانٹریکٹس (opens in a new tab)
4. B-money (opens in a new tab)
5. دوبارہ قابل استعمال پروفز آف ورک (Reusable proofs of work) (opens in a new tab)
6. مالک کے اختیار کے ساتھ محفوظ پراپرٹی ٹائٹلز (opens in a new tab)
7. Bitcoin وائٹ پیپر (opens in a new tab)
8. Namecoin (opens in a new tab)
9. Zooko's triangle (opens in a new tab)
10. Colored coins وائٹ پیپر (opens in a new tab)
11. Mastercoin وائٹ پیپر (opens in a new tab)
12. ڈی سینٹرلائزڈ خود مختار کارپوریشنز، Bitcoin میگزین (opens in a new tab)
13. آسان پیمنٹ کی تصدیق (Simplified payment verification) (opens in a new tab)
14. Merkle ٹریز (opens in a new tab)
15. Patricia ٹریز (opens in a new tab)
16. GHOST (opens in a new tab)
17. StorJ اور خود مختار ایجنٹس، Jeff Garzik (opens in a new tab)
18. Turing فیسٹیول میں اسمارٹ پراپرٹی پر Mike Hearn (opens in a new tab)
19. Ethereum RLP
20. Ethereum Merkle Patricia ٹریز
21. Merkle sum ٹریز پر Peter Todd (opens in a new tab)

وائٹ پیپر کی تاریخ کے لیے، یہ وکی (opens in a new tab) دیکھیں۔

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