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

পেজ সর্বশেষ আপডেট করা হয়েছে: 23 ফেব্রুয়ারী, 2026

Fusaka

Ethereum-এর বহুল প্রত্যাশিত Fusaka আপগ্রেড 3 ডিসেম্বর, 2025-এ লাইভ হয়েছে

Fusaka নেটওয়ার্ক আপগ্রেডটি Pectra-এর পরে এসেছে এবং এটি আরও নতুন ফিচার নিয়ে এসেছে এবং প্রতিটি Ethereum ব্যবহারকারী ও ডেভেলপারের অভিজ্ঞতা উন্নত করেছে। এর নামটি এক্সিকিউশন লেয়ার আপগ্রেড Osaka এবং Fulu তারার নামানুসারে কনসেন্সাস লেয়ার সংস্করণের সমন্বয়ে গঠিত। Ethereum-এর উভয় অংশই এমন একটি আপগ্রেড পেয়েছে যা Ethereum স্কেলিং, নিরাপত্তা এবং ব্যবহারকারীর অভিজ্ঞতাকে ভবিষ্যতের দিকে এগিয়ে নিয়ে যায়।

Fusaka-তে উন্নতিসমূহ

স্কেল ব্লবস

PeerDAS

এটি Fusaka ফর্ক-এর হেডলাইনার, এই আপগ্রেডে যুক্ত হওয়া প্রধান ফিচার। লেয়ার 2-গুলো বর্তমানে তাদের ডাটা Ethereum-এ ব্লব (blobs) আকারে পোস্ট করে, যা বিশেষভাবে লেয়ার 2-এর জন্য তৈরি করা ক্ষণস্থায়ী ডাটা টাইপ। Fusaka-এর আগে, ডাটার অস্তিত্ব নিশ্চিত করতে প্রতিটি ফুল নোড-কে প্রতিটি ব্লব সংরক্ষণ করতে হতো। ব্লব থ্রুপুট বাড়ার সাথে সাথে, এই সমস্ত ডাটা ডাউনলোড করা অত্যন্ত রিসোর্স-নিবিড় হয়ে ওঠে।

ডাটা এভেইলএবিলিটি স্যাম্পলিং (opens in a new tab)-এর মাধ্যমে, সমস্ত ব্লব ডাটা সংরক্ষণ করার পরিবর্তে, প্রতিটি নোড ব্লব ডাটার একটি সাবসেটের জন্য দায়ী থাকবে। ব্লবগুলো নেটওয়ার্ক-এর নোডগুলোর মধ্যে সমানভাবে এলোমেলোভাবে বিতরণ করা হয়, যেখানে প্রতিটি ফুল নোড ডাটার মাত্র 1/8 অংশ ধারণ করে, যার ফলে তাত্ত্বিকভাবে 8 গুণ পর্যন্ত স্কেল করা সম্ভব হয়। ডাটার প্রাপ্যতা নিশ্চিত করতে, ডাটার যেকোনো অংশ সম্পূর্ণ ডাটার বিদ্যমান 50% থেকে পুনর্গঠন করা যেতে পারে এমন পদ্ধতির মাধ্যমে যা ভুল বা হারিয়ে যাওয়া ডাটার সম্ভাবনাকে ক্রিপ্টোগ্রাফিক-ভাবে নগণ্য স্তরে নামিয়ে আনে (~1020-এর মধ্যে 1 থেকে 1024-এর মধ্যে 1)।

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

PeerDAS সম্পর্কে আরও জানুন

রিসোর্সসমূহ:

Blob-Parameter-Only ফর্কসমূহ

লেয়ার 2-গুলো Ethereum-কে স্কেল করে - তাদের নেটওয়ার্ক বাড়ার সাথে সাথে, তাদের Ethereum-এ আরও বেশি ডাটা পোস্ট করতে হয়। এর মানে হলো সময়ের সাথে সাথে Ethereum-কে তাদের জন্য উপলব্ধ ব্লবের সংখ্যা বাড়াতে হবে। যদিও PeerDAS ব্লব ডাটা স্কেলিং সক্ষম করে, এটি ধীরে ধীরে এবং নিরাপদে করা প্রয়োজন।

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

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

গ্যাস লিমিট-এর মতো অন্যান্য কনফিগারেশনের মতোই ক্লায়েন্ট-দের দ্বারা ব্লব প্যারামিটার অনলি ফর্কগুলো সেট করা যেতে পারে। বড় Ethereum আপগ্রেডগুলোর মধ্যে, ক্লায়েন্ট-রা target এবং max ব্লবগুলো যেমন 9 এবং 12-এ বাড়াতে সম্মত হতে পারে এবং তারপর নোড অপারেটররা সেই ছোট ফর্ক-এ অংশ নিতে আপডেট করবে। এই ব্লব প্যারামিটার অনলি ফর্কগুলো যেকোনো সময় কনফিগার করা যেতে পারে।

