ஹாஸ்கெல்லுடன் FunC ஐ FunCional ஆக மாற்றுதல்: டெலிகிராம் பிளாக்செயின் போட்டியில் செரோகெல் எப்படி வென்றார்

டெலிகிராம் என்று நீங்கள் கேள்விப்பட்டிருக்கலாம் டன் பிளாக்செயின் இயங்குதளத்தை அறிமுகப்படுத்த உள்ளது. ஆனால் நீண்ட காலத்திற்கு முன்பு டெலிகிராம் செய்தியை நீங்கள் தவறவிட்டிருக்கலாம் ஒரு போட்டியை அறிவித்தார் இந்த தளத்திற்கான ஒன்று அல்லது அதற்கு மேற்பட்ட ஸ்மார்ட் ஒப்பந்தங்களை செயல்படுத்துவதற்கு.

செரோகெல் குழு, பெரிய பிளாக்செயின் திட்டங்களை உருவாக்குவதில் விரிவான அனுபவத்துடன், ஒதுங்கி நிற்க முடியவில்லை. நாங்கள் ஐந்து ஊழியர்களை போட்டிக்கு நியமித்தோம், இரண்டு வாரங்களுக்குப் பிறகு அவர்கள் அதில் (இன்) அடக்கமான சீரற்ற புனைப்பெயரான செக்ஸி பச்சோந்தியின் கீழ் முதல் இடத்தைப் பிடித்தனர். இந்த கட்டுரையில் அவர்கள் அதை எப்படி செய்தார்கள் என்பதைப் பற்றி பேசுவேன். அடுத்த பத்து நிமிடங்களில் நீங்கள் குறைந்தபட்சம் ஒரு சுவாரஸ்யமான கதையைப் படிப்பீர்கள் என்று நாங்கள் நம்புகிறோம், மேலும் உங்கள் வேலையில் நீங்கள் விண்ணப்பிக்கக்கூடிய பயனுள்ள ஒன்றை அதில் காணலாம்.

ஆனால் ஒரு சிறிய சூழலுடன் ஆரம்பிக்கலாம்.

போட்டி மற்றும் அதன் நிபந்தனைகள்

எனவே, பங்கேற்பாளர்களின் முக்கிய பணிகள் முன்மொழியப்பட்ட ஒன்று அல்லது அதற்கு மேற்பட்ட ஸ்மார்ட் ஒப்பந்தங்களைச் செயல்படுத்துதல், அத்துடன் டன் சுற்றுச்சூழல் அமைப்பை மேம்படுத்துவதற்கான திட்டங்களை உருவாக்குதல். போட்டி செப்டம்பர் 24 முதல் அக்டோபர் 15 வரை நடைபெற்றது, அதன் முடிவுகள் நவம்பர் 15 அன்று மட்டுமே அறிவிக்கப்பட்டன. இந்த நேரத்தில், டெலிகிராமில் VoIP அழைப்புகளின் தரத்தை சோதிப்பதற்கும் மதிப்பிடுவதற்கும் C++ இல் உள்ள பயன்பாடுகளின் வடிவமைப்பு மற்றும் மேம்பாடு குறித்த போட்டிகளின் முடிவுகளை டெலிகிராம் நடத்தவும் அறிவிக்கவும் முடிந்தது.

அமைப்பாளர்கள் முன்மொழிந்த பட்டியலில் இருந்து இரண்டு ஸ்மார்ட் ஒப்பந்தங்களைத் தேர்ந்தெடுத்துள்ளோம். அவற்றில் ஒன்றுக்கு, நாங்கள் TON உடன் விநியோகிக்கப்பட்ட கருவிகளைப் பயன்படுத்தினோம், இரண்டாவது எங்கள் பொறியாளர்களால் குறிப்பாக TONக்காக உருவாக்கப்பட்டு ஹாஸ்கெல்லுக்குள் கட்டமைக்கப்பட்ட புதிய மொழியில் செயல்படுத்தப்பட்டது.

