---
title: "স্মার্ট কন্ট্রাক্ট আপগ্রেড করা"
description: "ইথেরিয়াম স্মার্ট কন্ট্রাক্টের আপগ্রেড প্যাটার্নগুলোর একটি ওভারভিউ"
lang: bn
---

ইথেরিয়ামের স্মার্ট কন্ট্রাক্টগুলো হলো স্বয়ংক্রিয়ভাবে নির্বাহিত প্রোগ্রাম যা ইথেরিয়াম ভার্চুয়াল মেশিনে (EVM) চলে। এই প্রোগ্রামগুলো ডিজাইনগতভাবেই অপরিবর্তনীয়, যা কন্ট্রাক্ট ডিপ্লয়মেন্টের পর এর বিজনেস লজিকে কোনো আপডেট করা প্রতিরোধ করে।

যদিও স্মার্ট কন্ট্রাক্টের আস্থাহীনতা, বিকেন্দ্রীকরণ এবং নিরাপত্তার জন্য অপরিবর্তনযোগ্যতা প্রয়োজনীয়, কিছু ক্ষেত্রে এটি একটি অসুবিধাও হতে পারে। উদাহরণস্বরূপ, অপরিবর্তনীয় কোড ডেভেলপারদের জন্য দুর্বল কন্ট্রাক্টগুলো ঠিক করা অসম্ভব করে তুলতে পারে।

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

## পূর্বশর্ত {#prerequisites}

আপনার [স্মার্ট কন্ট্রাক্ট](/developers/docs/smart-contracts/), [স্মার্ট কন্ট্রাক্টের গঠন](/developers/docs/smart-contracts/anatomy/) এবং [ইথেরিয়াম ভার্চুয়াল মেশিন (EVM)](/developers/docs/evm/) সম্পর্কে ভালো ধারণা থাকা উচিত। এই গাইডটি ধরে নেয় যে পাঠকদের স্মার্ট কন্ট্রাক্ট প্রোগ্রামিং সম্পর্কে ধারণা আছে।

## স্মার্ট কন্ট্রাক্ট আপগ্রেড কী? {#what-is-a-smart-contract-upgrade}

একটি স্মার্ট কন্ট্রাক্ট আপগ্রেড করার অর্থ হলো কন্ট্রাক্টের স্টেট বজায় রেখে এর বিজনেস লজিক পরিবর্তন করা। এটি স্পষ্ট করা গুরুত্বপূর্ণ যে আপগ্রেডযোগ্যতা এবং পরিবর্তনযোগ্যতা এক নয়, বিশেষ করে স্মার্ট কন্ট্রাক্টের প্রেক্ষাপটে।

আপনি এখনও ইথেরিয়াম নেটওয়ার্কের কোনো ঠিকানায় ডিপ্লয় করা প্রোগ্রাম পরিবর্তন করতে পারবেন না। তবে ব্যবহারকারীরা যখন কোনো স্মার্ট কন্ট্রাক্টের সাথে ইন্টারঅ্যাক্ট করে তখন যে কোডটি এক্সিকিউট হয়, আপনি তা পরিবর্তন করতে পারেন।

এটি নিচের পদ্ধতিগুলোর মাধ্যমে করা যেতে পারে:

1. একটি স্মার্ট কন্ট্রাক্টের একাধিক সংস্করণ তৈরি করা এবং পুরানো কন্ট্রাক্ট থেকে নতুন কন্ট্রাক্টের ইনস্ট্যান্সে স্টেট (অর্থাৎ, ডেটা) মাইগ্রেট করা।

2. বিজনেস লজিক এবং স্টেট সংরক্ষণ করার জন্য আলাদা কন্ট্রাক্ট তৈরি করা।

3. একটি অপরিবর্তনীয় প্রক্সি চুক্তি থেকে একটি পরিবর্তনযোগ্য লজিক কন্ট্রাক্টে ফাংশন কলগুলো প্রতিনিধি (delegate) করতে প্রক্সি প্যাটার্ন ব্যবহার করা।