Dencun আপগ্রেডে যখন প্রথম নেটওয়ার্ক-এ ব্লব যুক্ত করা হয়েছিল, তখন টার্গেট ছিল 3। Pectra-তে এটি বাড়িয়ে 6 করা হয়েছিল এবং Fusaka-এর পরে, এখন এই বড় নেটওয়ার্ক আপগ্রেডগুলো থেকে স্বাধীনভাবে একটি টেকসই হারে এটি বাড়ানো যেতে পারে।

প্রতি ব্লকে গড় ব্লব সংখ্যা এবং আপগ্রেডের সাথে টার্গেট বৃদ্ধির চার্ট

গ্রাফ সোর্স: Ethereum Blobs - @hildobby, Dune Analytics (opens in a new tab)

রিসোর্সসমূহ: EIP-7892 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

এক্সিকিউশন খরচের দ্বারা সীমাবদ্ধ ব্লব বেস ফি

লেয়ার 2-গুলো ডাটা পোস্ট করার সময় দুটি বিল প্রদান করে: ব্লব ফি এবং সেই ব্লবগুলো যাচাই করার জন্য প্রয়োজনীয় এক্সিকিউশন গ্যাস। যদি এক্সিকিউশন গ্যাস প্রাধান্য পায়, তবে ব্লব ফি নিলাম 1 wei-তে নেমে যেতে পারে এবং প্রাইস সিগন্যাল হওয়া বন্ধ করতে পারে।

EIP-7918 প্রতিটি ব্লবের নিচে একটি আনুপাতিক রিজার্ভ প্রাইস পিন করে। যখন রিজার্ভ নামমাত্র ব্লব বেস ফি-এর চেয়ে বেশি হয়, তখন ফি অ্যাডজাস্টমেন্ট এ্যালগরিদম ব্লক-টিকে টার্গেটের চেয়ে বেশি হিসেবে বিবেচনা করে এবং ফি কমানো বন্ধ করে এবং এটিকে স্বাভাবিকভাবে বাড়তে দেয়। এর ফলে:

  • ব্লব ফি মার্কেট সর্বদা কনজেশনের প্রতি প্রতিক্রিয়া দেখায়
  • লেয়ার 2-গুলো নোড-গুলোর উপর চাপিয়ে দেওয়া কম্পিউটের অন্তত একটি অর্থপূর্ণ অংশ প্রদান করে
  • EL-এ বেস ফি স্পাইকগুলো আর ব্লব ফি-কে 1 wei-তে আটকে রাখতে পারে না

রিসোর্সসমূহ:

স্কেল L1

হিস্ট্রি এক্সপায়ারি এবং সহজ রিসিপ্ট

জুলাই 2025-এ, Ethereum এক্সিকিউশন ক্লায়েন্ট-গুলো আংশিক হিস্ট্রি এক্সপায়ারি সমর্থন করতে শুরু করে (opens in a new tab)। Ethereum-এর বৃদ্ধি অব্যাহত থাকায় নোড অপারেটরদের প্রয়োজনীয় ডিস্ক স্পেস কমানোর জন্য এটি the Merge (opens in a new tab)-এর চেয়ে পুরানো হিস্ট্রি বাদ দেয়।

এই EIP-টি "কোর EIPs" থেকে আলাদা একটি সেকশনে রয়েছে কারণ ফর্ক আসলে কোনো পরিবর্তন বাস্তবায়ন করে না - এটি একটি নোটিশ যে ক্লায়েন্ট টিমগুলোকে অবশ্যই Fusaka আপগ্রেডের মাধ্যমে হিস্ট্রি এক্সপায়ারি সমর্থন করতে হবে। বাস্তবে, ক্লায়েন্ট-রা যেকোনো সময় এটি বাস্তবায়ন করতে পারে তবে এটিকে আপগ্রেডে যুক্ত করা তাদের টু-ডু লিস্টে স্পষ্টভাবে রাখে এবং এই ফিচারের সাথে একত্রে Fusaka পরিবর্তনগুলো পরীক্ষা করতে তাদের সক্ষম করে।

রিসোর্সসমূহ: EIP-7642 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

MODEXP-এর জন্য আপার বাউন্ড সেট করা

এখন পর্যন্ত, MODEXP প্রিকম্পাইল কার্যত যেকোনো আকারের সংখ্যা গ্রহণ করত। এটি পরীক্ষা করা কঠিন, অপব্যবহার করা সহজ এবং ক্লায়েন্ট স্থিতিশীলতার জন্য ঝুঁকিপূর্ণ করে তুলেছিল। EIP-7823 একটি স্পষ্ট সীমা নির্ধারণ করে: প্রতিটি ইনপুট সংখ্যা সর্বাধিক 8192 বিট (1024 বাইট) দীর্ঘ হতে পারে। এর চেয়ে বড় যেকোনো কিছু প্রত্যাখ্যান করা হয়, লেনদেন-এর গ্যাস পুড়িয়ে ফেলা হয় এবং কোনো স্টেট পরিবর্তন ঘটে না। এটি গ্যাস লিমিট পরিকল্পনা এবং নিরাপত্তা পর্যালোচনাকে জটিল করে তোলা চরম ক্ষেত্রগুলো দূর করার পাশাপাশি বাস্তব-বিশ্বের প্রয়োজনীয়তাগুলো খুব স্বাচ্ছন্দ্যে কভার করে। এই পরিবর্তনটি ব্যবহারকারী বা ডেভেলপারের অভিজ্ঞতাকে প্রভাবিত না করেই আরও নিরাপত্তা এবং DoS সুরক্ষা প্রদান করে।

