اگر ہم ایک دوسرے پر بھروسہ نہیں کرتے تو کیا بے ترتیب نمبر بنانا ممکن ہے؟ حصہ 1

ارے حبر!

اس مضمون میں میں ان شرکاء کے ذریعے چھدم بے ترتیب نمبروں کی نسل کے بارے میں بات کروں گا جو ایک دوسرے پر بھروسہ نہیں کرتے ہیں۔ جیسا کہ ہم ذیل میں دیکھیں گے، "تقریباً" اچھے جنریٹر کو لاگو کرنا بہت آسان ہے، لیکن بہت اچھا جنریٹر مشکل ہے۔

ایک دوسرے پر بھروسہ نہ کرنے والے شرکاء کے درمیان بے ترتیب نمبر پیدا کرنا کیوں ضروری ہوگا؟ ایک درخواست کا علاقہ وکندریقرت ایپلی کیشنز ہے۔ مثال کے طور پر، ایک درخواست جو کسی شریک سے شرط قبول کرتی ہے اور یا تو 49% امکان کے ساتھ رقم کو دگنا کرتی ہے یا 51% امکان کے ساتھ لے جاتی ہے صرف اس صورت میں کام کرے گی جب وہ غیر جانبدارانہ طور پر بے ترتیب نمبر حاصل کر سکے۔ اگر کوئی حملہ آور بے ترتیب نمبر جنریٹر کے نتائج کو متاثر کر سکتا ہے، اور درخواست میں ادائیگی حاصل کرنے کے اپنے امکانات کو بھی تھوڑا سا بڑھا سکتا ہے، تو وہ اسے آسانی سے تباہ کر دے گا۔

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

1. اسے غیرجانبدار ہونا چاہیے۔ دوسرے الفاظ میں، کسی بھی شریک کو کسی بھی طرح سے بے ترتیب نمبر جنریٹر کے نتیجے پر اثر انداز نہیں ہونا چاہیے۔

2. وہ غیر متوقع ہونا چاہیے۔ دوسرے لفظوں میں، کسی بھی شریک کو یہ اندازہ نہیں لگانا چاہیے کہ کون سا نمبر تیار کیا جائے گا (یا اس کی کسی خاصیت کا اندازہ لگانا) اس کے تیار ہونے سے پہلے۔

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

اس مضمون میں ہم دو طریقوں کو دیکھیں گے: RANDAO + VDF اور مٹانے والے کوڈز کا نقطہ نظر۔ اگلے حصے میں، ہم حد کے دستخطوں پر مبنی نقطہ نظر کا تفصیل سے جائزہ لیں گے۔

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

رنڈاؤ

RANDAO بے ترتیب پن پیدا کرنے کے لیے ایک بہت ہی آسان اور اس لیے عام طور پر استعمال ہونے والا طریقہ ہے۔ نیٹ ورک کے تمام شرکاء پہلے مقامی طور پر ایک سیوڈورنڈم نمبر منتخب کرتے ہیں، پھر ہر شریک منتخب نمبر کا ایک ہیش بھیجتا ہے۔ اس کے بعد، شرکاء باری باری اپنے منتخب کردہ نمبروں کو ظاہر کرتے ہیں اور ظاہر کردہ نمبروں پر ایک XOR آپریشن کرتے ہیں، اور اس آپریشن کا نتیجہ پروٹوکول کا نتیجہ بنتا ہے۔

نمبروں کو ظاہر کرنے سے پہلے ہیش شائع کرنے کا مرحلہ ضروری ہے تاکہ حملہ آور دوسرے شرکاء کے نمبر دیکھنے کے بعد اپنا نمبر منتخب نہ کر سکے۔ اس سے وہ عملی طور پر اکیلے ہی بے ترتیب نمبر جنریٹر کے آؤٹ پٹ کا تعین کر سکے گا۔

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

