ہاسکل کے ساتھ فن سی کو فنکشنل میں تبدیل کرنا: سیروکل نے ٹیلیگرام بلاک چین مقابلہ کیسے جیتا

آپ نے شاید وہ ٹیلیگرام سنا ہوگا۔ ٹن بلاکچین پلیٹ فارم لانچ کرنے والا ہے۔. لیکن شاید آپ کو ٹیلیگرام کی وہ خبر یاد نہیں آئی ہو گی۔ مقابلے کا اعلان کیا۔ اس پلیٹ فارم کے لیے ایک یا زیادہ سمارٹ معاہدوں کے نفاذ کے لیے۔

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

لیکن آئیے ایک چھوٹے سیاق و سباق سے شروع کرتے ہیں۔

مقابلہ اور اس کی شرائط

لہذا، شرکاء کے اہم کام ایک یا زیادہ مجوزہ سمارٹ معاہدوں پر عمل درآمد کے ساتھ ساتھ TON ماحولیاتی نظام کو بہتر بنانے کے لیے تجاویز پیش کرنا تھے۔ مقابلہ 24 ستمبر سے 15 اکتوبر تک جاری رہا اور نتائج کا اعلان صرف 15 نومبر کو کیا گیا۔ کافی عرصے سے، اس بات پر غور کرتے ہوئے کہ اس وقت کے دوران ٹیلیگرام نے C++ میں ایپلی کیشنز کے ڈیزائن اور ڈیولپمنٹ پر ہونے والے مقابلوں کے نتائج کا اعلان کرنے اور ٹیلیگرام میں VoIP کالز کے معیار کو جانچنے اور جانچنے میں کامیابی حاصل کی۔

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

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

ہم نے شرکت کرنے کا فیصلہ کیوں کیا؟

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

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

TON بلاکچین تحقیق

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

مقابلہ شروع ہونے تک، کوڈ شائع ہو چکا تھا، اس لیے وقت بچانے کے لیے، ہم نے ایک گائیڈ یا خلاصہ تلاش کرنے کا فیصلہ کیا۔ صارفین. بدقسمتی سے، اس سے کوئی نتیجہ نہیں نکلا - Ubuntu پر پلیٹ فارم کو جمع کرنے کی ہدایات کے علاوہ، ہمیں کوئی اور مواد نہیں ملا۔

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

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

نکس: منصوبے کو ایک ساتھ رکھنا

Serokell میں ہم بڑے پرستار ہیں۔ نکس. ہم اس کے ساتھ اپنے پروجیکٹ جمع کرتے ہیں اور ان کا استعمال کرتے ہوئے تعینات کرتے ہیں۔ نکس اوپس، اور ہمارے تمام سرورز پر انسٹال کیا گیا ہے۔ نکسوس. اس کی بدولت، ہماری تمام تعمیرات دوبارہ پیدا کی جا سکتی ہیں اور کسی بھی آپریٹنگ سسٹم پر کام کرتی ہیں جس پر نکس انسٹال کیا جا سکتا ہے۔

تو ہم نے تخلیق کرکے شروع کیا۔ TON اسمبلی کے لیے اظہار کے ساتھ نکس اوورلے. اس کی مدد سے، TON مرتب کرنا ممکن حد تک آسان ہے:

$ cd ~/.config/nixpkgs/overlays && git clone https://github.com/serokell/ton.nix
$ cd /path/to/ton/repo && nix-shell
[nix-shell]$ cmakeConfigurePhase && make

نوٹ کریں کہ آپ کو کوئی انحصار انسٹال کرنے کی ضرورت نہیں ہے۔ Nix جادوئی طور پر آپ کے لیے سب کچھ کرے گا، چاہے آپ NixOS، Ubuntu، یا macOS استعمال کر رہے ہوں۔

TON کے لیے پروگرامنگ

TON نیٹ ورک میں سمارٹ کنٹریکٹ کوڈ TON ورچوئل مشین (TVM) پر چلتا ہے۔ TVM دیگر ورچوئل مشینوں سے زیادہ پیچیدہ ہے، اور اس میں بہت دلچسپ فعالیت ہے، مثال کے طور پر، یہ اس کے ساتھ کام کر سکتی ہے۔ تسلسل и ڈیٹا کے لنکس.

مزید یہ کہ، TON کے لڑکوں نے تین نئی پروگرامنگ زبانیں بنائیں:

پانچ ایک یونیورسل اسٹیک پروگرامنگ لینگویج ہے جو اس سے ملتی جلتی ہے۔ چوتھا. اس کی انتہائی قابلیت TVM کے ساتھ بات چیت کرنے کی صلاحیت ہے۔

فن سی ایک سمارٹ کنٹریکٹ پروگرامنگ لینگویج ہے جو اس سے ملتی جلتی ہے۔ C اور دوسری زبان میں مرتب کیا گیا ہے - ففٹ اسمبلر۔

پانچواں اسمبلر - TVM کے لیے بائنری قابل عمل کوڈ بنانے کے لیے پانچ لائبریری۔ پانچویں اسمبلر کے پاس کمپائلر نہیں ہے۔ یہ ایمبیڈڈ ڈومین مخصوص زبان (ای ڈی ایس ایل).

ہمارا مقابلہ کام کرتا ہے۔

آخر میں، یہ ہماری کوششوں کے نتائج کو دیکھنے کا وقت ہے.

غیر مطابقت پذیر ادائیگی کا چینل

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

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

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

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