4. একটি অপরিবর্তনীয় মূল কন্ট্রাক্ট তৈরি করা যা নির্দিষ্ট ফাংশনগুলো এক্সিকিউট করার জন্য নমনীয় স্যাটেলাইট কন্ট্রাক্টগুলোর সাথে ইন্টারফেস করে এবং সেগুলোর ওপর নির্ভর করে।

5. একটি প্রক্সি চুক্তি থেকে লজিক কন্ট্রাক্টগুলোতে ফাংশন কলগুলো প্রতিনিধি (delegate) করতে ডায়মন্ড প্যাটার্ন ব্যবহার করা।

### আপগ্রেড মেকানিজম #1: কন্ট্রাক্ট মাইগ্রেশন {#contract-migration}

কন্ট্রাক্ট মাইগ্রেশন ভার্সনিংয়ের ওপর ভিত্তি করে তৈরি—একই সফটওয়্যারের অনন্য স্টেটগুলো তৈরি এবং পরিচালনা করার ধারণা। কন্ট্রাক্ট মাইগ্রেশনের মধ্যে একটি বিদ্যমান স্মার্ট কন্ট্রাক্টের নতুন ইনস্ট্যান্স ডিপ্লয় করা এবং নতুন কন্ট্রাক্টে স্টোরেজ ও ব্যালেন্স স্থানান্তর করা অন্তর্ভুক্ত।

নতুন ডিপ্লয় করা কন্ট্রাক্টের স্টোরেজ খালি থাকবে, যা আপনাকে পুরানো কন্ট্রাক্ট থেকে ডেটা পুনরুদ্ধার করতে এবং নতুন ইমপ্লিমেন্টেশনে লিখতে দেয়। এরপর, নতুন ঠিকানা প্রতিফলিত করার জন্য পুরানো কন্ট্রাক্টের সাথে ইন্টারঅ্যাক্ট করা সমস্ত কন্ট্রাক্ট আপডেট করতে হবে।

কন্ট্রাক্ট মাইগ্রেশনের শেষ ধাপ হলো ব্যবহারকারীদের নতুন কন্ট্রাক্ট ব্যবহারে স্যুইচ করতে রাজি করানো। নতুন কন্ট্রাক্ট সংস্করণটি ব্যবহারকারীর ব্যালেন্স এবং ঠিকানাগুলো ধরে রাখবে, যা অপরিবর্তনযোগ্যতা বজায় রাখে। যদি এটি একটি টোকেন-ভিত্তিক কন্ট্রাক্ট হয়, তবে পুরানো কন্ট্রাক্ট বাতিল করতে এবং নতুন কন্ট্রাক্ট ব্যবহার করতে আপনাকে এক্সচেঞ্জগুলোর সাথেও যোগাযোগ করতে হবে।

ব্যবহারকারীর ইন্টারঅ্যাকশন ব্যাহত না করে স্মার্ট কন্ট্রাক্ট আপগ্রেড করার জন্য কন্ট্রাক্ট মাইগ্রেশন তুলনামূলকভাবে একটি সহজ এবং নিরাপদ ব্যবস্থা। তবে, ম্যানুয়ালি ব্যবহারকারীর স্টোরেজ এবং ব্যালেন্স নতুন কন্ট্রাক্টে মাইগ্রেট করা সময়সাপেক্ষ এবং এতে উচ্চ গ্যাস খরচ হতে পারে।

[কন্ট্রাক্ট মাইগ্রেশন সম্পর্কে আরও জানুন।](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)

### আপগ্রেড মেকানিজম #2: ডেটা সেপারেশন {#data-separation}

স্মার্ট কন্ট্রাক্ট আপগ্রেড করার আরেকটি পদ্ধতি হলো বিজনেস লজিক এবং ডেটা স্টোরেজকে আলাদা কন্ট্রাক্টে বিভক্ত করা। এর মানে হলো ব্যবহারকারীরা লজিক কন্ট্রাক্টের সাথে ইন্টারঅ্যাক্ট করে, যেখানে ডেটা স্টোরেজ কন্ট্রাক্টে সংরক্ষিত থাকে।