செயல்பாட்டு நிரலாக்க மொழியின் தேர்வு தற்செயலானது அல்ல. எங்கள் பெருநிறுவன வலைப்பதிவு செயல்பாட்டு மொழிகளின் சிக்கலானது ஒரு பெரிய மிகைப்படுத்தல் என்று நாங்கள் ஏன் நினைக்கிறோம் மற்றும் பொதுவாக அவற்றை ஏன் பொருள் சார்ந்த மொழிகளுக்கு விரும்புகிறோம் என்பதைப் பற்றி அடிக்கடி பேசுகிறோம். மூலம், அது கொண்டுள்ளது இந்த கட்டுரையின் அசல்.

நாங்கள் ஏன் பங்கேற்க முடிவு செய்தோம்?

சுருக்கமாக, ஏனெனில் எங்கள் நிபுணத்துவம் என்பது தரமற்ற மற்றும் சிக்கலான திட்டங்களாகும், அவை சிறப்பு திறன்கள் தேவை மற்றும் பெரும்பாலும் IT சமூகத்திற்கு அறிவியல் மதிப்புடையவை. திறந்த மூல மேம்பாட்டை நாங்கள் வலுவாக ஆதரிக்கிறோம் மற்றும் அதை பிரபலப்படுத்துவதில் ஈடுபட்டுள்ளோம், மேலும் கணினி அறிவியல் மற்றும் கணிதத் துறையில் முன்னணி ரஷ்ய பல்கலைக்கழகங்களுடன் ஒத்துழைக்கிறோம்.

போட்டியின் சுவாரஸ்யமான பணிகள் மற்றும் எங்கள் அன்பான டெலிகிராம் திட்டத்தில் ஈடுபடுவது ஒரு சிறந்த உந்துதலாக இருந்தது, ஆனால் பரிசு நிதி கூடுதல் ஊக்கமாக மாறியது. 🙂

டன் பிளாக்செயின் ஆராய்ச்சி

பிளாக்செயின், செயற்கை நுண்ணறிவு மற்றும் இயந்திர கற்றல் ஆகியவற்றில் புதிய முன்னேற்றங்களை நாங்கள் உன்னிப்பாகக் கண்காணித்து, நாங்கள் பணிபுரியும் ஒவ்வொரு பகுதியிலும் ஒரு குறிப்பிடத்தக்க வெளியீட்டைத் தவறவிடாமல் இருக்க முயற்சிக்கிறோம். எனவே, போட்டி தொடங்கும் நேரத்தில், எங்கள் குழு ஏற்கனவே யோசனைகளை நன்கு அறிந்திருந்தது டன் வெள்ளை காகிதம். இருப்பினும், 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

நீங்கள் எந்த சார்புகளையும் நிறுவ வேண்டியதில்லை என்பதை நினைவில் கொள்ளவும். நீங்கள் NixOS, Ubuntu அல்லது macOS ஐப் பயன்படுத்தினாலும், நிக்ஸ் உங்களுக்காக எல்லாவற்றையும் அற்புதமாகச் செய்யும்.

TONக்கான நிரலாக்கம்

TON நெட்வொர்க்கில் உள்ள ஸ்மார்ட் ஒப்பந்தக் குறியீடு TON மெய்நிகர் இயந்திரத்தில் (TVM) இயங்குகிறது. மற்ற மெய்நிகர் இயந்திரங்களை விட TVM மிகவும் சிக்கலானது, மேலும் இது மிகவும் சுவாரஸ்யமான செயல்பாட்டைக் கொண்டுள்ளது, எடுத்துக்காட்டாக, இது வேலை செய்ய முடியும். தொடர்ச்சிகள் и தரவுக்கான இணைப்புகள்.

மேலும், TON இன் தோழர்கள் மூன்று புதிய நிரலாக்க மொழிகளை உருவாக்கினர்:

ஐந்து ஒத்திருக்கும் ஒரு உலகளாவிய அடுக்கு நிரலாக்க மொழி ஆகும் முன்னும் பின்னுமாக. TVM உடன் தொடர்பு கொள்ளும் திறன் அவரது சூப்பர் திறன்.