রিসোর্সসমূহ: EIP-7823 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

ট্রানজেকশন গ্যাস লিমিট ক্যাপ

EIP-7825 (opens in a new tab) প্রতি লেনদেন-এ 16,777,216 (2^24) গ্যাস-এর একটি ক্যাপ যোগ করে। আমরা ব্লক গ্যাস লিমিট বাড়ানোর সাথে সাথে যেকোনো একক লেনদেন-এর সবচেয়ে খারাপ পরিস্থিতির খরচ সীমাবদ্ধ করার মাধ্যমে এটি প্রোঅ্যাকটিভ DoS হার্ডেনিং। এটি গ্যাস লিমিট বাড়ানোর মাধ্যমে স্কেলিং মোকাবেলা করার অনুমতি দেওয়ার জন্য ভ্যালিডেশন এবং প্রোপাগেশন মডেল করা সহজ করে তোলে।

ঠিক 2^24 গ্যাস কেন? এটি আজকের গ্যাস লিমিট-এর চেয়ে স্বাচ্ছন্দ্যে ছোট, বাস্তব কন্ট্রাক্ট ডিপ্লয়মেন্ট এবং ভারী প্রিকম্পাইলের জন্য যথেষ্ট বড় এবং 2-এর পাওয়ার এটিকে ক্লায়েন্ট-দের মধ্যে বাস্তবায়ন করা সহজ করে তোলে। এই নতুন সর্বোচ্চ লেনদেন আকারটি প্রাক-Pectra গড় ব্লক আকারের অনুরূপ, যা এটিকে Ethereum-এ যেকোনো অপারেশনের জন্য একটি যুক্তিসঙ্গত সীমা করে তোলে।

রিসোর্সসমূহ: EIP-7825 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

MODEXP গ্যাস খরচ বৃদ্ধি

MODEXP হলো একটি প্রিকম্পাইল বিল্ট-ইন ফাংশন যা মডুলার এক্সপোনেনসিয়েশন গণনা করে, যা RSA সিগনেচার ভেরিফিকেশন এবং প্রুফ সিস্টেমে ব্যবহৃত এক ধরণের বড়-সংখ্যার গণিত। এটি কন্ট্রাক্টগুলোকে নিজেদের বাস্তবায়ন না করেই সরাসরি এই গণনাগুলো চালানোর অনুমতি দেয়।

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

এই EIP বাস্তব কম্পিউটেশনাল খরচের সাথে মেলাতে প্রাইসিং পরিবর্তন করে:

  • ন্যূনতম চার্জ 200 থেকে 500 গ্যাস-এ উন্নীত করা এবং সাধারণ খরচ গণনায় EIP-2565 থেকে এক-তৃতীয়াংশ ছাড় সরিয়ে দেওয়া
  • এক্সপোনেন্ট ইনপুট খুব দীর্ঘ হলে খরচ আরও তীব্রভাবে বৃদ্ধি করা। যদি এক্সপোনেন্ট (দ্বিতীয় আর্গুমেন্ট হিসেবে আপনি যে "পাওয়ার" নম্বরটি পাস করেন) 32 বাইট / 256 বিটের চেয়ে দীর্ঘ হয়, তবে প্রতিটি অতিরিক্ত বাইটের জন্য গ্যাস চার্জ অনেক দ্রুত বৃদ্ধি পায়
  • বড় বেস বা মডুলাসের জন্যও অতিরিক্ত চার্জ করা। অন্য দুটি সংখ্যা (বেস এবং মডুলাস) কমপক্ষে 32 বাইট বলে ধরে নেওয়া হয় - যদি কোনোটি বড় হয়, তবে এর আকারের অনুপাতে খরচ বৃদ্ধি পায়

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

রিসোর্সসমূহ: EIP-7883 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

RLP এক্সিকিউশন ব্লক সাইজ লিমিট

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

বিস্তারিত: এটি RLP-এনকোডেড এক্সিকিউশন ব্লক সাইজের উপর একটি ক্যাপ। 10 MiB মোট, বিকন-ব্লক ফ্রেমিংয়ের জন্য সংরক্ষিত 2 MiB সেফটি মার্জিন সহ। বাস্তবে, ক্লায়েন্ট-রা সংজ্ঞায়িত করে

MAX_BLOCK_SIZE = 10,485,760 বাইট এবং

SAFETY_MARGIN = 2,097,152 বাইট,

এবং এমন যেকোনো এক্সিকিউশন ব্লক প্রত্যাখ্যান করে যার RLP পেলোড অতিক্রম করে

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

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

রিসোর্সসমূহ: EIP-7934 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

ডিফল্ট গ্যাস লিমিট 60 মিলিয়নে সেট করা