ব্যবহারকারীরা যখন অ্যাপ্লিকেশনের সাথে ইন্টারঅ্যাক্ট করে তখন এক্সিকিউট হওয়া কোডটি লজিক কন্ট্রাক্টে থাকে। এটি স্টোরেজ কন্ট্রাক্টের ঠিকানাও ধারণ করে এবং ডেটা পেতে ও সেট করতে এর সাথে ইন্টারঅ্যাক্ট করে।

এদিকে, স্টোরেজ কন্ট্রাক্ট স্মার্ট কন্ট্রাক্টের সাথে যুক্ত স্টেট ধারণ করে, যেমন ব্যবহারকারীর ব্যালেন্স এবং ঠিকানা। মনে রাখবেন যে স্টোরেজ কন্ট্রাক্টটি লজিক কন্ট্রাক্টের মালিকানাধীন এবং ডিপ্লয়মেন্টের সময় লজিক কন্ট্রাক্টের ঠিকানা দিয়ে কনফিগার করা হয়। এটি অননুমোদিত কন্ট্রাক্টগুলোকে স্টোরেজ কন্ট্রাক্ট কল করা বা এর ডেটা আপডেট করা থেকে বিরত রাখে।

ডিফল্টরূপে, স্টোরেজ কন্ট্রাক্ট অপরিবর্তনীয়—তবে এটি যে লজিক কন্ট্রাক্টকে নির্দেশ করে, আপনি সেটিকে একটি নতুন ইমপ্লিমেন্টেশন দিয়ে প্রতিস্থাপন করতে পারেন। এটি EVM-এ চলা কোড পরিবর্তন করবে, যেখানে স্টোরেজ এবং ব্যালেন্স অক্ষুণ্ণ থাকবে।

এই আপগ্রেড পদ্ধতি ব্যবহার করার জন্য স্টোরেজ কন্ট্রাক্টে লজিক কন্ট্রাক্টের ঠিকানা আপডেট করতে হবে। পূর্বে ব্যাখ্যা করা কারণগুলোর জন্য আপনাকে অবশ্যই স্টোরেজ কন্ট্রাক্টের ঠিকানা দিয়ে নতুন লজিক কন্ট্রাক্ট কনফিগার করতে হবে।

ডেটা সেপারেশন প্যাটার্নটি কন্ট্রাক্ট মাইগ্রেশনের তুলনায় বাস্তবায়ন করা তুলনামূলকভাবে সহজ। তবে, ক্ষতিকারক আপগ্রেড থেকে স্মার্ট কন্ট্রাক্টগুলোকে রক্ষা করতে আপনাকে একাধিক কন্ট্রাক্ট পরিচালনা করতে হবে এবং জটিল অথোরাইজেশন স্কিম বাস্তবায়ন করতে হবে।

### আপগ্রেড মেকানিজম #3: প্রক্সি প্যাটার্ন {#proxy-patterns}

প্রক্সি প্যাটার্নও বিজনেস লজিক এবং ডেটাকে আলাদা কন্ট্রাক্টে রাখতে ডেটা সেপারেশন ব্যবহার করে। তবে, প্রক্সি প্যাটার্নে, স্টোরেজ কন্ট্রাক্ট (যাকে প্রক্সি বলা হয়) কোড এক্সিকিউশনের সময় লজিক কন্ট্রাক্টকে কল করে। এটি ডেটা সেপারেশন পদ্ধতির বিপরীত, যেখানে লজিক কন্ট্রাক্ট স্টোরেজ কন্ট্রাক্টকে কল করে।

প্রক্সি প্যাটার্নে যা ঘটে তা হলো:

1. ব্যবহারকারীরা প্রক্সি চুক্তির সাথে ইন্টারঅ্যাক্ট করে, যা ডেটা সংরক্ষণ করে, কিন্তু বিজনেস লজিক ধারণ করে না।

2. প্রক্সি চুক্তি লজিক কন্ট্রাক্টের ঠিকানা সংরক্ষণ করে এবং `delegatecall` ফাংশন ব্যবহার করে সমস্ত ফাংশন কল লজিক কন্ট্রাক্টে (যা বিজনেস লজিক ধারণ করে) প্রতিনিধি (delegate) করে।