FunC போன்ற ஒரு ஸ்மார்ட் ஒப்பந்த நிரலாக்க மொழியாகும் C மற்றும் வேறொரு மொழியில் தொகுக்கப்பட்டுள்ளது - ஃபிஃப்ட் அசெம்பிளர்.

ஐந்தாவது அசெம்பிளர் — TVM க்கான பைனரி இயங்கக்கூடிய குறியீட்டை உருவாக்குவதற்கான ஐந்தாவது நூலகம். ஐந்தாவது அசெம்பிளரிடம் கம்பைலர் இல்லை. இது உட்பொதிக்கப்பட்ட டொமைன் குறிப்பிட்ட மொழி (eDSL).

எங்கள் போட்டி வேலை செய்கிறது

இறுதியாக, எங்கள் முயற்சிகளின் முடிவுகளைப் பார்க்க வேண்டிய நேரம் இது.

ஒத்திசைவற்ற கட்டண சேனல்

கட்டணச் சேனல் என்பது ஒரு ஸ்மார்ட் ஒப்பந்தமாகும், இது இரண்டு பயனர்கள் பிளாக்செயினுக்கு வெளியே பணம் அனுப்ப அனுமதிக்கிறது. இதன் விளைவாக, நீங்கள் பணத்தை மட்டும் சேமிக்கிறீர்கள் (கமிஷன் இல்லை), ஆனால் நேரத்தையும் (அடுத்த தொகுதி செயலாக்கப்படுவதற்கு நீங்கள் காத்திருக்க வேண்டியதில்லை). கொடுப்பனவுகள் விரும்பியபடி சிறியதாக இருக்கலாம் மற்றும் அடிக்கடி தேவைப்படும். இந்த வழக்கில், கட்சிகள் ஒருவரையொருவர் நம்ப வேண்டியதில்லை, ஏனெனில் இறுதி தீர்வின் நேர்மையானது ஸ்மார்ட் ஒப்பந்தத்தால் உத்தரவாதம் அளிக்கப்படுகிறது.

சிக்கலுக்கு மிகவும் எளிமையான தீர்வைக் கண்டோம். இரண்டு தரப்பினரும் கையொப்பமிடப்பட்ட செய்திகளை பரிமாறிக்கொள்ளலாம், ஒவ்வொன்றும் இரண்டு எண்களைக் கொண்டிருக்கும்—ஒவ்வொரு தரப்பினரும் செலுத்தும் முழுத் தொகை. இந்த இரண்டு எண்களும் செயல்படுகின்றன திசையன் கடிகாரம் பாரம்பரிய விநியோக அமைப்புகளில் மற்றும் பரிவர்த்தனைகளில் "முன் நடந்தது" வரிசையை அமைக்கவும். இந்தத் தரவைப் பயன்படுத்தி, சாத்தியமான முரண்பாடுகளை ஒப்பந்தத்தால் தீர்க்க முடியும்.

உண்மையில், இந்த யோசனையைச் செயல்படுத்த ஒரு எண் போதுமானது, ஆனால் நாங்கள் இரண்டையும் விட்டுவிட்டோம், ஏனெனில் இந்த வழியில் நாங்கள் மிகவும் வசதியான பயனர் இடைமுகத்தை உருவாக்க முடியும். கூடுதலாக, ஒவ்வொரு செய்தியிலும் கட்டணத் தொகையைச் சேர்க்க முடிவு செய்தோம். இது இல்லாமல், சில காரணங்களால் செய்தி தொலைந்துவிட்டால், அனைத்து அளவுகளும் இறுதிக் கணக்கீடும் சரியாக இருந்தாலும், பயனர் இழப்பை கவனிக்காமல் இருக்கலாம்.