ফেব্রুয়ারি 2025-এ গ্যাস লিমিট 30M থেকে 36M (এবং পরবর্তীতে 45M)-এ বাড়ানোর আগে, the Merge (সেপ্টেম্বর 2022) থেকে এই মানটি পরিবর্তিত হয়নি। এই EIP-এর লক্ষ্য হলো ধারাবাহিক স্কেলিং-কে অগ্রাধিকার দেওয়া।

EIP-7935 EL ক্লায়েন্ট টিমগুলোকে Fusaka-এর জন্য ডিফল্ট গ্যাস-লিমিট আজকের 45M-এর উপরে বাড়ানোর জন্য সমন্বয় করে। এটি একটি ইনফরমেশনাল EIP, তবে এটি স্পষ্টভাবে ক্লায়েন্ট-দের ডেভনেটগুলোতে উচ্চতর সীমা পরীক্ষা করতে, একটি নিরাপদ মানে পৌঁছাতে এবং তাদের Fusaka রিলিজে সেই সংখ্যাটি শিপ করতে বলে।

ডেভনেট পরিকল্পনা ~60M স্ট্রেস (সিন্থেটিক লোড সহ ফুল ব্লকস) এবং ইটারেটিভ বাম্পস লক্ষ্য করে; গবেষণা বলে যে সবচেয়ে খারাপ পরিস্থিতির ব্লক-সাইজ প্যাথলজিগুলো ~150M-এর নিচে আবদ্ধ হওয়া উচিত নয়। রোলআউটটি ট্রানজেকশন গ্যাস-লিমিট ক্যাপ (EIP-7825)-এর সাথে যুক্ত করা উচিত যাতে সীমা বাড়ার সাথে সাথে কোনো একক লেনদেন আধিপত্য বিস্তার করতে না পারে।

রিসোর্সসমূহ: EIP-7935 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

UX উন্নত করা

ডিটারমিনিস্টিক প্রপোজার লুকঅ্যাহেড

EIP-7917-এর মাধ্যমে, বিকন চেইন পরবর্তী এপোক-এর জন্য আসন্ন ব্লক প্রপোজার সম্পর্কে সচেতন হবে। ভবিষ্যতের ব্লকস কোন ভ্যালিডেটরস প্রস্তাব করবে সে সম্পর্কে একটি ডিটারমিনিস্টিক ভিউ থাকা প্রিকনফার্মেশনস (opens in a new tab) সক্ষম করতে পারে - আসন্ন প্রপোজারের সাথে একটি প্রতিশ্রুতি যা গ্যারান্টি দেয় যে ব্যবহারকারীর লেনদেন প্রকৃত ব্লক-এর জন্য অপেক্ষা না করেই তাদের ব্লক-এ অন্তর্ভুক্ত করা হবে।

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

রিসোর্সসমূহ: EIP-7917 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

কাউন্ট লিডিং জিরোস (CLZ) অপকোড

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

রিসোর্সসমূহ: EIP-7939 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

secp256r1 কার্ভ সাপোর্টের জন্য প্রিকম্পাইল

ফিক্সড এডড্রেস 0x100-এ একটি বিল্ট-ইন, পাসকি-স্টাইল secp256r1 (P-256) সিগনেচার চেকার প্রবর্তন করে যা ইতিমধ্যেই অনেক L2 দ্বারা গৃহীত একই কল ফরম্যাট ব্যবহার করে এবং এজ কেসগুলো ঠিক করে, যাতে সেই পরিবেশগুলোর জন্য লেখা কন্ট্রাক্টগুলো কোনো পরিবর্তন ছাড়াই L1-এ কাজ করে।

UX আপগ্রেড! ব্যবহারকারীদের জন্য, এটি ডিভাইস-নেটিভ সাইনিং এবং পাসকি আনলক করে। ওয়ালেট-গুলো সরাসরি Apple Secure Enclave, Android Keystore, হার্ডওয়্যার সিকিউরিটি মডিউল (HSMs) এবং FIDO2/WebAuthn-এ ট্যাপ করতে পারে - কোনো সিড ফ্রেজ নেই, মসৃণ অনবোর্ডিং এবং মাল্টি-ফ্যাক্টর ফ্লো যা আধুনিক অ্যাপের মতো মনে হয়। এর ফলে আরও ভালো UX, সহজ রিকভারি এবং একাউন্ট অ্যাবস্ট্রাকশন প্যাটার্ন পাওয়া যায় যা বিলিয়ন বিলিয়ন ডিভাইস ইতিমধ্যেই যা করে তার সাথে মিলে যায়।

ডেভেলপারদের জন্য, এটি একটি 160-বাইট ইনপুট নেয় এবং একটি 32-বাইট আউটপুট রিটার্ন করে, যা বিদ্যমান লাইব্রেরি এবং L2 কন্ট্রাক্টগুলো পোর্ট করা সহজ করে তোলে। ভিতরে, এটি ভ্যালিড কলারদের ব্রেক না করেই ট্রিকি এজ কেসগুলো দূর করতে পয়েন্ট-অ্যাট-ইনফিনিটি এবং মডুলার-কম্পারিজন চেক অন্তর্ভুক্ত করে।