3. কলটি লজিক কন্ট্রাক্টে ফরোয়ার্ড করার পর, লজিক কন্ট্রাক্ট থেকে রিটার্ন করা ডেটা পুনরুদ্ধার করা হয় এবং ব্যবহারকারীকে ফেরত দেওয়া হয়।

প্রক্সি প্যাটার্ন ব্যবহার করার জন্য **delegatecall** ফাংশন সম্পর্কে বোঝা প্রয়োজন। মূলত, `delegatecall` হলো একটি অপকোড যা একটি কন্ট্রাক্টকে অন্য একটি কন্ট্রাক্ট কল করার অনুমতি দেয়, যেখানে প্রকৃত কোড এক্সিকিউশন কলিং কন্ট্রাক্টের প্রেক্ষাপটে ঘটে। প্রক্সি প্যাটার্নে `delegatecall` ব্যবহার করার একটি তাৎপর্য হলো যে প্রক্সি চুক্তি তার স্টোরেজে রিড এবং রাইট করে এবং লজিক কন্ট্রাক্টে সংরক্ষিত লজিক এমনভাবে এক্সিকিউট করে যেন এটি কোনো অভ্যন্তরীণ ফাংশন কল করছে।

[Solidity ডকুমেন্টেশন](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries) থেকে:

> _মেসেজ কলের একটি বিশেষ রূপ রয়েছে, যার নাম **delegatecall**, যা একটি মেসেজ কলের মতোই, তবে পার্থক্য হলো টার্গেট ঠিকানার কোডটি কলিং কন্ট্রাক্টের প্রেক্ষাপটে (অর্থাৎ, ঠিকানায়) এক্সিকিউট হয় এবং `msg.sender` ও `msg.value` তাদের মান পরিবর্তন করে না।_ _এর মানে হলো একটি কন্ট্রাক্ট রানটাইমে ভিন্ন একটি ঠিকানা থেকে ডায়নামিকভাবে কোড লোড করতে পারে। স্টোরেজ, বর্তমান ঠিকানা এবং ব্যালেন্স এখনও কলিং কন্ট্রাক্টকেই নির্দেশ করে, শুধুমাত্র কোডটি কল করা ঠিকানা থেকে নেওয়া হয়।_

প্রক্সি চুক্তি জানে যে যখনই কোনো ব্যবহারকারী একটি ফাংশন কল করে তখন `delegatecall` ইনভোক করতে হবে কারণ এতে একটি `fallback` ফাংশন বিল্ট-ইন থাকে। Solidity প্রোগ্রামিংয়ে [ফলব্যাক ফাংশন](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) তখন এক্সিকিউট হয় যখন কোনো ফাংশন কল কন্ট্রাক্টে নির্দিষ্ট করা ফাংশনগুলোর সাথে মেলে না।

প্রক্সি প্যাটার্ন কাজ করানোর জন্য একটি কাস্টম ফলব্যাক ফাংশন লিখতে হয় যা নির্দিষ্ট করে যে প্রক্সি চুক্তি কীভাবে সেই ফাংশন কলগুলো পরিচালনা করবে যা এটি সমর্থন করে না। এই ক্ষেত্রে প্রক্সির ফলব্যাক ফাংশনটি এমনভাবে প্রোগ্রাম করা হয় যাতে এটি একটি delegatecall শুরু করে এবং ব্যবহারকারীর রিকোয়েস্ট বর্তমান লজিক কন্ট্রাক্ট ইমপ্লিমেন্টেশনে রিরাউট করে।

প্রক্সি চুক্তি ডিফল্টরূপে অপরিবর্তনীয়, তবে আপডেট করা বিজনেস লজিক সহ নতুন লজিক কন্ট্রাক্ট তৈরি করা যেতে পারে। আপগ্রেড করা তখন প্রক্সি চুক্তিতে রেফারেন্স করা লজিক কন্ট্রাক্টের ঠিকানা পরিবর্তন করার বিষয় হয়ে দাঁড়ায়।