எங்கள் யோசனையைச் சோதிக்க, இதுபோன்ற எளிய மற்றும் சுருக்கமான கட்டணச் சேனல் நெறிமுறையைப் பயன்படுத்துவதற்கான எடுத்துக்காட்டுகளைத் தேடினோம். ஆச்சரியப்படும் விதமாக, நாங்கள் இரண்டை மட்டுமே கண்டோம்:

1. விளக்கம் ஒரே மாதிரியான அணுகுமுறை, ஒரு திசை சேனல் விஷயத்தில் மட்டுமே.
2. பயிற்சி, இது எங்களுடைய அதே கருத்தை விவரிக்கிறது, ஆனால் பொதுவான சரியான தன்மை மற்றும் மோதல் தீர்வு நடைமுறைகள் போன்ற பல முக்கியமான விவரங்களை விளக்காமல்.

எங்கள் நெறிமுறையை விரிவாக விவரிப்பது அர்த்தமுள்ளதாக இருந்தது, அதன் சரியான தன்மைக்கு சிறப்பு கவனம் செலுத்துகிறது. பல மறு செய்கைகளுக்குப் பிறகு, விவரக்குறிப்பு தயாராக இருந்தது, இப்போது நீங்களும் செய்யலாம். அவளை பார்.

நாங்கள் ஒப்பந்தத்தை FunC இல் செயல்படுத்தினோம், மேலும் அமைப்பாளர்கள் பரிந்துரைத்தபடி, எங்கள் ஒப்பந்தத்துடன் முழுமையாக தொடர்புகொள்வதற்கான கட்டளை வரி பயன்பாட்டை நாங்கள் எழுதினோம். எங்கள் CLI க்காக வேறு எந்த மொழியையும் நாங்கள் தேர்வு செய்திருக்கலாம், ஆனால் அது நடைமுறையில் எவ்வாறு செயல்படுகிறது என்பதைப் பார்க்க ஃபிட்டை முயற்சிப்பதில் ஆர்வமாக உள்ளோம்.

உண்மையைச் சொல்வதென்றால், ஃபிஃப்டுடன் பணிபுரிந்த பிறகு, வளர்ந்த கருவிகள் மற்றும் நூலகங்களைக் கொண்ட பிரபலமான மற்றும் தீவிரமாகப் பயன்படுத்தப்படும் மொழிகளுக்கு இந்த மொழியை விரும்புவதற்கான எந்த கட்டாய காரணங்களையும் நாங்கள் காணவில்லை. ஸ்டாக் அடிப்படையிலான மொழியில் நிரலாக்கம் மிகவும் விரும்பத்தகாதது, ஏனெனில் அடுக்கில் உள்ளதை நீங்கள் தொடர்ந்து உங்கள் தலையில் வைத்திருக்க வேண்டும், மேலும் கம்பைலர் இதற்கு உதவாது.

எனவே, எங்கள் கருத்துப்படி, ஃபிஃப்ட்டின் இருப்புக்கான ஒரே நியாயம் ஃபிஃப்ட் அசெம்பிளருக்கான ஹோஸ்ட் மொழியாக அதன் பங்கு. ஆனால் டிவிஎம் அசெம்ப்லரை இந்த ஒரே நோக்கத்திற்காகப் புதியதைக் கண்டுபிடிப்பதை விட, ஏற்கனவே உள்ள சில மொழியில் உட்பொதிப்பது நல்லது அல்லவா?

TVM Haskell eDSL

இப்போது எங்கள் இரண்டாவது ஸ்மார்ட் ஒப்பந்தத்தைப் பற்றி பேச வேண்டிய நேரம் இது. பல கையொப்பம் கொண்ட பணப்பையை உருவாக்க முடிவு செய்தோம், ஆனால் FunC இல் மற்றொரு ஸ்மார்ட் ஒப்பந்தத்தை எழுதுவது மிகவும் சலிப்பாக இருக்கும். நாங்கள் சில சுவைகளைச் சேர்க்க விரும்பினோம், அது TVM க்கு எங்கள் சொந்த மொழியாக இருந்தது.