রিসোর্সসমূহ:

মেটা

eth_config JSON-RPC মেথড

এটি একটি JSON-RPC কল যা আপনাকে আপনার নোড-কে জিজ্ঞাসা করতে দেয় যে আপনি কোন ফর্ক সেটিংস চালাচ্ছেন। এটি তিনটি স্ন্যাপশট রিটার্ন করে: current, next, এবং last যাতে ভ্যালিডেটরস এবং মনিটরিং টুলগুলো যাচাই করতে পারে যে ক্লায়েন্ট-রা আসন্ন ফর্ক-এর জন্য প্রস্তুত কিনা।

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

স্ন্যাপশটগুলোর মধ্যে রয়েছে: chainId, forkId, পরিকল্পিত ফর্ক অ্যাক্টিভেশন সময়, কোন প্রিকম্পাইলগুলো সক্রিয়, প্রিকম্পাইল এডড্রেস, সিস্টেম কন্ট্রাক্ট ডিপেন্ডেন্সি এবং ফর্ক-এর ব্লব শিডিউল।

এই EIP-টি "কোর EIPs" থেকে আলাদা একটি সেকশনে রয়েছে কারণ ফর্ক আসলে কোনো পরিবর্তন বাস্তবায়ন করে না - এটি একটি নোটিশ যে ক্লায়েন্ট টিমগুলোকে অবশ্যই Fusaka আপগ্রেডের মাধ্যমে এই JSON-RPC মেথডটি বাস্তবায়ন করতে হবে।

রিসোর্সসমূহ: EIP-7910 টেকনিক্যাল স্পেসিফিকেশন (opens in a new tab)

সাধারণ জিজ্ঞাসা (FAQ)

এই আপগ্রেড কি সমস্ত Ethereum নোড এবং ভ্যালিডেটরস-কে প্রভাবিত করে?

হ্যাঁ, Fusaka আপগ্রেডের জন্য এক্সিকিউশন ক্লায়েন্ট এবং কনসেন্সাস ক্লায়েন্ট উভয়েরই আপডেট প্রয়োজন। সমস্ত প্রধান Ethereum ক্লায়েন্ট উচ্চ অগ্রাধিকার হিসেবে চিহ্নিত হার্ড ফর্ক সমর্থনকারী সংস্করণ প্রকাশ করবে। আপনি এই রিলিজগুলো কখন ক্লায়েন্ট GitHub রেপো, তাদের Discord চ্যানেল (opens in a new tab), EthStaker Discord (opens in a new tab)-এ পাওয়া যাবে তা আপনি নজরে রাখতে পারেন, অথবা প্রটোকল আপডেটের জন্য Ethereum ব্লগে সাবস্ক্রাইব করতে পারেন। আপগ্রেড-পরবর্তী Ethereum নেটওয়ার্ক-এর সাথে সিঙ্ক্রোনাইজেশন বজায় রাখতে, নোড অপারেটরদের অবশ্যই নিশ্চিত করতে হবে যে তারা একটি সমর্থিত ক্লায়েন্ট সংস্করণ চালাচ্ছেন। মনে রাখবেন যে ক্লায়েন্ট রিলিজ সম্পর্কে তথ্য সময়-সংবেদনশীল, এবং ব্যবহারকারীদের সবচেয়ে বর্তমান বিবরণের জন্য সর্বশেষ আপডেটগুলো দেখা উচিত।

হার্ড ফর্ক-এর পরে কীভাবে ETH রূপান্তর করা যায়?

  • আপনার ETH-এর জন্য কোনো পদক্ষেপের প্রয়োজন নেই: Ethereum Fusaka আপগ্রেডের পরে, আপনার ETH রূপান্তর বা আপগ্রেড করার কোনো প্রয়োজন নেই। আপনার একাউন্ট ব্যালেন্স একই থাকবে এবং আপনার বর্তমানে থাকা ETH হার্ড ফর্ক-এর পরেও এর বিদ্যমান ফর্মে অ্যাক্সেসযোগ্য থাকবে।
  • স্ক্যাম থেকে সাবধান! যে কেউ আপনাকে আপনার ETH "আপগ্রেড" করার নির্দেশ দিলে সে আপনার সাথে স্ক্যাম করার চেষ্টা করছে। এই আপগ্রেডের বিষয়ে আপনার কিছুই করার দরকার নেই। আপনার সম্পদ সম্পূর্ণ অক্ষত থাকবে। মনে রাখবেন, অবগত থাকাই স্ক্যামের বিরুদ্ধে সর্বোত্তম প্রতিরক্ষা।

স্ক্যাম চেনা এবং এড়ানো সম্পর্কে আরও জানুন

জেব্রার বিষয়টি কী?

