--- title: "ایتھیریم وائٹ پیپر" description: "ایتھیریم کا ایک تعارفی مقالہ، جو اس کے آغاز سے قبل ⁦2013⁩ میں شائع ہوا۔" lang: ur sidebarDepth: 2 hideEditButton: true authors: ["وٹالک بوٹیرن"] --- _اگرچہ یہ کئی سال پرانا ہے، لیکن ہم ذیل میں اصل مقالے کو برقرار رکھے ہوئے ہیں کیونکہ یہ ایک مفید حوالے اور [ایتھیریم](/) اور اس کے وژن کی درست نمائندگی کے طور پر کام کرتا ہے۔_ ## ایک اگلی نسل کا سمارٹ کنٹریکٹ اور غیر مرکزی ایپلی کیشن (dapp) پلیٹ فارم {#a-next-generation-smart-contract-and-decentralized-application-platform} ۲۰۰۹ میں ستوشی ناکاموتو کی جانب سے بٹ کوائن کی تیاری کو اکثر رقم اور کرنسی کے میدان میں ایک انقلابی پیش رفت قرار دیا جاتا ہے، جو کہ ایک ایسے ڈیجیٹل اثاثہ کی پہلی مثال ہے جس کی بیک وقت کوئی پشت پناہی یا "[اندرونی قدر](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it)" نہیں ہے اور نہ ہی کوئی مرکزی جاری کنندہ یا کنٹرولر ہے۔ تاہم، بٹ کوائن کے تجربے کا ایک اور، اور بلاشبہ زیادہ اہم حصہ، تقسیم شدہ اتفاق رائے کے ایک ٹول کے طور پر اس کی بنیادی بلاک چین ٹیکنالوجی ہے، اور اب تیزی سے توجہ بٹ کوائن کے اس دوسرے پہلو کی طرف مبذول ہونا شروع ہو گئی ہے۔ بلاک چین ٹیکنالوجی کی عام طور پر بیان کی جانے والی متبادل ایپلی کیشنز میں کسٹم کرنسیوں اور مالیاتی آلات کی نمائندگی کے لیے آن چین ڈیجیٹل اثاثوں کا استعمال ("[رنگین کوائنز](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)")، کسی بنیادی جسمانی ڈیوائس کی ملکیت ("[سمارٹ پراپرٹی](https://en.bitcoin.it/wiki/Smart_Property)")، ناقابلِ تبادلہ اثاثے جیسے کہ ڈومین نام ("[Namecoin](http://namecoin.org)")، اس کے علاوہ مزید پیچیدہ ایپلی کیشنز جن میں ڈیجیٹل اثاثوں کو براہ راست کوڈ کے ایک ایسے ٹکڑے کے ذریعے کنٹرول کیا جاتا ہے جو صوابدیدی اصولوں کو نافذ کرتا ہے ("[سمارٹ کنٹریکٹس](https://nakamotoinstitute.org/smart-contracts/)") یا یہاں تک کہ بلاک چین پر مبنی "[غیر مرکزی خود مختار تنظیمیں](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/)" (DAOs) شامل ہیں۔ ایتھیریم جو کچھ فراہم کرنے کا ارادہ رکھتا ہے وہ ایک ایسی بلاک چین ہے جس میں ایک بلٹ ان، مکمل طور پر تیار شدہ ٹیورنگ-مکمل (Turing-complete) پروگرامنگ زبان موجود ہو جسے "کنٹریکٹس" بنانے کے لیے استعمال کیا جا سکے جنہیں صوابدیدی حالت کی منتقلی کے فنکشنز کو انکوڈ کرنے کے لیے استعمال کیا جا سکتا ہے، جس سے صارفین کو محض چند لائنوں کے کوڈ میں لاجک لکھ کر اوپر بیان کردہ کسی بھی سسٹم کو بنانے کی اجازت ملتی ہے، اور ساتھ ہی بہت سے دوسرے سسٹمز جن کا ہم نے ابھی تک تصور بھی نہیں کیا ہے۔ ## بٹ کوائن اور موجودہ تصورات کا تعارف {#introduction-to-bitcoin-and-existing-concepts} ### تاریخ {#history} لامركزی ڈیجیٹل کرنسی کا تصور، نیز پراپرٹی رجسٹری جیسی متبادل ایپلی کیشنز، کئی دہائیوں سے موجود ہیں۔ 1980s اور 1990s کے گمنام ای-کیش پروٹوکولز، جو زیادہ تر Chaumian blinding کے نام سے مشہور ایک کرپٹوگرافک پرائمیٹو پر انحصار کرتے تھے، نے اعلیٰ درجے کی رازداری کے ساتھ ایک کرنسی فراہم کی، لیکن یہ پروٹوکولز ایک مرکزی ثالث پر انحصار کی وجہ سے زیادہ مقبولیت حاصل کرنے میں ناکام رہے۔ 1998 میں، وے ڈائی کی [b-money](https://nakamotoinstitute.org/b-money/) کمپیوٹیشنل پہیلیوں کو حل کرنے کے ساتھ ساتھ لامركزی اتفاق رائے کے ذریعے رقم بنانے کا خیال پیش کرنے والی پہلی تجویز بن گئی، لیکن اس تجویز میں اس بات کی تفصیلات کم تھیں کہ لامركزی اتفاق رائے کو حقیقت میں کیسے نافذ کیا جا سکتا ہے۔ 2005 میں، Hal Finney نے "[reusable proofs of work](https://nakamotoinstitute.org/finney/rpow/)" کا تصور متعارف کرایا، ایک ایسا نظام جو کرپٹو کرنسی کا تصور بنانے کے لیے b-money کے خیالات کو Adam Back کی کمپیوٹیشنل طور پر مشکل Hashcash پہیلیوں کے ساتھ استعمال کرتا ہے، لیکن ایک بار پھر بیک اینڈ کے طور پر قابل اعتماد کمپیوٹنگ پر انحصار کر کے مثالی معیار سے پیچھے رہ گیا۔ 2005 میں، Satoshi Nakamoto کی جانب سے پہلی بار ایک لامركزی کرنسی کو عملی طور پر نافذ کیا گیا، جس میں عوامی کلید کے علمِ تشفیر کے ذریعے ملکیت کے انتظام کے لیے قائم کردہ پرائمیٹوز کو ایک اتفاق رائے کے الگورتھم کے ساتھ ملایا گیا تاکہ یہ ٹریک رکھا جا سکے کہ سکوں کا مالک کون ہے، جسے "ثبوتِ کار (PoW)" کہا جاتا ہے۔ ثبوتِ کار (PoW) کے پیچھے کا طریقہ کار اس میدان میں ایک اہم پیش رفت تھی کیونکہ اس نے بیک وقت دو مسائل حل کیے۔ پہلا، اس نے ایک سادہ اور معتدل حد تک موثر اتفاق رائے کا الگورتھم فراہم کیا، جس سے نیٹ ورک میں موجود نوڈز کو بٹ کوائن لیجر کی حالت میں کینونیکل اپ ڈیٹس کے ایک سیٹ پر اجتماعی طور پر متفق ہونے کی اجازت ملی۔ دوسرا، اس نے اتفاق رائے کے عمل میں آزادانہ داخلے کی اجازت دینے کا ایک طریقہ کار فراہم کیا، جس سے یہ فیصلہ کرنے کا سیاسی مسئلہ حل ہو گیا کہ اتفاق رائے پر اثر انداز ہونے کا حق کسے ملتا ہے، جبکہ بیک وقت sybil حملوں کو بھی روکا گیا۔ یہ شرکت میں ایک رسمی رکاوٹ، جیسے کسی خاص فہرست میں ایک منفرد ہستی کے طور پر رجسٹر ہونے کے تقاضے کو، ایک اقتصادی رکاوٹ سے بدل کر ایسا کرتا ہے - اتفاق رائے کے ووٹنگ کے عمل میں ایک واحد نوڈ کا وزن براہ راست اس کمپیوٹنگ پاور کے متناسب ہوتا ہے جو وہ نوڈ لاتا ہے۔ اس کے بعد سے، ایک متبادل نقطہ نظر تجویز کیا گیا ہے جسے _حصہ داری کا ثبوت (PoS)_ کہا جاتا ہے، جو کسی نوڈ کے وزن کا حساب اس کی کرنسی ہولڈنگز کے متناسب لگاتا ہے نہ کہ کمپیوٹیشنل وسائل کے؛ ان دونوں طریقوں کی نسبتی خوبیوں پر بحث اس مقالے کے دائرہ کار سے باہر ہے لیکن یہ نوٹ کیا جانا چاہیے کہ دونوں طریقوں کو کرپٹو کرنسی کی ریڑھ کی ہڈی کے طور پر استعمال کیا جا سکتا ہے۔ ### بٹ کوائن بطور اسٹیٹ ٹرانزیشن سسٹم {#bitcoin-as-a-state-transition-system} ![Ethereum state transition](./ethereum-state-transition.png) تکنیکی نقطہ نظر سے، بٹ کوائن جیسی کرپٹو کرنسی کے لیجر کو ایک اسٹیٹ ٹرانزیشن سسٹم کے طور پر سوچا جا سکتا ہے، جہاں ایک "حالت" ہوتی ہے جو تمام موجودہ بٹ کوائنز کی ملکیت کی حیثیت پر مشتمل ہوتی ہے اور ایک "اسٹیٹ ٹرانزیشن فنکشن" ہوتا ہے جو ایک حالت اور ایک ٹرانزیکشن لیتا ہے اور ایک نئی حالت آؤٹ پٹ کرتا ہے جو اس کا نتیجہ ہوتی ہے۔ مثال کے طور پر، ایک معیاری بینکنگ سسٹم میں، حالت ایک بیلنس شیٹ ہوتی ہے، ایک ٹرانزیکشن $X کو A سے B میں منتقل کرنے کی درخواست ہوتی ہے، اور اسٹیٹ ٹرانزیشن فنکشن A کے اکاؤنٹ میں $X کی کمی کرتا ہے اور B کے اکاؤنٹ میں $X کا اضافہ کرتا ہے۔ اگر A کے اکاؤنٹ میں پہلے ہی $X سے کم رقم ہے، تو اسٹیٹ ٹرانزیشن فنکشن ایک ایرر (error) لوٹاتا ہے۔ لہذا، کوئی بھی اسے باقاعدہ طور پر اس طرح بیان کر سکتا ہے: ``` APPLY(S,TX) -> S' or ERROR ``` اوپر بیان کردہ بینکنگ سسٹم میں: ```js APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 } ``` لیکن: ```js APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR ``` بٹ کوائن میں "حالت" ان تمام سکوں کا مجموعہ ہے (تکنیکی طور پر، "غیر خرچ شدہ ٹرانزیکشن آؤٹ پٹس" یا UTXO) جو بنائے گئے ہیں اور ابھی تک خرچ نہیں ہوئے ہیں، ہر UTXO کی ایک مالیت اور ایک مالک ہوتا ہے (جس کی تعریف ایک 20-byte پتہ سے ہوتی ہے جو بنیادی طور پر ایک کرپٹوگرافک عوامی کلید ہے[fn1](#notes))۔ ایک ٹرانزیکشن میں ایک یا زیادہ ان پٹس ہوتے ہیں، ہر ان پٹ میں ایک موجودہ UTXO کا حوالہ اور مالک کے پتہ سے وابستہ نجی کلید کے ذریعے تیار کردہ ایک کرپٹوگرافک دستخط ہوتا ہے، اور ایک یا زیادہ آؤٹ پٹس ہوتے ہیں، ہر آؤٹ پٹ میں حالت میں شامل کیے جانے والے ایک نئے UTXO پر مشتمل ہوتا ہے۔ اسٹیٹ ٹرانزیشن فنکشن `APPLY(S,TX) -> S'` کو تقریباً اس طرح بیان کیا جا سکتا ہے:
  1. TX میں ہر ان پٹ کے لیے:
    • اگر حوالہ دیا گیا UTXO S میں نہیں ہے، تو ایک ایرر لوٹائیں۔
    • اگر فراہم کردہ دستخط UTXO کے مالک سے میل نہیں کھاتا، تو ایک ایرر لوٹائیں۔
  2. اگر تمام ان پٹ UTXO کی مالیت کا مجموعہ تمام آؤٹ پٹ UTXO کی مالیت کے مجموعے سے کم ہے، تو ایک ایرر لوٹائیں۔
  3. تمام ان پٹ UTXO کو ہٹا کر اور تمام آؤٹ پٹ UTXO کو شامل کر کے S لوٹائیں۔
