মূল কন্টেন্টে যান

স্মার্ট কন্ট্রাক্ট সিকিউরিটি গাইডলাইন

solidity
স্মার্ট কন্ট্রাক্ট
সিকিউরিটি
মধ্যবর্তী
Trailofbits
6 সেপ্টেম্বর, 2020
5 মিনিট পড়ার সময়

আরও সুরক্ষিত স্মার্ট কন্ট্রাক্ট তৈরি করতে এই উচ্চ-স্তরের সুপারিশগুলো অনুসরণ করুন।

ডিজাইনের গাইডলাইন

কোডের কোনো লাইন লেখার আগে, কন্ট্রাক্টের ডিজাইন নিয়ে আগে থেকেই আলোচনা করা উচিত।

ডকুমেন্টেশন এবং স্পেসিফিকেশন

ডকুমেন্টেশন বিভিন্ন স্তরে লেখা যেতে পারে এবং কন্ট্রাক্টগুলো বাস্তবায়নের সময় এটি আপডেট করা উচিত:

  • সিস্টেমের একটি সাধারণ ইংরেজি বিবরণ, যেখানে কন্ট্রাক্টগুলো কী করে এবং কোডবেসের উপর কোনো অনুমান থাকলে তা বর্ণনা করা হয়।
  • স্কিমা এবং আর্কিটেকচারাল ডায়াগ্রাম, যার মধ্যে কন্ট্রাক্টের ইন্টারঅ্যাকশন এবং সিস্টেমের স্টেট মেশিন অন্তর্ভুক্ত থাকে। স্লিদার প্রিন্টার (নতুন ট্যাবে খোলে) এই স্কিমাগুলো তৈরি করতে সাহায্য করতে পারে।
  • পুঙ্খানুপুঙ্খ কোড ডকুমেন্টেশন, Solidity-এর জন্য NatSpec ফরম্যাট (নতুন ট্যাবে খোলে) ব্যবহার করা যেতে পারে।

অনচেইন বনাম অফচেইন কম্পিউটেশন

  • যতটা সম্ভব কোড অফচেইন রাখুন। অনচেইন লেয়ারটি ছোট রাখুন। অফচেইন কোড দিয়ে ডেটা এমনভাবে প্রি-প্রসেস করুন যাতে অনচেইনে ভেরিফিকেশন করা সহজ হয়। আপনার কি একটি সাজানো তালিকা দরকার? তালিকাটি অফচেইনে সাজান, তারপর শুধুমাত্র অনচেইনে এর ক্রমটি পরীক্ষা করুন।

আপগ্রেডযোগ্যতা

আমরা আমাদের ব্লগপোস্টে (নতুন ট্যাবে খোলে) বিভিন্ন আপগ্রেডযোগ্যতার সমাধান নিয়ে আলোচনা করেছি। কোনো কোড লেখার আগে আপগ্রেডযোগ্যতা সমর্থন করবেন কি না, সে বিষয়ে একটি সুচিন্তিত সিদ্ধান্ত নিন। এই সিদ্ধান্তটি আপনার কোডের কাঠামোকে প্রভাবিত করবে। সাধারণভাবে, আমরা সুপারিশ করি:

  • আপগ্রেডযোগ্যতার চেয়ে কন্ট্রাক্ট মাইগ্রেশনকে (নতুন ট্যাবে খোলে) অগ্রাধিকার দিন। মাইগ্রেশন সিস্টেমগুলোতে আপগ্রেডযোগ্য সিস্টেমের মতো অনেক সুবিধাই থাকে, তবে সেগুলোর ত্রুটিগুলো থাকে না।
  • delegatecallproxy প্যাটার্নের চেয়ে ডেটা সেপারেশন প্যাটার্ন ব্যবহার করুন। যদি আপনার প্রজেক্টে একটি স্পষ্ট অ্যাবস্ট্রাকশন সেপারেশন থাকে, তবে ডেটা সেপারেশন ব্যবহার করে আপগ্রেড করার জন্য শুধুমাত্র কয়েকটি সমন্বয়ের প্রয়োজন হবে। delegatecallproxy-এর জন্য EVM-এ দক্ষতা প্রয়োজন এবং এটি অত্যন্ত ত্রুটিপ্রবণ।
  • ডিপ্লয়মেন্টের আগে মাইগ্রেশন/আপগ্রেড পদ্ধতিটি ডকুমেন্ট করুন। যদি আপনাকে কোনো গাইডলাইন ছাড়াই চাপের মুখে কাজ করতে হয়, তবে আপনি ভুল করবেন। অনুসরণ করার পদ্ধতিটি আগে থেকেই লিখে রাখুন। এর মধ্যে অন্তর্ভুক্ত থাকা উচিত:
    • নতুন কন্ট্রাক্টগুলো চালু করার কলগুলো
    • কীগুলো (keys) কোথায় সংরক্ষিত আছে এবং কীভাবে সেগুলোতে অ্যাক্সেস করতে হবে
    • ডিপ্লয়মেন্ট কীভাবে চেক করবেন! একটি পোস্ট-ডিপ্লয়মেন্ট স্ক্রিপ্ট তৈরি করুন এবং পরীক্ষা করুন।