একটি জেব্রা হলো Fusaka-এর ডেভেলপার-নির্বাচিত "মাসকট" কারণ এর ডোরাকাটা দাগগুলো PeerDAS-এর কলাম-ভিত্তিক ডাটা-এভেইলএবিলিটি স্যাম্পলিং প্রতিফলিত করে, যেখানে নোড-গুলো নির্দিষ্ট কলাম সাবনেট কাস্টডি করে এবং ব্লব ডাটা উপলব্ধ কিনা তা পরীক্ষা করার জন্য প্রতিটি পিয়ার স্লট থেকে কয়েকটি অন্যান্য কলাম স্যাম্পল করে।

2022 সালে the Merge এক্সিকিউশন এবং কনসেন্সাস লেয়ার-এর যোগদান বোঝাতে এর মাসকট হিসেবে একটি পান্ডা ব্যবহার করেছিল (opens in a new tab)। তারপর থেকে, প্রতিটি ফর্ক-এর জন্য অনানুষ্ঠানিকভাবে মাসকট বেছে নেওয়া হয়েছে এবং আপগ্রেডের সময় ক্লায়েন্ট লগগুলোতে ASCII আর্ট হিসেবে প্রদর্শিত হয়। এটি উদযাপন করার একটি মজার উপায় মাত্র।

L2 স্কেলিং-এর জন্য কী কী উন্নতি অন্তর্ভুক্ত করা হয়েছে?

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

BPO ফর্কগুলো কীভাবে আলাদা?

ব্লব অনলি প্যারামিটার ফর্কগুলো একটি সম্পূর্ণ সমন্বিত আপগ্রেডের জন্য অপেক্ষা না করেই PeerDAS সক্রিয় হওয়ার পরে ব্লব সংখ্যা (টার্গেট এবং ম্যাক্স উভয়ই) ক্রমাগত বাড়ানোর একটি মেকানিজম প্রদান করে। প্রতিটি বৃদ্ধি Fusaka সমর্থনকারী ক্লায়েন্ট রিলিজগুলোতে প্রি-কনফিগার করার জন্য হার্ডকোড করা হয়।

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

BPO শিডিউল কী?

BPO আপডেটের সঠিক শিডিউল Fusaka রিলিজের সাথে নির্ধারণ করা হবে। প্রটোকল ঘোষণা (opens in a new tab) এবং আপনার ক্লায়েন্ট-দের রিলিজ নোটগুলো অনুসরণ করুন।

এটি কেমন হতে পারে তার উদাহরণ:

  • Fusaka-এর আগে: টার্গেট 6, ম্যাক্স 9
  • Fusaka অ্যাক্টিভেশনে: টার্গেট 6, ম্যাক্স 9
  • BPO1, Fusaka অ্যাক্টিভেশনের কয়েক সপ্তাহ পরে: টার্গেট 10, ম্যাক্স 15, দুই-তৃতীয়াংশ বৃদ্ধি
  • BPO2, BPO1-এর কয়েক সপ্তাহ পরে: টার্গেট 14, ম্যাক্স 21

এটি কি Ethereum-এ (লেয়ার 1) ফি কমাবে

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

একজন স্টেকার হিসেবে, আপগ্রেডের জন্য আমাকে কী করতে হবে?

প্রতিটি নেটওয়ার্ক আপগ্রেডের মতো, Fusaka সমর্থন সহ চিহ্নিত সর্বশেষ সংস্করণগুলোতে আপনার ক্লায়েন্ট-দের আপডেট করা নিশ্চিত করুন। রিলিজ সম্পর্কে জানতে মেইলিং লিস্ট এবং EF ব্লগে প্রটোকল ঘোষণা (opens in a new tab)-এর আপডেটগুলো অনুসরণ করুন। মেইননেট-এ Fusaka সক্রিয় হওয়ার আগে আপনার সেটআপ যাচাই করতে, আপনি টেস্টনেট-গুলোতে একটি ভ্যালিডেটর চালাতে পারেন। Fusaka টেস্টনেট-গুলোতে আগে সক্রিয় হয় (opens in a new tab) যা আপনাকে সবকিছু কাজ করছে কিনা তা নিশ্চিত করতে এবং বাগ রিপোর্ট করতে আরও সুযোগ দেয়। টেস্টনেট ফর্কগুলোও মেইলিং লিস্ট এবং ব্লগে ঘোষণা করা হয়।

"ডিটারমিনিস্টিক প্রপোজার লুকঅ্যাহেড" (EIP-7917) কি ভ্যালিডেটরস-কে প্রভাবিত করে?

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

Fusaka কীভাবে নোড এবং ভ্যালিডেটরস-এর জন্য ব্যান্ডউইথের প্রয়োজনীয়তাকে প্রভাবিত করে?