1. تفصیل اسی طرح کا نقطہ نظر، صرف ایک غیر سمتی چینل کے معاملے کے لیے۔
2. ٹیوٹوریل، جو ہمارے جیسا ہی خیال بیان کرتا ہے، لیکن بہت سی اہم تفصیلات کی وضاحت کیے بغیر، جیسا کہ عمومی درستگی اور تنازعات کے حل کے طریقہ کار۔

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

ہم نے معاہدے کو FunC میں لاگو کیا، اور ہم نے اپنے معاہدے کے ساتھ مکمل طور پر Fift میں تعامل کے لیے کمانڈ لائن یوٹیلیٹی لکھی، جیسا کہ منتظمین کی تجویز ہے۔ ہم اپنے CLI کے لیے کسی دوسری زبان کا انتخاب کر سکتے تھے، لیکن ہم یہ دیکھنے کے لیے Fit کو آزمانے میں دلچسپی رکھتے تھے کہ اس نے عملی طور پر کیسے کارکردگی کا مظاہرہ کیا۔

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

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

TVM ہاسکل ای ڈی ایس ایل

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

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

یہ ظاہر کرنے کے لیے کہ TVM اسمبلر کس طرح Haskell میں سرایت کرتا ہے، ہم نے اس پر ایک معیاری والیٹ نافذ کیا۔ یہاں پر توجہ دینے کے لئے چند چیزیں ہیں:

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

ملٹی سیگ والیٹ کا نفاذ ہمارے ای ڈی ایس ایل پر ایسا لگتا ہے:

main :: IO ()
main = putText $ pretty $ declProgram procedures methods
  where
    procedures =
      [ ("recv_external", decl recvExternal)
      , ("recv_internal", decl recvInternal)
      ]
    methods =
      [ ("seqno", declMethod getSeqno)
      ]

data Storage = Storage
  { sCnt :: Word32
  , sPubKey :: PublicKey
  }

instance DecodeSlice Storage where
  type DecodeSliceFields Storage = [PublicKey, Word32]
  decodeFromSliceImpl = do
    decodeFromSliceImpl @Word32
    decodeFromSliceImpl @PublicKey

instance EncodeBuilder Storage where
  encodeToBuilder = do
    encodeToBuilder @Word32
    encodeToBuilder @PublicKey

data WalletError
  = SeqNoMismatch
  | SignatureMismatch
  deriving (Eq, Ord, Show, Generic)

instance Exception WalletError

instance Enum WalletError where
  toEnum 33 = SeqNoMismatch
  toEnum 34 = SignatureMismatch
  toEnum _ = error "Uknown MultiSigError id"

  fromEnum SeqNoMismatch = 33
  fromEnum SignatureMismatch = 34

recvInternal :: '[Slice] :-> '[]
recvInternal = drop

recvExternal :: '[Slice] :-> '[]
recvExternal = do
  decodeFromSlice @Signature
  dup
  preloadFromSlice @Word32
  stacktype @[Word32, Slice, Signature]
  -- cnt cs sign

  pushRoot
  decodeFromCell @Storage
  stacktype @[PublicKey, Word32, Word32, Slice, Signature]
  -- pk cnt' cnt cs sign

  xcpu @1 @2
  stacktype @[Word32, Word32, PublicKey, Word32, Slice, Signature]
  -- cnt cnt' pk cnt cs sign

  equalInt >> throwIfNot SeqNoMismatch

  push @2
  sliceHash
  stacktype @[Hash Slice, PublicKey, Word32, Slice, Signature]
  -- hash pk cnt cs sign

  xc2pu @0 @4 @4
  stacktype @[PublicKey, Signature, Hash Slice, Word32, Slice, PublicKey]
  -- pubk sign hash cnt cs pubk

  chkSignU
  stacktype @[Bool, Word32, Slice, PublicKey]
  -- ? cnt cs pubk

  throwIfNot SignatureMismatch
  accept

  swap
  decodeFromSlice @Word32
  nip

  dup
  srefs @Word8

  pushInt 0
  if IsEq
  then ignore
  else do
    decodeFromSlice @Word8
    decodeFromSlice @(Cell MessageObject)
    stacktype @[Slice, Cell MessageObject, Word8, Word32, PublicKey]
    xchg @2
    sendRawMsg
    stacktype @[Slice, Word32, PublicKey]

  endS
  inc

  encodeToCell @Storage
  popRoot

getSeqno :: '[] :-> '[Word32]
getSeqno = do
  pushRoot
  cToS
  preloadFromSlice @Word32

ہمارے eDSL اور کثیر دستخط والے والیٹ کنٹریکٹ کا مکمل سورس کوڈ اس پر پایا جا سکتا ہے۔ یہ ذخیرہ. اور مزید تفصیل سے بتایا بلٹ ان زبانوں کے بارے میں، ہمارے ساتھی جارجی اگاپوف۔

مقابلہ اور TON کے بارے میں نتائج

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

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

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

اگر اس آرٹیکل کو پڑھنے کے بعد بھی آپ کے ذہن میں کوئی سوال ہے یا آپ کے پاس اپنے مسائل کو حل کرنے کے لیے TON کا استعمال کرنے کے بارے میں آئیڈیاز ہیں، ہمیں لکھیں - ہمیں اپنے تجربے کا اشتراک کرنے میں خوشی ہوگی۔

ماخذ: www.habr.com