ہم نے اوپر بیان کردہ خصوصیات میں سے کون سی RANDAO کے پاس ہے؟ یہ غیر متوقع ہے، بنیادی اتفاق رائے پروٹوکول کے طور پر ایک ہی جیورنبل ہے، لیکن یہ متعصب ہے۔ خاص طور پر، حملہ آور نیٹ ورک کا مشاہدہ کر سکتا ہے، اور دوسرے شرکاء کے اپنے نمبر ظاہر کرنے کے بعد، وہ اپنے XOR کا حساب لگا سکتا ہے، اور فیصلہ کر سکتا ہے کہ آیا نتیجہ پر اثر انداز ہونے کے لیے اس کا نمبر ظاہر کرنا ہے یا نہیں۔ اگرچہ یہ حملہ آور کو بے ترتیب نمبر جنریٹر کے آؤٹ پٹ کا تعین کرنے سے روکتا ہے، یہ اب بھی اسے 1 بٹ اثر دیتا ہے۔ اور اگر حملہ آور کئی شرکاء کو کنٹرول کرتے ہیں، تو ان کے کنٹرول میں بٹس کی تعداد ان کے زیر کنٹرول شرکاء کی تعداد کے برابر ہوگی۔

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

RANDAO+VDF

RANDAO کو غیرجانبدار بنانے کا ایک طریقہ یہ ہے: تمام نمبروں کے سامنے آنے اور XOR کا حساب لگانے کے بعد، اس کا نتیجہ کسی فنکشن کے ان پٹ میں ڈال دیا جاتا ہے، جس کا حساب لگانے میں بہت وقت لگتا ہے، لیکن آپ کو اس کی درستگی کی جانچ کرنے کی اجازت دیتا ہے۔ بہت تیزی سے حساب.

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленно
correct = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

اس فنکشن کو Verifiable Delay Function، یا VDF کہا جاتا ہے۔ اگر حتمی نتیجہ کا حساب لگانے میں تعداد کے انکشاف کے مرحلے سے زیادہ وقت لگتا ہے، تو حملہ آور اپنا نمبر دکھانے یا چھپانے کے اثر کا اندازہ نہیں لگا سکے گا، اور اس وجہ سے وہ نتیجہ پر اثر انداز ہونے کا موقع کھو دے گا۔

اچھے VDFs تیار کرنا انتہائی مشکل ہے۔ حال ہی میں کئی پیش رفت ہوئی ہیں، جیسے یہ и یہ، جس نے VDF کو عملی طور پر مزید عملی بنا دیا، اور Ethereum 2.0 طویل مدت میں VDF کے ساتھ RANDAO کو بے ترتیب نمبر کے ذریعہ استعمال کرنے کا ارادہ رکھتا ہے۔ اس حقیقت کے علاوہ کہ یہ نقطہ نظر غیر متوقع اور غیر جانبدارانہ ہے، اس کے قابل عمل ہونے کا اضافی فائدہ ہے اگر نیٹ ورک پر کم از کم دو شرکاء دستیاب ہوں (یہ فرض کرتے ہوئے کہ اتنی کم تعداد میں شرکاء سے نمٹنے کے دوران اتفاق رائے کا پروٹوکول قابل عمل ہے)۔

اس نقطہ نظر کا سب سے بڑا چیلنج VDF کو اس طرح ترتیب دینا ہے کہ بہت مہنگے خصوصی ہارڈ ویئر کے ساتھ ایک شریک بھی دریافت کے مرحلے کے اختتام سے پہلے VDF کا حساب نہیں لگا سکے گا۔ مثالی طور پر، الگورتھم میں ایک اہم حفاظتی مارجن بھی ہونا چاہیے، 10x کا کہنا ہے۔ نیچے دی گئی تصویر ایک اداکار کے حملے کو ظاہر کرتی ہے جس کے پاس ایک خصوصی ASIC ہے جو اسے RANDAO تصدیق کو ظاہر کرنے کے لیے مختص وقت سے زیادہ تیزی سے VDF چلانے کی اجازت دیتا ہے۔ ایسا حصہ لینے والا اپنے نمبر کا استعمال کرتے ہوئے یا نہ کرنے کے بعد بھی حتمی نتیجہ کا حساب لگا سکتا ہے، اور پھر، حساب کی بنیاد پر، انتخاب کرتا ہے کہ آیا اسے دکھانا ہے یا نہیں۔