নোড-গুলো কীভাবে ব্লব ডাটা ট্রান্সমিট করে তাতে PeerDAS একটি উল্লেখযোগ্য পরিবর্তন আনে। সমস্ত ডাটা 128টি সাবনেট জুড়ে কলাম নামক টুকরোতে বিভক্ত করা হয় যেখানে নোড-গুলো শুধুমাত্র সেগুলোর কয়েকটিতে সাবস্ক্রাইব করে। নোড-গুলোকে যে পরিমাণ সাবনেট কলাম কাস্টডি করতে হবে তা তাদের কনফিগারেশন এবং সংযুক্ত ভ্যালিডেটরস-এর সংখ্যার উপর নির্ভর করে। প্রকৃত ব্যান্ডউইথের প্রয়োজনীয়তা নেটওয়ার্ক-এ অনুমোদিত ব্লবের পরিমাণ এবং নোড-এর ধরণের উপর নির্ভর করবে। Fusaka অ্যাক্টিভেশনের মুহূর্তে ব্লব টার্গেট আগের মতোই থাকে, তবে PeerDAS-এর সাথে, নোড অপারেটররা ব্লবের ডিস্ক ব্যবহার এবং নেটওয়ার্ক ট্রাফিক হ্রাস দেখতে পারে। যেহেতু BPO-গুলো নেটওয়ার্ক-এ বেশি সংখ্যক ব্লব কনফিগার করে, তাই প্রতিটি BPO-এর সাথে প্রয়োজনীয় ব্যান্ডউইথ বৃদ্ধি পাবে।

Fusaka BPO-গুলোর পরেও নোড-গুলোর প্রয়োজনীয়তা এখনও প্রস্তাবিত মার্জিনের (opens in a new tab) মধ্যেই রয়েছে।

ফুল নোড

কোনো ভ্যালিডেটরস ছাড়া সাধারণ নোড-গুলো শুধুমাত্র 4টি সাবনেটে সাবস্ক্রাইব করবে, যা মূল ডাটার 1/8 অংশের জন্য কাস্টডি প্রদান করবে। এর মানে হলো একই পরিমাণ ব্লব ডাটার সাথে, সেগুলো ডাউনলোড করার নোড ব্যান্ডউইথ আট (8) গুণ ছোট হবে। একটি সাধারণ ফুল নোড-এর জন্য ব্লবের ডিস্ক ব্যবহার এবং ডাউনলোড ব্যান্ডউইথ প্রায় 80% কমে গিয়ে মাত্র কয়েক Mb হতে পারে।

সোলো স্টেকার

যদি নোড-টি একটি ভ্যালিডেটর ক্লায়েন্ট-এর জন্য ব্যবহার করা হয়, তবে এটিকে আরও কলাম কাস্টডি করতে হবে এবং তাই আরও ডাটা প্রসেস করতে হবে। একটি ভ্যালিডেটর যোগ করার সাথে, নোড-টি কমপক্ষে 8টি কলাম সাবনেটে সাবস্ক্রাইব করে এবং তাই সাধারণ নোড-এর চেয়ে দ্বিগুণ ডাটা প্রসেস করে তবে এখনও Fusaka-এর আগের চেয়ে কম। যদি ভ্যালিডেটর ব্যালেন্স 287 ETH-এর উপরে হয়, তবে আরও বেশি সাবনেটে সাবস্ক্রাইব করা হবে।

একজন সোলো স্টেকার-এর জন্য, এর মানে হলো তাদের ডিস্ক ব্যবহার এবং ডাউনলোড ব্যান্ডউইথ প্রায় 50% কমে যাবে। তবে স্থানীয়ভাবে ব্লকস তৈরি করতে এবং নেটওয়ার্ক-এ সমস্ত ব্লব আপলোড করতে, আরও আপলোড ব্যান্ডউইথ প্রয়োজন। Fusaka-এর সময় স্থানীয় বিল্ডারদের আগের চেয়ে 2-3 গুণ বেশি আপলোড ব্যান্ডউইথ প্রয়োজন হবে এবং 15/21 ব্লবের BPO2 টার্গেটের সাথে, চূড়ান্ত প্রয়োজনীয় আপলোড ব্যান্ডউইথ প্রায় 5 গুণ বেশি, 100Mpbs হতে হবে।

বড় ভ্যালিডেটরস

নোড-এ আরও ব্যালেন্স এবং ভ্যালিডেটরস যোগ করার সাথে সাথে সাবস্ক্রাইব করা সাবনেটের সংখ্যা বৃদ্ধি পায়। উদাহরণস্বরূপ, প্রায় 800 ETH ব্যালেন্সের ক্ষেত্রে, নোড-টি 25টি কলাম কাস্টডি করে এবং আগের চেয়ে প্রায় 30% বেশি ডাউনলোড ব্যান্ডউইথ প্রয়োজন হবে। প্রয়োজনীয় আপলোড সাধারণ নোড-গুলোর মতোই বৃদ্ধি পায় এবং কমপক্ষে 100Mbps প্রয়োজন।