ইমপ্লিমেন্টেশন গাইডলাইন

সরলতার জন্য চেষ্টা করুন। সর্বদা আপনার উদ্দেশ্যের সাথে মানানসই সবচেয়ে সহজ সমাধানটি ব্যবহার করুন। আপনার টিমের যেকোনো সদস্যের আপনার সমাধানটি বুঝতে পারা উচিত।

ফাংশন কম্পোজিশন

আপনার কোডবেসের আর্কিটেকচার এমন হওয়া উচিত যাতে আপনার কোডটি রিভিউ করা সহজ হয়। এমন আর্কিটেকচারাল পছন্দগুলো এড়িয়ে চলুন যা এর সঠিকতা সম্পর্কে যুক্তি দেওয়ার ক্ষমতা হ্রাস করে।

  • আপনার সিস্টেমের লজিককে বিভক্ত করুন, হয় একাধিক কন্ট্রাক্টের মাধ্যমে অথবা একই ধরনের ফাংশনগুলোকে একসাথে গ্রুপ করে (উদাহরণস্বরূপ, অথেনটিকেশন, পাটিগণিত, ...)।
  • একটি স্পষ্ট উদ্দেশ্য নিয়ে ছোট ছোট ফাংশন লিখুন। এটি সহজে রিভিউ করতে সহায়তা করবে এবং পৃথক উপাদানগুলোর টেস্টিং করার সুযোগ দেবে।

ইনহেরিটেন্স

  • ইনহেরিটেন্স পরিচালনাযোগ্য রাখুন। লজিককে ভাগ করার জন্য ইনহেরিটেন্স ব্যবহার করা উচিত, তবে আপনার প্রজেক্টের লক্ষ্য হওয়া উচিত ইনহেরিটেন্স ট্রির গভীরতা এবং প্রস্থ কমানো।
  • কন্ট্রাক্টগুলোর হায়ারার্কি চেক করতে স্লিদার-এর ইনহেরিটেন্স প্রিন্টার (নতুন ট্যাবে খোলে) ব্যবহার করুন। ইনহেরিটেন্স প্রিন্টার আপনাকে হায়ারার্কির আকার রিভিউ করতে সাহায্য করবে।

ইভেন্ট

  • সব গুরুত্বপূর্ণ অপারেশন লগ করুন। ইভেন্টগুলো ডেভেলপমেন্টের সময় কন্ট্রাক্ট ডিবাগ করতে এবং ডিপ্লয়মেন্টের পরে এটি মনিটর করতে সাহায্য করবে।

পরিচিত ফাঁদগুলো এড়িয়ে চলুন

ডিপেন্ডেন্সি

  • সুপরীক্ষিত লাইব্রেরি ব্যবহার করুন। সুপরীক্ষিত লাইব্রেরি থেকে কোড ইমপোর্ট করলে আপনার বাগযুক্ত কোড লেখার সম্ভাবনা কমে যাবে। আপনি যদি একটি ERC-20 কন্ট্রাক্ট লিখতে চান, তবে ওপেনজেপেলিন (নতুন ট্যাবে খোলে) ব্যবহার করুন।
  • একটি ডিপেন্ডেন্সি ম্যানেজার ব্যবহার করুন; কোড কপি-পেস্ট করা এড়িয়ে চলুন। আপনি যদি কোনো বাহ্যিক সোর্সের ওপর নির্ভর করেন, তবে আপনাকে অবশ্যই মূল সোর্সের সাথে এটি আপ-টু-ডেট রাখতে হবে।