اوپر ذکر کردہ VDF فیملی کے لیے، ایک وقف شدہ ASIC کی کارکردگی روایتی ہارڈ ویئر سے 100+ گنا زیادہ ہو سکتی ہے۔ لہذا اگر تعیناتی کا مرحلہ 10 سیکنڈ تک جاری رہتا ہے، تو اس طرح کے ASIC پر شمار کیے گئے VDF کو 100x حفاظتی مارجن حاصل کرنے میں 10 سیکنڈ سے زیادہ کا وقت لگنا چاہیے، اور اس طرح کموڈٹی ہارڈویئر پر شمار کیے گئے اسی VDF کو 100x 100 سیکنڈ = ~ 3 گھنٹے لگنا چاہیے۔

Ethereum فاؤنڈیشن اس مسئلے کو حل کرنے کا ارادہ رکھتی ہے اپنی عوامی طور پر دستیاب، مفت ASICs بنا کر۔ ایک بار ایسا ہونے کے بعد، دیگر تمام پروٹوکولز بھی اس ٹیکنالوجی سے فائدہ اٹھا سکتے ہیں، لیکن اس وقت تک RANDAO+VDF اپروچ ان پروٹوکولز کے لیے اتنا قابل عمل نہیں ہوگا جو اپنے ASICs کو تیار کرنے میں سرمایہ کاری نہیں کر سکتے۔

VDF کے بارے میں بہت سے مضامین، ویڈیوز اور دیگر معلومات جمع کی گئی ہیں۔ اس سائٹ.

ہم مٹانے والے کوڈ استعمال کرتے ہیں۔

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

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

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

2. شرکاء مخصوص 67 شرکاء سے کوڈڈ سیٹ پر معاہدے تک پہنچنے کے لیے کسی قسم کے اتفاق رائے کا استعمال کرتے ہیں۔

3. ایک بار اتفاق رائے تک پہنچنے کے بعد، ہر شریک اپنی عوامی کلید کے ساتھ انکرپٹ کردہ 67 سیٹوں میں سے ہر ایک میں انکوڈ شدہ حصص لیتا ہے، ایسے تمام شیئرز کو ڈیکرپٹ کرتا ہے، اور ایسے تمام ڈکرپٹڈ شیئرز کو شائع کرتا ہے۔

4. ایک بار جب 67 شرکاء نے مرحلہ (3) مکمل کر لیا، تمام متفقہ سیٹوں کو مکمل طور پر ڈی کوڈ کیا جا سکتا ہے اور مٹانے والے کوڈز کی خصوصیات کی وجہ سے دوبارہ تشکیل دیا جا سکتا ہے، اور حتمی نمبر ابتدائی قطاروں کے XOR کے طور پر حاصل کیا جا سکتا ہے جس کے ساتھ شرکاء نے (1) میں آغاز کیا تھا۔ .

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

