---
title: "திறன் ஒப்பந்தப் பாதுகாப்பு வழிகாட்டுதல்கள்"
description: "உங்கள் dapp-ஐ உருவாக்கும்போது கருத்தில் கொள்ள வேண்டிய பாதுகாப்பு வழிகாட்டுதல்களின் சரிபார்ப்புப் பட்டியல்"
author: "ட்ரெயில்ஆஃப்பிட்ஸ்"
tags: ["Solidity", "திறன் ஒப்பந்தங்கள்", "பாதுகாப்பு"]
skill: intermediate
breadcrumb: "பாதுகாப்பு வழிகாட்டுதல்கள்"
lang: ta
published: 2020-09-06
source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---

மேலும் பாதுகாப்பான திறன் ஒப்பந்தங்களை உருவாக்க இந்த உயர்மட்டப் பரிந்துரைகளைப் பின்பற்றவும்.

## வடிவமைப்பு வழிகாட்டுதல்கள் {#design-guidelines}

எந்தவொரு குறியீட்டையும் எழுதுவதற்கு முன்பாகவே, ஒப்பந்தத்தின் வடிவமைப்பு குறித்து முன்கூட்டியே விவாதிக்கப்பட வேண்டும்.

### ஆவணமாக்கல் மற்றும் விவரக்குறிப்புகள் {#documentation-and-specifications}

ஆவணமாக்கலை வெவ்வேறு நிலைகளில் எழுதலாம், மேலும் ஒப்பந்தங்களைச் செயல்படுத்தும்போது அதைப் புதுப்பிக்க வேண்டும்:

- **அமைப்பின் எளிய ஆங்கில விளக்கம்**, ஒப்பந்தங்கள் என்ன செய்கின்றன என்பதையும் குறியீட்டுத் தளத்தின் மீதான ஏதேனும் அனுமானங்களையும் விவரிக்கிறது.
- **திட்ட மற்றும் கட்டமைப்பு வரைபடங்கள்**, ஒப்பந்தப் பரிமாற்றங்கள் மற்றும் அமைப்பின் நிலை இயந்திரம் (state machine) உட்பட. இந்தத் திட்டங்களை உருவாக்க [ஸ்லித்தர் பிரிண்டர்கள்](https://github.com/crytic/slither/wiki/Printer-documentation) உதவலாம்.
- **முழுமையான குறியீட்டு ஆவணமாக்கல்**, Solidity-க்கு [NatSpec வடிவத்தைப்](https://docs.soliditylang.org/en/develop/natspec-format.html) பயன்படுத்தலாம்.

### சங்கிலிசார் மற்றும் புறச்சங்கிலி கணக்கீடு {#onchain-vs-offchain-computation}

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

### மேம்படுத்தும் திறன் {#upgradeability}

வெவ்வேறு மேம்படுத்தும் திறன் தீர்வுகள் குறித்து [எங்கள் வலைப்பதிவு இடுகையில்](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/) விவாதித்துள்ளோம். எந்தவொரு குறியீட்டையும் எழுதுவதற்கு முன்பு, மேம்படுத்தும் திறனை ஆதரிப்பதா இல்லையா என்பதைத் திட்டமிட்டு முடிவு செய்யுங்கள். இந்த முடிவு உங்கள் குறியீட்டை எவ்வாறு கட்டமைக்கிறீர்கள் என்பதைப் பாதிக்கும். பொதுவாக, நாங்கள் பரிந்துரைப்பது:

- **மேம்படுத்தும் திறனை விட [ஒப்பந்த இடம்பெயர்வுக்கு (contract migration)](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) முன்னுரிமை அளித்தல்.** இடம்பெயர்வு அமைப்புகள் மேம்படுத்தக்கூடிய அமைப்புகளின் பல நன்மைகளைக் கொண்டுள்ளன, ஆனால் அவற்றின் குறைபாடுகள் இல்லாமல்.
- **delegatecallproxy முறைக்கு பதிலாக தரவுப் பிரிப்பு (data separation) முறையைப் பயன்படுத்துதல்.** உங்கள் திட்டத்தில் தெளிவான சுருக்கப் பிரிப்பு (abstraction separation) இருந்தால், தரவுப் பிரிப்பைப் பயன்படுத்தி மேம்படுத்துவதற்குச் சில மாற்றங்கள் மட்டுமே தேவைப்படும். delegatecallproxy-க்கு EVM நிபுணத்துவம் தேவை, மேலும் இது அதிகப் பிழைகள் ஏற்பட வாய்ப்புள்ளது.
- **நிலைநிறுத்தத்திற்கு முன் இடம்பெயர்வு/மேம்படுத்தல் செயல்முறையை ஆவணப்படுத்தவும்.** எந்த வழிகாட்டுதலும் இல்லாமல் மன அழுத்தத்தின் கீழ் நீங்கள் செயல்பட வேண்டியிருந்தால், நீங்கள் தவறுகளைச் செய்வீர்கள். பின்பற்ற வேண்டிய செயல்முறையை முன்கூட்டியே எழுதுங்கள். அதில் பின்வருவன அடங்கியிருக்க வேண்டும்:
  - புதிய ஒப்பந்தங்களைத் தொடங்கும் அழைப்புகள்
  - திறவுகோல்கள் எங்கே சேமிக்கப்பட்டுள்ளன மற்றும் அவற்றை எவ்வாறு அணுகுவது
  - நிலைநிறுத்தத்தை எவ்வாறு சரிபார்ப்பது! நிலைநிறுத்தத்திற்குப் பிந்தைய ஸ்கிரிப்டை உருவாக்கிச் சோதிக்கவும்.

## செயலாக்க வழிகாட்டுதல்கள் {#implementation-guidelines}

**எளிமைக்காக முயலுங்கள்.** உங்கள் நோக்கத்திற்குப் பொருந்தக்கூடிய எளிமையான தீர்வை எப்போதும் பயன்படுத்தவும். உங்கள் குழுவில் உள்ள எந்தவொரு உறுப்பினரும் உங்கள் தீர்வைப் புரிந்துகொள்ள முடியும்.

### சார்பு உருவாக்கம் {#function-composition}

உங்கள் குறியீட்டுத் தளத்தின் கட்டமைப்பு உங்கள் குறியீட்டை மதிப்பாய்வு செய்வதை எளிதாக்க வேண்டும். அதன் சரியான தன்மையைப் பற்றிப் பகுத்தறியும் திறனைக் குறைக்கும் கட்டமைப்புத் தேர்வுகளைத் தவிர்க்கவும்.

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

### மரபுரிமை {#inheritance}

- **மரபுரிமையை நிர்வகிக்கக்கூடியதாக வைத்திருக்கவும்.** தர்க்கத்தைப் பிரிக்க மரபுரிமை பயன்படுத்தப்பட வேண்டும், இருப்பினும், உங்கள் திட்டம் மரபுரிமை மரத்தின் ஆழத்தையும் அகலத்தையும் குறைப்பதை நோக்கமாகக் கொண்டிருக்க வேண்டும்.
- **ஒப்பந்தங்களின் படிநிலையைச் சரிபார்க்க ஸ்லித்தரின் [மரபுரிமைப் பிரிண்டரைப்](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) பயன்படுத்தவும்.** படிநிலையின் அளவை மதிப்பாய்வு செய்ய மரபுரிமைப் பிரிண்டர் உங்களுக்கு உதவும்.

### நிகழ்வுகள் {#events}

- **அனைத்து முக்கியமான செயல்பாடுகளையும் பதிவு செய்யவும்.** மேம்பாட்டின் போது ஒப்பந்தத்தில் உள்ள பிழைகளைக் கண்டறியவும், நிலைநிறுத்தத்திற்குப் பிறகு அதைக் கண்காணிக்கவும் நிகழ்வுகள் உதவும்.

### அறியப்பட்ட ஆபத்துகளைத் தவிர்க்கவும் {#avoid-known-pitfalls}

- **மிகவும் பொதுவான பாதுகாப்புச் சிக்கல்களைப் பற்றி அறிந்திருங்கள்.** [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/) அல்லது [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/) போன்ற பொதுவான சிக்கல்களைப் பற்றி அறிய பல ஆன்லைன் ஆதாரங்கள் உள்ளன.
- **[Solidity ஆவணத்தில்](https://docs.soliditylang.org/en/latest/) உள்ள எச்சரிக்கைப் பிரிவுகளைப் பற்றி அறிந்திருங்கள்.** எச்சரிக்கைப் பிரிவுகள் மொழியின் வெளிப்படையற்ற நடத்தை பற்றி உங்களுக்குத் தெரிவிக்கும்.

### சார்புகள் {#dependencies}

- **நன்கு சோதிக்கப்பட்ட நூலகங்களைப் பயன்படுத்தவும்.** நன்கு சோதிக்கப்பட்ட நூலகங்களிலிருந்து குறியீட்டை இறக்குமதி செய்வது, நீங்கள் பிழையான குறியீட்டை எழுதுவதற்கான வாய்ப்பைக் குறைக்கும். நீங்கள் ஒரு ERC-20 ஒப்பந்தத்தை எழுத விரும்பினால், [ஓப்பன்செப்பெலின்](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20)-ஐப் பயன்படுத்தவும்.
- **சார்பு மேலாளரைப் பயன்படுத்தவும்; குறியீட்டை நகலெடுத்து ஒட்டுவதைத் தவிர்க்கவும்.** நீங்கள் ஒரு வெளிப்புற மூலத்தை நம்பியிருந்தால், அசல் மூலத்துடன் அதை நீங்கள் புதுப்பித்த நிலையில் வைத்திருக்க வேண்டும்.

### சோதனை மற்றும் சரிபார்ப்பு {#testing-and-verification}

- **முழுமையான அலகு-சோதனைகளை எழுதவும்.** உயர்தர மென்பொருளை உருவாக்க ஒரு விரிவான சோதனைத் தொகுப்பு முக்கியமானது.
- **[ஸ்லித்தர்](https://github.com/crytic/slither), [எக்கிட்னா](https://github.com/crytic/echidna) மற்றும் [மேண்டிகோர்](https://github.com/trailofbits/manticore) தனிப்பயன் சரிபார்ப்புகள் மற்றும் பண்புகளை எழுதவும்.** உங்கள் ஒப்பந்தம் பாதுகாப்பானது என்பதை உறுதிப்படுத்த தானியங்கி கருவிகள் உதவும். திறமையான சரிபார்ப்புகள் மற்றும் பண்புகளை எவ்வாறு எழுதுவது என்பதை அறிய இந்த வழிகாட்டியின் மீதமுள்ள பகுதியை மதிப்பாய்வு செய்யவும்.
- **[crytic.io](https://crytic.io/)-ஐப் பயன்படுத்தவும்.** Crytic, GitHub உடன் ஒருங்கிணைக்கிறது, தனிப்பட்ட ஸ்லித்தர் கண்டறிதல்களுக்கான அணுகலை வழங்குகிறது, மேலும் எக்கிட்னாவிலிருந்து தனிப்பயன் பண்புச் சரிபார்ப்புகளை இயக்குகிறது.

### Solidity {#solidity}

- **0.4 மற்றும் 0.6-ஐ விட Solidity 0.5-க்கு முன்னுரிமை அளிக்கவும்.** எங்கள் கருத்தில், Solidity 0.5 மிகவும் பாதுகாப்பானது மற்றும் 0.4-ஐ விடச் சிறந்த உள்ளமைக்கப்பட்ட நடைமுறைகளைக் கொண்டுள்ளது. Solidity 0.6 உற்பத்திக்கான பயன்பாட்டிற்கு மிகவும் நிலையற்றது என நிரூபிக்கப்பட்டுள்ளது, மேலும் அது முதிர்ச்சியடைய நேரம் தேவை.
- **தொகுக்க ஒரு நிலையான வெளியீட்டைப் பயன்படுத்தவும்; எச்சரிக்கைகளைச் சரிபார்க்க சமீபத்திய வெளியீட்டைப் பயன்படுத்தவும்.** சமீபத்திய கம்பைலர் பதிப்பில் உங்கள் குறியீட்டில் எந்தச் சிக்கல்களும் பதிவாகவில்லை என்பதைச் சரிபார்க்கவும். இருப்பினும், Solidity விரைவான வெளியீட்டுச் சுழற்சியைக் கொண்டுள்ளது மற்றும் கம்பைலர் பிழைகளின் வரலாற்றைக் கொண்டுள்ளது, எனவே நிலைநிறுத்தத்திற்குச் சமீபத்திய பதிப்பை நாங்கள் பரிந்துரைக்கவில்லை (ஸ்லித்தரின் [solc பதிப்புப் பரிந்துரையைப்](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) பார்க்கவும்).
- **உள்ளமைக்கப்பட்ட அசெம்பிளியைப் பயன்படுத்த வேண்டாம்.** அசெம்பிளிக்கு EVM நிபுணத்துவம் தேவை. நீங்கள் மஞ்சள் அறிக்கையில் _முழுமையான தேர்ச்சி_ பெறவில்லை என்றால் EVM குறியீட்டை எழுத வேண்டாம்.

## நிலைநிறுத்த வழிகாட்டுதல்கள் {#deployment-guidelines}

ஒப்பந்தம் உருவாக்கப்பட்டு நிலைநிறுத்தப்பட்டவுடன்:

- **உங்கள் ஒப்பந்தங்களைக் கண்காணிக்கவும்.** பதிவுகளைப் பார்க்கவும், மேலும் ஒப்பந்தம் அல்லது பணப்பை சமரசம் செய்யப்பட்டால் செயல்படத் தயாராக இருங்கள்.
- **உங்கள் தொடர்புத் தகவலை [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts)-இல் சேர்க்கவும்.** பாதுகாப்புப் பிழை கண்டறியப்பட்டால் மூன்றாம் தரப்பினர் உங்களைத் தொடர்புகொள்ள இந்தப் பட்டியல் உதவுகிறது.
- **சிறப்புரிமை பெற்ற பயனர்களின் பணப்பைகளைப் பாதுகாக்கவும்.** வன்பொருள் பணப்பைகளில் திறவுகோல்களைச் சேமித்தால், எங்கள் [சிறந்த நடைமுறைகளைப்](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) பின்பற்றவும்.
- **நிகழ்வுக்கான எதிர்வினைத் திட்டத்தை வைத்திருக்கவும்.** உங்கள் திறன் ஒப்பந்தங்கள் சமரசம் செய்யப்படலாம் என்பதைக் கருத்தில் கொள்ளுங்கள். உங்கள் ஒப்பந்தங்களில் பிழைகள் இல்லாவிட்டாலும், தாக்குபவர் ஒப்பந்த உரிமையாளரின் திறவுகோல்களைக் கட்டுப்படுத்தலாம்.