টেস্টিং এবং ভেরিফিকেশন

  • পুঙ্খানুপুঙ্খ ইউনিট-টেস্ট লিখুন। উচ্চ-মানের সফটওয়্যার তৈরি করার জন্য একটি বিস্তৃত টেস্ট স্যুট অত্যন্ত গুরুত্বপূর্ণ।
  • স্লিদার (নতুন ট্যাবে খোলে), একিডনা (নতুন ট্যাবে খোলে) এবং ম্যান্টিকোর (নতুন ট্যাবে খোলে) কাস্টম চেক এবং প্রপার্টিগুলো লিখুন। স্বয়ংক্রিয় টুলগুলো আপনার কন্ট্রাক্ট সুরক্ষিত কিনা তা নিশ্চিত করতে সাহায্য করবে। কীভাবে কার্যকর চেক এবং প্রপার্টি লিখতে হয় তা জানতে এই গাইডের বাকি অংশটি রিভিউ করুন।
  • crytic.io (নতুন ট্যাবে খোলে) ব্যবহার করুন। Crytic GitHub-এর সাথে একীভূত হয়, প্রাইভেট স্লিদার ডিটেক্টরগুলোতে অ্যাক্সেস প্রদান করে এবং একিডনা থেকে কাস্টম প্রপার্টি চেক রান করে।

Solidity

  • 0.4 এবং 0.6 এর চেয়ে Solidity 0.5 কে অগ্রাধিকার দিন। আমাদের মতে, Solidity 0.5 আরও সুরক্ষিত এবং এতে 0.4 এর চেয়ে ভালো বিল্ট-ইন প্র্যাকটিস রয়েছে। Solidity 0.6 প্রোডাকশনের জন্য খুব অস্থিতিশীল প্রমাণিত হয়েছে এবং এটি পরিপক্ক হওয়ার জন্য সময়ের প্রয়োজন।
  • কম্পাইল করার জন্য একটি স্থিতিশীল রিলিজ ব্যবহার করুন; সতর্কীকরণ চেক করার জন্য সর্বশেষ রিলিজ ব্যবহার করুন। চেক করুন যে সর্বশেষ কম্পাইলার সংস্করণের সাথে আপনার কোডে কোনো রিপোর্ট করা সমস্যা নেই। তবে, Solidity-এর একটি দ্রুত রিলিজ সাইকেল রয়েছে এবং কম্পাইলার বাগের ইতিহাস রয়েছে, তাই আমরা ডিপ্লয়মেন্টের জন্য সর্বশেষ সংস্করণের সুপারিশ করি না (স্লিদার-এর solc সংস্করণ সুপারিশ (নতুন ট্যাবে খোলে) দেখুন)।
  • ইনলাইন অ্যাসেম্বলি ব্যবহার করবেন না। অ্যাসেম্বলির জন্য EVM-এ দক্ষতা প্রয়োজন। আপনি যদি ইয়েলো পেপার আয়ত্ত না করে থাকেন তবে EVM কোড লিখবেন না।

ডিপ্লয়মেন্ট গাইডলাইন

কন্ট্রাক্টটি ডেভেলপ এবং ডিপ্লয়মেন্ট হওয়ার পরে:

  • আপনার কন্ট্রাক্টগুলো মনিটর করুন। লগগুলো লক্ষ্য করুন এবং কন্ট্রাক্ট বা ওয়ালেট আপস (compromise) হওয়ার ক্ষেত্রে প্রতিক্রিয়া জানাতে প্রস্তুত থাকুন।
  • blockchain-security-contacts (নতুন ট্যাবে খোলে)-এ আপনার যোগাযোগের তথ্য যোগ করুন। কোনো সিকিউরিটি ত্রুটি আবিষ্কৃত হলে তৃতীয় পক্ষকে আপনার সাথে যোগাযোগ করতে এই তালিকাটি সাহায্য করে।
  • সুবিধাপ্রাপ্ত ব্যবহারকারীদের ওয়ালেটগুলো সুরক্ষিত করুন। আপনি যদি হার্ডওয়্যার ওয়ালেটে কী (keys) সংরক্ষণ করেন তবে আমাদের সেরা প্র্যাকটিসগুলো (নতুন ট্যাবে খোলে) অনুসরণ করুন।
  • ঘটনার প্রতিক্রিয়া জানানোর একটি পরিকল্পনা রাখুন। বিবেচনা করুন যে আপনার স্মার্ট কন্ট্রাক্টগুলো আপস (compromise) হতে পারে। এমনকি আপনার কন্ট্রাক্টগুলো বাগ-মুক্ত হলেও, একজন আক্রমণকারী কন্ট্রাক্ট মালিকের কীগুলোর (keys) নিয়ন্ত্রণ নিতে পারে।