প্রক্সি চুক্তিকে একটি নতুন লজিক কন্ট্রাক্টে নির্দেশ করার মাধ্যমে, ব্যবহারকারীরা যখন প্রক্সি চুক্তির ফাংশন কল করে তখন এক্সিকিউট হওয়া কোডটি পরিবর্তিত হয়। এটি ব্যবহারকারীদের নতুন কন্ট্রাক্টের সাথে ইন্টারঅ্যাক্ট করতে না বলেই আমাদের একটি কন্ট্রাক্টের লজিক আপগ্রেড করার অনুমতি দেয়।

প্রক্সি প্যাটার্নগুলো স্মার্ট কন্ট্রাক্ট আপগ্রেড করার একটি জনপ্রিয় পদ্ধতি কারণ এগুলো কন্ট্রাক্ট মাইগ্রেশনের সাথে যুক্ত অসুবিধাগুলো দূর করে। তবে, প্রক্সি প্যাটার্নগুলো ব্যবহার করা আরও জটিল এবং ভুলভাবে ব্যবহার করা হলে [ফাংশন সিলেক্টর ক্ল্যাশ](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357)-এর মতো গুরুতর ত্রুটি দেখা দিতে পারে।

[প্রক্সি প্যাটার্ন সম্পর্কে আরও জানুন](https://blog.openzeppelin.com/proxy-patterns/)।

### আপগ্রেড মেকানিজম #4: কৌশল প্যাটার্ন {#strategy-pattern}

এই কৌশলটি [কৌশল প্যাটার্ন](https://en.wikipedia.org/wiki/Strategy_pattern) দ্বারা প্রভাবিত, যা নির্দিষ্ট বৈশিষ্ট্যগুলো বাস্তবায়নের জন্য অন্যান্য প্রোগ্রামের সাথে ইন্টারফেস করে এমন সফটওয়্যার প্রোগ্রাম তৈরি করতে উৎসাহিত করে। ইথেরিয়াম ডেভেলপমেন্টে কৌশল প্যাটার্ন প্রয়োগ করার অর্থ হলো এমন একটি স্মার্ট কন্ট্রাক্ট তৈরি করা যা অন্যান্য কন্ট্রাক্ট থেকে ফাংশন কল করে।

এই ক্ষেত্রে মূল কন্ট্রাক্টটি মূল বিজনেস লজিক ধারণ করে, তবে নির্দিষ্ট ফাংশনগুলো এক্সিকিউট করার জন্য অন্যান্য স্মার্ট কন্ট্রাক্টের ("স্যাটেলাইট কন্ট্রাক্ট") সাথে ইন্টারফেস করে। এই মূল কন্ট্রাক্টটি প্রতিটি স্যাটেলাইট কন্ট্রাক্টের ঠিকানাও সংরক্ষণ করে এবং স্যাটেলাইট কন্ট্রাক্টের বিভিন্ন ইমপ্লিমেন্টেশনের মধ্যে স্যুইচ করতে পারে।

আপনি একটি নতুন স্যাটেলাইট কন্ট্রাক্ট তৈরি করতে পারেন এবং নতুন ঠিকানা দিয়ে মূল কন্ট্রাক্ট কনফিগার করতে পারেন। এটি আপনাকে একটি স্মার্ট কন্ট্রাক্টের জন্য _কৌশল_ পরিবর্তন করার (অর্থাৎ, নতুন লজিক বাস্তবায়ন করার) অনুমতি দেয়।

যদিও এটি আগে আলোচনা করা প্রক্সি প্যাটার্নের মতো, কৌশল প্যাটার্নটি ভিন্ন কারণ মূল কন্ট্রাক্ট, যার সাথে ব্যবহারকারীরা ইন্টারঅ্যাক্ট করে, সেটি বিজনেস লজিক ধারণ করে। এই প্যাটার্নটি ব্যবহার করা আপনাকে মূল অবকাঠামোকে প্রভাবিত না করে একটি স্মার্ট কন্ট্রাক্টে সীমিত পরিবর্তন আনার সুযোগ দেয়।

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

### আপগ্রেড মেকানিজম #5: ডায়মন্ড প্যাটার্ন {#diamond-pattern}

ডায়মন্ড প্যাটার্নকে প্রক্সি প্যাটার্নের একটি উন্নতি হিসেবে বিবেচনা করা যেতে পারে। ডায়মন্ড প্যাটার্নগুলো প্রক্সি প্যাটার্ন থেকে আলাদা কারণ ডায়মন্ড প্রক্সি চুক্তি একাধিক লজিক কন্ট্রাক্টে ফাংশন কলগুলো প্রতিনিধি (delegate) করতে পারে।

ডায়মন্ড প্যাটার্নে লজিক কন্ট্রাক্টগুলো _ফ্যাসেট (facets)_ হিসেবে পরিচিত। ডায়মন্ড প্যাটার্ন কাজ করানোর জন্য, আপনাকে প্রক্সি চুক্তিতে একটি ম্যাপিং তৈরি করতে হবে যা [ফাংশন সিলেক্টরগুলোকে](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) বিভিন্ন ফ্যাসেট ঠিকানায় ম্যাপ করে।

যখন কোনো ব্যবহারকারী একটি ফাংশন কল করে, তখন প্রক্সি চুক্তি সেই ফাংশনটি এক্সিকিউট করার জন্য দায়ী ফ্যাসেটটি খুঁজে পেতে ম্যাপিং চেক করে। তারপর এটি `delegatecall` ইনভোক করে (ফলব্যাক ফাংশন ব্যবহার করে) এবং কলটিকে উপযুক্ত লজিক কন্ট্রাক্টে রিডাইরেক্ট করে।

প্রথাগত প্রক্সি আপগ্রেড প্যাটার্নগুলোর তুলনায় ডায়মন্ড আপগ্রেড প্যাটার্নের কিছু সুবিধা রয়েছে:

1. এটি আপনাকে সমস্ত কোড পরিবর্তন না করেই কন্ট্রাক্টের একটি ছোট অংশ আপগ্রেড করার অনুমতি দেয়। আপগ্রেডের জন্য প্রক্সি প্যাটার্ন ব্যবহার করার ক্ষেত্রে, এমনকি ছোটখাটো আপগ্রেডের জন্যও সম্পূর্ণ নতুন লজিক কন্ট্রাক্ট তৈরি করতে হয়।

2. সমস্ত স্মার্ট কন্ট্রাক্টের (প্রক্সি প্যাটার্নে ব্যবহৃত লজিক কন্ট্রাক্ট সহ) 24KB সাইজ লিমিট রয়েছে, যা একটি সীমাবদ্ধতা হতে পারে—বিশেষ করে আরও ফাংশন প্রয়োজন এমন জটিল কন্ট্রাক্টগুলোর জন্য। ডায়মন্ড প্যাটার্ন একাধিক লজিক কন্ট্রাক্ট জুড়ে ফাংশনগুলোকে বিভক্ত করে এই সমস্যার সমাধান করা সহজ করে তোলে।

3. প্রক্সি প্যাটার্নগুলো অ্যাক্সেস কন্ট্রোলের জন্য একটি ক্যাচ-অল (catch-all) পদ্ধতি গ্রহণ করে। আপগ্রেড ফাংশনগুলোতে অ্যাক্সেস থাকা কোনো সত্তা _সম্পূর্ণ_ কন্ট্রাক্ট পরিবর্তন করতে পারে। কিন্তু ডায়মন্ড প্যাটার্ন একটি মডুলার পারমিশন পদ্ধতি সক্ষম করে, যেখানে আপনি সত্তাগুলোকে একটি স্মার্ট কন্ট্রাক্টের মধ্যে নির্দিষ্ট ফাংশন আপগ্রেড করার মধ্যে সীমাবদ্ধ করতে পারেন।

[ডায়মন্ড প্যাটার্ন সম্পর্কে আরও জানুন](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w)।

## স্মার্ট কন্ট্রাক্ট আপগ্রেড করার সুবিধা এবং অসুবিধা {#pros-and-cons-of-upgrading-smart-contracts}

| সুবিধা                                                                                                           | অসুবিধা                                                                                                                                                    |
| -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| একটি স্মার্ট কন্ট্রাক্ট আপগ্রেড ডিপ্লয়মেন্ট-পরবর্তী পর্যায়ে আবিষ্কৃত দুর্বলতাগুলো ঠিক করা সহজ করে তুলতে পারে।    | স্মার্ট কন্ট্রাক্ট আপগ্রেড করা কোডের অপরিবর্তনযোগ্যতার ধারণাকে বাতিল করে, যার প্রভাব বিকেন্দ্রীকরণ এবং নিরাপত্তার ওপর পড়ে।                              |
| ডেভেলপাররা বিকেন্দ্রীকৃত অ্যাপ্লিকেশনগুলোতে নতুন বৈশিষ্ট্য যোগ করতে লজিক আপগ্রেড ব্যবহার করতে পারেন।                           | ব্যবহারকারীদের অবশ্যই ডেভেলপারদের ওপর আস্থা রাখতে হবে যে তারা ইচ্ছামতো স্মার্ট কন্ট্রাক্ট পরিবর্তন করবেন না।                                                                                  |
| স্মার্ট কন্ট্রাক্ট আপগ্রেডগুলো শেষ-ব্যবহারকারীদের জন্য নিরাপত্তা উন্নত করতে পারে কারণ বাগগুলো দ্রুত ঠিক করা যায়।                      | স্মার্ট কন্ট্রাক্টে আপগ্রেড কার্যকারিতা প্রোগ্রাম করা জটিলতার আরেকটি স্তর যোগ করে এবং গুরুতর ত্রুটির সম্ভাবনা বাড়ায়।                |
| কন্ট্রাক্ট আপগ্রেড ডেভেলপারদের বিভিন্ন বৈশিষ্ট্য নিয়ে পরীক্ষা করার এবং সময়ের সাথে সাথে ড্যাপ (dapp) উন্নত করার আরও সুযোগ দেয়। | স্মার্ট কন্ট্রাক্ট আপগ্রেড করার সুযোগ ডেভেলপারদের ডেভেলপমেন্ট পর্যায়ে যথাযথ পরিশ্রম না করেই দ্রুত প্রজেক্ট লঞ্চ করতে উৎসাহিত করতে পারে। |
|                                                                                                                | স্মার্ট কন্ট্রাক্টে অনিরাপদ অ্যাক্সেস কন্ট্রোল বা কেন্দ্রীকরণ ক্ষতিকারক অ্যাক্টরদের জন্য অননুমোদিত আপগ্রেড করা সহজ করে তুলতে পারে।                  |

## স্মার্ট কন্ট্রাক্ট আপগ্রেড করার জন্য বিবেচ্য বিষয়গুলো {#considerations-for-upgrading-smart-contracts}

1. অননুমোদিত স্মার্ট কন্ট্রাক্ট আপগ্রেড প্রতিরোধ করতে নিরাপদ অ্যাক্সেস কন্ট্রোল/অথোরাইজেশন মেকানিজম ব্যবহার করুন, বিশেষ করে যদি প্রক্সি প্যাটার্ন, কৌশল প্যাটার্ন বা ডেটা সেপারেশন ব্যবহার করেন। একটি উদাহরণ হলো আপগ্রেড ফাংশনে অ্যাক্সেস সীমাবদ্ধ করা, যাতে শুধুমাত্র কন্ট্রাক্টের মালিক এটি কল করতে পারে।

2. স্মার্ট কন্ট্রাক্ট আপগ্রেড করা একটি জটিল কাজ এবং দুর্বলতাগুলোর প্রবেশ রোধ করতে উচ্চ স্তরের পরিশ্রমের প্রয়োজন।

3. আপগ্রেড বাস্তবায়নের প্রক্রিয়াটিকে বিকেন্দ্রীকরণ করে আস্থার অনুমানগুলো হ্রাস করুন। সম্ভাব্য কৌশলগুলোর মধ্যে রয়েছে আপগ্রেডগুলো নিয়ন্ত্রণ করতে একটি [মাল্টি-সিগ ওয়ালেট কন্ট্রাক্ট](/developers/docs/smart-contracts/#multisig) ব্যবহার করা, অথবা আপগ্রেড অনুমোদনের জন্য [DAO-এর সদস্যদের](/dao/) ভোট দেওয়ার প্রয়োজন করা।

4. কন্ট্রাক্ট আপগ্রেড করার সাথে জড়িত খরচ সম্পর্কে সচেতন হোন। উদাহরণস্বরূপ, কন্ট্রাক্ট মাইগ্রেশনের সময় পুরানো কন্ট্রাক্ট থেকে নতুন কন্ট্রাক্টে স্টেট (যেমন, ব্যবহারকারীর ব্যালেন্স) কপি করার জন্য একাধিক ট্রানজ্যাকশনের প্রয়োজন হতে পারে, যার অর্থ হলো আরও বেশি গ্যাস ফি।

5. ব্যবহারকারীদের রক্ষা করতে **টাইমলক (timelocks)** বাস্তবায়নের কথা বিবেচনা করুন। টাইমলক বলতে কোনো সিস্টেমের পরিবর্তনে প্রয়োগ করা বিলম্বকে বোঝায়। আপগ্রেডগুলো নিয়ন্ত্রণ করতে টাইমলকগুলোকে একটি মাল্টি-সিগ গভর্ন্যান্স সিস্টেমের সাথে একত্রিত করা যেতে পারে: যদি কোনো প্রস্তাবিত পদক্ষেপ প্রয়োজনীয় অনুমোদনের থ্রেশহোল্ডে পৌঁছায়, তবে পূর্বনির্ধারিত বিলম্বের সময়কাল শেষ না হওয়া পর্যন্ত এটি এক্সিকিউট হয় না।

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

## রিসোর্স {#resources}

**ওপেনজেপেলিন আপগ্রেডস প্লাগিনস - _আপগ্রেডযোগ্য স্মার্ট কন্ট্রাক্ট ডিপ্লয় এবং সুরক্ষিত করার জন্য টুলের একটি স্যুট।_**

- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades)
- [ডকুমেন্টেশন](https://docs.openzeppelin.com/upgrades)

## টিউটোরিয়াল {#tutorials}

- প্যাট্রিক কলিন্স (Patrick Collins) এর [আপনার স্মার্ট কন্ট্রাক্ট আপগ্রেড করা | ইউটিউব টিউটোরিয়াল](https://www.youtube.com/watch?v=bdXJmWajZRY)
- অস্টিন গ্রিফিথ (Austin Griffith) এর [ইথেরিয়াম স্মার্ট কন্ট্রাক্ট মাইগ্রেশন টিউটোরিয়াল](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd)
- প্রাণেশ এ.এস (Pranesh A.S) এর [স্মার্ট কন্ট্রাক্ট আপগ্রেড করতে UUPS প্রক্সি প্যাটার্ন ব্যবহার করা](https://blog.logrocket.com/author/praneshas/)
- fangjun.eth এর [Web3 টিউটোরিয়াল: ওপেনজেপেলিন ব্যবহার করে আপগ্রেডযোগ্য স্মার্ট কন্ট্রাক্ট (প্রক্সি) লেখা](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916)

## আরও পড়ুন {#further-reading}

- সান্তিয়াগো প্যালাডিনো (Santiago Palladino) এর [স্মার্ট কন্ট্রাক্ট আপগ্রেডের স্টেট](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/)
- [Solidity স্মার্ট কন্ট্রাক্ট আপগ্রেড করার একাধিক উপায়](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - ক্রিপ্টো মার্কেট পুল ব্লগ
- [শিখুন: স্মার্ট কন্ট্রাক্ট আপগ্রেড করা](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - ওপেনজেপেলিন ডক্স
- নবীন সাহু (Naveen Sahu) এর [Solidity কন্ট্রাক্টের আপগ্রেডযোগ্যতার জন্য প্রক্সি প্যাটার্ন: ট্রান্সপারেন্ট বনাম UUPS প্রক্সি](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0)
- নিক মাজ (Nick Mudge) এর [ডায়মন্ড আপগ্রেড কীভাবে কাজ করে](https://dev.to/mudgen/how-diamond-upgrades-work-417j)