کیا ہوتا ہے اگر مرحلہ (1) میں ایک شرکاء نے دوسرے شرکاء کو انکوڈ شدہ شیئرز بھیجے جو کچھ سٹرنگ کے لیے درست مٹانے والے کوڈ نہیں ہیں؟ اضافی تبدیلیوں کے بغیر، مختلف شرکاء یا تو سٹرنگ کو بالکل بھی بازیافت نہیں کر پائیں گے، یا وہ مختلف سٹرنگز کو بازیافت کریں گے، جس کے نتیجے میں مختلف شرکاء کو مختلف بے ترتیب نمبر ملیں گے۔ اس کو روکنے کے لیے، آپ درج ذیل کام کر سکتے ہیں: ہر شریک، انکوڈ شدہ حصص کے علاوہ، حساب بھی کرتا ہے۔ مرکلا کا درخت اس طرح کے تمام حصص، اور ہر شریک کو انکوڈ شدہ شیئر خود اور مرکل کے درخت کی جڑ، اور مرکل کے درخت میں حصہ کی شمولیت کا ثبوت بھیجتا ہے۔ مرحلہ (2) میں اتفاق رائے میں، شرکاء پھر صرف سیٹوں کے سیٹ پر متفق نہیں ہوتے، بلکہ ایسے درختوں کی مخصوص جڑوں کے ایک سیٹ پر (اگر کچھ شرکاء پروٹوکول سے انحراف کرتے ہیں، اور مختلف شرکاء کو مرکل کے درخت کی مختلف جڑیں بھیجتے ہیں، اور اس طرح کی دو جڑیں اتفاق رائے کے دوران دکھائی گئی ہیں، اس کی قطار نتیجہ سیٹ میں شامل نہیں ہے)۔ اتفاق رائے کے نتیجے میں، ہمارے پاس 67 انکوڈ شدہ لائنیں ہوں گی اور مرکل کے درخت کی متعلقہ جڑیں اس طرح ہوں گی کہ کم از کم 67 شرکاء ہوں (ضروری نہیں کہ وہی لوگ ہوں جنہوں نے متعلقہ لائنوں کی تجویز پیش کی ہو)، جن کے پاس 67 لائنوں میں سے ہر ایک کے لیے مٹانے والے کوڈ کے ایک حصہ کے ساتھ ایک پیغام، اور متعلقہ درخت میں ان کے حصہ کے ختم ہونے کا ثبوت۔

جب مرحلہ (4) میں حصہ لینے والا ایک مخصوص سٹرنگ کے لیے 67 دھڑکنوں کو سمجھتا ہے اور ان سے اصل سٹرنگ کو دوبارہ بنانے کی کوشش کرتا ہے، ان میں سے ایک آپشن ممکن ہے:

1. اسٹرنگ کو بحال کیا جاتا ہے، اور اگر اسے دوبارہ مٹانے سے انکوڈ کیا جاتا ہے، اور مرکل کے درخت کو مقامی طور پر شمار کیے گئے حصص کے لیے شمار کیا جاتا ہے، تو جڑ اس کے ساتھ ملتی ہے جس پر اتفاق رائے ہوا تھا۔

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

3. قطار بحال نہیں ہوئی ہے۔

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

حد کے دستخط

بے ترتیب ہونے کا ایک اور طریقہ استعمال کرنا ہے جسے BLS تھریشولڈ دستخط کہتے ہیں۔ تھریشولڈ دستخطوں پر مبنی ایک بے ترتیب نمبر جنریٹر کے پاس بالکل وہی ضمانتیں ہوتی ہیں جو اوپر بیان کردہ مٹانے والے کوڈ پر مبنی الگورتھم کی ہوتی ہیں، لیکن اس میں ہر پیدا کردہ نمبر کے لیے نیٹ ورک پر بھیجے گئے پیغامات کی تعداد نمایاں طور پر کم ہوتی ہے۔

BLS دستخط ایک ایسا ڈیزائن ہے جو متعدد شرکاء کو پیغام کے لیے ایک مشترکہ دستخط بنانے کی اجازت دیتا ہے۔ یہ دستخط اکثر جگہ اور بینڈوتھ کو بچانے کے لیے استعمال کیے جاتے ہیں جس کے لیے متعدد دستخطوں کو بھیجنے کی ضرورت نہیں ہوتی ہے۔ 