ஃபிஃப்ட் அசெம்பிளரைப் போலவே, எங்களின் புதிய மொழியும் உட்பொதிக்கப்பட்டுள்ளது, ஆனால் ஃபிஃப்ட்டுக்குப் பதிலாக ஹாஸ்கெல்லை ஹோஸ்டாகத் தேர்ந்தெடுத்தோம், அதன் மேம்பட்ட வகை அமைப்பை முழுமையாகப் பயன்படுத்த அனுமதிக்கிறது. ஸ்மார்ட் ஒப்பந்தங்களுடன் பணிபுரியும் போது, ​​​​ஒரு சிறிய பிழையின் விலை மிக அதிகமாக இருக்கும், நிலையான தட்டச்சு, எங்கள் கருத்துப்படி, ஒரு பெரிய நன்மை.

டிவிஎம் அசெம்பிளர் ஹாஸ்கெல்லில் உட்பொதிக்கப்பட்டதைப் போல் இருப்பதைக் காட்ட, அதில் ஒரு நிலையான வாலட்டைச் செயல்படுத்தினோம். கவனம் செலுத்த வேண்டிய சில விஷயங்கள் இங்கே:

• இந்த ஒப்பந்தம் ஒரு செயல்பாட்டைக் கொண்டுள்ளது, ஆனால் நீங்கள் விரும்பும் பலவற்றைப் பயன்படுத்தலாம். ஹோஸ்ட் மொழியில் (அதாவது ஹாஸ்கெல்) ஒரு புதிய செயல்பாட்டை நீங்கள் வரையறுக்கும் போது, ​​அது TVM இல் ஒரு தனி வழக்கமாக மாற வேண்டுமா அல்லது அழைப்புப் புள்ளியில் உள்ளிட வேண்டுமா என்பதைத் தேர்வுசெய்ய எங்கள் eDSL உங்களை அனுமதிக்கிறது.
• ஹாஸ்கெலைப் போலவே, செயல்பாடுகளும் தொகுக்கும் நேரத்தில் சரிபார்க்கப்படும் வகைகளைக் கொண்டுள்ளன. எங்கள் eDSL இல், ஒரு செயல்பாட்டின் உள்ளீட்டு வகை என்பது செயல்பாடு எதிர்பார்க்கும் அடுக்கின் வகையாகும், மேலும் முடிவு வகை என்பது அழைப்புக்குப் பிறகு உருவாக்கப்படும் அடுக்கின் வகையாகும்.
• குறியீடு சிறுகுறிப்புகளைக் கொண்டுள்ளது stacktype, அழைப்புப் புள்ளியில் எதிர்பார்க்கப்படும் அடுக்கு வகையை விவரிக்கிறது. அசல் வாலட் ஒப்பந்தத்தில் இவை வெறும் கருத்துகளாக மட்டுமே இருந்தன, ஆனால் எங்கள் eDSL இல் அவை உண்மையில் குறியீட்டின் ஒரு பகுதியாகும் மற்றும் தொகுக்கும் நேரத்தில் சரிபார்க்கப்படும். குறியீடு மாறினால் மற்றும் அடுக்கு வகை மாறினால், டெவலப்பர் சிக்கலைக் கண்டறிய உதவும் ஆவணங்கள் அல்லது அறிக்கைகளாக அவை செயல்படும். நிச்சயமாக, அத்தகைய சிறுகுறிப்புகள் இயக்க நேர செயல்திறனை பாதிக்காது, ஏனெனில் அவற்றிற்கு TVM குறியீடு உருவாக்கப்படவில்லை.
• இது இன்னும் இரண்டு வாரங்களில் எழுதப்பட்ட ஒரு முன்மாதிரி, எனவே திட்டத்தில் இன்னும் நிறைய வேலை செய்ய வேண்டியிருக்கிறது. எடுத்துக்காட்டாக, கீழே உள்ள குறியீட்டில் நீங்கள் பார்க்கும் வகுப்புகளின் அனைத்து நிகழ்வுகளும் தானாகவே உருவாக்கப்பட வேண்டும்.