پہلے قدم کا پہلا نصف حصہ ٹرانزیکشن بھیجنے والوں کو وہ سکے خرچ کرنے سے روکتا ہے جو موجود نہیں ہیں، پہلے قدم کا دوسرا نصف حصہ ٹرانزیکشن بھیجنے والوں کو دوسرے لوگوں کے سکے خرچ کرنے سے روکتا ہے، اور دوسرا قدم قدر کے تحفظ کو نافذ کرتا ہے۔ اسے ادائیگی کے لیے استعمال کرنے کے لیے، پروٹوکول درج ذیل ہے۔ فرض کریں کہ ایلس باب کو 11.7 BTC بھیجنا چاہتی ہے۔ سب سے پہلے، ایلس اپنے پاس موجود دستیاب UTXO کا ایک سیٹ تلاش کرے گی جس کا کل کم از کم 11.7 BTC ہو۔ حقیقت پسندانہ طور پر، ایلس بالکل 11.7 BTC حاصل نہیں کر پائے گی؛ فرض کریں کہ وہ سب سے چھوٹی رقم جو حاصل کر سکتی ہے وہ 6+4+2=12 ہے۔ پھر وہ ان تین ان پٹس اور دو آؤٹ پٹس کے ساتھ ایک ٹرانزیکشن بناتی ہے۔ پہلا آؤٹ پٹ 11.7 BTC ہوگا جس کا مالک باب کا پتہ ہوگا، اور دوسرا آؤٹ پٹ بقیہ 0.3 BTC "بقیہ رقم (change)" ہوگا، جس کی مالک خود ایلس ہوگی۔ ### کان کنی {#mining} ![Ethereum blocks](./ethereum-blocks.png) اگر ہمیں ایک قابل اعتماد مرکزی سروس تک رسائی حاصل ہوتی، تو اس نظام کو نافذ کرنا بہت آسان ہوتا؛ اسے بالکل اسی طرح کوڈ کیا جا سکتا تھا جیسا کہ بیان کیا گیا ہے، حالت کا ٹریک رکھنے کے لیے ایک مرکزی سرور کی ہارڈ ڈرائیو کا استعمال کرتے ہوئے۔ تاہم، بٹ کوائن کے ساتھ ہم ایک لامركزی کرنسی کا نظام بنانے کی کوشش کر رہے ہیں، لہذا ہمیں اسٹیٹ ٹرانزیکشن سسٹم کو ایک اتفاق رائے کے نظام کے ساتھ ملانے کی ضرورت ہوگی تاکہ یہ یقینی بنایا جا سکے کہ ہر کوئی ٹرانزیکشنز کی ترتیب پر متفق ہے۔ بٹ کوائن کے لامركزی اتفاق رائے کے عمل میں نیٹ ورک میں موجود نوڈز کو مسلسل ٹرانزیکشنز کے پیکجز تیار کرنے کی کوشش کرنے کی ضرورت ہوتی ہے جنہیں "بلاک" کہا جاتا ہے۔ نیٹ ورک کا مقصد ہر دس منٹ میں تقریباً ایک بلاک تیار کرنا ہے، جس میں ہر بلاک میں ایک ٹائم اسٹیمپ، ایک نانس، پچھلے بلاک کا حوالہ (یعنی ہیش) اور ان تمام ٹرانزیکشنز کی فہرست ہوتی ہے جو پچھلے بلاک کے بعد سے ہوئی ہیں۔ وقت گزرنے کے ساتھ، یہ ایک مستقل، ہمیشہ بڑھتی ہوئی، "بلاک چین" بناتا ہے جو بٹ کوائن لیجر کی تازہ ترین حالت کی نمائندگی کرنے کے لیے مسلسل اپ ڈیٹ ہوتی ہے۔ یہ چیک کرنے کا الگورتھم کہ آیا کوئی بلاک درست ہے، اس پیراڈائم میں اس طرح بیان کیا گیا ہے: 1. چیک کریں کہ آیا بلاک کے ذریعے حوالہ دیا گیا پچھلا بلاک موجود ہے اور درست ہے۔ 2. چیک کریں کہ بلاک کا ٹائم اسٹیمپ پچھلے بلاک کے ٹائم اسٹیمپ سے زیادہ ہے[fn2](#notes) اور مستقبل میں 2 گھنٹے سے کم ہے۔ 3. چیک کریں کہ بلاک پر ثبوتِ کار (PoW) درست ہے۔ 4. فرض کریں کہ `S[0]` پچھلے بلاک کے اختتام پر حالت ہے۔ 5. فرض کریں کہ `TX` بلاک کی ٹرانزیکشن لسٹ ہے جس میں `n` ٹرانزیکشنز ہیں۔ `0...n-1` میں تمام `i` کے لیے، `S[i+1] = APPLY(S[i],TX[i])` سیٹ کریں۔ اگر کوئی ایپلیکیشن ایرر لوٹاتی ہے، تو باہر نکلیں اور false لوٹائیں۔ 6. true لوٹائیں، اور اس بلاک کے اختتام پر `S[n]` کو حالت کے طور پر رجسٹر کریں۔ بنیادی طور پر، بلاک میں موجود ہر ٹرانزیکشن کو ٹرانزیکشن کے عمل میں آنے سے پہلے کی کینونیکل حالت سے کسی نئی حالت میں ایک درست اسٹیٹ ٹرانزیشن فراہم کرنی چاہیے۔ نوٹ کریں کہ حالت کو کسی بھی طرح سے بلاک میں انکوڈ نہیں کیا گیا ہے؛ یہ خالصتاً ایک تجرید (abstraction) ہے جسے توثیق کرنے والے نوڈ کے ذریعے یاد رکھا جانا ہے اور اسے کسی بھی بلاک کے لیے صرف ابتدائی حالت سے شروع کر کے اور ہر بلاک میں ہر ٹرانزیکشن کو ترتیب وار لاگو کر کے (محفوظ طریقے سے) شمار کیا جا سکتا ہے۔ مزید برآں، نوٹ کریں کہ کان کن جس ترتیب سے ٹرانزیکشنز کو بلاک میں شامل کرتا ہے وہ اہمیت رکھتا ہے؛ اگر کسی بلاک میں دو ٹرانزیکشنز A اور B اس طرح ہیں کہ B ایک UTXO خرچ کرتا ہے جو A کے ذریعے بنایا گیا ہے، تو بلاک درست ہوگا اگر A، B سے پہلے آتا ہے لیکن بصورت دیگر نہیں۔ مندرجہ بالا فہرست میں موجود ایک درستگی کی شرط جو دوسرے سسٹمز میں نہیں پائی جاتی وہ "ثبوتِ کار (PoW)" کا تقاضا ہے۔ قطعی شرط یہ ہے کہ ہر بلاک کا ڈبل-SHA256 ہیش، جسے 256-bit نمبر کے طور پر سمجھا جاتا ہے، ایک متحرک طور پر ایڈجسٹ کیے گئے ہدف سے کم ہونا چاہیے، جو اس تحریر کے وقت تقریباً 2187 ہے۔ اس کا مقصد بلاک کی تخلیق کو کمپیوٹیشنل طور پر "مشکل" بنانا ہے، اس طرح sybil حملہ آوروں کو پوری بلاک چین کو اپنے حق میں دوبارہ بنانے سے روکنا ہے۔ چونکہ SHA-256 کو مکمل طور پر غیر متوقع سیڈو-رینڈم فنکشن کے طور پر ڈیزائن کیا گیا ہے، اس لیے ایک درست بلاک بنانے کا واحد طریقہ صرف ٹرائل اینڈ ایرر ہے، بار بار نانس میں اضافہ کرنا اور یہ دیکھنا کہ آیا نیا ہیش میل کھاتا ہے۔ \~2187 کے موجودہ ہدف پر، ایک درست بلاک ملنے سے پہلے نیٹ ورک کو اوسطاً \~269 کوششیں کرنی چاہئیں؛ عام طور پر، ہدف کو نیٹ ورک کے ذریعے ہر 2016 بلاکس کے بعد دوبارہ کیلیبریٹ کیا جاتا ہے تاکہ اوسطاً ہر دس منٹ میں نیٹ ورک میں کسی نوڈ کے ذریعے ایک نیا بلاک تیار کیا جائے۔ کان کنوں کو اس کمپیوٹیشنل کام کا معاوضہ دینے کے لیے، ہر بلاک کا کان کن ایک ایسی ٹرانزیکشن شامل کرنے کا حقدار ہے جو انہیں کہیں سے بھی 25 BTC دے۔ مزید برآں، اگر کسی ٹرانزیکشن کے ان پٹس میں اس کے آؤٹ پٹس کی نسبت زیادہ کل مالیت ہے، تو یہ فرق بھی کان کن کو "لین دین کی فیس" کے طور پر جاتا ہے۔ اتفاق سے، یہ واحد طریقہ کار بھی ہے جس کے ذریعے BTC کا اجراء ہوتا ہے؛ ابتدائی حالت میں بالکل کوئی سکے نہیں تھے۔ کان کنی کے مقصد کو بہتر طور پر سمجھنے کے لیے، آئیے جائزہ لیتے ہیں کہ کسی بدنیتی پر مبنی حملہ آور کی صورت میں کیا ہوتا ہے۔ چونکہ بٹ کوائن کا بنیادی علمِ تشفیر محفوظ سمجھا جاتا ہے، اس لیے حملہ آور بٹ کوائن سسٹم کے اس ایک حصے کو نشانہ بنائے گا جو براہ راست علمِ تشفیر سے محفوظ نہیں ہے: ٹرانزیکشنز کی ترتیب۔ حملہ آور کی حکمت عملی سادہ ہے: 1. کسی پروڈکٹ (ترجیحاً تیزی سے ڈیلیور ہونے والی ڈیجیٹل چیز) کے بدلے میں ایک تاجر کو 100 BTC بھیجیں۔ 2. پروڈکٹ کی ڈیلیوری کا انتظار کریں۔ 3. وہی 100 BTC خود کو بھیجنے والی ایک اور ٹرانزیکشن تیار کریں۔ 4. نیٹ ورک کو یہ باور کرانے کی کوشش کریں کہ اس کی خود کو کی گئی ٹرانزیکشن وہ تھی جو پہلے آئی تھی۔ ایک بار جب مرحلہ (1) ہو جاتا ہے، تو چند منٹوں کے بعد کوئی کان کن اس ٹرانزیکشن کو ایک بلاک میں شامل کر لے گا، فرض کریں بلاک نمبر 270000۔ تقریباً ایک گھنٹے کے بعد، اس بلاک کے بعد چین میں مزید پانچ بلاکس شامل ہو چکے ہوں گے، جن میں سے ہر ایک بلاک بالواسطہ طور پر اس ٹرانزیکشن کی طرف اشارہ کر رہا ہوگا اور اس طرح اس کی "تصدیق" کر رہا ہوگا۔ اس مقام پر، تاجر ادائیگی کو حتمی تسلیم کر لے گا اور پروڈکٹ ڈیلیور کر دے گا؛ چونکہ ہم فرض کر رہے ہیں کہ یہ ایک ڈیجیٹل چیز ہے، اس لیے ڈیلیوری فوری ہوتی ہے۔ اب، حملہ آور ایک اور ٹرانزیکشن بناتا ہے جس میں وہ 100 BTC خود کو بھیجتا ہے۔ اگر حملہ آور اسے محض عملی استعمال (in the wild) کے لیے جاری کر دیتا ہے، تو ٹرانزیکشن پر کارروائی نہیں کی جائے گی؛ کان کن `APPLY(S,TX)` چلانے کی کوشش کریں گے اور دیکھیں گے کہ `TX` ایک ایسا UTXO استعمال کرتا ہے جو اب حالت میں نہیں ہے۔ لہذا اس کے بجائے، حملہ آور بلاک چین کا ایک "فورک" بناتا ہے، جس کی شروعات بلاک 270000 کا ایک اور ورژن مائن کر کے ہوتی ہے جو اسی بلاک 269999 کو پیرنٹ کے طور پر اشارہ کرتا ہے لیکن پرانی ٹرانزیکشن کی جگہ نئی ٹرانزیکشن کے ساتھ۔ چونکہ بلاک کا ڈیٹا مختلف ہے، اس لیے اس کے لیے ثبوتِ کار (PoW) کو دوبارہ کرنے کی ضرورت ہوتی ہے۔ مزید برآں، حملہ آور کے بلاک 270000 کے نئے ورژن کا ہیش مختلف ہے، اس لیے اصل بلاکس 270001 سے 270005 اس کی طرف "اشارہ" نہیں کرتے؛ اس طرح، اصل چین اور حملہ آور کی نئی چین بالکل الگ ہیں۔ اصول یہ ہے کہ فورک میں سب سے لمبی بلاک چین کو سچ مانا جاتا ہے، اور اس لیے جائز کان کن 270005 چین پر کام کریں گے جبکہ حملہ آور اکیلا 270000 چین پر کام کر رہا ہوگا۔ حملہ آور کو اپنی بلاک چین کو سب سے لمبا بنانے کے لیے، اسے باقی تمام نیٹ ورک کے مجموعے سے زیادہ کمپیوٹیشنل پاور کی ضرورت ہوگی تاکہ وہ ان تک پہنچ سکے (اس لیے، "۵۱٪ حملہ")۔ ### مرکل ٹری {#merkle-trees} ![SPV in Bitcoin](./spv-bitcoin.png) _بائیں: کسی برانچ کی درستگی کا ثبوت دینے کے لیے مرکل ٹری میں صرف چند نوڈز پیش کرنا کافی ہے۔_ _دائیں: مرکل ٹری کے کسی بھی حصے کو تبدیل کرنے کی کوئی بھی کوشش بالآخر چین میں اوپر کہیں نہ کہیں عدم تسلسل کا باعث بنے گی۔_ بٹ کوائن کی اسکیل ایبلٹی کی ایک اہم خصوصیت یہ ہے کہ بلاک کو ملٹی لیول ڈیٹا اسٹرکچر میں اسٹور کیا جاتا ہے۔ کسی بلاک کا "ہیش" دراصل صرف بلاک ہیڈر کا ہیش ہوتا ہے، جو تقریباً 200-byte کا ڈیٹا ہوتا ہے جس میں ٹائم اسٹیمپ، نانس، پچھلے بلاک کا ہیش اور بلاک میں موجود تمام ٹرانزیکشنز کو اسٹور کرنے والے مرکل ٹری نامی ڈیٹا اسٹرکچر کا روٹ ہیش شامل ہوتا ہے۔ مرکل ٹری بائنری ٹری کی ایک قسم ہے، جو نوڈز کے ایک سیٹ پر مشتمل ہوتا ہے جس میں ٹری کے نچلے حصے میں بڑی تعداد میں لیف نوڈز ہوتے ہیں جن میں بنیادی ڈیٹا ہوتا ہے، درمیانی نوڈز کا ایک سیٹ ہوتا ہے جہاں ہر نوڈ اپنے دو چلڈرن کا ہیش ہوتا ہے، اور آخر میں ایک واحد روٹ نوڈ ہوتا ہے، جو اپنے دو چلڈرن کے ہیش سے بھی بنتا ہے، جو ٹری کے "اوپری حصے" کی نمائندگی کرتا ہے۔ مرکل ٹری کا مقصد بلاک میں موجود ڈیٹا کو ٹکڑوں میں ڈیلیور کرنے کی اجازت دینا ہے: ایک نوڈ ایک ذریعے سے صرف بلاک کا ہیڈر ڈاؤن لوڈ کر سکتا ہے، دوسرے ذریعے سے ٹری کا وہ چھوٹا حصہ جو ان سے متعلق ہے، اور پھر بھی اسے یقین دہانی ہو سکتی ہے کہ تمام ڈیٹا درست ہے۔ اس کے کام کرنے کی وجہ یہ ہے کہ ہیشز اوپر کی طرف پھیلتے ہیں: اگر کوئی بدنیتی پر مبنی صارف مرکل ٹری کے نچلے حصے میں جعلی ٹرانزیکشن کو تبدیل کرنے کی کوشش کرتا ہے، تو یہ تبدیلی اوپر والے نوڈ میں تبدیلی کا سبب بنے گی، اور پھر اس سے اوپر والے نوڈ میں تبدیلی کا سبب بنے گی، بالآخر ٹری کے روٹ کو اور اس وجہ سے بلاک کے ہیش کو تبدیل کر دے گی، جس کی وجہ سے پروٹوکول اسے بالکل مختلف بلاک کے طور پر رجسٹر کرے گا (تقریباً یقینی طور پر ایک غلط ثبوتِ کار (PoW) کے ساتھ)۔ مرکل ٹری پروٹوکول طویل مدتی پائیداری کے لیے بلاشبہ ضروری ہے۔ بٹ کوائن نیٹ ورک میں ایک "مکمل نوڈ"، جو ہر بلاک کی پوری تفصیلات کو اسٹور اور پروسیس کرتا ہے، اپریل 2014 تک بٹ کوائن نیٹ ورک میں تقریباً 15 GB ڈسک اسپیس لیتا ہے، اور ہر ماہ ایک گیگا بائٹ سے زیادہ بڑھ رہا ہے۔ فی الحال، یہ کچھ ڈیسک ٹاپ کمپیوٹرز کے لیے قابل عمل ہے اور فونز کے لیے نہیں، اور مستقبل میں بعد میں صرف کاروبار اور شوقین افراد ہی حصہ لے سکیں گے۔ ایک پروٹوکول جسے "آسان ادائیگی کی توثیق" (SPV) کہا جاتا ہے، نوڈز کی ایک اور کلاس کو موجود رہنے کی اجازت دیتا ہے، جسے "لائٹ نوڈ" کہا جاتا ہے، جو بلاک ہیڈرز ڈاؤن لوڈ کرتے ہیں، بلاک ہیڈرز پر ثبوتِ کار (PoW) کی توثیق کرتے ہیں، اور پھر صرف ان "برانچز" کو ڈاؤن لوڈ کرتے ہیں جو ان سے متعلقہ ٹرانزیکشنز سے وابستہ ہیں۔ یہ لائٹ نوڈز کو سیکیورٹی کی مضبوط ضمانت کے ساتھ یہ تعین کرنے کی اجازت دیتا ہے کہ کسی بھی بٹ کوائن ٹرانزیکشن کی حیثیت، اور ان کا موجودہ بیلنس کیا ہے، جبکہ وہ پوری بلاک چین کا صرف ایک بہت چھوٹا حصہ ڈاؤن لوڈ کرتے ہیں۔ ### متبادل بلاک چین ایپلی کیشنز {#alternative-blockchain-applications} بنیادی بلاک چین کے خیال کو لے کر اسے دوسرے تصورات پر لاگو کرنے کے خیال کی بھی ایک طویل تاریخ ہے۔ 2005 میں، نک سابو نے "[مالک کے اختیار کے ساتھ محفوظ پراپرٹی ٹائٹلز](https://nakamotoinstitute.org/library/secure-property-titles/)" کا تصور پیش کیا، ایک دستاویز جس میں یہ بیان کیا گیا ہے کہ کس طرح "ریپلیکیٹڈ ڈیٹا بیس ٹیکنالوجی میں نئی پیشرفت" ایک بلاک چین پر مبنی نظام کی اجازت دے گی تاکہ یہ رجسٹری اسٹور کی جا سکے کہ کس زمین کا مالک کون ہے، جس سے ہومسٹیڈنگ، منفی قبضہ اور جارجیائی لینڈ ٹیکس جیسے تصورات سمیت ایک وسیع فریم ورک تیار ہوگا۔ تاہم، بدقسمتی سے اس وقت کوئی موثر ریپلیکیٹڈ ڈیٹا بیس سسٹم دستیاب نہیں تھا، اور اس لیے پروٹوکول کو کبھی عملی طور پر نافذ نہیں کیا گیا۔ تاہم، 2009 کے بعد، ایک بار جب بٹ کوائن کا لامركزی اتفاق رائے تیار ہو گیا تو تیزی سے کئی متبادل ایپلی کیشنز ابھرنا شروع ہو گئیں۔ - **Namecoin** - 2010 میں بنایا گیا، [Namecoin](https://namecoin.org/) کو بہترین طور پر ایک لامركزی نام کے اندراج کے ڈیٹا بیس کے طور پر بیان کیا جا سکتا ہے۔ Tor، بٹ کوائن اور BitMessage جیسے لامركزی پروٹوکولز میں، اکاؤنٹس کی شناخت کا کوئی طریقہ ہونا چاہیے تاکہ دوسرے لوگ ان کے ساتھ بات چیت کر سکیں، لیکن تمام موجودہ حلوں میں دستیاب واحد قسم کا شناخت کنندہ ایک سیڈو-رینڈم ہیش ہے جیسے `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`۔ مثالی طور پر، کوئی بھی "george" جیسے نام کے ساتھ اکاؤنٹ رکھنا چاہے گا۔ تاہم، مسئلہ یہ ہے کہ اگر ایک شخص "george" کے نام سے اکاؤنٹ بنا سکتا ہے تو کوئی اور بھی اسی عمل کو استعمال کر کے اپنے لیے "george" رجسٹر کر سکتا ہے اور ان کا روپ دھار سکتا ہے۔ اس کا واحد حل فرسٹ-ٹو-فائل پیراڈائم ہے، جہاں پہلا رجسٹر کرنے والا کامیاب ہوتا ہے اور دوسرا ناکام ہو جاتا ہے - ایک ایسا مسئلہ جو بٹ کوائن کے اتفاق رائے کے پروٹوکول کے لیے بالکل موزوں ہے۔ Namecoin اس طرح کے خیال کو استعمال کرتے ہوئے نام کے اندراج کے نظام کا سب سے پرانا، اور سب سے کامیاب نفاذ ہے۔ - **رنگین سکے (Colored coins)** - [رنگین سکوں](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) کا مقصد ایک ایسے پروٹوکول کے طور پر کام کرنا ہے جو لوگوں کو اپنی ڈیجیٹل کرنسیاں بنانے کی اجازت دے - یا، ایک یونٹ والی کرنسی کے اہم معمولی معاملے میں، بٹ کوائن بلاک چین پر ڈیجیٹل ٹوکن بنانے کی اجازت دے۔ رنگین سکوں کے پروٹوکول میں، کوئی شخص ایک مخصوص بٹ کوائن UTXO کو عوامی طور پر ایک رنگ تفویض کر کے ایک نئی کرنسی "جاری" کرتا ہے، اور پروٹوکول بار بار دوسرے UTXO کے رنگ کو اسی رنگ کے طور پر بیان کرتا ہے جو ان ان پٹس کا رنگ تھا جنہیں انہیں بنانے والی ٹرانزیکشن نے خرچ کیا تھا (مخلوط رنگ کے ان پٹس کی صورت میں کچھ خاص اصول لاگو ہوتے ہیں)۔ یہ صارفین کو ایسے بٹوے (wallets) برقرار رکھنے کی اجازت دیتا ہے جن میں صرف ایک مخصوص رنگ کے UTXO ہوں اور انہیں باقاعدہ بٹ کوائنز کی طرح بھیج سکیں، بلاک چین کے ذریعے پیچھے کی طرف جا کر کسی بھی موصول ہونے والے UTXO کے رنگ کا تعین کر سکیں۔ - **Metacoins** - میٹا کوائن کے پیچھے خیال یہ ہے کہ ایک ایسا پروٹوکول ہو جو بٹ کوائن کے اوپر موجود ہو، میٹا کوائن ٹرانزیکشنز کو اسٹور کرنے کے لیے بٹ کوائن ٹرانزیکشنز کا استعمال کرے لیکن اس کا اسٹیٹ ٹرانزیشن فنکشن مختلف ہو، `APPLY'`۔ چونکہ میٹا کوائن پروٹوکول غلط میٹا کوائن ٹرانزیکشنز کو بٹ کوائن بلاک چین میں ظاہر ہونے سے نہیں روک سکتا، اس لیے ایک اصول شامل کیا گیا ہے کہ اگر `APPLY'(S,TX)` ایک ایرر لوٹاتا ہے، تو پروٹوکول ڈیفالٹ طور پر `APPLY'(S,TX) = S` پر چلا جاتا ہے۔ یہ ایک صوابدیدی کرپٹو کرنسی پروٹوکول بنانے کے لیے ایک آسان طریقہ کار فراہم کرتا ہے، ممکنہ طور پر ان جدید خصوصیات کے ساتھ جنہیں خود بٹ کوائن کے اندر نافذ نہیں کیا جا سکتا، لیکن بہت کم ترقیاتی لاگت کے ساتھ کیونکہ کان کنی اور نیٹ ورکنگ کی پیچیدگیوں کو پہلے ہی بٹ کوائن پروٹوکول کے ذریعے سنبھالا جا چکا ہے۔ میٹا کوائنز کا استعمال مالیاتی کنٹریکٹس کی کچھ کلاسز، نام کے اندراج اور لامركزی تبادلہ کو نافذ کرنے کے لیے کیا گیا ہے۔ اس طرح، عام طور پر، اتفاق رائے کا پروٹوکول بنانے کے دو طریقے ہیں: ایک آزاد نیٹ ورک بنانا، اور بٹ کوائن کے اوپر ایک پروٹوکول بنانا۔ پہلا طریقہ، اگرچہ Namecoin جیسی ایپلی کیشنز کے معاملے میں معقول حد تک کامیاب ہے، لیکن اسے نافذ کرنا مشکل ہے؛ ہر انفرادی نفاذ کو ایک آزاد بلاک چین کو بوٹ اسٹریپ کرنے کی ضرورت ہوتی ہے، نیز تمام ضروری اسٹیٹ ٹرانزیشن اور نیٹ ورکنگ کوڈ کو بنانے اور جانچنے کی ضرورت ہوتی ہے۔ مزید برآں، ہم پیش گوئی کرتے ہیں کہ لامركزی اتفاق رائے کی ٹیکنالوجی کے لیے ایپلی کیشنز کا سیٹ پاور لاء ڈسٹری بیوشن کی پیروی کرے گا جہاں ایپلی کیشنز کی اکثریت اتنی چھوٹی ہوگی کہ ان کی اپنی بلاک چین کی ضرورت نہیں ہوگی، اور ہم نوٹ کرتے ہیں کہ لامركزی ایپلی کیشنز کی بڑی کلاسز موجود ہیں، خاص طور پر لامركزی خود مختار تنظیمیں، جنہیں ایک دوسرے کے ساتھ بات چیت کرنے کی ضرورت ہے۔ دوسری طرف، بٹ کوائن پر مبنی نقطہ نظر میں یہ خامی ہے کہ اسے بٹ کوائن کی آسان ادائیگی کی توثیق کی خصوصیات وراثت میں نہیں ملتیں۔ SPV بٹ کوائن کے لیے کام کرتا ہے کیونکہ یہ بلاک چین کی گہرائی کو درستگی کے پراکسی کے طور پر استعمال کر سکتا ہے؛ کسی موڑ پر، ایک بار جب کسی ٹرانزیکشن کے آباؤ اجداد کافی پیچھے چلے جاتے ہیں، تو یہ کہنا محفوظ ہے کہ وہ جائز طور پر حالت کا حصہ تھے۔ دوسری طرف، بلاک چین پر مبنی میٹا پروٹوکولز بلاک چین کو مجبور نہیں کر سکتے کہ وہ ایسی ٹرانزیکشنز کو شامل نہ کرے جو ان کے اپنے پروٹوکولز کے تناظر میں درست نہیں ہیں۔ لہذا، ایک مکمل طور پر محفوظ SPV میٹا پروٹوکول کے نفاذ کو یہ تعین کرنے کے لیے بٹ کوائن بلاک چین کے آغاز تک پیچھے کی طرف اسکین کرنے کی ضرورت ہوگی کہ آیا کچھ ٹرانزیکشنز درست ہیں یا نہیں۔ فی الحال، بٹ کوائن پر مبنی میٹا پروٹوکولز کے تمام "لائٹ" نفاذ ڈیٹا فراہم کرنے کے لیے ایک قابل اعتماد سرور پر انحصار کرتے ہیں، جو بلاشبہ ایک انتہائی غیر موزوں نتیجہ ہے خاص طور پر جب کرپٹو کرنسی کے بنیادی مقاصد میں سے ایک اعتماد کی ضرورت کو ختم کرنا ہے۔ ### اسکرپٹنگ {#scripting} یہاں تک کہ کسی بھی ایکسٹینشن کے بغیر، بٹ کوائن پروٹوکول دراصل "سمارٹ کنٹریکٹ" کے تصور کے ایک کمزور ورژن کی سہولت فراہم کرتا ہے۔ بٹ کوائن میں UTXO کی ملکیت نہ صرف ایک عوامی کلید کے پاس ہو سکتی ہے، بلکہ ایک سادہ اسٹیک پر مبنی پروگرامنگ زبان میں ظاہر کیے گئے ایک زیادہ پیچیدہ اسکرپٹ کے پاس بھی ہو سکتی ہے۔ اس پیراڈائم میں، اس UTXO کو خرچ کرنے والی ٹرانزیکشن کو ایسا ڈیٹا فراہم کرنا چاہیے جو اسکرپٹ کو مطمئن کرے۔ درحقیقت، بنیادی عوامی کلید کی ملکیت کا طریقہ کار بھی ایک اسکرپٹ کے ذریعے نافذ کیا جاتا ہے: اسکرپٹ ایک بیضوی منحنی دستخط کو ان پٹ کے طور پر لیتا ہے، ٹرانزیکشن اور UTXO کے مالک پتہ کے خلاف اس کی توثیق کرتا ہے، اور اگر توثیق کامیاب ہو جاتی ہے تو 1 لوٹاتا ہے اور بصورت دیگر 0 لوٹاتا ہے۔ مختلف اضافی استعمال کے معاملات کے لیے دیگر، زیادہ پیچیدہ، اسکرپٹس موجود ہیں۔ مثال کے طور پر، کوئی ایک ایسا اسکرپٹ بنا سکتا ہے جسے توثیق کرنے کے لیے دی گئی تین نجی کلیدوں میں سے دو کے دستخطوں کا تقاضا ہو ("ملٹی سگ")، یہ ایک ایسا سیٹ اپ ہے جو کارپوریٹ اکاؤنٹس، محفوظ بچت اکاؤنٹس اور کچھ مرچنٹ ایسکرو حالات کے لیے مفید ہے۔ اسکرپٹس کا استعمال کمپیوٹیشنل مسائل کے حل کے لیے باؤنٹیز ادا کرنے کے لیے بھی کیا جا سکتا ہے، اور کوئی ایک ایسا اسکرپٹ بھی بنا سکتا ہے جو کچھ اس طرح کہے "یہ بٹ کوائن UTXO آپ کا ہے اگر آپ ایک SPV ثبوت فراہم کر سکیں کہ آپ نے مجھے اس مالیت کی Dogecoin ٹرانزیکشن بھیجی ہے"، جو بنیادی طور پر لامركزی کراس-کرپٹو کرنسی تبادلہ کی اجازت دیتا ہے۔ تاہم، بٹ کوائن میں نافذ کردہ اسکرپٹنگ زبان کی کئی اہم حدود ہیں: - **ٹیورنگ-کمپلیٹنس کی کمی** - یعنی، اگرچہ کمپیوٹیشن کا ایک بڑا سب سیٹ ہے جسے بٹ کوائن اسکرپٹنگ زبان سپورٹ کرتی ہے، لیکن یہ تقریباً ہر چیز کو سپورٹ نہیں کرتی۔ جو اہم زمرہ غائب ہے وہ لوپس (loops) ہے۔ یہ ٹرانزیکشن کی توثیق کے دوران لامحدود لوپس سے بچنے کے لیے کیا جاتا ہے؛ نظریاتی طور پر یہ اسکرپٹ پروگرامرز کے لیے ایک قابل عبور رکاوٹ ہے، کیونکہ کسی بھی لوپ کو if اسٹیٹمنٹ کے ساتھ بنیادی کوڈ کو کئی بار دہرا کر نقل کیا جا سکتا ہے، لیکن اس سے ایسے اسکرپٹس بنتے ہیں جو جگہ کے لحاظ سے بہت غیر موثر ہوتے ہیں۔ مثال کے طور پر، ایک متبادل بیضوی منحنی دستخطی الگورتھم کو نافذ کرنے کے لیے ممکنہ طور پر 256 بار بار ضرب کے راؤنڈز کی ضرورت ہوگی جو سب انفرادی طور پر کوڈ میں شامل ہوں۔ - **ویلیو-بلائنڈنیس (Value-blindness)** - UTXO اسکرپٹ کے لیے اس رقم پر باریک بینی سے کنٹرول فراہم کرنے کا کوئی طریقہ نہیں ہے جسے نکالا جا سکتا ہے۔ مثال کے طور پر، اوریکل کنٹریکٹ کا ایک طاقتور استعمال ہیجنگ کنٹریکٹ ہوگا، جہاں A اور B $1000 مالیت کے BTC ڈالتے ہیں اور 30 دنوں کے بعد اسکرپٹ $1000 مالیت کے BTC A کو اور باقی B کو بھیجتا ہے۔ اس کے لیے USD میں 1 BTC کی قدر کا تعین کرنے کے لیے ایک اوریکل کی ضرورت ہوگی، لیکن اس کے باوجود یہ اب دستیاب مکمل طور پر مرکزی حلوں کے مقابلے میں اعتماد اور بنیادی ڈھانچے کی ضرورت کے لحاظ سے ایک بہت بڑی بہتری ہے۔ تاہم، چونکہ UTXO سب کچھ یا کچھ نہیں (all-or-nothing) ہوتے ہیں، اس لیے اسے حاصل کرنے کا واحد طریقہ مختلف مالیت کے بہت سے UTXO رکھنے (مثلاً، 30 تک ہر k کے لیے 2k کا ایک UTXO) اور اوریکل سے یہ منتخب کروانے کا انتہائی غیر موثر ہیک ہے کہ کون سا UTXO A کو بھیجنا ہے اور کون سا B کو۔ - **حالت کی کمی** - UTXO یا تو خرچ کیے جا سکتے ہیں یا غیر خرچ شدہ رہ سکتے ہیں؛ ملٹی اسٹیج کنٹریکٹس یا اسکرپٹس کے لیے کوئی موقع نہیں ہے جو اس سے آگے کوئی اور اندرونی حالت رکھیں۔ اس سے ملٹی اسٹیج آپشنز کنٹریکٹس، لامركزی تبادلے کی پیشکشیں یا دو مرحلوں والے کرپٹوگرافک کمٹمنٹ پروٹوکولز (محفوظ کمپیوٹیشنل باؤنٹیز کے لیے ضروری) بنانا مشکل ہو جاتا ہے۔ اس کا مطلب یہ بھی ہے کہ UTXO کو صرف سادہ، یک وقتی کنٹریکٹس بنانے کے لیے استعمال کیا جا سکتا ہے نہ کہ زیادہ پیچیدہ "اسٹیٹ فل" کنٹریکٹس جیسے لامركزی تنظیمیں، اور یہ میٹا پروٹوکولز کو نافذ کرنا مشکل بناتا ہے۔ بائنری حالت کے ساتھ ویلیو-بلائنڈنیس کا مطلب یہ بھی ہے کہ ایک اور اہم ایپلی کیشن، انخلا کی حد، ناممکن ہے۔ - **بلاک چین-بلائنڈنیس (Blockchain-blindness)** - UTXO بلاک چین ڈیٹا جیسے نانس، ٹائم اسٹیمپ اور پچھلے بلاک ہیش سے ناواقف ہوتے ہیں۔ یہ اسکرپٹنگ زبان کو بے ترتیبی کے ممکنہ طور پر قیمتی ذریعہ سے محروم کر کے جوئے، اور کئی دیگر زمروں میں ایپلی کیشنز کو سختی سے محدود کرتا ہے۔ اس طرح، ہم کرپٹو کرنسی کے اوپر جدید ایپلی کیشنز بنانے کے تین طریقے دیکھتے ہیں: ایک نئی بلاک چین بنانا، بٹ کوائن کے اوپر اسکرپٹنگ کا استعمال کرنا، اور بٹ کوائن کے اوپر ایک میٹا پروٹوکول بنانا۔ ایک نئی بلاک چین بنانا فیچر سیٹ بنانے میں لامحدود آزادی کی اجازت دیتا ہے، لیکن ترقی کے وقت، بوٹ اسٹریپنگ کی کوشش اور سیکیورٹی کی قیمت پر۔ اسکرپٹنگ کا استعمال نافذ کرنے اور معیاری بنانے میں آسان ہے، لیکن اس کی صلاحیتیں بہت محدود ہیں، اور میٹا پروٹوکولز، اگرچہ آسان ہیں، اسکیل ایبلٹی میں خامیوں کا شکار ہیں۔ ایتھیریم کے ساتھ، ہم ایک ایسا متبادل فریم ورک بنانے کا ارادہ رکھتے ہیں جو ترقی کی آسانی کے ساتھ ساتھ اور بھی مضبوط لائٹ کلائنٹ خصوصیات میں اس سے بھی زیادہ فوائد فراہم کرے، جبکہ ایک ہی وقت میں ایپلی کیشنز کو ایک اقتصادی ماحول اور بلاک چین سیکیورٹی کا اشتراک کرنے کی اجازت دے۔ ## ایتھیریم {#ethereum} ایتھیریم کا ارادہ غیر مرکزی ایپلی کیشنز (dapps) بنانے کے لیے ایک متبادل پروٹوکول تیار کرنا ہے، جو سمجھوتوں کا ایک مختلف مجموعہ فراہم کرتا ہے جس کے بارے میں ہمارا ماننا ہے کہ یہ غیر مرکزی ایپلی کیشنز کی ایک بڑی کلاس کے لیے بہت مفید ثابت ہوگا، خاص طور پر ان حالات پر زور دیتے ہوئے جہاں تیز رفتار ترقی کا وقت، چھوٹی اور شاذ و نادر ہی استعمال ہونے والی ایپلی کیشنز کے لیے سیکیورٹی، اور مختلف ایپلی کیشنز کی انتہائی موثر انداز میں بات چیت کرنے کی صلاحیت اہم ہو۔ ایتھیریم یہ کام ایک ایسی چیز بنا کر کرتا ہے جو بنیادی طور پر حتمی تجریدی بنیادی تہہ ہے: ایک بلاک چین جس میں بلٹ ان ٹیورنگ-مکمل پروگرامنگ زبان ہے، جو کسی کو بھی سمارٹ کنٹریکٹس اور غیر مرکزی ایپلی کیشنز لکھنے کی اجازت دیتی ہے جہاں وہ ملکیت، ٹرانزیکشن کے فارمیٹس اور حالت کی منتقلی کے فنکشنز کے لیے اپنے من مانے اصول بنا سکتے ہیں۔ Namecoin کا ایک بنیادی ورژن کوڈ کی دو لائنوں میں لکھا جا سکتا ہے، اور دیگر پروٹوکولز جیسے کرنسیاں اور شہرت کے نظام بیس سے کم لائنوں میں بنائے جا سکتے ہیں۔ سمارٹ کنٹریکٹس، کرپٹوگرافک "باکسز" جن میں قدر ہوتی ہے اور وہ اسے صرف اسی صورت میں غیر مقفل کرتے ہیں جب کچھ شرائط پوری ہوں، انہیں بھی پلیٹ فارم کے اوپر بنایا جا سکتا ہے، جس میں بٹ کوائن اسکرپٹنگ کی پیش کردہ طاقت سے کہیں زیادہ طاقت ہوتی ہے کیونکہ اس میں ٹیورنگ-مکمل ہونے، قدر کی آگاہی، بلاک چین کی آگاہی اور حالت کی اضافی طاقتیں شامل ہیں۔ ### ایتھیریم اکاؤنٹس {#ethereum-accounts} ایتھیریم میں، حالت ان اشیاء پر مشتمل ہوتی ہے جنہیں "اکاؤنٹس" کہا جاتا ہے، جس میں ہر اکاؤنٹ کا 20-byte پتہ ہوتا ہے اور حالت کی منتقلی اکاؤنٹس کے درمیان قدر اور معلومات کی براہ راست منتقلی ہوتی ہے۔ ایک ایتھیریم اکاؤنٹ میں چار فیلڈز ہوتے ہیں: - **نانس**، ایک کاؤنٹر جو اس بات کو یقینی بنانے کے لیے استعمال ہوتا ہے کہ ہر ٹرانزیکشن پر صرف ایک بار کارروائی کی جا سکے - اکاؤنٹ کا موجودہ **ایتھر بیلنس** - اکاؤنٹ کا **کنٹریکٹ کوڈ**، اگر موجود ہو - اکاؤنٹ کی **اسٹوریج** (پہلے سے طے شدہ طور پر خالی) "ایتھر" ایتھیریم کا بنیادی اندرونی کرپٹو-ایندھن ہے، اور اسے لین دین کی فیس ادا کرنے کے لیے استعمال کیا جاتا ہے۔ عام طور پر، اکاؤنٹس کی دو اقسام ہیں: **بیرونی ملکیت والے اکاؤنٹس**، جو نجی کلیدوں کے ذریعے کنٹرول کیے جاتے ہیں، اور **کنٹریکٹ اکاؤنٹس**، جو ان کے کنٹریکٹ کوڈ کے ذریعے کنٹرول کیے جاتے ہیں۔ بیرونی ملکیت والے اکاؤنٹ میں کوئی کوڈ نہیں ہوتا، اور کوئی بھی ٹرانزیکشن بنا کر اور اس پر دستخط کر کے بیرونی ملکیت والے اکاؤنٹ سے پیغامات بھیج سکتا ہے؛ کنٹریکٹ اکاؤنٹ میں، جب بھی کنٹریکٹ اکاؤنٹ کو کوئی پیغام موصول ہوتا ہے تو اس کا کوڈ فعال ہو جاتا ہے، جس سے وہ اندرونی اسٹوریج کو پڑھنے اور لکھنے اور بدلے میں دوسرے پیغامات بھیجنے یا کنٹریکٹ بنانے کے قابل ہو جاتا ہے۔ واضح رہے کہ ایتھیریم میں "کنٹریکٹس" کو ایسی چیز کے طور پر نہیں دیکھا جانا چاہیے جسے "پورا" کیا جائے یا جس کی "تعمیل" کی جائے؛ بلکہ، وہ "خود مختار ایجنٹس" کی طرح ہیں جو ایتھیریم کے ایگزیکیوشن ماحول کے اندر رہتے ہیں، جب کسی پیغام یا ٹرانزیکشن کے ذریعے انہیں "چھیڑا" جاتا ہے تو وہ ہمیشہ کوڈ کا ایک مخصوص حصہ چلاتے ہیں، اور مستقل متغیرات کا ٹریک رکھنے کے لیے ان کا اپنے ایتھر بیلنس اور اپنے کلید/قدر کے اسٹور پر براہ راست کنٹرول ہوتا ہے۔ ### پیغامات اور ٹرانزیکشنز {#messages-and-transactions} ایتھیریم میں "ٹرانزیکشن" کی اصطلاح اس دستخط شدہ ڈیٹا پیکج کے لیے استعمال ہوتی ہے جو بیرونی ملکیت والے اکاؤنٹ سے بھیجے جانے والے پیغام کو اسٹور کرتا ہے۔ ٹرانزیکشنز میں شامل ہیں: - پیغام کا وصول کنندہ - بھیجنے والے کی شناخت کرنے والا دستخط - بھیجنے والے سے وصول کنندہ کو منتقل کیے جانے والے ایتھر کی مقدار - ایک اختیاری ڈیٹا فیلڈ - ایک `STARTGAS` قدر، جو ان کمپیوٹیشنل مراحل کی زیادہ سے زیادہ تعداد کی نمائندگی کرتی ہے جو ٹرانزیکشن کے ایگزیکیوشن کو لینے کی اجازت ہے - ایک `GASPRICE` قدر، جو اس فیس کی نمائندگی کرتی ہے جو بھیجنے والا فی کمپیوٹیشنل مرحلہ ادا کرتا ہے پہلے تین معیاری فیلڈز ہیں جن کی کسی بھی کرپٹو کرنسی میں توقع کی جاتی ہے۔ ڈیٹا فیلڈ کا پہلے سے طے شدہ طور پر کوئی فنکشن نہیں ہوتا، لیکن ورچوئل مشین میں ایک آپ کوڈ ہوتا ہے جس کا استعمال کرتے ہوئے ایک کنٹریکٹ ڈیٹا تک رسائی حاصل کر سکتا ہے؛ ایک مثال کے طور پر، اگر کوئی کنٹریکٹ آن-بلاک چین ڈومین رجسٹریشن سروس کے طور پر کام کر رہا ہے، تو وہ اسے پاس کیے جانے والے ڈیٹا کی تشریح اس طرح کرنا چاہ سکتا ہے کہ اس میں دو "فیلڈز" شامل ہیں، پہلا فیلڈ رجسٹر کرنے کے لیے ایک ڈومین ہے اور دوسرا فیلڈ وہ IP پتہ ہے جس پر اسے رجسٹر کرنا ہے۔ کنٹریکٹ پیغام کے ڈیٹا سے ان اقدار کو پڑھے گا اور انہیں مناسب طریقے سے اسٹوریج میں رکھے گا۔ `STARTGAS` اور `GASPRICE` فیلڈز ایتھیریم کے اینٹی-ڈینائل آف سروس ماڈل کے لیے انتہائی اہم ہیں۔ کوڈ میں حادثاتی یا مخالفانہ لامحدود لوپس یا دیگر کمپیوٹیشنل ضیاع کو روکنے کے لیے، ہر ٹرانزیکشن کے لیے یہ حد مقرر کرنا ضروری ہے کہ وہ کوڈ ایگزیکیوشن کے کتنے کمپیوٹیشنل مراحل استعمال کر سکتی ہے۔ کمپیوٹیشن کی بنیادی اکائی "گیس" ہے؛ عام طور پر، ایک کمپیوٹیشنل مرحلے کی قیمت 1 gas ہوتی ہے، لیکن کچھ آپریشنز میں گیس کی زیادہ مقدار خرچ ہوتی ہے کیونکہ وہ کمپیوٹیشنل طور پر زیادہ مہنگے ہوتے ہیں، یا اس ڈیٹا کی مقدار میں اضافہ کرتے ہیں جسے حالت کے حصے کے طور پر اسٹور کیا جانا چاہیے۔ ٹرانزیکشن ڈیٹا میں ہر بائٹ کے لیے 5 gas کی فیس بھی ہوتی ہے۔ فیس کے نظام کا ارادہ یہ ہے کہ حملہ آور کو ہر اس وسائل کے لیے متناسب طور پر ادائیگی کرنے کا تقاضا کیا جائے جو وہ استعمال کرتے ہیں، بشمول کمپیوٹیشن، بینڈوتھ اور اسٹوریج؛ لہذا، کوئی بھی ٹرانزیکشن جو نیٹ ورک کو ان میں سے کسی بھی وسائل کی زیادہ مقدار استعمال کرنے کی طرف لے جاتی ہے، اس کی گیس فیس اس اضافے کے تقریباً متناسب ہونی چاہیے۔ ### پیغامات {#messages} کنٹریکٹس میں دوسرے کنٹریکٹس کو "پیغامات" بھیجنے کی صلاحیت ہوتی ہے۔ پیغامات ورچوئل اشیاء ہیں جو کبھی سیریلائز نہیں ہوتے اور صرف ایتھیریم ایگزیکیوشن ماحول میں موجود ہوتے ہیں۔ ایک پیغام میں شامل ہیں: - پیغام بھیجنے والا (مضمر) - پیغام کا وصول کنندہ - پیغام کے ساتھ منتقل کیے جانے والے ایتھر کی مقدار - ایک اختیاری ڈیٹا فیلڈ - ایک `STARTGAS` قدر بنیادی طور پر، ایک پیغام ٹرانزیکشن کی طرح ہوتا ہے، سوائے اس کے کہ یہ کسی بیرونی اداکار کے بجائے کنٹریکٹ کے ذریعے تیار کیا جاتا ہے۔ ایک پیغام اس وقت تیار ہوتا ہے جب فی الحال کوڈ چلانے والا کنٹریکٹ `CALL` آپ کوڈ چلاتا ہے، جو ایک پیغام تیار کرتا ہے اور اسے چلاتا ہے۔ ٹرانزیکشن کی طرح، ایک پیغام وصول کنندہ اکاؤنٹ کو اپنا کوڈ چلانے کی طرف لے جاتا ہے۔ اس طرح، کنٹریکٹس کے دوسرے کنٹریکٹس کے ساتھ بالکل اسی طرح تعلقات ہو سکتے ہیں جس طرح بیرونی اداکاروں کے ہو سکتے ہیں۔ واضح رہے کہ کسی ٹرانزیکشن یا کنٹریکٹ کے ذریعے تفویض کردہ گیس الاؤنس اس ٹرانزیکشن اور تمام ذیلی ایگزیکیوشنز کے ذریعے استعمال ہونے والی کل گیس پر لاگو ہوتا ہے۔ مثال کے طور پر، اگر ایک بیرونی اداکار A، B کو 1000 gas کے ساتھ ایک ٹرانزیکشن بھیجتا ہے، اور B، C کو پیغام بھیجنے سے پہلے 600 gas استعمال کرتا ہے، اور C کا اندرونی ایگزیکیوشن واپس آنے سے پہلے 300 gas استعمال کرتا ہے، تو B گیس ختم ہونے سے پہلے مزید 100 gas خرچ کر سکتا ہے۔ ### ایتھیریم حالت کی منتقلی کا فنکشن {#ethereum-state-transition-function} ![Ether state transition](./ether-state-transition.png) ایتھیریم حالت کی منتقلی کے فنکشن، `APPLY(S,TX) -> S'` کی تعریف اس طرح کی جا سکتی ہے: 1. چیک کریں کہ آیا ٹرانزیکشن درست طریقے سے تشکیل دی گئی ہے (یعنی، اس میں اقدار کی صحیح تعداد ہے)، دستخط درست ہے، اور نانس بھیجنے والے کے اکاؤنٹ میں موجود نانس سے میل کھاتا ہے۔ اگر نہیں، تو ایک خرابی واپس کریں۔ 2. ٹرانزیکشن فیس کا حساب `STARTGAS * GASPRICE` کے طور پر لگائیں، اور دستخط سے بھیجنے والے کا پتہ متعین کریں۔ بھیجنے والے کے اکاؤنٹ کے بیلنس سے فیس منہا کریں اور بھیجنے والے کے نانس میں اضافہ کریں۔ اگر خرچ کرنے کے لیے کافی بیلنس نہیں ہے، تو ایک خرابی واپس کریں۔ 3. `GAS = STARTGAS` کو شروع کریں، اور ٹرانزیکشن میں بائٹس کی ادائیگی کے لیے فی بائٹ گیس کی ایک خاص مقدار نکال لیں۔ 4. ٹرانزیکشن کی قدر کو بھیجنے والے کے اکاؤنٹ سے وصول کرنے والے اکاؤنٹ میں منتقل کریں۔ اگر وصول کرنے والا اکاؤنٹ ابھی تک موجود نہیں ہے، تو اسے بنائیں۔ اگر وصول کرنے والا اکاؤنٹ ایک کنٹریکٹ ہے، تو کنٹریکٹ کا کوڈ یا تو مکمل ہونے تک چلائیں یا اس وقت تک چلائیں جب تک کہ ایگزیکیوشن کی گیس ختم نہ ہو جائے۔ 5. اگر قدر کی منتقلی ناکام ہو گئی کیونکہ بھیجنے والے کے پاس کافی رقم نہیں تھی، یا کوڈ ایگزیکیوشن کی گیس ختم ہو گئی، تو فیس کی ادائیگی کے علاوہ تمام حالت کی تبدیلیوں کو ریورٹ کریں، اور فیس کو کان کن کے اکاؤنٹ میں شامل کریں۔ 6. بصورت دیگر، تمام بقیہ گیس کی فیس بھیجنے والے کو واپس کریں، اور استعمال شدہ گیس کے لیے ادا کی گئی فیس کان کن کو بھیجیں۔ مثال کے طور پر، فرض کریں کہ کنٹریکٹ کا کوڈ یہ ہے: ```py if !self.storage[calldataload(0)]: self.storage[calldataload(0)] = calldataload(32) ``` واضح رہے کہ حقیقت میں کنٹریکٹ کوڈ نچلی سطح کے EVM کوڈ میں لکھا جاتا ہے؛ یہ مثال وضاحت کے لیے ہماری اعلیٰ سطحی زبانوں میں سے ایک، Serpent میں لکھی گئی ہے، اور اسے EVM کوڈ میں مرتب کیا جا سکتا ہے۔ فرض کریں کہ کنٹریکٹ کی اسٹوریج خالی شروع ہوتی ہے، اور ایک ٹرانزیکشن 10 ether قدر، 2000 gas، 0.001 ether گیس کی قیمت، اور 64 bytes ڈیٹا کے ساتھ بھیجی جاتی ہے، جس میں بائٹس 0-31 نمبر `2` کی نمائندگی کرتے ہیں اور بائٹس 32-63 سٹرنگ `CHARLIE`[fn3](#notes) کی نمائندگی کرتے ہیں۔ اس صورت میں حالت کی منتقلی کے فنکشن کا عمل درج ذیل ہے: 1. چیک کریں کہ ٹرانزیکشن درست اور صحیح طریقے سے تشکیل دی گئی ہے۔ 2. چیک کریں کہ ٹرانزیکشن بھیجنے والے کے پاس کم از کم 2000 \* 0.001 = 2 ether ہیں۔ اگر ایسا ہے، تو بھیجنے والے کے اکاؤنٹ سے 2 ether منہا کریں۔ 3. gas = 2000 شروع کریں؛ یہ فرض کرتے ہوئے کہ ٹرانزیکشن 170 bytes لمبی ہے اور بائٹ فیس 5 ہے، 850 منہا کریں تاکہ 1150 gas باقی رہ جائے۔ 4. بھیجنے والے کے اکاؤنٹ سے مزید 10 ether منہا کریں، اور اسے کنٹریکٹ کے اکاؤنٹ میں شامل کریں۔ 5. کوڈ چلائیں۔ اس صورت میں، یہ آسان ہے: یہ چیک کرتا ہے کہ آیا اشاریہ `2` پر کنٹریکٹ کی اسٹوریج استعمال کی گئی ہے، دیکھتا ہے کہ ایسا نہیں ہے، اور اس لیے یہ اشاریہ `2` پر اسٹوریج کو `CHARLIE` کی قدر پر سیٹ کرتا ہے۔ فرض کریں کہ اس میں 187 gas لگتی ہے، لہذا گیس کی بقیہ مقدار 1150 - 187 = 963 ہے 6. بھیجنے والے کے اکاؤنٹ میں 963 \* 0.001 = 0.963 ether واپس شامل کریں، اور نتیجے میں آنے والی حالت واپس کریں۔ اگر ٹرانزیکشن کے وصول کرنے والے سرے پر کوئی کنٹریکٹ نہیں تھا، تو کل ٹرانزیکشن فیس محض فراہم کردہ `GASPRICE` کو بائٹس میں ٹرانزیکشن کی لمبائی سے ضرب دینے کے برابر ہوگی، اور ٹرانزیکشن کے ساتھ بھیجا گیا ڈیٹا غیر متعلقہ ہوگا۔ واضح رہے کہ پیغامات ریورٹس کے لحاظ سے ٹرانزیکشنز کے مساوی کام کرتے ہیں: اگر کسی پیغام کے ایگزیکیوشن کی گیس ختم ہو جاتی ہے، تو اس پیغام کا ایگزیکیوشن، اور اس ایگزیکیوشن کے ذریعے متحرک ہونے والے دیگر تمام ایگزیکیوشنز، ریورٹ ہو جاتے ہیں، لیکن پیرنٹ ایگزیکیوشنز کو ریورٹ ہونے کی ضرورت نہیں ہوتی۔ اس کا مطلب ہے کہ ایک کنٹریکٹ کے لیے دوسرے کنٹریکٹ کو کال کرنا "محفوظ" ہے، کیونکہ اگر A، B کو G گیس کے ساتھ کال کرتا ہے تو A کے ایگزیکیوشن میں زیادہ سے زیادہ G گیس ضائع ہونے کی ضمانت دی جاتی ہے۔ آخر میں، واضح رہے کہ ایک آپ کوڈ، `CREATE` ہے، جو ایک کنٹریکٹ بناتا ہے؛ اس کے ایگزیکیوشن کا طریقہ کار عام طور پر `CALL` سے ملتا جلتا ہے، سوائے اس کے کہ ایگزیکیوشن کا آؤٹ پٹ نئے بنائے گئے کنٹریکٹ کا کوڈ متعین کرتا ہے۔ ### کوڈ ایگزیکیوشن {#code-execution} ایتھیریم کنٹریکٹس میں کوڈ ایک نچلی سطح کی، اسٹیک پر مبنی بائٹ کوڈ زبان میں لکھا جاتا ہے، جسے "ایتھیریم ورچوئل مشین کوڈ" یا "EVM کوڈ" کہا جاتا ہے۔ کوڈ بائٹس کی ایک سیریز پر مشتمل ہوتا ہے، جہاں ہر بائٹ ایک آپریشن کی نمائندگی کرتا ہے۔ عام طور پر، کوڈ ایگزیکیوشن ایک لامحدود لوپ ہے جو موجودہ پروگرام کاؤنٹر (جو صفر سے شروع ہوتا ہے) پر بار بار آپریشن کرنے اور پھر پروگرام کاؤنٹر میں ایک کا اضافہ کرنے پر مشتمل ہوتا ہے، جب تک کہ کوڈ کے اختتام تک نہ پہنچ جائے یا کوئی خرابی یا `STOP` یا `RETURN` ہدایت کا پتہ نہ چل جائے۔ آپریشنز کو ڈیٹا اسٹور کرنے کے لیے تین قسم کی جگہ تک رسائی حاصل ہوتی ہے: - **اسٹیک**، ایک لاسٹ-اِن-فرسٹ-آؤٹ کنٹینر جس میں اقدار کو پش اور پاپ کیا جا سکتا ہے - **میموری**، ایک لامحدود طور پر قابل توسیع بائٹ سرنی - کنٹریکٹ کی طویل مدتی **اسٹوریج**، ایک کلید/قدر کا اسٹور۔ اسٹیک اور میموری کے برعکس، جو کمپیوٹیشن ختم ہونے کے بعد ری سیٹ ہو جاتے ہیں، اسٹوریج طویل مدت تک برقرار رہتی ہے۔ کوڈ آنے والے پیغام کی قدر، بھیجنے والے اور ڈیٹا کے ساتھ ساتھ بلاک ہیڈر کے ڈیٹا تک بھی رسائی حاصل کر سکتا ہے، اور کوڈ آؤٹ پٹ کے طور پر ڈیٹا کی بائٹ سرنی بھی واپس کر سکتا ہے۔ EVM کوڈ کا رسمی ایگزیکیوشن ماڈل حیران کن طور پر آسان ہے۔ جب ایتھیریم ورچوئل مشین چل رہی ہوتی ہے، تو اس کی مکمل کمپیوٹیشنل حالت کی تعریف ٹوپل `(block_state, transaction, message, code, memory, stack, pc, gas)` کے ذریعے کی جا سکتی ہے، جہاں `block_state` عالمی حالت ہے جس میں تمام اکاؤنٹس شامل ہیں اور اس میں بیلنس اور اسٹوریج شامل ہیں۔ ایگزیکیوشن کے ہر دور کے آغاز میں، موجودہ ہدایت `code` کا `pc`واں بائٹ لے کر تلاش کی جاتی ہے (یا 0 اگر `pc >= len(code)`)، اور ہر ہدایت کی اپنی تعریف ہوتی ہے کہ یہ ٹوپل کو کیسے متاثر کرتی ہے۔ مثال کے طور پر، `ADD` اسٹیک سے دو آئٹمز کو پاپ کرتا ہے اور ان کے مجموعے کو پش کرتا ہے، `gas` کو 1 سے کم کرتا ہے اور `pc` کو 1 سے بڑھاتا ہے، اور `SSTORE` اسٹیک سے اوپر والے دو آئٹمز کو پاپ کرتا ہے اور دوسرے آئٹم کو پہلے آئٹم کے ذریعے بتائے گئے اشاریہ پر کنٹریکٹ کی اسٹوریج میں داخل کرتا ہے۔ اگرچہ جسٹ-اِن-ٹائم کمپائلیشن کے ذریعے ایتھیریم ورچوئل مشین کے ایگزیکیوشن کو بہتر بنانے کے بہت سے طریقے ہیں، لیکن ایتھیریم کا بنیادی نفاذ کوڈ کی چند سو لائنوں میں کیا جا سکتا ہے۔ ### بلاک چین اور کان کنی {#blockchain-and-mining} ![Ethereum apply block diagram](./ethereum-apply-block-diagram.png) ایتھیریم بلاک چین کئی لحاظ سے بٹ کوائن بلاک چین سے ملتی جلتی ہے، حالانکہ اس میں کچھ اختلافات ہیں۔ بلاک چین کے فن تعمیر کے حوالے سے ایتھیریم اور بٹ کوائن کے درمیان بنیادی فرق یہ ہے کہ، بٹ کوائن کے برعکس، ایتھیریم بلاکس میں ٹرانزیکشن کی فہرست اور تازہ ترین حالت دونوں کی ایک کاپی ہوتی ہے۔ اس کے علاوہ، دو دیگر اقدار، بلاک نمبر اور دشواری، بھی بلاک میں اسٹور کی جاتی ہیں۔ ایتھیریم میں بنیادی بلاک کی توثیق کا الگورتھم درج ذیل ہے: 1. چیک کریں کہ آیا حوالہ دیا گیا پچھلا بلاک موجود ہے اور درست ہے۔ 2. چیک کریں کہ بلاک کا ٹائم اسٹیمپ حوالہ دیے گئے پچھلے بلاک سے زیادہ ہے اور مستقبل میں 15 منٹ سے کم ہے 3. چیک کریں کہ بلاک نمبر، دشواری، ٹرانزیکشن روٹ، انکل روٹ اور گیس کی حد (مختلف نچلی سطح کے ایتھیریم کے مخصوص تصورات) درست ہیں۔ 4. چیک کریں کہ بلاک پر ثبوتِ کار (PoW) درست ہے۔ 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` کا مرکل ٹری روٹ بلاک ہیڈر میں فراہم کردہ حتمی حالت کے روٹ کے برابر ہے۔ اگر ایسا ہے، تو بلاک درست ہے؛ بصورت دیگر، یہ درست نہیں ہے۔ یہ نقطہ نظر پہلی نظر میں انتہائی غیر موثر لگ سکتا ہے، کیونکہ اسے ہر بلاک کے ساتھ پوری حالت کو اسٹور کرنے کی ضرورت ہوتی ہے، لیکن حقیقت میں کارکردگی بٹ کوائن کے مقابلے کی ہونی چاہیے۔ اس کی وجہ یہ ہے کہ حالت کو ٹری کے ڈھانچے میں اسٹور کیا جاتا ہے، اور ہر بلاک کے بعد ٹری کے صرف ایک چھوٹے سے حصے کو تبدیل کرنے کی ضرورت ہوتی ہے۔ اس طرح، عام طور پر، دو ملحقہ بلاکس کے درمیان ٹری کی اکثریت ایک جیسی ہونی چاہیے، اور اس لیے ڈیٹا کو ایک بار اسٹور کیا جا سکتا ہے اور پوائنٹرز (یعنی، ذیلی ٹریز کے ہیشز) کا استعمال کرتے ہوئے دو بار حوالہ دیا جا سکتا ہے۔ اسے پورا کرنے کے لیے ایک خاص قسم کا ٹری جسے "پیٹریشیا ٹری" کہا جاتا ہے استعمال کیا جاتا ہے، جس میں مرکل ٹری کے تصور میں ایک ترمیم شامل ہے جو نوڈز کو موثر طریقے سے داخل کرنے اور حذف کرنے کی اجازت دیتی ہے، اور نہ صرف تبدیل کرنے کی۔ مزید برآں، چونکہ حالت کی تمام معلومات آخری بلاک کا حصہ ہیں، اس لیے پوری بلاک چین کی تاریخ کو اسٹور کرنے کی ضرورت نہیں ہے - ایک ایسی حکمت عملی جس کا اگر بٹ کوائن پر اطلاق کیا جا سکے، تو اس کا حساب لگایا جا سکتا ہے کہ یہ جگہ میں 5-20x بچت فراہم کرے گی۔ ایک عام طور پر پوچھا جانے والا سوال یہ ہے کہ فزیکل ہارڈویئر کے لحاظ سے کنٹریکٹ کوڈ "کہاں" چلایا جاتا ہے۔ اس کا ایک آسان جواب ہے: کنٹریکٹ کوڈ کو چلانے کا عمل حالت کی منتقلی کے فنکشن کی تعریف کا حصہ ہے، جو بلاک کی توثیق کے الگورتھم کا حصہ ہے، لہذا اگر کسی ٹرانزیکشن کو بلاک `B` میں شامل کیا جاتا ہے تو اس ٹرانزیکشن کے ذریعے پیدا ہونے والا کوڈ ایگزیکیوشن ان تمام نوڈز کے ذریعے چلایا جائے گا، اب اور مستقبل میں، جو بلاک `B` کو ڈاؤن لوڈ اور توثیق کرتے ہیں۔ ## ایپلی کیشنز {#applications} عام طور پر، ایتھیریم پر تین قسم کی ایپلی کیشنز ہوتی ہیں۔ پہلی قسم مالیاتی ایپلی کیشنز کی ہے، جو صارفین کو اپنے پیسوں کا استعمال کرتے ہوئے کنٹریکٹس کا انتظام کرنے اور ان میں شامل ہونے کے زیادہ طاقتور طریقے فراہم کرتی ہیں۔ اس میں ذیلی کرنسیاں، مالیاتی مشتقات (financial derivatives)، ہیجنگ کنٹریکٹس، بچت کے بٹوے، وصیتیں، اور بالآخر مکمل روزگار کے کنٹریکٹس کی کچھ اقسام بھی شامل ہیں۔ دوسری قسم نیم مالیاتی ایپلی کیشنز کی ہے، جہاں پیسہ تو شامل ہوتا ہے لیکن جو کچھ کیا جا رہا ہے اس کا ایک بڑا غیر مالیاتی پہلو بھی ہوتا ہے؛ اس کی ایک بہترین مثال کمپیوٹیشنل مسائل کے حل کے لیے خودکار طور پر نافذ ہونے والے انعامات (bounties) ہیں۔ آخر میں، آن لائن ووٹنگ اور لامركزی گورننس جیسی ایپلی کیشنز ہیں جو بالکل بھی مالیاتی نہیں ہیں۔ ### ٹوکن سسٹمز {#token-systems} آن بلاک چین ٹوکن سسٹمز کی بہت سی ایپلی کیشنز ہیں جن میں USD یا سونے جیسے اثاثوں کی نمائندگی کرنے والی ذیلی کرنسیوں سے لے کر کمپنی کے حصص، سمارٹ پراپرٹی کی نمائندگی کرنے والے انفرادی ٹوکنز، محفوظ ناقابلِ جعل سازی کوپنز، اور یہاں تک کہ ایسے ٹوکن سسٹمز بھی شامل ہیں جن کا روایتی قدر سے کوئی تعلق نہیں ہوتا، اور انہیں ترغیب دینے کے لیے پوائنٹ سسٹمز کے طور پر استعمال کیا جاتا ہے۔ ٹوکن سسٹمز کو ایتھیریم میں نافذ کرنا حیرت انگیز طور پر آسان ہے۔ سمجھنے کا اہم نکتہ یہ ہے کہ کوئی بھی کرنسی، یا ٹوکن سسٹم، بنیادی طور پر ایک ڈیٹا بیس ہے جس میں ایک ہی عمل ہوتا ہے: A سے X یونٹس کو منہا کریں اور B کو X یونٹس دیں، اس شرط کے ساتھ کہ (i) ٹرانزیکشن سے پہلے A کے پاس کم از کم X یونٹس تھے اور (2) ٹرانزیکشن کی منظوری A نے دی ہو۔ ٹوکن سسٹم کو نافذ کرنے کے لیے بس اس منطق کو ایک کنٹریکٹ میں نافذ کرنے کی ضرورت ہوتی ہے۔ Serpent میں ٹوکن سسٹم کو نافذ کرنے کا بنیادی کوڈ کچھ یوں نظر آتا ہے: ```py 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) کے لیے کوڈ کی کچھ اضافی لائنیں شامل کرنے کی ضرورت ہے، اور مثالی طور پر ایک فنکشن شامل کیا جانا چاہیے تاکہ دیگر کنٹریکٹس کسی پتہ کے بیلنس کے بارے میں پوچھ گچھ کر سکیں۔ لیکن بس اتنا ہی کرنا ہوتا ہے۔ نظریاتی طور پر، ذیلی کرنسیوں کے طور پر کام کرنے والے ایتھیریم پر مبنی ٹوکن سسٹمز میں ممکنہ طور پر ایک اور اہم خصوصیت شامل ہو سکتی ہے جس کی آن چین بٹ کوائن پر مبنی میٹا کرنسیوں میں کمی ہے: براہ راست اسی کرنسی میں لین دین کی فیس ادا کرنے کی صلاحیت۔ اس کو نافذ کرنے کا طریقہ یہ ہوگا کہ کنٹریکٹ ایک ایتھر بیلنس برقرار رکھے گا جس کے ذریعے وہ بھیجنے والے کو فیس ادا کرنے کے لیے استعمال ہونے والے ایتھر کو واپس کر دے گا، اور وہ فیس کے طور پر لی گئی اندرونی کرنسی یونٹس کو جمع کر کے اور انہیں مسلسل چلنے والی نیلامی میں دوبارہ فروخت کر کے اس بیلنس کو دوبارہ بھرے گا۔ اس طرح صارفین کو اپنے اکاؤنٹس کو ایتھر کے ساتھ "فعال" کرنے کی ضرورت ہوگی، لیکن ایک بار جب ایتھر وہاں موجود ہو تو اسے دوبارہ استعمال کیا جا سکے گا کیونکہ کنٹریکٹ اسے ہر بار واپس کر دے گا۔ ### مالیاتی مشتقات اور مستحکم قدر والی کرنسیاں {#financial-derivatives-and-stable-value-currencies} مالیاتی مشتقات (Financial derivatives) "سمارٹ کنٹریکٹ" کی سب سے عام ایپلی کیشن ہیں، اور کوڈ میں نافذ کرنے کے لیے سب سے آسان میں سے ایک ہیں۔ مالیاتی کنٹریکٹس کو نافذ کرنے میں سب سے بڑا چیلنج یہ ہے کہ ان میں سے اکثریت کو بیرونی قیمت کے ٹکر (price ticker) کے حوالے کی ضرورت ہوتی ہے؛ مثال کے طور پر، ایک انتہائی مطلوبہ ایپلی کیشن ایک ایسا سمارٹ کنٹریکٹ ہے جو امریکی ڈالر کے مقابلے میں ایتھر (یا کسی اور کرپٹو کرنسی) کے اتار چڑھاؤ سے بچاتا ہے، لیکن ایسا کرنے کے لیے کنٹریکٹ کو یہ جاننے کی ضرورت ہوتی ہے کہ ETH/USD کی قدر کیا ہے۔ ایسا کرنے کا سب سے آسان طریقہ ایک مخصوص فریق (جیسے، NASDAQ) کے زیر انتظام "ڈیٹا فیڈ" کنٹریکٹ کے ذریعے ہے جسے اس طرح ڈیزائن کیا گیا ہو کہ اس فریق کے پاس ضرورت کے مطابق کنٹریکٹ کو اپ ڈیٹ کرنے کی صلاحیت ہو، اور ایک ایسا انٹرفیس فراہم کیا جائے جو دوسرے کنٹریکٹس کو اس کنٹریکٹ کو پیغام بھیجنے اور قیمت فراہم کرنے والا جواب واپس حاصل کرنے کی اجازت دے۔ اس اہم جزو کو مدنظر رکھتے ہوئے، ہیجنگ کنٹریکٹ کچھ یوں نظر آئے گا: 1. فریق A کی جانب سے 1000 ایتھر داخل کرنے کا انتظار کریں۔ 2. فریق B کی جانب سے 1000 ایتھر داخل کرنے کا انتظار کریں۔ 3. ڈیٹا فیڈ کنٹریکٹ سے استفسار کر کے حساب کی گئی 1000 ایتھر کی USD قدر کو سٹوریج میں ریکارڈ کریں، فرض کریں کہ یہ $x ہے۔ 4. 30 دنوں کے بعد، A یا B کو کنٹریکٹ کو "دوبارہ فعال" کرنے کی اجازت دیں تاکہ $x مالیت کا ایتھر (نئی قیمت حاصل کرنے کے لیے ڈیٹا فیڈ کنٹریکٹ سے دوبارہ استفسار کر کے حساب کیا گیا) A کو اور باقی B کو بھیجا جا سکے۔ اس طرح کے کنٹریکٹ میں کرپٹو کامرس میں نمایاں صلاحیت ہوگی۔ کرپٹو کرنسی کے بارے میں بیان کردہ اہم مسائل میں سے ایک یہ حقیقت ہے کہ یہ غیر مستحکم ہے؛ اگرچہ بہت سے صارفین اور تاجر کرپٹوگرافک اثاثوں کے ساتھ لین دین کی سیکیورٹی اور سہولت چاہتے ہوں گے، لیکن وہ ایک ہی دن میں اپنے فنڈز کی قدر کا 23% کھونے کے امکان کا سامنا نہیں کرنا چاہیں گے۔ اب تک، سب سے زیادہ تجویز کردہ حل جاری کنندہ کی حمایت یافتہ اثاثے (issuer-backed assets) رہا ہے؛ خیال یہ ہے کہ ایک جاری کنندہ ایک ذیلی کرنسی بناتا ہے جس میں اسے یونٹس جاری کرنے اور منسوخ کرنے کا حق حاصل ہوتا ہے، اور وہ کرنسی کا ایک یونٹ ہر اس شخص کو فراہم کرتا ہے جو انہیں (آف لائن) ایک مخصوص بنیادی اثاثے (جیسے، سونا، USD) کا ایک یونٹ فراہم کرتا ہے۔ پھر جاری کنندہ ہر اس شخص کو بنیادی اثاثے کا ایک یونٹ فراہم کرنے کا وعدہ کرتا ہے جو کرپٹو اثاثے کا ایک یونٹ واپس بھیجتا ہے۔ یہ طریقہ کار کسی بھی غیر کرپٹوگرافک اثاثے کو کرپٹوگرافک اثاثے میں "اپ لفٹ" کرنے کی اجازت دیتا ہے، بشرطیکہ جاری کنندہ پر بھروسہ کیا جا سکے۔ تاہم، عملی طور پر، جاری کنندگان ہمیشہ قابلِ بھروسہ نہیں ہوتے، اور بعض صورتوں میں بینکنگ کا بنیادی ڈھانچہ ایسی خدمات کے وجود کے لیے بہت کمزور، یا بہت مخالف ہوتا ہے۔ مالیاتی مشتقات ایک متبادل فراہم کرتے ہیں۔ یہاں، کسی اثاثے کی پشت پناہی کے لیے فنڈز فراہم کرنے والے ایک واحد جاری کنندہ کے بجائے، قیاس آرائی کرنے والوں (speculators) کی ایک لامركزی مارکیٹ، جو یہ شرط لگاتی ہے کہ کرپٹوگرافک حوالہ اثاثے (جیسے، ETH) کی قیمت بڑھے گی، یہ کردار ادا کرتی ہے۔ جاری کنندگان کے برعکس، قیاس آرائی کرنے والوں کے پاس سودے کے اپنے حصے سے مکرنے کا کوئی اختیار نہیں ہوتا کیونکہ ہیجنگ کنٹریکٹ ان کے فنڈز کو ایسکرو (escrow) میں رکھتا ہے۔ واضح رہے کہ یہ نقطہ نظر مکمل طور پر لامركزی نہیں ہے، کیونکہ قیمت کا ٹکر فراہم کرنے کے لیے اب بھی ایک قابلِ بھروسہ ذریعہ کی ضرورت ہوتی ہے، اگرچہ یہ دلیل دی جا سکتی ہے کہ بنیادی ڈھانچے کی ضروریات کو کم کرنے (جاری کنندہ ہونے کے برعکس، قیمت کی فراہمی جاری کرنے کے لیے کسی لائسنس کی ضرورت نہیں ہوتی اور اسے ممکنہ طور پر آزادی اظہار کے طور پر درجہ بند کیا جا سکتا ہے) اور دھوکہ دہی کے امکانات کو کم کرنے کے لحاظ سے یہ اب بھی ایک بہت بڑی بہتری ہے۔ ### شناخت اور ساکھ کے سسٹمز {#identity-and-reputation-systems} سب سے ابتدائی متبادل کرپٹو کرنسی، [Namecoin](http://namecoin.org/) نے نام کے اندراج کا نظام فراہم کرنے کے لیے بٹ کوائن جیسی بلاک چین استعمال کرنے کی کوشش کی، جہاں صارفین دیگر ڈیٹا کے ساتھ ایک عوامی ڈیٹا بیس میں اپنے نام رجسٹر کر سکتے ہیں۔ اس کا سب سے بڑا استعمال [DNS](https://wikipedia.org/wiki/Domain_Name_System) سسٹم کے لیے بتایا گیا ہے، جو "bitcoin.org" (یا، Namecoin کے معاملے میں، "bitcoin.bit") جیسے ڈومین ناموں کو ایک IP پتہ سے جوڑتا ہے۔ دیگر استعمالات میں ای میل کی تصدیق اور ممکنہ طور پر زیادہ جدید ساکھ کے سسٹمز شامل ہیں۔ ایتھیریم پر Namecoin جیسا نام کے اندراج کا نظام فراہم کرنے کے لیے بنیادی کنٹریکٹ یہ ہے: ```py def register(name, value): if !self.storage[name]: self.storage[name] = value ``` کنٹریکٹ بہت آسان ہے؛ یہ ایتھیریم نیٹ ورک کے اندر صرف ایک ڈیٹا بیس ہے جس میں اضافہ کیا جا سکتا ہے، لیکن اس میں ترمیم یا اسے ہٹایا نہیں جا سکتا۔ کوئی بھی شخص کچھ قدر کے ساتھ ایک نام رجسٹر کر سکتا ہے، اور پھر وہ رجسٹریشن ہمیشہ کے لیے قائم رہتی ہے۔ ایک زیادہ نفیس نام کے اندراج کے کنٹریکٹ میں ایک "فنکشن کلاز" بھی ہوگا جو دوسرے کنٹریکٹس کو اس سے استفسار کرنے کی اجازت دے گا، نیز کسی نام کے "مالک" (یعنی پہلا رجسٹر کرنے والا) کے لیے ڈیٹا کو تبدیل کرنے یا ملکیت کی منتقلی کا طریقہ کار بھی ہوگا۔ کوئی اس کے اوپر ساکھ اور ویب آف ٹرسٹ (web-of-trust) کی فعالیت بھی شامل کر سکتا ہے۔ ### لامركزی فائل سٹوریج {#decentralized-file-storage} پچھلے چند سالوں کے دوران، کئی مقبول آن لائن فائل سٹوریج سٹارٹ اپس ابھرے ہیں، جن میں سب سے نمایاں ڈراپ باکس (Dropbox) ہے، جو صارفین کو اپنی ہارڈ ڈرائیو کا بیک اپ اپ لوڈ کرنے کی اجازت دینے کی کوشش کر رہے ہیں اور سروس اس بیک اپ کو محفوظ کرتی ہے اور ماہانہ فیس کے عوض صارف کو اس تک رسائی کی اجازت دیتی ہے۔ تاہم، اس وقت فائل سٹوریج کی مارکیٹ بعض اوقات نسبتاً غیر موثر ہوتی ہے؛ مختلف موجودہ حلوں پر ایک سرسری نظر ڈالنے سے پتہ چلتا ہے کہ، خاص طور پر "uncanny valley" یعنی 20-200 GB کی سطح پر جہاں نہ تو مفت کوٹہ اور نہ ہی انٹرپرائز سطح کی چھوٹ لاگو ہوتی ہے، مین سٹریم فائل سٹوریج کے اخراجات کی ماہانہ قیمتیں ایسی ہیں کہ آپ ایک ہی مہینے میں پوری ہارڈ ڈرائیو کی قیمت سے زیادہ ادائیگی کر رہے ہوتے ہیں۔ ایتھیریم کنٹریکٹس ایک لامركزی فائل سٹوریج ایکو سسٹم کی ترقی کی اجازت دے سکتے ہیں، جہاں انفرادی صارفین اپنی ہارڈ ڈرائیوز کرائے پر دے کر تھوڑی مقدار میں پیسہ کما سکتے ہیں اور غیر استعمال شدہ جگہ کو فائل سٹوریج کے اخراجات کو مزید کم کرنے کے لیے استعمال کیا جا سکتا ہے۔ اس طرح کے آلے کا کلیدی بنیادی حصہ وہ ہوگا جسے ہم نے "لامركزی ڈراپ باکس کنٹریکٹ" کا نام دیا ہے۔ یہ کنٹریکٹ اس طرح کام کرتا ہے۔ سب سے پہلے، مطلوبہ ڈیٹا کو بلاکس میں تقسیم کیا جاتا ہے، رازداری کے لیے ہر بلاک کو انکرپٹ کیا جاتا ہے، اور اس سے ایک مرکل ٹری بنایا جاتا ہے۔ پھر ایک کنٹریکٹ اس اصول کے ساتھ بنایا جاتا ہے کہ، ہر N بلاکس کے بعد، کنٹریکٹ مرکل ٹری میں ایک بے ترتیب اشاریہ کا انتخاب کرے گا (پچھلے بلاک ہیش کا استعمال کرتے ہوئے، جو کنٹریکٹ کوڈ سے قابل رسائی ہے، بے ترتیبی کے ذریعہ کے طور پر)، اور اس پہلی ہستی کو X ایتھر دے گا جو ٹری میں اس مخصوص اشاریہ پر بلاک کی ملکیت کے آسان ادائیگی کی تصدیق (simplified payment verification) جیسے ثبوت کے ساتھ ٹرانزیکشن فراہم کرے۔ جب کوئی صارف اپنی فائل کو دوبارہ ڈاؤن لوڈ کرنا چاہتا ہے، تو وہ فائل کو بازیافت کرنے کے لیے مائیکرو پیمنٹ چینل پروٹوکول استعمال کر سکتا ہے (مثال کے طور پر، فی 32 kilobytes کے لیے 1 سابو ادا کریں)؛ فیس کے لحاظ سے سب سے موثر طریقہ یہ ہے کہ ادائیگی کرنے والا ٹرانزیکشن کو آخر تک شائع نہ کرے، بلکہ اس کے بجائے ہر 32 kilobytes کے بعد اسی نانس کے ساتھ ٹرانزیکشن کو قدرے زیادہ منافع بخش ٹرانزیکشن سے بدل دے۔ پروٹوکول کی ایک اہم خصوصیت یہ ہے کہ، اگرچہ ایسا لگ سکتا ہے کہ کوئی بہت سے بے ترتیب نوڈز پر بھروسہ کر رہا ہے کہ وہ فائل کو بھولنے کا فیصلہ نہیں کریں گے، لیکن کوئی بھی خفیہ شیئرنگ (secret sharing) کے ذریعے فائل کو کئی ٹکڑوں میں تقسیم کر کے، اور کنٹریکٹس کو دیکھ کر کہ ہر ٹکڑا اب بھی کسی نوڈ کے قبضے میں ہے، اس خطرے کو تقریباً صفر تک کم کر سکتا ہے۔ اگر کوئی کنٹریکٹ اب بھی پیسے ادا کر رہا ہے، تو یہ ایک کرپٹوگرافک ثبوت فراہم کرتا ہے کہ کوئی نہ کوئی اب بھی فائل کو محفوظ کر رہا ہے۔ ### لامركزی خود مختار تنظیمیں {#decentralized-autonomous-organizations} "لامركزی خود مختار تنظیم" (decentralized autonomous organization) کا عمومی تصور ایک ایسی ورچوئل ہستی کا ہے جس کے اراکین یا شیئر ہولڈرز کا ایک خاص مجموعہ ہوتا ہے جنہیں، شاید 67% اکثریت کے ساتھ، ہستی کے فنڈز خرچ کرنے اور اس کے کوڈ میں ترمیم کرنے کا حق حاصل ہوتا ہے۔ اراکین اجتماعی طور پر فیصلہ کریں گے کہ تنظیم کو اپنے فنڈز کیسے مختص کرنے چاہئیں۔ کسی DAO کے فنڈز مختص کرنے کے طریقوں میں انعامات، تنخواہوں سے لے کر کام کا انعام دینے کے لیے اندرونی کرنسی جیسے مزید غیر معمولی طریقہ کار شامل ہو سکتے ہیں۔ یہ بنیادی طور پر ایک روایتی کمپنی یا غیر منافع بخش ادارے کے قانونی ڈھانچے کی نقل کرتا ہے لیکن نفاذ کے لیے صرف کرپٹوگرافک بلاک چین ٹیکنالوجی کا استعمال کرتا ہے۔ اب تک DAOs کے بارے میں زیادہ تر بات چیت منافع حاصل کرنے والے شیئر ہولڈرز اور قابلِ تجارت حصص کے ساتھ "لامركزی خود مختار کارپوریشن" (DAC) کے "سرمایہ دارانہ" ماڈل کے گرد گھومتی رہی ہے؛ ایک متبادل، جسے شاید "لامركزی خود مختار کمیونٹی" کے طور پر بیان کیا جا سکتا ہے، اس میں تمام اراکین کا فیصلہ سازی میں مساوی حصہ ہوگا اور کسی رکن کو شامل کرنے یا ہٹانے کے لیے موجودہ اراکین کے 67% کے متفق ہونے کی ضرورت ہوگی۔ یہ شرط کہ ایک شخص کی صرف ایک ہی رکنیت ہو سکتی ہے، پھر گروپ کی طرف سے اجتماعی طور پر نافذ کرنے کی ضرورت ہوگی۔ DAO کو کوڈ کرنے کے طریقے کا عمومی خاکہ کچھ یوں ہے۔ سب سے آسان ڈیزائن محض خودکار ترمیم کرنے والے کوڈ کا ایک ٹکڑا ہے جو اس وقت تبدیل ہوتا ہے جب دو تہائی اراکین کسی تبدیلی پر متفق ہوں۔ اگرچہ کوڈ نظریاتی طور پر ناقابلِ تبدیلی ہے، لیکن کوئی بھی آسانی سے اس سے بچ سکتا ہے اور کوڈ کے حصوں کو الگ الگ کنٹریکٹس میں رکھ کر، اور کن کنٹریکٹس کو کال کرنا ہے ان کا پتہ قابلِ ترمیم سٹوریج میں محفوظ کر کے ڈی فیکٹو (de-facto) تبدیلی کی صلاحیت حاصل کر سکتا ہے۔ اس طرح کے DAO کنٹریکٹ کے ایک سادہ نفاذ میں، ٹرانزیکشن میں فراہم کردہ ڈیٹا کی بنیاد پر ممتاز تین قسم کی ٹرانزیکشنز ہوں گی: - `[0,i,K,V]` سٹوریج اشاریہ `K` پر پتہ کو قدر `V` میں تبدیل کرنے کے لیے اشاریہ `i` کے ساتھ ایک تجویز رجسٹر کرنے کے لیے - `[1,i]` تجویز `i` کے حق میں ووٹ رجسٹر کرنے کے لیے - `[2,i]` تجویز `i` کو حتمی شکل دینے کے لیے اگر کافی ووٹ ڈالے جا چکے ہوں پھر کنٹریکٹ میں ان میں سے ہر ایک کے لیے شقیں ہوں گی۔ یہ تمام کھلی سٹوریج تبدیلیوں کا ریکارڈ برقرار رکھے گا، اس فہرست کے ساتھ کہ ان کے لیے کس نے ووٹ دیا۔ اس میں تمام اراکین کی فہرست بھی ہوگی۔ جب کسی سٹوریج کی تبدیلی کو دو تہائی اراکین کے ووٹ مل جاتے ہیں، تو ایک حتمی ٹرانزیکشن اس تبدیلی کو نافذ کر سکتی ہے۔ ایک زیادہ نفیس ڈھانچے میں ٹرانزیکشن بھیجنے، اراکین کو شامل کرنے اور اراکین کو ہٹانے جیسی خصوصیات کے لیے بلٹ ان ووٹنگ کی صلاحیت بھی ہوگی، اور یہاں تک کہ [Liquid Democracy](https://wikipedia.org/wiki/Liquid_democracy) کے انداز میں ووٹ کی تفویض (یعنی، کوئی بھی کسی کو اپنے لیے ووٹ دینے کے لیے مقرر کر سکتا ہے، اور یہ تقرری متعدی (transitive) ہوتی ہے لہذا اگر A، B کو مقرر کرتا ہے اور B، C کو مقرر کرتا ہے تو C، A کے ووٹ کا تعین کرتا ہے) بھی فراہم کر سکتا ہے۔ یہ ڈیزائن DAO کو ایک لامركزی کمیونٹی کے طور پر باقاعدہ طور پر بڑھنے کی اجازت دے گا، جس سے لوگ بالآخر یہ چھاننے کا کام ماہرین کو تفویض کر سکیں گے کہ کون رکن ہے، اگرچہ "موجودہ نظام" کے برعکس ماہرین وقت کے ساتھ ساتھ آسانی سے ظاہر اور غائب ہو سکتے ہیں کیونکہ انفرادی کمیونٹی کے اراکین اپنی وابستگیاں تبدیل کرتے ہیں۔ ایک متبادل ماڈل لامركزی کارپوریشن کے لیے ہے، جہاں کسی بھی اکاؤنٹ کے صفر یا اس سے زیادہ حصص ہو سکتے ہیں، اور فیصلہ کرنے کے لیے دو تہائی حصص کی ضرورت ہوتی ہے۔ ایک مکمل ڈھانچے میں اثاثہ جات کے انتظام کی فعالیت، حصص خریدنے یا بیچنے کی پیشکش کرنے کی صلاحیت، اور پیشکشوں کو قبول کرنے کی صلاحیت (ترجیحی طور پر کنٹریکٹ کے اندر آرڈر میچنگ میکانزم کے ساتھ) شامل ہوگی۔ تفویض بھی Liquid Democracy کے انداز میں موجود ہوگی، جو "بورڈ آف ڈائریکٹرز" کے تصور کو عام کرے گی۔ ### مزید ایپلی کیشنز {#further-applications} 1. **بچت کے بٹوے**۔ فرض کریں کہ ایلس اپنے فنڈز کو محفوظ رکھنا چاہتی ہے، لیکن اسے فکر ہے کہ وہ اپنی نجی کلید کھو دے گی یا کوئی اسے ہیک کر لے گا۔ وہ باب، جو کہ ایک بینک ہے، کے ساتھ ایک کنٹریکٹ میں ایتھر اس طرح رکھتی ہے: - ایلس اکیلے روزانہ فنڈز کا زیادہ سے زیادہ 1% نکال سکتی ہے۔ - باب اکیلے روزانہ فنڈز کا زیادہ سے زیادہ 1% نکال سکتا ہے، لیکن ایلس کے پاس اپنی کلید کے ساتھ ایک ٹرانزیکشن کرنے کی صلاحیت ہے جو اس صلاحیت کو بند کر دے۔ - ایلس اور باب مل کر کچھ بھی نکال سکتے ہیں۔ عام طور پر، ایلس کے لیے روزانہ 1% کافی ہوتا ہے، اور اگر ایلس مزید نکالنا چاہتی ہے تو وہ مدد کے لیے باب سے رابطہ کر سکتی ہے۔ اگر ایلس کی کلید ہیک ہو جاتی ہے، تو وہ فنڈز کو نئے کنٹریکٹ میں منتقل کرنے کے لیے باب کے پاس بھاگتی ہے۔ اگر وہ اپنی کلید کھو دیتی ہے، تو باب بالآخر فنڈز نکال لے گا۔ اگر باب بدنیتی پر مبنی ثابت ہوتا ہے، تو وہ اس کے نکالنے کی صلاحیت کو بند کر سکتی ہے۔ 2. **فصل کی انشورنس**۔ کوئی بھی آسانی سے مالیاتی مشتقات کا کنٹریکٹ بنا سکتا ہے لیکن کسی بھی قیمت کے اشاریہ کے بجائے موسم کی ڈیٹا فیڈ کا استعمال کرتے ہوئے۔ اگر آئیووا (Iowa) میں کوئی کسان ایسا مشتق (derivative) خریدتا ہے جو آئیووا میں بارش کی بنیاد پر الٹ ادائیگی کرتا ہے، تو اگر خشک سالی ہوتی ہے، تو کسان کو خود بخود رقم مل جائے گی اور اگر کافی بارش ہوتی ہے تو کسان خوش ہوگا کیونکہ ان کی فصلیں اچھی ہوں گی۔ اسے عام طور پر قدرتی آفت کی انشورنس تک بڑھایا جا سکتا ہے۔ 3. **ایک لامركزی ڈیٹا فیڈ**۔ فرق کے لیے مالیاتی کنٹریکٹس (financial contracts for difference) کے لیے، دراصل "[SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed)" نامی پروٹوکول کے ذریعے ڈیٹا فیڈ کو لامركزی بنانا ممکن ہو سکتا ہے۔ SchellingCoin بنیادی طور پر اس طرح کام کرتا ہے: N پارٹیاں سبھی سسٹم میں دیے گئے ڈیٹا کی قدر (جیسے، ETH/USD قیمت) ڈالتی ہیں، قدروں کو ترتیب دیا جاتا ہے، اور 25th اور 75th پرسنٹائل کے درمیان ہر ایک کو انعام کے طور پر ایک ٹوکن ملتا ہے۔ ہر ایک کے پاس وہ جواب فراہم کرنے کی ترغیب ہوتی ہے جو باقی سب فراہم کریں گے، اور واحد قدر جس پر کھلاڑیوں کی ایک بڑی تعداد حقیقت پسندانہ طور پر متفق ہو سکتی ہے وہ واضح ڈیفالٹ ہے: سچائی۔ یہ ایک لامركزی پروٹوکول بناتا ہے جو نظریاتی طور پر کسی بھی تعداد میں قدریں فراہم کر سکتا ہے، بشمول ETH/USD قیمت، برلن میں درجہ حرارت یا یہاں تک کہ کسی خاص مشکل کمپیوٹیشن کا نتیجہ۔ 4. **سمارٹ ملٹی سگ ایسکرو**۔ بٹ کوائن ملٹی سگ ٹرانزیکشن کنٹریکٹس کی اجازت دیتا ہے جہاں، مثال کے طور پر، دی گئی پانچ میں سے تین کلیدیں فنڈز خرچ کر سکتی ہیں۔ ایتھیریم زیادہ باریکی (granularity) کی اجازت دیتا ہے؛ مثال کے طور پر، پانچ میں سے چار سب کچھ خرچ کر سکتے ہیں، پانچ میں سے تین روزانہ 10% تک خرچ کر سکتے ہیں، اور پانچ میں سے دو روزانہ 0.5% تک خرچ کر سکتے ہیں۔ مزید برآں، ایتھیریم ملٹی سگ غیر مطابقت پذیر (asynchronous) ہے - دو پارٹیاں مختلف اوقات میں بلاک چین پر اپنے دستخط رجسٹر کر سکتی ہیں اور آخری دستخط خود بخود ٹرانزیکشن بھیج دے گا۔ 5. **کلاؤڈ کمپیوٹنگ**۔ EVM ٹیکنالوجی کو ایک قابلِ تصدیق کمپیوٹنگ ماحول بنانے کے لیے بھی استعمال کیا جا سکتا ہے، جس سے صارفین دوسروں سے کمپیوٹیشن کرنے کا کہہ سکتے ہیں اور پھر اختیاری طور پر اس بات کے ثبوت مانگ سکتے ہیں کہ کچھ تصادفی طور پر منتخب کردہ چیک پوائنٹس پر کمپیوٹیشن درست طریقے سے کی گئی تھیں۔ یہ کلاؤڈ کمپیوٹنگ مارکیٹ بنانے کی اجازت دیتا ہے جہاں کوئی بھی صارف اپنے ڈیسک ٹاپ، لیپ ٹاپ یا خصوصی سرور کے ساتھ حصہ لے سکتا ہے، اور سیکیورٹی ڈپازٹس کے ساتھ مل کر سپاٹ چیکنگ کا استعمال اس بات کو یقینی بنانے کے لیے کیا جا سکتا ہے کہ سسٹم قابلِ بھروسہ ہے (یعنی، نوڈز منافع بخش طریقے سے دھوکہ نہیں دے سکتے)۔ اگرچہ ایسا سسٹم تمام کاموں کے لیے موزوں نہیں ہو سکتا؛ ایسے کام جن کے لیے اعلیٰ سطح کے انٹر پروسیس کمیونیکیشن کی ضرورت ہوتی ہے، مثال کے طور پر، نوڈز کے بڑے کلاؤڈ پر آسانی سے نہیں کیے جا سکتے۔ تاہم، دیگر کاموں کو متوازی (parallelize) کرنا بہت آسان ہے؛ SETI@home، folding@home اور جینیاتی الگورتھم جیسے پروجیکٹس کو ایسے پلیٹ فارم پر آسانی سے نافذ کیا جا سکتا ہے۔ 6. **پیئر ٹو پیئر جوا**۔ کسی بھی تعداد میں پیئر ٹو پیئر جوئے کے پروٹوکولز، جیسے فرینک سٹاجانو (Frank Stajano) اور رچرڈ کلیٹن (Richard Clayton) کا [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf)، ایتھیریم بلاک چین پر نافذ کیے جا سکتے ہیں۔ جوئے کا سب سے آسان پروٹوکول دراصل اگلے بلاک ہیش پر فرق کے لیے ایک کنٹریکٹ ہے، اور وہاں سے مزید جدید پروٹوکول بنائے جا سکتے ہیں، جس سے تقریباً صفر فیس کے ساتھ جوئے کی خدمات تخلیق ہوتی ہیں جن میں دھوکہ دینے کی کوئی صلاحیت نہیں ہوتی۔ 7. **پیشین گوئی کی مارکیٹس**۔ اگر ایک اوریکل یا SchellingCoin فراہم کیا جائے، تو پیشین گوئی کی مارکیٹس کو نافذ کرنا بھی آسان ہے، اور SchellingCoin کے ساتھ مل کر پیشین گوئی کی مارکیٹس لامركزی تنظیموں کے لیے گورننس پروٹوکول کے طور پر [futarchy](https://mason.gmu.edu/~rhanson/futarchy.html) کی پہلی مین سٹریم ایپلی کیشن ثابت ہو سکتی ہیں۔ 8. **آن چین لامركزی مارکیٹ پلیسز**، شناخت اور ساکھ کے سسٹم کو بنیاد کے طور پر استعمال کرتے ہوئے۔ ## متفرق امور اور خدشات {#miscellanea-and-concerns} ### ترمیم شدہ GHOST کا نفاذ {#modified-ghost-implementation} "Greedy Heaviest Observed Subtree" (GHOST) پروٹوکول ایک جدت ہے جسے پہلی بار یوناتن سومپولنسکی (Yonatan Sompolinsky) اور اویو زوہر (Aviv Zohar) نے [دسمبر ۲۰۱۳](https://eprint.iacr.org/2013/881.pdf) میں متعارف کرایا تھا۔ GHOST کے پیچھے محرک یہ ہے کہ تیز تر تصدیقی اوقات والی بلاک چینز فی الحال باسی (stale) شرح کی زیادتی کی وجہ سے کم سیکیورٹی کا شکار ہیں - چونکہ بلاکس کو نیٹ ورک میں پھیلنے کے لیے ایک خاص وقت درکار ہوتا ہے، اگر کان کن A ایک بلاک کی کان کنی کرتا ہے اور پھر کان کن B اتفاقاً ایک اور بلاک کی کان کنی کر لیتا ہے اس سے پہلے کہ کان کن A کا بلاک B تک پہنچے، تو کان کن B کا بلاک ضائع ہو جائے گا اور نیٹ ورک کی سیکیورٹی میں کوئی حصہ نہیں ڈالے گا۔ مزید برآں، مرکزیت کا ایک مسئلہ بھی ہے: اگر کان کن A ایک مائننگ پول ہے جس کے پاس 30% ہیش پاور ہے اور B کے پاس 10% ہیش پاور ہے، تو A کو 70% وقت ایک باسی بلاک پیدا کرنے کا خطرہ ہوگا (کیونکہ باقی 30% وقت A نے آخری بلاک پیدا کیا تھا اور اس لیے اسے کان کنی کا ڈیٹا فوری طور پر مل جائے گا) جبکہ B کو 90% وقت ایک باسی بلاک پیدا کرنے کا خطرہ ہوگا۔ لہذا، اگر بلاک کا وقفہ اتنا کم ہو کہ باسی شرح زیادہ ہو جائے، تو A محض اپنے حجم کی بدولت نمایاں طور پر زیادہ کارآمد ہوگا۔ ان دونوں اثرات کے ملنے سے، وہ بلاک چینز جو تیزی سے بلاکس پیدا کرتی ہیں، ان میں اس بات کا قوی امکان ہوتا ہے کہ ایک مائننگ پول کے پاس نیٹ ورک کی ہیش پاور کا اتنا بڑا حصہ آ جائے کہ وہ کان کنی کے عمل پر عملی طور پر (de facto) کنٹرول حاصل کر لے۔ جیسا کہ سومپولنسکی اور زوہر نے بیان کیا ہے، GHOST نیٹ ورک سیکیورٹی کے نقصان کے پہلے مسئلے کو اس حساب میں باسی بلاکس کو شامل کر کے حل کرتا ہے کہ کون سی چین "سب سے طویل" ہے؛ یعنی، نہ صرف ایک بلاک کے پیرنٹ اور مزید آباؤ اجداد، بلکہ بلاک کے آباؤ اجداد کی باسی اولاد (ایتھیریم کی اصطلاح میں، "انکلز" (uncles)) کو بھی اس حساب میں شامل کیا جاتا ہے کہ کس بلاک کے پیچھے سب سے بڑا مجموعی ثبوتِ کار (PoW) ہے۔ مرکزیت کے تعصب کے دوسرے مسئلے کو حل کرنے کے لیے، ہم سومپولنسکی اور زوہر کے بیان کردہ پروٹوکول سے آگے بڑھتے ہیں، اور باسی بلاکس کو بھی بلاک ریوارڈ فراہم کرتے ہیں: ایک باسی بلاک کو اس کے بنیادی انعام کا 87.5% ملتا ہے، اور وہ بھتیجا (nephew) جو باسی بلاک کو شامل کرتا ہے اسے باقی 12.5% ملتا ہے۔ تاہم، لین دین کی فیس انکلز کو نہیں دی جاتی۔ ایتھیریم GHOST کا ایک سادہ ورژن نافذ کرتا ہے جو صرف سات درجے نیچے جاتا ہے۔ خاص طور پر، اس کی تعریف اس طرح کی گئی ہے: - ایک بلاک کو لازمی طور پر ایک پیرنٹ کی وضاحت کرنی چاہیے، اور اسے 0 یا اس سے زیادہ انکلز کی وضاحت کرنی چاہیے۔ - بلاک B میں شامل ایک انکل میں درج ذیل خصوصیات ہونی چاہئیں: - اسے B کے k-ویں نسل کے آباؤ اجداد کا براہ راست چائلڈ ہونا چاہیے، جہاں `2 <= k <= 7` ہو۔ - یہ B کا آباؤ اجداد نہیں ہو سکتا۔ - ایک انکل کا درست بلاک ہیڈر ہونا لازمی ہے، لیکن اس کا پہلے سے تصدیق شدہ یا درست بلاک ہونا ضروری نہیں ہے۔ - ایک انکل کو پچھلے بلاکس میں شامل تمام انکلز اور اسی بلاک میں شامل دیگر تمام انکلز سے مختلف ہونا چاہیے (دوہری شمولیت نہیں)۔ - بلاک B میں ہر انکل U کے لیے، B کے کان کن کو اس کے کوائن بیس انعام میں اضافی 3.125% ملتا ہے اور U کے کان کن کو معیاری کوائن بیس انعام کا 93.75% ملتا ہے۔ GHOST کا یہ محدود ورژن، جس میں انکلز کو صرف 7 نسلوں تک شامل کیا جا سکتا ہے، دو وجوہات کی بنا پر استعمال کیا گیا تھا۔ اول، لامحدود GHOST اس حساب میں بہت سی پیچیدگیاں شامل کر دے گا کہ کسی دیے گئے بلاک کے لیے کون سے انکلز درست ہیں۔ دوم، ایتھیریم میں استعمال ہونے والے معاوضے کے ساتھ لامحدود GHOST کان کن کے لیے مین چین پر کان کنی کرنے کی ترغیب کو ختم کر دیتا ہے نہ کہ کسی عوامی حملہ آور کی چین پر۔ ### فیس {#fees} چونکہ بلاک چین میں شائع ہونے والی ہر ٹرانزیکشن نیٹ ورک پر اسے ڈاؤن لوڈ اور تصدیق کرنے کی لاگت عائد کرتی ہے، اس لیے غلط استعمال کو روکنے کے لیے کسی ریگولیٹری میکانزم کی ضرورت ہوتی ہے، جس میں عام طور پر لین دین کی فیس شامل ہوتی ہے۔ بٹ کوائن میں استعمال ہونے والا ڈیفالٹ طریقہ کار خالصتاً رضاکارانہ فیس کا ہے، جو کان کنوں پر انحصار کرتا ہے کہ وہ گیٹ کیپرز کے طور پر کام کریں اور متحرک کم از کم حدیں مقرر کریں۔ اس نقطہ نظر کو بٹ کوائن کمیونٹی میں خاص طور پر اس لیے بہت پذیرائی ملی ہے کیونکہ یہ "مارکیٹ پر مبنی" ہے، جو کان کنوں اور ٹرانزیکشن بھیجنے والوں کے درمیان طلب اور رسد کو قیمت کا تعین کرنے کی اجازت دیتا ہے۔ تاہم، اس استدلال کے ساتھ مسئلہ یہ ہے کہ ٹرانزیکشن پروسیسنگ کوئی مارکیٹ نہیں ہے؛ اگرچہ ٹرانزیکشن پروسیسنگ کو ایک ایسی سروس کے طور پر سمجھنا بدیہی طور پر پرکشش ہے جو کان کن بھیجنے والے کو پیش کر رہا ہے، لیکن حقیقت میں ہر وہ ٹرانزیکشن جسے کان کن شامل کرتا ہے اسے نیٹ ورک کے ہر نوڈ کے ذریعے پروسیس کرنے کی ضرورت ہوگی، لہذا ٹرانزیکشن پروسیسنگ کی لاگت کی اکثریت تیسرے فریق برداشت کرتے ہیں نہ کہ وہ کان کن جو اسے شامل کرنے یا نہ کرنے کا فیصلہ کر رہا ہے۔ لہذا، ٹریجڈی آف دی کامنز (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` کو بڑھاتا ہے؛ لہذا، یہ دونوں اثرات کم از کم جزوی طور پر ایک دوسرے کو منسوخ کر دیتے ہیں۔[کیسے؟](https://web.archive.org/web/20250427212319/https://github.com/ethereum/wiki/issues/447#issuecomment-316972260#issuecomment-316972260) (3) اور (4) بڑے مسائل ہیں؛ انہیں حل کرنے کے لیے ہم محض ایک فلوٹنگ کیپ (floating cap) قائم کرتے ہیں: کسی بھی بلاک میں طویل مدتی ایکسپونینشل موونگ ایوریج (exponential moving average) کے `BLK_LIMIT_FACTOR` گنا سے زیادہ آپریشنز نہیں ہو سکتے۔ خاص طور پر: ```js 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 پر سیٹ کیا جائے گا، لیکن مزید تجزیے کے بعد ان کے تبدیل ہونے کا امکان ہے۔ بٹ کوائن میں بڑے بلاک سائز کی حوصلہ شکنی کرنے والا ایک اور عنصر ہے: جو بلاکس بڑے ہوتے ہیں انہیں پھیلنے میں زیادہ وقت لگے گا، اور اس طرح ان کے باسی ہونے کا امکان زیادہ ہوتا ہے۔ ایتھیریم میں، زیادہ گیس استعمال کرنے والے بلاکس کو بھی پھیلنے میں زیادہ وقت لگ سکتا ہے کیونکہ وہ جسمانی طور پر بڑے ہوتے ہیں اور اس لیے بھی کہ انہیں توثیق کے لیے ٹرانزیکشن کی حالت کی تبدیلیوں کو پروسیس کرنے میں زیادہ وقت لگتا ہے۔ تاخیر کی یہ حوصلہ شکنی بٹ کوائن میں ایک اہم غور طلب بات ہے، لیکن GHOST پروٹوکول کی وجہ سے ایتھیریم میں کم ہے؛ لہذا، ریگولیٹڈ بلاک کی حدود پر انحصار کرنا ایک زیادہ مستحکم بنیاد فراہم کرتا ہے۔ ### کمپیوٹیشن اور ٹیورنگ-کمپلیٹنس {#computation-and-turing-completeness} ایک اہم بات یہ ہے کہ ایتھیریم ورچوئل مشین ٹیورنگ-کمپلیٹ (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 تکرار کر کے ہٹایا جا سکتا تھا۔ ٹیورنگ-کمپلیٹنس کے سنگین مضمرات، اور محدود فائدے کو دیکھتے ہوئے، کیوں نہ محض ایک ٹیورنگ-انکمپلیٹ زبان رکھی جائے؟ تاہم، حقیقت میں، ٹیورنگ-انکمپلیٹنس اس مسئلے کا کوئی صاف ستھرا حل نہیں ہے۔ یہ دیکھنے کے لیے کہ کیوں، درج ذیل کنٹریکٹس پر غور کریں: ```sh 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 ٹرانزیکشنز میں، ہمارے پاس ایک کنٹریکٹ ہے جو 250 کمپیوٹیشنل مراحل لیتا ہے۔ کان کن ہر کنٹریکٹ کے ساتھ ایک قدر برقرار رکھ کر وقت سے پہلے ایسے لاجک بموں (logic bombs) کا پتہ لگانے کی کوشش کر سکتے ہیں جو ان کمپیوٹیشنل مراحل کی زیادہ سے زیادہ تعداد کی وضاحت کرتی ہو جو یہ لے سکتا ہے، اور دوسرے کنٹریکٹس کو بار بار کال کرنے والے کنٹریکٹس کے لیے اس کا حساب لگا سکتے ہیں، لیکن اس کے لیے کان کنوں کو ان کنٹریکٹس کو منع کرنے کی ضرورت ہوگی جو دوسرے کنٹریکٹس بناتے ہیں (کیونکہ مندرجہ بالا تمام 26 کنٹریکٹس کی تخلیق اور عمل درآمد کو آسانی سے ایک ہی کنٹریکٹ میں رول کیا جا سکتا ہے)۔ ایک اور مسئلہ طلب نکتہ یہ ہے کہ پیغام کا ایڈریس فیلڈ ایک متغیر (variable) ہے، لہذا عام طور پر یہ بتانا بھی ممکن نہیں ہو سکتا کہ کوئی دیا گیا کنٹریکٹ وقت سے پہلے کن دوسرے کنٹریکٹس کو کال کرے گا۔ لہذا، مجموعی طور پر، ہمارے پاس ایک حیران کن نتیجہ ہے: ٹیورنگ-کمپلیٹنس کا انتظام کرنا حیرت انگیز طور پر آسان ہے، اور ٹیورنگ-کمپلیٹنس کی کمی کا انتظام کرنا بھی اتنا ہی حیرت انگیز طور پر مشکل ہے جب تک کہ بالکل وہی کنٹرولز موجود نہ ہوں - لیکن اس صورت میں کیوں نہ پروٹوکول کو ٹیورنگ-کمپلیٹ رہنے دیا جائے؟ ### کرنسی اور اجراء {#currency-and-issuance} ایتھیریم نیٹ ورک میں اس کی اپنی بلٹ ان کرنسی، ایتھر شامل ہے، جو مختلف قسم کے ڈیجیٹل اثاثوں کے درمیان موثر تبادلے کی اجازت دینے کے لیے ایک بنیادی سیالیت کی تہہ فراہم کرنے اور، اس سے بھی اہم بات، لین دین کی فیس ادا کرنے کے لیے ایک میکانزم فراہم کرنے کا دوہرا مقصد پورا کرتی ہے۔ سہولت کے لیے اور مستقبل کی بحث سے بچنے کے لیے (بٹ کوائن میں موجودہ mBTC/uBTC/satoshi بحث دیکھیں)، مالیتوں (denominations) کو پہلے سے لیبل کیا جائے گا: - 1: Wei - 1012: سابو - 1015: فنی - 1018: ایتھر اسے "ڈالر" اور "سینٹ" یا "BTC" اور "ستوشی" کے تصور کے توسیع شدہ ورژن کے طور پر لیا جانا چاہیے۔ مستقبل قریب میں، ہم توقع کرتے ہیں کہ "ایتھر" عام ٹرانزیکشنز کے لیے، "فنی" مائیکرو ٹرانزیکشنز کے لیے اور "سابو" اور "Wei" فیس اور پروٹوکول کے نفاذ کے ارد گرد تکنیکی بات چیت کے لیے استعمال ہوں گے؛ باقی مالیتیں بعد میں کارآمد ہو سکتی ہیں اور اس وقت انہیں کلائنٹس میں شامل نہیں کیا جانا چاہیے۔ اجراء کا ماڈل درج ذیل ہوگا: - ایتھر کو کرنسی کی فروخت میں 1000-2000 ایتھر فی BTC کی قیمت پر جاری کیا جائے گا، یہ ایک ایسا میکانزم ہے جس کا مقصد ایتھیریم تنظیم کو فنڈ دینا اور ترقی کی ادائیگی کرنا ہے جسے Mastercoin اور NXT جیسے دیگر پلیٹ فارمز نے کامیابی کے ساتھ استعمال کیا ہے۔ ابتدائی خریداروں کو بڑی چھوٹ سے فائدہ ہوگا۔ فروخت سے حاصل ہونے والے BTC کو مکمل طور پر ڈویلپرز کو تنخواہوں اور انعامات کی ادائیگی کے لیے استعمال کیا جائے گا اور ایتھیریم اور کرپٹو کرنسی ایکو سسٹم میں مختلف منافع بخش اور غیر منافع بخش منصوبوں میں سرمایہ کاری کی جائے گی۔ - فروخت شدہ کل رقم کا 0.099x (60102216 ETH) تنظیم کو مختص کیا جائے گا تاکہ ابتدائی تعاون کنندگان کو معاوضہ دیا جا سکے اور ابتدائی بلاک سے پہلے ETH پر مبنی اخراجات ادا کیے جا سکیں۔ - فروخت شدہ کل رقم کا 0.099x طویل مدتی ریزرو کے طور پر برقرار رکھا جائے گا۔ - اس مقام کے بعد ہمیشہ کے لیے ہر سال فروخت شدہ کل رقم کا 0.26x کان کنوں کو مختص کیا جائے گا۔ | گروپ | لانچ کے وقت | 1 سال بعد | 5 سال بعد | | ---------------------- | --------- | ------------ | ------------- | | کرنسی یونٹس | 1.198X | 1.458X | 2.498X | | خریدار | 83.5% | 68.6% | 40.0% | | فروخت سے پہلے خرچ شدہ ریزرو | 8.26% | 6.79% | 3.96% | | فروخت کے بعد استعمال شدہ ریزرو | 8.26% | 6.79% | 3.96% | | کان کن | 0% | 17.8% | 52.0% | #### طویل مدتی سپلائی کی شرح نمو (فیصد) {#long-term-supply-growth-rate-percent} ![Ethereum inflation](./ethereum-inflation.png) _لینیئر کرنسی کے اجراء کے باوجود، بالکل بٹ کوائن کی طرح وقت گزرنے کے ساتھ سپلائی کی شرح نمو صفر کی طرف مائل ہوتی ہے۔_ مذکورہ بالا ماڈل میں دو اہم انتخاب یہ ہیں (1) انڈوومنٹ پول (endowment pool) کی موجودگی اور سائز، اور (2) بٹ کوائن کی طرح محدود سپلائی کے برعکس، مستقل طور پر بڑھتی ہوئی لینیئر سپلائی کی موجودگی۔ انڈوومنٹ پول کا جواز درج ذیل ہے۔ اگر انڈوومنٹ پول موجود نہ ہوتا، اور لینیئر اجراء کم ہو کر 0.217x ہو جاتا تاکہ افراط زر کی وہی شرح فراہم کی جا سکے، تو ایتھر کی کل مقدار 16.5% کم ہوتی اور اس طرح ہر یونٹ 19.8% زیادہ قیمتی ہوتا۔ لہذا، توازن میں فروخت میں 19.8% زیادہ ایتھر خریدا جاتا، لہذا ہر یونٹ ایک بار پھر بالکل پہلے جتنا ہی قیمتی ہوتا۔ اس کے بعد تنظیم کے پاس 1.198x زیادہ BTC بھی ہوتا، جسے دو حصوں میں تقسیم سمجھا جا سکتا ہے: اصل BTC، اور اضافی 0.198x۔ لہذا، یہ صورتحال انڈوومنٹ کے _بالکل مساوی_ ہے، لیکن ایک اہم فرق کے ساتھ: تنظیم خالصتاً BTC رکھتی ہے، اور اس لیے اسے ایتھر یونٹ کی قدر کو سہارا دینے کی ترغیب نہیں ملتی۔ مستقل لینیئر سپلائی کی شرح نمو کا ماڈل اس خطرے کو کم کرتا ہے جسے کچھ لوگ بٹ کوائن میں دولت کے ضرورت سے زیادہ ارتکاز کے طور پر دیکھتے ہیں، اور موجودہ اور مستقبل کے ادوار میں رہنے والے افراد کو کرنسی یونٹس حاصل کرنے کا منصفانہ موقع فراہم کرتا ہے، جبکہ ایک ہی وقت میں ایتھر حاصل کرنے اور رکھنے کی ایک مضبوط ترغیب برقرار رکھتا ہے کیونکہ فیصد کے لحاظ سے "سپلائی کی شرح نمو" اب بھی وقت کے ساتھ صفر کی طرف مائل ہوتی ہے۔ ہم یہ نظریہ بھی پیش کرتے ہیں کہ چونکہ لاپرواہی، موت وغیرہ کی وجہ سے وقت کے ساتھ سکے ہمیشہ ضائع ہو جاتے ہیں، اور سکوں کے نقصان کو ہر سال کل سپلائی کے فیصد کے طور پر ماڈل کیا جا سکتا ہے، اس لیے گردش میں موجود کل کرنسی کی سپلائی درحقیقت بالآخر سالانہ اجراء کو نقصان کی شرح سے تقسیم کرنے کے برابر قدر پر مستحکم ہو جائے گی (مثال کے طور پر، 1% کے نقصان کی شرح پر، ایک بار جب سپلائی 26X تک پہنچ جائے گی تو ہر سال 0.26X کی کان کنی کی جائے گی اور 0.26X ضائع ہو جائے گا، جس سے ایک توازن پیدا ہوگا)۔ نوٹ کریں کہ مستقبل میں، اس بات کا امکان ہے کہ ایتھیریم سیکیورٹی کے لیے حصہ داری کا ثبوت (PoS) ماڈل پر منتقل ہو جائے گا، جس سے اجراء کی ضرورت کم ہو کر صفر اور 0.05X فی سال کے درمیان رہ جائے گی۔ اس صورت میں کہ ایتھیریم تنظیم فنڈنگ کھو دیتی ہے یا کسی اور وجہ سے غائب ہو جاتی ہے، ہم ایک "سماجی معاہدہ" (social contract) کھلا چھوڑتے ہیں: کسی کو بھی ایتھیریم کا مستقبل کا امیدوار ورژن بنانے کا حق حاصل ہے، جس کی واحد شرط یہ ہے کہ ایتھر کی مقدار زیادہ سے زیادہ `60102216 * (1.198 + 0.26 * n)` کے برابر ہونی چاہیے جہاں `n` ابتدائی بلاک کے بعد سالوں کی تعداد ہے۔ تخلیق کار ترقی کی ادائیگی کے لیے PoS سے چلنے والی سپلائی کی توسیع اور زیادہ سے زیادہ قابل اجازت سپلائی کی توسیع کے درمیان فرق کا کچھ حصہ یا تمام حصہ ہجوم کو فروخت کرنے (crowd-sell) یا بصورت دیگر تفویض کرنے کے لیے آزاد ہیں۔ امیدوار اپ گریڈز جو سماجی معاہدے کی تعمیل نہیں کرتے ہیں انہیں بجا طور پر تعمیل کرنے والے ورژنز میں فورک کیا جا سکتا ہے۔ ### کان کنی کی مرکزیت {#mining-centralization} بٹ کوائن کی کان کنی کا الگورتھم اس طرح کام کرتا ہے کہ کان کن بلاک ہیڈر کے قدرے تبدیل شدہ ورژنز پر لاکھوں بار بار بار SHA-256 کا حساب لگاتے ہیں، یہاں تک کہ بالآخر ایک نوڈ ایک ایسا ورژن لے کر آتا ہے جس کا ہیش ہدف سے کم ہوتا ہے (فی الحال تقریباً 2192)۔ تاہم، کان کنی کا یہ الگورتھم مرکزیت کی دو شکلوں کا شکار ہے۔ پہلا، کان کنی کے ایکو سسٹم پر ASIC (ایپلیکیشن کے لیے مخصوص انٹیگریٹڈ سرکٹس) کا غلبہ ہو گیا ہے، یہ کمپیوٹر چپس ہیں جو بٹ کوائن کی کان کنی کے مخصوص کام کے لیے ڈیزائن کی گئی ہیں، اور اس لیے ہزاروں گنا زیادہ کارآمد ہیں۔ اس کا مطلب یہ ہے کہ بٹ کوائن کی کان کنی اب کوئی انتہائی لامركزی اور مساوی مشغلہ نہیں رہی، جس میں مؤثر طریقے سے حصہ لینے کے لیے لاکھوں ڈالر کے سرمائے کی ضرورت ہوتی ہے۔ دوسرا، زیادہ تر بٹ کوائن کان کن دراصل مقامی طور پر بلاک کی توثیق نہیں کرتے؛ اس کے بجائے، وہ بلاک ہیڈرز فراہم کرنے کے لیے ایک مرکزی مائننگ پول پر انحصار کرتے ہیں۔ یہ مسئلہ بلاشبہ بدتر ہے: اس تحریر کے وقت، سرفہرست تین مائننگ پولز بالواسطہ طور پر بٹ کوائن نیٹ ورک میں پروسیسنگ پاور کے تقریباً 50% کو کنٹرول کرتے ہیں، حالانکہ اس میں اس حقیقت سے کمی آتی ہے کہ اگر کوئی پول یا اتحاد ۵۱٪ حملہ کرنے کی کوشش کرتا ہے تو کان کن دوسرے مائننگ پولز میں جا سکتے ہیں۔ ایتھیریم میں موجودہ ارادہ ایک ایسا کان کنی کا الگورتھم استعمال کرنا ہے جہاں کان کنوں کو حالت سے بے ترتیب ڈیٹا لانے، بلاک چین میں پچھلے N بلاکس سے تصادفی طور پر منتخب کردہ کچھ ٹرانزیکشنز کا حساب لگانے، اور نتیجے کا ہیش واپس کرنے کی ضرورت ہوتی ہے۔ اس کے دو اہم فوائد ہیں۔ پہلا، ایتھیریم کنٹریکٹس میں کسی بھی قسم کی کمپیوٹیشن شامل ہو سکتی ہے، لہذا ایک ایتھیریم ASIC بنیادی طور پر عام کمپیوٹیشن کے لیے ایک ASIC ہوگا - یعنی، ایک بہتر CPU۔ دوسرا، کان کنی کے لیے پوری بلاک چین تک رسائی کی ضرورت ہوتی ہے، جو کان کنوں کو پوری بلاک چین کو ذخیرہ کرنے اور کم از کم ہر ٹرانزیکشن کی تصدیق کرنے کے قابل ہونے پر مجبور کرتی ہے۔ یہ مرکزی مائننگ پولز کی ضرورت کو ختم کر دیتا ہے؛ اگرچہ مائننگ پولز اب بھی انعام کی تقسیم کی بے ترتیبی کو ہموار کرنے کا جائز کردار ادا کر سکتے ہیں، لیکن یہ کام بغیر کسی مرکزی کنٹرول کے پیئر ٹو پیئر پولز کے ذریعے بھی اتنی ہی اچھی طرح انجام دیا جا سکتا ہے۔ یہ ماڈل غیر آزمودہ ہے، اور کان کنی کے الگورتھم کے طور پر کنٹریکٹ پر عمل درآمد کا استعمال کرتے وقت کچھ چالاک اصلاحات (optimizations) سے بچنے میں راستے میں مشکلات پیش آ سکتی ہیں۔ تاہم، اس الگورتھم کی ایک خاص طور پر دلچسپ خصوصیت یہ ہے کہ یہ کسی کو بھی بلاک چین میں خاص طور پر کچھ ASIC کو روکنے کے لیے ڈیزائن کیے گئے کنٹریکٹس کی ایک بڑی تعداد متعارف کروا کر "کنویں میں زہر ملانے" (poison the well) کی اجازت دیتا ہے۔ ASIC مینوفیکچررز کے لیے ایک دوسرے پر حملہ کرنے کے لیے ایسی چال استعمال کرنے کی معاشی ترغیبات موجود ہیں۔ اس طرح، جو حل ہم تیار کر رہے ہیں وہ بالآخر خالصتاً تکنیکی حل کے بجائے ایک موافق معاشی انسانی حل ہے۔ ### اسکیل ایبلٹی {#scalability} ایتھیریم کے بارے میں ایک عام تشویش اسکیل ایبلٹی کا مسئلہ ہے۔ بٹ کوائن کی طرح، ایتھیریم بھی اس خامی کا شکار ہے کہ ہر ٹرانزیکشن کو نیٹ ورک کے ہر نوڈ کے ذریعے پروسیس کرنے کی ضرورت ہوتی ہے۔ بٹ کوائن کے ساتھ، موجودہ بلاک چین کا سائز تقریباً 15 GB ہے، جو تقریباً 1 MB فی گھنٹہ کی رفتار سے بڑھ رہا ہے۔ اگر بٹ کوائن نیٹ ورک ویزا (Visa) کی 2000 ٹرانزیکشنز فی سیکنڈ پروسیس کرے، تو یہ ہر تین سیکنڈ میں 1 MB (1 GB فی گھنٹہ، 8 TB فی سال) بڑھے گا۔ ایتھیریم کو بھی اسی طرح کے ترقی کے پیٹرن کا سامنا کرنے کا امکان ہے، جو اس حقیقت سے مزید خراب ہو جاتا ہے کہ ایتھیریم بلاک چین کے اوپر صرف ایک کرنسی کے بجائے بہت سی ایپلی کیشنز ہوں گی جیسا کہ بٹ کوائن کے معاملے میں ہے، لیکن اس حقیقت سے بہتری آتی ہے کہ ایتھیریم کے مکمل نوڈز کو پوری بلاک چین کی تاریخ کے بجائے صرف حالت کو ذخیرہ کرنے کی ضرورت ہوتی ہے۔ بلاک چین کے اتنے بڑے سائز کے ساتھ مسئلہ مرکزیت کا خطرہ ہے۔ اگر بلاک چین کا سائز بڑھ کر، فرض کریں، 100 TB ہو جاتا ہے، تو ممکنہ منظر نامہ یہ ہوگا کہ صرف بہت کم تعداد میں بڑے کاروبار مکمل نوڈز چلائیں گے، جبکہ تمام باقاعدہ صارفین لائٹ SPV نوڈز استعمال کریں گے۔ ایسی صورتحال میں، یہ ممکنہ تشویش پیدا ہوتی ہے کہ مکمل نوڈز اکٹھے ہو سکتے ہیں اور سب کسی منافع بخش انداز میں دھوکہ دینے پر متفق ہو سکتے ہیں (مثلاً، بلاک ریوارڈ تبدیل کرنا، خود کو BTC دینا)۔ لائٹ نوڈز کے پاس فوری طور پر اس کا پتہ لگانے کا کوئی طریقہ نہیں ہوگا۔ یقیناً، کم از کم ایک ایماندار مکمل نوڈ کے موجود ہونے کا امکان ہوگا، اور چند گھنٹوں کے بعد ریڈٹ جیسے چینلز کے ذریعے دھوکہ دہی کے بارے میں معلومات سامنے آ جائیں گی، لیکن اس وقت تک بہت دیر ہو چکی ہوگی: یہ عام صارفین پر منحصر ہوگا کہ وہ دیے گئے بلاکس کو بلیک لسٹ کرنے کی کوشش کو منظم کریں، جو کہ ایک کامیاب ۵۱٪ حملہ کرنے کے پیمانے پر ایک بڑے اور ممکنہ طور پر ناقابل عمل ہم آہنگی کا مسئلہ ہے۔ بٹ کوائن کے معاملے میں، یہ فی الحال ایک مسئلہ ہے، لیکن [پیٹر ٹوڈ کی طرف سے تجویز کردہ](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) ایک بلاک چین ترمیم موجود ہے جو اس مسئلے کو کم کر دے گی۔ مستقبل قریب میں، ایتھیریم اس مسئلے سے نمٹنے کے لیے دو اضافی حکمت عملیاں استعمال کرے گا۔ پہلا، بلاک چین پر مبنی کان کنی کے الگورتھم کی وجہ سے، کم از کم ہر کان کن کو مکمل نوڈ بننے پر مجبور کیا جائے گا، جس سے مکمل نوڈز کی تعداد پر ایک نچلی حد پیدا ہوگی۔ دوسرا اور اس سے بھی اہم بات، تاہم، ہم ہر ٹرانزیکشن کو پروسیس کرنے کے بعد بلاک چین میں ایک درمیانی حالت کے ٹری روٹ (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) پروٹوکول ہے: تصدیقی نوڈز ہدف ٹرانزیکشن کے اشاریوں کی شکل میں "چیلنجز" جاری کرتے ہیں، اور ایک نوڈ موصول ہونے پر ایک لائٹ نوڈ بلاک کو اس وقت تک ناقابل اعتبار سمجھتا ہے جب تک کہ کوئی دوسرا نوڈ، چاہے وہ کان کن ہو یا کوئی اور تصدیق کنندہ، درستگی کے ثبوت کے طور پر پیٹریشیا نوڈز کا سب سیٹ فراہم نہ کرے۔ ## نتیجہ {#conclusion} ایتھیریم پروٹوکول کا اصل تصور ایک کرپٹو کرنسی کے اپ گریڈ شدہ ورژن کے طور پر کیا گیا تھا، جو ایک انتہائی عمومی پروگرامنگ زبان کے ذریعے بلاک چین پر ایسکرو، انخلا کی حدود، مالیاتی کنٹریکٹس، جوئے کی مارکیٹس اور اس جیسی دیگر جدید خصوصیات فراہم کرتا ہے۔ ایتھیریم پروٹوکول براہ راست کسی بھی ایپلی کیشن کو "سپورٹ" نہیں کرے گا، لیکن ایک ٹیورنگ-کمپلیٹ پروگرامنگ زبان کی موجودگی کا مطلب یہ ہے کہ نظریاتی طور پر کسی بھی ٹرانزیکشن کی قسم یا ایپلی کیشن کے لیے من مانی کنٹریکٹس بنائے جا سکتے ہیں۔ تاہم، ایتھیریم کے بارے میں زیادہ دلچسپ بات یہ ہے کہ ایتھیریم پروٹوکول صرف کرنسی سے کہیں آگے نکل جاتا ہے۔ لامركزی فائل اسٹوریج، لامركزی کمپیوٹیشن اور لامركزی پیشین گوئی کی مارکیٹس کے ارد گرد موجود پروٹوکولز، درجنوں دیگر ایسے تصورات کے ساتھ، کمپیوٹیشنل انڈسٹری کی کارکردگی کو نمایاں طور پر بڑھانے کی صلاحیت رکھتے ہیں، اور پہلی بار ایک معاشی تہہ کا اضافہ کر کے دیگر پیئر ٹو پیئر پروٹوکولز کو بڑے پیمانے پر فروغ دے سکتے ہیں۔ آخر میں، ایپلی کیشنز کی ایک بڑی تعداد ایسی بھی ہے جن کا پیسوں سے بالکل کوئی تعلق نہیں ہے۔ ایتھیریم پروٹوکول کے ذریعے نافذ کردہ صوابدیدی حالت کے ٹرانزیشن فنکشن کا تصور ایک منفرد صلاحیت والے پلیٹ فارم کی فراہمی کرتا ہے؛ ڈیٹا اسٹوریج، جوئے یا مالیات میں ایپلی کیشنز کی ایک مخصوص صف کے لیے بنائے گئے محدود اور واحد مقصد والے پروٹوکول کے بجائے، ایتھیریم اپنے ڈیزائن کے لحاظ سے اوپن اینڈڈ ہے، اور ہمارا ماننا ہے کہ یہ آنے والے سالوں میں مالیاتی اور غیر مالیاتی دونوں طرح کے پروٹوکولز کی ایک بہت بڑی تعداد کے لیے ایک بنیادی تہہ کے طور پر کام کرنے کے لیے انتہائی موزوں ہے۔ ## نوٹس اور مزید مطالعہ {#notes-and-further-reading} ### نوٹس {#notes} 1. ایک سمجھدار قاری یہ محسوس کر سکتا ہے کہ درحقیقت ایک بٹ کوائن پتہ بیضوی منحنی (elliptic curve) کی عوامی کلید کا ہیش ہوتا ہے، نہ کہ خود عوامی کلید۔ تاہم، پب کی (pubkey) ہیش کو خود ایک عوامی کلید کے طور پر حوالہ دینا درحقیقت بالکل درست تشفیری (cryptographic) اصطلاح ہے۔ اس کی وجہ یہ ہے کہ بٹ کوائن کی کرپٹوگرافی کو ایک کسٹم ڈیجیٹل دستخط کا الگورتھم سمجھا جا سکتا ہے، جہاں عوامی کلید ECC عوامی کلید کے ہیش پر مشتمل ہوتی ہے، دستخط ECC عوامی کلید اور ECC دستخط کے ملاپ پر مشتمل ہوتا ہے، اور تصدیقی الگورتھم میں دستخط میں موجود ECC عوامی کلید کو بطور عوامی کلید فراہم کردہ ECC عوامی کلید کے ہیش سے جانچنا اور پھر ECC عوامی کلید کے خلاف ECC دستخط کی تصدیق کرنا شامل ہے۔ 2. تکنیکی طور پر، پچھلے ۱۱ بلاکس کا وسطانیہ (median)۔ 3. اندرونی طور پر، 2 اور "CHARLIE" دونوں نمبر ہیں، جن میں مؤخر الذکر بگ اینڈِین بیس 256 کی نمائندگی میں ہے۔ نمبر کم از کم 0 اور زیادہ سے زیادہ 2256-1 ہو سکتے ہیں۔ ### مزید مطالعہ {#further-reading} 1. [اندرونی قدر](https://bitcoinmagazine.com/culture/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it) 2. [سمارٹ پراپرٹی](https://en.bitcoin.it/wiki/Smart_Property) 3. [سمارٹ کنٹریکٹس](https://en.bitcoin.it/wiki/Contracts) 4. [B-money](https://nakamotoinstitute.org/b-money/) 5. [دوبارہ قابل استعمال ثبوتِ کار](https://nakamotoinstitute.org/finney/rpow/) 6. [مالک کے اختیار کے ساتھ محفوظ پراپرٹی ٹائٹلز](https://nakamotoinstitute.org/library/secure-property-titles/) 7. [بٹ کوائن وائٹ پیپر](https://bitcoin.org/bitcoin.pdf) 8. [Namecoin](https://namecoin.org/) 9. [زوکو کی مثلث](https://wikipedia.org/wiki/Zooko's_triangle) 10. [رنگین کوائنز کا وائٹ پیپر](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) 11. [ماسٹر کوائن وائٹ پیپر](https://github.com/mastercoin-MSC/spec) 12. [لامركزی خود مختار کارپوریشنز، بٹ کوائن میگزین](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) 13. [آسان ادائیگی کی تصدیق](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification) 14. [مرکل ٹریز](https://wikipedia.org/wiki/Merkle_tree) 15. [پیٹریشیا ٹریز](https://wikipedia.org/wiki/Patricia_tree) 16. [GHOST](https://eprint.iacr.org/2013/881.pdf) 17. [StorJ اور خود مختار ایجنٹس، جیف گارزک](https://garzikrants.blogspot.com/2013/01/storj-and-bitcoin-autonomous-agents.html) 18. [ٹیورنگ فیسٹیول میں سمارٹ پراپرٹی پر مائیک ہرن](https://www.youtube.com/watch?v=MVyv4t0OKe4) 19. [ایتھیریم RLP](/developers/docs/data-structures-and-encoding/rlp/) 20. [ایتھیریم مرکل پیٹریشیا ٹریز](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) 21. [مرکل سم ٹریز پر پیٹر ٹوڈ](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) _وائٹ پیپر کی تاریخ کے لیے، [یہ وکی](https://web.archive.org/web/20250427212319/https://ethereum.org/whitepaper/) دیکھیں۔_ _ایتھیریم، بہت سے کمیونٹی کے زیرِ انتظام، اوپن سورس سافٹ ویئر پروجیکٹس کی طرح، اپنے ابتدائی آغاز کے بعد سے تیار ہوا ہے۔ ایتھیریم کی تازہ ترین پیشرفت، اور پروٹوکول میں تبدیلیاں کیسے کی جاتی ہیں، اس کے بارے میں جاننے کے لیے ہم [اس گائیڈ](/learn/) کی سفارش کرتے ہیں۔_