4096 ETH-এ, 2টি ম্যাক্স ব্যালেন্স ভ্যালিডেটরস, নোড-টি 'সুপারনোড' হয়ে যায় যা সমস্ত কলাম কাস্টডি করে, তাই সবকিছু ডাউনলোড এবং স্টোর করে। এই নোড-গুলো হারিয়ে যাওয়া ডাটা ফিরিয়ে দিয়ে সক্রিয়ভাবে নেটওয়ার্ক-কে নিরাময় করে তবে এর জন্য আরও অনেক বেশি ব্যান্ডউইথ এবং স্টোরেজ প্রয়োজন। চূড়ান্ত ব্লব টার্গেট আগের চেয়ে 6 গুণ বেশি হওয়ায়, সুপার নোড-গুলোকে প্রায় 600GB অতিরিক্ত ব্লব ডাটা স্টোর করতে হবে এবং প্রায় 20Mbps-এ দ্রুত টেকসই ডাউনলোড ব্যান্ডউইথ থাকতে হবে।

প্রত্যাশিত প্রয়োজনীয়তা সম্পর্কে আরও বিস্তারিত পড়ুন। (opens in a new tab)

কী কী EVM পরিবর্তন বাস্তবায়িত হয়েছে?

Fusaka নতুন ছোটখাটো পরিবর্তন এবং ফিচারগুলোর মাধ্যমে EVM-কে সুসংহত করে।

নতুন 16M গ্যাস লিমিট কীভাবে কন্ট্রাক্ট ডেভেলপারদের প্রভাবিত করে?

Fusaka একটি একক লেনদেন-এর সর্বোচ্চ আকার 16.7 মিলিয়ন (opens in a new tab) (2^24) গ্যাস ইউনিটে সীমাবদ্ধ করে। এটি মোটামুটি একটি গড় ব্লক-এর আগের আকার যা এটিকে এমন জটিল লেনদেন-গুলোকে মিটমাট করার জন্য যথেষ্ট বড় করে তোলে যা একটি সম্পূর্ণ ব্লক গ্রাস করবে। এই সীমাটি ক্লায়েন্ট-দের জন্য সুরক্ষা তৈরি করে, ভবিষ্যতে উচ্চতর ব্লক গ্যাস লিমিট সহ সম্ভাব্য DoS আক্রমণ প্রতিরোধ করে। স্কেলিংয়ের লক্ষ্য হলো কোনো একক লেনদেন সম্পূর্ণ ব্লক গ্রাস না করেই ব্লকচেইন-এ আরও বেশি লেনদেন প্রবেশ করতে সক্ষম করা।

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

RPC মেথড eth_call সীমাবদ্ধ নয় এবং এটি প্রকৃত ব্লকচেইন সীমার চেয়ে বড় লেনদেন-এর সিমুলেশনের অনুমতি দেবে। অপব্যবহার রোধ নিশ্চিত করতে ক্লায়েন্ট অপারেটর দ্বারা RPC মেথডগুলোর প্রকৃত সীমা কনফিগার করা যেতে পারে।

ডেভেলপারদের জন্য CLZ-এর অর্থ কী?

Solidity-এর মতো EVM কম্পাইলারগুলো ভিতরে জিরো গণনার জন্য নতুন ফাংশনটি বাস্তবায়ন এবং ব্যবহার করবে। নতুন কন্ট্রাক্টগুলো গ্যাস সাশ্রয় থেকে উপকৃত হতে পারে যদি তারা এই ধরণের অপারেশনের উপর নির্ভর করে। সম্ভাব্য সাশ্রয়ের ডকুমেন্টেশনের জন্য স্মার্ট কন্ট্রাক্ট ভাষার রিলিজ এবং ফিচার ঘোষণা অনুসরণ করুন।

আমার বিদ্যমান স্মার্ট কন্ট্রাক্ট-গুলোর জন্য কি কোনো পরিবর্তন আছে?

Fusaka-এর কোনো সরাসরি প্রভাব নেই যা কোনো বিদ্যমান কন্ট্রাক্ট ব্রেক করবে বা তাদের আচরণ পরিবর্তন করবে। এক্সিকিউশন লেয়ার-এ প্রবর্তিত পরিবর্তনগুলো ব্যাকওয়ার্ড কম্প্যাটিবিলিটির সাথে করা হয়েছে, তবে সর্বদা এজ কেস এবং সম্ভাব্য প্রভাবের দিকে নজর রাখুন।

ModExp প্রিকম্পাইলের বর্ধিত খরচের সাথে (opens in a new tab), এর উপর নির্ভরশীল কন্ট্রাক্টগুলো এক্সিকিউশনের জন্য বেশি গ্যাস খরচ করবে। যদি আপনার কন্ট্রাক্ট এর উপর ব্যাপকভাবে নির্ভর করে এবং ব্যবহারকারীদের জন্য আরও ব্যয়বহুল হয়ে ওঠে, তবে এটি কীভাবে ব্যবহার করা হয় তা পুনর্বিবেচনা করুন।

যদি আপনার কন্ট্রাক্টগুলো এক্সিকিউট করা লেনদেন-গুলো অনুরূপ আকারে পৌঁছাতে পারে তবে নতুন 16.7 মিলিয়ন সীমা (opens in a new tab) বিবেচনা করুন।

আরও পড়ুন

পেজ সর্বশেষ আপডেট: 23 ফেব্রুয়ারী, 2026

architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
corwintinesc (opens in a new tab)
+5

এই আর্টিকেলটি কি সহায়ক ছিল?