எங்கள் eDSL இல் மல்டிசிக் வாலட்டின் செயலாக்கம் இப்படித்தான் இருக்கிறது:

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 மற்றும் பல கையொப்ப வாலட் ஒப்பந்தத்தின் முழு மூலக் குறியீட்டையும் இங்கே காணலாம் இந்த களஞ்சியம். இன்னமும் அதிகமாக விரிவாகச் சொன்னார் உள்ளமைக்கப்பட்ட மொழிகள் பற்றி, எங்கள் சக ஜார்ஜி அகபோவ்.

போட்டி மற்றும் டன் பற்றிய முடிவுகள்

மொத்தத்தில், எங்கள் பணி 380 மணிநேரம் எடுத்தது (ஆவணங்கள், கூட்டங்கள் மற்றும் உண்மையான மேம்பாடு ஆகியவற்றைப் பற்றிய அறிமுகம் உட்பட). போட்டித் திட்டத்தில் ஐந்து டெவலப்பர்கள் பங்கேற்றனர்: CTO, குழுத் தலைவர், பிளாக்செயின் இயங்குதள வல்லுநர்கள் மற்றும் ஹாஸ்கெல் மென்பொருள் உருவாக்குநர்கள்.

ஹேக்கத்தானின் உற்சாகம், நெருக்கமான குழுப்பணி மற்றும் புதிய தொழில்நுட்பங்களின் அம்சங்களில் விரைவாக மூழ்க வேண்டியதன் அவசியம் எப்போதும் உற்சாகமாக இருப்பதால், சிரமமின்றி போட்டியில் பங்கேற்பதற்கான ஆதாரங்களை நாங்கள் கண்டறிந்தோம். வரையறுக்கப்பட்ட வளங்களின் நிலைமைகளில் அதிகபட்ச முடிவுகளை அடைய பல தூக்கமில்லாத இரவுகள் விலைமதிப்பற்ற அனுபவம் மற்றும் சிறந்த நினைவுகளால் ஈடுசெய்யப்படுகின்றன. கூடுதலாக, இதுபோன்ற பணிகளில் பணிபுரிவது எப்போதும் நிறுவனத்தின் செயல்முறைகளுக்கு ஒரு நல்ல சோதனையாகும், ஏனெனில் உள் தொடர்பு நன்கு செயல்படாமல் உண்மையிலேயே ஒழுக்கமான முடிவுகளை அடைவது மிகவும் கடினம்.

பாடல் வரிகள் ஒருபுறம் இருக்க: டன் குழுவின் உழைப்பால் நாங்கள் ஈர்க்கப்பட்டோம். அவர்கள் ஒரு சிக்கலான, அழகான மற்றும் மிக முக்கியமாக, வேலை செய்யும் அமைப்பை உருவாக்க முடிந்தது. TON தன்னை ஒரு சிறந்த திறன் கொண்ட தளமாக நிரூபித்துள்ளது. இருப்பினும், இந்த சுற்றுச்சூழல் அமைப்பு வளர்ச்சியடைவதற்கு, பிளாக்செயின் திட்டங்களில் அதன் பயன்பாட்டின் அடிப்படையில் மற்றும் மேம்பாட்டுக் கருவிகளை மேம்படுத்துதல் ஆகியவற்றின் அடிப்படையில் இன்னும் நிறைய செய்ய வேண்டும். இந்த செயல்முறையின் ஒரு பகுதியாக நாங்கள் இப்போது பெருமைப்படுகிறோம்.

இந்தக் கட்டுரையைப் படித்த பிறகும் உங்களிடம் ஏதேனும் கேள்விகள் இருந்தால் அல்லது உங்கள் பிரச்சினைகளைத் தீர்க்க TON ஐ எவ்வாறு பயன்படுத்துவது என்பது குறித்த யோசனைகள் இருந்தால், எங்களுக்கு எழுதுங்கள் - எங்கள் அனுபவத்தைப் பகிர்ந்து கொள்வதில் மகிழ்ச்சி அடைவோம்.

ஆதாரம்: www.habr.com