بلاکچین پروٹوکولز میں BLS دستخطوں کے لیے ایک عام درخواست، بے ترتیب نمبر بنانے کے علاوہ، BFT پروٹوکول میں بلاک سائن کرنا ہے۔ فرض کریں کہ 100 شرکاء بلاکس بناتے ہیں، اور اگر ان میں سے 67 اس پر دستخط کرتے ہیں تو ایک بلاک کو حتمی سمجھا جاتا ہے۔ وہ سبھی BLS دستخط کے اپنے حصے جمع کر سکتے ہیں اور ان میں سے 67 پر متفق ہونے کے لیے کچھ متفقہ الگورتھم استعمال کر سکتے ہیں اور پھر انہیں ایک BLS دستخط میں ضم کر سکتے ہیں۔ حتمی دستخط بنانے کے لیے کوئی بھی 67 (یا اس سے زیادہ) حصوں کا استعمال کیا جا سکتا ہے، جس کا انحصار اس بات پر ہوگا کہ 67 دستخطوں کو یکجا کیا گیا تھا اور اس لیے مختلف ہو سکتے ہیں، اگرچہ 67 شرکاء کے مختلف انتخاب ایک مختلف دستخط بنائیں گے، ایسا کوئی بھی دستخط درست ہوگا۔ بلاک کے لیے دستخط۔ اس کے بعد باقی شرکاء کو نیٹ ورک پر 67 کے بجائے فی بلاک صرف ایک دستخط وصول کرنے اور اس کی تصدیق کرنے کی ضرورت ہے، جس سے نیٹ ورک پر بوجھ نمایاں طور پر کم ہو جاتا ہے۔

اس سے پتہ چلتا ہے کہ اگر وہ نجی چابیاں جو شرکاء استعمال کرتے ہیں ایک خاص طریقے سے تیار کی جاتی ہیں، تو اس سے کوئی فرق نہیں پڑتا ہے کہ 67 دستخط (یا زیادہ، لیکن کم نہیں) جمع کیے جائیں، نتیجے میں دستخط ایک ہی ہوں گے۔ اسے بے ترتیب ہونے کے ایک ذریعہ کے طور پر استعمال کیا جا سکتا ہے: شرکاء پہلے کسی پیغام پر اتفاق کرتے ہیں جس پر وہ دستخط کریں گے (یہ RANDAO کا آؤٹ پٹ ہو سکتا ہے یا صرف آخری بلاک کا ہیش ہو سکتا ہے، اس سے کوئی فرق نہیں پڑتا جب تک کہ یہ ہر بار تبدیل ہوتا ہے۔ اور مستقل ہے) اور اس کے لیے ایک BLS دستخط بنائیں۔ جنریشن کا نتیجہ اس وقت تک غیر متوقع ہو گا جب تک کہ 67 شرکاء اپنے حصے فراہم نہیں کر دیتے، اور اس کے بعد آؤٹ پٹ پہلے سے طے شدہ ہے اور کسی بھی شریک کے اعمال پر انحصار نہیں کر سکتا۔

بے ترتیب ہونے کا یہ نقطہ نظر اس وقت تک قابل عمل ہے جب تک کہ کم از کم ⅔ شرکاء آن لائن دونوں پروٹوکول کی پیروی کریں، اور غیر جانبدارانہ اور غیر متوقع ہے جب تک کہ کم از کم ⅓ شرکاء پروٹوکول کی پیروی کریں۔ یہ نوٹ کرنا ضروری ہے کہ ایک حملہ آور جو ⅓ سے زیادہ لیکن ⅔ سے کم شرکاء کو کنٹرول کرتا ہے پروٹوکول کو روک سکتا ہے، لیکن اس کے آؤٹ پٹ کی پیش گوئی یا اثر انداز نہیں ہو سکتا۔

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

آخر میں

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

پروٹوکول کوڈ کھلا ہوا ہے، ہمارا نفاذ Rust میں لکھا ہوا ہے، اسے مل سکتا ہے۔ یہاں.

آپ دیکھ سکتے ہیں کہ NEAR کی ترقی کیسی دکھتی ہے اور آن لائن IDE میں تجربہ کر سکتے ہیں۔ یہاں.

آپ روسی زبان میں تمام خبروں پر عمل کر سکتے ہیں۔ ٹیلیگرام گروپ اور VKontakte پر گروپ، اور سرکاری میں انگریزی میں ٹویٹر.

встреч скорых встреч!

ماخذ: www.habr.com