From 814bd04afe5e5c155aecaaab4739d8c95ec9f973 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:06:52 +0000 Subject: [PATCH 1/3] i18n(bn): translation import part 03 of 13 (24 files) --- .../pos/attack-and-defense/index.md | 166 +++ .../pos/attestations/index.md | 92 ++ .../pos/block-proposal/index.md | 69 ++ .../consensus-mechanisms/pos/faqs/index.md | 172 +++ .../consensus-mechanisms/pos/gasper/index.md | 52 + .../docs/consensus-mechanisms/pos/index.md | 99 ++ .../consensus-mechanisms/pos/keys/index.md | 102 ++ .../pos/pos-vs-pow/index.md | 69 ++ .../pos/rewards-and-penalties/index.md | 91 ++ .../pos/weak-subjectivity/index.md | 39 + .../pos/withdrawal-credentials/index.md | 64 ++ .../docs/consensus-mechanisms/pow/index.md | 114 ++ .../consensus-mechanisms/pow/mining/index.md | 86 ++ .../dagger-hashimoto/index.md | 330 ++++++ .../mining/mining-algorithms/ethash/index.md | 1022 +++++++++++++++++ .../pow/mining/mining-algorithms/index.md | 42 + .../bn/developers/docs/dapps/index.md | 96 ++ .../block-explorers/index.md | 254 ++++ .../docs/data-and-analytics/index.md | 72 ++ .../index.md | 118 ++ .../docs/data-availability/index.md | 84 ++ .../data-structures-and-encoding/index.md | 32 + .../patricia-merkle-trie/index.md | 266 +++++ .../data-structures-and-encoding/rlp/index.md | 163 +++ 24 files changed, 3694 insertions(+) create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attestations/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/block-proposal/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/faqs/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/gasper/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/keys/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pow/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md create mode 100644 public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md create mode 100644 public/content/translations/bn/developers/docs/dapps/index.md create mode 100644 public/content/translations/bn/developers/docs/data-and-analytics/block-explorers/index.md create mode 100644 public/content/translations/bn/developers/docs/data-and-analytics/index.md create mode 100644 public/content/translations/bn/developers/docs/data-availability/blockchain-data-storage-strategies/index.md create mode 100644 public/content/translations/bn/developers/docs/data-availability/index.md create mode 100644 public/content/translations/bn/developers/docs/data-structures-and-encoding/index.md create mode 100644 public/content/translations/bn/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md create mode 100644 public/content/translations/bn/developers/docs/data-structures-and-encoding/rlp/index.md diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md new file mode 100644 index 00000000000..adad61e7683 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -0,0 +1,166 @@ +--- +title: "ইথেরিয়াম প্রুফ-অফ-স্টেক আক্রমণ এবং প্রতিরক্ষা" +description: "প্রুফ-অফ-স্টেক ইথেরিয়ামের পরিচিত আক্রমণ ভেক্টর এবং কীভাবে সেগুলি থেকে প্রতিরক্ষা করা হয়, সে সম্পর্কে জানুন।" +lang: bn +--- + +চোর এবং নাশকতাকারীরা ক্রমাগত ইথেরিয়ামের ক্লায়েন্ট সফটওয়্যার আক্রমণ করার সুযোগ খুঁজছে। এই পৃষ্ঠাটিতে ইথেরিয়ামের কনসেন্সাস লেয়ারের ওপর পরিচিত আক্রমণ ভেক্টরগুলির রূপরেখা দেওয়া হয়েছে এবং কীভাবে সেই আক্রমণগুলির বিরুদ্ধে প্রতিরক্ষা করা যায়, তারও রূপরেখা দেওয়া হয়েছে। এই পৃষ্ঠার তথ্য একটি [দীর্ঘ সংস্করণ](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) থেকে অভিযোজিত। + +## পূর্বশর্ত {#prerequisites} + +[প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) সম্পর্কে কিছু প্রাথমিক জ্ঞান থাকা প্রয়োজন। এছাড়াও, ইথেরিয়ামের [ইনসেন্টিভ লেয়ার](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) এবং ফর্ক-চয়েস অ্যালগরিদম, [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) সম্পর্কে একটি প্রাথমিক ধারণা থাকা সহায়ক হবে। + +## আক্রমণকারীরা কী চায়? {#what-do-attackers-want} + +একটি সাধারণ ভুল ধারণা হল যে একজন সফল আক্রমণকারী নতুন ইথার তৈরি করতে পারে, বা নির্বিচার অ্যাকাউন্ট থেকে ইথার সরিয়ে নিতে পারে। এর কোনোটিই সম্ভব নয় কারণ নেটওয়ার্কের সমস্ত এক্সিকিউশন ক্লায়েন্ট দ্বারা সমস্ত লেনদেন কার্যকর করা হয়। তাদের অবশ্যই বৈধতার প্রাথমিক শর্তগুলি পূরণ করতে হবে (যেমন, লেনদেনগুলি প্রেরকের প্রাইভেট কী দ্বারা স্বাক্ষরিত, প্রেরকের পর্যাপ্ত ব্যালেন্স রয়েছে, ইত্যাদি) অন্যথায় সেগুলি কেবল প্রত্যাবর্তন করে। এমন তিন ধরনের ফলাফল রয়েছে যা একজন আক্রমণকারী বাস্তবিকভাবে লক্ষ্য করতে পারে: রিঅর্গ, ডাবল ফাইনালিটি বা ফাইনালিটি ডিলে। + +একটি **“রিঅর্গ”** হলো ক্যানোনিকাল চেইনে ব্লকগুলির একটি নতুন ক্রমে পুনর্বিন্যাস করা, সম্ভবত কিছু ব্লক যোগ বা বিয়োগ করে। একটি বিদ্বেষপূর্ণ রিঅর্গ নির্দিষ্ট ব্লক অন্তর্ভুক্ত বা বাদ দেওয়া নিশ্চিত করতে পারে, যা ডাবল-স্পেন্ডিং বা ফ্রন্ট-রানিং এবং ব্যাক-রানিং লেনদেনের (MEV) মাধ্যমে মূল্য আহরণের সুযোগ দেয়। রি-অর্গগুলি ক্যানোনিকাল চেইনে নির্দিষ্ট লেনদেনকে অন্তর্ভুক্ত হওয়া থেকে আটকাতেও ব্যবহার করা যেতে পারে - যা এক ধরনের সেন্সরশিপ। রিঅর্গের সবচেয়ে চরম রূপ হলো “ফাইনালিটি রিভার্সন”, যা পূর্বে ফাইনাল হওয়া ব্লকগুলিকে সরিয়ে দেয় বা প্রতিস্থাপন করে। এটি কেবল তখনই সম্ভব যদি আক্রমণকারী মোট স্টেক করা ইথারের ⅓-এর বেশি ধ্বংস করে দেয় - এই নিশ্চয়তাটি “ইকোনমিক ফাইনালিটি” নামে পরিচিত - এই বিষয়ে পরে আরও আলোচনা করা হবে। + +**ডাবল ফাইনালিটি** হল একটি অসম্ভাব্য কিন্তু গুরুতর পরিস্থিতি যেখানে দুটি ফর্ক একযোগে ফাইনাল হতে পারে, যা চেইনে একটি স্থায়ী বিভেদ তৈরি করে। মোট স্টেক করা ইথারের 34% ঝুঁকি নিতে ইচ্ছুক একজন আক্রমণকারীর জন্য এটি তাত্ত্বিকভাবে সম্ভব। সম্প্রদায়কে অফচেইন সমন্বয় করতে এবং কোন চেইন অনুসরণ করতে হবে সে সম্পর্কে একটি চুক্তিতে আসতে বাধ্য করা হবে, যার জন্য সামাজিক লেয়ারে শক্তির প্রয়োজন হবে। + +একটি **ফাইনালিটি ডিলে** আক্রমণ নেটওয়ার্ককে চেইনের বিভাগগুলোকে ফাইনাল করার জন্য প্রয়োজনীয় শর্তে পৌঁছাতে বাধা দেয়। ফাইনালিটি ছাড়া, ইথেরিয়ামের উপরে নির্মিত আর্থিক অ্যাপ্লিকেশনগুলিকে বিশ্বাস করা কঠিন। একটি ফাইনালিটি ডিলে আক্রমণের লক্ষ্য সম্ভবত সরাসরি লাভের পরিবর্তে ইথেরিয়ামকে ব্যাহত করা, যদি না আক্রমণকারীর কিছু কৌশলগত শর্ট পজিশন থাকে। + +সামাজিক লেয়ারের উপর একটি আক্রমণের লক্ষ্য হতে পারে ইথেরিয়ামের উপর জনসাধারণের আস্থা নষ্ট করা, ইথারের অবমূল্যায়ন করা, গ্রহণ হ্রাস করা বা ইথেরিয়াম সম্প্রদায়কে দুর্বল করা যাতে ব্যান্ডের বাইরের সমন্বয় আরও কঠিন হয়ে ওঠে। + +একজন প্রতিপক্ষ কেন ইথেরিয়ামকে আক্রমণ করতে পারে তা প্রতিষ্ঠা করার পর, নিম্নলিখিত বিভাগগুলি পরীক্ষা করে যে তারা _কীভাবে_ এটি করতে পারে। + +## আক্রমণের পদ্ধতি {#methods-of-attack} + +### লেয়ার 0 আক্রমণ {#layer-0} + +প্রথমত, যে ব্যক্তিরা সক্রিয়ভাবে ইথেরিয়ামে অংশগ্রহণ করছেন না (ক্লায়েন্ট সফ্টওয়্যার চালানোর মাধ্যমে) তারা সামাজিক স্তর (লেয়ার 0) লক্ষ্য করে আক্রমণ করতে পারেন। লেয়ার 0 হল সেই ভিত্তি যার উপর ইথেরিয়াম নির্মিত, এবং সেই কারণে এটি আক্রমণের জন্য একটি সম্ভাব্য ক্ষেত্র যার পরিণতি বাকি স্ট্যাকের মাধ্যমে ছড়িয়ে পড়ে। কিছু উদাহরণ অন্তর্ভুক্ত হতে পারে: + +- একটি ভুল তথ্য প্রচার ইথেরিয়ামের রোডম্যাপ, ডেভেলপারদের দল, অ্যাপস ইত্যাদির প্রতি সম্প্রদায়ের আস্থাকে ক্ষয় করতে পারে। এটি তখন নেটওয়ার্ক সুরক্ষিত করতে ইচ্ছুক ব্যক্তির সংখ্যা হ্রাস করতে পারে, যা বিকেন্দ্রীকরণ এবং ক্রিপ্টো-অর্থনৈতিক নিরাপত্তা উভয়কেই হ্রাস করে। + +- ডেভেলপার সম্প্রদায়ের প্রতি লক্ষ্যবস্তু আক্রমণ এবং/অথবা ভীতি প্রদর্শন। এটি ডেভেলপারদের স্বেচ্ছায় প্রস্থান এবং ইথেরিয়ামের অগ্রগতি মন্থর করতে পারে। + +- অতিরিক্ত উদ্যোগী নিয়ন্ত্রণকেও লেয়ার 0-এর উপর আক্রমণ হিসাবে বিবেচনা করা যেতে পারে, কারণ এটি দ্রুত অংশগ্রহণ এবং গ্রহণকে নিরুৎসাহিত করতে পারে। + +- ডেভেলপার সম্প্রদায়ে জ্ঞানী কিন্তু দূষিত অভিনেতাদের অনুপ্রবেশ যাদের লক্ষ্য হল বাইক-শেডিং আলোচনার মাধ্যমে অগ্রগতি মন্থর করা, মূল সিদ্ধান্ত বিলম্বিত করা, স্প্যাম তৈরি করা ইত্যাদি। + +- সিদ্ধান্ত গ্রহণে প্রভাব ফেলতে ইথেরিয়াম ইকোসিস্টেমের মূল খেলোয়াড়দের ঘুষ দেওয়া। + +যা এই আক্রমণগুলিকে বিশেষভাবে বিপজ্জনক করে তোলে তা হল অনেক ক্ষেত্রে খুব কম মূলধন বা প্রযুক্তিগত জ্ঞানের প্রয়োজন হয়। একটি লেয়ার 0 আক্রমণ একটি ক্রিপ্টো-অর্থনৈতিক আক্রমণের উপর একটি গুণক হতে পারে। উদাহরণস্বরূপ, যদি একটি বিদ্বেষপরায়ণ সংখ্যাগরিষ্ঠ স্টেকহোল্ডার দ্বারা সেন্সরশিপ বা ফাইনালিটি রিভার্সন অর্জন করা হয়, তাহলে সামাজিক লেয়ারকে দুর্বল করা একটি সম্প্রদায় প্রতিক্রিয়াকে ব্যান্ডের বাইরে সমন্বয় করা আরও কঠিন করে তুলতে পারে। + +লেয়ার 0 আক্রমণের বিরুদ্ধে প্রতিরক্ষা সম্ভবত সহজবোধ্য নয়, তবে কিছু মৌলিক নীতি স্থাপন করা যেতে পারে। একটি হল ইথেরিয়াম সম্পর্কে জনসাধারণের তথ্যের জন্য একটি সামগ্রিক উচ্চ সংকেত-থেকে-শব্দ অনুপাত বজায় রাখা, যা সম্প্রদায়ের সৎ সদস্যদের দ্বারা ব্লগ, ডিসকর্ড সার্ভার, টীকাযুক্ত স্পেক, বই, পডকাস্ট এবং ইউটিউবের মাধ্যমে তৈরি এবং প্রচারিত হয়। এখানে ethereum.org-এ আমরা সঠিক তথ্য বজায় রাখতে এবং এটিকে যতটা সম্ভব ভাষায় অনুবাদ করার জন্য কঠোর চেষ্টা করি। উচ্চ মানের তথ্য এবং মেমে দিয়ে একটি স্থান প্লাবিত করা ভুল তথ্যের বিরুদ্ধে একটি কার্যকর প্রতিরক্ষা। + +সামাজিক লেয়ার আক্রমণের বিরুদ্ধে আরেকটি গুরুত্বপূর্ণ দুর্গ হল একটি স্পষ্ট মিশন বিবৃতি এবং গভর্নেন্স প্রোটোকল। ইথেরিয়াম নিজেকে স্মার্ট-কন্ট্রাক্ট লেয়ার 1-এর মধ্যে বিকেন্দ্রীকরণ এবং নিরাপত্তার চ্যাম্পিয়ন হিসাবে প্রতিষ্ঠিত করেছে, পাশাপাশি স্কেলেবিলিটি এবং স্থায়িত্বকেও অত্যন্ত মূল্য দেয়। ইথেরিয়াম সম্প্রদায়ে যে মতবিরোধই দেখা দিক না কেন, এই মূল নীতিগুলিতে ন্যূনতম আপস করা হয়। এই মূল নীতিগুলির বিরুদ্ধে একটি আখ্যানের মূল্যায়ন করা এবং EIP (ইথেরিয়াম ইমপ্রুভমেন্ট প্রোপোজাল) প্রক্রিয়ায় পর্যালোচনার ধারাবাহিক রাউন্ডের মাধ্যমে সেগুলি পরীক্ষা করা, সম্প্রদায়কে ভাল এবং খারাপ অভিনেতাদের মধ্যে পার্থক্য করতে সাহায্য করতে পারে এবং ইথেরিয়ামের ভবিষ্যতের দিকনির্দেশকে প্রভাবিত করার জন্য দূষিত অভিনেতাদের সুযোগ সীমিত করতে পারে। + +অবশেষে, এটি অত্যন্ত গুরুত্বপূর্ণ যে ইথেরিয়াম সম্প্রদায় সমস্ত অংশগ্রহণকারীদের জন্য উন্মুক্ত এবং স্বাগত জানায়। দ্বাররক্ষক এবং একচেটিয়াতা সহ একটি সম্প্রদায় সামাজিক আক্রমণের জন্য বিশেষভাবে ঝুঁকিপূর্ণ কারণ এটি "আমরা এবং তারা" আখ্যান তৈরি করা সহজ। গোষ্ঠীবাদ এবং বিষাক্ত সর্বোচ্চবাদ সম্প্রদায়ের ক্ষতি করে এবং লেয়ার 0 নিরাপত্তাকে ক্ষয় করে। নেটওয়ার্কের নিরাপত্তায় নিহিত স্বার্থ সহ ইথেরিয়ানদের অনলাইনে এবং মিটস্পেসে তাদের আচরণকে ইথেরিয়ামের লেয়ার 0-এর নিরাপত্তায় সরাসরি অবদানকারী হিসাবে দেখা উচিত। + +### প্রোটোকলে আক্রমণ করা {#attacking-the-protocol} + +যে কেউ ইথেরিয়ামের ক্লায়েন্ট সফ্টওয়্যার চালাতে পারে। একটি ক্লায়েন্টে একটি ভ্যালিডেটর যোগ করতে, একজন ব্যবহারকারীকে ডিপোজিট কন্ট্রাক্টে 32 ইথার স্টেক করতে হবে। একটি ভ্যালিডেটর একজন ব্যবহারকারীকে নতুন ব্লক প্রস্তাব এবং প্রমাণীকরণের মাধ্যমে ইথেরিয়ামের নেটওয়ার্ক নিরাপত্তায় সক্রিয়ভাবে অংশগ্রহণ করতে দেয়। ভ্যালিডেটরের এখন একটি কণ্ঠস্বর আছে যা তারা ব্লকচেইনের ভবিষ্যতের বিষয়বস্তুকে প্রভাবিত করতে ব্যবহার করতে পারে - তারা সততার সাথে এটি করতে পারে এবং পুরস্কারের মাধ্যমে তাদের ইথারের ভান্ডার বাড়াতে পারে অথবা তারা তাদের নিজের সুবিধার জন্য প্রক্রিয়াটিকে কাজে লাগানোর চেষ্টা করতে পারে, তাদের স্টেককে ঝুঁকিতে ফেলে। আক্রমণের একটি উপায় হল মোট স্টেকের একটি বড় অংশ সংগ্রহ করা এবং তারপর সৎ ভ্যালিডেটরদের ছাড়িয়ে যাওয়ার জন্য এটি ব্যবহার করা। আক্রমণকারীর দ্বারা নিয়ন্ত্রিত স্টেকের অনুপাত যত বেশি হবে, তাদের ভোটের ক্ষমতা তত বেশি হবে, বিশেষ করে নির্দিষ্ট অর্থনৈতিক মাইলফলকে যা আমরা পরে অন্বেষণ করব। যাইহোক, বেশিরভাগ আক্রমণকারী এইভাবে আক্রমণ করার জন্য পর্যাপ্ত ইথার সংগ্রহ করতে সক্ষম হবে না, তাই পরিবর্তে তাদের সৎ সংখ্যাগরিষ্ঠকে একটি নির্দিষ্ট উপায়ে কাজ করার জন্য সূক্ষ্ম কৌশল ব্যবহার করতে হবে। + +মূলত, সমস্ত ছোট-স্টেক আক্রমণ হল দুই ধরনের ভ্যালিডেটর অসদাচরণের সূক্ষ্ম ভিন্নতা: কম-ক্রিয়াকলাপ (প্রমাণ/প্রস্তাব করতে ব্যর্থ হওয়া বা দেরিতে করা) বা অতিরিক্ত-ক্রিয়াকলাপ (একটি স্লটে অনেকবার প্রস্তাব/প্রমাণ করা)। তাদের সবচেয়ে সরল রূপে এই ক্রিয়াগুলি ফর্ক-চয়েস অ্যালগরিদম এবং ইনসেনটিভ লেয়ার দ্বারা সহজেই পরিচালিত হয়, তবে আক্রমণকারীর সুবিধার জন্য সিস্টেমটিকে খেলার জন্য চতুর উপায় রয়েছে। + +### অল্প পরিমাণে ETH ব্যবহার করে আক্রমণ {#attacks-by-small-stakeholders} + +#### রিঅর্গ {#reorgs} + +বেশ কয়েকটি গবেষণাপত্রে ইথেরিয়ামের উপর আক্রমণের ব্যাখ্যা দেওয়া হয়েছে যা মোট স্টেক করা ইথারের একটি ছোট অনুপাতের সাথে রিঅর্গ বা ফাইনালিটি ডিলে অর্জন করে। এই আক্রমণগুলি সাধারণত আক্রমণকারীর উপর নির্ভর করে যে তারা অন্যান্য ভ্যালিডেটরদের কাছ থেকে কিছু তথ্য গোপন করে এবং তারপর এটিকে কিছু সূক্ষ্ম উপায়ে এবং/অথবা কিছু সুবিধাজনক মুহূর্তে প্রকাশ করে। তারা সাধারণত ক্যানোনিকাল চেইন থেকে কিছু সৎ ব্লককে স্থানচ্যুত করার লক্ষ্য রাখে। [নিউডার এট আল ২০২০](https://arxiv.org/pdf/2102.02247.pdf) দেখিয়েছেন কিভাবে একজন আক্রমণকারী ভ্যালিডেটর একটি নির্দিষ্ট স্লট `n+1`-এর জন্য একটি ব্লক (`B`) তৈরি করতে এবং প্রমাণ করতে পারে কিন্তু নেটওয়ার্কের অন্যান্য নোডগুলিতে এটি প্রচার করা থেকে বিরত থাকতে পারে। পরিবর্তে, তারা পরবর্তী স্লট `n+2` পর্যন্ত সেই সত্যায়িত ব্লকটি ধরে রাখে। একজন সৎ ভ্যালিডেটর স্লট `n+2` এর জন্য একটি ব্লক (`C`) প্রস্তাব করে। প্রায় একই সাথে, আক্রমণকারী তাদের গোপন রাখা ব্লক (`B`) এবং এর জন্য তাদের গোপন রাখা অ্যাটেস্টেশনগুলি প্রকাশ করতে পারে, এবং স্লট `n+2`-এর জন্য তাদের ভোট দিয়ে চেইনের প্রধান হিসাবে `B`-কে অ্যাটেস্ট করতে পারে, কার্যকরভাবে সৎ ব্লক `C`-এর অস্তিত্ব অস্বীকার করে। যখন সৎ ব্লক `D` প্রকাশ করা হয়, ফর্ক চয়েস অ্যালগরিদম `C`-এর উপর `D` তৈরির চেয়ে `B`-এর উপর `D` তৈরি করাকে ভারী হিসাবে দেখে। আক্রমণকারী তাই একটি 1-ব্লক এক্স অ্যান্টে রিঅর্গ ব্যবহার করে ক্যানোনিকাল চেইন থেকে স্লট `n+2`-এ সৎ ব্লক `C` অপসারণ করতে সক্ষম হয়েছে। [৩৪% স্টেক সহ একজন আক্রমণকারীর](https://www.youtube.com/watch?v=6vzXwwk12ZE) এই আক্রমণে সফল হওয়ার খুব ভাল সুযোগ রয়েছে, যেমনটি [এই নোটে](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) ব্যাখ্যা করা হয়েছে। তাত্ত্বিকভাবে, যদিও, এই আক্রমণটি ছোট স্টেক দিয়েও চেষ্টা করা যেতে পারে। [নিউডার এট আল ২০২০](https://arxiv.org/pdf/2102.02247.pdf) এই আক্রমণটিকে ৩০% স্টেক দিয়ে কাজ করার বর্ণনা দিয়েছেন, তবে পরে এটি [মোট স্টেকের ২%](https://arxiv.org/pdf/2009.04987.pdf) দিয়ে কার্যকর দেখানো হয়েছিল এবং তারপরে আবার একটি [একক ভ্যালিডেটরের](https://arxiv.org/abs/2110.10086#) জন্য ব্যালান্সিং কৌশল ব্যবহার করে যা আমরা পরবর্তী বিভাগে পরীক্ষা করব। + +![এক্স-অ্যান্টে রি-অর্গ](reorg-schematic.png) + +উপরে বর্ণিত এক-ব্লক রিঅর্গ আক্রমণের একটি ধারণাগত চিত্র (https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair থেকে অভিযোজিত) + +আরও একটি অত্যাধুনিক আক্রমণ সৎ ভ্যালিডেটর সেটকে আলাদা আলাদা গ্রুপে ভাগ করতে পারে যাদের চেইনের প্রধান সম্পর্কে ভিন্ন ভিন্ন দৃষ্টিভঙ্গি রয়েছে। এটি একটি **ব্যালান্সিং আক্রমণ** হিসাবে পরিচিত। আক্রমণকারী একটি ব্লক প্রস্তাব করার সুযোগের জন্য অপেক্ষা করে, এবং যখন এটি আসে তখন তারা সমতুল্য হয় এবং দুটি প্রস্তাব করে। তারা সৎ ভ্যালিডেটর সেটের অর্ধেককে একটি ব্লক পাঠায় এবং অন্য অর্ধেককে অন্য ব্লক পাঠায়। এই ইকুইভোকেশনটি ফর্ক-চয়েস অ্যালগরিদম দ্বারা শনাক্ত করা হবে এবং ব্লক প্রপোজারকে স্ল্যাশ করে নেটওয়ার্ক থেকে বের করে দেওয়া হবে, কিন্তু দুটি ব্লক তখনও বিদ্যমান থাকবে এবং প্রতিটি ফর্কের জন্য ভ্যালিডেটর সেটের প্রায় অর্ধেক অ্যাটেস্ট করবে। এদিকে, অবশিষ্ট বিদ্বেষপরায়ণ ভ্যালিডেটররা তাদের অ্যাটেস্টেশনগুলি আটকে রাখে। তারপরে, একটি বা অন্য ফর্কের পক্ষে অ্যাটেস্টেশনগুলির সঞ্চিত ওজনকে এক বা অন্য ফর্কের পক্ষে ঝুঁকাতে, ঠিক যখন ফর্ক-চয়েস অ্যালগরিদম কার্যকর হয় তখন বেছে বেছে অ্যাটেস্টেশনগুলি যথেষ্ট ভ্যালিডেটরদের কাছে প্রকাশ করে। এটি অনির্দিষ্টকালের জন্য চলতে পারে, আক্রমণকারী ভ্যালিডেটররা দুটি ফর্ক জুড়ে ভ্যালিডেটরদের একটি সমান বিভাজন বজায় রাখে। যেহেতু কোনো ফর্কই ২/৩ সুপারমেজরটি আকর্ষণ করতে পারে না, তাই নেটওয়ার্কটি চূড়ান্ত হবে না। + +**বাউন্সিং আক্রমণ** একই রকম। আক্রমণকারী ভ্যালিডেটরদের দ্বারা আবার ভোট আটকে রাখা হয়। দুটি ফর্কের মধ্যে একটি সমান বিভাজন রাখার জন্য ভোট প্রকাশ করার পরিবর্তে, তারা ফর্ক A এবং ফর্ক B-এর মধ্যে পর্যায়ক্রমে চেকপয়েন্টগুলিকে ন্যায্যতা দেওয়ার জন্য সুবিধাজনক মুহূর্তে তাদের ভোট ব্যবহার করে। দুটি ফর্কের মধ্যে ন্যায্যতার এই ফ্লিপ-ফ্লপিং ন্যায্য উত্স এবং লক্ষ্য চেকপয়েন্টগুলির জোড়া হতে বাধা দেয় যা চূড়ান্ত হতে পারে, চূড়ান্ততা বন্ধ করে দেয়। + + + +বাউন্সিং এবং ব্যালেন্সিং উভয় আক্রমণই নেটওয়ার্ক জুড়ে মেসেজ টাইমিং-এর উপর আক্রমণকারীর খুব সূক্ষ্ম নিয়ন্ত্রণের উপর নির্ভর করে, যা অসম্ভাব্য। তবুও, ধীর মেসেজের তুলনায় দ্রুত মেসেজকে অতিরিক্ত ওজন দেওয়ার আকারে প্রোটোকলে প্রতিরক্ষা তৈরি করা হয়। এটি [প্রোপোজার-ওয়েট বুস্টিং](https://github.com/ethereum/consensus-specs/pull/2730) নামে পরিচিত। বাউন্সিং আক্রমণের বিরুদ্ধে রক্ষা করার জন্য ফর্ক-চয়েস অ্যালগরিদম আপডেট করা হয়েছিল যাতে সর্বশেষ ন্যায্য চেকপয়েন্টটি [প্রতিটি যুগের স্লটের প্রথম ১/৩ অংশ চলাকালীন](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) একটি বিকল্প চেইনের সাথে পরিবর্তন করতে পারে। এই শর্তটি আক্রমণকারীকে পরে স্থাপন করার জন্য ভোট সঞ্চয় করা থেকে বিরত রাখে - ফর্ক চয়েস অ্যালগরিদম কেবল সেই চেকপয়েন্টের প্রতি অনুগত থাকে যা এটি যুগের প্রথম ১/৩ অংশে বেছে নিয়েছিল, যে সময়ে বেশিরভাগ সৎ ভ্যালিডেটররা ভোট দিয়েছিল। + +একসাথে, এই পদক্ষেপগুলি এমন একটি পরিস্থিতি তৈরি করে যেখানে একজন সৎ ব্লক প্রস্তাবক স্লটের শুরু হওয়ার সাথে সাথেই খুব দ্রুত তাদের ব্লক নির্গত করে, তারপরে প্রায় ১/৩ স্লটের (৪ সেকেন্ড) একটি সময়কাল থাকে যেখানে সেই নতুন ব্লকটি ফর্ক-চয়েস অ্যালগরিদমকে অন্য চেইনে স্যুইচ করতে পারে। একই সময়সীমার পরে, ধীর ভ্যালিডেটরদের কাছ থেকে আসা অ্যাটেস্টেশনগুলিকে আগে আসা অ্যাটেস্টেশনগুলির তুলনায় কম ওজন দেওয়া হয়। এটি চেইনের প্রধান নির্ধারণে দ্রুত প্রস্তাবক এবং ভ্যালিডেটরদের দৃঢ়ভাবে সমর্থন করে এবং একটি সফল ব্যালেন্সিং বা বাউন্সিং আক্রমণের সম্ভাবনা যথেষ্ট হ্রাস করে। + +এটা উল্লেখ করার মতো, যে প্রস্তাবক বুস্টিং একা শুধুমাত্র “সস্তা রিঅর্গ” এর বিরুদ্ধে রক্ষা করে, অর্থাৎ, একটি ছোট স্টেক সহ একজন আক্রমণকারীর দ্বারা চেষ্টা করা হয়। প্রকৃতপক্ষে, প্রোপোজার-বুস্টিং নিজেই বড় স্টেকহোল্ডারদের দ্বারা গেম করা যেতে পারে। [এই পোস্টের](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) লেখকরা বর্ণনা করেছেন কিভাবে ৭% স্টেকের একজন আক্রমণকারী সৎ ভ্যালিডেটরদের তাদের ফর্কে তৈরি করতে, একটি সৎ ব্লককে রিঅর্গ করে বের করে দেওয়ার জন্য কৌশলগতভাবে তাদের ভোট স্থাপন করতে পারে। এই আক্রমণটি আদর্শ লেটেন্সি শর্ত ধরে নিয়ে তৈরি করা হয়েছিল যা খুব অসম্ভাব্য। আক্রমণকারীর জন্য প্রতিকূলতা এখনও খুব দীর্ঘ, এবং বৃহত্তর স্টেক মানে আরও বেশি মূলধন ঝুঁকিতে এবং একটি শক্তিশালী অর্থনৈতিক অনীহা। + +[এলএমডি নিয়মকে বিশেষভাবে লক্ষ্য করে একটি ব্যালান্সিং আক্রমণ](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) প্রস্তাব করা হয়েছিল, যা প্রোপোজার বুস্টিং সত্ত্বেও কার্যকর বলে পরামর্শ দেওয়া হয়েছিল। একজন আক্রমণকারী তাদের ব্লক প্রস্তাবনার ইকুইভোকেটিং করে এবং প্রতিটি ব্লককে নেটওয়ার্কের প্রায় অর্ধেক অংশে প্রচার করে দুটি প্রতিযোগী চেইন স্থাপন করে, ফর্কগুলির মধ্যে একটি আনুমানিক ভারসাম্য স্থাপন করে। তারপরে, ষড়যন্ত্রকারী ভ্যালিডেটররা তাদের ভোট ইকুইভোকেট করে, এটিকে এমনভাবে সময় দেয় যাতে নেটওয়ার্কের অর্ধেক প্রথমে ফর্ক `A`-এর জন্য তাদের ভোট গ্রহণ করে এবং অন্য অর্ধেক প্রথমে ফর্ক `B`-এর জন্য তাদের ভোট গ্রহণ করে। যেহেতু LMD নিয়মটি দ্বিতীয় অ্যাটেস্টেশনটি বাতিল করে এবং প্রতিটি ভ্যালিডেটরের জন্য শুধুমাত্র প্রথমটি রাখে, নেটওয়ার্কের অর্ধেক `A`-এর জন্য ভোট দেখে এবং `B`-এর জন্য কোনোটিই নয়, অন্য অর্ধেক `B`-এর জন্য ভোট দেখে এবং `A`-এর জন্য কোনোটিই নয়। লেখকরা বর্ণনা করেছেন যে LMD নিয়মটি প্রতিপক্ষকে একটি ব্যালান্সিং আক্রমণ মাউন্ট করার জন্য "উল্লেখযোগ্য শক্তি" দেয়। + +এই LMD আক্রমণের ভেক্টরটি [ফর্ক চয়েস অ্যালগরিদম আপডেট](https://github.com/ethereum/consensus-specs/pull/2845) করে বন্ধ করা হয়েছিল যাতে এটি ফর্ক চয়েস বিবেচনা থেকে সম্পূর্ণরূপে ইকুইভোকেটিং ভ্যালিডেটরদের বাতিল করে দেয়। ইকুইভোকেটিং ভ্যালিডেটরদের ভবিষ্যতের প্রভাবও ফর্ক চয়েস অ্যালগরিদম দ্বারা ছাড় দেওয়া হয়। এটি উপরে বর্ণিত ব্যালেন্সিং আক্রমণকে প্রতিরোধ করে এবং একই সাথে অ্যাভাল্যাঞ্চ আক্রমণের বিরুদ্ধে স্থিতিস্থাপকতা বজায় রাখে। + +আরেক ধরনের আক্রমণ, যাকে [**অ্যাভাল্যাঞ্চ আক্রমণ**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3) বলা হয়, একটি [মার্চ ২০২২ সালের গবেষণাপত্রে](https://arxiv.org/pdf/2203.01315.pdf) বর্ণনা করা হয়েছিল। একটি অ্যাভাল্যাঞ্চ আক্রমণ মাউন্ট করতে, আক্রমণকারীকে বেশ কয়েকটি পরপর ব্লক প্রস্তাবক নিয়ন্ত্রণ করতে হবে। প্রতিটি ব্লক প্রস্তাবনা স্লটে, আক্রমণকারী তাদের ব্লকটি গোপন রাখে, সৎ চেইন গোপন রাখা ব্লকগুলির সাথে একটি সমান সাবট্রি ওজনে পৌঁছানো পর্যন্ত সেগুলি সংগ্রহ করে। তারপরে, গোপন রাখা ব্লকগুলি প্রকাশ করা হয় যাতে তারা সর্বাধিক ইকুইভোকেট করে। লেখকরা পরামর্শ দেন যে প্রোপোজার বুস্টিং - ব্যালেন্সিং এবং বাউন্সিং আক্রমণের বিরুদ্ধে প্রাথমিক প্রতিরক্ষা - অ্যাভাল্যাঞ্চ আক্রমণের কিছু রূপের বিরুদ্ধে রক্ষা করে না। যাইহোক, লেখকরা শুধুমাত্র ইথেরিয়ামের ফর্ক-চয়েস অ্যালগরিদমের একটি অত্যন্ত আদর্শীকৃত সংস্করণে আক্রমণটি প্রদর্শন করেছেন (তারা LMD ছাড়া GHOST ব্যবহার করেছেন)। + +অ্যাভাল্যাঞ্চ আক্রমণটি LMD-GHOST ফর্ক চয়েস অ্যালগরিদমের LMD অংশ দ্বারা প্রশমিত হয়। LMD মানে "লেটেস্ট-মেসেজ-ড্রিভেন" এবং এটি প্রতিটি ভ্যালিডেটর দ্বারা রাখা একটি টেবিলকে বোঝায় যা অন্যান্য ভ্যালিডেটরদের কাছ থেকে প্রাপ্ত সর্বশেষ বার্তা ধারণ করে। সেই ক্ষেত্রটি শুধুমাত্র তখনই আপডেট করা হয় যদি নতুন বার্তাটি একটি নির্দিষ্ট ভ্যালিডেটরের জন্য টেবিলের মধ্যে থাকা স্লটের চেয়ে পরের স্লটের হয়। বাস্তবে, এর মানে হল যে প্রতিটি স্লটে, প্রাপ্ত প্রথম বার্তাটি গৃহীত হয় এবং যেকোনো অতিরিক্ত বার্তা উপেক্ষা করার জন্য ইকুইভোকেশন হয়। অন্যভাবে বলতে গেলে, কনসেন্সাস ক্লায়েন্টরা ইকুইভোকেশন গণনা করে না - তারা প্রতিটি ভ্যালিডেটরের কাছ থেকে প্রথম-আগত বার্তা ব্যবহার করে এবং ইকুইভোকেশনগুলি কেবল বাতিল করা হয়, যা অ্যাভাল্যাঞ্চ আক্রমণ প্রতিরোধ করে। + +ফর্ক চয়েস নিয়মে আরও বেশ কিছু সম্ভাব্য ভবিষ্যতের আপগ্রেড রয়েছে যা প্রোপোজার-বুস্ট দ্বারা প্রদত্ত নিরাপত্তায় যোগ করতে পারে। একটি হল [ভিউ-মার্জ](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), যেখানে অ্যাটেস্টররা একটি স্লটের শুরু হওয়ার `n` সেকেন্ড আগে ফর্ক চয়েসের তাদের ভিউ হিমায়িত করে এবং তারপর প্রস্তাবক নেটওয়ার্ক জুড়ে চেইনের ভিউ সিঙ্ক্রোনাইজ করতে সাহায্য করে। আরেকটি সম্ভাব্য আপগ্রেড হল [একক-স্লট ফাইনালিটি](https://notes.ethereum.org/@vbuterin/single_slot_finality), যা মাত্র একটি স্লটের পরে চেইনটি ফাইনাল করে বার্তা টাইমিংয়ের উপর ভিত্তি করে আক্রমণের বিরুদ্ধে রক্ষা করে। + +#### ফাইনালিটি ডিলে {#finality-delay} + +[একই গবেষণাপত্র](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf) যা প্রথম স্বল্প-মূল্যের একক ব্লক রিঅর্গ আক্রমণের বর্ণনা দিয়েছে, একটি ফাইনালিটি ডিলে (ওরফে “লাইভনেস ফেইলিওর”) আক্রমণও বর্ণনা করেছে যা আক্রমণকারীর একটি যুগ-সীমানা ব্লকের জন্য ব্লক প্রস্তাবক হওয়ার উপর নির্ভর করে। এটি অত্যন্ত গুরুত্বপূর্ণ কারণ এই যুগ সীমানা ব্লকগুলি ক্যাসপার এফএফজি চেইনের অংশগুলিকে চূড়ান্ত করার জন্য ব্যবহৃত চেকপয়েন্ট হয়ে ওঠে। আক্রমণকারী কেবল তাদের ব্লকটি ততক্ষণ পর্যন্ত আটকে রাখে যতক্ষণ না যথেষ্ট সৎ ভ্যালিডেটর তাদের FFG ভোটগুলি বর্তমান ফাইনালিটি লক্ষ্য হিসাবে পূর্ববর্তী যুগ-সীমানা ব্লকের পক্ষে ব্যবহার করে। তারপরে তারা তাদের আটকে রাখা ব্লক প্রকাশ করে। তারা তাদের ব্লককে প্রমাণ করে এবং বাকি সৎ ভ্যালিডেটররাও ভিন্ন ভিন্ন লক্ষ্য চেকপয়েন্ট সহ ফর্ক তৈরি করে। যদি তারা এটিকে ঠিক সময়ে সময় দেয়, তবে তারা ফাইনালিটি প্রতিরোধ করবে কারণ কোনো ফর্কের পক্ষে ২/৩ সুপারমেজরটি অ্যাটেস্ট করা হবে না। স্টেক যত ছোট হবে, সময় তত বেশি সুনির্দিষ্ট হতে হবে কারণ আক্রমণকারী সরাসরি কম অ্যাটেস্টেশন নিয়ন্ত্রণ করে, এবং আক্রমণকারীর একটি প্রদত্ত যুগ-সীমানা ব্লক প্রস্তাবকারী ভ্যালিডেটর নিয়ন্ত্রণ করার সম্ভাবনা তত কম। + +#### লং-রেঞ্জ আক্রমণ {#long-range-attacks} + +প্রুফ-অফ-স্টেক ব্লকচেইনগুলির জন্য নির্দিষ্ট একটি ধরনের আক্রমণও রয়েছে যা জেনেসিস ব্লকে অংশগ্রহণকারী একটি ভ্যালিডেটরকে জড়িত করে যা সৎ একের পাশাপাশি ব্লকচেইনের একটি পৃথক ফর্ক বজায় রাখে, অবশেষে সৎ ভ্যালিডেটর সেটকে অনেক পরে কোনো সুবিধাজনক সময়ে এটিতে স্যুইচ করতে রাজি করায়। এই ধরনের আক্রমণ ইথেরিয়ামে সম্ভব নয় কারণ ফাইনালিটি গ্যাজেট নিশ্চিত করে যে সমস্ত ভ্যালিডেটর নিয়মিত বিরতিতে (“চেকপয়েন্ট”) সৎ চেইনের অবস্থায় একমত। এই সহজ প্রক্রিয়াটি দীর্ঘ পরিসরের আক্রমণকারীদের নিরপেক্ষ করে কারণ ইথেরিয়াম ক্লায়েন্টরা কেবল ফাইনাল করা ব্লকগুলিকে রিঅর্গ করবে না। নেটওয়ার্কে যোগদানকারী নতুন নোডগুলি একটি বিশ্বস্ত সাম্প্রতিক স্টেট হ্যাশ (“[দুর্বল বিষয়ভিত্তিকতা](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) চেকপয়েন্ট”) খুঁজে বের করে এবং এটিকে একটি ছদ্ম-জেনেসিস ব্লক হিসাবে ব্যবহার করে যার উপরে তৈরি করা হয়। এটি একটি নতুন নোডের জন্য নেটওয়ার্কে প্রবেশের জন্য একটি ‘ট্রাস্ট গেটওয়ে’ তৈরি করে, তার আগে এটি নিজের জন্য তথ্য যাচাই করা শুরু করতে পারে। + +#### পরিষেবা অস্বীকার {#denial-of-service} + +ইথেরিয়ামের PoS প্রক্রিয়া প্রতিটি স্লটে মোট ভ্যালিডেটর সেট থেকে একটি একক ভ্যালিডেটরকে ব্লক প্রস্তাবক হিসাবে বেছে নেয়। এটি একটি সর্বজনীনভাবে পরিচিত ফাংশন ব্যবহার করে গণনা করা যেতে পারে এবং একজন প্রতিপক্ষের পক্ষে তাদের ব্লক প্রস্তাবনার সামান্য আগে পরবর্তী ব্লক প্রস্তাবককে সনাক্ত করা সম্ভব। তারপরে, আক্রমণকারী ব্লক প্রস্তাবককে স্প্যাম করতে পারে যাতে তারা তাদের সহকর্মীদের সাথে তথ্য আদান-প্রদান করতে না পারে। নেটওয়ার্কের বাকি অংশের কাছে, এটি মনে হবে যে ব্লক প্রস্তাবক অফলাইন ছিল এবং স্লটটি কেবল খালি যাবে। এটি নির্দিষ্ট ভ্যালিডেটরদের বিরুদ্ধে সেন্সরশিপের একটি রূপ হতে পারে, যা তাদের ব্লকচেইনে তথ্য যোগ করা থেকে বিরত রাখে। একক গোপন নেতা নির্বাচন (SSLE) বা অ-একক গোপন নেতা নির্বাচন বাস্তবায়ন করলে DoS ঝুঁকি কমবে কারণ শুধুমাত্র ব্লক প্রস্তাবকই জানেন যে তারা নির্বাচিত হয়েছেন এবং নির্বাচনটি আগে থেকে জানা যায় না। এটি এখনও বাস্তবায়িত হয়নি, তবে এটি [গবেষণা ও উন্নয়নের](https://ethresear.ch/t/secret-non-single-leader-election/11789) একটি সক্রিয় ক্ষেত্র। + +এই সবই এই সত্যের দিকে ইঙ্গিত করে যে অল্প স্টেক দিয়ে ইথেরিয়ামকে সফলভাবে আক্রমণ করা খুব কঠিন। এখানে বর্ণিত কার্যকর আক্রমণগুলির জন্য একটি আদর্শীকৃত ফর্ক-চয়েস অ্যালগরিদম, অসম্ভাব্য নেটওয়ার্ক শর্ত প্রয়োজন, অথবা আক্রমণ ভেক্টরগুলি ইতিমধ্যেই ক্লায়েন্ট সফ্টওয়্যারের তুলনামূলকভাবে ছোটখাটো প্যাচ দিয়ে বন্ধ করা হয়েছে। এটি, অবশ্যই, বন্য পরিবেশে জিরো-ডে থাকার সম্ভাবনাকে বাতিল করে না, তবে এটি একজন সংখ্যালঘু-স্টেক আক্রমণকারীকে কার্যকর হতে হলে প্রযুক্তিগত যোগ্যতা, কনসেন্সাস লেয়ার জ্ঞান এবং ভাগ্যের অত্যন্ত উচ্চ বার প্রদর্শন করে। একজন আক্রমণকারীর দৃষ্টিকোণ থেকে তাদের সেরা বাজি হতে পারে যতটা সম্ভব ইথার জমা করা এবং মোট স্টেকের একটি বৃহত্তর অনুপাত নিয়ে সশস্ত্র হয়ে ফিরে আসা। + +### মোট স্টেকের >= ৩৩% ব্যবহারকারী আক্রমণকারী {#attackers-with-33-stake} + +এই নিবন্ধে পূর্বে উল্লিখিত সমস্ত আক্রমণ সফল হওয়ার সম্ভাবনা বেশি যখন আক্রমণকারীর কাছে ভোট দেওয়ার জন্য আরও স্টেক করা ইথার থাকে, এবং আরও ভ্যালিডেটর থাকে যারা প্রতিটি স্লটে ব্লক প্রস্তাব করার জন্য নির্বাচিত হতে পারে। একটি বিদ্বেষপরায়ণ ভ্যালিডেটর তাই যতটা সম্ভব স্টেক করা ইথার নিয়ন্ত্রণ করার লক্ষ্য রাখতে পারে। + +স্টেক করা ইথারের ৩৩% একজন আক্রমণকারীর জন্য একটি বেঞ্চমার্ক কারণ এই পরিমাণের চেয়ে বেশি কিছু দিয়ে তাদের অন্য ভ্যালিডেটরদের ক্রিয়া সূক্ষ্মভাবে নিয়ন্ত্রণ না করেই চেইনটিকে চূড়ান্ত করা থেকে বিরত রাখার ক্ষমতা থাকে। তারা কেবল সবাই একসাথে অদৃশ্য হয়ে যেতে পারে। যদি স্টেক করা ইথারের ১/৩ বা তার বেশি বিদ্বেষপরায়ণভাবে অ্যাটেস্ট করে বা অ্যাটেস্ট করতে ব্যর্থ হয়, তাহলে একটি ২/৩ সুপারমেজরটি থাকতে পারে না এবং চেইনটি চূড়ান্ত হতে পারে না। এর বিরুদ্ধে প্রতিরক্ষা হল নিষ্ক্রিয়তা ফাঁস। নিষ্ক্রিয়তা ফাঁস সেই ভ্যালিডেটরদের সনাক্ত করে যারা অ্যাটেস্ট করতে ব্যর্থ হচ্ছে বা সংখ্যাগরিষ্ঠের বিরুদ্ধে অ্যাটেস্ট করছে। এই অ-অ্যাটেস্টিং ভ্যালিডেটরদের মালিকানাধীন স্টেক করা ইথার ধীরে ধীরে শেষ হয়ে যায় যতক্ষণ না অবশেষে তারা সম্মিলিতভাবে মোট স্টেকের ১/৩-এর কম প্রতিনিধিত্ব করে যাতে চেইনটি আবার ফাইনাল হতে পারে। + +নিষ্ক্রিয়তা ফাঁসের উদ্দেশ্য হল চেইনটিকে আবার চূড়ান্ত করা। তবে, আক্রমণকারী তাদের স্টেক করা ইথারের একটি অংশও হারায়। মোট স্টেক করা ইথারের ৩৩% প্রতিনিধিত্বকারী ভ্যালিডেটরদের মধ্যে ক্রমাগত নিষ্ক্রিয়তা খুব ব্যয়বহুল যদিও ভ্যালিডেটরদের স্ল্যাশ করা হয় না। + +ধরা যাক যে ইথেরিয়াম নেটওয়ার্কটি অ্যাসিঙ্ক্রোনাস (অর্থাৎ, মেসেজ পাঠানো এবং গ্রহণের মধ্যে বিলম্ব হয়), তাহলে মোট স্টেকের 34% নিয়ন্ত্রণকারী একজন আক্রমণকারী ডাবল ফাইনালিটি ঘটাতে পারে। এর কারণ হল আক্রমণকারী যখন ব্লক উৎপাদক হিসাবে নির্বাচিত হয় তখন ইকুইভোকেট করতে পারে, তারপর তাদের সমস্ত ভ্যালিডেটরদের সাথে ডাবল ভোট দিতে পারে। এটি এমন একটি পরিস্থিতি তৈরি করে যেখানে ব্লকচেইনের একটি ফর্ক বিদ্যমান, যার প্রত্যেকটির পক্ষে ৩৪% স্টেক করা ইথার ভোট দিচ্ছে। প্রতিটি ফর্কের জন্য বাকি ভ্যালিডেটরদের মাত্র ৫০% ভোট প্রয়োজন যাতে উভয় ফর্ক একটি সুপারমেজরটি দ্বারা সমর্থিত হয়, সেক্ষেত্রে উভয় চেইন চূড়ান্ত হতে পারে (কারণ আক্রমণকারীদের ভ্যালিডেটরদের ৩৪% + বাকি ৬৬%-এর অর্ধেক = প্রতিটি ফর্কে ৬৭%)। প্রতিযোগী ব্লকগুলিকে প্রায় ৫০% সৎ ভ্যালিডেটরদের দ্বারা গ্রহণ করতে হবে তাই এই আক্রমণটি তখনই কার্যকর যখন আক্রমণকারীর নেটওয়ার্ক জুড়ে বার্তা প্রচারের সময়কালের উপর কিছুটা নিয়ন্ত্রণ থাকে যাতে তারা প্রতিটি চেইনে অর্ধেক সৎ ভ্যালিডেটরকে ঠেলে দিতে পারে। আক্রমণকারীকে অবশ্যই এই ডাবল ফাইনালিটি অর্জনের জন্য তাদের সম্পূর্ণ স্টেক (আজকের ভ্যালিডেটর সেটের সাথে ~১০ মিলিয়ন ইথারের ৩৪%) ধ্বংস করতে হবে কারণ তাদের ভ্যালিডেটরদের ৩৪% একই সাথে ডাবল-ভোট দেবে - যা সর্বোচ্চ পারস্পরিক সম্পর্ক জরিমানার সাথে একটি স্ল্যাশযোগ্য অপরাধ। এই আক্রমণের বিরুদ্ধে প্রতিরক্ষা হল মোট স্টেক করা ইথারের ৩৪% ধ্বংস করার বিশাল খরচ। এই আক্রমণ থেকে পুনরুদ্ধার করার জন্য ইথেরিয়াম সম্প্রদায়কে “ব্যান্ডের বাইরে” সমন্বয় করতে হবে এবং একটি বা অন্য ফর্ক অনুসরণ করতে এবং অন্যটিকে উপেক্ষা করতে সম্মত হতে হবে। + +### মোট স্টেকের ~৫০% ব্যবহারকারী আক্রমণকারী {#attackers-with-50-stake} + +স্টেক করা ইথারের ৫০%-এ, ভ্যালিডেটরদের একটি দুষ্টু দল তাত্ত্বিকভাবে চেইনটিকে দুটি সমান আকারের ফর্কে বিভক্ত করতে পারে এবং তারপর কেবল তাদের সম্পূর্ণ ৫০% স্টেক সৎ ভ্যালিডেটর সেটের বিপরীতে ভোট দেওয়ার জন্য ব্যবহার করতে পারে, যার ফলে দুটি ফর্ক বজায় থাকে এবং ফাইনালিটি প্রতিরোধ করা যায়। উভয় ফর্কে নিষ্ক্রিয়তা ফাঁস অবশেষে উভয় চেইনকে চূড়ান্ত করতে পরিচালিত করবে। এই মুহূর্তে, একমাত্র বিকল্প হল একটি সামাজিক পুনরুদ্ধারের উপর নির্ভর করা। + +সৎ ভ্যালিডেটর সংখ্যা, নেটওয়ার্ক লেটেন্সি ইত্যাদিতে একটি নির্দিষ্ট মাত্রার প্রবাহের কারণে একটি প্রতিকূল দল ভ্যালিডেটররা ক্রমাগতভাবে মোট স্টেকের ঠিক ৫০% নিয়ন্ত্রণ করতে পারবে এমন সম্ভাবনা খুবই কম - এই ধরনের আক্রমণ মাউন্ট করার বিশাল খরচ এবং সাফল্যের কম সম্ভাবনার সাথে মিলিত হয়ে একজন যুক্তিসঙ্গত আক্রমণকারীর জন্য একটি শক্তিশালী অনীহা বলে মনে হয়, বিশেষ করে যখন _৫০%-এর বেশি_ অর্জনের জন্য একটি ছোট অতিরিক্ত বিনিয়োগ অনেক বেশি শক্তি আনলক করে। + +মোট স্টেকের >৫০%-এ আক্রমণকারী ফর্ক চয়েস অ্যালগরিদমে আধিপত্য বিস্তার করতে পারে। এই ক্ষেত্রে, আক্রমণকারী সংখ্যাগরিষ্ঠ ভোটের সাথে অ্যাটেস্ট করতে সক্ষম হবে, যা তাদের সৎ ক্লায়েন্টদের বোকা না বানিয়েই ছোট রিঅর্গ করার জন্য যথেষ্ট নিয়ন্ত্রণ দেবে। সৎ ভ্যালিডেটররা অনুসরণ করবে কারণ তাদের ফর্ক চয়েস অ্যালগরিদমও আক্রমণকারীর পছন্দের চেইনটিকে সবচেয়ে ভারী হিসাবে দেখবে, তাই চেইনটি চূড়ান্ত হতে পারে। এটি আক্রমণকারীকে নির্দিষ্ট লেনদেন সেন্সর করতে, স্বল্প-পরিসরের রিঅর্গ করতে এবং তাদের পক্ষে ব্লক পুনর্বিন্যাস করে সর্বাধিক MEV আহরণ করতে সক্ষম করে। এর বিরুদ্ধে প্রতিরক্ষা হল সংখ্যাগরিষ্ঠ স্টেকের বিশাল খরচ (বর্তমানে প্রায় $১৯ বিলিয়ন মার্কিন ডলার) যা একজন আক্রমণকারীর দ্বারা ঝুঁকিতে পড়ে কারণ সামাজিক লেয়ার সম্ভবত হস্তক্ষেপ করবে এবং একটি সৎ সংখ্যালঘু ফর্ক গ্রহণ করবে, যা আক্রমণকারীর স্টেককে নাটকীয়ভাবে অবমূল্যায়ন করবে। + +### মোট স্টেকের >=৬৬% ব্যবহারকারী আক্রমণকারী {#attackers-with-66-stake} + +৬৬% বা তার বেশি মোট স্টেক করা ইথার সহ একজন আক্রমণকারী কোনো সৎ ভ্যালিডেটরকে জোর না করেই তাদের পছন্দের চেইন চূড়ান্ত করতে পারে। আক্রমণকারী কেবল তাদের পছন্দের ফর্কের জন্য ভোট দিতে পারে এবং তারপর এটিকে চূড়ান্ত করতে পারে, কেবল কারণ তারা একটি অসৎ সুপারমেজরটি দিয়ে ভোট দিতে পারে। সুপারমেজরটি স্টেকহোল্ডার হিসাবে, আক্রমণকারী সর্বদা চূড়ান্ত ব্লকগুলির বিষয়বস্তু নিয়ন্ত্রণ করবে, খরচ করার, রিওয়াইন্ড করার এবং আবার খরচ করার, নির্দিষ্ট লেনদেন সেন্সর করার এবং ইচ্ছামত চেইন রিঅর্গ করার ক্ষমতা সহ। ৫১%-এর পরিবর্তে ৬৬% নিয়ন্ত্রণ করার জন্য অতিরিক্ত ইথার ক্রয় করে, আক্রমণকারী কার্যকরভাবে এক্স পোস্ট রিঅর্গ এবং ফাইনালিটি রিভার্সন করার ক্ষমতা কিনছে (অর্থাৎ, ভবিষ্যতের নিয়ন্ত্রণের পাশাপাশি অতীত পরিবর্তন করা)। এখানে একমাত্র আসল প্রতিরক্ষা হল মোট স্টেক করা ইথারের ৬৬%-এর বিশাল খরচ, এবং একটি বিকল্প ফর্ক গ্রহণের সমন্বয়ের জন্য সামাজিক লেয়ারে ফিরে যাওয়ার বিকল্প। আমরা পরবর্তী বিভাগে এটি আরও বিস্তারিতভাবে অন্বেষণ করতে পারি। + +## মানুষ: প্রতিরক্ষার শেষ লাইন {#people-the-last-line-of-defense} + +যদি অসৎ ভ্যালিডেটররা চেইনের তাদের পছন্দের সংস্করণটি চূড়ান্ত করতে সক্ষম হয়, তবে ইথেরিয়াম সম্প্রদায় একটি কঠিন পরিস্থিতিতে পড়ে। ক্যানোনিকাল চেইনে এর ইতিহাসে একটি অসৎ অংশ বেক করা থাকে, যখন সৎ ভ্যালিডেটররা একটি বিকল্প (সৎ) চেইন অ্যাটেস্ট করার জন্য শাস্তি পেতে পারে। মনে রাখবেন যে একটি চূড়ান্ত কিন্তু ভুল চেইন একটি সংখ্যাগরিষ্ঠ ক্লায়েন্টের একটি বাগ থেকেও উদ্ভূত হতে পারে। শেষ পর্যন্ত, চূড়ান্ত ফলব্যাক হল পরিস্থিতি সমাধানের জন্য সামাজিক লেয়ার - লেয়ার 0 - এর উপর নির্ভর করা। + +ইথেরিয়ামের PoS কনসেন্সাসের একটি শক্তি হল যে সম্প্রদায় একটি আক্রমণের মুখে [বিভিন্ন ধরনের প্রতিরক্ষামূলক কৌশল](https://youtu.be/1m12zgJ42dI?t=1712) ব্যবহার করতে পারে। একটি ন্যূনতম প্রতিক্রিয়া হতে পারে কোনো অতিরিক্ত জরিমানা ছাড়াই আক্রমণকারীদের ভ্যালিডেটরদের নেটওয়ার্ক থেকে জোরপূর্বক বের করে দেওয়া। নেটওয়ার্কে পুনরায় প্রবেশ করতে, আক্রমণকারীকে একটি অ্যাক্টিভেশন সারিতে যোগ দিতে হবে যা নিশ্চিত করে যে ভ্যালিডেটর সেট ধীরে ধীরে বৃদ্ধি পায়। উদাহরণস্বরূপ, স্টেক করা ইথারের পরিমাণ দ্বিগুণ করার জন্য যথেষ্ট ভ্যালিডেটর যোগ করতে প্রায় ২০০ দিন সময় লাগে, যা আক্রমণকারীকে আরেকটি ৫১% আক্রমণের চেষ্টা করার আগে সৎ ভ্যালিডেটরদের ২০০ দিন সময় দেয়। তবে, সম্প্রদায় আক্রমণকারীকে আরও কঠোরভাবে শাস্তি দেওয়ার সিদ্ধান্ত নিতে পারে, অতীতের পুরস্কার বাতিল করে বা তাদের স্টেক করা মূলধনের কিছু অংশ (১০০% পর্যন্ত) পুড়িয়ে দিয়ে। + +আক্রমণকারীর উপর যে শাস্তিই আরোপ করা হোক না কেন, সম্প্রদায়কে একসাথে সিদ্ধান্ত নিতে হবে যে অসৎ চেইনটি, ইথেরিয়াম ক্লায়েন্টগুলিতে কোড করা ফর্ক চয়েস অ্যালগরিদম দ্বারা পছন্দসই হওয়া সত্ত্বেও, প্রকৃতপক্ষে অবৈধ এবং সম্প্রদায়কে এর পরিবর্তে সৎ চেইনের উপরে তৈরি করা উচিত। সৎ ভ্যালিডেটররা সম্মিলিতভাবে ইথেরিয়াম ব্লকচেইনের একটি সম্প্রদায়-স্বীকৃত ফর্কের উপর ভিত্তি করে তৈরি করতে সম্মত হতে পারে যা, উদাহরণস্বরূপ, আক্রমণ শুরু হওয়ার আগে ক্যানোনিকাল চেইন থেকে ফর্ক হয়ে গেছে বা আক্রমণকারীদের ভ্যালিডেটরদের জোরপূর্বক অপসারণ করা হয়েছে। সৎ ভ্যালিডেটররা এই চেইনে তৈরি করতে উৎসাহিত হবে কারণ তারা আক্রমণকারীর চেইন অ্যাটেস্ট করতে (সঠিকভাবে) ব্যর্থ হওয়ার জন্য তাদের উপর প্রয়োগ করা জরিমানা এড়াতে পারবে। এক্সচেঞ্জ, অন-র‍্যাম্প এবং ইথেরিয়ামের উপর নির্মিত অ্যাপ্লিকেশনগুলি সম্ভবত সৎ চেইনে থাকতে পছন্দ করবে এবং সৎ ভ্যালিডেটরদের সৎ ব্লকচেইনে অনুসরণ করবে। + +যাইহোক, এটি একটি উল্লেখযোগ্য গভর্নেন্স চ্যালেঞ্জ হবে। কিছু ব্যবহারকারী এবং ভ্যালিডেটর নিঃসন্দেহে সৎ চেইনে ফিরে যাওয়ার ফলে ক্ষতিগ্রস্ত হবে, আক্রমণের পরে ভ্যালিডেট করা ব্লকগুলিতে লেনদেনগুলি সম্ভাব্যভাবে রোল ব্যাক করা যেতে পারে, অ্যাপ্লিকেশন লেয়ারকে ব্যাহত করতে পারে, এবং এটি বেশ সহজভাবে কিছু ব্যবহারকারীর নীতিকে দুর্বল করে যারা বিশ্বাস করে “কোডই আইন”। এক্সচেঞ্জ এবং অ্যাপ্লিকেশনগুলি সম্ভবত অফচেইন অ্যাকশনগুলিকে অনচেইন লেনদেনগুলির সাথে লিঙ্ক করেছে যা এখন রোল ব্যাক করা হতে পারে, যা প্রত্যাহার এবং সংশোধনের একটি ক্যাসকেড শুরু করবে যা ন্যায্যভাবে আনপিক করা কঠিন হবে, বিশেষ করে যদি অবৈধ লাভগুলি মিশ্রিত করা হয়, DeFi বা অন্যান্য ডেরিভেটিভগুলিতে জমা করা হয় যা সৎ ব্যবহারকারীদের জন্য মাধ্যমিক প্রভাব ফেলে। নিঃসন্দেহে কিছু ব্যবহারকারী, এমনকি প্রাতিষ্ঠানিকরাও, ইতিমধ্যেই অসৎ চেইন থেকে চতুরতার মাধ্যমে বা সৌভাগ্যক্রমে উপকৃত হয়েছে, এবং তাদের লাভ রক্ষার জন্য একটি ফর্কের বিরোধিতা করতে পারে। >৫১% আক্রমণের প্রতি সম্প্রদায়ের প্রতিক্রিয়া মহড়া দেওয়ার জন্য আহ্বান জানানো হয়েছে যাতে একটি সংবেদনশীল সমন্বিত প্রশমন দ্রুত কার্যকর করা যায়। Ethresearch.ch-এ Vitalik-এর কিছু দরকারী আলোচনা রয়েছে [এখানে](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) এবং [এখানে](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) এবং টুইটারে [এখানে](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw)। একটি সমন্বিত সামাজিক প্রতিক্রিয়ার লক্ষ্য হওয়া উচিত আক্রমণকারীকে শাস্তি দেওয়ার এবং অন্যান্য ব্যবহারকারীদের জন্য প্রভাব কমানোর বিষয়ে খুব লক্ষ্যবস্তু এবং নির্দিষ্ট হওয়া। + +গভর্নেন্স ইতিমধ্যেই একটি জটিল বিষয়। একটি অসৎ চূড়ান্তকরণ চেইনের প্রতি একটি লেয়ার-0 জরুরি প্রতিক্রিয়া পরিচালনা করা নিঃসন্দেহে ইথেরিয়াম সম্প্রদায়ের জন্য চ্যালেঞ্জিং হবে, তবে এটি ইথেরিয়ামের ইতিহাসে [ঘটেছে](/ethereum-forks/#dao-fork-summary) - [দুইবার](/ethereum-forks/#tangerine-whistle))। + +তবুও, মিটস্পেসে বসে থাকা চূড়ান্ত ফলব্যাকে মোটামুটি সন্তোষজনক কিছু রয়েছে। অবশেষে, আমাদের উপরে এই অসাধারণ প্রযুক্তির স্ট্যাক থাকা সত্ত্বেও, যদি সবচেয়ে খারাপ ঘটনাটি ঘটে তবে আসল মানুষদের এটি থেকে বেরিয়ে আসার জন্য সমন্বয় করতে হবে। + +## সারসংক্ষেপ {#summary} + +এই পৃষ্ঠাটি কিছু উপায় অন্বেষণ করেছে যেভাবে আক্রমণকারীরা ইথেরিয়ামের প্রুফ-অফ-স্টেক কনসেন্সাস প্রোটোকলকে কাজে লাগানোর চেষ্টা করতে পারে। মোট স্টেক করা ইথারের ক্রমবর্ধমান অনুপাত সহ আক্রমণকারীদের জন্য রিঅর্গ এবং ফাইনালিটি ডিলে অন্বেষণ করা হয়েছিল। সামগ্রিকভাবে, একজন ধনী আক্রমণকারীর সাফল্যের সম্ভাবনা বেশি কারণ তাদের স্টেক ভোটের ক্ষমতায় রূপান্তরিত হয় যা তারা ভবিষ্যতের ব্লকগুলির বিষয়বস্তুকে প্রভাবিত করতে ব্যবহার করতে পারে। স্টেক করা ইথারের নির্দিষ্ট থ্রেশহোল্ড পরিমাণে, আক্রমণকারীর ক্ষমতা স্তর বৃদ্ধি পায়: + +৩৩%: ফাইনালিটি ডিলে + +৩৪%: ফাইনালিটি ডিলে, ডাবল ফাইনালিটি + +৫১%: ফাইনালিটি ডিলে, ডাবল ফাইনালিটি, সেন্সরশিপ, ব্লকচেইন ভবিষ্যতের উপর নিয়ন্ত্রণ + +৬৬%: ফাইনালিটি ডিলে, ডাবল ফাইনালিটি, সেন্সরশিপ, ব্লকচেইন ভবিষ্যত এবং অতীতের উপর নিয়ন্ত্রণ + +এছাড়াও আরও কিছু অত্যাধুনিক আক্রমণ রয়েছে যার জন্য অল্প পরিমাণে স্টেক করা ইথারের প্রয়োজন হয় কিন্তু একজন খুব অত্যাধুনিক আক্রমণকারীর উপর নির্ভর করে যা সৎ ভ্যালিডেটর সেটকে তাদের পক্ষে প্রভাবিত করার জন্য বার্তা টাইমিংয়ের উপর সূক্ষ্ম নিয়ন্ত্রণ রাখে। + +সামগ্রিকভাবে, এই সম্ভাব্য আক্রমণ ভেক্টর সত্ত্বেও একটি সফল আক্রমণের ঝুঁকি কম, অবশ্যই প্রুফ-অফ-ওয়ার্ক সমতুল্যের চেয়ে কম। এর কারণ হল স্টেক করা ইথারের বিশাল খরচ যা একজন আক্রমণকারীর দ্বারা ঝুঁকিতে পড়ে যা তাদের ভোটের ক্ষমতা দিয়ে সৎ ভ্যালিডেটরদের অভিভূত করার লক্ষ্য রাখে। অন্তর্নির্মিত “গাজর এবং লাঠি” প্রণোদনা স্তরটি বেশিরভাগ অসদাচরণের বিরুদ্ধে রক্ষা করে, বিশেষ করে কম-স্টেক আক্রমণকারীদের জন্য। আরও সূক্ষ্ম বাউন্সিং এবং ব্যালান্সিং আক্রমণগুলিও সফল হওয়ার সম্ভাবনা কম কারণ বাস্তব নেটওয়ার্ক শর্তগুলি ভ্যালিডেটরদের নির্দিষ্ট উপসেটগুলিতে বার্তা সরবরাহের সূক্ষ্ম নিয়ন্ত্রণ অর্জন করা খুব কঠিন করে তোলে এবং ক্লায়েন্ট দলগুলি দ্রুত পরিচিত বাউন্সিং, ব্যালান্সিং এবং অ্যাভাল্যাঞ্চ আক্রমণ ভেক্টরগুলি সাধারণ প্যাচ দিয়ে বন্ধ করে দিয়েছে। + +৩৪%, ৫১% বা ৬৬% আক্রমণের জন্য সম্ভবত সমাধানের জন্য ব্যান্ডের বাইরের সামাজিক সমন্বয়ের প্রয়োজন হবে। যদিও এটি সম্প্রদায়ের জন্য বেদনাদায়ক হতে পারে, তবে ব্যান্ডের বাইরে প্রতিক্রিয়া জানানোর একটি সম্প্রদায়ের ক্ষমতা একজন আক্রমণকারীর জন্য একটি শক্তিশালী অনীহা। ইথেরিয়াম সামাজিক লেয়ার হল চূড়ান্ত ব্যাকস্টপ - একটি প্রযুক্তিগতভাবে সফল আক্রমণ এখনও সম্প্রদায় একটি সৎ ফর্ক গ্রহণ করতে সম্মত হয়ে নিষ্ক্রিয় করা যেতে পারে। এটি আক্রমণকারী এবং ইথেরিয়াম সম্প্রদায়ের মধ্যে একটি প্রতিযোগিতা হবে - একটি 66% আক্রমণের জন্য ব্যয় করা বিলিয়ন ডলার সম্ভবত একটি সফল সামাজিক সমন্বয় আক্রমণের মাধ্যমে নিশ্চিহ্ন হয়ে যাবে যদি এটি যথেষ্ট দ্রুত সম্পন্ন করা হয়, যা আক্রমণকারীকে ইথেরিয়াম সম্প্রদায় দ্বারা উপেক্ষা করা একটি পরিচিত অসৎ চেইনে ইলিকুইড স্টেকড ইথারের ভারী ব্যাগসহ রেখে দেবে। এটি আক্রমণকারীর জন্য লাভজনক হওয়ার সম্ভাবনা যথেষ্ট কম যা একটি কার্যকর প্রতিরোধক হিসাবে কাজ করে। এই কারণেই শক্তভাবে সারিবদ্ধ মান সহ একটি সুসংহত সামাজিক স্তর বজায় রাখার জন্য বিনিয়োগ এত গুরুত্বপূর্ণ। + +## আরও পড়ুন {#further-reading} + +- [এই পৃষ্ঠার আরও বিস্তারিত সংস্করণ](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [নিষ্পত্তির ফাইনালিটি বিষয়ে ভিটালিক](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [LMD GHOST গবেষণাপত্র](https://arxiv.org/abs/2003.03052) +- [Casper-FFG পেপার](https://arxiv.org/abs/1710.09437) +- [গ্যাসপার গবেষণাপত্র](https://arxiv.org/pdf/2003.03052.pdf) +- [প্রস্তাবকের ওজন বুস্টিং কনসেন্সাস স্পেকস](https://github.com/ethereum/consensus-specs/pull/2730) +- [ethresear.ch-এ বাউন্সিং আক্রমণ](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) +- [SSLE গবেষণা](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..09ec379b4eb --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "প্রত্যয়নসমূহ" +description: "প্রুফ-অফ-স্টেক ইথেরিয়ামের উপর প্রত্যয়নসমূহের একটি বিবরণ।" +lang: bn +--- + +একজন ভ্যালিডেটরের থেকে প্রতিটি ইপকে একটি প্রত্যয়ন তৈরি, স্বাক্ষর এবং ব্রডকাস্ট করার আশা করা হয়। এই পৃষ্ঠাটি রূপরেখা দেয় যে এই প্রত্যয়নসমূহ দেখতে কেমন এবং কীভাবে সেগুলি কনসেন্সাস ক্লায়েন্টদের মধ্যে প্রক্রিয়া করা হয় এবং যোগাযোগ করা হয়। + +## প্রত্যয়ন কী? {#what-is-an-attestation} + +প্রতিটি [ইপকে](/glossary/#epoch) (6.4 মিনিট) একজন ভ্যালিডেটর নেটওয়ার্কে একটি প্রত্যয়ন প্রস্তাব করেন। প্রত্যয়নটি ইপকের একটি নির্দিষ্ট স্লটের জন্য। প্রত্যয়নের উদ্দেশ্য হল ভ্যালিডেটরের চেইনের দৃষ্টিভঙ্গির পক্ষে ভোট দেওয়া, বিশেষ করে সবচেয়ে সাম্প্রতিক জাস্টিফাইড ব্লক এবং বর্তমান ইপকের প্রথম ব্লক (`সোর্স` এবং `টার্গেট` চেকপয়েন্ট হিসাবে পরিচিত)। এই তথ্যটি সমস্ত অংশগ্রহণকারী ভ্যালিডেটরদের জন্য একত্রিত করা হয়, যা নেটওয়ার্ককে ব্লকচেইনের স্টেট সম্পর্কে কনসেন্সাসে পৌঁছাতে সক্ষম করে। + +প্রত্যয়নটিতে নিম্নলিখিত উপাদানগুলি রয়েছে: + +- `aggregation_bits`: ভ্যালিডেটরদের একটি বিটলিস্ট যেখানে অবস্থানটি তাদের কমিটিতে ভ্যালিডেটর সূচকে ম্যাপ করে; মান (0/1) নির্দেশ করে যে ভ্যালিডেটর `data`-তে স্বাক্ষর করেছেন কিনা (অর্থাৎ, তারা সক্রিয় কিনা এবং ব্লক প্রোপোজারের সাথে একমত কিনা) +- `data`: প্রত্যয়ন সম্পর্কিত বিবরণ, যেমনটি নীচে সংজ্ঞায়িত করা হয়েছে +- `signature`: একটি BLS সিগনেচার যা স্বতন্ত্র ভ্যালিডেটরদের সিগনেচার একত্রিত করে + +একটি প্রত্যয়নকারী ভ্যালিডেটরের জন্য প্রথম কাজ হল `data` তৈরি করা। `data`-তে নিম্নলিখিত তথ্য রয়েছে: + +- `slot`: যে স্লট নম্বরটিকে প্রত্যয়নটি উল্লেখ করে +- `index`: একটি সংখ্যা যা চিহ্নিত করে যে একটি প্রদত্ত স্লটে ভ্যালিডেটর কোন কমিটির অন্তর্গত +- `beacon_block_root`: চেইনের শীর্ষে ভ্যালিডেটর যে ব্লকটি দেখেন তার রুট হ্যাস (ফর্ক-চয়েস অ্যালগরিদম প্রয়োগের ফল) +- `source`: ফাইনালিটি ভোটের অংশ যা নির্দেশ করে যে ভ্যালিডেটররা সবচেয়ে সাম্প্রতিক জাস্টিফাইড ব্লক হিসাবে কী দেখছেন +- `target`: ফাইনালিটি ভোটের অংশ যা নির্দেশ করে যে ভ্যালিডেটররা বর্তমান ইপকের প্রথম ব্লক হিসাবে কী দেখছেন + +`data` তৈরি হয়ে গেলে, ভ্যালিডেটর তাদের অংশগ্রহণের প্রমাণস্বরূপ `aggregation_bits`-এ তাদের নিজস্ব ভ্যালিডেটর সূচকের সাথে সঙ্গতিপূর্ণ বিটটি 0 থেকে 1-এ ফ্লিপ করতে পারেন। + +অবশেষে, ভ্যালিডেটর প্রত্যয়নটিতে স্বাক্ষর করে এবং এটি নেটওয়ার্কে ব্রডকাস্ট করে। + +### একত্রিত প্রত্যয়ন {#aggregated-attestation} + +প্রতিটি ভ্যালিডেটরের জন্য নেটওয়ার্কের চারপাশে এই ডেটা পাস করার সাথে একটি উল্লেখযোগ্য ওভারহেড জড়িত। অতএব, স্বতন্ত্র ভ্যালিডেটরদের থেকে প্রত্যয়নসমূহ আরও ব্যাপকভাবে ব্রডকাস্ট করার আগে সাবনেটের মধ্যে একত্রিত করা হয়। এর মধ্যে সিগনেচারগুলিকে একত্রিত করাও অন্তর্ভুক্ত রয়েছে যাতে একটি প্রত্যয়ন যা ব্রডকাস্ট করা হয় তাতে কনসেন্সাস `data` এবং সেই `data`-এর সাথে একমত সমস্ত ভ্যালিডেটরদের সিগনেচার একত্রিত করে গঠিত একটি একক সিগনেচার থাকে। এটি `aggregation_bits` ব্যবহার করে পরীক্ষা করা যেতে পারে কারণ এটি তাদের কমিটিতে প্রতিটি ভ্যালিডেটরের সূচক প্রদান করে (যার আইডি `data`-তে প্রদান করা হয়) যা স্বতন্ত্র সিগনেচারগুলি জিজ্ঞাসা করতে ব্যবহার করা যেতে পারে। + +প্রতিটি ইপকে প্রতিটি সাবনেটে 16 জন ভ্যালিডেটরকে `aggregators` হিসাবে নির্বাচিত করা হয়। অ্যাগ্রিগেটররা গসিপ নেটওয়ার্কের মাধ্যমে শোনা সমস্ত প্রত্যয়ন সংগ্রহ করে যেগুলির `data` তাদের নিজস্ব ডেটার সমতুল্য। প্রতিটি ম্যাচিং প্রত্যয়নের প্রেরককে `aggregation_bits`-এ রেকর্ড করা হয়। অ্যাগ্রিগেটররা তারপর প্রত্যয়নের সমষ্টিটিকে বৃহত্তর নেটওয়ার্কে ব্রডকাস্ট করে। + +যখন একজন ভ্যালিডেটরকে ব্লক প্রোপোজার হিসাবে নির্বাচিত করা হয়, তখন তারা নতুন ব্লকের সর্বশেষ স্লট পর্যন্ত সাবনেট থেকে সমষ্টিগত প্রত্যয়নসমূহ প্যাকেজ করে। + +### প্রত্যয়ন অন্তর্ভুক্তির জীবনচক্র {#attestation-inclusion-lifecycle} + +1. জেনারেসন +2. বিস্তার +3. একত্রীকরণ +4. বিস্তার +5. অন্তর্ভুক্তি + +প্রত্যয়নের জীবনচক্রটি নীচের পরিকল্পিত চিত্রে রূপরেখা দেওয়া হয়েছে: + +![প্রত্যয়নের জীবনচক্র](./attestation_schematic.png) + +## পুরস্কার {#rewards} + +ভ্যালিডেটররা প্রত্যয়ন জমা দেওয়ার জন্য পুরস্কৃত হন। প্রত্যয়নের পুরস্কার অংশগ্রহণের ফ্ল্যাগ (সোর্স, টার্গেট এবং হেড), বেস রিওয়ার্ড এবং অংশগ্রহণের হারের উপর নির্ভর করে। + +জমা দেওয়া প্রত্যয়ন এবং এর অন্তর্ভুক্তি বিলম্বের উপর নির্ভর করে অংশগ্রহণের প্রতিটি ফ্ল্যাগ সত্য বা মিথ্যা হতে পারে। + +সেরা পরিস্থিতিটি ঘটে যখন তিনটি ফ্ল্যাগই সত্য হয়, সেক্ষেত্রে একজন ভ্যালিডেটর উপার্জন করবেন (প্রতিটি সঠিক ফ্ল্যাগের জন্য): + +`রিওয়ার্ড += বেস রিওয়ার্ড * ফ্ল্যাগ ওয়েট * ফ্ল্যাগ অ্যাটেস্টিং রেট / 64` + +ফ্ল্যাগ অ্যাটেস্টিং রেট পরিমাপ করা হয় প্রদত্ত ফ্ল্যাগের জন্য সমস্ত অ্যাটেস্টিং ভ্যালিডেটরের কার্যকর ব্যালেন্সের যোগফলকে মোট সক্রিয় কার্যকর ব্যালেন্সের সাথে তুলনা করে। + +### বেস রিওয়ার্ড {#base-reward} + +বেস রিওয়ার্ড গণনা করা হয় অ্যাটেস্টিং ভ্যালিডেটরের সংখ্যা এবং তাদের কার্যকর স্টেক করা ইথার ব্যালেন্স অনুযায়ী: + +`বেস রিওয়ার্ড = ভ্যালিডেটর কার্যকর ব্যালেন্স x 2^6 / SQRT(সমস্ত সক্রিয় ভ্যালিডেটরের কার্যকর ব্যালেন্স)` + +#### অন্তর্ভুক্তি বিলম্ব {#inclusion-delay} + +যে সময়ে ভ্যালিডেটররা চেইনের শীর্ষে (`ব্লক n`) ভোট দিয়েছিলেন, তখন `ব্লক n+1` এখনও প্রস্তাব করা হয়নি। অতএব প্রত্যয়নসমূহ স্বাভাবিকভাবেই **এক ব্লক পরে** অন্তর্ভুক্ত হয় তাই `ব্লক n` চেইনের হেড হওয়ার পক্ষে ভোট দেওয়া সমস্ত প্রত্যয়ন `ব্লক n+1`-এ অন্তর্ভুক্ত হয় এবং, **অন্তর্ভুক্তি বিলম্ব** 1 হয়। যদি অন্তর্ভুক্তি বিলম্ব দ্বিগুণ হয়ে দুটি স্লটে পৌঁছায়, তবে প্রত্যয়নের পুরস্কার অর্ধেক হয়ে যায়, কারণ প্রত্যয়নের পুরস্কার গণনা করতে বেস রিওয়ার্ডকে অন্তর্ভুক্তি বিলম্বের অন্যোন্যক দ্বারা গুণ করা হয়। + +### প্রত্যয়নের পরিস্থিতি {#attestation-scenarios} + +#### অনুপস্থিত ভোটিং ভ্যালিডেটর {#missing-voting-validator} + +ভ্যালিডেটরদের তাদের প্রত্যয়ন জমা দেওয়ার জন্য সর্বোচ্চ 1 ইপক সময় থাকে। যদি ইপক 0-তে প্রত্যয়নটি মিস হয়ে যায়, তবে তারা এটি ইপক 1-এ অন্তর্ভুক্তি বিলম্বের সাথে জমা দিতে পারে। + +#### অনুপস্থিত অ্যাগ্রিগেটর {#missing-aggregator} + +মোট প্রতি ইপকে 16 জন অ্যাগ্রিগেটর থাকে। এছাড়াও, র‍্যান্ডম ভ্যালিডেটররা **256 ইপকের জন্য দুটি সাবনেটে** সাবস্ক্রাইব করে এবং অ্যাগ্রিগেটর অনুপস্থিত থাকলে ব্যাকআপ হিসাবে কাজ করে। + +#### অনুপস্থিত ব্লক প্রোপোজার {#missing-block-proposer} + +মনে রাখবেন যে কিছু ক্ষেত্রে একজন ভাগ্যবান অ্যাগ্রিগেটরও ব্লক প্রোপোজার হতে পারে। যদি ব্লক প্রোপোজার অনুপস্থিত থাকার কারণে প্রত্যয়নটি অন্তর্ভুক্ত না করা হয়, তবে পরবর্তী ব্লক প্রোপোজার একত্রিত প্রত্যয়নটি তুলে নিয়ে পরবর্তী ব্লকে অন্তর্ভুক্ত করবে। তবে, **অন্তর্ভুক্তি বিলম্ব** এক বেড়ে যাবে। + +## আরও পড়ুন {#further-reading} + +- [ভিটালিকের অ্যানোটেটেড কনসেন্সাস স্পেকে প্রত্যয়নসমূহ](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [eth2book.info-তে প্রত্যয়নসমূহ](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন যা আপনাকে সাহায্য করেছে? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যোগ করুন!_ diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..d867beffdec --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "ব্লক প্রস্তাব" +description: "প্রুফ-অফ-স্টেক ইথেরিয়ামে কীভাবে ব্লক প্রস্তাব করা হয় তার ব্যাখ্যা।" +lang: bn +--- + +ব্লকগুলো হল ব্লকচেইনের মৌলিক একক। ব্লকগুলো হল তথ্যের বিচ্ছিন্ন একক যা নোডগুলোর মধ্যে আদান-প্রদান করা হয়, সম্মত হয় এবং প্রতিটি নোডের ডেটাবেসে যোগ করা হয়। এই পেজটি ব্যাখ্যা করে কীভাবে সেগুলি তৈরি করা হয়। + +## পূর্বশর্ত {#prerequisites} + +ব্লক প্রস্তাব প্রুফ-অফ-স্টেক প্রোটোকলের একটি অংশ। এই পেজটি বুঝতে সাহায্য করার জন্য, আমরা আপনাকে [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) এবং [ব্লক আর্কিটেকচার](/developers/docs/blocks/) সম্পর্কে পড়ার পরামর্শ দিই। + +## কারা ব্লক তৈরি করে? {#who-produces-blocks} + +ভ্যালিডেটর অ্যাকাউন্টগুলি ব্লক প্রস্তাব করে। ভ্যালিডেটর অ্যাকাউন্টগুলি নোড অপারেটরদের দ্বারা পরিচালিত হয় যারা তাদের এক্সিকিউশন এবং কনসেন্সাস ক্লায়েন্ট-এর অংশ হিসাবে ভ্যালিডেটর সফ্টওয়্যার চালায় এবং ডিপোজিট চুক্তিতে কমপক্ষে 32 ETH জমা করেছে। তবে, প্রতিটি ভ্যালিডেটর শুধুমাত্র মাঝে মাঝে একটি ব্লক প্রস্তাব করার জন্য দায়ী থাকে। ইথেরিয়াম স্লট এবং ইপোক-এ সময় পরিমাপ করে। প্রতিটি স্লট বারো সেকেন্ডের, এবং 32টি স্লট (6.4 মিনিট) মিলে একটি ইপোক তৈরি করে। প্রতিটি স্লট ইথেরিয়ামে একটি নতুন ব্লক যোগ করার একটি সুযোগ। + +### র‍্যান্ডম নির্বাচন {#random-selection} + +প্রতিটি স্লটে একটি ব্লক প্রস্তাব করার জন্য একজন একক ভ্যালিডেটর সিউডো-র‍্যান্ডমভাবে নির্বাচিত হয়। একটি ব্লকচেইনে প্রকৃত র‍্যান্ডমনেসের মতো কিছু নেই কারণ যদি প্রতিটি নোড প্রকৃত র‍্যান্ডম সংখ্যা তৈরি করত, তবে তারা কনসেন্সাসে আসতে পারত না। এর পরিবর্তে, লক্ষ্য হল ভ্যালিডেটর নির্বাচন প্রক্রিয়াটিকে অপ্রত্যাশিত করে তোলা। ইথেরিয়ামে র‍্যান্ডমনেস অর্জন করা হয় RANDAO নামক একটি অ্যালগরিদম ব্যবহার করে যা ব্লক প্রস্তাবকের থেকে একটি হ্যাসকে একটি সিডের সাথে মিশ্রিত করে যা প্রতিটি ব্লকে আপডেট করা হয়। এই মানটি মোট ভ্যালিডেটর সেট থেকে একটি নির্দিষ্ট ভ্যালিডেটর নির্বাচন করতে ব্যবহৃত হয়। নির্দিষ্ট ধরণের সিড ম্যানিপুলেশনের বিরুদ্ধে সুরক্ষার একটি উপায় হিসাবে ভ্যালিডেটর নির্বাচন দুই ইপোক আগে থেকে স্থির করা হয়। + +যদিও ভ্যালিডেটররা প্রতিটি স্লটে RANDAO-তে যোগ করে, গ্লোবাল RANDAO মান প্রতি ইপোকে শুধুমাত্র একবার আপডেট করা হয়। পরবর্তী ব্লক প্রস্তাবকের সূচক গণনা করার জন্য, প্রতিটি স্লটে একটি অনন্য মান দিতে RANDAO মান স্লট নম্বরের সাথে মিশ্রিত করা হয়। একজন স্বতন্ত্র ভ্যালিডেটর নির্বাচিত হওয়ার সম্ভাবনা কেবল `1/N` নয় (যেখানে `N` = মোট সক্রিয় ভ্যালিডেটর)। এর পরিবর্তে, এটি প্রতিটি ভ্যালিডেটরের কার্যকর ETH ব্যালেন্স দ্বারা ওজনযুক্ত হয়। সর্বোচ্চ কার্যকর ব্যালেন্স হল 32 ETH (এর মানে হল `ব্যালেন্স < 32 ETH` হলে `ব্যালেন্স == 32 ETH`-এর চেয়ে কম ওজন হয়, কিন্তু `ব্যালেন্স > 32 ETH` হলে `ব্যালেন্স == 32 ETH`-এর চেয়ে বেশি ওজন হয় না)। + +প্রতিটি স্লটে শুধুমাত্র একজন ব্লক প্রস্তাবক নির্বাচিত হয়। স্বাভাবিক পরিস্থিতিতে, একজন একক ব্লক প্রযোজক তাদের নিবেদিত স্লটে একটি একক ব্লক তৈরি করে এবং প্রকাশ করে। একই স্লটের জন্য দুটি ব্লক তৈরি করা একটি স্ল্যাশযোগ্য অপরাধ, যা প্রায়শই "ইকুইভোকেশন" নামে পরিচিত। + +## ব্লকটি কীভাবে তৈরি করা হয়? {#how-is-a-block-created} + +ব্লক প্রস্তাবকের একটি স্বাক্ষরিত বীকন ব্লক সম্প্রচার করার কথা যা তাদের স্থানীয়ভাবে চালিত ফর্ক পছন্দ অ্যালগরিদমের দৃষ্টিভঙ্গি অনুসারে চেইনের সবচেয়ে সাম্প্রতিক হেডের উপরে তৈরি হয়। ফর্ক পছন্দ অ্যালগরিদম পূর্ববর্তী স্লট থেকে অবশিষ্ট থাকা যেকোনো সারিবদ্ধ অ্যাটেস্টেশন প্রয়োগ করে, তারপর তার ইতিহাসে অ্যাটেস্টেশনের সর্বাধিক সঞ্চিত ওজনসহ ব্লকটি খুঁজে বের করে। সেই ব্লকটি হল প্রস্তাবক দ্বারা তৈরি করা নতুন ব্লকের প্যারেন্ট। + +ব্লক প্রস্তাবক তার নিজস্ব স্থানীয় ডেটাবেস এবং চেইনের ভিউ থেকে ডেটা সংগ্রহ করে একটি ব্লক তৈরি করে। ব্লকের বিষয়বস্তু নীচের স্নিপেটে দেখানো হয়েছে: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +`randao_reveal` ফিল্ড একটি যাচাইযোগ্য র‍্যান্ডম মান নেয় যা ব্লক প্রস্তাবক বর্তমান ইপোক নম্বর স্বাক্ষর করে তৈরি করে। `eth1_data` হল ডিপোজিট চুক্তির বিষয়ে ব্লক প্রস্তাবকের দৃষ্টিভঙ্গির জন্য একটি ভোট, যার মধ্যে ডিপোজিট মার্কল ট্রাই-এর রুট এবং মোট ডিপোজিটের সংখ্যা অন্তর্ভুক্ত রয়েছে যা নতুন ডিপোজিট যাচাই করতে সক্ষম করে। `graffiti` একটি ঐচ্ছিক ফিল্ড যা ব্লকে একটি বার্তা যোগ করতে ব্যবহার করা যেতে পারে। `proposer_slashings` এবং `attester_slashings` হল এমন ফিল্ড যেগুলিতে প্রমাণ থাকে যে প্রস্তাবকের চেইন দেখার দৃষ্টিভঙ্গি অনুসারে নির্দিষ্ট ভ্যালিডেটররা স্ল্যাশযোগ্য অপরাধ করেছে। `deposits` হল নতুন ভ্যালিডেটর ডিপোজিটের একটি তালিকা যা সম্পর্কে ব্লক প্রস্তাবক সচেতন, এবং `voluntary_exits` হল এমন ভ্যালিডেটরদের একটি তালিকা যারা প্রস্থান করতে চায়, যাদের সম্পর্কে ব্লক প্রস্তাবক কনসেন্সাস লেয়ার গসিপ নেটওয়ার্কে শুনেছে। `sync_aggregate` হল একটি ভেক্টর যা দেখায় কোন ভ্যালিডেটরদের আগে একটি সিঙ্ক কমিটিতে (ভ্যালিডেটরদের একটি উপসেট যা লাইট ক্লায়েন্ট ডেটা পরিবেশন করে) নিযুক্ত করা হয়েছিল এবং ডেটা স্বাক্ষরে অংশ নিয়েছিল। + +`execution_payload` এক্সিকিউশন এবং কনসেন্সাস ক্লায়েন্টদের মধ্যে লেনদেন সম্পর্কিত তথ্য পাস করতে সক্ষম করে। `execution_payload` হল এক্সিকিউশন ডেটার একটি ব্লক যা একটি বীকন ব্লকের ভিতরে নেস্টেড থাকে। `execution_payload`-এর ভিতরের ফিল্ডগুলি ইথেরিয়াম ইয়োলো পেপারে বর্ণিত ব্লক কাঠামোকে প্রতিফলিত করে, তবে এতে কোনো অমার্স নেই এবং `difficulty`-এর পরিবর্তে `prev_randao` বিদ্যমান। এক্সিকিউশন ক্লায়েন্টের লেনদেনের একটি স্থানীয় পুলে অ্যাক্সেস রয়েছে যা সে তার নিজস্ব গসিপ নেটওয়ার্কে শুনেছে। এই লেনদেনগুলি স্থানীয়ভাবে কার্যকর করা হয় একটি আপডেট করা স্টেট ট্রাই তৈরি করতে যা পোস্ট-স্টেট নামে পরিচিত। লেনদেনগুলি `execution_payload`-এ `transactions` নামক একটি তালিকা হিসাবে অন্তর্ভুক্ত করা হয় এবং পোস্ট-স্টেট `state-root` ফিল্ডে সরবরাহ করা হয়। + +এই সমস্ত ডেটা একটি বীকন ব্লকে সংগ্রহ করা হয়, স্বাক্ষরিত হয়, এবং ব্লক প্রস্তাবকের পিয়ারদের কাছে সম্প্রচার করা হয়, যারা এটিকে তাদের পিয়ারদের কাছে প্রচার করে ইত্যাদি। + +[ব্লকের অ্যানাটমি](/developers/docs/blocks) সম্পর্কে আরও পড়ুন। + +## ব্লকের কী হয়? {#what-happens-to-blocks} + +ব্লকটি ব্লক প্রস্তাবকের স্থানীয় ডেটাবেসে যোগ করা হয় এবং কনসেন্সাস লেয়ার গসিপ নেটওয়ার্কের মাধ্যমে পিয়ারদের কাছে সম্প্রচার করা হয়। যখন একজন ভ্যালিডেটর ব্লকটি গ্রহণ করে, তখন সে এর ভিতরের ডেটা যাচাই করে, যার মধ্যে রয়েছে ব্লকটির সঠিক প্যারেন্ট আছে কিনা, সঠিক স্লটের সাথে মিলে যায় কিনা, প্রস্তাবকের সূচকটি প্রত্যাশিত কিনা, RANDAO রিভিল বৈধ কিনা এবং প্রস্তাবক স্ল্যাশড হয়নি কিনা তা পরীক্ষা করা। `execution_payload` আনবান্ডেল করা হয়, এবং ভ্যালিডেটরের এক্সিকিউশন ক্লায়েন্ট প্রস্তাবিত স্টেট পরিবর্তন পরীক্ষা করার জন্য তালিকার লেনদেনগুলি পুনরায় কার্যকর করে। ধরে নেওয়া হয় যে ব্লকটি এই সমস্ত পরীক্ষায় উত্তীর্ণ হয়েছে, প্রতিটি ভ্যালিডেটর ব্লকটিকে তার নিজস্ব ক্যানোনিকাল চেইনে যোগ করে। প্রক্রিয়াটি তারপর পরবর্তী স্লটে আবার শুরু হয়। + +## ব্লক রিওয়ার্ডস {#block-rewards} + +ব্লক প্রস্তাবক তাদের কাজের জন্য পেমেন্ট পায়। সক্রিয় ভ্যালিডেটরের সংখ্যা এবং তাদের কার্যকর ব্যালেন্সের একটি ফাংশন হিসাবে একটি `base_reward` গণনা করা হয়। ব্লক প্রস্তাবক তারপর ব্লকে অন্তর্ভুক্ত প্রতিটি বৈধ অ্যাটেস্টেশনের জন্য `base_reward`-এর একটি ভগ্নাংশ পায়; যত বেশি ভ্যালিডেটর ব্লকটিকে অ্যাটেস্ট করে, ব্লক প্রস্তাবকের রিওয়ার্ড তত বেশি হয়। যে ভ্যালিডেটরদের স্ল্যাশ করা উচিত তাদের রিপোর্ট করার জন্যও একটি রিওয়ার্ড রয়েছে, যা প্রতিটি স্ল্যাশড ভ্যালিডেটরের জন্য `1/512 * কার্যকর ব্যালেন্স`-এর সমান। + +[রিওয়ার্ড এবং পেনাল্টি সম্পর্কে আরও](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## আরও পড়ুন {#further-reading} + +- [ব্লকের পরিচিতি](/developers/docs/blocks/) +- [প্রুফ-অফ-স্টেক-এর পরিচিতি](/developers/docs/consensus-mechanisms/pos/) +- [ইথেরিয়াম কনসেন্সাস স্পেকস](https://github.com/ethereum/consensus-specs) +- [গ্যাসপারের পরিচিতি](/developers/docs/consensus-mechanisms/pos/gasper/) +- [ইথেরিয়াম আপগ্রেড করা](https://eth2book.info/) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..632988b27e0 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "বহুল জিজ্ঞাসিত প্রশ্নাবলী" +description: "প্রুফ-অফ-স্টেক ইথেরিয়াম-এর উপর বহুল জিজ্ঞাসিত প্রশ্নাবলী।" +lang: bn +--- + +## প্রুফ-অফ-স্টেক কী {#what-is-proof-of-stake} + +প্রুফ-অফ-স্টেক হল এক শ্রেণীর অ্যালগরিদম যা ব্লকচেইনকে সুরক্ষা প্রদান করতে পারে এটি নিশ্চিত করার মাধ্যমে যে, যে সমস্ত আক্রমণকারীরা অসৎভাবে কাজ করে তাদের মূল্যবান সম্পদগুলি হারিয়ে যায়। প্রুফ-অফ-স্টেক সিস্টেমের জন্য এক সেট ভ্যালিডেটরের প্রয়োজন হয় কিছু সম্পদ উপলব্ধ করার জন্য যা ধ্বংস করা যেতে পারে যদি ভ্যালিডেটর কোনো প্রমাণিত অসৎ আচরণে জড়িত থাকে। ইথেরিয়াম ব্লকচেইনকে সুরক্ষিত করতে একটি প্রুফ-অফ-স্টেক মেকানিজম ব্যবহার করে। + +## প্রুফ-অফ-ওয়ার্ক-এর সাথে প্রুফ-অফ-স্টেক-এর তুলনা কেমন? {#comparison-to-proof-of-work} + +প্রুফ-অফ-ওয়ার্ক এবং প্রুফ-অফ-স্টেক উভয়ই এমন পদ্ধতি যা ক্ষতিকারক অভিনেতাদের নেটওয়ার্কে স্প্যামিং বা প্রতারণা করা থেকে অর্থনৈতিকভাবে নিরুৎসাহিত করে। উভয় ক্ষেত্রেই, যে নোডগুলি সক্রিয়ভাবে কনসেন্সাস-এ অংশগ্রহণ করে তারা কিছু সম্পদ "নেটওয়ার্কে" রাখে যা তারা খারাপ আচরণ করলে হারাবে। + +প্রুফ-অফ-ওয়ার্ক-এ, এই সম্পদটি হল শক্তি। নোড, যা মাইনার হিসাবে পরিচিত, একটি অ্যালগরিদম চালায় যার লক্ষ্য অন্য যেকোনো নোডের চেয়ে দ্রুত একটি মান গণনা করা। দ্রুততম নোডের চেইনে একটি ব্লক প্রস্তাব করার অধিকার রয়েছে। চেইনের ইতিহাস পরিবর্তন করতে বা ব্লক প্রস্তাবে আধিপত্য বিস্তার করতে, একজন মাইনারকে এত বেশি কম্পিউটিং শক্তি থাকতে হবে যে তারা সবসময় রেসে জয়ী হয়। এটি কার্যকর করার জন্য অত্যধিক ব্যয়বহুল এবং কঠিন, যা চেইনকে আক্রমণ থেকে রক্ষা করে। প্রুফ-অফ-ওয়ার্ক ব্যবহার করে "মাইন" করার জন্য প্রয়োজনীয় শক্তি একটি বাস্তব-বিশ্বের সম্পদ যার জন্য মাইনাররা অর্থ প্রদান করে। + +প্রুফ-অফ-স্টেক-এর জন্য নোড, যা ভ্যালিডেটর হিসাবে পরিচিত, তাদের একটি স্মার্ট কন্ট্র্যাক্ট-এ স্পষ্টভাবে একটি ক্রিপ্টো সম্পদ জমা দিতে হয়। যদি কোনো ভ্যালিডেটর খারাপ আচরণ করে, তাহলে এই ক্রিপ্টোটি ধ্বংস হয়ে যেতে পারে কারণ তারা শক্তির ব্যয়ের মাধ্যমে পরোক্ষভাবে না করে সরাসরি চেইনে তাদের সম্পদ "স্টেকিং" করছে। + +প্রুফ-অফ-ওয়ার্ক অনেক বেশি শক্তি-ক্ষুধার্ত কারণ মাইনিং প্রক্রিয়ায় বিদ্যুৎ পোড়ানো হয়। অন্যদিকে, প্রুফ-অফ-স্টেক-এর জন্য খুব অল্প পরিমাণে শক্তির প্রয়োজন হয় - ইথেরিয়াম ভ্যালিডেটররা এমনকি Raspberry Pi-এর মতো কম-শক্তিসম্পন্ন ডিভাইসেও চলতে পারে। ইথেরিয়াম-এর প্রুফ-অফ-স্টেক পদ্ধতিকে প্রুফ-অফ-ওয়ার্কের চেয়ে বেশি সুরক্ষিত বলে মনে করা হয় কারণ আক্রমণের খরচ বেশি এবং আক্রমণকারীর জন্য পরিণতি আরও গুরুতর। + +প্রুফ-অফ-ওয়ার্ক বনাম প্রুফ-অফ-স্টেক একটি বিতর্কিত বিষয়। [Vitalik Buterin-এর ব্লগ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) এবং Justin Drake ও Lyn Alden-এর মধ্যে বিতর্কটি যুক্তিগুলির একটি ভাল সারসংক্ষেপ দেয়। + + + +## প্রুফ-অফ-স্টেক কি শক্তি-সাশ্রয়ী? {#is-pos-energy-efficient} + +হ্যাঁ। প্রুফ অফ স্টেকের নোডগুলো কিছু পরিমান এনার্জি ব্যবহার করে থাকে। একটি তৃতীয় পক্ষের সমীক্ষা এই সিদ্ধান্তে উপনীত হয়েছে যে সম্পূর্ণ প্রুফ-অফ-স্টেক ইথেরিয়াম নেটওয়ার্ক বছরে প্রায় 0.0026 TWh খরচ করে - যা শুধুমাত্র মার্কিন যুক্তরাষ্ট্রে গেমিংয়ের থেকে প্রায় 13,000 গুণ কম। + +[ইথেরিয়াম-এর শক্তি খরচ সম্পর্কে আরও জানুন](/energy-consumption/)। + +## প্রুফ-অফ-স্টেক কি সুরক্ষিত? {#is-pos-secure} + +ইথেরিয়াম-এর প্রুফ-অফ-স্টেক খুবই সুরক্ষিত। লাইভ হওয়ার আগে আট বছরেরও বেশি সময় ধরে এই পদ্ধতিটি নিয়ে গবেষণা করা হয়েছিল, বিকশিত করা হয়েছিল এবং কঠোরভাবে পরীক্ষা করা হয়েছিল। নিরাপত্তার গ্যারান্টিগুলি প্রুফ-অফ-ওয়ার্ক ব্লকচেইন থেকে ভিন্ন। প্রুফ-অফ-স্টেক-এ, দূষিত ভ্যালিডেটরদের সক্রিয়ভাবে শাস্তি ("স্ল্যাশড") দেওয়া যেতে পারে এবং ভ্যালিডেটর সেট থেকে বের করে দেওয়া যেতে পারে, যার ফলে যথেষ্ট পরিমাণে ETH খরচ হয়। প্রুফ-অফ-ওয়ার্ক-এর অধীনে, একজন আক্রমণকারী যতক্ষণ পর্যন্ত তাদের পর্যাপ্ত হ্যাস শক্তি থাকবে ততক্ষণ তাদের আক্রমণ পুনরাবৃত্তি করতে পারে। প্রুফ-অফ-ওয়ার্কের তুলনায় প্রুফ-অফ-স্টেক ইথেরিয়াম-এ সমতুল্য আক্রমণ চালানো আরও ব্যয়বহুল। চেইনের লাইভনেসকে প্রভাবিত করতে, নেটওয়ার্কে মোট স্টেক করা ইথারের কমপক্ষে 33% প্রয়োজন (খুবই পরিশীলিত আক্রমণের ক্ষেত্রে ছাড়া যেখানে সাফল্যের সম্ভাবনা অত্যন্ত কম)। ভবিষ্যতের ব্লকের বিষয়বস্তু নিয়ন্ত্রণ করতে, মোট স্টেক করা ETH-এর কমপক্ষে 51% প্রয়োজন এবং ইতিহাস পুনরায় লিখতে, মোট স্টেক-এর 66%-এর বেশি প্রয়োজন। ইথেরিয়াম প্রোটোকল 33% বা 51% আক্রমণের পরিস্থিতিতে এই সম্পদগুলিকে ধ্বংস করে দেবে এবং 66% আক্রমণের পরিস্থিতিতে সামাজিক কনসেন্সাস দ্বারা ধ্বংস করবে। + +- [আক্রমণকারীদের থেকে ইথেরিয়াম প্রুফ-অফ-স্টেক রক্ষা করার বিষয়ে আরও জানুন](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [প্রুফ-অফ-স্টেক ডিজাইন সম্পর্কে আরও জানুন](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## প্রুফ-অফ-স্টেক কি ইথেরিয়াম-কে সস্তা করে? {#does-pos-make-ethereum-cheaper} + +না। একটি লেনদেন পাঠানোর খরচ (গ্যাস ফি) একটি ডাইনামিক ফি মার্কেট দ্বারা নির্ধারিত হয় যা নেটওয়ার্কের চাহিদা বাড়ার সাথে সাথে বৃদ্ধি পায়। কনসেন্সাস পদ্ধতি এটিকে সরাসরি প্রভাবিত করে না। + +[গ্যাস সম্পর্কে আরও জানুন](/developers/docs/gas)। + +## নোড, ক্লায়েন্ট এবং ভ্যালিডেটর কী? {#what-are-nodes-clients-and-validators} + +নোড হল ইথেরিয়াম নেটওয়ার্কের সাথে সংযুক্ত কম্পিউটার। ক্লায়েন্ট হল সেই সফ্টওয়্যার যা তারা চালায় যা কম্পিউটারকে একটি নোডে পরিণত করে। দুই ধরনের ক্লায়েন্ট আছে: এক্সিকিউশন ক্লায়েন্ট এবং কনসেন্সাস ক্লায়েন্ট। একটি নোড তৈরি করতে উভয়ই প্রয়োজন। একটি ভ্যালিডেটর হল কনসেন্সাস ক্লায়েন্টের একটি ঐচ্ছিক অ্যাড-অন যা নোডকে প্রুফ-অফ-স্টেক কনসেন্সাসে অংশগ্রহণ করতে সক্ষম করে। এর অর্থ হল নির্বাচিত হলে ব্লক তৈরি এবং প্রস্তাব করা এবং নেটওয়ার্কে শোনা ব্লকগুলির প্রত্যয়ন করা। একটি ভ্যালিডেটর চালানোর জন্য, নোড অপারেটরকে ডিপোজিট কন্ট্রাক্টে 32 ETH জমা দিতে হবে। + +- [নোড এবং ক্লায়েন্ট সম্পর্কে আরও জানুন](/developers/docs/nodes-and-clients) +- [স্টেকিং সম্পর্কে আরও জানুন](/staking) + +## প্রুফ-অফ-স্টেক কি একটি নতুন ধারণা? {#is-pos-new} + +না। BitcoinTalk-এর একজন ব্যবহারকারী 2011 সালে Bitcoin-এর একটি আপগ্রেড হিসাবে [প্রুফ-অফ-স্টেক-এর মূল ধারণাটি প্রস্তাব করেছিলেন](https://bitcointalk.org/index.php?topic=27787.0)। ইথেরিয়াম মেইননেটে এটি বাস্তবায়নের জন্য প্রস্তুত হওয়ার আগে এগারো বছর লেগেছিল। কিছু অন্যান্য চেইন ইথেরিয়ামের আগে প্রুফ-অফ-স্টেক বাস্তবায়ন করেছিল, কিন্তু ইথেরিয়ামের নির্দিষ্ট মেকানিজম (Gasper নামে পরিচিত) নয়। + +## ইথেরিয়াম-এর প্রুফ-অফ-স্টেক-এর বিশেষত্ব কী? {#why-is-ethereum-pos-special} + +ইথেরিয়াম-এর প্রুফ-অফ-স্টেক পদ্ধতিটি তার ডিজাইনে অনন্য। এটি ডিজাইন এবং বাস্তবায়িত প্রথম প্রুফ-অফ-স্টেক পদ্ধতি ছিল না, তবে এটি সবচেয়ে শক্তিশালী। প্রুফ-অফ-স্টেক পদ্ধতিটি "Casper" নামে পরিচিত। Casper নির্ধারণ করে কিভাবে ভ্যালিডেটররা ব্লক প্রস্তাব করার জন্য নির্বাচিত হয়, কিভাবে এবং কখন প্রত্যয়ন করা হয়, কিভাবে প্রত্যয়ন গণনা করা হয়, ভ্যালিডেটরদের দেওয়া পুরস্কার এবং শাস্তি, স্ল্যাশিং শর্তাবলী, নিষ্ক্রিয়তা ফাঁসের মতো ফেইলসেফ পদ্ধতি এবং "ফাইনালিটি"-র শর্তাবলী। ফাইনালিটি হল এমন একটি শর্ত যে একটি ব্লককে ক্যানোনিকাল চেইনের একটি স্থায়ী অংশ হিসাবে বিবেচনা করার জন্য নেটওয়ার্কে মোট স্টেক করা ETH-এর কমপক্ষে 66% দ্বারা ভোট দেওয়া আবশ্যক। গবেষকরা বিশেষভাবে ইথেরিয়ামের জন্য Casper তৈরি করেছেন, এবং ইথেরিয়াম হল প্রথম এবং একমাত্র ব্লকচেইন যা এটি বাস্তবায়ন করেছে। + +Casper ছাড়াও, ইথেরিয়ামের প্রুফ-অফ-স্টেক LMD-GHOST নামক একটি ফর্ক পছন্দ অ্যালগরিদম ব্যবহার করে। একই স্লটের জন্য দুটি ব্লক বিদ্যমান এমন একটি শর্ত দেখা দিলে এটি প্রয়োজন। এটি ব্লকচেইনের দুটি ফর্ক তৈরি করে। LMD-GHOST সেইটিকে বেছে নেয় যার প্রত্যয়নের "ওজন" সবচেয়ে বেশি। ওজন হল ভ্যালিডেটরদের কার্যকর ব্যালেন্স দ্বারা ওজন করা প্রত্যয়নের সংখ্যা। LMD-GHOST ইথেরিয়ামের জন্য অনন্য। + +Casper এবং LMD_GHOST-এর সংমিশ্রণ Gasper নামে পরিচিত। + +[Gasper সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/gasper/) + +## স্ল্যাশিং কী? {#what-is-slashing} + +স্ল্যাশিং হল একটি ভ্যালিডেটরের স্টেক-এর কিছু অংশ ধ্বংস করা এবং নেটওয়ার্ক থেকে ভ্যালিডেটরকে বের করে দেওয়ার জন্য ব্যবহৃত একটি শব্দ। স্ল্যাশিং-এ হারানো ETH-এর পরিমাণ স্ল্যাশ করা ভ্যালিডেটরের সংখ্যার সাথে স্কেল করে - এর মানে হল ষড়যন্ত্রকারী ভ্যালিডেটররা ব্যক্তিদের চেয়ে বেশি কঠোরভাবে শাস্তি পায়। + +[স্ল্যাশিং সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## ভ্যালিডেটরদের 32 ETH কেন প্রয়োজন? {#why-32-eth} + +ভ্যালিডেটরদের ETH স্টেক করতে হয় যাতে তারা খারাপ আচরণ করলে তাদের হারানোর মতো কিছু থাকে। তাদের বিশেষভাবে 32 ETH স্টেক করতে হওয়ার কারণ হল নোডগুলিকে সাধারণ হার্ডওয়্যারে চলতে সক্ষম করা। যদি প্রতি ভ্যালিডেটরের সর্বনিম্ন ETH কম হত, তাহলে ভ্যালিডেটরের সংখ্যা এবং ফলস্বরূপ প্রতিটি স্লটে প্রক্রিয়া করা আবশ্যক বার্তাগুলির সংখ্যা বাড়ত, যার অর্থ একটি নোড চালানোর জন্য আরও শক্তিশালী হার্ডওয়্যারের প্রয়োজন হত। + +## ভ্যালিডেটরদের কীভাবে নির্বাচন করা হয়? {#how-are-validators-selected} + +RANDAO নামক একটি অ্যালগরিদম ব্যবহার করে প্রতিটি স্লটে একটি ব্লক প্রস্তাব করার জন্য একজন একক ভ্যালিডেটরকে ছদ্ম-এলোমেলোভাবে বেছে নেওয়া হয় যা ব্লক প্রস্তাবকের একটি হ্যাসকে একটি সিডের সাথে মিশ্রিত করে যা প্রতিটি ব্লকে আপডেট হয়। এই মানটি মোট ভ্যালিডেটর সেট থেকে একটি নির্দিষ্ট ভ্যালিডেটর নির্বাচন করতে ব্যবহৃত হয়। ভ্যালিডেটর নির্বাচন দুটি ইপক আগে থেকে স্থির করা হয়। + +[ভ্যালিডেটর নির্বাচন সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## স্টেক গ্রাইন্ডিং কী? {#what-is-stake-grinding} + +স্টেক গ্রাইন্ডিং হল প্রুফ-অফ-স্টেক নেটওয়ার্কের উপর এক ধরনের আক্রমণ যেখানে আক্রমণকারী তাদের নিজস্ব ভ্যালিডেটরদের পক্ষে ভ্যালিডেটর নির্বাচন অ্যালগরিদমকে পক্ষপাতদুষ্ট করার চেষ্টা করে। RANDAO-এর উপর স্টেক গ্রাইন্ডিং আক্রমণের জন্য মোট স্টেক করা ETH-এর প্রায় অর্ধেক প্রয়োজন। + +[স্টেক গ্রাইন্ডিং সম্পর্কে আরও জানুন](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## সোশ্যাল স্ল্যাশিং কী? {#what-is-social-slashing} + +সোশ্যাল স্ল্যাশিং হল একটি আক্রমণের প্রতিক্রিয়ায় ব্লকচেইনের একটি ফর্ক সমন্বয় করার জন্য সম্প্রদায়ের ক্ষমতা। এটি সম্প্রদায়কে একজন আক্রমণকারীর একটি অসৎ চেইন চূড়ান্ত করা থেকে পুনরুদ্ধার করতে সক্ষম করে। সেন্সরশিপ আক্রমণের বিরুদ্ধেও সোশ্যাল স্ল্যাশিং ব্যবহার করা যেতে পারে। + +- [সোশ্যাল স্ল্যাশিং সম্পর্কে আরও জানুন](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [সোশ্যাল স্ল্যাশিং সম্পর্কে Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## আমি কি স্ল্যাশড হব? {#will-i-get-slashed} + +একজন ভ্যালিডেটর হিসাবে, স্ল্যাশড হওয়া খুব কঠিন যদি না আপনি ইচ্ছাকৃতভাবে ক্ষতিকারক আচরণে জড়িত হন। স্ল্যাশিং শুধুমাত্র খুব নির্দিষ্ট পরিস্থিতিতে বাস্তবায়িত হয় যেখানে ভ্যালিডেটররা একই স্লটের জন্য একাধিক ব্লক প্রস্তাব করে বা তাদের প্রত্যয়ন দিয়ে নিজেদের বিরোধিতা করে - এগুলি দুর্ঘটনাক্রমে ঘটার সম্ভাবনা খুব কম। + +[স্ল্যাশিং শর্তাবলী সম্পর্কে আরও জানুন](https://eth2book.info/altair/part2/incentives/slashing) + +## নাথিং-অ্যাট-স্টেক সমস্যাটি কী? {#what-is-nothing-at-stake-problem} + +নাথিং-অ্যাট-স্টেক সমস্যাটি কিছু প্রুফ-অফ-স্টেক পদ্ধতির সাথে একটি ধারণাগত সমস্যা যেখানে শুধুমাত্র পুরস্কার আছে এবং কোনো শাস্তি নেই। যদি স্টেক করার মতো কিছু না থাকে, তবে একজন বাস্তববাদী ভ্যালিডেটর ব্লকচেইনের যেকোনো, বা এমনকি একাধিক, ফর্কের প্রত্যয়ন করতে সমানভাবে খুশি, কারণ এটি তাদের পুরস্কার বাড়ায়। ইথেরিয়াম একটি ক্যানোনিকাল চেইন নিশ্চিত করতে ফাইনালিটি শর্ত এবং স্ল্যাশিং ব্যবহার করে এই সমস্যার সমাধান করে। + +[নাথিং-অ্যাট-স্টেক সমস্যা সম্পর্কে আরও জানুন](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## ফর্ক পছন্দ অ্যালগরিদম কী? {#what-is-a-fork-choice-algorithm} + +একটি ফর্ক পছন্দ অ্যালগরিদম নিয়ম বাস্তবায়ন করে যা নির্ধারণ করে কোন চেইনটি ক্যানোনিকাল। অনুকূল পরিস্থিতিতে, ফর্ক পছন্দ নিয়মের কোনো প্রয়োজন নেই কারণ প্রতি স্লটে কেবল একজন ব্লক প্রস্তাবক থাকে এবং বেছে নেওয়ার জন্য একটি ব্লক থাকে। তবে মাঝে মাঝে, একই স্লটের জন্য একাধিক ব্লক বা দেরিতে আসা তথ্য চেইনের শীর্ষের কাছাকাছি ব্লকগুলি কীভাবে সংগঠিত হয় তার জন্য একাধিক বিকল্পের দিকে নিয়ে যায়। এইসব ক্ষেত্রে, সমস্ত ক্লায়েন্টদের অবশ্যই কিছু নিয়ম একইভাবে বাস্তবায়ন করতে হবে যাতে তারা সবাই সঠিক ব্লকের ক্রম বেছে নেয়। ফর্ক পছন্দ অ্যালগরিদম এই নিয়মগুলিকে এনকোড করে। + +ইথেরিয়ামের ফর্ক পছন্দ অ্যালগরিদমকে LMD-GHOST বলা হয়। এটি সবচেয়ে বেশি প্রত্যয়নের ওজনের ফর্কটি বেছে নেয়, যার অর্থ হল সবচেয়ে বেশি স্টেক করা ETH যেটির জন্য ভোট দিয়েছে। + +[LMD-GHOST সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## প্রুফ-অফ-স্টেক-এ ফাইনালিটি কী? {#what-is-finality} + +প্রুফ-অফ-স্টেক-এ ফাইনালিটি হল এই গ্যারান্টি যে একটি প্রদত্ত ব্লক ক্যানোনিকাল চেইনের একটি স্থায়ী অংশ এবং এটিকে প্রত্যাবর্তন করা যাবে না যদি না একটি কনসেন্সাস ব্যর্থতা হয় যেখানে একজন আক্রমণকারী মোট স্টেক করা ইথারের 33% পুড়িয়ে ফেলে। এটি হল "ক্রিপ্টো-অর্থনৈতিক" ফাইনালিটি, যা "সম্ভাব্য ফাইনালিটি"-এর বিপরীত যা প্রুফ-অফ-ওয়ার্ক ব্লকচেইনের সাথে প্রাসঙ্গিক। সম্ভাব্য ফাইনালিটিতে, ব্লকগুলির জন্য কোনো সুস্পষ্ট চূড়ান্ত/অ-চূড়ান্ত অবস্থা নেই - একটি ব্লক চেইন থেকে সরানো যেতে পারে এমন সম্ভাবনা কেবল কমতে থাকে যখন এটি পুরানো হয়, এবং ব্যবহারকারীরা নিজেরাই নির্ধারণ করে কখন তারা যথেষ্ট আত্মবিশ্বাসী যে একটি ব্লক "নিরাপদ"। ক্রিপ্টো-অর্থনৈতিক ফাইনালিটির সাথে, জোড়া চেকপয়েন্ট ব্লকের জন্য স্টেক করা ইথারের 66% দ্বারা ভোট দিতে হবে। যদি এই শর্তটি পূরণ হয়, তবে সেই চেকপয়েন্টগুলির মধ্যেকার ব্লকগুলিকে স্পষ্টভাবে "চূড়ান্ত" করা হয়। + +[ফাইনালিটি সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/#finality) + +## "উইক সাবজেক্টিভিটি" কী? {#what-is-weak-subjectivity} + +উইক সাবজেক্টিভিটি হল প্রুফ-অফ-স্টেক নেটওয়ার্কগুলির একটি বৈশিষ্ট্য যেখানে ব্লকচেইনের বর্তমান অবস্থা নিশ্চিত করতে সামাজিক তথ্য ব্যবহার করা হয়। নতুন নোড বা দীর্ঘ সময় ধরে অফলাইন থাকার পর নেটওয়ার্কে পুনরায় যোগদানকারী নোডগুলিকে একটি সাম্প্রতিক অবস্থা দেওয়া যেতে পারে যাতে নোডটি অবিলম্বে দেখতে পারে যে তারা সঠিক চেইনে আছে কিনা। এই অবস্থাগুলিকে "উইক সাবজেক্টিভিটি চেকপয়েন্ট" বলা হয় এবং এগুলি অন্যান্য নোড অপারেটরদের কাছ থেকে আউট-অফ-ব্যান্ড, বা ব্লক এক্সপ্লোরার থেকে, বা বেশ কয়েকটি পাবলিক এন্ডপয়েন্ট থেকে পাওয়া যেতে পারে। + +[উইক সাবজেক্টিভিটি সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## প্রুফ-অফ-স্টেক কি সেন্সরশিপ প্রতিরোধী? {#is-pos-censorship-resistant} + +সেন্সরশিপ প্রতিরোধ ক্ষমতা বর্তমানে প্রমাণ করা কঠিন। তবে, প্রুফ-অফ-ওয়ার্কের বিপরীতে, প্রুফ-অফ-স্টেক সেন্সরকারী ভ্যালিডেটরদের শাস্তি দেওয়ার জন্য স্ল্যাশিং সমন্বয় করার বিকল্প প্রস্তাব করে। প্রোটোকলে আসন্ন পরিবর্তন রয়েছে যা ব্লক বিল্ডারদের ব্লক প্রস্তাবকদের থেকে পৃথক করে এবং লেনদেনের তালিকা বাস্তবায়ন করে যা বিল্ডারদের প্রতিটি ব্লকে অন্তর্ভুক্ত করতে হবে। এই প্রস্তাবটি প্রপার-বিল্ডার সেপারেশন নামে পরিচিত এবং ভ্যালিডেটরদের লেনদেন সেন্সর করা থেকে বিরত রাখতে সাহায্য করে। + +[প্রস্তাবক-নির্মাতা পৃথকীকরণ সম্পর্কে আরও জানুন](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## ইথেরিয়ামের প্রুফ-অফ-স্টেক সিস্টেমে কি 51% আক্রমণ করা সম্ভব? {#pos-51-attack} + +হ্যাঁ। প্রুফ-অফ-স্টেক, প্রুফ-অফ-ওয়ার্ক-এর মতোই 51% আক্রমণের জন্য ঝুঁকিপূর্ণ। আক্রমণকারীর নেটওয়ার্কের 51% হ্যাস পাওয়ারের পরিবর্তে, আক্রমণকারীর মোট স্টেক করা ETH-এর 51% প্রয়োজন। একজন আক্রমণকারী যে মোট স্টেক-এর 51% সংগ্রহ করে সে ফর্ক-পছন্দ অ্যালগরিদম নিয়ন্ত্রণ করতে পারে। এটি আক্রমণকারীকে নির্দিষ্ট লেনদেন সেন্সর করতে, স্বল্প-পরিসরের রিঅর্গ করতে এবং তাদের পক্ষে ব্লকগুলির পুনর্বিন্যাস করে MEV নিষ্কাশন করতে সক্ষম করে। + +[প্রুফ-অফ-স্টেক-এর উপর আক্রমণ সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## সামাজিক সমন্বয় কী, এবং কেন এটি প্রয়োজন? {#what-is-social-coordination} + +সামাজিক সমন্বয় হল ইথেরিয়ামের জন্য প্রতিরক্ষার শেষ লাইন যা একটি সৎ চেইনকে এমন একটি আক্রমণ থেকে পুনরুদ্ধার করার অনুমতি দেবে যা অসৎ ব্লকগুলিকে চূড়ান্ত করেছে। এই ক্ষেত্রে, ইথেরিয়াম সম্প্রদায়কে "আউট-অফ-ব্যান্ড" সমন্বয় করতে হবে এবং একটি সৎ সংখ্যালঘু ফর্ক ব্যবহার করতে সম্মত হতে হবে, এই প্রক্রিয়ায় আক্রমণকারীর ভ্যালিডেটরদের স্ল্যাশ করে। এর জন্য অ্যাপ এবং এক্সচেঞ্জগুলিকেও সৎ ফর্কটিকে স্বীকৃতি দিতে হবে। + +[সামাজিক সমন্বয় সম্পর্কে আরও পড়ুন](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## প্রুফ-অফ-স্টেক-এ কি ধনীরা আরও ধনী হয়? {#do-rich-get-richer} + +কারও কাছে যত বেশি ETH স্টেক করার জন্য থাকবে, তারা তত বেশি ভ্যালিডেটর চালাতে পারবে, এবং তারা তত বেশি পুরস্কার অর্জন করতে পারবে। পুরস্কারগুলি স্টেক করা ETH-এর পরিমাণের সাথে রৈখিকভাবে স্কেল করে, এবং প্রত্যেকে একই শতাংশ রিটার্ন পায়। প্রুফ-অফ-ওয়ার্ক প্রুফ-অফ-স্টেকের চেয়ে ধনীদের বেশি সমৃদ্ধ করে কারণ ধনী মাইনাররা যারা স্কেলে হার্ডওয়্যার কেনেন তারা ইকোনোমি অফ স্কেল থেকে উপকৃত হন, যার অর্থ সম্পদ এবং পুরস্কারের মধ্যে সম্পর্কটি অরৈখিক। + +## প্রুফ-অফ-স্টেক কি প্রুফ-অফ-ওয়ার্কের চেয়ে বেশি কেন্দ্রীভূত? {#is-pos-decentralized} + +না, প্রুফ-অফ-ওয়ার্ক কেন্দ্রীকরণের দিকে ঝোঁকে কারণ মাইনিং খরচ বাড়ে এবং ব্যক্তিদের দাম বাড়িয়ে দেয়, তারপর ছোট সংস্থাগুলিকে দাম বাড়িয়ে দেয়, ইত্যাদি। প্রুফ-অফ-স্টেকের বর্তমান সমস্যা হল লিকুইড স্টেকিং ডেরিভেটিভস (LSDs)-এর প্রভাব। এগুলি হল টোকেন যা কোনো প্রদানকারীর দ্বারা স্টেক করা ETH-কে প্রতিনিধিত্ব করে যা যে কেউ সেকেন্ডারি মার্কেটে সোয়াপ করতে পারে আসল ETH আনস্টেক না করেই। LSD গুলি ব্যবহারকারীদের 32 ETH-এর কম দিয়ে স্টেক করার অনুমতি দেয়, কিন্তু তারা একটি কেন্দ্রীকরণের ঝুঁকিও তৈরি করে যেখানে কয়েকটি বড় সংস্থা স্টেক-এর বেশিরভাগ অংশ নিয়ন্ত্রণ করতে পারে। এই কারণেই ইথেরিয়ামের জন্য [সোলো স্টেকিং](/staking/solo) সেরা বিকল্প। + +[LSD-তে স্টেক কেন্দ্রীকরণ সম্পর্কে আরও জানুন](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## আমি কেন শুধু ETH স্টেক করতে পারি? {#why-can-i-only-stake-eth} + +ETH হল ইথেরিয়ামের স্থানীয় মুদ্রা। ভোটের ওজন এবং সুরক্ষার জন্য কার্যকর ব্যালেন্সের হিসাব রাখার জন্য সমস্ত স্টেককে একটি একক মুদ্রায় চিহ্নিত করা অপরিহার্য। ETH নিজেই একটি স্মার্ট কন্ট্রাক্টের পরিবর্তে ইথেরিয়ামের একটি মৌলিক উপাদান। অন্যান্য মুদ্রা অন্তর্ভুক্ত করলে স্টেকিংয়ের জটিলতা উল্লেখযোগ্যভাবে বৃদ্ধি পাবে এবং নিরাপত্তা হ্রাস পাবে। + +## ইথেরিয়াম কি একমাত্র প্রুফ-অফ-স্টেক ব্লকচেইন? {#is-ethereum-the-only-pos-blockchain} + +না, বেশ কয়েকটি প্রুফ-অফ-স্টেক ব্লকচেইন রয়েছে। কোনোটিই ইথেরিয়ামের অনুরূপ নয়; ইথেরিয়ামের প্রুফ-অফ-স্টেক পদ্ধতিটি অনন্য। + +## দ্য মার্জ কী? {#what-is-the-merge} + +দ্য মার্জ হল সেই মুহূর্ত যখন ইথেরিয়াম তার প্রুফ-অফ-ওয়ার্ক-ভিত্তিক কনসেন্সাস মেকানিজম বন্ধ করে দেয় এবং তার প্রুফ-অফ-স্টেক-ভিত্তিক কনসেন্সাস মেকানিজম চালু করে। দ্য মার্জ 15 সেপ্টেম্বর, 2022-এ ঘটেছিল। + +[দ্য মার্জ সম্পর্কে আরও জানুন](/roadmap/merge) + +## লাইভনেস এবং সেফটি কী? {#what-are-liveness-and-safety} + +লাইভনেস এবং সেফটি হল একটি ব্লকচেইনের জন্য দুটি মৌলিক নিরাপত্তা উদ্বেগ। লাইভনেস হল একটি চূড়ান্তকারী চেইনের প্রাপ্যতা। যদি চেইন চূড়ান্ত হওয়া বন্ধ করে দেয় বা ব্যবহারকারীরা সহজেই এটি অ্যাক্সেস করতে না পারে, সেগুলি হল লাইভনেস ব্যর্থতা। অত্যন্ত উচ্চ অ্যাক্সেস খরচকেও একটি লাইভনেস ব্যর্থতা হিসাবে বিবেচনা করা যেতে পারে। সেফটি বলতে বোঝায় চেইনে আক্রমণ করা কতটা কঠিন - অর্থাৎ, পরস্পরবিরোধী চেকপয়েন্ট চূড়ান্ত করা। + +[Casper পেপারে আরও পড়ুন](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..db0d694a9ba --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: "গ্যাস্পার" +description: "গ্যাস্পার প্রুফ-অফ-স্টেক মেকানিজমের একটি ব্যাখ্যা।" +lang: bn +--- + +গ্যাস্পার হল ক্যাসপার দ্য ফ্রেন্ডলি ফাইনালিটি গ্যাজেট (Casper-FFG) এবং LMD-GHOST ফর্ক চয়েস অ্যালগরিদমের একটি সংমিশ্রণ। একত্রে এই উপাদানগুলি প্রুফ-অফ-স্টেক ইথেরিয়ামকে সুরক্ষিত করার জন্য কনসেন্সাস মেকানিজম তৈরি করে। ক্যাসপার হল সেই মেকানিজম যা নির্দিষ্ট ব্লকগুলিকে "চূড়ান্ত" করতে আপগ্রেড করে যাতে নেটওয়ার্কে নতুন প্রবেশকারীরা আত্মবিশ্বাসী হতে পারে যে তারা ক্যানোনিকাল চেইন সিঙ্ক করছে। ফর্ক চয়েস অ্যালগরিদমটি সঞ্চিত ভোট ব্যবহার করে নিশ্চিত করে যে যখন ব্লকচেইনে ফর্ক দেখা দেয় তখন নোডগুলি সহজেই সঠিকটি নির্বাচন করতে পারে। + +**দ্রষ্টব্য** যে Casper-FFG-এর মূল সংজ্ঞাটি গ্যাস্পারে অন্তর্ভুক্ত করার জন্য সামান্য আপডেট করা হয়েছিল। এই পৃষ্ঠায় আমরা আপডেট করা সংস্করণটি বিবেচনা করব। + +## পূর্বশর্ত + +এই উপাদানটি বুঝতে হলে [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/)-এর ভূমিকা পৃষ্ঠাটি পড়া প্রয়োজন। + +## গ্যাস্পারের ভূমিকা {#role-of-gasper} + +গ্যাস্পার একটি প্রুফ-অফ-স্টেক ব্লকচেইনের উপরে বসে যেখানে নোডগুলি একটি নিরাপত্তা আমানত হিসাবে ইথার সরবরাহ করে যা ব্লক প্রস্তাব বা ভ্যালিডেট করার ক্ষেত্রে অলস বা অসৎ হলে ধ্বংস করা যেতে পারে। গ্যাস্পার হল সেই মেকানিজম যা নির্ধারণ করে যে কীভাবে ভ্যালিডেটরদের পুরস্কৃত এবং শাস্তি দেওয়া হবে, কোন ব্লকগুলি গ্রহণ বা প্রত্যাখ্যান করা হবে এবং ব্লকচেইনের কোন ফর্কের উপর ভিত্তি করে তৈরি করা হবে। + +## চূড়ান্ততা কী? {#what-is-finality} + +চূড়ান্ততা হল নির্দিষ্ট ব্লকের একটি বৈশিষ্ট্য যার অর্থ হল যে সেগুলিকে প্রত্যাবর্তন করা যাবে না যতক্ষণ না একটি গুরুতর কনসেন্সাস ব্যর্থতা ঘটে এবং একজন আক্রমণকারী মোট স্টেক করা ইথারের কমপক্ষে 1/3 অংশ ধ্বংস করে দেয়। চূড়ান্ত ব্লকগুলিকে এমন তথ্য হিসাবে ভাবা যেতে পারে যার সম্পর্কে ব্লকচেইন নিশ্চিত। একটি ব্লককে চূড়ান্ত করার জন্য দুটি ধাপের আপগ্রেড পদ্ধতির মধ্যে দিয়ে যেতে হবে: + +1. ক্যানোনিকাল চেইনে সেই ব্লকের অন্তর্ভুক্তির পক্ষে মোট স্টেক করা ইথারের দুই-তৃতীয়াংশকে অবশ্যই ভোট দিতে হবে। এই শর্তটি ব্লকটিকে "যৌক্তিক"-এ আপগ্রেড করে। যৌক্তিক ব্লকগুলি প্রত্যাবর্তন করার সম্ভাবনা কম, তবে নির্দিষ্ট শর্তে তা করা যেতে পারে। +2. যখন একটি যৌক্তিক ব্লকের উপরে আরেকটি ব্লক যৌক্তিক হয়, তখন এটিকে "চূড়ান্ত"-তে আপগ্রেড করা হয়। একটি ব্লককে চূড়ান্ত করা হল ক্যানোনিকাল চেইনে ব্লকটিকে অন্তর্ভুক্ত করার একটি প্রতিশ্রুতি। এটি প্রত্যাবর্তন করা যাবে না যতক্ষণ না একজন আক্রমণকারী লক্ষ লক্ষ ইথার (বিলিয়ন $USD) ধ্বংস করে। + +এই ব্লক আপগ্রেডগুলি প্রতিটি স্লটে ঘটে না। পরিবর্তে, শুধুমাত্র ইপক-বাউন্ডারি ব্লকগুলিকেই যৌক্তিক এবং চূড়ান্ত করা যেতে পারে। এই ব্লকগুলি "চেকপয়েন্ট" নামে পরিচিত। আপগ্রেড করার সময় এক জোড়া চেকপয়েন্ট বিবেচনা করা হয়। কম সাম্প্রতিক চেকপয়েন্টকে চূড়ান্ত এবং আরও সাম্প্রতিক ব্লককে যৌক্তিক করতে আপগ্রেড করার জন্য দুটি ধারাবাহিক চেকপয়েন্টের মধ্যে একটি "সুপারমেজরিটি লিঙ্ক" থাকতে হবে (অর্থাৎ, মোট স্টেক করা ইথারের দুই-তৃতীয়াংশের ভোট দেওয়া যে চেকপয়েন্ট B হল চেকপয়েন্ট A-এর সঠিক উত্তরসূরি)। + +যেহেতু চূড়ান্ততার জন্য একটি ব্লকের ক্যানোনিকাল হওয়ার জন্য দুই-তৃতীয়াংশের চুক্তির প্রয়োজন হয়, তাই একজন আক্রমণকারী নিম্নলিখিতগুলি ছাড়া কোনো বিকল্প চূড়ান্ত চেইন তৈরি করতে পারে না: + +1. মোট স্টেক করা ইথারের দুই-তৃতীয়াংশের মালিকানা বা কারসাজি করা। +2. মোট স্টেক করা ইথারের অন্তত এক-তৃতীয়াংশ ধ্বংস করা। + +প্রথম শর্তটি দেখা দেয় কারণ একটি চেইনকে চূড়ান্ত করতে স্টেক করা ইথারের দুই-তৃতীয়াংশের প্রয়োজন। দ্বিতীয় শর্তটি দেখা দেয় কারণ যদি মোট স্টেকের দুই-তৃতীয়াংশ উভয় ফর্কের পক্ষে ভোট দিয়ে থাকে, তাহলে এক-তৃতীয়াংশকে অবশ্যই উভয়ের উপর ভোট দিতে হবে। ডাবল-ভোটিং একটি স্ল্যাশিং শর্ত যা সর্বোচ্চ শাস্তিযোগ্য, এবং মোট স্টেকের এক-তৃতীয়াংশ ধ্বংস হয়ে যাবে। মে 2022 অনুযায়ী, এর জন্য একজন আক্রমণকারীকে প্রায় $10 বিলিয়ন মূল্যের ইথার পোড়াতে হবে। গ্যাস্পারে যে অ্যালগরিদম ব্লকগুলিকে যৌক্তিক এবং চূড়ান্ত করে, তা হল [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf)-এর একটি সামান্য পরিবর্তিত রূপ। + +### ইনসেনটিভ এবং স্ল্যাশিং {#incentives-and-slashing} + +ভ্যালিডেটররা সৎভাবে ব্লক প্রস্তাব এবং ভ্যালিডেট করার জন্য পুরস্কৃত হয়। ইথার পুরস্কৃত করা হয় এবং তাদের স্টেকে যোগ করা হয়। অন্যদিকে, যে ভ্যালিডেটররা অনুপস্থিত থাকে এবং যখন কাজ করার জন্য ডাকা হয় তখন কাজ করতে ব্যর্থ হয়, তারা এই পুরস্কারগুলি থেকে বঞ্চিত হয় এবং কখনও কখনও তাদের বিদ্যমান স্টেকের একটি ছোট অংশ হারায়। যাইহোক, অফলাইন থাকার জন্য জরিমানা সামান্য এবং বেশিরভাগ ক্ষেত্রে, পুরস্কার হারানোর সুযোগ ব্যয়ের সমান। যাইহোক, কিছু ভ্যালিডেটর ক্রিয়া দুর্ঘটনাক্রমে করা খুব কঠিন এবং কিছু দূষিত উদ্দেশ্যকে বোঝায়, যেমন একই স্লটের জন্য একাধিক ব্লক প্রস্তাব করা, একই স্লটের জন্য একাধিক ব্লকে অ্যাটেস্টিং করা, বা পূর্ববর্তী চেকপয়েন্ট ভোটের বিরোধিতা করা। এগুলি হল "স্ল্যাশযোগ্য" আচরণ যেগুলিকে আরও কঠোরভাবে শাস্তি দেওয়া হয়—স্ল্যাশিং-এর ফলে ভ্যালিডেটরের স্টেকের কিছু অংশ ধ্বংস হয়ে যায় এবং ভ্যালিডেটরকে ভ্যালিডেটরদের নেটওয়ার্ক থেকে সরিয়ে দেওয়া হয়। এই প্রক্রিয়াটি 36 দিন সময় নেয়। প্রথম দিনে, 1 ETH পর্যন্ত প্রাথমিক জরিমানা রয়েছে। তারপর স্ল্যাশ করা ভ্যালিডেটরের ইথার ধীরে ধীরে এক্সিট পিরিয়ড জুড়ে শেষ হয়ে যায়, কিন্তু 18তম দিনে, তারা একটি "কোরিলেশন পেনাল্টি" পায়, যা একই সময়ে আরও বেশি ভ্যালিডেটর স্ল্যাশ করা হলে আরও বড় হয়। সর্বোচ্চ জরিমানা হল সম্পূর্ণ স্টেক। এই পুরস্কার এবং জরিমানাগুলি সৎ ভ্যালিডেটরদের উৎসাহিত করতে এবং নেটওয়ার্কে আক্রমণকে নিরুৎসাহিত করার জন্য ডিজাইন করা হয়েছে। + +### নিষ্ক্রিয়তা লিক {#inactivity-leak} + +নিরাপত্তার পাশাপাশি, গ্যাস্পার "বিশ্বাসযোগ্য লাইভনেস" প্রদান করে। এটি এমন একটি শর্ত যে যতক্ষণ পর্যন্ত মোট স্টেক করা ইথারের দুই-তৃতীয়াংশ সততার সাথে ভোট দিচ্ছে এবং প্রোটোকল অনুসরণ করছে, ততক্ষণ চেইনটি অন্য কোনও কার্যকলাপ (যেমন আক্রমণ, লেটেন্সি সমস্যা বা স্ল্যাশিং) নির্বিশেষে চূড়ান্ত হতে সক্ষম হবে। অন্যভাবে বলতে গেলে, চেইনকে চূড়ান্ত হওয়া থেকে আটকাতে মোট স্টেক করা ইথারের এক-তৃতীয়াংশকে কোনোভাবে আপোস করতে হবে। গ্যাস্পারে, লাইভনেস ব্যর্থতার বিরুদ্ধে একটি অতিরিক্ত প্রতিরক্ষা ব্যবস্থা রয়েছে, যা "নিষ্ক্রিয়তা লিক" নামে পরিচিত। এই মেকানিজমটি সক্রিয় হয় যখন চেইনটি চারটিরও বেশি ইপক ধরে চূড়ান্ত হতে ব্যর্থ হয়। যেসব ভ্যালিডেটর সক্রিয়ভাবে মেজরিটি চেইনে অ্যাটেস্টিং করছে না, তাদের স্টেক ধীরে ধীরে নিঃশেষ হয়ে যায় যতক্ষণ না মেজরিটি মোট স্টেকের দুই-তৃতীয়াংশ ফিরে পায়, এটি নিশ্চিত করে যে লাইভনেস ব্যর্থতা শুধুমাত্র অস্থায়ী। + +### ফর্ক পছন্দ {#fork-choice} + +Casper-FFG-এর মূল সংজ্ঞায় একটি ফর্ক চয়েস অ্যালগরিদম অন্তর্ভুক্ত ছিল যা এই নিয়মটি আরোপ করেছিল: `সেই চেইনটি অনুসরণ করুন যেখানে সর্বোচ্চ উচ্চতার যৌক্তিক চেকপয়েন্ট রয়েছে` যেখানে উচ্চতাকে জেনেসিস ব্লক থেকে সর্বাধিক দূরত্ব হিসাবে সংজ্ঞায়িত করা হয়। গ্যাস্পারে, আসল ফর্ক চয়েস নিয়মটি LMD-GHOST নামক একটি আরও পরিশীলিত অ্যালগরিদমের পক্ষে বাতিল করা হয়েছে। এটা বোঝা গুরুত্বপূর্ণ যে সাধারণ পরিস্থিতিতে, একটি ফর্ক চয়েস নিয়মের প্রয়োজন নেই - প্রতিটি স্লটের জন্য একটি একক ব্লক প্রোপোজার থাকে এবং সৎ ভ্যালিডেটররা এতে অ্যাটেস্টিং করে। শুধুমাত্র বড় নেটওয়ার্ক অ্যাসিঙ্ক্রোনিসিটির ক্ষেত্রে বা যখন একজন অসৎ ব্লক প্রোপোজার দ্ব্যর্থবোধক কথা বলে, তখনই একটি ফর্ক চয়েস অ্যালগরিদমের প্রয়োজন হয়। যাইহোক, যখন সেই ঘটনাগুলি ঘটে, তখন ফর্ক চয়েস অ্যালগরিদম একটি গুরুত্বপূর্ণ প্রতিরক্ষা যা সঠিক চেইনকে সুরক্ষিত করে। + +LMD-GHOST-এর পূর্ণরূপ হল "লেটেস্ট মেসেজ-ড্রিভেন গ্রিডি হেভিয়েস্ট অবজার্ভড সাব-ট্রি"। এটি একটি পরিভাষা-বহুল উপায় একটি অ্যালগরিদমকে সংজ্ঞায়িত করার, যা অ্যাটেস্টেশনের সর্বাধিক সঞ্চিত ওজন সহ ফর্কটিকে ক্যানোনিকাল হিসাবে নির্বাচন করে (গ্রিডি হেভিয়েস্ট সাবট্রি) এবং যদি একজন ভ্যালিডেটরের কাছ থেকে একাধিক বার্তা পাওয়া যায়, তবে শুধুমাত্র সর্বশেষটি বিবেচনা করা হয় (লেটেস্ট-মেসেজ ড্রিভেন)। সবচেয়ে ভারী ব্লকটিকে তার ক্যানোনিকাল চেইনে যোগ করার আগে, প্রতিটি ভ্যালিডেটর এই নিয়মটি ব্যবহার করে প্রতিটি ব্লক মূল্যায়ন করে। + +## আরও পড়ুন {#further-reading} + +- [গ্যাস্পার: GHOST এবং Casper-এর সমন্বয়](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..74ff1c10770 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: "প্রুফ-অফ-স্টেক (PoS)" +description: "প্রুফ-অফ-স্টেক কনসেন্সাস প্রোটোকল এবং Ethereum-এ এর ভূমিকা সম্পর্কে একটি ব্যাখ্যা।" +lang: bn +--- + +প্রুফ-অফ-স্টেক (PoS) হল Ethereum-এর [কনসেন্সাস মেকানিজম](/developers/docs/consensus-mechanisms/)-এর ভিত্তি। Ethereum 2022 সালে তার প্রুফ-অফ-স্টেক মেকানিজমে পরিবর্তন করে কারণ এটি পূর্ববর্তী [প্রুফ-অফ-ওয়ার্ক](/developers/docs/consensus-mechanisms/pow) আর্কিটেকচারের তুলনায় আরও বেশি সুরক্ষিত, কম শক্তি-নিবিড় এবং নতুন স্কেলিং সমাধান বাস্তবায়নের জন্য উন্নত। + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি ভালোভাবে বোঝার জন্য, আমরা আপনাকে প্রথমে [কনসেন্সাস মেকানিজম](/developers/docs/consensus-mechanisms/) সম্পর্কে পড়ে নেওয়ার সুপারিশ করছি। + +## প্রুফ-অফ-স্টেক (PoS) কী? {#what-is-pos} + +প্রুফ-অফ-স্টেক হল এটি প্রমাণ করার একটি উপায় যে ভ্যালিডেটররা নেটওয়ার্কে মূল্যবান কিছু রেখেছে যা তারা অসাধুভাবে কাজ করলে ধ্বংস করা যেতে পারে। Ethereum-এর প্রুফ-অফ-স্টেক-এ, ভ্যালিডেটররা Ethereum-এর একটি স্মার্ট কন্ট্র্যাক্টে ETH-এর আকারে মূলধন হিসেবে সুস্পষ্টভাবে স্টেক করে। ভ্যালিডেটর তখন নেটওয়ার্কের মাধ্যমে প্রচারিত নতুন ব্লকগুলো বৈধ কিনা তা পরীক্ষা করার জন্য এবং মাঝে মাঝে নিজেরাই নতুন ব্লক তৈরি এবং প্রচার করার জন্য দায়ী থাকে। যদি তারা নেটওয়ার্ককে প্রতারণা করার চেষ্টা করে (উদাহরণস্বরূপ, যখন তাদের একটি ব্লক পাঠানোর কথা তখন একাধিক ব্লক প্রস্তাব করা বা পরস্পরবিরোধী অ্যাটাস্টেশন পাঠানো), তাহলে তাদের স্টেক করা ETH-এর কিছু বা সমস্ত অংশ ধ্বংস করা যেতে পারে। + +## ভ্যালিডেটর {#validators} + +একজন ভ্যালিডেটর হিসেবে অংশগ্রহণ করার জন্য, একজন ব্যবহারকারীকে অবশ্যই ডিপোজিট কন্ট্র্যাক্টে 32 ETH জমা দিতে হবে এবং তিনটি পৃথক সফটওয়্যার চালাতে হবে: একটি এক্সিকিউশন ক্লায়েন্ট, একটি কনসেন্সাস ক্লায়েন্ট এবং একটি ভ্যালিডেটর ক্লায়েন্ট। তাদের ETH জমা দেওয়ার পরে, ব্যবহারকারী একটি অ্যাক্টিভেশন কিউতে যোগদান করে যা নেটওয়ার্কে নতুন ভ্যালিডেটরদের যোগদানের হারকে সীমিত করে। একবার সক্রিয় হয়ে গেলে, ভ্যালিডেটররা Ethereum নেটওয়ার্কের পিয়ারদের থেকে নতুন ব্লক গ্রহণ করে। ব্লকে ডেলিভার করা ট্রানজ্যাকশনগুলো পুনরায় এক্সিকিউট করা হয় এটি পরীক্ষা করতে যে Ethereum-এর স্টেটে প্রস্তাবিত পরিবর্তনগুলো বৈধ, এবং ব্লকের সিগনেচার পরীক্ষা করা হয়। তারপর ভ্যালিডেটর নেটওয়ার্ক জুড়ে সেই ব্লকের পক্ষে একটি ভোট (যাকে অ্যাটাস্টেশন বলা হয়) পাঠায়। + +যেখানে প্রুফ-অফ-ওয়ার্ক-এর অধীনে, ব্লকের সময় মাইনিং ডিফিকাল্টি দ্বারা নির্ধারিত হয়, সেখানে প্রুফ-অফ-স্টেক-এ টেম্পো স্থির থাকে। প্রুফ-অফ-স্টেক Ethereum-এ সময়কে স্লট (12 সেকেন্ড) এবং ইপক (32 স্লট)-এ ভাগ করা হয়। প্রতিটি স্লটে একজন ভ্যালিডেটরকে এলোমেলোভাবে ব্লক প্রপোজার হিসেবে নির্বাচিত করা হয়। এই ভ্যালিডেটর একটি নতুন ব্লক তৈরি করে এবং নেটওয়ার্কের অন্যান্য নোডগুলিতে পাঠানোর জন্য দায়ী থাকে। এছাড়াও প্রতিটি স্লটে, ভ্যালিডেটরদের একটি কমিটি এলোমেলোভাবে বেছে নেওয়া হয়, যাদের ভোট প্রস্তাবিত ব্লকের বৈধতা নির্ধারণ করতে ব্যবহৃত হয়। ভ্যালিডেটর সেটকে কমিটিগুলিতে ভাগ করা নেটওয়ার্কের লোড পরিচালনাযোগ্য রাখার জন্য গুরুত্বপূর্ণ। কমিটিগুলো ভ্যালিডেটর সেটকে এমনভাবে ভাগ করে যে প্রতিটি সক্রিয় ভ্যালিডেটর প্রতিটি ইপকে অ্যাটেস্ট করে, কিন্তু প্রতিটি স্লটে নয়। + +## Ethereum PoS-এ একটি ট্রানজ্যাকশন কিভাবে এক্সিকিউট হয় {#transaction-execution-ethereum-pos} + +নিচে Ethereum প্রুফ-অফ-স্টেক-এ কীভাবে একটি ট্রানজ্যাকশন এক্সিকিউট করা হয় তার একটি এন্ড-টু-এন্ড ব্যাখ্যা প্রদান করা হলো। + +1. একজন ব্যবহারকারী তাদের প্রাইভেট কী দিয়ে একটি [ট্রানজ্যাকশন](/developers/docs/transactions/) তৈরি করে এবং সাইন করে। এটি সাধারণত একটি ওয়ালেট বা [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) ইত্যাদির মতো একটি লাইব্রেরি দ্বারা পরিচালিত হয়, কিন্তু পর্দার আড়ালে ব্যবহারকারী Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/) ব্যবহার করে একটি নোডে অনুরোধ করে। ব্যবহারকারী গ্যাসের পরিমাণ নির্ধারণ করে যা তারা একজন ভ্যালিডেটরকে টিপস হিসেবে দিতে প্রস্তুত, যাতে তারা ব্লকটিতে ট্রানজ্যাকশনটি অন্তর্ভুক্ত করতে উৎসাহিত হয়। [টিপস](/developers/docs/gas/#priority-fee) ভ্যালিডেটরকে প্রদান করা হয়, যেখানে [বেস ফি](/developers/docs/gas/#base-fee) বার্ন করা হয়। +2. ট্রানজ্যাকশনটি একটি Ethereum [এক্সিকিউশন ক্লায়েন্ট](/developers/docs/nodes-and-clients/#execution-client)-এ জমা দেওয়া হয় যা এর বৈধতা যাচাই করে। এর মানে হল নিশ্চিত করা যে প্রেরকের কাছে ট্রানজ্যাকশনটি পূরণ করার জন্য যথেষ্ট ETH আছে এবং তারা সঠিক কী দিয়ে এটি সাইন করেছে। +3. ট্রানজ্যাকশনটি বৈধ হলে, এক্সিকিউশন ক্লায়েন্ট এটিকে তার স্থানীয় মেমপুলে (মুলতুবি থাকা ট্রানজ্যাকশনের তালিকা) যোগ করে এবং এক্সিকিউশন লেয়ার গসিপ নেটওয়ার্কের মাধ্যমে অন্যান্য নোডগুলিতে এটি সম্প্রচার করে। যখন অন্যান্য নোডগুলো ট্রানজ্যাকশনটি সম্পর্কে জানতে পারে, তখন তারাও এটিকে তাদের স্থানীয় মেমপুলে যোগ করে। উন্নত ব্যবহারকারীরা তাদের ট্রানজ্যাকশন সম্প্রচার করা থেকে বিরত থাকতে পারে এবং পরিবর্তে এটি [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview)-এর মতো বিশেষ ব্লক বিল্ডারদের কাছে ফরোয়ার্ড করতে পারে। এটি তাদের সর্বোচ্চ লাভের জন্য আসন্ন ব্লকগুলিতে ট্রানজ্যাকশনগুলো সংগঠিত করার অনুমতি দেয় ([MEV](/developers/docs/mev/#mev-extraction))। +4. নেটওয়ার্কের একটি ভ্যালিডেটর নোড হল বর্তমান স্লটের ব্লক প্রপোজার, যা পূর্বে RANDAO ব্যবহার করে ছদ্ম-এলোমেলোভাবে নির্বাচিত হয়েছে। এই নোডটি Ethereum ব্লকচেইনে যোগ করার জন্য পরবর্তী ব্লক তৈরি এবং সম্প্রচার করা এবং গ্লোবাল স্টেট আপডেট করার জন্য দায়ী। নোডটি তিনটি অংশ নিয়ে গঠিত: একটি এক্সিকিউশন ক্লায়েন্ট, একটি কনসেন্সাস ক্লায়েন্ট এবং একটি ভ্যালিডেটর ক্লায়েন্ট। এক্সিকিউশন ক্লায়েন্ট স্থানীয় মেমপুল থেকে ট্রানজ্যাকশনগুলোকে একটি "এক্সিকিউশন পেলোড"-এ বান্ডিল করে এবং একটি স্টেট পরিবর্তন তৈরি করার জন্য স্থানীয়ভাবে সেগুলোকে এক্সিকিউট করে। এই তথ্যটি কনসেন্সাস ক্লায়েন্টের কাছে পাঠানো হয় যেখানে এক্সিকিউশন পেলোড একটি "বিকন ব্লক"-এর অংশ হিসাবে মোড়ানো থাকে, যেটিতে পুরস্কার, জরিমানা, স্ল্যাশিং, অ্যাটাস্টেশন ইত্যাদি সম্পর্কিত তথ্যও থাকে যা নেটওয়ার্ককে চেইনের হেডে থাকা ব্লকের ক্রম সম্পর্কে একমত হতে সক্ষম করে। এক্সিকিউশন এবং কনসেন্সাস ক্লায়েন্টদের মধ্যে যোগাযোগ সম্পর্কে [কনসেন্সাস এবং এক্সিকিউশন ক্লায়েন্টদের সংযোগ করা](/developers/docs/networking-layer/#connecting-clients)-এ আরও বিস্তারিতভাবে বর্ণনা করা হয়েছে। +5. অন্যান্য নোডগুলো কনসেন্সাস লেয়ার গসিপ নেটওয়ার্কে নতুন বিকন ব্লক গ্রহণ করে। তারা এটি তাদের এক্সিকিউশন ক্লায়েন্টের কাছে পাঠায় যেখানে ট্রানজ্যাকশনগুলো প্রস্তাবিত স্টেট পরিবর্তন বৈধ কিনা তা নিশ্চিত করার জন্য স্থানীয়ভাবে পুনরায় এক্সিকিউট করা হয়। ভ্যালিডেটর ক্লায়েন্ট তখন প্রমাণ করে যে ব্লকটি বৈধ এবং চেইনের তাদের দৃষ্টিভঙ্গিতে এটি যৌক্তিক পরবর্তী ব্লক (অর্থাৎ এটি [ফর্ক পছন্দ নিয়ম](/developers/docs/consensus-mechanisms/pos/#fork-choice)-এ সংজ্ঞায়িত অ্যাটাস্টেশনের সর্বাধিক ওজন সহ চেইনের উপর ভিত্তি করে তৈরি হয়)। ব্লকটি প্রতিটি নোডের স্থানীয় ডাটাবেসে যোগ করা হয় যা এটিতে অ্যাটেস্ট করে। +6. যদি ট্রানজ্যাকশনটি দুটি চেকপয়েন্টের মধ্যে একটি "সুপারমেজররিটি লিঙ্ক" সহ একটি চেইনের অংশ হয়ে যায় তবে এটিকে "ফাইনাল" হিসাবে বিবেচনা করা যেতে পারে। প্রতিটি ইপকের শুরুতে চেকপয়েন্ট ঘটে এবং তারা এই বিষয়টির জন্য বিদ্যমান যে প্রতিটি স্লটে সক্রিয় ভ্যালিডেটরদের একটি উপসেট অ্যাটেস্ট করে, কিন্তু সকল সক্রিয় ভ্যালিডেটর প্রতিটি ইপকে অ্যাটেস্ট করে। সুতরাং, শুধুমাত্র ইপকগুলোর মধ্যে একটি 'সুপারমেজররিটি লিঙ্ক' প্রদর্শন করা যেতে পারে (এখানেই নেটওয়ার্কের মোট স্টেক করা ETH-এর ৬৬% দুটি চেকপয়েন্টে একমত হয়)। + +ফাইনালিটি সম্পর্কে আরও বিস্তারিত নিচে পাওয়া যাবে। + +## ফাইনালিটি {#finality} + +ডিস্ট্রিবিউটেড নেটওয়ার্কে একটি ট্রানজ্যাকশনের "ফাইনালিটি" থাকে যখন এটি এমন একটি ব্লকের অংশ হয় যা বিপুল পরিমাণ ETH বার্ন করা ছাড়া পরিবর্তন করা যায় না। প্রুফ-অফ-স্টেক Ethereum-এ, এটি "চেকপয়েন্ট" ব্লক ব্যবহার করে পরিচালিত হয়। প্রতিটি ইপকের প্রথম ব্লকটি একটি চেকপয়েন্ট। ভ্যালিডেটররা চেকপয়েন্টের জোড়ার জন্য ভোট দেয় যেগুলোকে এটি বৈধ বলে মনে করে। যদি একজোড়া চেকপয়েন্ট মোট স্টেক করা ETH-এর কমপক্ষে দুই-তৃতীয়াংশের প্রতিনিধিত্বকারী ভোট আকর্ষণ করে, তবে চেকপয়েন্টগুলো আপগ্রেড করা হয়। দুটির মধ্যে সাম্প্রতিকটি (টার্গেট) "যুক্তিযুক্ত" হয়ে যায়। দুটির মধ্যে পূর্বেরটি ইতিমধ্যেই যুক্তিযুক্ত কারণ এটি পূর্ববর্তী ইপকের "টার্গেট" ছিল। এখন এটি "ফাইনাল"-এ আপগ্রেড করা হয়েছে। চেকপয়েন্ট আপগ্রেড করার এই প্রক্রিয়াটি **[ক্যাসপার দ্য ফ্রেন্ডলি ফাইনালিটি গ্যাজেট (ক্যাসপার-এফএফজি)](https://arxiv.org/pdf/1710.09437)** দ্বারা পরিচালিত হয়। ক্যাসপার-এফএফজি হল কনসেন্সাসের জন্য একটি ব্লক ফাইনালিটি টুল। একবার একটি ব্লক ফাইনাল হয়ে গেলে, স্ট্যাকারদের সংখ্যাগরিষ্ঠ স্ল্যাশিং ছাড়া এটি রিভার্ট বা পরিবর্তন করা যায় না, যা এটিকে অর্থনৈতিকভাবে অকার্যকর করে তোলে। + +একটি ফাইনাল ব্লক রিভার্ট করতে, একজন আক্রমণকারীকে স্টেক করা ETH-এর মোট সরবরাহের অন্তত এক-তৃতীয়াংশ হারানোর প্রতিশ্রুতি দিতে হবে। এর সঠিক কারণ এই [Ethereum Foundation ব্লগ পোস্টে](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) ব্যাখ্যা করা হয়েছে। যেহেতু ফাইনালিটির জন্য দুই-তৃতীয়াংশ সংখ্যাগরিষ্ঠতার প্রয়োজন, তাই একজন আক্রমণকারী মোট স্টেকের এক-তৃতীয়াংশ দিয়ে ভোট দিয়ে নেটওয়ার্ককে ফাইনালিটিতে পৌঁছানো থেকে আটকাতে পারে। এর বিরুদ্ধে রক্ষা করার জন্য একটি মেকানিজম রয়েছে: [ইনঅ্যাক্টিভিটি লিক](https://eth2book.info/bellatrix/part2/incentives/inactivity)। এটি সক্রিয় হয় যখন চেইনটি চারটির বেশি ইপকের জন্য ফাইনাল হতে ব্যর্থ হয়। ইনঅ্যাক্টিভিটি লিক সংখ্যাগরিষ্ঠের বিরুদ্ধে ভোট দেওয়া ভ্যালিডেটরদের থেকে স্টেক করা ETH সরিয়ে দেয়, যা সংখ্যাগরিষ্ঠকে দুই-তৃতীয়াংশ সংখ্যাগরিষ্ঠতা পুনরুদ্ধার করতে এবং চেইনটিকে ফাইনাল করতে দেয়। + +## ক্রিপ্টো-ইকোনমিক সিকিউরিটি {#crypto-economic-security} + +একজন ভ্যালিডেটর চালানো একটি প্রতিশ্রুতি। ভ্যালিডেটরের কাছ থেকে ব্লক ভ্যালিডেশন এবং প্রপোজাল-এ অংশগ্রহণের জন্য পর্যাপ্ত হার্ডওয়্যার এবং কানেক্টিভিটি বজায় রাখার প্রত্যাশা করা হয়। এর বিনিময়ে, ভ্যালিডেটরকে ETH-এ অর্থ প্রদান করা হয় (তাদের স্টেক করা ব্যালেন্স বৃদ্ধি পায়)। অন্যদিকে, একজন ভ্যালিডেটর হিসাবে অংশগ্রহণ করা ব্যবহারকারীদের ব্যক্তিগত লাভ বা নাশকতার জন্য নেটওয়ার্কে আক্রমণ করার নতুন পথ খুলে দেয়। এটি প্রতিরোধ করার জন্য, ভ্যালিডেটররা যখন অংশগ্রহণের জন্য বলা হয় তখন ব্যর্থ হলে ETH পুরস্কার থেকে বঞ্চিত হয়, এবং তারা যদি অসাধুভাবে আচরণ করে তবে তাদের বিদ্যমান স্টেক ধ্বংস করা যেতে পারে। দুটি প্রধান আচরণকে অসাধু বলে বিবেচনা করা যেতে পারে: একটি স্লটে একাধিক ব্লক প্রস্তাব করা (দ্বিচারিতা) এবং পরস্পরবিরোধী অ্যাটাস্টেশন জমা দেওয়া। + +কত পরিমাণ ETH স্ল্যাশ করা হবে তা নির্ভর করে একই সময়ে কতজন ভ্যালিডেটরকেও স্ল্যাশ করা হচ্ছে তার উপর। এটি ["কোরিলেশন পেনাল্টি"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) নামে পরিচিত, এবং এটি সামান্য হতে পারে (নিজে থেকে স্ল্যাশ হওয়া একজন ভ্যালিডেটরের জন্য ~1% স্টেক) অথবা এর ফলে ভ্যালিডেটরের 100% স্টেক ধ্বংস হয়ে যেতে পারে (গণ স্ল্যাশিং ইভেন্ট)। এটি একটি বাধ্যতামূলক এক্সিট পিরিয়ডের মাঝপথে আরোপ করা হয় যা প্রথম দিনে একটি তাৎক্ষণিক জরিমানা (1 ETH পর্যন্ত) দিয়ে শুরু হয়, 18 তম দিনে কোরিলেশন পেনাল্টি এবং অবশেষে, 36 তম দিনে নেটওয়ার্ক থেকে বহিষ্কার করা হয়। তারা প্রতিদিন সামান্য অ্যাটাস্টেশন জরিমানা পায় কারণ তারা নেটওয়ার্কে উপস্থিত থাকে কিন্তু ভোট জমা দেয় না। এই সবকিছুর অর্থ হল একটি সমন্বিত আক্রমণ আক্রমণকারীর জন্য খুব ব্যয়বহুল হবে। + +## ফর্ক পছন্দ {#fork-choice} + +যখন নেটওয়ার্ক সর্বোত্তম এবং সততার সাথে কাজ করে, তখন চেইনের হেডে শুধুমাত্র একটি নতুন ব্লক থাকে এবং সমস্ত ভ্যালিডেটর এটিতে অ্যাটেস্ট করে। যাইহোক, নেটওয়ার্ক লেটেন্সি বা ব্লক প্রপোজার দ্বিমুখী আচরণ করার কারণে ভ্যালিডেটরদের চেইনের হেডের বিভিন্ন ভিউ থাকা সম্ভব। অতএব, কনসেন্সাস ক্লায়েন্টদের একটি অ্যালগরিদম প্রয়োজন যা নির্ধারণ করবে কোনটি পছন্দ করা হবে। প্রুফ-অফ-স্টেক Ethereum-এ ব্যবহৃত অ্যালগরিদমটিকে [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) বলা হয়, এবং এটি সেই ফর্কটি সনাক্ত করে কাজ করে যার ইতিহাসে অ্যাটাস্টেশনের সর্বাধিক ওজন রয়েছে। + +## প্রুফ-অফ-স্টেক এবং নিরাপত্তা {#pos-and-security} + +প্রুফ-অফ-ওয়ার্কের মতো প্রুফ-অফ-স্টেকের ক্ষেত্রেও [51% আক্রমণের](https://www.investopedia.com/terms/1/51-attack.asp) হুমকি এখনও বিদ্যমান, তবে এটি আক্রমণকারীদের জন্য আরও ঝুঁকিপূর্ণ। একজন আক্রমণকারীর 51% স্টেক করা ETH-এর প্রয়োজন হবে। তারা তখন তাদের নিজস্ব অ্যাটাস্টেশন ব্যবহার করে নিশ্চিত করতে পারে যে তাদের পছন্দের ফর্কটিই সবচেয়ে বেশি সঞ্চিত অ্যাটাস্টেশন সহ ছিল। সঞ্চিত অ্যাটাস্টেশনের 'ওজন' হল যা কনসেন্সাস ক্লায়েন্টরা সঠিক চেইন নির্ধারণ করতে ব্যবহার করে, তাই এই আক্রমণকারী তাদের ফর্কটিকে ক্যানোনিকাল করে তুলতে সক্ষম হবে। যাইহোক, প্রুফ-অফ-ওয়ার্কের উপর প্রুফ-অফ-স্টেকের একটি শক্তি হল যে সম্প্রদায়ের একটি পাল্টা আক্রমণ মাউন্ট করার নমনীয়তা রয়েছে। উদাহরণস্বরূপ, সৎ ভ্যালিডেটররা সংখ্যালঘু চেইনে নির্মাণ চালিয়ে যাওয়ার এবং আক্রমণকারীর ফর্ক উপেক্ষা করার সিদ্ধান্ত নিতে পারে, এবং অ্যাপস, এক্সচেঞ্জ এবং পুলগুলোকে একই কাজ করতে উত্সাহিত করতে পারে। তারা আক্রমণকারীকে জোরপূর্বক নেটওয়ার্ক থেকে সরিয়ে দেওয়ার এবং তাদের স্টেক করা ETH ধ্বংস করার সিদ্ধান্তও নিতে পারে। এগুলো ৫১% আক্রমণের বিরুদ্ধে শক্তিশালী অর্থনৈতিক প্রতিরক্ষা। + +৫১% আক্রমণের বাইরে, খারাপ অভিনেতারা অন্যান্য ধরণের দূষিত কার্যকলাপের চেষ্টাও করতে পারে, যেমন: + +- লং-রেঞ্জ আক্রমণ (যদিও ফাইনালিটি গ্যাজেট এই আক্রমণ ভেক্টরকে নিষ্ক্রিয় করে) +- স্বল্প পরিসরের 'রিঅর্গস' (যদিও প্রপোজার বুস্টিং এবং অ্যাটাস্টেশন ডেডলাইন এটি প্রশমিত করে) +- বাউন্সিং এবং ব্যালেন্সিং আক্রমণ (প্রপোজার বুস্টিং দ্বারাও প্রশমিত, এবং এই আক্রমণগুলো যাইহোক শুধুমাত্র আদর্শ নেটওয়ার্ক অবস্থার অধীনে প্রদর্শিত হয়েছে) +- অ্যাভাল্যাঞ্চ আক্রমণ (ফর্ক পছন্দ অ্যালগরিদমের শুধুমাত্র সর্বশেষ মেসেজ বিবেচনা করার নিয়ম দ্বারা নিষ্ক্রিয় করা হয়) + +সামগ্রিকভাবে, প্রুফ-অফ-স্টেক, যেমনটি Ethereum-এ প্রয়োগ করা হয়েছে, প্রুফ-অফ-ওয়ার্কের চেয়ে অর্থনৈতিকভাবে বেশি সুরক্ষিত বলে প্রমাণিত হয়েছে। + +## সুবিধা এবং অসুবিধা {#pros-and-cons} + +| যেসব বিষয়ে এর সুফল পাওয়া যায় | কনস | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | +| স্টেকিং ব্যক্তিদের নেটওয়ার্ক সুরক্ষিত করতে অংশগ্রহণ করা সহজ করে তোলে, যা বিকেন্দ্রীকরণকে উৎসাহিত করে। ভ্যালিডেটর নোড একটি সাধারণ ল্যাপটপে চালানো যেতে পারে। স্টেকিং পুল ব্যবহারকারীদের 32 ETH না থাকলেও স্টেক করার অনুমতি দেয়। | প্রুফ-অফ-ওয়ার্কের তুলনায় প্রুফ-অফ-স্টেক নতুন এবং কম পরীক্ষিত | +| স্টেকিং আরও বিকেন্দ্রীভূত। PoW মাইনিংয়ের ক্ষেত্রে যেভাবে ইকোনোমিক্স অফ স্কেল প্রযোজ্য, এক্ষেত্রে তেমনভাবে হয় না। | প্রুফ-অফ-ওয়ার্কের চেয়ে প্রুফ-অফ-স্টেক প্রয়োগ করা আরও জটিল | +| প্রুফ-অফ-স্টেক প্রুফ-অফ-ওয়ার্কের চেয়ে বেশি ক্রিপ্টো-অর্থনৈতিক নিরাপত্তা প্রদান করে | Ethereum-এর প্রুফ-অফ-স্টেকে অংশগ্রহণ করার জন্য ব্যবহারকারীদের তিনটি সফটওয়্যার চালাতে হবে। | +| নেটওয়ার্ক অংশগ্রহণকারীদের উৎসাহিত করার জন্য নতুন ETH-এর কম ইস্যুয়েন্স প্রয়োজন | | + +### প্রুফ-অফ-ওয়ার্ক-এর সঙ্গে তুলনা {#comparison-to-proof-of-work} + +Ethereum মূলত প্রুফ-অফ-ওয়ার্ক ব্যবহার করত কিন্তু সেপ্টেম্বর ২০২২-এ প্রুফ-অফ-স্টেকে পরিবর্তিত হয়েছে। PoS, PoW-এর তুলনায় বেশ কিছু সুবিধা প্রদান করে, যেমন: + +- উন্নত শক্তি দক্ষতা – প্রুফ-অফ-ওয়ার্ক কম্পিউটেশনে প্রচুর শক্তি ব্যবহার করার কোনো প্রয়োজন নেই +- প্রবেশের জন্য কম বাধা, হার্ডওয়্যারের প্রয়োজনীয়তা হ্রাস – নতুন ব্লক তৈরি করার সুযোগ পেতে এলিট হার্ডওয়্যারের কোনো প্রয়োজন নেই +- কেন্দ্রীভূতকরণের ঝুঁকি হ্রাস – প্রুফ-অফ-স্টেক নেটওয়ার্ক সুরক্ষিত করার জন্য আরও নোডের দিকে নিয়ে যাওয়া উচিত +- কম শক্তির প্রয়োজনীয়তার কারণে অংশগ্রহণে উৎসাহিত করার জন্য কম ETH ইস্যুয়েন্স প্রয়োজন +- অসদাচরণের জন্য অর্থনৈতিক জরিমানা প্রুফ-অফ-ওয়ার্কের তুলনায় একজন আক্রমণকারীর জন্য ৫১% স্টাইলের আক্রমণকে আরও ব্যয়বহুল করে তোলে +- যদি ৫১% আক্রমণ ক্রিপ্টো-অর্থনৈতিক প্রতিরক্ষা অতিক্রম করে, তাহলে কমিউনিটি একটি সৎ চেইনের সামাজিক পুনরুদ্ধারের আশ্রয় নিতে পারে। + +## আরও পড়ুন {#further-reading} + +- [প্রুফ অফ স্টেক FAQ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _ভিটালিক বুটেরিন_ +- [প্রুফ অফ স্টেক কী](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _কনসেনসিস_ +- [প্রুফ অফ স্টেক কী এবং কেন এটি গুরুত্বপূর্ণ](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _ভিটালিক বুটেরিন_ +- [কেন প্রুফ অফ স্টেক (নভেম্বর ২০২০)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _ভিটালিক বুটেরিন_ +- [প্রুফ অফ স্টেক: আমি কীভাবে দুর্বল বিষয়বস্তুকে ভালোবাসতে শিখলাম](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _ভিটালিক বুটেরিন_ +- [প্রুফ-অফ-স্টেক Ethereum আক্রমণ এবং প্রতিরক্ষা](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [একটি প্রুফ অফ স্টেক ডিজাইন দর্শন](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _ভিটালিক বুটেরিন_ +- [ভিডিও: ভিটালিক বুটেরিন লেক্স ফ্রিডম্যানকে প্রুফ-অফ-স্টেক ব্যাখ্যা করছেন](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## সম্পর্কিত বিষয় {#related-topics} + +- [প্রুফ-অফ-ওয়ার্ক](/developers/docs/consensus-mechanisms/pow/) +- [প্রুফ-অফ-অথোরিটি](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..21e75b735a2 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "প্রুফ-অফ-স্টেক ইথেরিয়ামের কী" +description: "ইথেরিয়ামের প্রুফ-অফ-স্টেক কনসেন্সাস মেকানিজমে ব্যবহৃত কী-গুলোর একটি ব্যাখ্যা" +lang: bn +--- + +ইথেরিয়াম পাবলিক-প্রাইভেট কী ক্রিপ্টোগ্রাফি ব্যবহার করে ব্যবহারকারীর সম্পদ সুরক্ষিত করে। পাবলিক কী একটি ইথেরিয়াম অ্যাড্রেসের ভিত্তি হিসাবে ব্যবহৃত হয়—অর্থাৎ, এটি সাধারণ জনগণের কাছে দৃশ্যমান এবং একটি অনন্য শনাক্তকারী হিসাবে ব্যবহৃত হয়। প্রাইভেট (বা 'গোপন') কী শুধুমাত্র একজন অ্যাকাউন্টের মালিকের কাছে অ্যাক্সেসযোগ্য হওয়া উচিত। প্রাইভেট কী লেনদেন এবং ডেটা 'স্বাক্ষর' করার জন্য ব্যবহৃত হয় যাতে ক্রিপ্টোগ্রাফি প্রমাণ করতে পারে যে ধারক একটি নির্দিষ্ট প্রাইভেট কী-এর কিছু ক্রিয়াকলাপ অনুমোদন করেছেন। + +ইথেরিয়ামের কী-গুলো [ইলিপটিক-কার্ভ ক্রিপ্টোগ্রাফি](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) ব্যবহার করে তৈরি করা হয়। + +যাইহোক, যখন ইথেরিয়াম [প্রুফ-অফ-ওয়ার্ক](/developers/docs/consensus-mechanisms/pow) থেকে [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos)-এ পরিবর্তিত হয়, তখন ইথেরিয়ামে একটি নতুন ধরণের কী যোগ করা হয়েছিল। আসল কী-গুলো আগের মতোই কাজ করে—অ্যাকাউন্ট সুরক্ষিতকারী ইলিপটিক-কার্ভ-ভিত্তিক কী-গুলোতে কোনও পরিবর্তন করা হয়নি। যাইহোক, ETH স্টেকিং এবং ভ্যালিডেটর চালানোর মাধ্যমে প্রুফ-অফ-স্টেক-এ অংশগ্রহণের জন্য ব্যবহারকারীদের একটি নতুন ধরনের কী-এর প্রয়োজন ছিল। এই প্রয়োজনটি বিপুল সংখ্যক ভ্যালিডেটরের মধ্যে প্রেরিত অনেকগুলো মেসেজের সাথে সম্পর্কিত স্কেলেবিলিটি চ্যালেঞ্জ থেকে উদ্ভূত হয়েছিল, যার জন্য একটি ক্রিপ্টোগ্রাফিক পদ্ধতির প্রয়োজন ছিল যা সহজেই একত্রিত করা যেতে পারে যাতে নেটওয়ার্ককে কনসেন্সাসে আসতে প্রয়োজনীয় যোগাযোগের পরিমাণ কমানো যায়। + +এই নতুন ধরনের কী [**বনিহ-লিন-শাচাম (BLS)** সিগনেচার স্কিম](https://wikipedia.org/wiki/BLS_digital_signature) ব্যবহার করে। BLS সিগনেচারের একটি অত্যন্ত কার্যকর একত্রীকরণ সক্ষম করে কিন্তু একত্রিত পৃথক ভ্যালিডেটর কী-গুলোর রিভার্স ইঞ্জিনিয়ারিংয়ের অনুমতি দেয় এবং ভ্যালিডেটরদের মধ্যে ক্রিয়া পরিচালনা করার জন্য এটি আদর্শ। + +## দুই ধরনের ভ্যালিডেটর কী {#two-types-of-keys} + +প্রুফ-অফ-স্টেক-এ স্যুইচ করার আগে, ইথেরিয়াম ব্যবহারকারীদের তাদের তহবিল অ্যাক্সেস করার জন্য শুধুমাত্র একটি ইলিপটিক-কার্ভ-ভিত্তিক প্রাইভেট কী ছিল। প্রুফ-অফ-স্টেক প্রবর্তনের সাথে, যে ব্যবহারকারীরা সোলো স্টেকার হতে চেয়েছিলেন তাদের একটি **ভ্যালিডেটর কী** এবং একটি **উইথড্রয়াল কী**-এরও প্রয়োজন ছিল। + +### ভ্যালিডেটর কী {#validator-key} + +ভ্যালিডেটর সাইনিং কী দুটি উপাদান নিয়ে গঠিত: + +- ভ্যালিডেটর **প্রাইভেট** কী +- ভ্যালিডেটর **পাবলিক** কী + +ভ্যালিডেটর প্রাইভেট কী-এর উদ্দেশ্য হল অনচেইন অপারেশন যেমন ব্লক প্রস্তাবনা এবং অ্যাটেস্টেশন স্বাক্ষর করা। এই কারণে, এই কী-গুলো অবশ্যই একটি হট ওয়ালেটে রাখতে হবে। + +এই নমনীয়তার সুবিধা হল ভ্যালিডেটর সাইনিং কী-গুলো খুব দ্রুত এক ডিভাইস থেকে অন্য ডিভাইসে সরানো যায়, তবে, যদি সেগুলি হারিয়ে যায় বা চুরি হয়ে যায়, তাহলে একজন চোর কয়েকটি উপায়ে **ক্ষতিকরভাবে কাজ** করতে পারে: + +- এর মাধ্যমে ভ্যালিডেটরকে স্ল্যাশ করান: + - একজন প্রস্তাবক হয়ে একই স্লটের জন্য দুটি ভিন্ন বীকন ব্লকে স্বাক্ষর করা + - একজন অ্যাটেস্টার হয়ে এমন একটি অ্যাটেস্টেশনে স্বাক্ষর করা যা অন্য একটিকে "ঘিরে" রাখে + - একজন অ্যাটেস্টার হয়ে একই টার্গেটযুক্ত দুটি ভিন্ন অ্যাটেস্টেশনে স্বাক্ষর করা +- একটি স্বেচ্ছাসেবী প্রস্থান করতে বাধ্য করা, যা ভ্যালিডেটরকে স্টেকিং থেকে বিরত করে, এবং উইথড্রয়াল কী-এর মালিককে তার ETH ব্যালেন্সে অ্যাক্সেস দেয়। + +যখন একজন ব্যবহারকারী স্টেকিং ডিপোজিট কন্ট্রাক্টে ETH জমা করে তখন **ভ্যালিডেটর পাবলিক কী** লেনদেনের ডেটাতে অন্তর্ভুক্ত থাকে। এটি _ডিপোজিট ডেটা_ হিসাবে পরিচিত এবং এটি ইথেরিয়ামকে ভ্যালিডেটর শনাক্ত করতে দেয়। + +### উইথড্রয়াল ক্রেডেনশিয়াল {#withdrawal-credentials} + +প্রতিটি ভ্যালিডেটরের _উইথড্রয়াল ক্রেডেনশিয়াল_ হিসাবে পরিচিত একটি বৈশিষ্ট্য রয়েছে। এই 32-বাইট ফিল্ডের প্রথম বাইট অ্যাকাউন্টের ধরন শনাক্ত করে: `0x00` আসল BLS (প্রি-শাপেলা, নন-উইথড্রয়েবল) ক্রেডেনশিয়াল প্রতিনিধিত্ব করে, `0x01` একটি এক্সিকিউশন অ্যাড্রেসে নির্দেশকারী লিগ্যাসি ক্রেডেনশিয়াল প্রতিনিধিত্ব করে, এবং `0x02` আধুনিক কম্পাউন্ডিং ক্রেডেনশিয়াল ধরনের প্রতিনিধিত্ব করে। + +`0x00` BLS কী সহ ভ্যালিডেটরদের অবশ্যই অতিরিক্ত ব্যালেন্স পেমেন্ট বা স্টেকিং থেকে সম্পূর্ণ উইথড্রয়াল সক্রিয় করার জন্য একটি এক্সিকিউশন অ্যাড্রেসে নির্দেশ করতে এই ক্রেডেনশিয়ালগুলো আপডেট করতে হবে। এটি প্রাথমিক কী জেনারেশনের সময় ডিপোজিট ডেটাতে একটি এক্সিকিউশন অ্যাড্রেস প্রদান করে, _অথবা_ পরবর্তী সময়ে একটি `BLSToExecutionChange` মেসেজ স্বাক্ষর এবং সম্প্রচার করতে উইথড্রয়াল কী ব্যবহার করে করা যেতে পারে। + +[ভ্যালিডেটর উইথড্রয়াল ক্রেডেনশিয়াল সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### উইথড্রয়াল কী {#withdrawal-key} + +প্রাথমিক জমার সময় সেট করা না হলে, উইথড্রয়াল ক্রেডেনশিয়ালগুলোকে একটি এক্সিকিউশন অ্যাড্রেসে নির্দেশ করার জন্য আপডেট করতে উইথড্রয়াল কী-এর প্রয়োজন হবে। এটি অতিরিক্ত ব্যালেন্স পেমেন্ট প্রক্রিয়া শুরু করতে সক্ষম করবে এবং ব্যবহারকারীদের তাদের স্টেক করা ETH সম্পূর্ণরূপে উইথড্র করার অনুমতিও দেবে। + +ভ্যালিডেটর কী-গুলোর মতোই, উইথড্রয়াল কী-গুলোও দুটি উপাদান নিয়ে গঠিত: + +- উইথড্রয়াল **প্রাইভেট** কী +- উইথড্রয়াল **পাবলিক** কী + +উইথড্রয়াল ক্রেডেনশিয়াল `0x01` টাইপে আপডেট করার আগে এই কী হারিয়ে ফেলার অর্থ হল ভ্যালিডেটরের ব্যালেন্সে অ্যাক্সেস হারানো। ভ্যালিডেটর এখনও অ্যাটেস্টেশন এবং ব্লক স্বাক্ষর করতে পারে কারণ এই ক্রিয়াকলাপগুলোর জন্য ভ্যালিডেটরের প্রাইভেট কী প্রয়োজন, তবে উইথড্রয়াল কী হারিয়ে গেলে কোনো ইনসেন্টিভ থাকে না বললেই চলে। + +ইথেরিয়াম অ্যাকাউন্ট কী থেকে ভ্যালিডেটর কী আলাদা করার ফলে একজন একক ব্যবহারকারী একাধিক ভ্যালিডেটর চালাতে পারে। + +![ভ্যালিডেটর কী স্কিম্যাটিক](validator-key-schematic.png) + +**দ্রষ্টব্য**: স্টেকিংয়ের দায়িত্ব থেকে প্রস্থান করা এবং একটি ভ্যালিডেটরের ব্যালেন্স উইথড্র করার জন্য বর্তমানে ভ্যালিডেটর কী দিয়ে একটি [ভলান্টারি এক্সিট মেসেজ (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) স্বাক্ষর করতে হয়। যাইহোক, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) একটি প্রস্তাব যা ভবিষ্যতে একজন ব্যবহারকারীকে উইথড্রয়াল কী দিয়ে এক্সিট মেসেজ স্বাক্ষর করে একটি ভ্যালিডেটরের প্রস্থান ট্রিগার করতে এবং তার ব্যালেন্স উইথড্র করতে দেবে। এটি [স্টেকিং-অ্যাজ-এ-সার্ভিস প্রদানকারী](/staking/saas/#what-is-staking-as-a-service)-দের কাছে ETH ডেলিগেটকারী স্টেকারদের তাদের তহবিলের নিয়ন্ত্রণে থাকতে সক্ষম করে বিশ্বাসের অনুমান হ্রাস করবে। + +## একটি সিড ফ্রেজ থেকে কী পাওয়া {#deriving-keys-from-seed} + +যদি প্রতি 32 ETH স্টেকের জন্য 2টি সম্পূর্ণ স্বাধীন কী-এর একটি নতুন সেটের প্রয়োজন হত, তাহলে কী ম্যানেজমেন্ট দ্রুত কষ্টসাধ্য হয়ে যেত, বিশেষ করে একাধিক ভ্যালিডেটর চালানো ব্যবহারকারীদের জন্য। এর পরিবর্তে, একটি একক সাধারণ সিক্রেট থেকে একাধিক ভ্যালিডেটর কী পাওয়া যেতে পারে এবং সেই একক সিক্রেট সংরক্ষণ করা একাধিক ভ্যালিডেটর কী-তে অ্যাক্সেসের অনুমতি দেয়। + +[নেমোনিক্স](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) এবং পাথগুলি হল প্রধান বৈশিষ্ট্য যা ব্যবহারকারীরা প্রায়শই তাদের ওয়ালেট [অ্যাক্সেস করার](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) সময় সম্মুখীন হন। নেমোনিক হল শব্দের একটি ক্রম যা একটি প্রাইভেট কী-এর জন্য একটি প্রাথমিক সিড হিসাবে কাজ করে। অতিরিক্ত ডেটার সাথে মিলিত হলে, নেমোনিক 'মাস্টার কী' নামে পরিচিত একটি হ্যাস তৈরি করে। এটিকে একটি গাছের মূল হিসাবে ভাবা যেতে পারে। এই মূল থেকে শাখাগুলো একটি অনুক্রমিক পাথ ব্যবহার করে পাওয়া যেতে পারে যাতে চাইল্ড নোডগুলো তাদের প্যারেন্ট নোডের হ্যাস এবং ট্রিতে তাদের ইন্ডেক্সের সংমিশ্রণ হিসাবে থাকতে পারে। নেমোনিক-ভিত্তিক কী জেনারেশনের জন্য [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) এবং [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) স্ট্যান্ডার্ড সম্পর্কে পড়ুন। + +এই পাথগুলোর নিম্নলিখিত কাঠামো রয়েছে, যা হার্ডওয়্যার ওয়ালেটের সাথে ইন্টারঅ্যাক্ট করা ব্যবহারকারীদের কাছে পরিচিত হবে: + +``` +m/44'/60'/0'/0` +``` + +এই পাথের স্ল্যাশগুলো প্রাইভেট কী-এর উপাদানগুলোকে নিম্নরূপ পৃথক করে: + +``` +master_key / purpose / coin_type / account / change / address_index +``` + +এই যুক্তিটি ব্যবহারকারীদের একটি একক **নেমোনিক ফ্রেজ**-এর সাথে যত বেশি সম্ভব ভ্যালিডেটর সংযুক্ত করতে সক্ষম করে কারণ ট্রি রুটটি সাধারণ হতে পারে, এবং শাখাগুলিতে পার্থক্য করা যেতে পারে। ব্যবহারকারী নেমোনিক ফ্রেজ থেকে **যেকোনো সংখ্যক কী** পেতে পারেন। + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +প্রতিটি শাখা একটি `/` দ্বারা পৃথক করা হয়েছে তাই `m/2` মানে মাস্টার কী দিয়ে শুরু করুন এবং শাখা 2 অনুসরণ করুন। নীচের স্কিম্যাটিকে একটি একক নেমোনিক ফ্রেজ তিনটি উইথড্রয়াল কী সংরক্ষণ করতে ব্যবহৃত হয়, প্রতিটির সাথে দুটি সংশ্লিষ্ট ভ্যালিডেটর রয়েছে। + +![ভ্যালিডেটর কী লজিক](multiple-keys.png) + +## আরও পড়ুন {#further-reading} + +- [কার্ল বিকহুইজেনের ইথেরিয়াম ফাউন্ডেশন ব্লগ পোস্ট](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 BLS12-381 কী জেনারেশন](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: এক্সিকিউশন লেয়ার ট্রিগারড এক্সিট](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [বৃহৎ স্কেলে কী ম্যানেজমেন্ট](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..7d74fffe7f5 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "প্রুফ-অফ-স্টেক বনাম প্রুফ-অফ-ওয়ার্ক" +description: "ইথেরিয়ামের প্রুফ-অফ-স্টেক এবং প্রুফ-অফ-ওয়ার্ক ভিত্তিক কনসেন্সাস মেকানিজমের মধ্যে একটি তুলনা" +lang: bn +--- + +যখন ইথেরিয়াম চালু করা হয়েছিল, তখন ইথেরিয়ামকে সুরক্ষিত করার জন্য বিশ্বাসযোগ্য হওয়ার আগে প্রুফ-অফ-স্টেকের অনেক গবেষণা এবং উন্নয়নের প্রয়োজন ছিল। প্রুফ-অফ-ওয়ার্ক একটি সহজতর প্রক্রিয়া ছিল যা ইতিমধ্যেই বিটকয়েন দ্বারা প্রমাণিত হয়েছিল, যার অর্থ হল মূল ডেভেলপাররা ইথেরিয়াম চালু করার জন্য এটিকে অবিলম্বে বাস্তবায়ন করতে পারত। প্রুফ-অফ-স্টেককে এমন পর্যায়ে বিকশিত করতে আরও আট বছর সময় লেগেছিল যেখানে এটি বাস্তবায়ন করা যেতে পারে। + +এই পৃষ্ঠাটি ইথেরিয়ামের প্রুফ-অফ-ওয়ার্ক থেকে প্রুফ-অফ-স্টেকে পরিবর্তনের পেছনের যুক্তি এবং এর সাথে জড়িত ট্রেড-অফগুলি ব্যাখ্যা করে। + +## নিরাপত্তা {#security} + +ইথেরিয়াম গবেষকরা প্রুফ-অফ-ওয়ার্কের চেয়ে প্রুফ-অফ-স্টেককে বেশি সুরক্ষিত বলে মনে করেন। যাইহোক, এটি শুধুমাত্র সম্প্রতি আসল ইথেরিয়াম মেইননেটের জন্য প্রয়োগ করা হয়েছে এবং এটি প্রুফ-অফ-ওয়ার্কের চেয়ে কম সময়-পরীক্ষিত। নিম্নলিখিত বিভাগগুলিতে প্রুফ-অফ-ওয়ার্কের তুলনায় প্রুফ-অফ-স্টেকের নিরাপত্তা মডেলের সুবিধা এবং অসুবিধাগুলি নিয়ে আলোচনা করা হয়েছে। + +### আক্রমণের খরচ {#cost-to-attack} + +প্রুফ-অফ-স্টেকে, ভ্যালিডেটরদের একটি স্মার্ট কন্ট্র্যাক্টে কমপক্ষে 32 ETH এসক্রো ("স্টেক") করতে হয়। ভুল আচরণকারী ভ্যালিডেটরদের শাস্তি দিতে ইথেরিয়াম স্টেক করা ইথার ধ্বংস করতে পারে। কনসেন্সাসে পৌঁছানোর জন্য, মোট স্টেক করা ইথারের কমপক্ষে 66% একটি নির্দিষ্ট ব্লক সেটের পক্ষে ভোট দিতে হবে। স্টেক এর >=66% দ্বারা ভোট দেওয়া ব্লকগুলি "চূড়ান্ত" হয়ে যায়, যার অর্থ সেগুলি সরানো বা পুনর্গঠিত করা যাবে না। + +নেটওয়ার্কে আক্রমণ করার অর্থ হতে পারে চেইনকে চূড়ান্ত করা থেকে বিরত রাখা বা ক্যানোনিকাল চেইনে ব্লকগুলির একটি নির্দিষ্ট সংগঠন নিশ্চিত করা যা কোনোভাবে আক্রমণকারীকে উপকৃত করে। এর জন্য আক্রমণকারীকে হয় বিপুল পরিমাণ ইথার জমা করে সরাসরি ভোট দিয়ে বা সৎ ভ্যালিডেটরদের একটি নির্দিষ্ট উপায়ে ভোট দেওয়ার জন্য প্রতারণা করে সৎ কনসেন্সাসের পথ পরিবর্তন করতে হয়। সৎ ভ্যালিডেটরদেরকে প্রতারণা করে এমন পরিশীলিত, কম-সম্ভাব্য আক্রমণগুলি বাদ দিলে, ইথেরিয়ামকে আক্রমণ করার খরচ হল সেই স্টেকের খরচ যা একজন আক্রমণকারীকে তাদের পক্ষে কনসেন্সাসকে প্রভাবিত করার জন্য জমা করতে হবে। + +আক্রমণের সর্বনিম্ন খরচ হল মোট স্টেকের >33%। মোট স্টেকের >33% ধারণকারী একজন আক্রমণকারী কেবল অফলাইনে গিয়ে একটি ফাইনালিটি বিলম্বের কারণ হতে পারে। এটি নেটওয়ার্কের জন্য একটি তুলনামূলকভাবে ছোট সমস্যা কারণ এখানে "ইনঅ্যাকটিভিটি লিক" নামে পরিচিত একটি প্রক্রিয়া রয়েছে যা অফলাইন ভ্যালিডেটরদের থেকে স্টেক ফাঁস করে যতক্ষণ না অনলাইন সংখ্যাগরিষ্ঠ স্টেকের 66% প্রতিনিধিত্ব করে এবং চেইনটিকে আবার চূড়ান্ত করতে পারে। তাত্ত্বিকভাবে একজন আক্রমণকারীর পক্ষে মোট স্টেকের 33%-এর সামান্য বেশি দিয়ে দ্বিগুণ ফাইনালিটি ঘটানোও সম্ভব, যখন তাদের ব্লক প্রযোজক হতে বলা হয় তখন একটির পরিবর্তে দুটি ব্লক তৈরি করে এবং তারপর তাদের সমস্ত ভ্যালিডেটরদের সাথে দ্বিগুণ-ভোট দিয়ে। প্রতিটি ফর্কের জন্য শুধুমাত্র অবশিষ্ট সৎ ভ্যালিডেটরদের 50%-কে প্রথমে প্রতিটি ব্লক দেখতে হবে, তাই যদি তারা তাদের বার্তাগুলিকে ঠিক সময়ে পরিচালনা করতে পারে, তবে তারা উভয় ফর্ককেই চূড়ান্ত করতে সক্ষম হতে পারে। এটির সফলতার সম্ভাবনা কম, কিন্তু যদি একজন আক্রমণকারী ডাবল-ফাইনালিটি ঘটাতে সক্ষম হয়, তাহলে ইথেরিয়াম সম্প্রদায়কে একটি ফর্ক অনুসরণ করার সিদ্ধান্ত নিতে হবে, সেক্ষেত্রে আক্রমণকারীর ভ্যালিডেটরদের অন্যটিতে স্ল্যাশ করা হবে। + +মোট স্টেকের >33% দিয়ে, একজন আক্রমণকারীর ইথেরিয়াম নেটওয়ার্কে একটি ছোট (ফাইনালিটি বিলম্ব) বা আরও গুরুতর (ডাবল ফাইনালিটি) প্রভাব ফেলার সুযোগ থাকে। নেটওয়ার্কে 14,000,000-এর বেশি ETH স্টেক করা এবং $1000/ETH-এর একটি প্রতিনিধি মূল্যের সাথে, এই আক্রমণগুলি মাউন্ট করার জন্য সর্বনিম্ন খরচ হল `1000 x 14,000,000 x 0.33 = $4,620,000,000`। আক্রমণকারী স্ল্যাশিংয়ের মাধ্যমে এই অর্থ হারাবে এবং নেটওয়ার্ক থেকে বের হয়ে যাবে। আবার আক্রমণ করার জন্য, তাদের স্টেকের >33% (আবার) জমা করতে হবে এবং তা পুড়িয়ে ফেলতে হবে (আবার)। নেটওয়ার্কে আক্রমণ করার প্রতিটি প্রচেষ্টায় >$4.6 বিলিয়ন খরচ হবে ($1000/ETH এবং 14M ETH স্টেক করা অবস্থায়)। আক্রমণকারীকে যখন স্ল্যাশ করা হয় তখন নেটওয়ার্ক থেকে বের করে দেওয়া হয় এবং পুনরায় যোগদানের জন্য তাদের একটি অ্যাক্টিভেশন কিউতে যোগ দিতে হয়। এর মানে হল যে একটি পুনরাবৃত্ত আক্রমণের হার শুধুমাত্র সেই হারের মধ্যে সীমাবদ্ধ নয় যে হারে আক্রমণকারী মোট স্টেকের >33% জমা করতে পারে বরং তাদের সমস্ত ভ্যালিডেটরদের নেটওয়ার্কে অনবোর্ড করতে যে সময় লাগে তার দ্বারাও সীমাবদ্ধ। প্রতিবার আক্রমণকারী আক্রমণ করার সময়, তারা অনেক বেশি দরিদ্র হয়ে যায়, এবং ফলস্বরূপ সরবরাহ ধাক্কার জন্য সম্প্রদায়ের বাকিরা আরও ধনী হয়। + +অন্যান্য আক্রমণ, যেমন 51% আক্রমণ বা মোট স্টেকের 66% সহ ফাইনালিটি রিভার্সন, এর জন্য যথেষ্ট বেশি ETH প্রয়োজন এবং আক্রমণকারীর জন্য অনেক বেশি ব্যয়বহুল। + +প্রুফ-অফ-ওয়ার্ক-এর সাথে এর তুলনা করুন। প্রুফ-অফ-ওয়ার্ক ইথেরিয়ামে একটি আক্রমণ শুরু করার খরচ ছিল ধারাবাহিকভাবে মোট নেটওয়ার্ক হ্যাস রেটের >50% মালিকানার খরচ। ধারাবাহিকভাবে প্রুফ-অফ-ওয়ার্ক সমাধানগুলি গণনা করার জন্য অন্যান্য মাইনারদের ছাড়িয়ে যাওয়ার জন্য পর্যাপ্ত কম্পিউটিং পাওয়ারের হার্ডওয়্যার এবং চলমান খরচের পরিমাণ ছিল এটি। ইথেরিয়াম বেশিরভাগই ASIC-এর পরিবর্তে GPU ব্যবহার করে মাইন করা হয়েছিল, যা খরচ কমিয়েছিল (যদিও ইথেরিয়াম যদি প্রুফ-অফ-ওয়ার্কে থাকত, তাহলে ASIC মাইনিং আরও জনপ্রিয় হয়ে উঠতে পারত)। একজন প্রতিপক্ষকে একটি প্রুফ-অফ-ওয়ার্ক ইথেরিয়াম নেটওয়ার্কে আক্রমণ করার জন্য প্রচুর হার্ডওয়্যার ক্রয় করতে হবে এবং এটি চালানোর জন্য বিদ্যুতের জন্য অর্থ প্রদান করতে হবে, তবে মোট খরচ একটি আক্রমণ শুরু করার জন্য পর্যাপ্ত ETH জমা করার জন্য প্রয়োজনীয় খরচের চেয়ে কম হবে। একটি 51% আক্রমণ প্রুফ-অফ-স্টেকের চেয়ে প্রুফ-অফ-ওয়ার্কে ~[20x কম](https://youtu.be/1m12zgJ42dI?t=1562) ব্যয়বহুল। যদি আক্রমণটি শনাক্ত করা হয় এবং তাদের পরিবর্তনগুলি অপসারণের জন্য চেইনটি হার্ড-ফর্ক করা হয়, তাহলে আক্রমণকারী বারবার একই হার্ডওয়্যার ব্যবহার করে নতুন ফর্কটিকে আক্রমণ করতে পারে। + +### জটিলতা {#complexity} + +প্রুফ-অফ-স্টেক প্রুফ-অফ-ওয়ার্কের চেয়ে অনেক বেশি জটিল। এটি প্রুফ-অফ-ওয়ার্ক-এর পক্ষে একটি পয়েন্ট হতে পারে কারণ সহজ প্রোটোকলগুলিতে ঘটনাক্রমে বাগ বা অনিচ্ছাকৃত প্রভাবগুলি প্রবর্তন করা কঠিন। যাইহোক, বছরের পর বছর গবেষণা ও উন্নয়ন, সিমুলেশন এবং টেস্টনেট বাস্তবায়নের মাধ্যমে জটিলতাকে দমন করা হয়েছে। প্রুফ-অফ-স্টেক প্রোটোকলটি পাঁচটি পৃথক দল দ্বারা (এক্সিকিউশন এবং কনসেন্সাস লেয়ারের প্রত্যেকটিতে) পাঁচটি প্রোগ্রামিং ভাষায় স্বাধীনভাবে প্রয়োগ করা হয়েছে, যা ক্লায়েন্ট বাগগুলির বিরুদ্ধে স্থিতিস্থাপকতা প্রদান করে। + +প্রুফ-অফ-স্টেক কনসেন্সাস লজিককে নিরাপদে বিকাশ এবং পরীক্ষা করার জন্য, ইথেরিয়াম মেইননেটে প্রুফ-অফ-স্টেক প্রয়োগ করার দুই বছর আগে বিকন চেইন চালু করা হয়েছিল। বিকন চেইন প্রুফ-অফ-স্টেক পরীক্ষার জন্য একটি স্যান্ডবক্স হিসাবে কাজ করেছিল, কারণ এটি একটি লাইভ ব্লকচেইন ছিল যা প্রুফ-অফ-স্টেক কনসেন্সাস লজিক প্রয়োগ করে কিন্তু আসল ইথেরিয়াম লেনদেনগুলিকে স্পর্শ না করে - কার্যকরভাবে কেবল নিজের উপর কনসেন্সাসে আসে। একবার এটি পর্যাপ্ত সময়ের জন্য স্থিতিশীল এবং বাগ-মুক্ত হয়ে গেলে, বিকন চেইনটিকে ইথেরিয়াম মেইননেটের সাথে "মার্জ" করা হয়েছিল। এই সবগুলি প্রুফ-অফ-স্টেকের জটিলতাকে এমন পর্যায়ে নিয়ন্ত্রণ করতে অবদান রেখেছে যে অনিচ্ছাকৃত পরিণতি বা ক্লায়েন্ট বাগের ঝুঁকি খুব কম ছিল। + +### আক্রমণের ক্ষেত্র {#attack-surface} + +প্রুফ-অফ-স্টেক প্রুফ-অফ-ওয়ার্কের চেয়ে বেশি জটিল, যার অর্থ হল পরিচালনা করার জন্য আরও সম্ভাব্য আক্রমণ ভেক্টর রয়েছে। ক্লায়েন্টদের সংযোগকারী একটি পিয়ার-টু-পিয়ার নেটওয়ার্কের পরিবর্তে, দুটি রয়েছে, প্রতিটি একটি পৃথক প্রোটোকল বাস্তবায়ন করে। প্রতিটি স্লটে একটি ব্লক প্রস্তাব করার জন্য একটি নির্দিষ্ট ভ্যালিডেটর আগে থেকে নির্বাচন করা ডিনায়েল-অফ-সার্ভিসের সম্ভাবনা তৈরি করে যেখানে বিপুল পরিমাণ নেটওয়ার্ক ট্র্যাফিক সেই নির্দিষ্ট ভ্যালিডেটরকে অফলাইনে নিয়ে যায়। + +এমন উপায়ও রয়েছে যে আক্রমণকারীরা তাদের ব্লক বা অ্যাটাস্টেশনগুলির মুক্তির সময় সাবধানে নির্ধারণ করতে পারে যাতে সেগুলি সৎ নেটওয়ার্কের একটি নির্দিষ্ট অনুপাত দ্বারা প্রাপ্ত হয়, যা তাদের নির্দিষ্ট উপায়ে ভোট দিতে প্রভাবিত করে। অবশেষে, একজন আক্রমণকারী কেবল স্টেক করার জন্য পর্যাপ্ত ETH জমা করতে পারে এবং কনসেন্সাস মেকানিজমে আধিপত্য বিস্তার করতে পারে। এই প্রতিটি [আক্রমণ ভেক্টরের সাথে যুক্ত প্রতিরক্ষা রয়েছে](/developers/docs/consensus-mechanisms/pos/attack-and-defense), কিন্তু প্রুফ-অফ-ওয়ার্কের অধীনে রক্ষা করার জন্য তাদের অস্তিত্ব নেই। + +## বিকেন্দ্রীকরণ {#decentralization} + +প্রুফ-অফ-স্টেক প্রুফ-অফ-ওয়ার্কের চেয়ে বেশি বিকেন্দ্রীভূত কারণ মাইনিং হার্ডওয়্যার অস্ত্র প্রতিযোগিতা ব্যক্তি এবং ছোট সংস্থাগুলিকে মূল্যহীন করে তোলে। যদিও যে কেউ প্রযুক্তিগতভাবে পরিমিত হার্ডওয়্যার দিয়ে মাইনিং শুরু করতে পারে, প্রাতিষ্ঠানিক মাইনিং অপারেশনের তুলনায় তাদের কোনো পুরস্কার পাওয়ার সম্ভাবনা খুবই কম। প্রুফ-অফ-স্টেকের সাথে, স্টেকিংয়ের খরচ এবং সেই স্টেকের উপর শতাংশ রিটার্ন সবার জন্য একই। বর্তমানে একটি ভ্যালিডেটর চালাতে 32 ETH খরচ হয়। + +অন্যদিকে, লিকুইড স্টেকিং ডেরিভেটিভের উদ্ভাবন কেন্দ্রীকরণের উদ্বেগ সৃষ্টি করেছে কারণ কয়েকটি বড় প্রদানকারী বিপুল পরিমাণে স্টেক করা ETH পরিচালনা করে। এটি সমস্যাযুক্ত এবং যত তাড়াতাড়ি সম্ভব সংশোধন করা প্রয়োজন, তবে এটি দেখতে যতটা সহজ তার চেয়েও বেশি সূক্ষ্ম। কেন্দ্রীভূত স্টেকিং প্রদানকারীদের অগত্যা ভ্যালিডেটরদের উপর কেন্দ্রীভূত নিয়ন্ত্রণ থাকে না - প্রায়শই এটি ETH-এর একটি কেন্দ্রীয় পুল তৈরি করার একটি উপায় যা অনেক স্বাধীন নোড অপারেটর প্রতিটি অংশগ্রহণকারীর নিজের 32 ETH প্রয়োজন ছাড়াই স্টেক করতে পারে। + +ইথেরিয়ামের জন্য সেরা বিকল্প হল ভ্যালিডেটরগুলিকে বাড়ির কম্পিউটারে স্থানীয়ভাবে চালানো, যা বিকেন্দ্রীকরণকে সর্বাধিক করে। এই কারণেই ইথেরিয়াম এমন পরিবর্তনগুলিকে প্রতিরোধ করে যা একটি নোড/ভ্যালিডেটর চালানোর জন্য হার্ডওয়্যার প্রয়োজনীয়তা বাড়ায়। + +## স্থায়িত্ব {#sustainability} + +প্রুফ-অফ-স্টেক হল ব্লকচেইন সুরক্ষিত করার একটি কার্বন-সস্তা উপায়। প্রুফ-অফ-ওয়ার্ক-এর অধীনে মাইনাররা একটি ব্লক মাইন করার অধিকারের জন্য প্রতিযোগিতা করে। মাইনাররা যখন দ্রুত গণনা করতে পারে তখন তারা আরও সফল হয়, যা হার্ডওয়্যার এবং শক্তি খরচে বিনিয়োগকে উৎসাহিত করে। প্রুফ-অফ-স্টেকে স্যুইচ করার আগে ইথেরিয়ামের জন্য এটি পরিলক্ষিত হয়েছিল। প্রুফ-অফ-স্টেকে রূপান্তরের কিছুক্ষণ আগে, ইথেরিয়াম প্রায় 78 TWh/বছর ব্যবহার করছিল - যা একটি ছোট দেশের সমান। যাইহোক, প্রুফ-অফ-স্টেকে স্যুইচ করা এই শক্তি ব্যয়কে ~99.98% কমিয়েছে। প্রুফ-অফ-স্টেক ইথেরিয়ামকে একটি শক্তি-দক্ষ, কম কার্বন প্ল্যাটফর্ম তৈরি করেছে। + +[ইথেরিয়ামের শক্তি খরচ সম্পর্কে আরও](/energy-consumption) + +## ইস্যুয়েন্স {#issuance} + +প্রুফ-অফ-স্টেক ইথেরিয়াম প্রুফ-অফ-ওয়ার্ক ইথেরিয়ামের চেয়ে অনেক কম কয়েন ইস্যু করে তার নিরাপত্তার জন্য অর্থ প্রদান করতে পারে কারণ ভ্যালিডেটরদের উচ্চ বিদ্যুৎ খরচ দিতে হয় না। ফলস্বরূপ, যখন বিপুল পরিমাণ ETH পুড়িয়ে ফেলা হয় তখন ETH তার মুদ্রাস্ফীতি কমাতে পারে বা এমনকি মুদ্রাসংকোচনকারী হয়ে উঠতে পারে। কম মুদ্রাস্ফীতির মাত্রা মানে ইথেরিয়ামের নিরাপত্তা প্রুফ-অফ-ওয়ার্কের অধীনে যা ছিল তার চেয়ে সস্তা। + +## আপনি কি দেখে শিখতে বেশি পছন্দ করেন? {#visual-learner} + +জাস্টিন ড্রেক-কে প্রুফ-অফ-ওয়ার্কের উপর প্রুফ-অফ-স্টেকের সুবিধাগুলি ব্যাখ্যা করতে দেখুন: + + + +## আরও পড়ুন {#further-reading} + +- [Vitalik-এর প্রুফ-অফ-স্টেক ডিজাইন দর্শন](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Vitalik-এর প্রুফ-অফ-স্টেক প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [PoS বনাম PoW-এর উপর "সিম্পলি এক্সপ্লেইনড" ভিডিও](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..c99abcb2c09 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "প্রুফ-অফ-স্টেক রিওয়ার্ডস এবং পেনাল্টি" +description: "প্রুফ-অফ-স্টেক ইথেরিয়ামে ইন-প্রটোকল ইনসেন্টিভ সম্পর্কে জানুন।" +lang: bn +--- + +ইথেরিয়াম তার নিজস্ব ক্রিপ্টোকারেন্সি, ইথার (ETH) ব্যবহার করে সুরক্ষিত থাকে। যে নোড অপারেটররা ব্লক ভ্যালিডেট করতে এবং চেইনের হেড শনাক্ত করতে অংশগ্রহণ করতে ইচ্ছুক, তারা ইথেরিয়ামে [ডিপোজিট কন্ট্রাক্ট](/staking/deposit-contract/)-এ ইথার জমা করে। এরপর তাদেরকে ভ্যালিডেটর সফটওয়্যার চালানোর জন্য ইথারে অর্থ প্রদান করা হয়, যা পিয়ার-টু-পিয়ার নেটওয়ার্কের মাধ্যমে প্রাপ্ত নতুন ব্লকের বৈধতা পরীক্ষা করে এবং চেইনের হেড শনাক্ত করার জন্য ফর্ক-চয়েস অ্যালগরিদম প্রয়োগ করে। + +একজন ভ্যালিডেটরের দুটি প্রধান ভূমিকা রয়েছে: ১) নতুন ব্লক পরীক্ষা করা এবং যদি সেগুলি বৈধ হয় তবে সেগুলিতে “অ্যাটেস্ট” করা, ২) মোট ভ্যালিডেটর পুল থেকে র‍্যান্ডমভাবে নির্বাচিত হলে নতুন ব্লক প্রস্তাব করা। যদি ভ্যালিডেটরকে বলা হলে এই কাজগুলির কোনোটি করতে ব্যর্থ হয়, তবে তারা একটি ইথার পেআউট থেকে বঞ্চিত হয়। ভ্যালিডেটরদের কখনও কখনও সিগনেচার অ্যাগ্রিগেশন এবং সিঙ্ক কমিটিতে অংশগ্রহণের দায়িত্বও দেওয়া হয়। + +এমন কিছু কাজও আছে যা দুর্ঘটনাক্রমে করা খুব কঠিন এবং কিছু दुर्भावनाপূর্ণ উদ্দেশ্য নির্দেশ করে, যেমন একই স্লটের জন্য একাধিক ব্লক প্রস্তাব করা বা একই স্লটের জন্য একাধিক ব্লকে অ্যাটেস্ট করা। এগুলো হলো “স্ল্যাশেবল” আচরণ, যার ফলে ভ্যালিডেটরকে নেটওয়ার্ক থেকে সরিয়ে দেওয়ার আগে কিছু পরিমাণ ইথার (১ ETH পর্যন্ত) বার্ন করা হয়, যা ৩৬ দিন সময় নেয়। স্ল্যাশড ভ্যালিডেটরের ইথার এক্সিট পিরিয়ড জুড়ে ধীরে ধীরে শেষ হয়ে যায়, কিন্তু ১৮তম দিনে তারা একটি “কোরিলেশন পেনাল্টি” পায়, যা একই সময়ে আরও বেশি ভ্যালিডেটর স্ল্যাশড হলে বড় হয়। কনসেন্সাস মেকানিজমের ইনসেনটিভ কাঠামো তাই সততার জন্য পুরস্কৃত করে এবং খারাপ অ্যাক্টরদের শাস্তি দেয়। + +সমস্ত রিওয়ার্ড এবং পেনাল্টি প্রতি ইপোকে একবার প্রয়োগ করা হয়। + +আরও বিস্তারিত জানতে পড়তে থাকুন... + +## রিওয়ার্ড এবং পেনাল্টি {#rewards} + +### পুরস্কার {#rewards} + +ভ্যালিডেটররা যখন অন্য ভ্যালিডেটরদের সংখ্যাগরিষ্ঠের সাথে সামঞ্জস্যপূর্ণ ভোট দেয়, যখন তারা ব্লক প্রস্তাব করে এবং যখন তারা সিঙ্ক কমিটিতে অংশগ্রহণ করে তখন তারা রিওয়ার্ড পায়। প্রতিটি ইপোকে রিওয়ার্ডের মান একটি `base_reward` থেকে গণনা করা হয়। এটি সেই বেস ইউনিট যা থেকে অন্যান্য রিওয়ার্ড গণনা করা হয়। `base_reward` একজন ভ্যালিডেটরের দ্বারা প্রতি ইপোকে অনুকূল পরিস্থিতিতে প্রাপ্ত গড় রিওয়ার্ডকে উপস্থাপন করে। এটি ভ্যালিডেটরের কার্যকরী ব্যালেন্স এবং সক্রিয় ভ্যালিডেটরের মোট সংখ্যা থেকে নিম্নরূপ গণনা করা হয়: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +যেখানে `base_reward_factor` হল 64, `base_rewards_per_epoch` হল 4 এবং `sum(active balance)` হল সমস্ত সক্রিয় ভ্যালিডেটর জুড়ে মোট স্টেক করা ইথার। + +এর মানে হল বেস রিওয়ার্ড ভ্যালিডেটরের কার্যকরী ব্যালেন্সের সমানুপাতিক এবং নেটওয়ার্কে ভ্যালিডেটরের সংখ্যার ব্যস্তানুপাতিক। যত বেশি ভ্যালিডেটর, সামগ্রিক ইস্যুয়েন্স তত বেশি (`sqrt(N)` হিসাবে), কিন্তু প্রতি ভ্যালিডেটরের জন্য `base_reward` তত কম (`1/sqrt(N)` হিসাবে)। এই ফ্যাক্টরগুলো একটি স্টেকিং নোডের জন্য APR-কে প্রভাবিত করে। এর যৌক্তিকতা [Vitalik's notes](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards)-এ পড়ুন। + +মোট রিওয়ার্ড তখন পাঁচটি উপাদানের যোগফল হিসাবে গণনা করা হয়, যার প্রত্যেকটির একটি ওয়েটিং আছে যা নির্ধারণ করে প্রতিটি উপাদান মোট রিওয়ার্ডে কতটা যোগ করবে। উপাদানগুলো হলো: + +``` +1. সোর্স ভোট: ভ্যালিডেটর সঠিক সোর্স চেকপয়েন্টের জন্য সময়মতো ভোট দিয়েছে +2. টার্গেট ভোট: ভ্যালিডেটর সঠিক টার্গেট চেকপয়েন্টের জন্য সময়মতো ভোট দিয়েছে +3. হেড ভোট: ভ্যালিডেটর সঠিক হেড ব্লকের জন্য সময়মতো ভোট দিয়েছে +4. সিঙ্ক কমিটি রিওয়ার্ড: ভ্যালিডেটর একটি সিঙ্ক কমিটিতে অংশগ্রহণ করেছে +5. প্রোপোজার রিওয়ার্ড: ভ্যালিডেটর সঠিক স্লটে একটি ব্লক প্রস্তাব করেছে +``` + +প্রতিটি উপাদানের জন্য ওয়েটিংগুলি নিম্নরূপ: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +এই ওয়েটগুলোর যোগফল 64। রিওয়ার্ডটি প্রযোজ্য ওয়েটগুলোর যোগফলকে 64 দ্বারা ভাগ করে গণনা করা হয়। একজন ভ্যালিডেটর যিনি সময়মত সোর্স, টার্গেট এবং হেড ভোট দিয়েছেন, একটি ব্লক প্রস্তাব করেছেন এবং একটি সিঙ্ক কমিটিতে অংশগ্রহণ করেছেন, তিনি `64/64 * base_reward == base_reward` পেতে পারেন। তবে, একজন ভ্যালিডেটর সাধারণত ব্লক প্রোপোজার হন না, তাই তাদের সর্বোচ্চ রিওয়ার্ড হলো `64-8 /64 * base_reward == 7/8 * base_reward`। যে ভ্যালিডেটররা ব্লক প্রোপোজার বা সিঙ্ক কমিটিতে নেই তারা `64-8-2 / 64 * base_reward == 6.75/8 * base_reward` পেতে পারে। + +দ্রুত অ্যাটেস্টেশনকে উৎসাহিত করতে একটি অতিরিক্ত রিওয়ার্ড যোগ করা হয়। এটি হলো `inclusion_delay_reward`। এর মান `base_reward`-কে `1/delay` দ্বারা গুণ করার সমান, যেখানে `delay` হলো ব্লক প্রস্তাবনা এবং অ্যাটেস্টেশনকে পৃথককারী স্লটের সংখ্যা। উদাহরণস্বরূপ, যদি অ্যাটেস্টেশনটি ব্লক প্রস্তাবনার এক স্লটের মধ্যে জমা দেওয়া হয়, তবে অ্যাটেস্টর `base_reward * 1/1 == base_reward` পাবেন। যদি অ্যাটেস্টেশনটি পরবর্তী স্লটে আসে, তবে অ্যাটেস্টর `base_reward * 1/2` পাবেন এবং এভাবেই চলতে থাকবে। + +ব্লক প্রোপোজাররা ব্লকে অন্তর্ভুক্ত **প্রতিটি বৈধ অ্যাটেস্টেশনের** জন্য `8 / 64 * base_reward` পায়, তাই রিওয়ার্ডের প্রকৃত মান অ্যাটেস্টিং ভ্যালিডেটরের সংখ্যার সাথে স্কেল করে। ব্লক প্রোপোজাররা তাদের প্রস্তাবিত ব্লকে অন্যান্য ভ্যালিডেটরদের অসদাচরণের প্রমাণ অন্তর্ভুক্ত করে তাদের রিওয়ার্ড বাড়াতে পারে। এই রিওয়ার্ডগুলো হলো সেই "প্রোৎসাহন" যা ভ্যালিডেটরদের সততাকে উৎসাহিত করে। একজন ব্লক প্রোপোজার যিনি স্ল্যাশিং অন্তর্ভুক্ত করবেন তাকে `slashed_validators_effective_balance / 512` দিয়ে পুরস্কৃত করা হবে। + +### পেনাল্টি {#penalties} + +এখন পর্যন্ত আমরা নিখুঁতভাবে সুশৃঙ্খল ভ্যালিডেটরদের বিবেচনা করেছি, কিন্তু সেই ভ্যালিডেটরদের কী হবে যারা সময়মত হেড, সোর্স এবং টার্গেট ভোট দেয় না বা ধীরে ধীরে করে? + +টার্গেট এবং সোর্স ভোট মিস করার জন্য পেনাল্টি সেই রিওয়ার্ডের সমান যা অ্যাটেস্টর পেত যদি তারা সেগুলি জমা দিত। এর মানে হল তাদের ব্যালেন্সে রিওয়ার্ড যোগ করার পরিবর্তে, তাদের ব্যালেন্স থেকে একটি সমান মূল্য সরানো হয়। হেড ভোট মিস করার জন্য কোনো পেনাল্টি নেই (অর্থাৎ, হেড ভোটের জন্য শুধুমাত্র রিওয়ার্ড দেওয়া হয়, কখনও পেনাল্টি দেওয়া হয় না)। `inclusion_delay`-এর সাথে সম্পর্কিত কোনো পেনাল্টি নেই - রিওয়ার্ডটি কেবল ভ্যালিডেটরের ব্যালেন্সে যোগ করা হবে না। একটি ব্লক প্রস্তাব করতে ব্যর্থ হওয়ার জন্যও কোনো পেনাল্টি নেই। + +[কনসেন্সাস স্পেকস](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md)-এ রিওয়ার্ড এবং পেনাল্টি সম্পর্কে আরও পড়ুন। Bellatrix আপগ্রেডে রিওয়ার্ড এবং পেনাল্টি সমন্বয় করা হয়েছিল - ড্যানি রায়ান এবং ভিটালিককে এই [Peep an EIP ভিডিও](https://www.youtube.com/watch?v=iaAEGs1DMgQ)-তে এটি নিয়ে আলোচনা করতে দেখুন। + +## স্ল্যাশিং {#slashing} + +স্ল্যাশিং একটি আরও গুরুতর পদক্ষেপ যার ফলে নেটওয়ার্ক থেকে একজন ভ্যালিডেটরকে জোরপূর্বক অপসারণ করা হয় এবং তাদের স্টেক করা ইথারের ক্ষতি হয়। একজন ভ্যালিডেটরকে তিনভাবে স্ল্যাশড করা যেতে পারে, যার সবই ব্লকের অসৎ প্রস্তাবনা বা অ্যাটেস্টেশনের সামিল: + +- একই স্লটের জন্য দুটি ভিন্ন ব্লক প্রস্তাব ও স্বাক্ষর করার মাধ্যমে +- এমন একটি ব্লকে অ্যাটেস্ট করার মাধ্যমে যা অন্য একটিকে "ঘিরে রাখে" (কার্যকরভাবে ইতিহাস পরিবর্তন করা) +- একই ব্লকের জন্য দুটি ক্যান্ডিডেটে অ্যাটেস্ট করার মাধ্যমে "ডাবল ভোটিং" করা + +যদি এই কাজগুলি সনাক্ত করা হয়, ভ্যালিডেটরকে স্ল্যাশড করা হয়। এর মানে হলো একজন 32 ETH ভ্যালিডেটরের জন্য তাৎক্ষণিকভাবে 0.0078125 বার্ন করা হয় (সক্রিয় ব্যালেন্সের সাথে রৈখিকভাবে স্কেল করা হয়), তারপর একটি 36 দিনের অপসারণ সময়কাল শুরু হয়। এই অপসারণ সময়কালে ভ্যালিডেটরের স্টেক ধীরে ধীরে কমে যায়। মধ্যবর্তী সময়ে (দিন ১৮) একটি অতিরিক্ত পেনাল্টি প্রয়োগ করা হয় যার মাত্রা স্ল্যাশিং ইভেন্টের আগের ৩৬ দিনে সমস্ত স্ল্যাশড ভ্যালিডেটরের মোট স্টেক করা ইথারের সাথে স্কেল করে। এর মানে হল যখন আরও বেশি ভ্যালিডেটর স্ল্যাশড হয়, তখন স্ল্যাশের মাত্রা বৃদ্ধি পায়। সর্বোচ্চ স্ল্যাশ হলো সমস্ত স্ল্যাশড ভ্যালিডেটরের সম্পূর্ণ কার্যকরী ব্যালেন্স (অর্থাৎ, যদি অনেক ভ্যালিডেটর স্ল্যাশড হতে থাকে তবে তারা তাদের সম্পূর্ণ স্টেক হারাতে পারে)। অন্যদিকে, একটি একক, বিচ্ছিন্ন স্ল্যাশিং ইভেন্ট শুধুমাত্র ভ্যালিডেটরের স্টেকের একটি ছোট অংশ বার্ন করে। স্ল্যাশড ভ্যালিডেটরের সংখ্যার সাথে স্কেল করা এই মধ্যবর্তী পেনাল্টিকে "কোরিলেশন পেনাল্টি" বলা হয়। + +## ইনঅ্যাক্টিভিটি লিক {#inactivity-leak} + +যদি কনসেন্সাস লেয়ার চূড়ান্ত না করে চারটির বেশি ইপোক পার করে, তাহলে "ইনঅ্যাক্টিভিটি লিক" নামক একটি জরুরি প্রোটোকল সক্রিয় করা হয়। ইনঅ্যাক্টিভিটি লিকের চূড়ান্ত লক্ষ্য হল চেইনকে ফাইনালিটি পুনরুদ্ধারের জন্য প্রয়োজনীয় শর্ত তৈরি করা। উপরে যেমন ব্যাখ্যা করা হয়েছে, ফাইনালিটির জন্য সোর্স এবং টার্গেট চেকপয়েন্টগুলিতে সম্মত হতে মোট স্টেক করা ইথারের ২/৩ সংখ্যাগরিষ্ঠতা প্রয়োজন। যদি মোট ভ্যালিডেটরের ১/৩ এর বেশি প্রতিনিধিত্বকারী ভ্যালিডেটররা অফলাইন হয়ে যায় বা সঠিক অ্যাটেস্টেশন জমা দিতে ব্যর্থ হয়, তাহলে ২/৩ সুপারম্যাজরিটির পক্ষে চেকপয়েন্ট চূড়ান্ত করা সম্ভব নয়। ইনঅ্যাক্টিভিটি লিক নিষ্ক্রিয় ভ্যালিডেটরদের স্টেক ধীরে ধীরে কমে যেতে দেয় যতক্ষণ না তারা মোট স্টেকের ১/৩ এর কম নিয়ন্ত্রণ করে, যা অবশিষ্ট সক্রিয় ভ্যালিডেটরদের চেইন চূড়ান্ত করতে দেয়। নিষ্ক্রিয় ভ্যালিডেটরদের পুল যতই বড় হোক না কেন, অবশিষ্ট সক্রিয় ভ্যালিডেটররা অবশেষে স্টেকের >২/৩ নিয়ন্ত্রণ করবে। স্টেকের ক্ষতি নিষ্ক্রিয় ভ্যালিডেটরদের যত তাড়াতাড়ি সম্ভব পুনরায় সক্রিয় হওয়ার জন্য একটি শক্তিশালী উৎসাহ! Medalla টেস্টনেটে একটি ইনঅ্যাক্টিভিটি লিকের পরিস্থিতি দেখা গিয়েছিল যখন < ৬৬% সক্রিয় ভ্যালিডেটর ব্লকচেইনের বর্তমান হেডের উপর কনসেন্সাসে আসতে সক্ষম হয়েছিল। ইনঅ্যাক্টিভিটি লিক সক্রিয় করা হয়েছিল এবং অবশেষে ফাইনালিটি পুনরুদ্ধার করা হয়েছিল! + +কনসেন্সাস মেকানিজমের রিওয়ার্ড, পেনাল্টি এবং স্ল্যাশিং ডিজাইন স্বতন্ত্র ভ্যালিডেটরদের সঠিকভাবে আচরণ করতে উৎসাহিত করে। তবে, এই ডিজাইনের পছন্দগুলি থেকে এমন একটি সিস্টেম উদ্ভূত হয় যা একাধিক ক্লায়েন্ট জুড়ে ভ্যালিডেটরদের সমান বন্টনকে দৃঢ়ভাবে উৎসাহিত করে এবং একক-ক্লায়েন্ট আধিপত্যকে দৃঢ়ভাবে নিরুৎসাহিত করা উচিত। + +## আরও পড়ুন {#further-reading} + +- [ইথেরিয়াম আপগ্রেড করা: ইনসেনটিভ লেয়ার](https://eth2book.info/altair/part2/incentives) +- [ইথেরিয়ামের হাইব্রিড ক্যাসপার প্রটোকলে ইনসেনটিভ](https://arxiv.org/pdf/1903.04205.pdf) +- [ভিটালিকের অ্যানোটেটেড স্পেক](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Eth2 স্ল্যাশিং প্রতিরোধের টিপস](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [EIP-7251 এর অধীনে স্ল্যাশিং পেনাল্টির বিশ্লেষণ](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_সোর্স_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..02347e1c55f --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "দুর্বল বিষয়গততা" +description: "দুর্বল বিষয়গততার একটি ব্যাখ্যা এবং PoS ইথেরিয়ামে এর ভূমিকা।" +lang: bn +--- + +ব্লকচেইনে বিষয়গততা বলতে বর্তমান স্টেটে সম্মত হওয়ার জন্য সামাজিক তথ্যের উপর নির্ভরতাকে বোঝায়। একাধিক বৈধ ফর্ক থাকতে পারে যা নেটওয়ার্কের অন্যান্য সহকর্মীদের কাছ থেকে সংগৃহীত তথ্য অনুসারে বেছে নেওয়া হয়। এর বিপরীত হল বস্তুনিষ্ঠতা যা এমন চেইনগুলিকে বোঝায় যেখানে শুধুমাত্র একটি সম্ভাব্য বৈধ চেইন রয়েছে যা সমস্ত নোড তাদের কোডেড নিয়ম প্রয়োগ করে অগত্যা সম্মত হবে। দুর্বল বিষয়গততা নামে পরিচিত একটি তৃতীয় স্টেটও রয়েছে। এটি এমন একটি চেইনকে বোঝায় যা সামাজিকভাবে কিছু প্রাথমিক তথ্যের বীজ পুনরুদ্ধার করার পরে বস্তুনিষ্ঠভাবে অগ্রসর হতে পারে। + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি বোঝার জন্য প্রথমে [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/)-এর মূল বিষয়গুলি বোঝা প্রয়োজন। + +## দুর্বল বিষয়গততা কোন সমস্যাগুলোর সমাধান করে? {#problems-ws-solves} + +প্রুফ-অফ-স্টেক ব্লকচেইনগুলোতে বিষয়গততা অন্তর্নিহিত কারণ একাধিক ফর্ক থেকে সঠিক চেইন নির্বাচন করা হয় ঐতিহাসিক ভোট গণনার মাধ্যমে। এটি ব্লকচেইনকে বিভিন্ন আক্রমণের ভেক্টরের সামনে উন্মোচিত করে, যার মধ্যে দীর্ঘ-পরিসরের আক্রমণও রয়েছে যেখানে চেইনের প্রথম দিকে অংশগ্রহণকারী নোডগুলো একটি বিকল্প ফর্ক বজায় রাখে যা তারা অনেক পরে তাদের নিজেদের সুবিধার জন্য প্রকাশ করে। বিকল্পভাবে, যদি 33% ভ্যালিডেটর তাদের স্টেক উত্তোলন করে কিন্তু ব্লক প্রত্যয়ন এবং উৎপাদন চালিয়ে যায়, তবে তারা একটি বিকল্প ফর্ক তৈরি করতে পারে যা ক্যানোনিকাল চেইনের সাথে বিরোধপূর্ণ। নতুন নোড বা যে নোডগুলো দীর্ঘ সময় ধরে অফলাইনে ছিল তারা হয়তো জানে না যে এই আক্রমণকারী ভ্যালিডেটররা তাদের তহবিল উত্তোলন করেছে, তাই আক্রমণকারীরা তাদের একটি ভুল চেইন অনুসরণ করার জন্য প্রতারণা করতে পারে। ইথেরিয়াম এই আক্রমণের ভেক্টরগুলোর সমাধান করতে পারে এমন সীমাবদ্ধতা আরোপ করে যা প্রক্রিয়ার বিষয়গত দিকগুলো — এবং ফলস্বরূপ আস্থার অনুমানগুলোকে — একেবারে ন্যূনতম পর্যায়ে নামিয়ে আনে। + +## দুর্বল বিষয়গততার চেকপয়েন্ট {#ws-checkpoints} + +প্রুফ-অফ-স্টেক ইথেরিয়ামে "দুর্বল বিষয়গততার চেকপয়েন্ট" ব্যবহার করে দুর্বল বিষয়গততা প্রয়োগ করা হয়। এগুলো হল স্টেট রুট যা নেটওয়ার্কের সমস্ত নোড ক্যানোনিকাল চেইনের অন্তর্গত বলে সম্মত হয়। এগুলো জেনেসিস ব্লকের মতো একই "সার্বজনীন সত্য" উদ্দেশ্য পরিবেশন করে, তবে এগুলো ব্লকচেইনে জেনেসিস অবস্থানে বসে না। ফর্ক চয়েস অ্যালগরিদম বিশ্বাস করে যে সেই চেকপয়েন্টে সংজ্ঞায়িত ব্লকচেইন স্টেট সঠিক এবং এটি সেই বিন্দু থেকে স্বাধীনভাবে এবং বস্তুনিষ্ঠভাবে চেইন যাচাই করে। চেকপয়েন্টগুলো "প্রত্যাবর্তন সীমা" হিসাবে কাজ করে কারণ দুর্বল-বিষয়গততার চেকপয়েন্টের আগে অবস্থিত ব্লকগুলো পরিবর্তন করা যায় না। এটি মেকানিজম ডিজাইনের অংশ হিসাবে দীর্ঘ-পরিসরের ফর্কগুলোকে অবৈধ হিসাবে সংজ্ঞায়িত করে দীর্ঘ-পরিসরের আক্রমণকে খর্ব করে। দুর্বল বিষয়গততার চেকপয়েন্টগুলো ভ্যালিডেটরদের উত্তোলন সময়ের চেয়ে কম দূরত্বে পৃথক করা হয়েছে তা নিশ্চিত করা হলে, এটি নিশ্চিত করে যে চেইন ফর্ক করা একজন ভ্যালিডেটর তাদের স্টেক উত্তোলন করার আগে কমপক্ষে একটি নির্দিষ্ট থ্রেশহোল্ড পরিমাণ স্ল্যাশড হবে এবং নতুন প্রবেশকারীদের সেইসব ভ্যালিডেটরদের দ্বারা ভুল ফর্কে প্রতারিত করা যাবে না যাদের স্টেক উত্তোলন করা হয়েছে। + +## দুর্বল বিষয়গততার চেকপয়েন্ট এবং চূড়ান্ত ব্লকগুলোর মধ্যে পার্থক্য {#difference-between-ws-and-finalized-blocks} + +চূড়ান্ত ব্লক এবং দুর্বল বিষয়গততার চেকপয়েন্টগুলো ইথেরিয়াম নোড দ্বারা ভিন্নভাবে বিবেচিত হয়। যদি একটি নোড দুটি প্রতিযোগী চূড়ান্ত ব্লক সম্পর্কে সচেতন হয়, তবে এটি দুটির মধ্যে দ্বিধান্বিত হয়ে যায় - এটির কাছে স্বয়ংক্রিয়ভাবে কোনটি ক্যানোনিকাল ফর্ক তা সনাক্ত করার কোনো উপায় থাকে না। এটি একটি কনসেন্সাস ব্যর্থতার লক্ষণ। বিপরীতে, একটি নোড তার দুর্বল বিষয়গততার চেকপয়েন্টের সাথে সাংঘর্ষিক যেকোনো ব্লককে কেবল প্রত্যাখ্যান করে। নোডের দৃষ্টিকোণ থেকে, দুর্বল বিষয়গততার চেকপয়েন্ট একটি পরম সত্যকে প্রতিনিধিত্ব করে যা তার সহকর্মীদের কাছ থেকে নতুন জ্ঞান দ্বারা ক্ষুণ্ন করা যায় না। + +## কতটা দুর্বল এই দুর্বলতা? {#how-weak-is-weak} + +ইথেরিয়ামের প্রুফ-অফ-স্টেকের বিষয়গত দিকটি হল সিঙ্ক করার জন্য একটি বিশ্বস্ত উৎস থেকে একটি সাম্প্রতিক স্টেট (দুর্বল বিষয়গততার চেকপয়েন্ট) এর প্রয়োজনীয়তা। একটি খারাপ দুর্বল বিষয়গততার চেকপয়েন্ট পাওয়ার ঝুঁকি খুব কম কারণ সেগুলো ব্লক এক্সপ্লোরার বা একাধিক নোডের মতো বিভিন্ন স্বাধীন পাবলিক উৎসের সাথে মিলিয়ে দেখা যেতে পারে। যাইহোক, যেকোনো সফ্টওয়্যার এপ্লিকেশন চালানোর জন্য সর্বদা কিছু মাত্রার আস্থার প্রয়োজন হয়, উদাহরণস্বরূপ, সফ্টওয়্যার ডেভেলপাররা সৎ সফ্টওয়্যার তৈরি করেছে এই বিশ্বাস রাখা। + +একটি দুর্বল বিষয়গততার চেকপয়েন্ট এমনকি ক্লায়েন্ট সফ্টওয়্যারের অংশ হিসাবেও আসতে পারে। তর্কসাপেক্ষে একজন আক্রমণকারী সফ্টওয়্যারের মধ্যে থাকা চেকপয়েন্টকে দূষিত করতে পারে এবং ঠিক ততটাই সহজে সফ্টওয়্যারটিকেই দূষিত করতে পারে। এই সমস্যার সমাধানের জন্য কোনো বাস্তব ক্রিপ্টো-অর্থনৈতিক পথ নেই, তবে ইথেরিয়ামে একাধিক স্বাধীন ক্লায়েন্ট টিম থাকার মাধ্যমে অবিশ্বস্ত ডেভেলপারদের প্রভাব কমানো হয়েছে, প্রতিটি টিম বিভিন্ন ভাষায় সমতুল্য সফ্টওয়্যার তৈরি করে, এবং সকলেরই একটি সৎ চেইন বজায় রাখার ক্ষেত্রে একটি নিহিত আগ্রহ রয়েছে। ব্লক এক্সপ্লোরারগুলো দুর্বল বিষয়গততার চেকপয়েন্ট বা অন্য কোথাও থেকে প্রাপ্ত চেকপয়েন্টগুলোকে একটি অতিরিক্ত উৎসের সাথে ক্রস-রেফারেন্স করার উপায়ও সরবরাহ করতে পারে। + +পরিশেষে, অন্যান্য নোড থেকে চেকপয়েন্টের জন্য অনুরোধ করা যেতে পারে; সম্ভবত অন্য একজন ইথেরিয়াম ব্যবহারকারী যিনি একটি সম্পূর্ণ নোড চালান, তিনি একটি চেকপয়েন্ট সরবরাহ করতে পারেন যা ভ্যালিডেটররা তারপর একটি ব্লক এক্সপ্লোরারের ডেটার সাথে যাচাই করতে পারে। সামগ্রিকভাবে, একটি দুর্বল বিষয়গততার চেকপয়েন্টের প্রদানকারীকে বিশ্বাস করা ক্লায়েন্ট ডেভেলপারদের বিশ্বাস করার মতোই সমস্যাযুক্ত হিসাবে বিবেচনা করা যেতে পারে। প্রয়োজনীয় সামগ্রিক বিশ্বাস কম। এটি লক্ষ করা গুরুত্বপূর্ণ যে এই বিবেচনাগুলো শুধুমাত্র সেই অত্যন্ত অসম্ভাব্য ঘটনাতেই গুরুত্বপূর্ণ হয়ে ওঠে যেখানে সংখ্যাগরিষ্ঠ ভ্যালিডেটর ব্লকচেইনের একটি বিকল্প ফর্ক তৈরি করার জন্য ষড়যন্ত্র করে। অন্য যেকোনো পরিস্থিতিতে, বেছে নেওয়ার জন্য শুধুমাত্র একটি ইথেরিয়াম চেইন রয়েছে। + +## আরও পড়ুন {#further-reading} + +- [Eth2-তে দুর্বল বিষয়গততা](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [ভিটালিক: আমি কীভাবে দুর্বল বিষয়গততাকে ভালোবাসতে শিখলাম](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [দুর্বল বিষয়গততা (Teku ডক্স)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [ফেজ-0 দুর্বল বিষয়গততা নির্দেশিকা](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [ইথেরিয়াম 2.0-তে দুর্বল বিষয়গততার বিশ্লেষণ](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..8028bab3fb1 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "উইথড্রয়াল ক্রেডেনশিয়াল" +description: "ভ্যালিডেটর উইথড্রল ক্রেডেনশিয়াল প্রকারের (0x00, 0x01, 0x02) একটি ব্যাখ্যা এবং ইথেরিয়াম স্ট্যাকারদের জন্য তাদের প্রভাব।" +lang: bn +--- + +প্রত্যেক ভ্যালিডেটরের একটি **উইথড্রল ক্রেডেনশিয়াল** থাকে যা নির্ধারণ করে কিভাবে এবং কোথায় তাদের স্টেক করা ETH এবং পুরস্কার উইথড্র করা যাবে। ক্রেডেনশিয়ালের প্রকার প্রথম বাইট দ্বারা নির্দেশিত হয়: `0x00`, `0x01`, বা `0x02`। এই প্রকারগুলি বোঝা ভ্যালিডেটরদের জন্য তাদের স্টেক পরিচালনা করার জন্য গুরুত্বপূর্ণ। + +## 0x00: প্রি-শ্যাপেলা ক্রেডেনশিয়াল {#0x00-credentials} + +`0x00` প্রকারটি শ্যাপেলা আপগ্রেডের (এপ্রিল ২০২৩) আগের আসল উইথড্রল ক্রেডেনশিয়াল ফরম্যাট। এই ক্রেডেনশিয়ালের প্রকার সহ ভ্যালিডেটরদের কোনো এক্সিকিউশন লেয়ার উইথড্রল অ্যাড্রেস সেট করা নেই, যার মানে তাদের ফান্ড কনসেন্সাস লেয়ারে লক করা থাকে। আপনার যদি এখনও `0x00` ক্রেডেনশিয়াল থাকে, তাহলে কোনো উইথড্রল পাওয়ার আগে আপনাকে অবশ্যই `0x01` বা `0x02`-তে আপগ্রেড করতে হবে। + +## 0x01: লিগ্যাসি উইথড্রল ক্রেডেনশিয়াল {#0x01-credentials} + +`0x01` প্রকারটি শ্যাপেলা আপগ্রেডের সাথে চালু করা হয়েছিল এবং এটি সেইসব ভ্যালিডেটরদের জন্য স্ট্যান্ডার্ড হয়ে ওঠে যারা একটি এক্সিকিউশন লেয়ার উইথড্রল অ্যাড্রেস সেট করতে চেয়েছিল। `0x01` ক্রেডেনশিয়ালের সাথে: + +- 32 ETH-এর উপরে যেকোনো ব্যালেন্স **স্বয়ংক্রিয়ভাবে আপনার উইথড্রল অ্যাড্রেসে সুইপ্ট** হয়ে যায় +- সম্পূর্ণ এক্সিট স্ট্যান্ডার্ড এক্সিট কিউ-এর মাধ্যমে সম্পন্ন হয় +- 32 ETH-এর উপরের পুরস্কার কম্পাউন্ড হতে পারে না—সেগুলো পর্যায়ক্রমে সুইপ্ট আউট হয়ে যায় + +**কিছু ভ্যালিডেটর কেন এখনও 0x01 ব্যবহার করে:** এটি সহজ এবং পরিচিত। অনেক ভ্যালিডেটর শ্যাপেলার পরে ডিপোজিট করেছে এবং তাদের কাছে ইতিমধ্যেই এই প্রকারটি রয়েছে, এবং যারা অতিরিক্ত ব্যালেন্সের স্বয়ংক্রিয় উইথড্রল চান তাদের জন্য এটি ঠিকঠাক কাজ করে। + +**কেন এটি সুপারিশ করা হয় না:** `0x01`-এর সাথে, আপনি 32 ETH-এর উপরে পুরস্কার কম্পাউন্ড করার ক্ষমতা হারান। প্রতিটি অতিরিক্ত অংশ স্বয়ংক্রিয়ভাবে সুইপ্ট হয়ে যায়, যা আপনার ভ্যালিডেটরের আয়ের সম্ভাবনাকে সীমিত করে এবং উইথড্র করা ফান্ড আলাদাভাবে পরিচালনা করার প্রয়োজন হয়। + +## 0x02: কম্পাউন্ডিং উইথড্রল ক্রেডেনশিয়াল {#0x02-credentials} + +`0x02` প্রকারটি পেক্ট্রা আপগ্রেডের সাথে চালু করা হয়েছিল এবং এটি আজকের ভ্যালিডেটরদের জন্য **সুপারিশকৃত পছন্দ**। `0x02` ক্রেডেনশিয়াল সহ ভ্যালিডেটরদের কখনও কখনও "কম্পাউন্ডিং ভ্যালিডেটর" বলা হয়। + +`0x02` ক্রেডেনশিয়ালের সাথে: + +- 32 ETH-এর উপরের পুরস্কার 1 ETH বৃদ্ধিতে সর্বোচ্চ 2048 ETH কার্যকর ব্যালেন্স পর্যন্ত **কম্পাউন্ড** হয় +- আংশিক উইথড্রল অবশ্যই ম্যানুয়ালি অনুরোধ করতে হবে (স্বয়ংক্রিয় সুইপ শুধুমাত্র 2048 ETH থ্রেশহোল্ডের উপরে ঘটে) +- ভ্যালিডেটররা একাধিক 32 ETH ভ্যালিডেটরকে একটি একক উচ্চ-ব্যালেন্সের ভ্যালিডেটরে একত্রিত করতে পারে +- সম্পূর্ণ এক্সিট এখনও স্ট্যান্ডার্ড এক্সিট কিউ-এর মাধ্যমে সমর্থিত + +আংশিক উইথড্রল এবং একত্রীকরণ উভয়ই [লঞ্চপ্যাড ভ্যালিডেটর অ্যাকশন](https://launchpad.ethereum.org/en/validator-actions) এর মাধ্যমে করা যেতে পারে। + +**কেন ভ্যালিডেটরদের 0x02 পছন্দ করা উচিত:** এটি কম্পাউন্ডিংয়ের মাধ্যমে উন্নত মূলধন দক্ষতা, উইথড্রল কখন হবে তার উপর আরও নিয়ন্ত্রণ প্রদান করে এবং ভ্যালিডেটর একত্রীকরণ সমর্থন করে। সময়ের সাথে সাথে পুরস্কার সংগ্রহকারী সোলো স্ট্যাকারদের জন্য, এর মানে হল তাদের কার্যকর ব্যালেন্স—এবং ফলস্বরূপ তাদের পুরস্কার—ম্যানুয়াল হস্তক্ষেপ ছাড়াই 32 ETH-এর বাইরে বাড়তে পারে। + +**গুরুত্বপূর্ণ:** একবার আপনি `0x01` থেকে `0x02`-তে রূপান্তর করলে, আপনি আর আগের অবস্থায় ফিরতে পারবেন না। + +টাইপ 2 ক্রেডেনশিয়ালে রূপান্তর এবং MaxEB ফিচারের উপর একটি বিস্তারিত গাইডের জন্য, [MaxEB ব্যাখ্যাকারী পাতা](/roadmap/pectra/maxeb/) দেখুন। + +## আমার কোনটি বেছে নেওয়া উচিত? {#what-should-i-pick} + +- **নতুন ভ্যালিডেটর:** `0x02` বেছে নিন। এটি উন্নত কম্পাউন্ডিং এবং নমনীয়তার সাথে আধুনিক স্ট্যান্ডার্ড। +- **বিদ্যমান 0x01 ভ্যালিডেটর:** আপনি যদি 32 ETH-এর উপরে পুরস্কার কম্পাউন্ড করতে চান বা ভ্যালিডেটরদের একত্রিত করার পরিকল্পনা করেন তবে `0x02`-তে রূপান্তর করার কথা বিবেচনা করুন। +- **বিদ্যমান 0x00 ভ্যালিডেটর:** অবিলম্বে আপগ্রেড করুন—আপনার ক্রেডেনশিয়াল আপডেট না করে আপনি উইথড্র করতে পারবেন না। আপনাকে প্রথমে `0x01`-এ রূপান্তর করতে হবে, তারপর আপনি `0x02`-তে রূপান্তর করতে পারবেন। + +## উইথড্রল ক্রেডেনশিয়াল পরিচালনার জন্য টুলস {#withdrawal-credential-tools} + +বেশ কিছু টুলস ক্রেডেনশিয়ালের প্রকারের মধ্যে নির্বাচন বা রূপান্তর সমর্থন করে: + +- **[ইথেরিয়াম স্টেকিং লঞ্চপ্যাড](https://launchpad.ethereum.org/en/validator-actions)** - ক্রেডেনশিয়াল রূপান্তর এবং একত্রীকরণ সহ ডিপোজিট এবং ভ্যালিডেটর পরিচালনার জন্য অফিসিয়াল টুল +- **[পেক্ট্রা স্টেকিং ম্যানেজার](https://pectrastaking.com)** - রূপান্তর এবং একত্রীকরণের জন্য ওয়ালেট-কানেক্ট সমর্থন সহ ওয়েব UI +- **[পেক্ট্রা ভ্যালিডেটর অপ্স CLI টুল](https://github.com/Luganodes/Pectra-Batch-Contract)** - ব্যাচ রূপান্তরের জন্য কমান্ড-লাইন টুল +- **[Ethereal](https://github.com/wealdtech/ethereal)** - ভ্যালিডেটর পরিচালনা সহ ইথেরিয়াম অপারেশনের জন্য CLI টুল + +একত্রীকরণ টুলসের একটি সম্পূর্ণ তালিকা এবং বিস্তারিত রূপান্তর নির্দেশাবলীর জন্য, দেখুন [MaxEB একত্রীকরণ টুলিং](/roadmap/pectra/maxeb/#consolidation-tooling)। + +## আরও পড়ুন {#further-reading} + +- [প্রুফ-অফ-স্টেক ইথেরিয়ামে কী-সমূহ](/developers/docs/consensus-mechanisms/pos/keys/) - ভ্যালিডেটর কী এবং কীভাবে তারা উইথড্রল ক্রেডেনশিয়ালের সাথে সম্পর্কিত তা জানুন +- [MaxEB](/roadmap/pectra/maxeb/) - পেক্ট্রা আপগ্রেড এবং সর্বোচ্চ কার্যকর ব্যালেন্স ফিচারের উপর বিস্তারিত গাইড diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..51276ad236e --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: "প্রুফ-অফ-ওয়ার্ক (PoW)" +description: "প্রুফ-অফ-ওয়ার্ক কনসেন্সাস প্রোটোকল এবং ইথেরিয়ামে এর ভূমিকার একটি ব্যাখ্যা।" +lang: bn +--- + +ইথেরিয়াম নেটওয়ার্ক একটি কনসেন্সাস মেকানিজম ব্যবহার করে শুরু হয়েছিল যা **[প্রুফ-অফ-ওয়ার্ক (PoW)](/developers/docs/consensus-mechanisms/pow)** এর সাথে জড়িত ছিল। এটি ইথেরিয়াম নেটওয়ার্কের নোডগুলিকে ইথেরিয়াম ব্লকচেইনে রেকর্ড করা সমস্ত তথ্যের স্টেটের উপর একমত হতে সাহায্য করে এবং নির্দিষ্ট ধরণের অর্থনৈতিক আক্রমণ প্রতিরোধ করে। তবে, 2022 সালে ইথেরিয়াম প্রুফ-অফ-ওয়ার্ক বন্ধ করে দেয় এবং পরিবর্তে [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos) ব্যবহার করা শুরু করে। + + + + + + প্রুফ-অফ-ওয়ার্ক এখন বাতিল করা হয়েছে। ইথেরিয়াম আর তার কনসেন্সাস মেকানিজমের অংশ হিসাবে প্রুফ-অফ-ওয়ার্ক ব্যবহার করে না। পরিবর্তে, এটি প্রুফ-অফ-স্টেক ব্যবহার করে। [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) এবং [স্টেকিং](/staking/) সম্পর্কে আরও পড়ুন। + + + + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি আরও ভালোভাবে বোঝার জন্য, আমরা আপনাকে প্রথমে [ট্রানজ্যাকশন](/developers/docs/transactions/), [ব্লক](/developers/docs/blocks/), এবং [কনসেন্সাস মেকানিজম](/developers/docs/consensus-mechanisms/) সম্পর্কে পড়ার পরামর্শ দিচ্ছি। + +## প্রুফ-অফ-ওয়ার্ক (PoW) কী? {#what-is-pow} + +নাকামোতো কনসেন্সাস, যা প্রুফ-অফ-ওয়ার্ক ব্যবহার করে, এটি সেই প্রক্রিয়া যা একসময় বিকেন্দ্রীভূত ইথেরিয়াম নেটওয়ার্ককে অ্যাকাউন্টের ব্যালেন্স এবং লেনদেনের ক্রমের মতো বিষয়গুলিতে কনসেন্সাসে (অর্থাৎ, সমস্ত নোড একমত) আসতে দিয়েছিল। এটি ব্যবহারকারীদের তাদের কয়েন "ডাবল স্পেন্ডিং" থেকে বিরত রেখেছিল এবং নিশ্চিত করেছিল যে ইথেরিয়াম চেইন আক্রমণ বা ম্যানিপুলেট করা অত্যন্ত কঠিন ছিল। এই সুরক্ষা বৈশিষ্ট্যগুলি এখন [গ্যাসপার](/developers/docs/consensus-mechanisms/pos/gasper/) নামে পরিচিত কনসেন্সাস মেকানিজম ব্যবহার করে প্রুফ-অফ-স্টেক থেকে আসে। + +## প্রুফ-অফ-ওয়ার্ক এবং মাইনিং {#pow-and-mining} + +প্রুফ-অফ-ওয়ার্ক হল অন্তর্নিহিত অ্যালগরিদম যা প্রুফ-অফ-ওয়ার্ক ব্লকচেইনে মাইনাররা যে কাজ করে তার জন্য অসুবিধা এবং নিয়ম সেট করে। মাইনিং নিজেই "কাজ"। এটি চেইনে বৈধ ব্লক যোগ করার কাজ। এটি গুরুত্বপূর্ণ কারণ চেইনের দৈর্ঘ্য নেটওয়ার্ককে ব্লকচেইনের সঠিক ফর্ক অনুসরণ করতে সহায়তা করে। যত বেশি "কাজ" করা হয়, চেইন তত দীর্ঘ হয় এবং ব্লকের সংখ্যা যত বেশি হয়, নেটওয়ার্ক বর্তমান অবস্থার বিষয়ে তত বেশি নিশ্চিত হতে পারে। + +[মাইনিং সম্পর্কে আরও](/developers/docs/consensus-mechanisms/pow/mining/) + +## ইথেরিয়ামের প্রুফ-অফ-ওয়ার্ক কীভাবে কাজ করে? {#how-it-works} + +ইথেরিয়াম ট্রানজ্যাকশনগুলি ব্লকে প্রক্রিয়া করা হয়। এখন-অপ্রচলিত প্রুফ-অফ-ওয়ার্ক ইথেরিয়ামে, প্রতিটি ব্লকে ছিল: + +- ব্লকের অসুবিধা – উদাহরণস্বরূপ: 3,324,092,183,262,715 +- mixHash – উদাহরণস্বরূপ: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- নন্স – উদাহরণস্বরূপ: `0xd3ee432b4fb3d26b` + +এই ব্লক ডেটা সরাসরি প্রুফ-অফ-ওয়ার্কের সাথে সম্পর্কিত ছিল। + +### প্রুফ-অফ-ওয়ার্কের কাজ {#the-work} + +প্রুফ-অফ-ওয়ার্ক প্রোটোকল, ইথ্যাশ (Ethash), একটি ব্লকের জন্য নন্স খুঁজে বের করার জন্য মাইনারদের ট্রায়াল এবং ত্রুটির একটি তীব্র প্রতিযোগিতার মধ্য দিয়ে যেতে হতো। শুধুমাত্র একটি বৈধ নন্স সহ ব্লকগুলি চেইনে যোগ করা যেতে পারে। + +একটি ব্লক তৈরি করার জন্য দৌড়ানোর সময়, একজন মাইনার বারবার একটি ডেটাসেট রাখে, যা শুধুমাত্র সম্পূর্ণ চেইন ডাউনলোড এবং চালানোর মাধ্যমে পাওয়া যেতে পারে (যেমন একজন মাইনার করে), একটি গাণিতিক ফাংশনের মাধ্যমে। ডেটাসেটটি একটি টার্গেটের নীচে একটি মিক্সহ্যাশ (mixHash) তৈরি করতে ব্যবহৃত হয়েছিল যা ব্লকের অসুবিধা দ্বারা নির্দেশিত হয়। এটি করার সর্বোত্তম উপায় হল ট্রায়াল এবং ত্রুটির মাধ্যমে। + +অসুবিধাটি হ্যাসের জন্য লক্ষ্য নির্ধারণ করে। টার্গেট যত কম হবে, বৈধ হ্যাসের সেট তত ছোট হবে। একবার তৈরি হয়ে গেলে, অন্যান্য মাইনার এবং ক্লায়েন্টদের জন্য এটি যাচাই করা অবিশ্বাস্যভাবে সহজ ছিল। এমনকি যদি একটি লেনদেন পরিবর্তন হয়, হ্যাস সম্পূর্ণরূপে ভিন্ন হবে, যা জালিয়াতির সংকেত দেবে। + +হ্যাশিং জালিয়াতি সনাক্ত করা সহজ করে তোলে। কিন্তু একটি প্রক্রিয়া হিসাবে প্রুফ-অফ-ওয়ার্কও চেইন আক্রমণ করার জন্য একটি বড় প্রতিরোধক ছিল। + +### প্রুফ-অফ-ওয়ার্ক এবং নিরাপত্তা {#security} + +মাইনারদের প্রধান ইথেরিয়াম চেইনে এই কাজটি করার জন্য উৎসাহিত করা হয়েছিল। মাইনারদের একটি উপসেটের জন্য তাদের নিজস্ব চেইন শুরু করার জন্য সামান্য উৎসাহ ছিল - এটি সিস্টেমকে দুর্বল করে। ব্লকচেইন সত্যের উৎস হিসাবে একটি একক স্টেটের উপর নির্ভর করে। + +প্রুফ-অফ-ওয়ার্কের উদ্দেশ্য ছিল চেইনকে প্রসারিত করা। দীর্ঘতম চেইনটি বৈধ হিসাবে সবচেয়ে বিশ্বাসযোগ্য ছিল কারণ এটি তৈরি করার জন্য সবচেয়ে বেশি গণনামূলক কাজ করা হয়েছিল। ইথেরিয়ামের PoW সিস্টেমের মধ্যে, লেনদেন মুছে ফেলা, নকল তৈরি করা বা দ্বিতীয় চেইন বজায় রাখে এমন নতুন ব্লক তৈরি করা প্রায় অসম্ভব ছিল। কারণ একজন দূষিত মাইনারকে সব সময় অন্য সবার চেয়ে দ্রুত ব্লক নন্স সমাধান করতে হতো। + +ধারাবাহিকভাবে দূষিত অথচ বৈধ ব্লক তৈরি করতে, একজন দূষিত মাইনারকে অন্য সবাইকে হারানোর জন্য নেটওয়ার্ক মাইনিং পাওয়ারের 51% এর বেশি প্রয়োজন হতো। এই পরিমাণ "কাজের" জন্য প্রচুর ব্যয়বহুল কম্পিউটিং শক্তি প্রয়োজন এবং ব্যয় করা শক্তি এমনকি একটি আক্রমণে অর্জিত লাভের চেয়েও বেশি হতে পারে। + +### প্রুফ-অফ-ওয়ার্ক অর্থনীতি {#economics} + +প্রুফ-অফ-ওয়ার্ক সিস্টেমে নতুন মুদ্রা ইস্যু করার এবং মাইনারদের কাজ করার জন্য উৎসাহিত করার জন্যও দায়ী ছিল। + +[কনস্টান্টিনোপল আপগ্রেড](/ethereum-forks/#constantinople) থেকে, যে মাইনাররা সফলভাবে একটি ব্লক তৈরি করে তাদের দুটি নতুন মিন্ট করা ETH এবং লেনদেন ফি-এর অংশ দিয়ে পুরস্কৃত করা হয়েছিল। অমার ব্লকগুলিও 1.75 ETH ক্ষতিপূরণ দিয়েছে। অমার ব্লকগুলি ছিল একজন মাইনার দ্বারা কার্যত একই সময়ে তৈরি করা বৈধ ব্লক যখন অন্য একজন মাইনার ক্যানোনিকাল ব্লক তৈরি করেছিল, যা শেষ পর্যন্ত কোন চেইনটি প্রথমে তৈরি হয়েছিল তার দ্বারা নির্ধারিত হয়েছিল। অমার ব্লক সাধারণত নেটওয়ার্ক লেটেন্সির কারণে ঘটে। + +## ফাইনালিটি {#finality} + +ইথেরিয়ামে একটি লেনদেনের "ফাইনালিটি" থাকে যখন এটি এমন একটি ব্লকের অংশ হয় যা পরিবর্তন করা যায় না। + +যেহেতু মাইনাররা একটি বিকেন্দ্রীভূত উপায়ে কাজ করে, দুটি বৈধ ব্লক একই সময়ে মাইন করা যেতে পারে। এটি একটি অস্থায়ী ফর্ক তৈরি করে। অবশেষে, এই চেইনগুলির মধ্যে একটি পরবর্তী ব্লকগুলি মাইন করা এবং এতে যুক্ত করার পরে গৃহীত চেইন হয়ে ওঠে, যা এটিকে দীর্ঘ করে তোলে। + +বিষয়টিকে আরও জটিল করার জন্য, অস্থায়ী ফর্কে প্রত্যাখ্যাত লেনদেনগুলি গৃহীত চেইনে অন্তর্ভুক্ত নাও হতে পারে। এর মানে হল এটি উল্টে যেতে পারে। সুতরাং ফাইনালিটি বলতে সেই সময়কে বোঝায় যা আপনার একটি লেনদেনকে অপরিবর্তনীয় বিবেচনা করার আগে অপেক্ষা করা উচিত। পূর্ববর্তী প্রুফ-অফ-ওয়ার্ক ইথেরিয়ামের অধীনে, একটি নির্দিষ্ট ব্লক `N`-এর উপরে যত বেশি ব্লক মাইন করা হয়েছিল, `N`-এর লেনদেন সফল হয়েছে এবং প্রত্যাবর্তন করা হবে না তার উপর আস্থা তত বেশি ছিল। এখন, প্রুফ-অফ-স্টেক-এর সাথে, ফাইনালটি একটি ব্লকের সম্ভাব্যতার পরিবর্তে একটি সুস্পষ্ট সম্পত্তি। + +## প্রুফ-অফ-ওয়ার্ক শক্তি-ব্যবহার {#energy} + +প্রুফ-অফ-ওয়ার্কের একটি প্রধান সমালোচনা হল নেটওয়ার্ককে নিরাপদ রাখার জন্য প্রয়োজনীয় শক্তির পরিমাণ। নিরাপত্তা এবং বিকেন্দ্রীকরণ বজায় রাখার জন্য, প্রুফ-অফ-ওয়ার্কে ইথেরিয়াম প্রচুর পরিমাণে শক্তি খরচ করে। প্রুফ-অফ-স্টেকে স্যুইচ করার কিছুক্ষণ আগে, ইথেরিয়াম মাইনাররা সম্মিলিতভাবে প্রায় 70 TWh/বছর খরচ করছিল (প্রায় চেক প্রজাতন্ত্রের সমান - 18-জুলাই-2022-এ [ডিজিকোνομিস্ট](https://digiconomist.net/) অনুসারে)। + +## সুবিধা এবং অসুবিধা {#pros-and-cons} + +| যেসব বিষয়ে এর সুফল পাওয়া যায় | কনস | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| প্রুফ-অফ-ওয়ার্ক নিরপেক্ষ। শুরু করার জন্য আপনার ETH-এর প্রয়োজন নেই এবং ব্লক রিওয়ার্ড আপনাকে 0ETH থেকে একটি ইতিবাচক ব্যালেন্সে যেতে দেয়। [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) দিয়ে শুরু করার জন্য আপনার ETH প্রয়োজন। | প্রুফ-অফ-ওয়ার্ক এত শক্তি ব্যবহার করে যে এটি পরিবেশের জন্য খারাপ। | +| প্রুফ-অফ-ওয়ার্ক একটি পরীক্ষিত এবং পরীক্ষিত কনসেন্সাস মেকানিজম যা বিটকয়েন এবং ইথেরিয়ামকে বহু বছর ধরে নিরাপদ এবং বিকেন্দ্রীভূত রেখেছে। | আপনি যদি মাইন করতে চান, আপনার এমন বিশেষ সরঞ্জামের প্রয়োজন যা শুরু করার জন্য একটি বড় বিনিয়োগ। | +| প্রুফ-অফ-স্টেকের তুলনায় এটি বাস্তবায়ন করা তুলনামূলকভাবে সহজ। | প্রয়োজনীয় গণনার পরিমাণ বৃদ্ধির কারণে, মাইনিং পুলগুলি সম্ভাব্যভাবে মাইনিং গেমটিতে আধিপত্য বিস্তার করতে পারে, যা কেন্দ্রীকরণ এবং নিরাপত্তা ঝুঁকির দিকে পরিচালিত করে। | + +## প্রুফ-অফ-স্টেকের সাথে তুলনা {#compared-to-pos} + +একটি উচ্চ স্তরে, প্রুফ-অফ-স্টেকের প্রুফ-অফ-ওয়ার্কের মতো একই শেষ লক্ষ্য রয়েছে: বিকেন্দ্রীভূত নেটওয়ার্ককে নিরাপদে কনসেন্সাসে পৌঁছাতে সহায়তা করা। তবে প্রক্রিয়া এবং কর্মীদের মধ্যে এর কিছু পার্থক্য রয়েছে: + +- প্রুফ-অফ-স্টেক স্টেক করা ETH-এর জন্য গণনামূলক শক্তির গুরুত্বকে পরিবর্তন করে। +- প্রুফ-অফ-স্টেক মাইনারদেরকে ভ্যালিডেটর দিয়ে প্রতিস্থাপন করে। ভ্যালিডেটররা নতুন ব্লক তৈরি করার ক্ষমতা সক্রিয় করতে তাদের ETH স্টেক করে। +- ভ্যালিডেটররা ব্লক তৈরি করার জন্য প্রতিযোগিতা করে না, পরিবর্তে তারা একটি অ্যালগরিদম দ্বারা এলোমেলোভাবে নির্বাচিত হয়। +- ফাইনালিটি পরিষ্কার: নির্দিষ্ট চেকপয়েন্টে, যদি 2/3 ভ্যালিডেটর ব্লকের স্টেটের উপর একমত হয় তবে এটিকে ফাইনাল হিসাবে বিবেচনা করা হয়। ভ্যালিডেটরদের অবশ্যই তাদের পুরো স্টেক এর উপর বাজি ধরতে হবে, তাই যদি তারা লাইনের নিচে ষড়যন্ত্র করার চেষ্টা করে, তবে তারা তাদের পুরো স্টেক হারাবে। + +[প্রুফ-অফ-স্টেক সম্পর্কে আরও](/developers/docs/consensus-mechanisms/pos/) + +## আপনি কি দেখে শিখতে বেশি পছন্দ করেন? {#visual-learner} + + + +## আরও পড়ুন {#further-reading} + +- [সংখ্যাগরিষ্ঠের আক্রমণ](https://en.bitcoin.it/wiki/Majority_attack) +- [সেটেলমেন্ট ফাইনালিটির উপর](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### ভিডিও {#videos} + +- [প্রুফ-অফ-ওয়ার্ক প্রোটোকলের একটি প্রযুক্তিগত ব্যাখ্যা](https://youtu.be/9V1bipPkCTU) + +## সম্পর্কিত বিষয় {#related-topics} + +- [মাইনিং](/developers/docs/consensus-mechanisms/pow/mining/) +- [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) +- [প্রুফ-অফ-অথোরিটি](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..6a16951a38c --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "মাইনিং" +description: "ইথেরিয়ামে মাইনিং কীভাবে কাজ করত তার একটি ব্যাখ্যা।" +lang: bn +--- + + + + + +প্রুফ-অফ-ওয়ার্ক আর ইথেরিয়ামের কনসেন্সাস মেকানিজমের ভিত্তি নয়, যার অর্থ মাইনিং বন্ধ করে দেওয়া হয়েছে। পরিবর্তে, ইথেরিয়াম ভ্যালিডেটরদের দ্বারা সুরক্ষিত যারা ETH স্টেক করে। আপনি আজই আপনার ETH স্টেকিং শুরু করতে পারেন। The Merge, প্রুফ-অফ-স্টেক, এবং স্টেকিং সম্পর্কে আরও পড়ুন। এই পৃষ্ঠাটি শুধুমাত্র ঐতিহাসিক আগ্রহের জন্য। + + + + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি ভালোভাবে বোঝার জন্য, আমরা আপনাকে প্রথমে [লেনদেন](/developers/docs/transactions/), [ব্লক](/developers/docs/blocks/) এবং [প্রুফ-অফ-ওয়ার্ক](/developers/docs/consensus-mechanisms/pow/) সম্পর্কে পড়ার পরামর্শ দিই। + +## ইথেরিয়াম মাইনিং কী? {#what-is-ethereum-mining} + +মাইনিং হল ইথেরিয়ামের এখন-অপ্রচলিত প্রুফ-অফ-ওয়ার্ক আর্কিটেকচারে ইথেরিয়াম ব্লকচেইনে যোগ করার জন্য লেনদেনের একটি ব্লক তৈরি করার প্রক্রিয়া। + +মাইনিং শব্দটি ক্রিপ্টোকারেন্সির জন্য সোনার উপমা প্রসঙ্গে উদ্ভূত হয়েছে। সোনা বা মূল্যবান ধাতু দুর্লভ, ডিজিটাল টোকেনও তাই, এবং একটি প্রুফ-অফ-ওয়ার্ক সিস্টেমে মোট পরিমাণ বাড়ানোর একমাত্র উপায় হল মাইনিং। প্রুফ-অফ-ওয়ার্ক ইথেরিয়ামে, ইস্যুয়েন্সের একমাত্র পদ্ধতি ছিল মাইনিং। তবে সোনা বা মূল্যবান ধাতুর মতো নয়, ইথেরিয়াম মাইনিং ব্লকচেইনে ব্লক তৈরি, যাচাই, প্রকাশ এবং প্রচার করে নেটওয়ার্ক সুরক্ষিত করার একটি উপায়ও ছিল। + +ইথার মাইনিং = নেটওয়ার্ক সুরক্ষিত করা + +যেকোনো প্রুফ-অফ-ওয়ার্ক ব্লকচেইনের প্রাণশক্তি হল মাইনিং। প্রুফ-অফ-স্টেকে স্থানান্তরিত হওয়ার আগে ইথেরিয়াম মাইনাররা - সফটওয়্যার চালিত কম্পিউটার - তাদের সময় এবং কম্পিউটেশনাল শক্তি ব্যবহার করে লেনদেন প্রক্রিয়া এবং ব্লক তৈরি করত। + +## মাইনারদের অস্তিত্ব কেন? {#why-do-miners-exist} + +ইথেরিয়ামের মতো ডিসেন্ট্রালাইজড সিস্টেমে, আমাদের নিশ্চিত করতে হবে যে সবাই লেনদেনের ক্রমে একমত। মাইনাররা ব্লক তৈরি করার জন্য কম্পিউটেশনালি কঠিন পাজল সমাধান করে, নেটওয়ার্ককে আক্রমণ থেকে সুরক্ষিত করে এটি ঘটতে সাহায্য করেছে। + +[প্রুফ-অফ-ওয়ার্ক সম্পর্কে আরও](/developers/docs/consensus-mechanisms/pow/) + +আগে যে কেউ তাদের কম্পিউটার ব্যবহার করে ইথেরিয়াম নেটওয়ার্কে মাইনিং করতে পারত। তবে, সবাই লাভজনকভাবে ইথার (ETH) মাইনিং করতে পারত না। বেশিরভাগ ক্ষেত্রে, মাইনারদের ডেডিকেটেড কম্পিউটার হার্ডওয়্যার কিনতে হতো এবং সস্তা শক্তির উৎসের অ্যাক্সেস থাকতে হতো। গড় কম্পিউটারের মাইনিংয়ের সাথে সম্পর্কিত খরচগুলি কভার করার জন্য যথেষ্ট ব্লক রিওয়ার্ড উপার্জন করার সম্ভাবনা কম ছিল। + +### মাইনিংয়ের খরচ {#cost-of-mining} + +- একটি মাইনিং রিগ তৈরি এবং রক্ষণাবেক্ষণের জন্য প্রয়োজনীয় হার্ডওয়্যারের সম্ভাব্য খরচ +- মাইনিং রিগকে শক্তি দেওয়ার জন্য বৈদ্যুতিক খরচ +- আপনি যদি একটি পুলে মাইনিং করতেন, তবে এই পুলগুলি সাধারণত পুল দ্বারা তৈরি প্রতিটি ব্লকের উপর একটি নির্দিষ্ট % ফি চার্জ করত +- মাইনিং রিগকে সাপোর্ট করার জন্য প্রয়োজনীয় যন্ত্রপাতির সম্ভাব্য খরচ (ভেন্টিলেশন, শক্তি পর্যবেক্ষণ, বৈদ্যুতিক ওয়্যারিং, ইত্যাদি) + +মাইনিং লাভজনকতা আরও অন্বেষণ করতে, একটি মাইনিং ক্যালকুলেটর ব্যবহার করুন, যেমনটি [Etherscan](https://etherscan.io/ether-mining-calculator) প্রদান করে। + +## ইথেরিয়াম লেনদেন কীভাবে মাইনিং করা হয়েছিল {#how-ethereum-transactions-were-mined} + +নিচে ইথেরিয়াম প্রুফ-অফ-ওয়ার্কে লেনদেনগুলি কীভাবে মাইনিং করা হয়েছিল তার একটি সংক্ষিপ্ত বিবরণ দেওয়া হল। ইথেরিয়াম প্রুফ-অফ-স্টেকের জন্য এই প্রক্রিয়ার একটি অনুরূপ বিবরণ [এখানে](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) পাওয়া যাবে। + +1. একজন ব্যবহারকারী কিছু [অ্যাকাউন্টের](/developers/docs/accounts/) প্রাইভেট কী দিয়ে একটি [লেনদেন](/developers/docs/transactions/) অনুরোধ লেখেন এবং স্বাক্ষর করেন। +2. ব্যবহারকারী কিছু [নোড](/developers/docs/nodes-and-clients/) থেকে সমগ্র ইথেরিয়াম নেটওয়ার্কে লেনদেনের অনুরোধটি ব্রডকাস্ট করেন। +3. নতুন লেনদেনের অনুরোধ সম্পর্কে শোনার পরে, ইথেরিয়াম নেটওয়ার্কের প্রতিটি নোড তাদের স্থানীয় মেমপুলে অনুরোধটি যুক্ত করে, যা তারা শুনেছে এমন সমস্ত লেনদেনের অনুরোধের একটি তালিকা যা এখনও একটি ব্লকে ব্লকচেইনে জমা হয়নি। +4. এক পর্যায়ে, একটি মাইনিং নোড ব্লক গ্যাস লিমিটের নিচে থেকে তারা যে [ট্রানজ্যাকশন ফি](/developers/docs/gas/) উপার্জন করে তা সর্বাধিক করার উপায়ে বেশ কয়েকটি ডজন বা শত শত লেনদেনের অনুরোধকে একটি সম্ভাব্য [ব্লকে](/developers/docs/blocks/) একত্রিত করে। তারপর মাইনিং নোড: + 1. প্রতিটি লেনদেনের অনুরোধের বৈধতা যাচাই করে (যেমন, কেউ এমন একটি অ্যাকাউন্ট থেকে ইথার স্থানান্তর করার চেষ্টা করছে না যার জন্য তারা একটি স্বাক্ষর তৈরি করেনি, অনুরোধটি ত্রুটিপূর্ণ নয়, ইত্যাদি), এবং তারপর অনুরোধের কোড কার্যকর করে, তাদের EVM-এর স্থানীয় কপির স্টেট পরিবর্তন করে। মাইনার প্রতিটি এই ধরনের লেনদেনের অনুরোধের জন্য ট্রানজ্যাকশন ফি তাদের নিজস্ব অ্যাকাউন্টে পুরস্কার হিসেবে দেয়। + 2. ব্লকের সমস্ত লেনদেনের অনুরোধ যাচাই এবং স্থানীয় EVM কপিতে কার্যকর করার পরে, সম্ভাব্য ব্লকের জন্য প্রুফ-অফ-ওয়ার্ক “বৈধতার শংসাপত্র” তৈরি করার প্রক্রিয়া শুরু করে। +5. অবশেষে, একজন মাইনার একটি ব্লকের জন্য একটি শংসাপত্র তৈরি করা শেষ করবে যার মধ্যে আমাদের নির্দিষ্ট লেনদেনের অনুরোধ অন্তর্ভুক্ত থাকবে। তারপর মাইনার সম্পূর্ণ ব্লকটি ব্রডকাস্ট করে, যার মধ্যে শংসাপত্র এবং দাবি করা নতুন EVM স্টেটের একটি চেকসাম অন্তর্ভুক্ত থাকে। +6. অন্যান্য নোড নতুন ব্লক সম্পর্কে শুনতে পায়। তারা শংসাপত্র যাচাই করে, ব্লকের সমস্ত লেনদেন নিজেরাই কার্যকর করে (আমাদের ব্যবহারকারীর দ্বারা মূলত ব্রডকাস্ট করা লেনদেন সহ), এবং যাচাই করে যে সমস্ত লেনদেন কার্যকর করার পরে তাদের নতুন EVM স্টেটের চেকসাম মাইনারের ব্লক দ্বারা দাবি করা স্টেটের চেকসামের সাথে মেলে। শুধুমাত্র তারপরেই এই নোডগুলি এই ব্লকটিকে তাদের ব্লকচেইনের লেজে যুক্ত করে এবং নতুন EVM স্টেটকে ক্যানোনিকাল স্টেট হিসাবে গ্রহণ করে। +7. প্রতিটি নোড নতুন ব্লকের সমস্ত লেনদেন তাদের স্থানীয় অসম্পূর্ণ লেনদেন অনুরোধের মেমপুল থেকে সরিয়ে দেয়। +8. নেটওয়ার্কে যোগদানকারী নতুন নোডগুলি আমাদের আগ্রহের লেনদেন ধারণকারী ব্লক সহ ক্রমানুসারে সমস্ত ব্লক ডাউনলোড করে। তারা একটি স্থানীয় EVM কপি শুরু করে (যা একটি ফাঁকা-স্টেট EVM হিসাবে শুরু হয়), এবং তারপরে তাদের স্থানীয় EVM কপির উপরে প্রতিটি ব্লকের প্রতিটি লেনদেন কার্যকর করার প্রক্রিয়ার মধ্য দিয়ে যায়, পথে প্রতিটি ব্লকে স্টেট চেকসাম যাচাই করে। + +প্রতিটি লেনদেন একবার মাইনিং করা হয় (একটি নতুন ব্লকে অন্তর্ভুক্ত করা হয় এবং প্রথমবারের জন্য প্রচার করা হয়), কিন্তু ক্যানোনিকাল EVM স্টেটকে এগিয়ে নেওয়ার প্রক্রিয়ায় প্রতিটি অংশগ্রহণকারী দ্বারা কার্যকর এবং যাচাই করা হয়। এটি ব্লকচেইনের একটি কেন্দ্রীয় মন্ত্রকে তুলে ধরে: **বিশ্বাস করবেন না, যাচাই করুন**। + +## Ommer (আঙ্কল) ব্লক {#ommer-blocks} + +প্রুফ-অফ-ওয়ার্কে ব্লক মাইনিং ছিল সম্ভাবনামূলক, যার মানে কখনও কখনও নেটওয়ার্ক লেটেন্সির কারণে দুটি বৈধ ব্লক একই সাথে প্রকাশিত হত। এই ক্ষেত্রে, প্রোটোকলকে দীর্ঘতম (এবং তাই সবচেয়ে "বৈধ") চেইন নির্ধারণ করতে হয়েছিল এবং প্রস্তাবিত অন্তর্ভুক্ত না হওয়া বৈধ ব্লককে আংশিকভাবে রিওয়ার্ড দিয়ে মাইনারদের প্রতি ন্যায্যতা নিশ্চিত করতে হয়েছিল। এটি নেটওয়ার্কের আরও বিকেন্দ্রীকরণকে উৎসাহিত করেছে কারণ ছোট মাইনাররা, যারা বেশি লেটেন্সির সম্মুখীন হতে পারে, তারা এখনও [ommer](/glossary/#ommer) ব্লক রিওয়ার্ডের মাধ্যমে রিটার্ন জেনারেট করতে পারত। + +"ommer" শব্দটি একটি প্যারেন্ট ব্লকের সহোদরের জন্য পছন্দের লিঙ্গ-নিরপেক্ষ শব্দ, তবে এটিকে কখনও কখনও "uncle" হিসাবেও উল্লেখ করা হয়। **ইথেরিয়াম প্রুফ-অফ-স্টেকে স্থানান্তরিত হওয়ার পর থেকে, ommer ব্লক আর মাইনিং করা হয় না** কারণ প্রতিটি স্লটে শুধুমাত্র একজন প্রস্তাবককে নির্বাচিত করা হয়। মাইনিং করা ommer ব্লকের [ঐতিহাসিক চার্ট](https://ycharts.com/indicators/ethereum_uncle_rate) দেখে আপনি এই পরিবর্তনটি দেখতে পারেন। + +## একটি ভিজ্যুয়াল ডেমো {#a-visual-demo} + +দেখুন অস্টিন আপনাকে মাইনিং এবং প্রুফ-অফ-ওয়ার্ক ব্লকচেইন সম্পর্কে বোঝাচ্ছেন। + + + +## মাইনিং অ্যালগরিদম {#mining-algorithm} + +ইথেরিয়াম মেইননেট শুধুমাত্র একটি মাইনিং অ্যালগরিদম ব্যবহার করেছে - ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)। Ethash ছিল ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) নামে পরিচিত একটি আসল R&D অ্যালগরিদমের উত্তরসূরি। + +[মাইনিং অ্যালগরিদম সম্পর্কে আরও](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/)। + +## সম্পর্কিত বিষয় {#related-topics} + +- [গ্যাস](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [প্রুফ-অফ-ওয়ার্ক](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..018f4c0a6ce --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,330 @@ +--- +title: Dagger-Hashimoto +description: "Dagger-Hashimoto অ্যালগরিদমের একটি বিশদ আলোচনা।" +lang: bn +--- + +Dagger-Hashimoto ছিল Ethereum-এর মাইনিং অ্যালগরিদমের জন্য মূল গবেষণা বাস্তবায়ন এবং স্পেসিফিকেশন। Dagger-Hashimoto [Ethash](#ethash) দ্বারা প্রতিস্থাপিত হয়েছিল। ১৫ই সেপ্টেম্বর ২০২২-এ [The Merge](/roadmap/merge/)-এ মাইনিং সম্পূর্ণভাবে বন্ধ করে দেওয়া হয়েছিল। তারপর থেকে, Ethereum পরিবর্তে একটি [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos) মেকানিজম ব্যবহার করে সুরক্ষিত হয়েছে। এই পৃষ্ঠাটি ঐতিহাসিক আগ্রহের জন্য - এখানে থাকা তথ্যগুলি মার্জ-পরবর্তী Ethereum-এর জন্য আর প্রাসঙ্গিক নয়। + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি আরও ভালভাবে বোঝার জন্য, আমরা আপনাকে প্রথমে [প্রুফ-অফ-ওয়ার্ক কনসেন্সাস](/developers/docs/consensus-mechanisms/pow), [মাইনিং](/developers/docs/consensus-mechanisms/pow/mining), এবং [মাইনিং অ্যালগরিদম](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) সম্পর্কে পড়ার পরামর্শ দিই। + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto দুটি লক্ষ্য পূরণের লক্ষ্য রাখে: + +1. **ASIC-প্রতিরোধ**: অ্যালগরিদমের জন্য বিশেষ হার্ডওয়্যার তৈরির সুবিধা যতটা সম্ভব কম হওয়া উচিত। +2. **লাইট ক্লায়েন্ট যাচাইযোগ্যতা**: একটি ব্লক একটি লাইট ক্লায়েন্ট দ্বারা দক্ষতার সাথে যাচাইযোগ্য হওয়া উচিত। + +একটি অতিরিক্ত পরিবর্তনের সাথে, আমরা আরও নির্দিষ্ট করি যে ইচ্ছা হলে কীভাবে তৃতীয় লক্ষ্য পূরণ করা যায়, তবে অতিরিক্ত জটিলতার মূল্যে: + +**সম্পূর্ণ চেইন স্টোরেজ**: মাইনিংয়ের জন্য সম্পূর্ণ ব্লকচেইন স্টেটের স্টোরেজ প্রয়োজন হবে (Ethereum স্টেট ট্রাই-এর অনিয়মিত কাঠামোর কারণে, আমরা আশা করি যে কিছু ছাঁটাই সম্ভব হবে, বিশেষ করে কিছু প্রায়শই ব্যবহৃত চুক্তির ক্ষেত্রে, তবে আমরা এটি কমানো করতে চাই)। + +## DAG জেনারেশন {#dag-generation} + +অ্যালগরিদমের জন্য কোডটি নিচে পাইথনে সংজ্ঞায়িত করা হবে। প্রথমে, আমরা নির্দিষ্ট নির্ভুলতার আনসাইন্ড পূর্ণসংখ্যাকে স্ট্রিং-এ মার্শালিং করার জন্য `encode_int` প্রদান করি। এর বিপরীতটিও দেওয়া হল: + +```python +NUM_BITS = 512 + +def encode_int(x): + "একটি ইন্টিজার x কে একটি স্ট্রিং হিসাবে এনকোড করুন যা 64টি অক্ষর নিয়ে গঠিত, একটি বড়-এন্ডিয়ান স্কিম ব্যবহার করে" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "একটি বড়-এন্ডিয়ান স্কিম ব্যবহার করে একটি স্ট্রিং থেকে একটি ইন্টিজার x আনএনকোড করুন" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +আমরা এরপরে ধরে নিই যে `sha3` একটি ফাংশন যা একটি পূর্ণসংখ্যা নেয় এবং একটি পূর্ণসংখ্যা আউটপুট দেয়, এবং `dbl_sha3` একটি ডাবল-sha3 ফাংশন; যদি এই রেফারেন্স কোডটিকে একটি বাস্তবায়নে রূপান্তর করা হয় তবে ব্যবহার করুন: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### প্যারামিটার {#parameters} + +অ্যালগরিদমের জন্য ব্যবহৃত প্যারামিটারগুলি হল: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # ২**৫১২ এর চেয়ে কম বৃহত্তম সেফ প্রাইম + +params = { + "n": 4000055296 * 8 // NUM_BITS, # ডেটাসেটের আকার (4 গিগাবাইট); অবশ্যই 65536 এর গুণিতক হতে হবে + "n_inc": 65536, # প্রতি পিরিয়ডে n-এর মানের বৃদ্ধি; অবশ্যই 65536 এর গুণিতক হতে হবে + # epochtime=20000 হলে প্রতি বছর 882 MB বৃদ্ধি পায় + "cache_size": 2500, # লাইট ক্লায়েন্টের ক্যাশের আকার (লাইট ক্লায়েন্ট দ্বারা নির্বাচিত হতে পারে; + # অ্যালগো স্পেকের অংশ নয়) + "diff": 2**14, # কঠিনতা (ব্লক মূল্যায়নের সময় সমন্বয় করা হয়) + "epochtime": 100000, # ব্লকগুলিতে একটি যুগের দৈর্ঘ্য (কত ঘন ঘন ডেটাসেট আপডেট করা হয়) + "k": 1, # একটি নোডের প্যারেন্টের সংখ্যা + "w": w, # মডুলার এক্সপোনেনশিয়েশন হ্যাশিংয়ের জন্য ব্যবহৃত হয় + "accesses": 200, # হ্যাশিমোটো চলাকালীন ডেটাসেট অ্যাক্সেসের সংখ্যা + "P": SAFE_PRIME_512 # হ্যাশিং এবং র‍্যান্ডম নম্বর জেনারেশনের জন্য নিরাপদ প্রাইম +} +``` + +`P` এই ক্ষেত্রে এমন একটি প্রাইম যা এমনভাবে বেছে নেওয়া হয়েছে যে `log₂(P)` 512-এর চেয়ে সামান্য কম, যা আমাদের সংখ্যাগুলিকে উপস্থাপন করার জন্য আমরা যে 512 বিট ব্যবহার করছি তার সাথে সঙ্গতিপূর্ণ। লক্ষ্য করুন যে DAG-এর শুধুমাত্র শেষার্ধটি সঞ্চয় করা প্রয়োজন, তাই ডি-ফ্যাক্টো RAM-এর প্রয়োজনীয়তা 1 GB থেকে শুরু হয় এবং প্রতি বছর 441 MB বৃদ্ধি পায়। + +### ডেগার গ্রাফ বিল্ডিং {#dagger-graph-building} + +ডেগার গ্রাফ বিল্ডিং প্রিমিটিভটি নিম্নরূপ সংজ্ঞায়িত করা হয়েছে: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +মূলত, এটি একটি গ্রাফকে একটি একক নোড, `sha3(seed)` হিসাবে শুরু করে এবং সেখান থেকে এলোমেলো পূর্ববর্তী নোডের উপর ভিত্তি করে ক্রমানুসারে অন্যান্য নোড যুক্ত করা শুরু করে। যখন একটি নতুন নোড তৈরি করা হয়, তখন `i`-এর চেয়ে কম কিছু সূচক এলোমেলোভাবে নির্বাচন করার জন্য সিডের একটি মডুলার পাওয়ার গণনা করা হয় (উপরে `x % i` ব্যবহার করে), এবং সেই সূচকে থাকা নোডগুলির মানগুলি একটি গণনায় ব্যবহার করা হয় `x`-এর জন্য একটি নতুন মান তৈরি করতে, যা পরে একটি ছোট প্রুফ অফ ওয়ার্ক ফাংশনে (XOR-এর উপর ভিত্তি করে) ফিড করা হয় যাতে অবশেষে সূচক `i`-তে গ্রাফের মান তৈরি করা যায়। এই বিশেষ ডিজাইনের পিছনে যুক্তি হল DAG-এর অনুক্রমিক অ্যাক্সেস জোর করা; DAG-এর পরবর্তী মান যা অ্যাক্সেস করা হবে তা বর্তমান মান না জানা পর্যন্ত নির্ধারণ করা যাবে না। অবশেষে, মডুলার এক্সপোনেনশিয়েশন ফলাফলটিকে আরও হ্যাস করে। + +এই অ্যালগরিদম সংখ্যা তত্ত্বের বেশ কয়েকটি ফলাফলের উপর নির্ভর করে। আলোচনার জন্য নীচের পরিশিষ্ট দেখুন। + +## লাইট ক্লায়েন্ট মূল্যায়ন {#light-client-evaluation} + +উপরের গ্রাফ নির্মাণটি গ্রাফের প্রতিটি নোডকে শুধুমাত্র অল্প সংখ্যক নোডের একটি সাবট্রি গণনা করে এবং শুধুমাত্র অল্প পরিমাণে সহায়ক মেমরির প্রয়োজন করে পুনর্গঠন করার অনুমতি দেওয়ার উদ্দেশ্যে করা হয়েছে। লক্ষ্য করুন যে k=1 হলে, সাবট্রিটি DAG-এর প্রথম উপাদান পর্যন্ত যাওয়া মানগুলির একটি চেইন মাত্র। + +DAG-এর জন্য লাইট ক্লায়েন্ট কম্পিউটিং ফাংশনটি নিম্নরূপ কাজ করে: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +মূলত, এটি উপরের অ্যালগরিদমের একটি পুনর্লিখন যা সম্পূর্ণ DAG-এর জন্য মান গণনা করার লুপটি সরিয়ে দেয় এবং পূর্ববর্তী নোড লুকআপকে একটি পুনরাবৃত্তিমূলক কল বা একটি ক্যাশে লুকআপ দিয়ে প্রতিস্থাপন করে। লক্ষ্য করুন যে `k=1`-এর জন্য ক্যাশে অপ্রয়োজনীয়, যদিও একটি আরও অপ্টিমাইজেশান আসলে DAG-এর প্রথম কয়েক হাজার মান প্রিকম্পিউট করে এবং সেটিকে গণনার জন্য একটি স্ট্যাটিক ক্যাশে হিসাবে রাখে; এর একটি কোড বাস্তবায়নের জন্য পরিশিষ্ট দেখুন। + +## DAG-এর ডাবল বাফার {#double-buffer} + +একটি সম্পূর্ণ ক্লায়েন্টে, উপরের সূত্র দ্বারা উৎপাদিত 2টি DAG-এর একটি [_ডাবল বাফার_](https://wikipedia.org/wiki/Multiple_buffering) ব্যবহার করা হয়। ধারণাটি হল যে উপরের প্যারাম অনুযায়ী প্রতি `epochtime` সংখ্যক ব্লক অন্তর DAG তৈরি করা হয়। ক্লায়েন্ট সর্বশেষ উৎপাদিত DAG ব্যবহার করার পরিবর্তে, এটি পূর্ববর্তীটি ব্যবহার করে। এর সুবিধা হল এটি সময়ের সাথে সাথে DAG-গুলিকে প্রতিস্থাপন করার অনুমতি দেয় এমন একটি ধাপ অন্তর্ভুক্ত করার প্রয়োজন ছাড়াই যেখানে মাইনারদের হঠাৎ করে সমস্ত ডেটা পুনরায় গণনা করতে হবে। অন্যথায়, নিয়মিত বিরতিতে চেইন প্রক্রিয়াকরণে একটি আকস্মিক অস্থায়ী মন্দার সম্ভাবনা রয়েছে এবং নাটকীয়ভাবে কেন্দ্রীকরণ বৃদ্ধি পায়। এইভাবে সমস্ত ডেটা পুনরায় গণনা করার আগে সেই কয়েক মিনিটের মধ্যে 51% আক্রমণের ঝুঁকি থাকে। + +একটি ব্লকের জন্য কাজ গণনা করতে ব্যবহৃত DAG-এর সেট তৈরি করতে ব্যবহৃত অ্যালগরিদমটি নিম্নরূপ: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # কোনো ব্যাক বাফার সম্ভব নয়, শুধু ফ্রন্ট বাফার তৈরি করুন + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## হ্যাশিমোটো {#hashimoto} + +আসল হ্যাশিমোটোর পিছনের ধারণাটি হল ব্লকচেইনকে একটি ডেটাসেট হিসাবে ব্যবহার করা, একটি গণনা সম্পাদন করা যা ব্লকচেইন থেকে N সূচক নির্বাচন করে, সেই সূচকগুলিতে লেনদেন সংগ্রহ করে, এই ডেটার একটি XOR সম্পাদন করে এবং ফলাফলের হ্যাস প্রদান করে। থ্যাডিউস ড্রায়জার আসল অ্যালগরিদম, সামঞ্জস্যের জন্য পাইথনে অনূদিত, নিম্নরূপ: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +দুর্ভাগ্যবশত, যদিও হ্যাশিমোটোকে RAM হার্ড হিসাবে বিবেচনা করা হয়, এটি 256-বিট গাণিতিকের উপর নির্ভর করে, যার যথেষ্ট গণনামূলক ওভারহেড রয়েছে। যাইহোক, Dagger-Hashimoto এই সমস্যাটি সমাধান করার জন্য তার ডেটাসেটকে ইন্ডেক্স করার সময় শুধুমাত্র সর্বনিম্ন গুরুত্বপূর্ণ 64 বিট ব্যবহার করে। + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +ডাবল SHA3-এর ব্যবহার জিরো-ডেটা, প্রায়-তাত্ক্ষণিক প্রাক-যাচাইকরণের একটি ফর্মের অনুমতি দেয়, শুধুমাত্র এটি যাচাই করে যে একটি সঠিক মধ্যবর্তী মান প্রদান করা হয়েছিল। প্রুফ-অফ-ওয়ার্কের এই বাইরের লেয়ারটি অত্যন্ত ASIC-বান্ধব এবং মোটামুটি দুর্বল, তবে এটি DDoS-কে আরও কঠিন করার জন্য বিদ্যমান কারণ একটি ব্লক তৈরি করার জন্য সেই অল্প পরিমাণ কাজ অবশ্যই করতে হবে যা অবিলম্বে বাতিল করা হবে না। এখানে লাইট-ক্লায়েন্ট সংস্করণটি রয়েছে: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## মাইনিং এবং যাচাইকরণ {#mining-and-verifying} + +এখন, আসুন আমরা সবকিছু একসাথে মাইনিং অ্যালগরিদমে রাখি: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +এখানে যাচাইকরণ অ্যালগরিদমটি রয়েছে: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +লাইট-ক্লায়েন্ট বন্ধুত্বপূর্ণ যাচাইকরণ: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +এছাড়াও, মনে রাখবেন যে Dagger-Hashimoto ব্লক হেডারের উপর অতিরিক্ত প্রয়োজনীয়তা আরোপ করে: + +- দুই-স্তরীয় যাচাইকরণের কাজ করার জন্য, একটি ব্লক হেডারে অবশ্যই ননস এবং মধ্যবর্তী মান উভয়ই প্রাক-sha3 থাকতে হবে। +- কোথাও, একটি ব্লক হেডারকে অবশ্যই বর্তমান সিডসেটের sha3 সংরক্ষণ করতে হবে। + +## আরও পড়ুন {#further-reading} + +_এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন যা আপনাকে সাহায্য করেছে? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যোগ করুন!_ + +## পরিশিষ্ট {#appendix} + +উপরে উল্লিখিত হিসাবে, DAG প্রজন্মের জন্য ব্যবহৃত RNG সংখ্যা তত্ত্বের কিছু ফলাফলের উপর নির্ভর করে। প্রথমত, আমরা নিশ্চিত করি যে লেহমার আরএনজি যা `picker` ভেরিয়েবলের ভিত্তি তার একটি বিস্তৃত সময়কাল রয়েছে। দ্বিতীয়ত, আমরা দেখাই যে `pow(x,3,P)` `x`-কে `1` বা `P-1`-এ ম্যাপ করবে না যদি `x ∈ [2,P-2]` দিয়ে শুরু করা হয়। অবশেষে, আমরা দেখাই যে হ্যাশিং ফাংশন হিসাবে ব্যবহার করা হলে `pow(x,3,P)`-এর সংঘর্ষের হার কম থাকে। + +### লেহমার র‍্যান্ডম নম্বর জেনারেটর {#lehmer-random-number} + +যদিও `produce_dag` ফাংশনটিকে নিরপেক্ষ র‍্যান্ডম সংখ্যা তৈরি করতে হবে না, একটি সম্ভাব্য হুমকি হল `seed**i % P` শুধুমাত্র মুষ্টিমেয় কিছু মান নেয়। এটি প্যাটার্নটি চিনতে পারা মাইনারদের জন্য একটি সুবিধা প্রদান করতে পারে যারা তা করে না। + +এটি এড়াতে, সংখ্যা তত্ত্বের একটি ফলাফলের সাহায্য নেওয়া হয়। একটি [_সেফ প্রাইম_](https://en.wikipedia.org/wiki/Safe_prime)-কে একটি প্রাইম `P` হিসাবে সংজ্ঞায়িত করা হয় যাতে `(P-1)/2`ও প্রাইম হয়। [গুণক গ্রুপ](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ`-এর একটি সদস্য `x`-এর _ক্রম_ কে ন্যূনতম `m` হিসাবে সংজ্ঞায়িত করা হয় যেমন 
xᵐ mod P ≡ 1
+এই সংজ্ঞাগুলি দেওয়া হলে, আমরা পাই: + +> পর্যবেক্ষণ ১। ধরা যাক, `x` একটি সেফ প্রাইম `P`-এর জন্য গুণক গ্রুপ `ℤ/Pℤ`-এর একটি সদস্য। যদি `x mod P ≠ 1 mod P` এবং `x mod P ≠ P-1 mod P` হয়, তাহলে `x`-এর ক্রম হয় `P-1` অথবা `(P-1)/2` হবে। + +_প্রমাণ_। যেহেতু `P` একটি সেফ প্রাইম, তাই [লাগ্রাঞ্জের উপপাদ্য][lagrange] দ্বারা আমরা পাই যে `x`-এর ক্রম হয় `1`, `2`, `(P-1)/2`, অথবা `P-1`। + +`x`-এর ক্রম `1` হতে পারে না, যেহেতু ফার্মার ছোট উপপাদ্য দ্বারা আমরা পাই: + +
xP-1 mod P ≡ 1
+ +অতএব, `x` অবশ্যই `ℤ/nℤ`-এর একটি গুণক পরিচয় হতে হবে, যা অনন্য। যেহেতু আমরা ধরে নিয়েছি যে `x ≠ 1`, তাই এটি সম্ভব নয়। + +`x`-এর ক্রম `2` হতে পারে না যদি না `x = P-1` হয়, কারণ এটি `P`-এর প্রাইম হওয়ার বিষয়টিকে লঙ্ঘন করবে। + +উপরের প্রস্তাবনা থেকে, আমরা বুঝতে পারি যে `(picker * init) % P`-এর পুনরাবৃত্তির একটি চক্র দৈর্ঘ্য অন্তত `(P-1)/2` হবে। এর কারণ হল আমরা `P`-কে দুইয়ের একটি উচ্চতর পাওয়ারের প্রায় সমান একটি সেফ প্রাইম হিসাবে নির্বাচন করেছি, এবং `init` ব্যবধান `[2,2**256+1]`-এর মধ্যে রয়েছে। `P`-এর বিশালতার পরিপ্রেক্ষিতে, আমাদের মডুলার এক্সপোনেনশিয়েশন থেকে কোনো চক্র আশা করা উচিত নয়। + +যখন আমরা DAG-এর প্রথম সেলটি নির্ধারণ করছি (`init` লেবেলযুক্ত ভেরিয়েবল), আমরা `pow(sha3(seed) + 2, 3, P)` গণনা করি। প্রথম নজরে, এটি গ্যারান্টি দেয় না যে ফলাফলটি `1` বা `P-1` কোনোটিই নয়। যাইহোক, যেহেতু `P-1` একটি সেফ প্রাইম, আমাদের কাছে নিম্নলিখিত অতিরিক্ত আশ্বাস রয়েছে, যা পর্যবেক্ষণ ১-এর একটি উপসিদ্ধান্ত: + +> পর্যবেক্ষণ ২। ধরা যাক, `x` একটি সেফ প্রাইম `P`-এর জন্য গুণক গ্রুপ `ℤ/Pℤ`-এর একটি সদস্য, এবং ধরা যাক `w` একটি স্বাভাবিক সংখ্যা। যদি `x mod P ≠ 1 mod P` এবং `x mod P ≠ P-1 mod P` হয়, এবং সেইসাথে `w mod P ≠ P-1 mod P` এবং `w mod P ≠ 0 mod P` হয়, তাহলে `xʷ mod P ≠ 1 mod P` এবং `xʷ mod P ≠ P-1 mod P` হবে। + +### একটি হ্যাস ফাংশন হিসাবে মডুলার এক্সপোনেনসিয়েশন {#modular-exponentiation} + +`P` এবং `w`-এর নির্দিষ্ট মানের জন্য, `pow(x, w, P)` ফাংশনে অনেক সংঘর্ষ হতে পারে। উদাহরণস্বরূপ, `pow(x,9,19)` শুধুমাত্র `{1,18}` মানগুলি নেয়। + +যেহেতু `P` প্রাইম, তাই একটি মডুলার এক্সপোনেনশিয়েশন হ্যাশিং ফাংশনের জন্য একটি উপযুক্ত `w` নিম্নলিখিত ফলাফল ব্যবহার করে বেছে নেওয়া যেতে পারে: + +> পর্যবেক্ষণ ৩। ধরা যাক, `P` একটি প্রাইম; `w` এবং `P-1` তুলনামূলকভাবে প্রাইম হবে যদি এবং কেবল যদি `ℤ/Pℤ`-এর সমস্ত `a` এবং `b`-এর জন্য:
`aʷ mod P ≡ bʷ mod P` হয় যদি এবং কেবল যদি `a mod P ≡ b mod P` হয়
+ +এইভাবে, যেহেতু `P` প্রাইম এবং `w` `P-1`-এর সাথে তুলনামূলকভাবে প্রাইম, আমরা পাই যে `|{pow(x, w, P) : x ∈ ℤ}| = P`, যা বোঝায় যে হ্যাশিং ফাংশনের সম্ভাব্য সর্বনিম্ন সংঘর্ষের হার রয়েছে। + +বিশেষ ক্ষেত্রে যখন `P` আমাদের নির্বাচিত সেফ প্রাইম, তখন `P-1`-এর শুধুমাত্র উৎপাদক 1, 2, `(P-1)/2` এবং `P-1` থাকে। যেহেতু `P` > 7, আমরা জানি যে 3 `P-1`-এর সাথে তুলনামূলকভাবে প্রাইম, তাই `w=3` উপরের প্রস্তাবনাটি পূরণ করে। + +## আরও দক্ষ ক্যাশে-ভিত্তিক মূল্যায়ন অ্যালগরিদম {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..2dbf077b275 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1022 @@ +--- +title: Ethash +description: "Ethash অ্যালগরিদমটির একটি বিস্তারিত বিবরণ।" +lang: bn +--- + + + + + + Ethash ছিল Ethereum-এর প্রুফ-অফ-ওয়ার্ক মাইনিং অ্যালগরিদম। প্রুফ-অফ-ওয়ার্ক এখন **সম্পূর্ণরূপে বন্ধ করে দেওয়া হয়েছে** এবং Ethereum এখন এর পরিবর্তে [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) ব্যবহার করে সুরক্ষিত। [The Merge](/roadmap/merge/), [প্রুফ-অফ-স্টেক](/developers/docs/consensus-mechanisms/pos/) এবং [স্টেকিং](/staking/) সম্পর্কে আরও পড়ুন। এই পৃষ্ঠাটি ঐতিহাসিক আগ্রহের জন্য! + + + + +Ethash হল [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) অ্যালগরিদমের একটি পরিবর্তিত সংস্করণ। Ethash প্রুফ-অফ-ওয়ার্ক [মেমরি হার্ড](https://wikipedia.org/wiki/Memory-hard_function), যা অ্যালগরিদমটিকে ASIC প্রতিরোধী করে তুলবে বলে মনে করা হয়েছিল। Ethash ASIC অবশেষে তৈরি করা হয়েছিল কিন্তু প্রুফ-অফ-ওয়ার্ক বন্ধ না হওয়া পর্যন্ত GPU মাইনিং একটি কার্যকর বিকল্প ছিল। Ethash এখনও অন্যান্য নন-Ethereum প্রুফ-অফ-ওয়ার্ক নেটওয়ার্কে অন্য কয়েন মাইন করতে ব্যবহৃত হয়। + +## Ethash কিভাবে কাজ করে? {#how-does-ethash-work} + +মেমরি হার্ডনেস একটি প্রুফ-অফ-ওয়ার্ক অ্যালগরিদম দিয়ে অর্জন করা হয় যার জন্য ননস এবং ব্লক হেডারের উপর নির্ভরশীল একটি নির্দিষ্ট রিসোর্সের সাবসেট বেছে নিতে হয়। এই রিসোর্স (আকারে কয়েক গিগাবাইট) কে DAG বলা হয়। DAG প্রতি 30000 ব্লকে পরিবর্তিত হয়, একটি ~125-ঘন্টার উইন্ডো যাকে ইপক বলা হয় (প্রায় 5.2 দিন) এবং এটি তৈরি হতে কিছুটা সময় নেয়। যেহেতু DAG শুধুমাত্র ব্লকের উচ্চতার উপর নির্ভর করে, তাই এটি আগে থেকে তৈরি করা যেতে পারে, কিন্তু যদি তা না করা হয় তাহলে ক্লায়েন্টকে একটি ব্লক তৈরি করার জন্য এই প্রক্রিয়ার শেষ পর্যন্ত অপেক্ষা করতে হবে। যদি ক্লায়েন্টরা সময়ের আগে DAG তৈরি এবং ক্যাশে না করে, তাহলে প্রতিটি ইপক পরিবর্তনের সময় নেটওয়ার্কে ব্যাপক ব্লক বিলম্ব হতে পারে। নোট করুন যে প্রুফ-অফ-ওয়ার্ক যাচাই করার জন্য DAG তৈরি করার প্রয়োজন নেই, যা মূলত কম CPU এবং ছোট মেমরি উভয় দিয়েই যাচাইকরণের অনুমতি দেয়। + +অ্যালগরিদমটি যে সাধারণ পথ গ্রহণ করে তা নিম্নরূপ: + +1. একটি **সীড** বিদ্যমান যা প্রতিটি ব্লকের জন্য সেই পর্যন্ত ব্লক হেডারগুলো স্ক্যান করে গণনা করা যেতে পারে। +2. সীড থেকে, একজন একটি **16 MB সিউডোর‍্যান্ডম ক্যাশে** গণনা করতে পারে। লাইট ক্লায়েন্টরা ক্যাশে সংরক্ষণ করে। +3. ক্যাশে থেকে, আমরা একটি **1 GB ডেটাসেট** তৈরি করতে পারি, এই বৈশিষ্ট্য সহ যে ডেটাসেটের প্রতিটি আইটেম ক্যাশে থেকে শুধুমাত্র অল্প সংখ্যক আইটেমের উপর নির্ভর করে। সম্পূর্ণ ক্লায়েন্ট এবং মাইনাররা ডেটাসেট সংরক্ষণ করে। ডেটাসেট সময়ের সাথে রৈখিকভাবে বৃদ্ধি পায়। +4. মাইনিং এর মধ্যে ডেটাসেটের র‍্যান্ডম স্লাইস গ্রহণ করা এবং সেগুলোকে একসাথে হ্যাস করা জড়িত। আপনার প্রয়োজনীয় ডেটাসেটের নির্দিষ্ট অংশগুলো পুনরায় তৈরি করতে ক্যাশে ব্যবহার করে কম মেমরির সাথে যাচাইকরণ করা যেতে পারে, তাই আপনাকে কেবল ক্যাশে সংরক্ষণ করতে হবে। + +বৃহৎ ডেটাসেটটি প্রতি 30000 ব্লকে একবার আপডেট করা হয়, তাই একজন মাইনারের প্রচেষ্টার বেশিরভাগই হবে ডেটাসেট পড়া, এতে পরিবর্তন করা নয়। + +## সংজ্ঞা {#definitions} + +আমরা নিম্নলিখিত সংজ্ঞাগুলো ব্যবহার করি: + +``` +WORD_BYTES = 4 # শব্দে বাইট +DATASET_BYTES_INIT = 2**30 # জেনেসিসে ডেটাসেটে বাইট +DATASET_BYTES_GROWTH = 2**23 # প্রতি ইপকে ডেটাসেট বৃদ্ধি +CACHE_BYTES_INIT = 2**24 # জেনেসিসে ক্যাশে বাইট +CACHE_BYTES_GROWTH = 2**17 # প্রতি ইপকে ক্যাশে বৃদ্ধি +CACHE_MULTIPLIER=1024 # ক্যাশের সাপেক্ষে DAG-এর আকার +EPOCH_LENGTH = 30000 # প্রতি ইপকে ব্লক +MIX_BYTES = 128 # মিক্সের প্রস্থ +HASH_BYTES = 64 # বাইটে হ্যাশের দৈর্ঘ্য +DATASET_PARENTS = 256 # প্রতিটি ডেটাসেট উপাদানের প্যারেন্টের সংখ্যা +CACHE_ROUNDS = 3 # ক্যাশে উৎপাদনে রাউন্ডের সংখ্যা +ACCESSES = 64 # হ্যাশিমোটো লুপে অ্যাক্সেসের সংখ্যা +``` + +### 'SHA3'-এর ব্যবহার {#sha3} + +Ethereum-এর ডেভেলপমেন্ট SHA3 স্ট্যান্ডার্ডের ডেভেলপমেন্টের সাথে একই সময়ে হয়েছিল, এবং +স্ট্যান্ডার্ড প্রক্রিয়াটি চূড়ান্ত হ্যাস অ্যালগরিদমের প্যাডিংয়ে একটি দেরীতে পরিবর্তন করেছিল, যাতে Ethereum-এর +"sha3_256" এবং "sha3_512" হ্যাসগুলো স্ট্যান্ডার্ড sha3 হ্যাস নয়, বরং একটি ভ্যারিয়েন্ট যা প্রায়শই +অন্যান্য প্রসঙ্গে "Keccak-256" এবং "Keccak-512" হিসাবে উল্লেখ করা হয়। আলোচনা দেখুন, যেমন, [এখানে](https://eips.ethereum.org/EIPS/eip-1803), [এখানে](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), অথবা [এখানে](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057)। + +অনুগ্রহ করে মনে রাখবেন যে নীচের অ্যালগরিদমের বিবরণে "sha3" হ্যাসগুলো উল্লেখ করা হয়েছে। + +## প্যারামিটার {#parameters} + +Ethash-এর ক্যাশে এবং ডেটাসেটের জন্য প্যারামিটারগুলো ব্লক নম্বরের উপর নির্ভর করে। ক্যাশে সাইজ এবং ডেটাসেট সাইজ উভয়ই রৈখিকভাবে বৃদ্ধি পায়; তবে, আমরা চক্রীয় আচরণের দিকে পরিচালিত করতে পারে এমন আকস্মিক নিয়মিততার ঝুঁকি কমাতে রৈখিকভাবে ক্রমবর্ধমান থ্রেশহোল্ডের নীচে সর্বোচ্চ প্রাইম সংখ্যাটি নিই। + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +ডেটাসেট এবং ক্যাশে সাইজের মানের সারণী পরিশিষ্টে সরবরাহ করা হয়েছে। + +## ক্যাশে জেনারেশন {#cache-generation} + +এখন, আমরা ক্যাশে তৈরির জন্য ফাংশনটি নির্দিষ্ট করছি: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # ক্রমানুসারে প্রাথমিক ডেটাসেট তৈরি করুন + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # randmemohash এর একটি লো-রাউন্ড সংস্করণ ব্যবহার করুন + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +ক্যাশে উৎপাদন প্রক্রিয়ার মধ্যে প্রথমে ক্রমানুসারে 32 MB মেমরি পূরণ করা হয়, তারপর [_স্ট্রিক্ট মেমরি হার্ড হ্যাশিং ফাংশন_ (2014)](http://www.hashcash.org/papers/memohash.pdf) থেকে Sergio Demian Lerner-এর _RandMemoHash_ অ্যালগরিদমের দুটি পাস করা হয়। আউটপুটটি হল 524288টি 64-বাইট মানের একটি সেট। + +## ডেটা এগ্রিগেশন ফাংশন {#date-aggregation-function} + +আমরা কিছু ক্ষেত্রে XOR-এর একটি নন-অ্যাসোসিয়েটিভ বিকল্প হিসাবে [FNV হ্যাস](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) দ্বারা অনুপ্রাণিত একটি অ্যালগরিদম ব্যবহার করি। নোট করুন যে আমরা প্রাইমটিকে সম্পূর্ণ 32-বিট ইনপুটের সাথে গুণ করি, FNV-1 স্পেকের বিপরীতে যা প্রাইমটিকে এক বাইট (অক্টেট) দিয়ে পর্যায়ক্রমে গুণ করে। + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +অনুগ্রহ করে মনে রাখবেন, যদিও ইয়েলো পেপারে fnv কে v1\*(FNV_PRIME ^ v2) হিসাবে নির্দিষ্ট করা হয়েছে, সমস্ত বর্তমান ইমপ্লিমেন্টেশন ধারাবাহিকভাবে উপরের সংজ্ঞাটি ব্যবহার করে। + +## সম্পূর্ণ ডেটাসেট গণনা {#full-dataset-calculation} + +সম্পূর্ণ 1 GB ডেটাসেটের প্রতিটি 64-বাইট আইটেম নিম্নরূপ গণনা করা হয়: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # মিক্স শুরু করুন + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # i-এর উপর ভিত্তি করে অনেক র‍্যান্ডম ক্যাশে নোডের সাথে এটিকে fnv করুন + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +মূলত, আমরা 256টি সিউডোর‍্যান্ডমলি নির্বাচিত ক্যাশে নোড থেকে ডেটা একত্রিত করি, এবং ডেটাসেট নোড গণনা করার জন্য এটিকে হ্যাস করি। সম্পূর্ণ ডেটাসেটটি তখন নিম্নলিখিতভাবে তৈরি করা হয়: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## প্রধান লুপ {#main-loop} + +এখন, আমরা প্রধান "হ্যাশিমোটো"-সদৃশ লুপটি নির্দিষ্ট করছি, যেখানে আমরা একটি নির্দিষ্ট হেডার এবং ননসের জন্য আমাদের চূড়ান্ত মান তৈরি করার জন্য সম্পূর্ণ ডেটাসেট থেকে ডেটা একত্রিত করি। নীচের কোডে, `header` একটি _ট্রাঙ্কেটেড_ ব্লক হেডারের RLP উপস্থাপনার SHA3-256 _হ্যাস_ প্রতিনিধিত্ব করে, অর্থাৎ, **mixHash** এবং **nonce** ক্ষেত্রগুলো বাদ দিয়ে একটি হেডার। `nonce` হলো বিগ-এন্ডিয়ান অর্ডারে একটি 64 বিট আনসাইন্ড ইন্টিজারের আট বাইট। সুতরাং `nonce[::-1]` হল সেই মানের আট-বাইট লিটল-এন্ডিয়ান উপস্থাপনা: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # হেডার+ননসকে একটি 64 বাইট সীডে একত্রিত করুন + s = sha3_512(header + nonce[::-1]) + # রেপ্লিকেটেড s দিয়ে মিক্স শুরু করুন + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # র‍্যান্ডম ডেটাসেট নোডগুলোতে মিক্স করুন + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # মিক্স কম্প্রেস করুন + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +মূলত, আমরা একটি 128 বাইট চওড়া "মিক্স" বজায় রাখি, এবং বারবার ক্রমানুসারে সম্পূর্ণ ডেটাসেট থেকে 128 বাইট আনি এবং মিক্সের সাথে একত্রিত করার জন্য `fnv` ফাংশন ব্যবহার করি। 128 বাইটের সিকুয়েন্সিয়াল অ্যাক্সেস ব্যবহার করা হয় যাতে অ্যালগরিদমের প্রতিটি রাউন্ড সর্বদা RAM থেকে একটি সম্পূর্ণ পেজ নিয়ে আসে, যা ট্রান্সলেশন লুকাসাইড বাফার মিস কমিয়ে দেয় যা ASIC তাত্ত্বিকভাবে এড়াতে সক্ষম হবে। + +যদি এই অ্যালগরিদমের আউটপুট কাঙ্ক্ষিত লক্ষ্যের নিচে হয়, তবে ননসটি বৈধ। নোট করুন যে শেষে `sha3_256`-এর অতিরিক্ত প্রয়োগ নিশ্চিত করে যে একটি মধ্যবর্তী ননস বিদ্যমান যা প্রমাণ করতে প্রদান করা যেতে পারে যে অন্তত অল্প পরিমাণে কাজ করা হয়েছে; এই দ্রুত বাইরের PoW যাচাইকরণ অ্যান্টি-DDoS উদ্দেশ্যে ব্যবহার করা যেতে পারে। এটি পরিসংখ্যানগত নিশ্চয়তা প্রদান করতেও কাজ করে যে ফলাফলটি একটি নিরপেক্ষ, 256-বিট সংখ্যা। + +## মাইনিং {#mining} + +মাইনিং অ্যালগরিদমটি নিম্নরূপ সংজ্ঞায়িত করা হয়েছে: + +```python +def mine(full_size, dataset, header, difficulty): + # একই ডিজিটে হ্যাশের সাথে তুলনা করার জন্য টার্গেটকে জিরো-প্যাড করুন + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## সীড হ্যাস সংজ্ঞায়িত করা {#seed-hash} + +একটি প্রদত্ত ব্লকের উপরে মাইন করার জন্য ব্যবহৃত সীড হ্যাস গণনা করার জন্য, আমরা নিম্নলিখিত অ্যালগরিদম ব্যবহার করি: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +নোট করুন যে মসৃণ মাইনিং এবং যাচাইকরণের জন্য, আমরা একটি পৃথক থ্রেডে ভবিষ্যতের সীডহ্যাস এবং ডেটাসেটগুলো আগে থেকে গণনা করার সুপারিশ করি। + +## আরও পড়ুন {#further-reading} + +_এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন যা আপনাকে সাহায্য করেছে? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যোগ করুন!_ + +## পরিশিষ্ট {#appendix} + +আপনি যদি উপরের পাইথন স্পেকটিকে কোড হিসাবে চালাতে আগ্রহী হন তবে নিম্নলিখিত কোডটি আগে যুক্ত করা উচিত। + +```python +import sha3, copy + +# লিটল এন্ডিয়ান বিট অর্ডারিং ধরে নেয় (Intel আর্কিটেকচারের মতো) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# sha3 হ্যাস ফাংশন, 64 বাইট আউটপুট দেয় +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### ডেটা সাইজ {#data-sizes} + +নিম্নলিখিত লুকআপ টেবিলগুলো ডেটা সাইজ এবং ক্যাশে সাইজের প্রায় 2048টি সারণীবদ্ধ ইপক প্রদান করে। + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..3ad27677755 --- /dev/null +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "মাইনিং অ্যালগরিদম সমূহ" +description: "ইথেরিয়াম মাইনিং-এর জন্য ব্যবহৃত অ্যালগরিদমগুলির একটি বিশদ বিবরণ।" +lang: bn +--- + + + + + +প্রুফ-অফ-ওয়ার্ক আর ইথেরিয়ামের কনসেন্সাস মেকানিজমের ভিত্তি নয়, যার অর্থ মাইনিং বন্ধ করে দেওয়া হয়েছে। পরিবর্তে, ইথেরিয়াম ভ্যালিডেটরদের দ্বারা সুরক্ষিত যারা ETH স্টেক করে। আপনি আজই আপনার ETH স্টেকিং শুরু করতে পারেন। The Merge, প্রুফ-অফ-স্টেক, এবং স্টেকিং সম্পর্কে আরও পড়ুন। এই পৃষ্ঠাটি শুধুমাত্র ঐতিহাসিক আগ্রহের জন্য। + + + + +ইথেরিয়াম মাইনিং Ethash নামে পরিচিত একটি অ্যালগরিদম ব্যবহার করত। অ্যালগরিদমটির মূল ধারণাটি হলো, একজন মাইনার ব্রুট ফোর্স কম্পিউটেশন ব্যবহার করে একটি নন্স ইনপুট খুঁজে বের করার চেষ্টা করে যাতে ফলস্বরূপ হ্যাসটি গণনা করা কঠিনতা দ্বারা নির্ধারিত একটি থ্রেশহোল্ডের চেয়ে ছোট হয়। এই কঠিনতার স্তরটি গতিশীলভাবে সামঞ্জস্য করা যেতে পারে, যা একটি নিয়মিত ব্যবধানে ব্লক উৎপাদন হতে দেয়। + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি আরও ভালোভাবে বোঝার জন্য, আমরা আপনাকে প্রথমে [প্রুফ-অফ-ওয়ার্ক কনসেন্সাস](/developers/docs/consensus-mechanisms/pow) এবং [মাইনিং](/developers/docs/consensus-mechanisms/pow/mining) সম্পর্কে পড়ে নেওয়ার পরামর্শ দিচ্ছি। + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto ছিল ইথেরিয়াম মাইনিং-এর জন্য একটি পূর্বসূরী গবেষণা অ্যালগরিদম যা Ethash দ্বারা প্রতিস্থাপিত হয়েছিল। এটি দুটি ভিন্ন অ্যালগরিদমের সংমিশ্রণ ছিল: Dagger এবং Hashimoto। এটি শুধুমাত্র একটি গবেষণা বাস্তবায়ন ছিল এবং ইথেরিয়াম মেইননেট চালু হওয়ার সময় Ethash দ্বারা প্রতিস্থাপিত হয়েছিল। + +[Dagger](http://www.hashcash.org/papers/dagger.html) একটি [ডিরেক্টেড অ্যাসাইক্লিক গ্রাফ](https://en.wikipedia.org/wiki/Directed_acyclic_graph) তৈরি করে, যার র‍্যান্ডম স্লাইসগুলিকে একসাথে হ্যাস করা হয়। মূল নীতিটি হলো প্রতিটি নন্সের জন্য একটি বড় মোট ডেটা ট্রি-এর শুধুমাত্র একটি ছোট অংশ প্রয়োজন। প্রতিটি নন্সের জন্য সাবট্রি পুনর্গণনা করা মাইনিং-এর জন্য বাধা সৃষ্টিকারী - তাই ট্রি সংরক্ষণ করার প্রয়োজন - কিন্তু একটি একক নন্সের ভেরিফিকেশনের জন্য ঠিক আছে। Dagger-কে Scrypt-এর মতো বিদ্যমান অ্যালগরিদমগুলির একটি বিকল্প হিসাবে ডিজাইন করা হয়েছিল, যা মেমরি-হার্ড কিন্তু যখন তাদের মেমরি-হার্ডনেস প্রকৃত সুরক্ষিত স্তরে বৃদ্ধি পায় তখন যাচাই করা কঠিন। তবে, Dagger শেয়ারড মেমরি হার্ডওয়্যার অ্যাক্সিলারেশনের জন্য ঝুঁকিপূর্ণ ছিল এবং গবেষণার অন্যান্য পথের জন্য এটি বাতিল করা হয়েছিল। + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) এমন একটি অ্যালগরিদম যা I/O বাউন্ড (অর্থাৎ, মাইনিং প্রক্রিয়ায় মেমরি রিডগুলি হলো সীমাবদ্ধকারী ফ্যাক্টর) হওয়ার মাধ্যমে ASIC-প্রতিরোধ ক্ষমতা যোগ করে। তত্ত্বটি হলো কম্পিউটেশনের চেয়ে RAM বেশি উপলব্ধ; বিভিন্ন ব্যবহারের ক্ষেত্রে RAM অপ্টিমাইজ করার জন্য ইতিমধ্যে বিলিয়ন ডলার মূল্যের গবেষণা করা হয়েছে, যা প্রায়শই র‍্যান্ডম অ্যাক্সেস প্যাটার্ন জড়িত থাকে (তাই “র‍্যান্ডম অ্যাক্সেস মেমরি”)। ফলস্বরূপ, বিদ্যমান RAM সম্ভবত অ্যালগরিদম মূল্যায়নের জন্য সর্বোত্তমের বেশ কাছাকাছি। Hashimoto ডেটার উৎস হিসাবে ব্লকচেইন ব্যবহার করে, যা একই সাথে উপরের (1) এবং (3) পূরণ করে। + +Dagger-Hashimoto, Dagger এবং Hashimoto অ্যালগরিদমের সংশোধিত সংস্করণ ব্যবহার করেছে। Dagger Hashimoto এবং Hashimoto-এর মধ্যে পার্থক্য হলো, ডেটার উৎস হিসাবে ব্লকচেইন ব্যবহার করার পরিবর্তে, Dagger Hashimoto একটি কাস্টম-জেনারেটেড ডেটা সেট ব্যবহার করে, যা প্রতি N ব্লকে ব্লক ডেটার উপর ভিত্তি করে আপডেট হয়। ডেটা সেটটি Dagger অ্যালগরিদম ব্যবহার করে তৈরি করা হয়, যা লাইট ক্লায়েন্ট ভেরিফিকেশন অ্যালগরিদমের জন্য প্রতিটি নন্সের জন্য নির্দিষ্ট একটি সাবসেট দক্ষতার সাথে গণনা করার অনুমতি দেয়। Dagger Hashimoto এবং Dagger-এর মধ্যে পার্থক্য হলো, আসল Dagger-এর থেকে ভিন্ন, ব্লক কোয়েরি করার জন্য ব্যবহৃত ডেটাসেটটি আধা-স্থায়ী, যা শুধুমাত্র মাঝে মাঝে বিরতিতে (যেমন, প্রতি সপ্তাহে একবার) আপডেট করা হয়। এর মানে হলো যে ডেটাসেট তৈরি করার প্রচেষ্টার অংশ প্রায় শূন্যের কাছাকাছি, তাই শেয়ার্ড মেমরি স্পিডআপ সংক্রান্ত সার্জিও লার্নারের যুক্তিগুলি নগণ্য হয়ে যায়। + +[Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto)-এর উপর আরও তথ্য। + +## Ethash {#ethash} + +Ethash ছিল সেই মাইনিং অ্যালগরিদম যা এখন অপ্রচলিত প্রুফ-অফ-ওয়ার্ক আর্কিটেকচারের অধীনে আসল ইথেরিয়াম মেইননেটে ব্যবহৃত হয়েছিল। অ্যালগরিদমটি উল্লেখযোগ্যভাবে আপডেট হওয়ার পরে Dagger-Hashimoto-এর একটি নির্দিষ্ট সংস্করণকে কার্যকরভাবে Ethash নামটি দেওয়া হয়েছিল, যদিও এটি তার পূর্বসূরীর মৌলিক নীতিগুলি উত্তরাধিকার সূত্রে পেয়েছিল। ইথেরিয়াম মেইননেট শুধুমাত্র Ethash ব্যবহার করেছে - Dagger Hashimoto ছিল মাইনিং অ্যালগরিদমের একটি R&D সংস্করণ যা ইথেরিয়াম মেইননেটে মাইনিং শুরু হওয়ার আগে প্রতিস্থাপিত হয়েছিল। + +[Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash)-এর উপর আরও তথ্য। + +## আরও পড়ুন {#further-reading} + +_এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন যা আপনাকে সাহায্য করেছে? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যোগ করুন!_ diff --git a/public/content/translations/bn/developers/docs/dapps/index.md b/public/content/translations/bn/developers/docs/dapps/index.md new file mode 100644 index 00000000000..1c94216390a --- /dev/null +++ b/public/content/translations/bn/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "ডিএ্যাপস এর প্রযুক্তিগত পরিচিতি" +description: +lang: bn +--- + +একটি ডিসেন্ট্রালাইজড এপ্লিকেশন (ডিএ্যাপ) হল একটি বিকেন্দ্রীভূত নেটওয়ার্কে নির্মিত একটি এপ্লিকেশন যা একটি [স্মার্ট কন্ট্র্যাক্ট](/developers/docs/smart-contracts/) এবং একটি ফ্রন্টএন্ড ইউজার ইন্টারফেসকে একত্রিত করে। Ethereum-এ, স্মার্ট কন্ট্র্যাক্টগুলি অ্যাক্সেসযোগ্য এবং স্বচ্ছ – যেমন ওপেন APIs – তাই আপনার ডিএ্যাপ-এ এমন একটি স্মার্ট কন্ট্র্যাক্টও অন্তর্ভুক্ত থাকতে পারে যা অন্য কেউ লিখেছে। + +## পূর্বশর্ত {#prerequisites} + +ডিএ্যাপস সম্পর্কে শেখার আগে, আপনার [ব্লকচেইনের মূল বিষয়গুলো](/developers/docs/intro-to-ethereum/) কভার করা উচিত এবং Ethereum নেটওয়ার্ক ও এটি কীভাবে বিকেন্দ্রীভূত হয় সে সম্পর্কে পড়া উচিত। + +## একটি ডিএ্যাপ-এর সংজ্ঞা {#definition-of-a-dapp} + +একটি ডিএ্যাপ-এর ব্যাকএন্ড কোড একটি বিকেন্দ্রীভূত পিয়ার-টু-পিয়ার নেটওয়ার্কে চলে। একটি অ্যাপের সাথে এর তুলনা করুন যেখানে ব্যাকএন্ড কোড কেন্দ্রীয় সার্ভারে চলছে। + +একটি ডিএ্যাপ-এর ফ্রন্টএন্ড কোড এবং ইউজার ইন্টারফেস যেকোনো ভাষায় লেখা যেতে পারে (ঠিক একটি অ্যাপের মতো) যা এর ব্যাকএন্ডে কল করার জন্য ব্যবহৃত হয়। অধিকন্তু, এর ফ্রন্টএন্ড [IPFS](https://ipfs.io/)-এর মতো বিকেন্দ্রীভূত স্টোরেজে হোস্ট করা যেতে পারে। + +- **বিকেন্দ্রীভূত** - ডিএ্যাপস Ethereum-এ কাজ করে, যা একটি উন্মুক্ত পাবলিক বিকেন্দ্রীভূত প্ল্যাটফর্ম যেখানে কোনো ব্যক্তি বা গোষ্ঠীর নিয়ন্ত্রণ নেই। +- **ডিটারমিনিস্টিক** - ডিএ্যাপস যে পরিবেশে চালানো হোক না কেন, একই ফাংশন সম্পাদন করে। +- **ট্যুরিং কমপ্লিট** - প্রয়োজনীয় রিসোর্স দেওয়া হলে ডিএ্যাপস যেকোনো কাজ সম্পাদন করতে পারে। +- **আইসোলেটেড** - ডিএ্যাপস ইথিরিয়াম ভার্চুয়াল মেশিন নামে পরিচিত একটি ভার্চুয়াল পরিবেশে কার্যকর করা হয়, যাতে স্মার্ট কন্ট্র্যাক্টে কোনো বাগ থাকলেও এটি ব্লকচেইন নেটওয়ার্কের স্বাভাবিক কার্যকারিতায় বাধা দেবে না। + +### স্মার্ট কন্ট্র্যাক্ট প্রসঙ্গে {#on-smart-contracts} + +ডিএ্যাপস এর পরিচয় দিতে হলে, আমাদের স্মার্ট কন্ট্র্যাক্টগুলির পরিচয় দিতে হবে – যা ভাল কোনও শব্দের অভাবে একটি ডিএ্যাপ-এর ব্যাকএন্ড। বিস্তারিত বিবরণের জন্য, আমাদের [স্মার্ট কন্ট্র্যাক্ট](/developers/docs/smart-contracts/) সম্পর্কিত বিভাগে যান। + +একটি স্মার্ট কন্ট্র্যাক্ট হল কোড যা Ethereum ব্লকচেইনে থাকে এবং ঠিক প্রোগ্রাম অনুযায়ী চলে। একবার স্মার্ট কন্ট্র্যাক্টগুলি নেটওয়ার্কে ডিপ্লয় করা হলে আপনি সেগুলি পরিবর্তন করতে পারবেন না। ডিএ্যাপস বিকেন্দ্রীভূত হতে পারে কারণ সেগুলি কন্ট্র্যাক্টে লেখা যুক্তি দ্বারা নিয়ন্ত্রিত হয়, কোনো ব্যক্তি বা কোম্পানির দ্বারা নয়। এর মানে হল আপনাকে আপনার কন্ট্র্যাক্টগুলি খুব সাবধানে ডিজাইন করতে হবে এবং সেগুলি পুঙ্খানুপুঙ্খভাবে পরীক্ষা করতে হবে। + +## ডিএ্যাপ ডেভেলপমেন্টের সুবিধা {#benefits-of-dapp-development} + +- **জিরো ডাউনটাইম** – একবার ব্লকচেইনে স্মার্ট কন্ট্র্যাক্টটি ডিপ্লয় করা হলে, পুরো নেটওয়ার্কটি সর্বদা কন্ট্র্যাক্টের সাথে ইন্টারঅ্যাক্ট করতে চাওয়া ক্লায়েন্টদের পরিষেবা দিতে সক্ষম হবে। অতএব, ক্ষতিকারক অ্যাক্টররা ব্যক্তিগত ডিএ্যাপস-কে লক্ষ্য করে ডিনায়াল-অফ-সার্ভিস অ্যাটাক চালাতে পারে না। +- **গোপনীয়তা** – একটি ডিএ্যাপ ডিপ্লয় বা তার সাথে ইন্টারঅ্যাক্ট করার জন্য আপনাকে বাস্তব-জগতের পরিচয় প্রদান করতে হবে না। +- **সেন্সরশিপ প্রতিরোধ** – নেটওয়ার্কের কোনো একক সত্তা ব্যবহারকারীদের লেনদেন জমা দেওয়া, ডিএ্যাপস ডিপ্লয় করা, বা ব্লকচেইন থেকে ডেটা পড়া থেকে ব্লক করতে পারে না। +- **সম্পূর্ণ ডেটা ইন্টিগ্রিটি** – ব্লকচেইনে সংরক্ষিত ডেটা অপরিবর্তনীয় এবং অকাট্য, ক্রিপ্টোগ্রাফিক প্রিমিটিভের জন্য ধন্যবাদ। ক্ষতিকারক অ্যাক্টররা লেনদেন বা অন্যান্য ডেটা যা ইতিমধ্যে পাবলিক করা হয়েছে তা জালিয়াতি করতে পারে না। +- **ট্রাস্টলেস কম্পিউটেশন/যাচাইযোগ্য আচরণ** – স্মার্ট কন্ট্র্যাক্ট বিশ্লেষণ করা যেতে পারে এবং একটি কেন্দ্রীয় কর্তৃপক্ষকে বিশ্বাস করার প্রয়োজন ছাড়াই অনুমানযোগ্য উপায়ে কার্যকর করার গ্যারান্টি দেওয়া হয়। প্রচলিত মডেলগুলিতে এটি সত্য নয়; উদাহরণস্বরূপ, যখন আমরা অনলাইন ব্যাংকিং সিস্টেম ব্যবহার করি, তখন আমাদের বিশ্বাস করতে হবে যে আর্থিক প্রতিষ্ঠানগুলি আমাদের আর্থিক ডেটার অপব্যবহার করবে না, রেকর্ডে গরমিল করবে না, বা হ্যাক হবে না। + +## ডিএ্যাপ ডেভেলপমেন্টের অসুবিধা {#drawbacks-of-dapp-development} + +- **রক্ষণাবেক্ষণ** – ডিএ্যাপস রক্ষণাবেক্ষণ করা কঠিন হতে পারে কারণ ব্লকচেইনে প্রকাশিত কোড এবং ডেটা পরিবর্তন করা কঠিন। ডেভেলপারদের জন্য তাদের ডিএ্যাপস-এ (বা একটি ডিএ্যাপ দ্বারা সংরক্ষিত অন্তর্নিহিত ডেটা) আপডেট করা কঠিন, একবার সেগুলি ডিপ্লয় করা হলে, এমনকি যদি পুরনো সংস্করণে বাগ বা নিরাপত্তা ঝুঁকি চিহ্নিত করা হয়। +- **পারফরম্যান্স ওভারহেড** – একটি বিশাল পারফরম্যান্স ওভারহেড আছে, এবং স্কেলিং সত্যিই কঠিন। Ethereum যে স্তরের নিরাপত্তা, অখণ্ডতা, স্বচ্ছতা এবং নির্ভরযোগ্যতা অর্জনের আকাঙ্ক্ষা করে, তা অর্জনের জন্য প্রতিটি নোড প্রতিটি লেনদেন চালায় এবং সংরক্ষণ করে। এর উপরে, প্রুফ-অফ-স্টেক কনসেন্সাস-এও সময় লাগে। +- **নেটওয়ার্ক কনজেশন** – যখন একটি ডিএ্যাপ খুব বেশি কম্পিউটেশনাল রিসোর্স ব্যবহার করে, তখন পুরো নেটওয়ার্ক ব্যাক আপ হয়ে যায়। বর্তমানে, নেটওয়ার্কটি প্রতি সেকেন্ডে প্রায় 10-15টি লেনদেন প্রক্রিয়া করতে পারে; যদি এর চেয়ে দ্রুত লেনদেন পাঠানো হয়, তাহলে অপরিশোধিত লেনদেনের পুল দ্রুত ফুলে উঠতে পারে। +- **ব্যবহারকারীর অভিজ্ঞতা** – ব্যবহারকারী-বান্ধব অভিজ্ঞতা তৈরি করা কঠিন হতে পারে কারণ গড় শেষ-ব্যবহারকারী একটি সত্যিকারের নিরাপদ ফ্যাশনে ব্লকচেইনের সাথে ইন্টারঅ্যাক্ট করার জন্য প্রয়োজনীয় একটি টুল স্ট্যাক সেট আপ করা খুব কঠিন মনে করতে পারে। +- **কেন্দ্রীকরণ** – Ethereum-এর বেস লেয়ারের উপরে নির্মিত ব্যবহারকারী-বান্ধব এবং ডেভেলপার-বান্ধব সমাধানগুলি শেষ পর্যন্ত কেন্দ্রীয় পরিষেবার মতো দেখতে হতে পারে। উদাহরণস্বরূপ, এই ধরনের পরিষেবাগুলি সার্ভার-সাইডে কী বা অন্যান্য সংবেদনশীল তথ্য সংরক্ষণ করতে পারে, একটি কেন্দ্রীয় সার্ভার ব্যবহার করে একটি ফ্রন্টএন্ড পরিবেশন করতে পারে, বা ব্লকচেইনে লেখার আগে একটি কেন্দ্রীয় সার্ভারে গুরুত্বপূর্ণ ব্যবসায়িক যুক্তি চালাতে পারে। কেন্দ্রীকরণ ঐতিহ্যগত মডেলের উপর ব্লকচেইনের অনেক (যদি সব না হয়) সুবিধা দূর করে। + +## আপনি কি দেখে শিখতে বেশি পছন্দ করেন? {#visual-learner} + + + +## ডিএ্যাপস তৈরির জন্য টুলস {#dapp-tools} + +**Scaffold-ETH _- আপনার স্মার্ট কন্ট্র্যাক্টের সাথে খাপ খাইয়ে নেওয়া একটি ফ্রন্টএন্ড ব্যবহার করে দ্রুত Solidity নিয়ে পরীক্ষা করুন।_** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [উদাহরণ ডিএ্যাপ](https://punkwallet.io/) + +**Create Eth App _- একটি কমান্ড দিয়ে Ethereum-চালিত অ্যাপ তৈরি করুন।_** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- একটি [ABI](/glossary/#abi) থেকে ডিএ্যাপ ফ্রন্টএন্ড তৈরি করার জন্য FOSS টুল।_** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _- Ethereum ডেভেলপারদের জন্য তাদের নোড পরীক্ষা করার জন্য এবং ব্রাউজার থেকে RPC কল রচনা এবং ডিবাগ করার জন্য FOSS টুল।_** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- প্রতিটি ভাষায় SDK, স্মার্ট কন্ট্র্যাক্ট, টুলস, এবং web3 ডেভেলপমেন্টের জন্য পরিকাঠামো।_** + +- [হোমপেজ](https://thirdweb.com/) +- [নথিপত্র](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- স্মার্ট কন্ট্র্যাক্ট ডিপ্লয় করতে, ক্রেডিট-কার্ড এবং ক্রস চেইন পেমেন্ট সক্ষম করতে, এবং NFTs তৈরি, বিতরণ, বিক্রি, সঞ্চয় এবং সম্পাদনা করতে API ব্যবহার করার জন্য এন্টারপ্রাইজ-গ্রেড web3 ডেভেলপমেন্ট প্ল্যাটফর্ম।_** + +- [crossmint.com](https://www.crossmint.com) +- [নথিপত্র](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## আরও পড়ুন {#further-reading} + +- [ডিএ্যাপস এক্সপ্লোর করুন](/apps) +- [একটি ওয়েব 3.0 অ্যাপ্লিকেশনের আর্কিটেকচার](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _প্রীতি কাসিরেড্ডি_ +- [ডিসেন্ট্রালাইজড এপ্লিকেশনগুলির জন্য একটি 2021 সালের নির্দেশিকা](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [ডিসেন্ট্রালাইজড এপ্লিকেশন কী?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [জনপ্রিয় ডিএ্যাপস](https://www.alchemy.com/dapps) - _Alchemy_ + +_এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন যা আপনাকে সাহায্য করেছে? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যোগ করুন!_ + +## সম্পর্কিত বিষয় {#related-topics} + +- [Ethereum স্ট্যাকের পরিচিতি](/developers/docs/ethereum-stack/) +- [ডেভেলপমেন্ট ফ্রেমওয়ার্ক](/developers/docs/frameworks/) diff --git a/public/content/translations/bn/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/bn/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..87b6e70e22b --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "ব্লক এক্সপ্লোরার" +description: "ব্লক এক্সপ্লোরারের একটি ভূমিকা, ব্লকচেইন ডেটার জগতে আপনার পোর্টাল, যেখানে আপনি লেনদেন, অ্যাকাউন্ট, কন্ট্র্যাক্ট এবং আরও অনেক কিছু সম্পর্কে তথ্য জানতে পারেন।" +lang: bn +sidebarDepth: 3 +--- + +ব্লক এক্সপ্লোরার হল ইথেরিয়াম-এর ডেটাতে আপনার পোর্টাল। ব্লক, লেনদেন, ভ্যালিডেটর, অ্যাকাউন্ট এবং অন্যান্য অনচেইন কার্যকলাপের রিয়েল-টাইম ডেটা দেখতে আপনি সেগুলি ব্যবহার করতে পারেন। + +## পূর্বশর্ত {#prerequisites} + +আপনার ইথেরিয়ামের প্রাথমিক ধারণাগুলি বোঝা উচিত যাতে একটি ব্লক এক্সপ্লোরার আপনাকে যে ডেটা দেয় তা আপনি বুঝতে পারেন। [ইথেরিয়ামের একটি ভূমিকা](/developers/docs/intro-to-ethereum/) দিয়ে শুরু করুন। + +## পরিষেবা {#services} + +- [Etherscan](https://etherscan.io/) -_চীনা, কোরিয়ান, রাশিয়ান এবং জাপানি ভাষায়ও উপলব্ধ_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_স্প্যানিশ, ফরাসি, ইতালীয়, ডাচ, পর্তুগিজ, রাশিয়ান, চীনা এবং ফারসি ভাষায়ও উপলব্ধ_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [DexGuru ব্লক এক্সপ্লোরার](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_চীনা, স্প্যানিশ, ফরাসি, তুর্কি, রাশিয়ান, কোরিয়ান এবং ভিয়েতনামী ভাষায়ও উপলব্ধ_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## ওপেন সোর্স টুলস {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## ডেটা {#data} + +ইথেরিয়াম ডিজাইন অনুযায়ী স্বচ্ছ তাই সবকিছু যাচাইযোগ্য। ব্লক এক্সপ্লোরার এই তথ্য পাওয়ার জন্য একটি ইন্টারফেস প্রদান করে। এবং আপনার যদি সেই ডেটার প্রয়োজন হয়, তবে এটি মূল ইথেরিয়াম নেটওয়ার্ক এবং টেস্টনেট উভয়ের জন্যই। ডেটা এক্সিকিউশন ডেটা এবং কনসেন্সাস ডেটাতে বিভক্ত। এক্সিকিউশন ডেটা একটি নির্দিষ্ট ব্লকে সম্পাদিত লেনদেনকে বোঝায়। কনসেন্সাস ডেটা বলতে ব্লকগুলি এবং যে ভ্যালিডেটররা সেগুলির প্রস্তাব দিয়েছিল তাদের বোঝায়। + +এখানে একটি ব্লক এক্সপ্লোরার থেকে আপনি যে ধরনের ডেটা পেতে পারেন তার একটি সারসংক্ষেপ রয়েছে। + +### এক্সিকিউশন ডেটা {#execution-data} + +প্রতি 12 সেকেন্ডে ইথেরিয়ামে নতুন ব্লক যুক্ত করা হয় (যদি না কোনো ব্লক প্রোপোজার তার পালা মিস করে), তাই ব্লক এক্সপ্লোরারগুলিতে প্রায়-ধ্রুবক ডেটার একটি প্রবাহ যুক্ত হয়। ব্লকগুলিতে অনেক গুরুত্বপূর্ণ ডেটা রয়েছে যা আপনার কাছে দরকারী মনে হতে পারে: + +**স্ট্যান্ডার্ড ডেটা** + +- ব্লক হাইট - বর্তমান ব্লক তৈরির সময় ব্লক নম্বর এবং ব্লকচেইনের দৈর্ঘ্য (ব্লকে)। +- টাইমস্ট্যাম্প - যে সময়ে একটি ব্লকের প্রস্তাব করা হয়েছিল। +- লেনদেন - ব্লকের মধ্যে অন্তর্ভুক্ত লেনদেনের সংখ্যা। +- ফি প্রাপক - যে অ্যাড্রেস লেনদেন থেকে গ্যাস ফি টিপস পেয়েছে। +- ব্লক রিওয়ার্ড - যে ভ্যালিডেটর ব্লকটির প্রস্তাব করেছে তাকে পুরস্কৃত করা ETH-এর পরিমাণ। +- সাইজ - ব্লকের মধ্যে ডেটার সাইজ (বাইটে পরিমাপ করা হয়)। +- ব্যবহৃত গ্যাস - ব্লকের লেনদেন দ্বারা ব্যবহৃত গ্যাসের মোট একক। +- গ্যাস লিমিট - ব্লকের লেনদেন দ্বারা সেট করা মোট গ্যাস লিমিট। +- গ্যাস প্রতি বেস ফি - একটি ব্লকে একটি লেনদেন অন্তর্ভুক্ত করার জন্য প্রয়োজনীয় সর্বনিম্ন গুণক। +- বার্নড ফি - ব্লকে কত ETH বার্ন করা হয়। +- অতিরিক্ত ডেটা - বিল্ডার ব্লকে অন্তর্ভুক্ত করেছে এমন কোনো অতিরিক্ত ডেটা। + +**অ্যাডভান্সড ডেটা** + +- হ্যাস - ক্রিপ্টোগ্রাফিক হ্যাস যা ব্লক হেডারকে (ব্লকের অনন্য শনাক্তকারী) প্রতিনিধিত্ব করে। +- পেরেন্ট হ্যাস - বর্তমান ব্লকের আগে আসা ব্লকের হ্যাস। +- স্টেট রুট - Merkle trie-এর রুট হ্যাস যা সিস্টেমের সমগ্র স্টেট সংরক্ষণ করে। + +### গ্যাস {#gas} + +ব্লক এক্সপ্লোরারগুলি আপনাকে কেবল লেনদেন এবং ব্লকে গ্যাস ব্যবহার সম্পর্কে ডেটা দেবে না, কিছু কিছু আপনাকে নেটওয়ার্কের বর্তমান গ্যাসের দাম সম্পর্কেও তথ্য দেবে। এটি আপনাকে নেটওয়ার্ক ব্যবহার বুঝতে, নিরাপদ লেনদেন জমা দিতে এবং গ্যাসে অতিরিক্ত খরচ না করতে সাহায্য করবে। আপনার পণ্যের ইন্টারফেসে এই তথ্য পেতে সাহায্য করতে পারে এমন API-গুলির জন্য সন্ধান করুন। গ্যাস-নির্দিষ্ট ডেটা কভার করে: + +- একটি নিরাপদ কিন্তু ধীর লেনদেনের জন্য প্রয়োজনীয় গ্যাসের আনুমানিক ইউনিট (+ আনুমানিক মূল্য এবং সময়কাল) +- একটি গড় লেনদেনের জন্য প্রয়োজনীয় গ্যাসের আনুমানিক ইউনিট (+ আনুমানিক মূল্য এবং সময়কাল) +- একটি দ্রুত লেনদেনের জন্য প্রয়োজনীয় গ্যাসের আনুমানিক ইউনিট (+ আনুমানিক মূল্য এবং সময়কাল) +- গ্যাসের দামের উপর ভিত্তি করে গড় কনফার্মেশন সময়। +- যেসব কন্ট্র্যাক্ট গ্যাস ব্যবহার করছে - অন্য কথায়, জনপ্রিয় পণ্য যা নেটওয়ার্কে প্রচুর ব্যবহার হচ্ছে। +- যেসব অ্যাকাউন্ট গ্যাস খরচ করছে - অন্য কথায়, ঘন ঘন নেটওয়ার্ক ব্যবহারকারীরা। + +### লেনদেন {#transactions} + +ব্লক এক্সপ্লোরার মানুষের জন্য তাদের লেনদেনের অগ্রগতি ট্র্যাক করার জন্য একটি সাধারণ জায়গা হয়ে উঠেছে। এর কারণ হল আপনি যে স্তরের বিস্তারিত তথ্য পেতে পারেন তা অতিরিক্ত নিশ্চয়তা প্রদান করে। লেনদেনের ডেটা অন্তর্ভুক্ত: + +**স্ট্যান্ডার্ড ডেটা** + +- লেনদেনের হ্যাস - লেনদেন জমা দেওয়ার সময় একটি হ্যাস তৈরি হয়। +- স্ট্যাটাস - লেনদেনটি পেন্ডিং, ব্যর্থ বা সফল কিনা তার একটি ইঙ্গিত। +- ব্লক - যে ব্লকে লেনদেন অন্তর্ভুক্ত করা হয়েছে। +- টাইমস্ট্যাম্প - যে সময়ে একটি লেনদেন একজন ভ্যালিডেটর দ্বারা প্রস্তাবিত একটি ব্লকে অন্তর্ভুক্ত করা হয়েছিল। +- প্রেরক - লেনদেন জমা দেওয়া অ্যাকাউন্টের অ্যাড্রেস। +- প্রাপক - প্রাপকের অ্যাড্রেস বা স্মার্ট কন্ট্র্যাক্ট যার সাথে লেনদেনটি ইন্টারঅ্যাক্ট করে। +- স্থানান্তরিত টোকেন - লেনদেনের অংশ হিসাবে স্থানান্তরিত টোকেনের একটি তালিকা। +- ভ্যালু - স্থানান্তরিত মোট ETH ভ্যালু। +- লেনদেন ফি - লেনদেন প্রক্রিয়া করার জন্য ভ্যালিডেটরকে প্রদত্ত পরিমাণ (গ্যাসের মূল্য\*ব্যবহৃত গ্যাস দ্বারা গণনা করা হয়)। + +**অ্যাডভান্সড ডেটা** + +- গ্যাস লিমিট - এই লেনদেনটি সর্বোচ্চ যত ইউনিট গ্যাস ব্যবহার করতে পারে। +- ব্যবহৃত গ্যাস - লেনদেনটি যে পরিমাণ গ্যাস ইউনিট ব্যবহার করেছে। +- গ্যাসের মূল্য - প্রতি গ্যাস ইউনিটের জন্য নির্ধারিত মূল্য। +- Nonce - `from` অ্যাড্রেসের জন্য লেনদেন নম্বর (মনে রাখবেন এটি 0 থেকে শুরু হয় তাই `100` এর একটি নন্স আসলে এই অ্যাকাউন্ট দ্বারা জমা দেওয়া 101তম লেনদেন হবে)। +- ইনপুট ডেটা - লেনদেনের জন্য প্রয়োজনীয় যেকোনো অতিরিক্ত তথ্য। + +### অ্যাকাউন্ট {#accounts} + +একটি অ্যাকাউন্ট সম্পর্কে আপনি অনেক ডেটা অ্যাক্সেস করতে পারেন। এই কারণেই প্রায়শই একাধিক অ্যাকাউন্ট ব্যবহার করার পরামর্শ দেওয়া হয় যাতে আপনার সম্পদ এবং মূল্য সহজে ট্র্যাক করা না যায়। লেনদেন এবং অ্যাকাউন্টের কার্যকলাপকে আরও ব্যক্তিগত করার জন্য কিছু সমাধানও তৈরি করা হচ্ছে। তবে এখানে অ্যাকাউন্টগুলির জন্য উপলব্ধ ডেটা রয়েছে: + +**ব্যবহারকারী অ্যাকাউন্ট** + +- অ্যাকাউন্ট অ্যাড্রেস - পাবলিক অ্যাড্রেস যা আপনি ফান্ড পাঠাতে ব্যবহার করতে পারেন। +- ETH ব্যালেন্স - সেই অ্যাকাউন্টের সাথে যুক্ত ETH-এর পরিমাণ। +- মোট ETH ভ্যালু - ETH-এর ভ্যালু। +- টোকেন - অ্যাকাউন্টের সাথে যুক্ত টোকেন এবং তাদের ভ্যালু। +- লেনদেনের ইতিহাস - সমস্ত লেনদেনের একটি তালিকা যেখানে এই অ্যাকাউন্টটি প্রেরক বা প্রাপক ছিল। + +**স্মার্ট কন্ট্র্যাক্ট** + +স্মার্ট কন্ট্র্যাক্ট অ্যাকাউন্টগুলিতে একটি ব্যবহারকারী অ্যাকাউন্টের সমস্ত ডেটা থাকে, তবে কিছু ব্লক এক্সপ্লোরার এমনকি কিছু কোড তথ্যও প্রদর্শন করবে। উদাহরণগুলির মধ্যে রয়েছে: + +- কন্ট্র্যাক্ট নির্মাতা - যে অ্যাড্রেসটি Mainnet-এ কন্ট্র্যাক্টটি ডিপ্লয় করেছে। +- তৈরির লেনদেন - যে লেনদেন Mainnet-এ ডিপ্লয়মেন্ট অন্তর্ভুক্ত করেছে। +- সোর্স কোড - স্মার্ট কন্ট্র্যাক্টের সলিডিটি বা ভাইপার কোড। +- কন্ট্র্যাক্ট ABI - কন্ট্র্যাক্টের অ্যাপ্লিকেশন বাইনারি ইন্টারফেস—কন্ট্র্যাক্ট যে কলগুলি করে এবং প্রাপ্ত ডেটা। +- কন্ট্র্যাক্ট তৈরির কোড - স্মার্ট কন্ট্র্যাক্টের কম্পাইল করা বাইটকোড—আপনি যখন সলিডিটি বা ভাইপার ইত্যাদিতে লেখা একটি স্মার্ট কন্ট্র্যাক্ট কম্পাইল করেন তখন তৈরি হয়। +- কন্ট্র্যাক্ট ইভেন্ট - স্মার্ট কন্ট্র্যাক্টে কল করা পদ্ধতিগুলির একটি ইতিহাস—মূলত কন্ট্র্যাক্টটি কীভাবে এবং কত ঘন ঘন ব্যবহার করা হচ্ছে তা দেখার একটি উপায়। + +### টোকেন {#tokens} + +টোকেন এক ধরনের কন্ট্র্যাক্ট তাই তাদের স্মার্ট কন্ট্র্যাক্টের মতো একই ধরনের ডেটা থাকবে। কিন্তু যেহেতু তাদের মূল্য আছে এবং ট্রেড করা যায়, তাই তাদের অতিরিক্ত ডেটা পয়েন্ট রয়েছে: + +- প্রকার - সেগুলি একটি ERC-20, ERC-721 বা অন্য কোনো টোকেন স্ট্যান্ডার্ড কিনা। +- মূল্য - যদি সেগুলি একটি ERC-20 হয় তবে তাদের একটি বর্তমান বাজার মূল্য থাকবে। +- মার্কেট ক্যাপ - যদি সেগুলি একটি ERC-20 হয় তবে তাদের একটি মার্কেট ক্যাপ থাকবে (মূল্য\*মোট সরবরাহ দ্বারা গণনা করা হয়)। +- মোট সরবরাহ - প্রচলিত টোকেনের সংখ্যা। +- হোল্ডার - টোকেন ধারণকারী অ্যাড্রেসের সংখ্যা। +- স্থানান্তর - অ্যাকাউন্টগুলির মধ্যে টোকেনটি যতবার স্থানান্তরিত হয়েছে। +- লেনদেনের ইতিহাস - টোকেন সহ সমস্ত লেনদেনের একটি ইতিহাস। +- কন্ট্র্যাক্ট অ্যাড্রেস - Mainnet-এ ডিপ্লয় করা টোকেনের অ্যাড্রেস। +- ডেসিমেল - ERC-20 টোকেন বিভাজ্য এবং দশমিক স্থান আছে। + +### নেটওয়ার্ক {#network} + +কিছু ব্লক ডেটা আরও সামগ্রিকভাবে ইথেরিয়ামের স্বাস্থ্য সম্পর্কে উদ্বিগ্ন। + +- মোট লেনদেন - ইথেরিয়াম তৈরি হওয়ার পর থেকে লেনদেনের সংখ্যা। +- প্রতি সেকেন্ডে লেনদেন - এক সেকেন্ডের মধ্যে প্রক্রিয়াযোগ্য লেনদেনের সংখ্যা। +- ETH মূল্য - 1 ETH-এর বর্তমান মূল্যায়ন। +- মোট ETH সরবরাহ - প্রচলিত ETH-এর সংখ্যা—মনে রাখবেন ব্লক রিওয়ার্ড আকারে প্রতিটি ব্লক তৈরির সাথে নতুন ETH তৈরি হয়। +- মার্কেট ক্যাপ - মূল্য\*সরবরাহের গণনা। + +## কনসেন্সাস লেয়ার ডেটা {#consensus-layer-data} + +### ইপক {#epoch} + +নিরাপত্তার কারণে, প্রতিটি ইপকের শেষে (প্রতি 6.4 মিনিটে) ভ্যালিডেটরদের র‍্যান্ডমাইজড কমিটি তৈরি করা হয়। ইপক ডেটা অন্তর্ভুক্ত: + +- ইপক নম্বর +- ফাইনাল করা স্ট্যাটাস - ইপক ফাইনাল করা হয়েছে কিনা (হ্যাঁ/না)। +- সময় - যে সময়ে ইপক শেষ হয়েছিল। +- অ্যাটেস্টেশন - ইপকের অ্যাটেস্টেশনের সংখ্যা (স্লটের মধ্যে ব্লকের জন্য ভোট)। +- ডিপোজিট - ইপকে অন্তর্ভুক্ত ETH ডিপোজিটের সংখ্যা (ভ্যালিডেটরদের ভ্যালিডেটর হওয়ার জন্য ETH স্টেক করতে হবে)। +- স্ল্যাশিং - ব্লক বা অ্যাটেস্টরদের প্রস্তাবকদের দেওয়া পেনাল্টির সংখ্যা। +- ভোটদান অংশগ্রহণ - ব্লক অ্যাটেস্ট করতে ব্যবহৃত স্টেক করা ETH-এর পরিমাণ। +- ভ্যালিডেটর - ইপকের জন্য সক্রিয় ভ্যালিডেটরের সংখ্যা। +- গড় ভ্যালিডেটর ব্যালেন্স - সক্রিয় ভ্যালিডেটরদের জন্য গড় ব্যালেন্স। +- স্লট - ইপকে অন্তর্ভুক্ত স্লটের সংখ্যা (স্লটে একটি বৈধ ব্লক অন্তর্ভুক্ত থাকে)। + +### স্লট {#slot} + +স্লট হল ব্লক তৈরির সুযোগ, প্রতিটি স্লটের জন্য উপলব্ধ ডেটা অন্তর্ভুক্ত: + +- ইপক - যে ইপকে স্লটটি বৈধ। +- স্লট নম্বর +- স্ট্যাটাস - স্লটের স্ট্যাটাস (প্রস্তাবিত/মিসড)। +- সময় - স্লটের টাইমস্ট্যাম্প। +- প্রস্তাবক - যে ভ্যালিডেটর স্লটের জন্য ব্লকের প্রস্তাব করেছিল। +- ব্লক রুট - BeaconBlock-এর হ্যাস-ট্রি-রুট। +- পেরেন্ট রুট - এর আগে আসা ব্লকের হ্যাস। +- স্টেট রুট - BeaconState-এর হ্যাস-ট্রি-রুট। +- স্বাক্ষর +- Randao রিভিল +- গ্রাফিতি - একটি ব্লক প্রস্তাবক তার ব্লক প্রস্তাবে 32 বাইট দীর্ঘ বার্তা অন্তর্ভুক্ত করতে পারে। +- এক্সিকিউশন ডেটা + - ব্লক হ্যাস + - ডিপোজিট কাউন্ট + - ডিপোজিট রুট +- অ্যাটেস্টেশন - এই স্লটে ব্লকের জন্য অ্যাটেস্টেশনের সংখ্যা। +- ডিপোজিট - এই স্লটের সময় ডিপোজিটের সংখ্যা। +- স্বেচ্ছায় প্রস্থান - স্লটের সময় চলে যাওয়া ভ্যালিডেটরদের সংখ্যা। +- স্ল্যাশিং - ব্লক বা অ্যাটেস্টরদের প্রস্তাবকদের দেওয়া পেনাল্টির সংখ্যা। +- ভোট - এই স্লটে ব্লকের জন্য ভোট দেওয়া ভ্যালিডেটররা। + +### ব্লক {#blocks-1} + +প্রুফ-অফ-স্টেক সময়কে স্লট এবং ইপকে বিভক্ত করে। সুতরাং এর মানে নতুন ডেটা! + +- প্রস্তাবক - নতুন ব্লকের প্রস্তাব দেওয়ার জন্য অ্যালগরিদমিকভাবে নির্বাচিত ভ্যালিডেটর। +- ইপক - যে ইপকে ব্লকের প্রস্তাব করা হয়েছিল। +- স্লট - যে স্লটে ব্লকের প্রস্তাব করা হয়েছিল। +- অ্যাটেস্টেশন - স্লটে অন্তর্ভুক্ত অ্যাটেস্টেশনের সংখ্যা—অ্যাটেস্টেশন হল ভোটের মতো যা নির্দেশ করে যে ব্লকটি বিকন চেইনে যাওয়ার জন্য প্রস্তুত। + +### ভ্যালিডেটর {#validators} + +ভ্যালিডেটররা স্লটের মধ্যে ব্লক প্রস্তাব এবং অ্যাটেস্ট করার জন্য দায়ী। + +- ভ্যালিডেটর নম্বর - অনন্য নম্বর যা ভ্যালিডেটরকে প্রতিনিধিত্ব করে। +- বর্তমান ব্যালেন্স - পুরস্কার সহ ভ্যালিডেটরের ব্যালেন্স। +- কার্যকরী ব্যালেন্স - ভ্যালিডেটরের ব্যালেন্স যা স্টেকিংয়ের জন্য ব্যবহৃত হয়। +- আয় - ভ্যালিডেটর দ্বারা প্রাপ্ত পুরস্কার বা পেনাল্টি। +- স্ট্যাটাস - ভ্যালিডেটর বর্তমানে অনলাইন এবং সক্রিয় আছে কি না। +- অ্যাটেস্টেশন কার্যকারিতা - ভ্যালিডেটরের অ্যাটেস্টেশনগুলি চেইনে অন্তর্ভুক্ত হতে যে গড় সময় লাগে। +- অ্যাক্টিভেশনের জন্য যোগ্যতা - তারিখ (এবং ইপক) যখন ভ্যালিডেটর ভ্যালিডেট করার জন্য উপলব্ধ হয়েছিল। +- থেকে সক্রিয় - তারিখ (এবং ইপক) যখন ভ্যালিডেটর সক্রিয় হয়েছিল। +- প্রস্তাবিত ব্লক - ভ্যালিডেটর যে ব্লকের প্রস্তাব করেছে। +- অ্যাটেস্টেশন - ভ্যালিডেটর যে অ্যাটেস্টেশনগুলি প্রদান করেছে। +- ডিপোজিট - ভ্যালিডেটরের দ্বারা করা স্টেকিং ডিপোজিটের প্রেরকের অ্যাড্রেস, লেনদেন হ্যাস, ব্লক নম্বর, টাইমস্ট্যাম্প, পরিমাণ এবং স্ট্যাটাস। + +### অ্যাটেস্টেশন {#attestations} + +অ্যাটেস্টেশনগুলি হল চেইনে ব্লক অন্তর্ভুক্ত করার জন্য "হ্যাঁ" ভোট। তাদের ডেটা অ্যাটেস্টেশনের একটি রেকর্ড এবং অ্যাটেস্ট করা ভ্যালিডেটরদের সাথে সম্পর্কিত। + +- স্লট - যে স্লটে অ্যাটেস্টেশন হয়েছিল। +- কমিটি ইন্ডেক্স - প্রদত্ত স্লটে কমিটির ইন্ডেক্স। +- অ্যাগ্রিগেশন বিটস - অ্যাটেস্টেশনে অংশগ্রহণকারী সমস্ত ভ্যালিডেটরের অ্যাগ্রিগেটেড অ্যাটেস্টেশনকে প্রতিনিধিত্ব করে। +- ভ্যালিডেটর - যে ভ্যালিডেটররা অ্যাটেস্টেশন প্রদান করেছে। +- বিকন ব্লক রুট - যে ব্লকে ভ্যালিডেটররা অ্যাটেস্ট করছে সেটিকে নির্দেশ করে। +- সোর্স - সর্বশেষ জাস্টিফাইড ইপককে নির্দেশ করে। +- টার্গেট - সর্বশেষ ইপক বাউন্ডারিকে নির্দেশ করে। +- স্বাক্ষর + +### নেটওয়ার্ক {#network-1} + +কনসেন্সাস লেয়ারের টপ-লেভেল ডেটার মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে: + +- বর্তমান ইপক +- বর্তমান স্লট +- সক্রিয় ভ্যালিডেটর - সক্রিয় ভ্যালিডেটরের সংখ্যা। +- পেন্ডিং ভ্যালিডেটর - সক্রিয় হওয়ার জন্য অপেক্ষারত ভ্যালিডেটরের সংখ্যা। +- স্টেক করা ETH - নেটওয়ার্কে স্টেক করা ETH-এর পরিমাণ। +- গড় ব্যালেন্স - ভ্যালিডেটরদের গড় ETH ব্যালেন্স। + +## ব্লক এক্সপ্লোরার {#block-explorers} + +- [Etherscan](https://etherscan.io/) - একটি ব্লক এক্সপ্লোরার যা আপনি Ethereum Mainnet এবং টেস্টনেটের জন্য ডেটা আনতে ব্যবহার করতে পারেন। +- [3xpl](https://3xpl.com/ethereum) - একটি বিজ্ঞাপন-মুক্ত ওপেন-সোর্স Ethereum এক্সপ্লোরার যা এর ডেটাসেট ডাউনলোড করার অনুমতি দেয়। +- [Beaconcha.in](https://beaconcha.in/) - Ethereum Mainnet এবং টেস্টনেটের জন্য একটি ওপেন সোর্স ব্লক এক্সপ্লোরার। +- [Blockchair](https://blockchair.com/ethereum) - সবচেয়ে ব্যক্তিগত Ethereum এক্সপ্লোরার। এছাড়াও (mempool) ডেটা সর্টিং এবং ফিল্টার করার জন্য। +- [Etherchain](https://www.etherchain.org/) - Ethereum Mainnet-এর জন্য একটি ব্লক এক্সপ্লোরার। +- [Ethplorer](https://ethplorer.io/) - Ethereum Mainnet এবং Kovan টেস্টনেটের জন্য টোকেনের উপর ফোকাস সহ একটি ব্লক এক্সপ্লোরার। + +## আরও পড়ুন {#further-reading} + +_এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন যা আপনাকে সাহায্য করেছে? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যোগ করুন!_ + +## সম্পর্কিত বিষয় {#related-topics} + +- [লেনদেন](/developers/docs/transactions/) +- [অ্যাকাউন্ট](/developers/docs/accounts/) +- [নেটওয়ার্ক](/developers/docs/networks/) diff --git a/public/content/translations/bn/developers/docs/data-and-analytics/index.md b/public/content/translations/bn/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..8d3fbdc744b --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "ডেটা এবং বিশ্লেষণ" +description: "আপনার ডিএ্যাপস-এ ব্যবহারের জন্য কীভাবে অনচেইন বিশ্লেষণ এবং ডেটা পাবেন" +lang: bn +--- + +## ভূমিকা {#Introduction} + +নেটওয়ার্কের ব্যবহার ক্রমাগত বাড়তে থাকায়, অনচেইন ডেটাতে ক্রমবর্ধমান মূল্যবান তথ্য বিদ্যমান থাকবে। ডেটার পরিমাণ দ্রুত বাড়ার সাথে সাথে, রিপোর্ট করার জন্য বা একটি ডিএ্যাপ চালানোর জন্য এই তথ্য গণনা করা এবং একত্রিত করা একটি সময় এবং প্রক্রিয়া সাপেক্ষ প্রচেষ্টা হয়ে উঠতে পারে। + +বিদ্যমান ডেটা প্রদানকারীদের ব্যবহার উন্নয়নকে ত্বরান্বিত করতে পারে, আরও সঠিক ফলাফল তৈরি করতে পারে এবং চলমান রক্ষণাবেক্ষণের প্রচেষ্টা কমাতে পারে। এটি একটি দলকে তাদের প্রকল্পের মূল কার্যকারিতার উপর মনোযোগ কেন্দ্রীভূত করতে সক্ষম করবে। + +## পূর্বশর্ত {#prerequisites} + +ডেটা বিশ্লেষণ প্রসঙ্গে ব্লক এক্সপ্লোরারগুলির ব্যবহার আরও ভালভাবে বোঝার জন্য আপনার [ব্লক এক্সপ্লোরার](/developers/docs/data-and-analytics/block-explorers/)-এর মূল ধারণাটি বোঝা উচিত। এছাড়াও, একটি সিস্টেম ডিজাইনে তারা যে সুবিধাগুলি যোগ করে তা বোঝার জন্য একটি [সূচক](/glossary/#index)-এর ধারণার সাথে নিজেকে পরিচিত করুন। + +স্থাপত্যের মৌলিক বিষয়গুলির পরিপ্রেক্ষিতে, একটি [API](https://www.wikipedia.org/wiki/API) এবং [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) কী, তা অন্তত তাত্ত্বিকভাবে বোঝা প্রয়োজন। + +## ব্লক এক্সপ্লোরার {#block-explorers} + +অনেক [ব্লক এক্সপ্লোরার](/developers/docs/data-and-analytics/block-explorers/) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) গেটওয়ে অফার করে যা ডেভেলপারদের ব্লক, লেনদেন, ভ্যালিডেটর, অ্যাকাউন্ট এবং অন্যান্য অনচেইন কার্যকলাপের রিয়েল-টাইম ডেটাতে দৃশ্যমানতা প্রদান করবে। + +ডেভেলপাররা তখন তাদের ব্যবহারকারীদের [ব্লকচেইন](/glossary/#blockchain)-এর সাথে অনন্য অন্তর্দৃষ্টি এবং মিথস্ক্রিয়া দেওয়ার জন্য এই ডেটা প্রক্রিয়া এবং রূপান্তর করতে পারে। উদাহরণস্বরূপ, [Etherscan](https://etherscan.io) এবং [Blockscout](https://eth.blockscout.com) প্রতি 12s স্লটের জন্য এক্সিকিউশন এবং কনসেন্সাস ডেটা সরবরাহ করে। + +## গ্রাফ {#the-graph} + +[The Graph](https://thegraph.com/) একটি ইন্ডেক্সিং প্রোটোকল যা সাবগ্রাফ নামে পরিচিত ওপেন API-এর মাধ্যমে ব্লকচেইন ডেটা জিজ্ঞাসা করার একটি সহজ উপায় সরবরাহ করে। + +The Graph-এর মাধ্যমে, ডেভেলপাররা নিম্নলিখিত সুবিধাগুলি থেকে উপকৃত হতে পারেন: + +- বিকেন্দ্রীভূত ইন্ডেক্সিং: একাধিক ইন্ডেক্সারের মাধ্যমে ব্লকচেইন ডেটা ইন্ডেক্সিং সক্ষম করে, যার ফলে ব্যর্থতার কোনো একক বিন্দু দূর হয়। +- GraphQL কোয়েরি: ইন্ডেক্সড ডেটা কোয়েরি করার জন্য একটি শক্তিশালী GraphQL ইন্টারফেস সরবরাহ করে, যা ডেটা পুনরুদ্ধারকে খুব সহজ করে তোলে। +- কাস্টমাইজেশন: ব্লকচেইন ডেটা রূপান্তর এবং সংরক্ষণের জন্য আপনার নিজস্ব যুক্তি সংজ্ঞায়িত করুন, এবং The Graph নেটওয়ার্কে অন্যান্য ডেভেলপারদের দ্বারা প্রকাশিত সাবগ্রাফগুলি পুনরায় ব্যবহার করুন। + +৫ মিনিটের মধ্যে একটি সাবগ্রাফ তৈরি, স্থাপন এবং জিজ্ঞাসা করতে এই [কুইক-স্টার্ট](https://thegraph.com/docs/en/quick-start/) গাইডটি অনুসরণ করুন। + +## ক্লায়েন্ট বৈচিত্র্য {#client-diversity} + +[ক্লায়েন্ট বৈচিত্র্য](/developers/docs/nodes-and-clients/client-diversity/) ইথেরিয়াম নেটওয়ার্কের সামগ্রিক স্বাস্থ্যের জন্য গুরুত্বপূর্ণ কারণ এটি বাগ এবং এক্সপ্লয়েটের বিরুদ্ধে স্থিতিস্থাপকতা প্রদান করে। এখন বেশ কয়েকটি ক্লায়েন্ট বৈচিত্র্য ড্যাশবোর্ড রয়েছে যার মধ্যে রয়েছে [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) এবং [Ethernodes](https://ethernodes.org/)। + +## Dune অ্যানালিটিক্স {#dune-analytics} + +[Dune Analytics](https://dune.com/) ব্লকচেইন ডেটাকে রিলেশনাল ডাটাবেস (DuneSQL) টেবিলে প্রাক-প্রসেস করে, ব্যবহারকারীদের SQL ব্যবহার করে ব্লকচেইন ডেটা জিজ্ঞাসা করতে এবং কোয়েরির ফলাফলের উপর ভিত্তি করে ড্যাশবোর্ড তৈরি করতে দেয়। অনচেইন ডেটা ৪টি কাঁচা টেবিলে সংগঠিত হয়: `blocks`, `transactions`, (ইভেন্ট) `logs` এবং (কল) `traces`। জনপ্রিয় চুক্তি এবং প্রোটোকলগুলি ডিকোড করা হয়েছে, এবং প্রত্যেকের নিজস্ব ইভেন্ট এবং কল টেবিলের সেট রয়েছে। সেই ইভেন্ট এবং কল টেবিলগুলি আরও প্রক্রিয়াজাত করা হয় এবং প্রোটোকলের ধরন অনুসারে অ্যাবস্ট্র্যাকশন টেবিলে সংগঠিত করা হয়, উদাহরণস্বরূপ, dex, লেন্ডিং, স্টেবলকয়েন ইত্যাদি। + +## SQD {#sqd} + +[SQD](https://sqd.dev/) একটি বিকেন্দ্রীভূত হাইপার-স্কেলেবল ডেটা প্ল্যাটফর্ম যা প্রচুর পরিমাণে ডেটাতে দক্ষ, অনুমতিহীন অ্যাক্সেস প্রদানের জন্য অপ্টিমাইজ করা হয়েছে। এটি বর্তমানে ঐতিহাসিক অন-চেইন ডেটা পরিবেশন করে, যার মধ্যে রয়েছে ইভেন্ট লগ, লেনদেনের রসিদ, ট্রেস এবং প্রতি-লেনদেন স্টেট ডিফস। SQD কাস্টম ডেটা নিষ্কাশন এবং প্রক্রিয়াকরণ পাইপলাইন তৈরির জন্য একটি শক্তিশালী টুলকিট অফার করে, যা প্রতি সেকেন্ডে ১৫০k ব্লক পর্যন্ত একটি ইন্ডেক্সিং গতি অর্জন করে। + +শুরু করতে, [নথিপত্র](https://docs.sqd.dev/) দেখুন বা SQD দিয়ে আপনি কী তৈরি করতে পারেন তার [EVM উদাহরণ](https://github.com/subsquid-labs/squid-evm-examples) দেখুন। + +## SubQuery নেটওয়ার্ক {#subquery-network} + +[SubQuery](https://subquery.network/) একটি নেতৃস্থানীয় ডেটা ইন্ডেক্সার যা ডেভেলপারদের তাদের web3 প্রকল্পগুলির জন্য দ্রুত, নির্ভরযোগ্য, বিকেন্দ্রীভূত এবং কাস্টমাইজড API দেয়। SubQuery ১৬৫টিরও বেশি ইকোসিস্টেম (ইথেরিয়াম সহ) থেকে ডেভেলপারদের সমৃদ্ধ ইন্ডেক্সড ডেটা দিয়ে তাদের ব্যবহারকারীদের জন্য একটি স্বজ্ঞাত এবং নিমগ্ন অভিজ্ঞতা তৈরি করতে ক্ষমতা দেয়। SubQuery নেটওয়ার্ক আপনার অপ্রতিরোধ্য অ্যাপগুলিকে একটি স্থিতিস্থাপক এবং বিকেন্দ্রীভূত অবকাঠামো নেটওয়ার্কের সাথে শক্তি দেয়। ডেটা প্রক্রিয়াকরণ কার্যকলাপের জন্য একটি কাস্টম ব্যাকএন্ড তৈরি করার জন্য সময় ব্যয় না করে ভবিষ্যতের web3 অ্যাপ্লিকেশনগুলি তৈরি করতে SubQuery-এর ব্লকচেইন ডেভেলপার টুলকিট ব্যবহার করুন। + +শুরু করতে, [SubQuery-এর পরিচালিত পরিষেবা](https://managedservice.subquery.network/) বা [SubQuery-এর বিকেন্দ্রীভূত নেটওয়ার্ক](https://app.subquery.network/dashboard)-এ লাইভ যাওয়ার আগে পরীক্ষার জন্য একটি স্থানীয় ডকার পরিবেশে মিনিটের মধ্যে ইথেরিয়াম ব্লকচেইন ডেটা ইন্ডেক্স করা শুরু করতে [ইথেরিয়াম কুইক স্টার্ট গাইড](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) দেখুন। + +## EVM কোয়েরি ল্যাঙ্গুয়েজ {#evm-query-language} + +EVM কোয়েরি ল্যাঙ্গুয়েজ (EQL) হল একটি SQL-এর মতো ভাষা যা EVM (ইথিরিয়াম ভার্চুয়াল মেশিন) চেইনগুলিকে জিজ্ঞাসা করার জন্য ডিজাইন করা হয়েছে। EQL-এর চূড়ান্ত লক্ষ্য হল EVM চেইনের প্রথম-শ্রেণীর নাগরিক (ব্লক, অ্যাকাউন্ট, এবং লেনদেন)-এর উপর জটিল রিলেশনাল কোয়েরি সমর্থন করা এবং একই সাথে ডেভেলপার এবং গবেষকদের দৈনন্দিন ব্যবহারের জন্য একটি আর্গোনমিক সিনট্যাক্স প্রদান করা। EQL-এর সাহায্যে, ডেভেলপাররা পরিচিত SQL-এর মতো সিনট্যাক্স ব্যবহার করে ব্লকচেইন ডেটা আনতে পারে এবং জটিল বয়লারপ্লেট কোডের প্রয়োজন দূর করতে পারে। EQL স্ট্যান্ডার্ড ব্লকচেইন ডেটা অনুরোধগুলি সমর্থন করে (যেমন, ইথেরিয়ামে একটি অ্যাকাউন্টের নন্স এবং ব্যালেন্স পুনরুদ্ধার করা বা বর্তমান ব্লক আকার এবং টাইমস্ট্যাম্প আনা) এবং ক্রমাগত আরও জটিল অনুরোধ এবং বৈশিষ্ট্যসেটগুলির জন্য সমর্থন যোগ করছে। + +## আরও পড়ুন {#further-reading} + +- [ক্রিপ্টো ডেটা অন্বেষণ I: ডেটা ফ্লো আর্কিটেকচার](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [গ্রাফ নেটওয়ার্ক ওভারভিউ](https://thegraph.com/docs/en/about/) +- [গ্রাফ কোয়েরি প্লেগ্রাউন্ড](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [EtherScan-এ API কোডের উদাহরণ](https://etherscan.io/apis#contracts) +- [Blockscout-এ API নথিপত্র](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in বিকন চেইন এক্সপ্লোরার](https://beaconcha.in) +- [Dune বেসিকস](https://docs.dune.com/#dune-basics) +- [SubQuery ইথেরিয়াম কুইক স্টার্ট গাইড](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [SQD নেটওয়ার্ক ওভারভিউ](https://docs.sqd.dev/) +- [EVM কোয়েরি ল্যাঙ্গুয়েজ](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/bn/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/bn/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..5b631371d81 --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "ব্লকচেইন ডেটা সংগ্রহের কৌশল" +description: "ব্লকচেইন ব্যবহার করে ডেটা সঞ্চয় করার বিভিন্ন উপায় রয়েছে। এই নিবন্ধে বিভিন্ন কৌশল, তাদের খরচ এবং ট্রেডঅফ, সেইসাথে এটি নিরাপদে ব্যবহারের জন্য প্রয়োজনীয়তাগুলির তুলনা করা হবে।" +lang: bn +--- + +ব্লকচেইনে সরাসরি তথ্য সঞ্চয় করার একাধিক উপায় রয়েছে, অথবা এমন একটি পদ্ধতিতে যা ব্লকচেইন দ্বারা সুরক্ষিত: + +- EIP-4844 blobs +- Calldata +- L1 মেকানিজম সহ অফচেইন +- কন্ট্র্যাক্ট "কোড" +- অনুষ্ঠানসমূহ +- EVM সংগ্রহস্থল + +কোন পদ্ধতিটি ব্যবহার করা হবে তা বিভিন্ন মানদণ্ডের উপর ভিত্তি করে নির্ধারিত হয়: + +- তথ্যের উৎস। Calldata-তে থাকা তথ্য সরাসরি ব্লকচেইন থেকে আসতে পারে না। +- তথ্যের গন্তব্য। Calldata শুধুমাত্র সেই লেনদেনেই উপলব্ধ যা এটি অন্তর্ভুক্ত করে। ইভেন্টগুলি অনচেইনে একেবারেই অ্যাক্সেসযোগ্য নয়। +- কতটা ঝামেলা গ্রহণযোগ্য? একটি পূর্ণ-স্কেল নোড চালানো কম্পিউটারগুলি ব্রাউজারে চলমান একটি অ্যাপ্লিকেশনের লাইট ক্লায়েন্টের চেয়ে বেশি প্রক্রিয়াকরণ করতে পারে। +- প্রতিটি নোড থেকে তথ্যে সহজ অ্যাক্সেসের সুবিধা প্রদান করা কি প্রয়োজনীয়? +- নিরাপত্তা প্রয়োজনীয়তা। + +## নিরাপত্তা প্রয়োজনীয়তা {#security-requirements} + +সাধারণত, তথ্য নিরাপত্তা তিনটি বৈশিষ্ট্যের সমন্বয়ে গঠিত: + +- _গোপনীয়তা_, অননুমোদিত সত্তাকে তথ্য পড়ার অনুমতি দেওয়া হয় না। এটি অনেক ক্ষেত্রে গুরুত্বপূর্ণ, কিন্তু এখানে নয়। _ব্লকচেইনে কোনো গোপনীয়তা নেই_। ব্লকচেইন কাজ করে কারণ যে কেউ অবস্থার পরিবর্তন যাচাই করতে পারে, তাই সরাসরি গোপনীয়তা সঞ্চয় করতে এটি ব্যবহার করা অসম্ভব। ব্লকচেইনে গোপনীয় তথ্য সঞ্চয় করার উপায় রয়েছে, কিন্তু সেগুলি সবই অন্তত একটি কী সঞ্চয় করার জন্য কিছু অফচেইন উপাদানের উপর নির্ভর করে। + +- _অখণ্ডতা_, তথ্য সঠিক, এটি অননুমোদিত সত্তা দ্বারা বা অননুমোদিত উপায়ে পরিবর্তন করা যায় না (উদাহরণস্বরূপ, `Transfer` ইভেন্ট ছাড়া [ERC-20 টোকেন](https://eips.ethereum.org/EIPS/eip-20#events) স্থানান্তর করা)। ব্লকচেইনে, প্রতিটি নোড প্রতিটি অবস্থার পরিবর্তন যাচাই করে, যা অখণ্ডতা নিশ্চিত করে। + +- _প্রাপ্যতা_, তথ্য যেকোনো অনুমোদিত সত্তার কাছে উপলব্ধ। ব্লকচেইনে, এটি সাধারণত প্রতিটি [সম্পূর্ণ নোডে](https://ethereum.org/developers/docs/nodes-and-clients#full-node) তথ্য উপলব্ধ রাখার মাধ্যমে অর্জন করা হয়। + +এখানকার বিভিন্ন সমাধানের সবকটিরই চমৎকার অখণ্ডতা রয়েছে, কারণ হ্যাশগুলি L1-এ পোস্ট করা হয়। তবে, তাদের বিভিন্ন প্রাপ্যতা গ্যারান্টি রয়েছে। + +## পূর্বশর্ত {#prerequisites} + +[ব্লকচেইন মৌলিক বিষয়গুলো](/developers/docs/intro-to-ethereum/) সম্পর্কে আপনার একটি ভালো ধারণা থাকা উচিত। এই পৃষ্ঠাটি আরও ধরে নেয় যে পাঠক [ব্লক](/developers/docs/blocks/), [লেনদেন](/developers/docs/transactions/), এবং অন্যান্য প্রাসঙ্গিক বিষয়গুলির সাথে পরিচিত। + +## EIP-4844 blobs {#eip-4844-blobs} + +[Dencun হার্ডফর্ক](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) থেকে শুরু করে ইথেরিয়াম ব্লকচেইনে [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) অন্তর্ভুক্ত রয়েছে, যা ইথেরিয়ামে একটি সীমিত জীবনকালের (প্রাথমিকভাবে প্রায় [18 দিন](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)) ডেটা ব্লব যোগ করে। এই ব্লবগুলির মূল্য [এক্সিকিউশন গ্যাস](/developers/docs/gas) থেকে আলাদাভাবে নির্ধারিত হয়, যদিও একটি অনুরূপ মেকানিজম ব্যবহার করা হয়। এগুলি অস্থায়ী ডেটা পোস্ট করার একটি সস্তা উপায়। + +EIP-4844 ব্লবগুলির প্রধান ব্যবহার হলো রোলআপগুলির লেনদেন প্রকাশ করা। [অপ্টিমেস্টিক রোলআপগুলির](/developers/docs/scaling/optimistic-rollups) তাদের ব্লকচেইনে লেনদেন প্রকাশ করতে হয়। রোলআপের [সিকোয়েন্সার](https://docs.optimism.io/connect/resources/glossary#sequencer) যদি একটি ভুল স্টেট রুট পোস্ট করে, তাহলে [ভ্যালিডেটরদের](https://docs.optimism.io/connect/resources/glossary#validator) ভুলটি সংশোধন করতে সক্ষম করার জন্য [চ্যালেঞ্জ পিরিয়ড](https://docs.optimism.io/connect/resources/glossary#challenge-period) চলাকালীন সেই লেনদেনগুলি যে কারও কাছে উপলব্ধ থাকতে হবে। + +তবে, চ্যালেঞ্জ পিরিয়ড শেষ হয়ে গেলে এবং স্টেট রুট চূড়ান্ত হয়ে গেলে, এই লেনদেনগুলি জানার বাকি উদ্দেশ্য হলো চেইনের বর্তমান অবস্থার প্রতিলিপি তৈরি করা। এই অবস্থাটি চেইন নোড থেকেও উপলব্ধ, যেখানে অনেক কম প্রক্রিয়াকরণের প্রয়োজন হয়। সুতরাং লেনদেনের তথ্য এখনও কিছু জায়গায় সংরক্ষণ করা উচিত, যেমন [ব্লক এক্সপ্লোরার](/developers/docs/data-and-analytics/block-explorers), কিন্তু ইথেরিয়ামের দেওয়া সেন্সরশিপ প্রতিরোধের স্তরের জন্য অর্থ প্রদানের প্রয়োজন নেই। + +[জিরো-নলেজ রোলআপগুলি](/developers/docs/scaling/zk-rollups/#data-availability) তাদের লেনদেনের ডেটাও পোস্ট করে যাতে অন্যান্য নোড বিদ্যমান অবস্থার প্রতিলিপি তৈরি করতে এবং ভ্যালিডিটি প্রুফ যাচাই করতে পারে, তবে এটিও একটি স্বল্পমেয়াদী প্রয়োজন। + +লেখার সময় EIP-4844-এ পোস্ট করার জন্য প্রতি বাইটে এক wei (10-18 ETH) খরচ হয়, যা [যেকোনো লেনদেনের জন্য 21,000 এক্সিকিউশন গ্যাস, যার মধ্যে ব্লব পোস্ট করাও অন্তর্ভুক্ত, খরচের](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index) তুলনায় নগণ্য। আপনি [blobscan.com](https://blobscan.com/blocks)-এ বর্তমান EIP-4844 মূল্য দেখতে পারেন। + +এখানে কিছু বিখ্যাত রোলআপ দ্বারা পোস্ট করা ব্লবগুলি দেখার জন্য ঠিকানা দেওয়া হলো। + +| রোলআপ | মেলবক্স ঠিকানা | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +Calldata বলতে লেনদেনের অংশ হিসেবে পাঠানো বাইটগুলিকে বোঝায়। এটি ব্লকচেইনের স্থায়ী রেকর্ডের অংশ হিসাবে সেই ব্লকে সংরক্ষণ করা হয় যা সেই লেনদেনটি অন্তর্ভুক্ত করে। + +ব্লকচেইনে স্থায়ীভাবে ডেটা রাখার জন্য এটি সবচেয়ে সস্তা পদ্ধতি। প্রতি বাইটের খরচ হয় 4 এক্সিকিউশন গ্যাস (যদি বাইটটি শূন্য হয়) অথবা 16 গ্যাস (অন্য কোনো মান)। যদি ডেটা সংকুচিত করা হয়, যা একটি মানসম্মত অনুশীলন, তাহলে প্রতিটি বাইট মানের সমান সম্ভাবনা থাকে, তাই গড় খরচ প্রতি বাইটে প্রায় 15.95 গ্যাস। + +লেখার সময়, দাম 12 gwei/গ্যাস এবং 2300 $/ETH, যার মানে প্রতি কিলোবাইটে খরচ প্রায় 45 সেন্ট। যেহেতু EIP-4844 এর আগে এটি সবচেয়ে সস্তা পদ্ধতি ছিল, তাই রোলআপগুলি এই পদ্ধতিটি লেনদেনের তথ্য সঞ্চয় করতে ব্যবহার করত, যা [ফল্ট চ্যালেঞ্জের](https://docs.optimism.io/stack/protocol/overview#fault-proofs) জন্য উপলব্ধ থাকা প্রয়োজন, কিন্তু সরাসরি অনচেইনে অ্যাক্সেসযোগ্য হওয়ার প্রয়োজন নেই। + +এখানে কিছু বিখ্যাত রোলআপ দ্বারা পোস্ট করা লেনদেনগুলি দেখার জন্য ঠিকানা দেওয়া হলো। + +| রোলআপ | মেলবক্স ঠিকানা | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## L1 মেকানিজম সহ অফচেইন {#offchain-with-l1-mechs} + +আপনার নিরাপত্তা ট্রেডঅফের উপর নির্ভর করে, তথ্য অন্য কোথাও রাখা এবং প্রয়োজনে ডেটা উপলব্ধতা নিশ্চিত করে এমন একটি মেকানিজম ব্যবহার করা গ্রহণযোগ্য হতে পারে। এটি কাজ করার জন্য দুটি প্রয়োজনীয়তা রয়েছে: + +1. ব্লকচেইনে ডেটার একটি [হ্যাস](https://en.wikipedia.org/wiki/Cryptographic_hash_function) পোস্ট করুন, যাকে _ইনপুট কমিটমেন্ট_ বলা হয়। এটি একটি একক 32-বাইট শব্দ হতে পারে, তাই এটি ব্যয়বহুল নয়। যতক্ষণ ইনপুট কমিটমেন্ট উপলব্ধ থাকে, ততক্ষণ অখণ্ডতা নিশ্চিত, কারণ একই মানে হ্যাস হবে এমন অন্য কোনো ডেটা খুঁজে পাওয়া সম্ভব নয়। সুতরাং যদি ভুল ডেটা প্রদান করা হয়, তা সনাক্ত করা যেতে পারে। + +2. এমন একটি মেকানিজম রাখুন যা প্রাপ্যতা নিশ্চিত করে। উদাহরণস্বরূপ, [Redstone](https://redstone.xyz/docs/what-is-redstone)-এ যেকোনো নোড একটি প্রাপ্যতা চ্যালেঞ্জ জমা দিতে পারে। যদি সিকোয়েন্সার সময়সীমার মধ্যে অনচেইনে প্রতিক্রিয়া না জানায়, তবে ইনপুট কমিটমেন্টটি বাতিল করা হয়, তাই তথ্যটি কখনও পোস্ট করা হয়নি বলে মনে করা হয়। + +এটি একটি অপ্টিমেস্টিক রোলআপের জন্য গ্রহণযোগ্য কারণ আমরা ইতিমধ্যেই স্টেট রুটের জন্য অন্তত একজন সৎ যাচাইকারীর উপর নির্ভর করছি। এমন একজন সৎ যাচাইকারী এটিও নিশ্চিত করবে যে ব্লক প্রক্রিয়া করার জন্য তার কাছে ডেটা আছে, এবং যদি তথ্য অফচেইনে উপলব্ধ না থাকে তবে একটি প্রাপ্যতা চ্যালেঞ্জ জারি করবে। এই ধরনের অপ্টিমেস্টিক রোলআপকে [প্লাসমা](/developers/docs/scaling/plasma/) বলা হয়। + +## কন্ট্র্যাক্ট কোড {#contract-code} + +যে তথ্য কেবল একবার লিখতে হবে, কখনও ওভাররাইট হবে না এবং অনচেইনে উপলব্ধ থাকা প্রয়োজন, তা কন্ট্র্যাক্ট কোড হিসাবে সংরক্ষণ করা যেতে পারে। এর মানে হলো আমরা ডেটা দিয়ে একটি "স্মার্ট কন্ট্র্যাক্ট" তৈরি করি এবং তারপর তথ্য পড়ার জন্য [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) ব্যবহার করি। সুবিধা হলো কোড কপি করা তুলনামূলকভাবে সস্তা। + +মেমরি সম্প্রসারণের খরচ ছাড়াও, `EXTCODECOPY`-তে একটি কন্ট্র্যাক্টে প্রথম অ্যাক্সেসের জন্য 2600 গ্যাস খরচ হয় (যখন এটি "কোল্ড" থাকে) এবং একই কন্ট্র্যাক্ট থেকে পরবর্তী কপিগুলির জন্য 100 গ্যাস এবং প্রতি 32 বাইট শব্দের জন্য 3 গ্যাস খরচ হয়। calldata-এর তুলনায়, যার খরচ প্রতি বাইটে 15.95, এটি প্রায় 200 বাইট থেকে শুরু করে সস্তা। [মেমরি সম্প্রসারণ খরচের সূত্র](https://www.evm.codes/about#memoryexpansion) অনুসারে, যতক্ষণ আপনার 4MB-এর বেশি মেমরির প্রয়োজন না হয়, ততক্ষণ মেমরি সম্প্রসারণ খরচ calldata যোগ করার খরচের চেয়ে কম। + +অবশ্যই, এটি কেবল ডেটা _পড়ার_ খরচ। কন্ট্র্যাক্ট তৈরি করতে প্রায় 32,000 গ্যাস + 200 গ্যাস/বাইট খরচ হয়। এই পদ্ধতিটি তখনই সাশ্রয়ী হয় যখন একই তথ্য বিভিন্ন লেনদেনে অনেকবার পড়ার প্রয়োজন হয়। + +কন্ট্র্যাক্ট কোড অর্থহীন হতে পারে, যতক্ষণ না এটি `0xEF` দিয়ে শুরু হয়। `0xEF` দিয়ে শুরু হওয়া কন্ট্র্যাক্টগুলিকে [ইথেরিয়াম অবজেক্ট ফরম্যাট](https://notes.ethereum.org/@ipsilon/evm-object-format-overview) হিসাবে ব্যাখ্যা করা হয়, যার অনেক কঠোর প্রয়োজনীয়তা রয়েছে। + +## ইভেন্ট {#events} + +[ইভেন্টগুলি](https://docs.alchemy.com/docs/solidity-events) স্মার্ট কন্ট্র্যাক্ট দ্বারা নির্গত হয় এবং অফচেইন সফ্টওয়্যার দ্বারা পড়া হয়। +তাদের সুবিধা হল অফচেইন কোড ইভেন্ট শুনতে পারে। খরচ হল [গ্যাস](https://www.evm.codes/#a0?fork=cancun), 375 প্লাস প্রতি বাইট ডেটার জন্য 8 গ্যাস। 12 gwei/গ্যাস এবং 2300 $/ETH-এ, এর অর্থ এক সেন্ট প্লাস প্রতি কিলোবাইটে 22 সেন্ট। + +## সংগ্রহস্থল {#storage} + +স্মার্ট কন্ট্র্যাক্টগুলির [স্থায়ী সংগ্রহস্থলে](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) অ্যাক্সেস আছে। তবে এটি খুব ব্যয়বহুল। আগে থেকে খালি একটি সংগ্রহস্থল স্লটে একটি 32 বাইট শব্দ লেখার জন্য [22,100 গ্যাস খরচ](https://www.evm.codes/#55?fork=cancun) হতে পারে। 12 gwei/গ্যাস এবং 2300 $/ETH-এ, এটি প্রতি লেখার অপারেশনে প্রায় 61 সেন্ট, অথবা প্রতি কিলোবাইটে $19.5। + +এটি ইথেরিয়ামের সবচেয়ে ব্যয়বহুল সংগ্রহস্থলের রূপ। + +## সারসংক্ষেপ {#summary} + +এই টেবিলটি বিভিন্ন বিকল্প, তাদের সুবিধা এবং অসুবিধাগুলির সারসংক্ষেপ করে। + +| সংগ্রহস্থলের প্রকার | ডেটার উৎস | প্রাপ্যতা গ্যারান্টি | অনচেইন প্রাপ্যতা | অতিরিক্ত সীমাবদ্ধতা | +| --------------------- | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------- | +| EIP-4844 blobs | অফচেইন | [~18 দিনের](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) জন্য ইথেরিয়াম গ্যারান্টি | শুধু হ্যাস উপলব্ধ | | +| Calldata | অফচেইন | ইথেরিয়াম চিরকালের জন্য গ্যারান্টি (ব্লকচেইনের অংশ) | শুধুমাত্র একটি কন্ট্র্যাক্টে লেখা হলে এবং সেই লেনদেনে উপলব্ধ | | +| L1 মেকানিজম সহ অফচেইন | অফচেইন | চ্যালেঞ্জ পিরিয়ডের সময় "একজন সৎ যাচাইকারী" গ্যারান্টি | শুধুমাত্র হ্যাস | চ্যালেঞ্জ মেকানিজম দ্বারা গ্যারান্টিযুক্ত, শুধুমাত্র চ্যালেঞ্জ পিরিয়ডের সময় | +| কন্ট্র্যাক্ট কোড | অনচেইন বা অফচেইন | ইথেরিয়াম চিরকালের জন্য গ্যারান্টি (ব্লকচেইনের অংশ) | হ্যাঁ | একটি "র‍্যান্ডম" ঠিকানায় লেখা, `0xEF` দিয়ে শুরু হতে পারে না | +| অনুষ্ঠানসমূহ | অনচেইন | ইথেরিয়াম চিরকালের জন্য গ্যারান্টি (ব্লকচেইনের অংশ) | না | | +| সংগ্রহস্থল | অনচেইন | ইথেরিয়াম চিরকালের জন্য গ্যারান্টি (ব্লকচেইনের অংশ এবং ওভাররাইট না হওয়া পর্যন্ত বর্তমান অবস্থা) | হ্যাঁ | | diff --git a/public/content/translations/bn/developers/docs/data-availability/index.md b/public/content/translations/bn/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..7511736d5f6 --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "ডেটা উপলব্ধতা" +description: "Ethereum-এ ডেটা উপলব্ধতা সম্পর্কিত সমস্যা এবং সমাধানের একটি সংক্ষিপ্ত বিবরণ" +lang: bn +--- + +"বিশ্বাস করবেন না, যাচাই করুন" Ethereum-এর একটি সাধারণ নীতি। ধারণাটি হল যে আপনার নোড স্বাধীনভাবে যাচাই করতে পারে যে এটি যে তথ্য গ্রহণ করে তা সঠিক কিনা। এটি তারা তাদের সহকর্মীদের থেকে প্রাপ্ত ব্লকগুলিতে থাকা সমস্ত লেনদেন সম্পাদন করে করে থাকে, যাতে প্রস্তাবিত পরিবর্তনগুলি নোড দ্বারা স্বাধীনভাবে গণনা করা পরিবর্তনগুলির সাথে হুবহু মিলে যায়। এর মানে হল যে নোডগুলিকে বিশ্বাস করতে হবে না যে ব্লকের প্রেরকরা সৎ। ডেটা অনুপস্থিত থাকলে এটি সম্ভব নয়। + +**ডেটা উপলব্ধতা** বলতে বোঝায় একজন ব্যবহারকারীর সেই আত্মবিশ্বাস যে একটি ব্লক যাচাই করার জন্য প্রয়োজনীয় ডেটা সত্যিই সমস্ত নেটওয়ার্ক অংশগ্রহণকারীদের জন্য উপলব্ধ রয়েছে। Ethereum লেয়ার 1-এর সম্পূর্ণ নোডগুলির জন্য এটি তুলনামূলকভাবে সহজ; সম্পূর্ণ নোড প্রতিটি ব্লকের সমস্ত ডেটার একটি অনুলিপি ডাউনলোড করে - ডাউনলোডের জন্য ডেটা অবশ্যই উপলব্ধ থাকতে হবে। অনুপস্থিত ডেটা সহ একটি ব্লককে ব্লকচেইনে যোগ না করে বাতিল করে দেওয়া হবে। এটি হল "অনচেইন ডেটা উপলব্ধতা" এবং এটি মনোলিথিক ব্লকচেইনের একটি বৈশিষ্ট্য। সম্পূর্ণ নোডগুলিকে অবৈধ লেনদেন গ্রহণ করার জন্য প্রতারিত করা যায় না কারণ তারা নিজেদের জন্য প্রতিটি লেনদেন ডাউনলোড এবং সম্পাদন করে। যাইহোক, মডুলার ব্লকচেইন, লেয়ার 2 রোলআপ এবং লাইট ক্লায়েন্টদের জন্য, ডেটা উপলব্ধতার প্রেক্ষাপট আরও জটিল, যার জন্য কিছু আরও পরিশীলিত যাচাইকরণ পদ্ধতির প্রয়োজন। + +## পূর্বশর্ত {#prerequisites} + +আপনার [ব্লকচেইনের মৌলিক বিষয়গুলি](/developers/docs/intro-to-ethereum/)-এর উপর একটি ভালো ধারণা থাকা উচিত, বিশেষ করে [কনসেন্সাস মেকানিজম](/developers/docs/consensus-mechanisms/)-এর উপর। এই পৃষ্ঠাটি আরও অনুমান করে যে পাঠক [ব্লক](/developers/docs/blocks/), [লেনদেন](/developers/docs/transactions/), [নোড](/developers/docs/nodes-and-clients/), [স্কেলিং সমাধান](/developers/docs/scaling/), এবং অন্যান্য প্রাসঙ্গিক বিষয়গুলির সাথে পরিচিত। + +## ডেটা উপলব্ধতার সমস্যা {#the-data-availability-problem} + +ডেটা উপলব্ধতার সমস্যা হলো সমগ্র নেটওয়ার্ককে প্রমাণ করার প্রয়োজন যে কিছু লেনদেনের ডেটার সংক্ষিপ্ত রূপ যা ব্লকচেইনে যোগ করা হচ্ছে তা সত্যিই বৈধ লেনদেনের একটি সেটকে প্রতিনিধিত্ব করে, কিন্তু সমস্ত নোডকে সমস্ত ডেটা ডাউনলোড করার প্রয়োজন ছাড়াই এটি করা। স্বাধীনভাবে ব্লক যাচাই করার জন্য সম্পূর্ণ লেনদেনের ডেটা প্রয়োজনীয়, কিন্তু সমস্ত নোডকে সমস্ত লেনদেনের ডেটা ডাউনলোড করতে বাধ্য করা স্কেলিংয়ের জন্য একটি বাধা। ডেটা উপলব্ধতার সমস্যার সমাধানগুলি সেই নেটওয়ার্ক অংশগ্রহণকারীদের জন্য যথেষ্ট আশ্বাস প্রদানের লক্ষ্যে করা হয় যারা নিজেদের জন্য ডেটা ডাউনলোড এবং সংরক্ষণ করে না, যাতে যাচাইয়ের জন্য সম্পূর্ণ লেনদেনের ডেটা উপলব্ধ করা হয়েছিল। + +[লাইট নোড](/developers/docs/nodes-and-clients/light-clients) এবং [লেয়ার 2 রোলআপ](/developers/docs/scaling) হলো নেটওয়ার্ক অংশগ্রহণকারীদের গুরুত্বপূর্ণ উদাহরণ যাদের শক্তিশালী ডেটা উপলব্ধতার আশ্বাস প্রয়োজন কিন্তু তারা নিজেদের জন্য লেনদেনের ডেটা ডাউনলোড এবং প্রক্রিয়া করতে পারে না। লেনদেনের ডেটা ডাউনলোড করা এড়ানোই লাইট নোডগুলিকে হালকা করে তোলে এবং রোলআপগুলিকে কার্যকর স্কেলিং সমাধান হতে সক্ষম করে। + +ভবিষ্যতের ["স্টেটলেস"](/roadmap/statelessness) Ethereum ক্লায়েন্টদের জন্য ডেটা উপলব্ধতা একটি গুরুত্বপূর্ণ উদ্বেগের বিষয়, যাদের ব্লক যাচাই করার জন্য স্টেট ডেটা ডাউনলোড এবং সংরক্ষণ করার প্রয়োজন হয় না। স্টেটলেস ক্লায়েন্টদের এখনও নিশ্চিত হতে হবে যে ডেটা _কোথাও_ উপলব্ধ আছে এবং এটি সঠিকভাবে প্রক্রিয়া করা হয়েছে। + +## ডেটা উপলব্ধতার সমাধান {#data-availability-solutions} + +### ডেটা উপলব্ধতা স্যাম্পলিং (DAS) {#data-availability-sampling} + +ডেটা উপলব্ধতা স্যাম্পলিং (DAS) হল নেটওয়ার্কের জন্য ডেটা উপলব্ধ কিনা তা পরীক্ষা করার একটি উপায়, যা কোনো একক নোডের উপর খুব বেশি চাপ সৃষ্টি করে না। প্রতিটি নোড (নন-স্টেকিং নোড সহ) মোট ডেটার কিছু ছোট, এলোমেলোভাবে নির্বাচিত উপসেট ডাউনলোড করে। নমুনাগুলি সফলভাবে ডাউনলোড করা উচ্চ আত্মবিশ্বাসের সাথে নিশ্চিত করে যে সমস্ত ডেটা উপলব্ধ রয়েছে। এটি ডেটা ইরেজার কোডিং-এর উপর নির্ভর করে, যা একটি প্রদত্ত ডেটাসেটকে রিডান্ড্যান্ট তথ্য দিয়ে প্রসারিত করে (এটি করার উপায় হলো ডেটার উপর একটি _পলিনোমিয়াল_ নামে পরিচিত একটি ফাংশন ফিট করা এবং অতিরিক্ত পয়েন্টে সেই পলিনোমিয়ালটিকে মূল্যায়ন করা)। এটি প্রয়োজনে রিডান্ড্যান্ট ডেটা থেকে মূল ডেটা পুনরুদ্ধার করতে দেয়। এই ডেটা তৈরির একটি পরিণতি হলো যদি মূল ডেটার _কোনো_ অংশ অনুপলব্ধ থাকে, তাহলে প্রসারিত ডেটার _অর্ধেক_ অনুপস্থিত থাকবে! প্রতিটি নোড দ্বারা ডাউনলোড করা ডেটা নমুনার পরিমাণ এমনভাবে টিউন করা যেতে পারে যাতে এটি _অত্যন্ত_ সম্ভাব্য যে প্রতিটি ক্লায়েন্ট দ্বারা নমুনা করা ডেটা খণ্ডগুলির মধ্যে অন্তত একটি অনুপস্থিত থাকবে _যদি_ অর্ধেকের কম ডেটা সত্যিই উপলব্ধ থাকে। + +[Full Danksharding](/roadmap/danksharding/#what-is-danksharding) বাস্তবায়িত হওয়ার পরে রোলআপ অপারেটররা যাতে তাদের লেনদেনের ডেটা উপলব্ধ করে তা নিশ্চিত করতে DAS ব্যবহার করা হবে। Ethereum নোডগুলি ব্লব-এ প্রদত্ত লেনদেনের ডেটার এলোমেলোভাবে নমুনা নেবে, উপরে ব্যাখ্যা করা রিডান্ডান্সি স্কিম ব্যবহার করে, যাতে নিশ্চিত করা যায় যে সমস্ত ডেটা বিদ্যমান রয়েছে। একই কৌশলটি ব্লক প্রযোজকরা তাদের সমস্ত ডেটা সুরক্ষিত লাইট ক্লায়েন্টদের জন্য উপলব্ধ করছে কিনা তা নিশ্চিত করতেও ব্যবহার করা যেতে পারে। একইভাবে, [প্রস্তাবক-নির্মাতা বিচ্ছেদ](/roadmap/pbs)-এর অধীনে, শুধুমাত্র ব্লক নির্মাতাকে একটি সম্পূর্ণ ব্লক প্রক্রিয়া করতে হবে - অন্যান্য যাচাইকারীরা ডেটা উপলব্ধতা স্যাম্পলিং ব্যবহার করে যাচাই করবে। + +### ডেটা উপলব্ধতা কমিটি {#data-availability-committees} + +ডেটা উপলব্ধতা কমিটি (DACs) হল বিশ্বস্ত পক্ষ যারা ডেটা উপলব্ধতা প্রদান করে, বা তার প্রমাণ দেয়। DAC গুলি DAS-এর পরিবর্তে, [বা এর সাথে একত্রে](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) ব্যবহার করা যেতে পারে। কমিটির সাথে আসা নিরাপত্তা নিশ্চয়তা নির্দিষ্ট সেট আপের উপর নির্ভর করে। উদাহরণস্বরূপ, Ethereum লাইট নোডগুলির জন্য ডেটা উপলব্ধতার প্রমাণ দেওয়ার জন্য যাচাইকারীদের এলোমেলোভাবে নমুনা করা উপসেট ব্যবহার করে। + +কিছু ভ্যালিডিয়াম দ্বারা DACs ব্যবহার করা হয়। DAC হল একটি বিশ্বস্ত নোড সেট যা অফলাইনে ডেটার অনুলিপি সংরক্ষণ করে। বিবাদের ক্ষেত্রে DAC-কে ডেটা উপলব্ধ করতে হয়। DAC-এর সদস্যরা অনচেইন অ্যাটেস্টেশনও প্রকাশ করে প্রমাণ করার জন্য যে উক্ত ডেটা সত্যিই উপলব্ধ। কিছু ভ্যালিডিয়াম DAC-কে একটি প্রুফ-অফ-স্টেক (PoS) যাচাইকারী সিস্টেম দিয়ে প্রতিস্থাপন করে। এখানে, যে কেউ একজন যাচাইকারী হতে পারে এবং অফলাইনে ডেটা সংরক্ষণ করতে পারে। তবে, তাদের একটি "বন্ড" প্রদান করতে হবে, যা একটি স্মার্ট কন্ট্র্যাক্টে জমা করা হয়। বিদ্বেষপূর্ণ আচরণের ক্ষেত্রে, যেমন যাচাইকারীর ডেটা আটকে রাখা, বন্ডটি স্ল্যাশ করা যেতে পারে। প্রুফ-অফ-স্টেক ডেটা উপলব্ধতা কমিটিগুলি নিয়মিত DAC-এর চেয়ে যথেষ্ট বেশি সুরক্ষিত কারণ তারা সরাসরি সৎ আচরণকে উৎসাহিত করে। + +## ডেটা উপলব্ধতা এবং লাইট নোড {#data-availability-and-light-nodes} + +[লাইট নোড](/developers/docs/nodes-and-clients/light-clients)-কে ব্লক ডেটা ডাউনলোড না করেই তাদের প্রাপ্ত ব্লক হেডারগুলির সঠিকতা যাচাই করতে হবে। এই হালকাতার মূল্য হলো সম্পূর্ণ নোডগুলির মতো স্থানীয়ভাবে লেনদেন পুনরায় সম্পাদন করে ব্লক হেডারগুলি স্বাধীনভাবে যাচাই করতে না পারা। + +Ethereum লাইট নোডগুলি 512 জন যাচাইকারীর এলোমেলো সেটের উপর বিশ্বাস করে যাদের একটি _সিঙ্ক কমিটি_-তে নিয়োগ করা হয়েছে। সিঙ্ক কমিটি একটি DAC হিসাবে কাজ করে যা লাইট ক্লায়েন্টদের একটি ক্রিপ্টোগ্রাফিক স্বাক্ষরের মাধ্যমে সংকেত দেয় যে হেডারের ডেটা সঠিক। প্রতিদিন, সিঙ্ক কমিটি রিফ্রেশ হয়। প্রতিটি ব্লক হেডার লাইট নোডগুলিকে সতর্ক করে যে কোন যাচাইকারীরা _পরবর্তী_ ব্লকে স্বাক্ষর করবে বলে আশা করা যায়, তাই তারা আসল সিঙ্ক-কমিটি হিসাবে ভান করা কোনো বিদ্বেষপূর্ণ গোষ্ঠীর উপর বিশ্বাস করতে প্রতারিত হতে পারে না। + +কিন্তু, যদি কোনো আক্রমণকারী কোনোভাবে লাইট ক্লায়েন্টদের কাছে একটি বিদ্বেষপূর্ণ ব্লক হেডার পাঠাতে এবং তাদের বোঝাতে সক্ষম হয় যে এটি একটি সৎ সিঙ্ক-কমিটি দ্বারা স্বাক্ষরিত হয়েছে, তাহলে কী হবে? সেক্ষেত্রে, আক্রমণকারী অবৈধ লেনদেন অন্তর্ভুক্ত করতে পারে এবং লাইট ক্লায়েন্ট অন্ধভাবে সেগুলি গ্রহণ করবে, কারণ তারা ব্লক হেডারে সংক্ষিপ্ত করা সমস্ত স্টেট পরিবর্তনগুলি স্বাধীনভাবে পরীক্ষা করে না। এর থেকে রক্ষা পেতে, লাইট ক্লায়েন্ট জালিয়াতির প্রমাণ (fraud proofs) ব্যবহার করতে পারে। + +এই জালিয়াতির প্রমাণগুলি যেভাবে কাজ করে তা হলো, একটি সম্পূর্ণ নোড, নেটওয়ার্কে একটি অবৈধ স্টেট ট্রানজিশন দেখতে পেয়ে, দ্রুত একটি ছোট ডেটা তৈরি করতে পারে যা প্রমাণ করে যে একটি প্রস্তাবিত স্টেট ট্রানজিশন একটি প্রদত্ত লেনদেনের সেট থেকে সম্ভব নয় এবং সেই ডেটা পিয়ারদের কাছে সম্প্রচার করতে পারে। লাইট নোডগুলি সেই জালিয়াতির প্রমাণগুলি তুলে নিতে পারে এবং খারাপ ব্লক হেডারগুলি বাতিল করতে ব্যবহার করতে পারে, যা নিশ্চিত করে যে তারা সম্পূর্ণ নোডগুলির মতো একই সৎ চেইনে থাকে। + +এটি সম্পূর্ণ নোডগুলির সম্পূর্ণ লেনদেনের ডেটাতে অ্যাক্সেসের উপর নির্ভর করে। একজন আক্রমণকারী যে একটি খারাপ ব্লক হেডার সম্প্রচার করে এবং লেনদেনের ডেটা উপলব্ধ করতে ব্যর্থ হয়, সে সম্পূর্ণ নোডগুলিকে জালিয়াতির প্রমাণ তৈরি করতে বাধা দিতে সক্ষম হবে। সম্পূর্ণ নোডগুলি হয়তো একটি খারাপ ব্লক সম্পর্কে একটি সতর্কতা সংকেত দিতে পারে, কিন্তু তারা তাদের সতর্কতাকে প্রমাণ দিয়ে সমর্থন করতে পারবে না, কারণ প্রমাণ তৈরি করার জন্য ডেটা উপলব্ধ করা হয়নি! + +এই ডেটা উপলব্ধতার সমস্যার সমাধান হল DAS। লাইট নোডগুলি সম্পূর্ণ স্টেট ডেটার খুব ছোট এলোমেলো খণ্ড ডাউনলোড করে এবং সম্পূর্ণ ডেটা সেট উপলব্ধ কিনা তা যাচাই করতে নমুনাগুলি ব্যবহার করে। Nটি এলোমেলো খণ্ড ডাউনলোড করার পরে ভুলভাবে সম্পূর্ণ ডেটা উপলব্ধতা অনুমান করার প্রকৃত সম্ভাবনা গণনা করা যেতে পারে ([100টি খণ্ডের জন্য সম্ভাবনা হল 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), অর্থাৎ, অবিশ্বাস্যভাবে অসম্ভাব্য)। + +এমনকি এই পরিস্থিতিতেও, মাত্র কয়েকটি বাইট আটকে রাখা আক্রমণগুলি এলোমেলো ডেটা অনুরোধকারী ক্লায়েন্টদের দ্বারা অলক্ষিত থেকে যেতে পারে। ইরেজার কোডিং ডেটার ছোট অনুপস্থিত অংশগুলি পুনর্গঠন করে এটি ঠিক করে, যা প্রস্তাবিত স্টেট পরিবর্তনগুলি পরীক্ষা করতে ব্যবহার করা যেতে পারে। পুনর্গঠিত ডেটা ব্যবহার করে একটি জালিয়াতির প্রমাণ তৈরি করা যেতে পারে, যা লাইট নোডগুলিকে খারাপ হেডার গ্রহণ করা থেকে বিরত রাখে। + +**দ্রষ্টব্য:** প্রুফ-অফ-স্টেক Ethereum লাইট ক্লায়েন্টদের জন্য DAS এবং জালিয়াতির প্রমাণ এখনও বাস্তবায়িত হয়নি, তবে সেগুলি রোডম্যাপে রয়েছে, যা সম্ভবত ZK-SNARK ভিত্তিক প্রমাণের রূপ নেবে। আজকের লাইট ক্লায়েন্টরা এক ধরনের DAC-এর উপর নির্ভর করে: তারা সিঙ্ক-কমিটির পরিচয় যাচাই করে এবং তারপর তাদের প্রাপ্ত স্বাক্ষরিত ব্লক হেডারগুলিতে বিশ্বাস করে। + +## ডেটা উপলব্ধতা এবং লেয়ার 2 রোলআপ {#data-availability-and-layer-2-rollups} + +[লেয়ার 2 স্কেলিং সমাধান](/layer-2/), যেমন [রোলআপ](/glossary/#rollups), অফলাইনে লেনদেন প্রক্রিয়া করে লেনদেনের খরচ কমায় এবং Ethereum-এর থ্রুপুট বাড়ায়। রোলআপ লেনদেনগুলি সংকুচিত করা হয় এবং ব্যাচ আকারে Ethereum-এ পোস্ট করা হয়। ব্যাচগুলি Ethereum-এ একটি একক লেনদেনে হাজার হাজার স্বতন্ত্র অফচেইন লেনদেনকে প্রতিনিধিত্ব করে। এটি বেস লেয়ারের যানজট কমায় এবং ব্যবহারকারীদের জন্য ফি কমায়। + +তবে, Ethereum-এ পোস্ট করা 'সারাংশ' লেনদেনগুলিতে কেবল তখনই বিশ্বাস করা সম্ভব যদি প্রস্তাবিত স্টেট পরিবর্তন স্বাধীনভাবে যাচাই করা যায় এবং নিশ্চিত করা যায় যে এটি সমস্ত স্বতন্ত্র অফচেইন লেনদেন প্রয়োগের ফল। যদি রোলআপ অপারেটররা এই যাচাইয়ের জন্য লেনদেনের ডেটা উপলব্ধ না করে, তাহলে তারা Ethereum-এ ভুল ডেটা পাঠাতে পারে। + +[অপ্টিমেস্টিক রোলআপ](/developers/docs/scaling/optimistic-rollups/) সংকুচিত লেনদেনের ডেটা Ethereum-এ পোস্ট করে এবং কিছু সময়ের জন্য (সাধারণত 7 দিন) অপেক্ষা করে যাতে স্বাধীন যাচাইকারীরা ডেটা পরীক্ষা করতে পারে। যদি কেউ কোনো সমস্যা শনাক্ত করে, তারা একটি জালিয়াতির প্রমাণ তৈরি করতে পারে এবং রোলআপকে চ্যালেঞ্জ করতে এটি ব্যবহার করতে পারে। এটি চেইনটিকে রোল ব্যাক করতে এবং অবৈধ ব্লকটি বাদ দিতে বাধ্য করবে। ডেটা উপলব্ধ থাকলেই কেবল এটি সম্ভব। বর্তমানে, দুটি উপায়ে অপ্টিমেস্টিক রোলআপগুলি L1-এ লেনদেনের ডেটা পোস্ট করে। কিছু রোলআপ `CALLDATA` হিসাবে ডেটা স্থায়ীভাবে উপলব্ধ করে, যা স্থায়ীভাবে অনচেইনে থাকে। EIP-4844 বাস্তবায়নের সাথে, কিছু রোলআপ তাদের লেনদেনের ডেটা পরিবর্তে সস্তা ব্লব স্টোরেজে পোস্ট করে। এটি স্থায়ী সংগ্রহস্থল নয়। স্বাধীন যাচাইকারীদের ~18 দিনের মধ্যে ব্লবগুলি জিজ্ঞাসা করতে হবে এবং তাদের চ্যালেঞ্জ উত্থাপন করতে হবে, এরপরে ডেটা Ethereum লেয়ার-1 থেকে মুছে ফেলা হবে। সেই স্বল্প নির্দিষ্ট সময়ের জন্য শুধুমাত্র Ethereum প্রোটোকল দ্বারা ডেটা উপলব্ধতার নিশ্চয়তা দেওয়া হয়। এর পরে, এটি Ethereum ইকোসিস্টেমের অন্যান্য সত্তার দায়িত্ব হয়ে যায়। যেকোনো নোড DAS ব্যবহার করে ডেটা উপলব্ধতা যাচাই করতে পারে, অর্থাৎ, ব্লব ডেটার ছোট, এলোমেলো নমুনা ডাউনলোড করে। + +[জিরো-নলেজ (ZK) রোলআপ](/developers/docs/scaling/zk-rollups)-এর লেনদেনের ডেটা পোস্ট করার প্রয়োজন নেই কারণ [জিরো-নলেজ ভ্যালিডিটি প্রুফ](/glossary/#zk-proof) স্টেট ট্রানজিশনের সঠিকতার নিশ্চয়তা দেয়। তবে, ডেটা উপলব্ধতা এখনও একটি সমস্যা কারণ আমরা এর স্টেট ডেটাতে অ্যাক্সেস ছাড়া ZK-রোলআপের কার্যকারিতা (বা এর সাথে ইন্টারঅ্যাক্ট করা) নিশ্চিত করতে পারি না। উদাহরণস্বরূপ, যদি একজন অপারেটর রোলআপের স্টেট সম্পর্কে বিশদ বিবরণ আটকে রাখে তবে ব্যবহারকারীরা তাদের ব্যালেন্স জানতে পারে না। এছাড়াও, তারা নতুন যোগ করা ব্লকে থাকা তথ্য ব্যবহার করে স্টেট আপডেট করতে পারে না। + +## ডেটা উপলব্ধতা বনাম ডেটা পুনরুদ্ধারযোগ্যতা {#data-availability-vs-data-retrievability} + +ডেটা উপলব্ধতা ডেটা পুনরুদ্ধারযোগ্যতা থেকে ভিন্ন। ডেটা উপলব্ধতা হল এই আশ্বাস যে সম্পূর্ণ নোডগুলি একটি নির্দিষ্ট ব্লকের সাথে সম্পর্কিত লেনদেনের সম্পূর্ণ সেট অ্যাক্সেস এবং যাচাই করতে সক্ষম হয়েছে। এর মানে এই নয় যে ডেটা চিরকালের জন্য অ্যাক্সেসযোগ্য। + +ডেটা পুনরুদ্ধারযোগ্যতা হল ব্লকচেইন থেকে _ঐতিহাসিক তথ্য_ পুনরুদ্ধার করার জন্য নোডগুলির ক্ষমতা। এই ঐতিহাসিক ডেটা নতুন ব্লক যাচাই করার জন্য প্রয়োজন হয় না, এটি শুধুমাত্র জেনেসিস ব্লক থেকে সম্পূর্ণ নোড সিঙ্ক করার জন্য বা নির্দিষ্ট ঐতিহাসিক অনুরোধ পরিবেশন করার জন্য প্রয়োজন। + +মূল Ethereum প্রোটোকল মূলত ডেটা উপলব্ধতা নিয়ে চিন্তিত, ডেটা পুনরুদ্ধারযোগ্যতা নিয়ে নয়। ডেটা পুনরুদ্ধারযোগ্যতা তৃতীয় পক্ষ দ্বারা চালিত আর্কাইভ নোডগুলির একটি ছোট জনসংখ্যা দ্বারা সরবরাহ করা যেতে পারে, অথবা এটি [পোর্টাল নেটওয়ার্ক](https://www.ethportal.net/)-এর মতো বিকেন্দ্রীভূত ফাইল স্টোরেজ ব্যবহার করে নেটওয়ার্ক জুড়ে বিতরণ করা যেতে পারে। + +## আরও পড়ুন {#further-reading} + +- [ডেটা উপলব্ধতা কী?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [ডেটা উপলব্ধতা কী?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [ডেটা উপলব্ধতা চেকের উপর একটি প্রাইমার](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [শার্ডিং + DAS প্রস্তাবের একটি ব্যাখ্যা](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [ডেটা উপলব্ধতা এবং ইরেজার কোডিং-এর উপর একটি নোট](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [ডেটা উপলব্ধতা কমিটি।](https://medium.com/starkware/data-availability-e5564c416424) +- [প্রুফ-অফ-স্টেক ডেটা উপলব্ধতা কমিটি।](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [ডেটা পুনরুদ্ধারযোগ্যতা সমস্যার সমাধান](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [ডেটা উপলব্ধতা অথবা: কীভাবে রোলআপগুলি চিন্তা করা বন্ধ করতে এবং Ethereum-কে ভালোবাসতে শিখেছে](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: কলডেটার খরচ বৃদ্ধি](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/bn/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/bn/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..f4b2bbfd489 --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "ডেটা স্ট্রাকচার এবং এনকোডিং" +description: "সাধারণ ভাবে ইথেরিয়াম ডাটা স্ট্রাটার ধারণা." +lang: bn +sidebarDepth: 2 +--- + +ইথেরিয়াম তৈরির রহস্য, এটি কিভাবে সংরক্ষণ এবং বড় করে তথ্য স্থানান্তর করে. এই ডেটা অবশ্যই এমন মানসম্মত এবং মেমরি-দক্ষ উপায়ে ফর্ম্যাট করা উচিত যাতে যে কেউ অপেক্ষাকৃত সাধারণ কনজিউমার-গ্রেড হার্ডওয়্যারে একটি [নোড চালাতে](/run-a-node/) পারে। এটি অর্জন করার জন্য, Ethereum স্ট্যাকের উপর বেশ কয়েকটি নির্দিষ্ট ডেটা স্ট্রাকচার ব্যবহার করা হয়। + +## পূর্বশর্ত {#prerequisites} + +আপনার Ethereum এবং [ক্লায়েন্ট সফটওয়্যার](/developers/docs/nodes-and-clients/) এর মূল বিষয়গুলি বোঝা উচিত। নেটওয়ার্কিং লেয়ার এবং [Ethereum হোয়াইটপেপার](/whitepaper/) সম্পর্কে পরিচিতি থাকা বাঞ্ছনীয়। + +## ডেটা স্ট্রাকচার {#data-structures} + +### প্যাট্রিসিয়া মার্কল ট্রাই {#patricia-merkle-tries} + +প্যাট্রিসিয়া মার্কল ট্রাই হলো এমন স্ট্রাকচার যা কী-ভ্যালু পেয়ারগুলিকে একটি ডিটারমিনিস্টিক এবং ক্রিপ্টোগ্রাফিক্যালি প্রমাণীকৃত ট্রাই-তে এনকোড করে। এগুলি Ethereum-এর এক্সিকিউশন লেয়ার জুড়ে ব্যাপকভাবে ব্যবহৃত হয়। + +[প্যাট্রিসিয়া মার্কল ট্রাই সম্পর্কে আরও](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### রিকার্সিভ লেংথ প্রিফিক্স {#recursive-length-prefix} + +রিকার্সিভ লেংথ প্রিফিক্স (RLP) হল একটি সিরিয়ালাইজেশন পদ্ধতি যা Ethereum-এর এক্সিকিউশন লেয়ার জুড়ে ব্যাপকভাবে ব্যবহৃত হয়। + +[RLP সম্পর্কে আরও](/developers/docs/data-structures-and-encoding/rlp) + +### সিম্পল সিরিয়ালাইজ {#simple-serialize} + +সিম্পল সিরিয়ালাইজ (SSZ) হল Ethereum-এর কনসেন্সাস লেয়ার-এর প্রধান সিরিয়ালাইজেশন ফর্ম্যাট কারণ এটি মার্কলাইজেশনের সাথে সামঞ্জস্যপূর্ণ। + +[SSZ সম্পর্কে আরও](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/bn/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/bn/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..e7c913ccfa5 --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: "মার্কল প্যাট্রিসিয়া ট্রাই" +description: "মার্কল প্যাট্রিসিয়া ট্রাই-এর ভূমিকা।" +lang: bn +sidebarDepth: 2 +--- + +ইথেরিয়ামের স্টেট (সমস্ত অ্যাকাউন্ট, ব্যালেন্স এবং স্মার্ট কন্ট্র্যাক্টের সমষ্টি), কম্পিউটার বিজ্ঞানে সাধারণত মার্কল ট্রি হিসাবে পরিচিত ডেটা স্ট্রাকচারের একটি বিশেষ সংস্করণে এনকোড করা হয়। এই কাঠামোটি ক্রিপ্টোগ্রাফির অনেক অ্যাপ্লিকেশনের জন্য দরকারী কারণ এটি ট্রিতে জড়িত ডেটার সমস্ত পৃথক অংশের মধ্যে একটি যাচাইযোগ্য সম্পর্ক তৈরি করে, যার ফলে একটি একক **রুট** মান পাওয়া যায় যা ডেটা সম্পর্কে বিভিন্ন বিষয় প্রমাণ করতে ব্যবহার করা যেতে পারে। + +ইথেরিয়ামের ডেটা স্ট্রাকচারটি একটি 'মডিফায়েড মার্কল-প্যাট্রিসিয়া ট্রাই', এর এই নামকরণ করা হয়েছে কারণ এটি PATRICIA (প্র্যাকটিক্যাল অ্যালগরিদম টু রিট্রিভ ইনফরমেশন কোডেড ইন আলফানিউমেরিক) এর কিছু বৈশিষ্ট্য ধার করে, এবং কারণ এটি ইথেরিয়াম স্টেট গঠনকারী আইটেমগুলির কার্যকর ডেটা রি**ট্রি**ভালের জন্য ডিজাইন করা হয়েছে। + +একটি মার্কল-প্যাট্রিসিয়া ট্রাই ডিটারমিনিস্টিক এবং ক্রিপ্টোগ্রাফিকভাবে যাচাইযোগ্য: একটি স্টেট রুট তৈরি করার একমাত্র উপায় হল স্টেটের প্রতিটি পৃথক অংশ থেকে এটি গণনা করা, এবং দুটি স্টেট যা অভিন্ন তা রুট হ্যাস এবং যে হ্যাসগুলি থেকে এটি তৈরি হয়েছে তা তুলনা করে সহজেই প্রমাণ করা যেতে পারে (_একটি মার্কল প্রুফ_)। বিপরীতভাবে, একই রুট হ্যাস দিয়ে দুটি ভিন্ন স্টেট তৈরি করার কোনো উপায় নেই, এবং ভিন্ন মান দিয়ে স্টেট পরিবর্তন করার যেকোনো প্রচেষ্টা একটি ভিন্ন স্টেট রুট হ্যাসের জন্ম দেবে। তাত্ত্বিকভাবে, এই কাঠামোটি সন্নিবেশ, সন্ধান এবং মুছে ফেলার জন্য `O(log(n))` দক্ষতার 'হোলি গ্রেইল' প্রদান করে। + +অদূর ভবিষ্যতে, ইথেরিয়াম একটি [ভার্কল ট্রি](/roadmap/verkle-trees) কাঠামোতে স্থানান্তরিত করার পরিকল্পনা করছে, যা ভবিষ্যতের প্রোটোকল উন্নতির জন্য অনেক নতুন সম্ভাবনার দ্বার উন্মোচন করবে। + +## পূর্বশর্ত {#prerequisites} + +এই পৃষ্ঠাটি আরও ভালভাবে বোঝার জন্য, [হ্যাস](https://en.wikipedia.org/wiki/Hash_function), [মার্কল ট্রি](https://en.wikipedia.org/wiki/Merkle_tree), [ট্রাই](https://en.wikipedia.org/wiki/Trie) এবং [সিরিয়ালাইজেশন](https://en.wikipedia.org/wiki/Serialization)-এর প্রাথমিক জ্ঞান থাকা সহায়ক হবে। এই নিবন্ধটি একটি বেসিক [রেডিক্স ট্রি](https://en.wikipedia.org/wiki/Radix_tree)-এর বর্ণনা দিয়ে শুরু হয়েছে, তারপর ধীরে ধীরে ইথেরিয়ামের আরও অপ্টিমাইজড ডেটা স্ট্রাকচারের জন্য প্রয়োজনীয় পরিবর্তনগুলি উপস্থাপন করা হয়েছে। + +## বেসিক রেডিক্স ট্রাই {#basic-radix-tries} + +একটি বেসিক রেডিক্স ট্রাই-তে, প্রতিটি নোড নিম্নলিখিত রূপে দেখায়: + +``` + [i_0, i_1 ... i_n, value] +``` + +যেখানে `i_0 ...` `i_n` বর্ণমালার প্রতীকগুলিকে (প্রায়শই বাইনারি বা হেক্স) প্রতিনিধিত্ব করে, `value` হল নোডের টার্মিনাল মান, এবং `i_0, i_1 ...`-এর মধ্যেকার মানগুলি। `i_n` স্লটগুলি হয় `NULL` অথবা অন্য নোডের পয়েন্টার (আমাদের ক্ষেত্রে, হ্যাস)। এটি একটি বেসিক `(কী, মান)` স্টোর গঠন করে। + +ধরুন আপনি কী-মান জোড়ার একটি সেটের উপর একটি ক্রম বজায় রাখার জন্য একটি রেডিক্স ট্রি ডেটা স্ট্রাকচার ব্যবহার করতে চেয়েছিলেন। `dog` কী-এর সাথে ট্রাই-তে বর্তমানে ম্যাপ করা মানটি খুঁজে পেতে, আপনাকে প্রথমে `dog`-কে বর্ণমালার অক্ষরে রূপান্তর করতে হবে (যা `64 6f 67` দেবে), এবং তারপর সেই পথ অনুসরণ করে ট্রাই-এর গভীরে যেতে হবে যতক্ষণ না আপনি মানটি খুঁজে পান। অর্থাৎ, আপনি ট্রাই-এর রুট নোড খুঁজে পেতে একটি ফ্ল্যাট কী/মান DB-তে রুট হ্যাস সন্ধান করে শুরু করবেন। এটি অন্য নোডগুলিতে নির্দেশকারী কী-গুলির একটি অ্যারে হিসাবে উপস্থাপিত হয়। আপনি ইনডেক্স `6`-এর মানটিকে কী হিসাবে ব্যবহার করবেন এবং এক স্তর নিচের নোডটি পেতে ফ্ল্যাট কী/মান DB-তে এটি সন্ধান করবেন। তারপর পরবর্তী মানটি দেখতে ইনডেক্স `4` বেছে নিন, তারপর ইনডেক্স `6`, এবং এভাবেই চলতে থাকবে, যতক্ষণ না আপনি পথটি অনুসরণ করেন: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, আপনি নোডের মান সন্ধান করবেন এবং ফলাফল ফেরত দেবেন। + +'ট্রাই' এবং অন্তর্নিহিত ফ্ল্যাট কী/মান 'DB'-তে কিছু সন্ধান করার মধ্যে একটি পার্থক্য আছে। উভয়ই কী/মান বিন্যাস সংজ্ঞায়িত করে, কিন্তু অন্তর্নিহিত DB একটি কী-এর জন্য একটি ঐতিহ্যবাহী ১-ধাপের সন্ধান করতে পারে। ট্রাই-তে একটি কী সন্ধান করার জন্য উপরে বর্ণিত চূড়ান্ত মানটিতে পৌঁছাতে একাধিক অন্তর্নিহিত DB সন্ধানের প্রয়োজন হয়। আসুন অস্পষ্টতা দূর করতে পরেরটিকে `পথ` হিসাবে উল্লেখ করি। + +রেডিক্স ট্রাই-এর জন্য আপডেট এবং ডিলিট অপারেশনগুলি নিম্নরূপ সংজ্ঞায়িত করা যেতে পারে: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 + newnode = curnode.copy() + if path == "": + newnode[-1] = value + else: + newindex = update(curnode[path[0]], path[1:], value) + newnode[path[0]] = newindex + db.put(hash(newnode), newnode) + return hash(newnode) + + def delete(node_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + newnode = curnode.copy() + if path == "": + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]], path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode), newnode) + return hash(newnode) +``` + +একটি "মার্কল" রেডিক্স ট্রি ডিটারমিনিস্টিকভাবে-জেনারেটেড ক্রিপ্টোগ্রাফিক হ্যাস ডাইজেস্ট ব্যবহার করে নোডগুলিকে লিঙ্ক করার মাধ্যমে নির্মিত হয়। এই কন্টেন্ট-অ্যাড্রেসিং (কী/মান DB-তে `key == keccak256(rlp(value))`) সঞ্চিত ডেটার একটি ক্রিপ্টোগ্রাফিক ইন্টিগ্রিটি গ্যারান্টি প্রদান করে। যদি একটি প্রদত্ত ট্রাই-এর রুট হ্যাস সর্বজনীনভাবে জানা থাকে, তবে অন্তর্নিহিত লিফ ডেটাতে অ্যাক্সেস আছে এমন যে কেউ একটি প্রমাণ তৈরি করতে পারে যে ট্রাইটি একটি নির্দিষ্ট পথে একটি প্রদত্ত মান অন্তর্ভুক্ত করে, যা প্রতিটি নোডের হ্যাস প্রদান করে যা একটি নির্দিষ্ট মানকে ট্রি রুটের সাথে যুক্ত করে। + +একজন আক্রমণকারীর পক্ষে এমন একটি `(পথ, মান)` জোড়ার প্রমাণ দেওয়া অসম্ভব যার অস্তিত্ব নেই কারণ রুট হ্যাসটি চূড়ান্তভাবে এর নীচের সমস্ত হ্যাসের উপর ভিত্তি করে তৈরি। যেকোনো অন্তর্নিহিত পরিবর্তন রুট হ্যাস পরিবর্তন করবে। আপনি হ্যাসকে ডেটা সম্পর্কে কাঠামোগত তথ্যের একটি সংকুচিত উপস্থাপনা হিসাবে ভাবতে পারেন, যা হ্যাশিং ফাংশনের প্রি-ইমেজ সুরক্ষা দ্বারা সুরক্ষিত। + +আমরা একটি রেডিক্স ট্রি-এর একটি পারমাণবিক একককে (যেমন, একটি একক হেক্স অক্ষর, বা ৪ বিট বাইনারি সংখ্যা) একটি "নিবল" হিসাবে উল্লেখ করব। উপরে বর্ণিত হিসাবে, একবারে একটি নিবল করে একটি পথ অতিক্রম করার সময়, নোডগুলি সর্বাধিক ১৬টি চাইল্ডকে উল্লেখ করতে পারে তবে একটি `মান` উপাদান অন্তর্ভুক্ত করে। তাই, আমরা সেগুলিকে ১৭ দৈর্ঘ্যের একটি অ্যারে হিসাবে উপস্থাপন করি। আমরা এই ১৭-উপাদান বিশিষ্ট অ্যারেগুলিকে "ব্রাঞ্চ নোড" বলি। + +## মার্কল প্যাট্রিসিয়া ট্রাই {#merkle-patricia-trees} + +রেডিক্স ট্রাই-এর একটি প্রধান সীমাবদ্ধতা রয়েছে: এগুলি অদক্ষ। আপনি যদি একটি `(পথ, মান)` বাইন্ডিং সঞ্চয় করতে চান যেখানে পথটি, ইথেরিয়ামের মতো, ৬৪ অক্ষর দীর্ঘ ( `bytes32`-তে নিবলের সংখ্যা), তাহলে প্রতি অক্ষরের জন্য একটি স্তর সঞ্চয় করতে আমাদের এক কিলোবাইটের বেশি অতিরিক্ত জায়গার প্রয়োজন হবে, এবং প্রতিটি সন্ধান বা মুছে ফেলার জন্য পুরো ৬৪টি ধাপ লাগবে। নিম্নলিখিত অংশে প্রবর্তিত প্যাট্রিসিয়া ট্রাই এই সমস্যার সমাধান করে। + +### অপ্টিমাইজেশান {#optimization} + +মার্কল প্যাট্রিসিয়া ট্রাই-এর একটি নোড নিম্নলিখিতগুলির মধ্যে একটি: + +1. `NULL` (খালি স্ট্রিং হিসাবে উপস্থাপিত) +2. `branch` একটি ১৭-আইটেম নোড `[ v0 ...` `v15, vt ]` +3. `leaf` একটি ২-আইটেম নোড `[ encodedPath, value ]` +4. `extension` একটি ২-আইটেম নোড `[ encodedPath, key ]` + +৬৪ অক্ষরের পথগুলির সাথে এটি অনিবার্য যে ট্রাই-এর প্রথম কয়েকটি লেয়ার অতিক্রম করার পরে, আপনি এমন একটি নোডে পৌঁছাবেন যেখানে নিচের দিকের পথের অন্তত কিছু অংশের জন্য কোনো ভিন্ন পথ বিদ্যমান নেই। পথ বরাবর ১৫টি পর্যন্ত স্পার্স `NULL` নোড তৈরি করা এড়াতে, আমরা একটি `[ encodedPath, key ]` ফর্মের `এক্সটেনশন` নোড সেট আপ করে ডিসেন্টকে শর্টকাট করি, যেখানে `encodedPath` এগিয়ে যাওয়ার জন্য "আংশিক পথ" ধারণ করে (নিচে বর্ণিত একটি কমপ্যাক্ট এনকোডিং ব্যবহার করে), এবং `key` পরবর্তী DB অনুসন্ধানের জন্য ব্যবহৃত হয়। + +`লিফ` নোডের জন্য, যা `encodedPath`-এর প্রথম নিবলে একটি ফ্ল্যাগ দ্বারা চিহ্নিত করা যেতে পারে, পথটি পূর্ববর্তী সমস্ত নোডের পথের খণ্ডাংশ এনকোড করে এবং আমরা সরাসরি `মান` সন্ধান করতে পারি। + +তবে উপরের এই অপ্টিমাইজেশানটি অস্পষ্টতা তৈরি করে। + +নিবলে পথ অতিক্রম করার সময়, আমরা বিজোড় সংখ্যক নিবল দিয়ে শেষ করতে পারি, কিন্তু কারণ সমস্ত ডেটা `বাইট` ফরম্যাটে সংরক্ষিত হয়। উদাহরণস্বরূপ, নিবল `1` এবং নিবল `01` এর মধ্যে পার্থক্য করা সম্ভব নয় (উভয়কেই `<01>` হিসাবে সংরক্ষণ করতে হবে)। বিজোড় দৈর্ঘ্য নির্দিষ্ট করতে, আংশিক পথের আগে একটি ফ্ল্যাগ যুক্ত করা হয়। + +### স্পেসিফিকেশন: ঐচ্ছিক টার্মিনেটর সহ হেক্স সিকোয়েন্সের কমপ্যাক্ট এনকোডিং {#specification} + +উপরে বর্ণিত _বিজোড় বনাম জোড় অবশিষ্ট আংশিক পথের দৈর্ঘ্য_ এবং _লিফ বনাম এক্সটেনশন নোড_ উভয়ের ফ্ল্যাগিং যেকোনো ২-আইটেম নোডের আংশিক পথের প্রথম নিবলে থাকে। এর ফলস্বরূপ নিম্নলিখিতগুলি ঘটে: + +| হেক্স অক্ষর | বিট | নোডের প্রকার আংশিক | পথের দৈর্ঘ্য | +| ----------- | ---- | ------------------------------------ | ------------ | +| 0 | 0000 | এক্সটেনশন | জোড় | +| 1 | 0001 | এক্সটেনশন | বিজোড় | +| 2 | 0010 | টার্মিনেটিং (লিফ) | জোড় | +| 3 | 0011 | টার্মিনেটিং (লিফ) | বিজোড় | + +জোড় অবশিষ্ট পথের দৈর্ঘ্যের জন্য (`0` বা `2`), আরেকটি `0` "প্যাডিং" নিবল সর্বদা অনুসরণ করবে। + +```python + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: + hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + # hexarray now has an even length whose first nibble is the flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +উদাহরণ: + +```python + > [1, 2, 3, 4, 5, ...] + '11 23 45' + > [0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +মার্কল প্যাট্রিসিয়া ট্রাই-তে একটি নোড পাওয়ার জন্য এখানে বর্ধিত কোড দেওয়া হলো: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) + else: + return "" + elif len(curnode) == 17: + return get_helper(curnode[path[0]], path[1:]) + + def get(node_hash, path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node_hash, path2) +``` + +### উদাহরণ ট্রাই {#example-trie} + +ধরুন আমরা এমন একটি ট্রাই চাই যেখানে চারটি পথ/মান জোড়া রয়েছে: `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`। + +প্রথমে, আমরা পথ এবং মান উভয়কেই `বাইট`-এ রূপান্তর করি। নিচে, _পথগুলির_ জন্য প্রকৃত বাইট উপস্থাপনা `<>` দ্বারা চিহ্নিত করা হয়েছে, যদিও _মানগুলি_ এখনও স্ট্রিং হিসাবে `''` দ্বারা দেখানো হয়েছে, সহজে বোঝার জন্য (এগুলিও আসলে `বাইট` হবে): + +``` + <64 6f> : 'verb' + <64 6f 67> : 'puppy' + <64 6f 67 65> : 'coins' + <68 6f 72 73 65> : 'stallion' +``` + +এখন, আমরা অন্তর্নিহিত DB-তে নিম্নলিখিত কী/মান জোড়া দিয়ে এমন একটি ট্রাই তৈরি করি: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +যখন একটি নোড অন্য নোডের ভিতরে রেফারেন্স করা হয়, তখন যা অন্তর্ভুক্ত করা হয় তা হলো `keccak256(rlp.encode(node))`, যদি `len(rlp.encode(node)) >= 32` হয়, অন্যথায় `node` যেখানে `rlp.encode` হলো [RLP](/developers/docs/data-structures-and-encoding/rlp) এনকোডিং ফাংশন। + +মনে রাখবেন যে একটি ট্রাই আপডেট করার সময়, একজনকে কী/মান জোড়া `(keccak256(x), x)` একটি পার্সিস্টেন্ট লুকআপ টেবিলে সংরক্ষণ করতে হবে _যদি_ নতুন তৈরি নোডের দৈর্ঘ্য >= ৩২ হয়। তবে, যদি নোডটি তার চেয়ে ছোট হয়, তবে কিছু সংরক্ষণ করার প্রয়োজন নেই, যেহেতু f(x) = x ফাংশনটি বিপরীতমুখী। + +## ইথেরিয়ামে ট্রাই {#tries-in-ethereum} + +ইথেরিয়ামের এক্সিকিউশন লেয়ারের সমস্ত মার্কল ট্রাই একটি মার্কল প্যাট্রিসিয়া ট্রাই ব্যবহার করে। + +একটি ব্লক হেডার থেকে এই ট্রাইগুলির ৩টি থেকে ৩টি রুট থাকে। + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### স্টেট ট্রাই {#state-trie} + +একটি গ্লোবাল স্টেট ট্রাই আছে, এবং যখনই কোনো ক্লায়েন্ট একটি ব্লক প্রসেস করে, এটি আপডেট করা হয়। এতে, একটি `পথ` সর্বদা: `keccak256(ethereumAddress)` এবং একটি `মান` সর্বদা: `rlp(ethereumAccount)`। আরও নির্দিষ্টভাবে একটি ইথেরিয়াম `অ্যাকাউন্ট` হল `[nonce,balance,storageRoot,codeHash]` এর একটি ৪-আইটেমের অ্যারে। এই মুহূর্তে, এটি উল্লেখ্য যে এই `storageRoot` অন্য একটি প্যাট্রিসিয়া ট্রাই-এর রুট: + +### স্টোরেজ ট্রাই {#storage-trie} + +স্টোরেজ ট্রাই হল যেখানে _সমস্ত_ কন্ট্র্যাক্ট ডেটা থাকে। প্রতিটি অ্যাকাউন্টের জন্য একটি পৃথক স্টোরেজ ট্রাই রয়েছে। একটি নির্দিষ্ট অ্যাড্রেসে নির্দিষ্ট স্টোরেজ পজিশনে মানগুলি পুনরুদ্ধার করতে স্টোরেজ অ্যাড্রেস, স্টোরেজে সঞ্চিত ডেটার পূর্ণসংখ্যার পজিশন এবং ব্লক আইডি প্রয়োজন। এগুলিকে তারপর JSON-RPC API-তে সংজ্ঞায়িত `eth_getStorageAt`-এ আর্গুমেন্ট হিসাবে পাস করা যেতে পারে, যেমন, `0x295a70b2de5e3953354a6a8344e616ed314d7251` অ্যাড্রেসের জন্য স্টোরেজ স্লট ০-এর ডেটা পুনরুদ্ধার করতে: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +স্টোরেজের অন্যান্য উপাদান পুনরুদ্ধার করা কিছুটা বেশি জড়িত কারণ স্টোরেজ ট্রাই-তে পজিশনটি প্রথমে গণনা করতে হবে। পজিশনটি অ্যাড্রেস এবং স্টোরেজ পজিশনের `keccak256` হ্যাস হিসাবে গণনা করা হয়, উভয়ই ৩২ বাইট দৈর্ঘ্যে শূন্য দিয়ে বাম-প্যাড করা হয়। উদাহরণস্বরূপ, `0x391694e7e0b0cce554cb130d723a9d27458f9298` অ্যাড্রেসের জন্য স্টোরেজ স্লট ১-এ ডেটার পজিশন হল: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +একটি Geth কনসোলে, এটি নিম্নরূপে গণনা করা যেতে পারে: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +`পথ`টি তাই `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`। এটি এখন আগের মতোই স্টোরেজ ট্রাই থেকে ডেটা পুনরুদ্ধার করতে ব্যবহার করা যেতে পারে: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +দ্রষ্টব্য: একটি ইথেরিয়াম অ্যাকাউন্টের জন্য `storageRoot` ডিফল্টরূপে খালি থাকে যদি এটি একটি কন্ট্র্যাক্ট অ্যাকাউন্ট না হয়। + +### ট্রানজ্যাকশন ট্রাই {#transaction-trie} + +প্রতিটি ব্লকের জন্য একটি পৃথক ট্রানজ্যাকশন ট্রাই রয়েছে, যা আবার `(কী, মান)` জোড়া সংরক্ষণ করে। এখানে একটি পথ হল: `rlp(transactionIndex)` যা একটি কী প্রতিনিধিত্ব করে যা একটি মান দ্বারা নির্ধারিত হয়: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +এ সম্পর্কে আরও তথ্য [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) ডকুমেন্টেশনে পাওয়া যাবে। + +### রিসিপ্টস ট্রাই {#receipts-trie} + +প্রতিটি ব্লকের নিজস্ব রিসিপ্টস ট্রাই রয়েছে। এখানে একটি `পথ` হল: `rlp(transactionIndex)`। `transactionIndex` হল সেই ব্লকের মধ্যে তার ইনডেক্স যেখানে এটি অন্তর্ভুক্ত ছিল। রিসিপ্টস ট্রাই কখনও আপডেট করা হয় না। ট্রানজ্যাকশন ট্রাই-এর অনুরূপ, এখানে বর্তমান এবং লিগ্যাসি রিসিপ্ট রয়েছে। রিসিপ্টস ট্রাই-তে একটি নির্দিষ্ট রিসিপ্ট কোয়েরি করতে, তার ব্লকের মধ্যে ট্রানজ্যাকশনের ইনডেক্স, রিসিপ্ট পেলোড এবং ট্রানজ্যাকশনের প্রকার প্রয়োজন। প্রত্যাবর্তিত রিসিপ্ট `রিসিপ্ট` ধরনের হতে পারে যা `TransactionType` এবং `ReceiptPayload`-এর কনক্যাটেনেশন হিসাবে সংজ্ঞায়িত করা হয় অথবা এটি `লিগ্যাসি রিসিপ্ট` ধরনের হতে পারে যা `rlp([status, cumulativeGasUsed, logsBloom, logs])` হিসাবে সংজ্ঞায়িত করা হয়। + +এ সম্পর্কে আরও তথ্য [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) ডকুমেন্টেশনে পাওয়া যাবে। + +## আরও পড়ুন {#further-reading} + +- [মডিফায়েড মার্কল প্যাট্রিসিয়া ট্রাই — ইথেরিয়াম কীভাবে একটি স্টেট সংরক্ষণ করে](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [ইথেরিয়ামে মার্কলিং](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [ইথেরিয়াম ট্রাই বোঝা](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/bn/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/bn/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..56e9efe977a --- /dev/null +++ b/public/content/translations/bn/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: "রিকার্সিভ-লেংথ প্রিফিক্স (RLP) সিরিয়ালাইজেশন" +description: "ইথেরিয়ামের এক্সিকিউশন লেয়ারে rlp এনকোডিং-এর একটি সংজ্ঞা।" +lang: bn +sidebarDepth: 2 +--- + +ইথেরিয়ামের এক্সিকিউশন ক্লায়েন্টগুলিতে রিকার্সিভ লেংথ প্রিফিক্স (RLP) সিরিয়ালাইজেশন ব্যাপকভাবে ব্যবহৃত হয়। RLP একটি স্পেস-এফিশিয়েন্ট ফরম্যাটে নোডগুলির মধ্যে ডেটা স্থানান্তরকে প্রমিত করে। RLP-এর উদ্দেশ্য হল বাইনারি ডেটার নির্বিচারে নেস্টেড অ্যারে এনকোড করা, এবং RLP হল ইথেরিয়ামের এক্সিকিউশন লেয়ারে অবজেক্ট সিরিয়ালাইজ করার জন্য ব্যবহৃত প্রাথমিক এনকোডিং পদ্ধতি। RLP-এর মূল উদ্দেশ্য হল গঠন এনকোড করা; ধনাত্মক পূর্ণসংখ্যা ছাড়া, RLP নির্দিষ্ট ডেটা প্রকার (যেমন, স্ট্রিং, ফ্লোট) এনকোড করার দায়িত্ব উচ্চ-স্তরের প্রোটোকলগুলিতে অর্পণ করে। ধনাত্মক পূর্ণসংখ্যাগুলিকে অবশ্যই বিগ-এন্ডিয়ান বাইনারি আকারে উপস্থাপন করতে হবে যেখানে কোনো লিডিং জিরো থাকবে না (এভাবে শূন্য পূর্ণসংখ্যার মানকে খালি বাইট অ্যারের সমতুল্য করে তোলে)। RLP ব্যবহারকারী যেকোনো উচ্চ-স্তরের প্রোটোকল দ্বারা লিডিং জিরো সহ ডিসিরিয়ালাইজড ধনাত্মক পূর্ণসংখ্যাগুলিকে অবশ্যই অবৈধ হিসাবে গণ্য করতে হবে। + +[ইথেরিয়াম ইয়েলো পেপার (পরিশিষ্ট B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19)-এ আরও তথ্য। + +একটি ডিকশনারি এনকোড করতে RLP ব্যবহার করার জন্য, দুটি প্রস্তাবিত ক্যানোনিকাল ফর্ম হল: + +- লেক্সিকোগ্রাফিক ক্রমে কি সহ `[[k1,v1],[k2,v2]...]` ব্যবহার করুন +- ইথেরিয়ামের মতো উচ্চ-স্তরের প্যাট্রিসিয়া ট্রি এনকোডিং ব্যবহার করুন + +## সংজ্ঞা {#definition} + +RLP এনকোডিং ফাংশন একটি আইটেম ইনপুট হিসাবে নেয়। একটি আইটেমকে নিম্নরূপ সংজ্ঞায়িত করা হয়েছে: + +- একটি স্ট্রিং (অর্থাৎ, বাইট অ্যারে) একটি আইটেম +- আইটেমের একটি তালিকা একটি আইটেম +- একটি ধনাত্মক পূর্ণসংখ্যা একটি আইটেম + +উদাহরণস্বরূপ, নিম্নলিখিত সবগুলি আইটেম: + +- একটি খালি স্ট্রিং; +- "cat" শব্দটি ধারণকারী স্ট্রিং; +- যেকোনো সংখ্যক স্ট্রিং ধারণকারী একটি তালিকা; +- এবং `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`-এর মতো আরও জটিল ডেটা স্ট্রাকচার। +- `100` সংখ্যাটি + +মনে রাখবেন যে এই পৃষ্ঠার বাকি প্রেক্ষাপটে, 'স্ট্রিং' মানে "বাইনারি ডেটার একটি নির্দিষ্ট সংখ্যক বাইট"; কোনো বিশেষ এনকোডিং ব্যবহার করা হয় না, এবং স্ট্রিংগুলির বিষয়বস্তু সম্পর্কে কোনো জ্ঞানের ইঙ্গিত দেওয়া হয় না (নন-মিনিমাল ধনাত্মক পূর্ণসংখ্যার বিরুদ্ধে নিয়মের প্রয়োজন ছাড়া)। + +RLP এনকোডিং নিম্নরূপ সংজ্ঞায়িত করা হয়েছে: + +- একটি ধনাত্মক পূর্ণসংখ্যার জন্য, এটিকে সবচেয়ে ছোট বাইট অ্যারেতে রূপান্তরিত করা হয় যার বিগ-এন্ডিয়ান ব্যাখ্যা হল পূর্ণসংখ্যা, এবং তারপর নীচের নিয়ম অনুসারে একটি স্ট্রিং হিসাবে এনকোড করা হয়। +- `[0x00, 0x7f]` (ডেসিমেল `[0, 127]`) পরিসরের মধ্যে থাকা একটি একক বাইটের জন্য, সেই বাইটটিই তার নিজস্ব RLP এনকোডিং। +- অন্যথায়, যদি একটি স্ট্রিং 0-55 বাইট দীর্ঘ হয়, তাহলে RLP এনকোডিং-এ **0x80** (ডেসিমেল 128) মানের একটি একক বাইট এবং স্ট্রিংটির দৈর্ঘ্য এবং তারপরে স্ট্রিংটি থাকে। সুতরাং প্রথম বাইটের পরিসর হল `[0x80, 0xb7]` (ডেসিমেল `[128, 183]`)। +- যদি একটি স্ট্রিং 55 বাইটের বেশি দীর্ঘ হয়, তাহলে RLP এনকোডিং-এ **0xb7** (ডেসিমেল 183) মানের একটি একক বাইট এবং বাইনারি আকারে স্ট্রিংটির দৈর্ঘ্যের বাইটে দৈর্ঘ্য, তারপরে স্ট্রিংটির দৈর্ঘ্য এবং তারপরে স্ট্রিংটি থাকে। উদাহরণস্বরূপ, একটি 1024 বাইট দীর্ঘ স্ট্রিং `\xb9\x04\x00` (ডেসিমেল `185, 4, 0`) হিসাবে এনকোড করা হবে এবং তারপরে স্ট্রিংটি থাকবে। এখানে, প্রথম বাইট হিসাবে `0xb9` (183 + 2 = 185), তারপরে 2 বাইট `0x0400` (ডেসিমেল 1024) যা আসল স্ট্রিংটির দৈর্ঘ্য নির্দেশ করে। সুতরাং প্রথম বাইটের পরিসর হল `[0xb8, 0xbf]` (ডেসিমেল `[184, 191]`)। +- যদি একটি স্ট্রিং 2^64 বাইট দীর্ঘ বা তার বেশি হয়, তবে এটি এনকোড করা নাও হতে পারে। +- যদি একটি তালিকার মোট পেলোড (অর্থাৎ, RLP এনকোড করা তার সমস্ত আইটেমের সম্মিলিত দৈর্ঘ্য) 0-55 বাইট দীর্ঘ হয়, তবে RLP এনকোডিং-এ **0xc0** মানের একটি একক বাইট এবং পেলোডের দৈর্ঘ্য এবং তারপরে আইটেমগুলির RLP এনকোডিংগুলির ক্যাটেনেশন থাকে। সুতরাং প্রথম বাইটের পরিসর হল `[0xc0, 0xf7]` (ডেসিমেল `[192, 247]`)। +- যদি একটি তালিকার মোট পেলোড 55 বাইটের বেশি দীর্ঘ হয়, তবে RLP এনকোডিং-এ **0xf7** মানের একটি একক বাইট এবং বাইনারি আকারে পেলোডের দৈর্ঘ্যের বাইটে দৈর্ঘ্য, তারপরে পেলোডের দৈর্ঘ্য এবং তারপরে আইটেমগুলির RLP এনকোডিংগুলির ক্যাটেনেশন থাকে। সুতরাং প্রথম বাইটের পরিসর হল `[0xf8, 0xff]` (ডেসিমেল `[248, 255]`)। + +কোডে, এটি হল: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("input too long") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## উদাহরণ {#examples} + +- "dog" স্ট্রিংটি = [ 0x83, 'd', 'o', 'g' ] +- [ "cat", "dog" ] তালিকাটি = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- খালি স্ট্রিং ('null') = `[ 0x80 ]` +- খালি তালিকা = `[ 0xc0 ]` +- পূর্ণসংখ্যা 0 = `[ 0x80 ]` +- বাইট '\\x00' = `[ 0x00 ]` +- বাইট '\\x0f' = `[ 0x0f ]` +- বাইট '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- তিন-এর [সেট থিওরেটিক্যাল রিপ্রেজেন্টেশন](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers), `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- "Lorem ipsum dolor sit amet, consectetur adipisicing elit" স্ট্রিংটি = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... `, 'e', 'l', 'i', 't' ]` + +## RLP ডিকোডিং {#rlp-decoding} + +RLP এনকোডিং-এর নিয়ম এবং প্রক্রিয়া অনুসারে, RLP ডিকোডিং-এর ইনপুটকে বাইনারি ডেটার একটি অ্যারে হিসাবে গণ্য করা হয়। RLP ডিকোডিং প্রক্রিয়াটি নিম্নরূপ: + +1. ইনপুট ডেটার প্রথম বাইট (অর্থাৎ, প্রিফিক্স) অনুযায়ী ডেটার ধরন, আসল ডেটার দৈর্ঘ্য এবং অফসেট ডিকোড করা; + +2. ডেটার ধরন এবং অফসেট অনুযায়ী, ধনাত্মক পূর্ণসংখ্যার জন্য মিনিমাল এনকোডিং নিয়মকে সম্মান করে ডেটা ডিকোড করা; + +3. ইনপুটের বাকি অংশ ডিকোড করা চালিয়ে যাওয়া; + +তাদের মধ্যে, ডেটার ধরন এবং অফসেট ডিকোড করার নিয়মগুলি নিম্নরূপ: + +1. ডেটা একটি স্ট্রিং যদি প্রথম বাইটের (অর্থাৎ, প্রিফিক্স) পরিসর [0x00, 0x7f] হয়, এবং স্ট্রিংটি ঠিক প্রথম বাইট নিজেই; + +2. ডেটা একটি স্ট্রিং যদি প্রথম বাইটের পরিসর [0x80, 0xb7] হয়, এবং যে স্ট্রিংটির দৈর্ঘ্য প্রথম বাইট মাইনাস 0x80 এর সমান, তা প্রথম বাইটকে অনুসরণ করে; + +3. ডেটা একটি স্ট্রিং যদি প্রথম বাইটের পরিসর [0xb8, 0xbf] হয়, এবং যে স্ট্রিংটির বাইটে দৈর্ঘ্য প্রথম বাইট মাইনাস 0xb7 এর সমান তা প্রথম বাইটকে অনুসরণ করে, এবং স্ট্রিংটি স্ট্রিংয়ের দৈর্ঘ্যকে অনুসরণ করে; + +4. ডেটা একটি তালিকা যদি প্রথম বাইটের পরিসর [0xc0, 0xf7] হয়, এবং তালিকার সমস্ত আইটেমের RLP এনকোডিংগুলির ক্যাটেনেশন, যার মোট পেলোড প্রথম বাইট মাইনাস 0xc0 এর সমান, তা প্রথম বাইটকে অনুসরণ করে; + +5. ডেটা একটি তালিকা যদি প্রথম বাইটের পরিসর [0xf8, 0xff] হয়, এবং তালিকার মোট পেলোড যার দৈর্ঘ্য প্রথম বাইট মাইনাস 0xf7 এর সমান, তা প্রথম বাইটকে অনুসরণ করে, এবং তালিকার সমস্ত আইটেমের RLP এনকোডিংগুলির ক্যাটেনেশন তালিকার মোট পেলোডকে অনুসরণ করে; + +কোডে, এটি হল: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("input is null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("input does not conform to RLP encoding form") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("input is null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## আরও পড়ুন {#further-reading} + +- [ইথেরিয়ামে RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [ইথেরিয়ামের আদ্যোপান্ত: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- Coglio, A. (2020)। ACL2-তে ইথেরিয়ামের রিকার্সিভ লেংথ প্রিফিক্স। arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## সম্পর্কিত বিষয় {#related-topics} + +- [প্যাট্রিসিয়া মার্কল ট্রাই](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) From c8cbd92bad86526758443bd4ede8a2b64e311295 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 18:52:06 +0000 Subject: [PATCH 2/3] fix(i18n): correct brand names and syntax in Bengali translations --- .../pos/rewards-and-penalties/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index c99abcb2c09..a495b64826d 100644 --- a/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -8,7 +8,7 @@ lang: bn একজন ভ্যালিডেটরের দুটি প্রধান ভূমিকা রয়েছে: ১) নতুন ব্লক পরীক্ষা করা এবং যদি সেগুলি বৈধ হয় তবে সেগুলিতে “অ্যাটেস্ট” করা, ২) মোট ভ্যালিডেটর পুল থেকে র‍্যান্ডমভাবে নির্বাচিত হলে নতুন ব্লক প্রস্তাব করা। যদি ভ্যালিডেটরকে বলা হলে এই কাজগুলির কোনোটি করতে ব্যর্থ হয়, তবে তারা একটি ইথার পেআউট থেকে বঞ্চিত হয়। ভ্যালিডেটরদের কখনও কখনও সিগনেচার অ্যাগ্রিগেশন এবং সিঙ্ক কমিটিতে অংশগ্রহণের দায়িত্বও দেওয়া হয়। -এমন কিছু কাজও আছে যা দুর্ঘটনাক্রমে করা খুব কঠিন এবং কিছু दुर्भावनाপূর্ণ উদ্দেশ্য নির্দেশ করে, যেমন একই স্লটের জন্য একাধিক ব্লক প্রস্তাব করা বা একই স্লটের জন্য একাধিক ব্লকে অ্যাটেস্ট করা। এগুলো হলো “স্ল্যাশেবল” আচরণ, যার ফলে ভ্যালিডেটরকে নেটওয়ার্ক থেকে সরিয়ে দেওয়ার আগে কিছু পরিমাণ ইথার (১ ETH পর্যন্ত) বার্ন করা হয়, যা ৩৬ দিন সময় নেয়। স্ল্যাশড ভ্যালিডেটরের ইথার এক্সিট পিরিয়ড জুড়ে ধীরে ধীরে শেষ হয়ে যায়, কিন্তু ১৮তম দিনে তারা একটি “কোরিলেশন পেনাল্টি” পায়, যা একই সময়ে আরও বেশি ভ্যালিডেটর স্ল্যাশড হলে বড় হয়। কনসেন্সাস মেকানিজমের ইনসেনটিভ কাঠামো তাই সততার জন্য পুরস্কৃত করে এবং খারাপ অ্যাক্টরদের শাস্তি দেয়। +এমন কিছু কাজও আছে যা দুর্ঘটনাক্রমে করা খুব কঠিন এবং কিছু দুর্ভাবনাপূর্ণ উদ্দেশ্য নির্দেশ করে, যেমন একই স্লটের জন্য একাধিক ব্লক প্রস্তাব করা বা একই স্লটের জন্য একাধিক ব্লকে অ্যাটেস্ট করা। এগুলো হলো “স্ল্যাশেবল” আচরণ, যার ফলে ভ্যালিডেটরকে নেটওয়ার্ক থেকে সরিয়ে দেওয়ার আগে কিছু পরিমাণ ইথার (১ ETH পর্যন্ত) বার্ন করা হয়, যা ৩৬ দিন সময় নেয়। স্ল্যাশড ভ্যালিডেটরের ইথার এক্সিট পিরিয়ড জুড়ে ধীরে ধীরে শেষ হয়ে যায়, কিন্তু ১৮তম দিনে তারা একটি “কোরিলেশন পেনাল্টি” পায়, যা একই সময়ে আরও বেশি ভ্যালিডেটর স্ল্যাশড হলে বড় হয়। কনসেন্সাস মেকানিজমের ইনসেনটিভ কাঠামো তাই সততার জন্য পুরস্কৃত করে এবং খারাপ অ্যাক্টরদের শাস্তি দেয়। সমস্ত রিওয়ার্ড এবং পেনাল্টি প্রতি ইপোকে একবার প্রয়োগ করা হয়। @@ -31,11 +31,11 @@ base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch মোট রিওয়ার্ড তখন পাঁচটি উপাদানের যোগফল হিসাবে গণনা করা হয়, যার প্রত্যেকটির একটি ওয়েটিং আছে যা নির্ধারণ করে প্রতিটি উপাদান মোট রিওয়ার্ডে কতটা যোগ করবে। উপাদানগুলো হলো: ``` -1. সোর্স ভোট: ভ্যালিডেটর সঠিক সোর্স চেকপয়েন্টের জন্য সময়মতো ভোট দিয়েছে -2. টার্গেট ভোট: ভ্যালিডেটর সঠিক টার্গেট চেকপয়েন্টের জন্য সময়মতো ভোট দিয়েছে -3. হেড ভোট: ভ্যালিডেটর সঠিক হেড ব্লকের জন্য সময়মতো ভোট দিয়েছে -4. সিঙ্ক কমিটি রিওয়ার্ড: ভ্যালিডেটর একটি সিঙ্ক কমিটিতে অংশগ্রহণ করেছে -5. প্রোপোজার রিওয়ার্ড: ভ্যালিডেটর সঠিক স্লটে একটি ব্লক প্রস্তাব করেছে +1. source vote: the validator has made a timely vote for the correct source checkpoint +2. target vote: the validator has made a timely vote for the correct target checkpoint +3. head vote: the validator has made a timely vote for the correct head block +4. sync committee reward: the validator has participated in a sync committee +5. proposer reward: the validator has proposed a block in the correct slot ``` প্রতিটি উপাদানের জন্য ওয়েটিংগুলি নিম্নরূপ: From 3066756620e11fcb6ac55186d7cfd3742227c144 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Mon, 16 Feb 2026 10:56:32 +0000 Subject: [PATCH 3/3] fix(i18n): restore English code comments in Bengali translations Crowdin translated Python/Rust code comments inside fenced code blocks in the ethash and dagger-hashimoto pages. Code comments must remain in English to preserve correctness and readability of reference implementations. --- .../dagger-hashimoto/index.md | 30 ++++++------ .../mining/mining-algorithms/ethash/index.md | 46 +++++++++---------- 2 files changed, 38 insertions(+), 38 deletions(-) diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md index 018f4c0a6ce..c97d70a50e6 100644 --- a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -29,7 +29,7 @@ Dagger-Hashimoto দুটি লক্ষ্য পূরণের লক্ষ NUM_BITS = 512 def encode_int(x): - "একটি ইন্টিজার x কে একটি স্ট্রিং হিসাবে এনকোড করুন যা 64টি অক্ষর নিয়ে গঠিত, একটি বড়-এন্ডিয়ান স্কিম ব্যবহার করে" + "Encode an integer x as a string of 64 characters using a big-endian scheme" o = '' for _ in range(NUM_BITS / 8): o = chr(x % 256) + o @@ -37,7 +37,7 @@ def encode_int(x): return o def decode_int(s): - "একটি বড়-এন্ডিয়ান স্কিম ব্যবহার করে একটি স্ট্রিং থেকে একটি ইন্টিজার x আনএনকোড করুন" + "Unencode an integer x from a string using a big-endian scheme" x = 0 for c in s: x *= 256 @@ -65,20 +65,20 @@ def dbl_sha3(x): অ্যালগরিদমের জন্য ব্যবহৃত প্যারামিটারগুলি হল: ```python -SAFE_PRIME_512 = 2**512 - 38117 # ২**৫১২ এর চেয়ে কম বৃহত্তম সেফ প্রাইম +SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512 params = { - "n": 4000055296 * 8 // NUM_BITS, # ডেটাসেটের আকার (4 গিগাবাইট); অবশ্যই 65536 এর গুণিতক হতে হবে - "n_inc": 65536, # প্রতি পিরিয়ডে n-এর মানের বৃদ্ধি; অবশ্যই 65536 এর গুণিতক হতে হবে - # epochtime=20000 হলে প্রতি বছর 882 MB বৃদ্ধি পায় - "cache_size": 2500, # লাইট ক্লায়েন্টের ক্যাশের আকার (লাইট ক্লায়েন্ট দ্বারা নির্বাচিত হতে পারে; - # অ্যালগো স্পেকের অংশ নয়) - "diff": 2**14, # কঠিনতা (ব্লক মূল্যায়নের সময় সমন্বয় করা হয়) - "epochtime": 100000, # ব্লকগুলিতে একটি যুগের দৈর্ঘ্য (কত ঘন ঘন ডেটাসেট আপডেট করা হয়) - "k": 1, # একটি নোডের প্যারেন্টের সংখ্যা - "w": w, # মডুলার এক্সপোনেনশিয়েশন হ্যাশিংয়ের জন্য ব্যবহৃত হয় - "accesses": 200, # হ্যাশিমোটো চলাকালীন ডেটাসেট অ্যাক্সেসের সংখ্যা - "P": SAFE_PRIME_512 # হ্যাশিং এবং র‍্যান্ডম নম্বর জেনারেশনের জন্য নিরাপদ প্রাইম + "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536 + "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536 + # with epochtime=20000 gives 882 MB growth per year + "cache_size": 2500, # Size of the light client's cache (can be chosen by light + # client; not part of the algo spec) + "diff": 2**14, # Difficulty (adjusted during block evaluation) + "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated) + "k": 1, # Number of parents of a node + "w": w, # Used for modular exponentiation hashing + "accesses": 200, # Number of dataset accesses during hashimoto + "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation } ``` @@ -164,7 +164,7 @@ def get_daggerset(params, block): dagsz = get_dagsize(params, block) seedset = get_seedset(params, block) if seedset["front_hash"] <= 0: - # কোনো ব্যাক বাফার সম্ভব নয়, শুধু ফ্রন্ট বাফার তৈরি করুন + # No back buffer is possible, just make front buffer return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), "block_number": 0}} else: diff --git a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index 2dbf077b275..198380efa71 100644 --- a/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/translations/bn/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -33,18 +33,18 @@ Ethash হল [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/minin আমরা নিম্নলিখিত সংজ্ঞাগুলো ব্যবহার করি: ``` -WORD_BYTES = 4 # শব্দে বাইট -DATASET_BYTES_INIT = 2**30 # জেনেসিসে ডেটাসেটে বাইট -DATASET_BYTES_GROWTH = 2**23 # প্রতি ইপকে ডেটাসেট বৃদ্ধি -CACHE_BYTES_INIT = 2**24 # জেনেসিসে ক্যাশে বাইট -CACHE_BYTES_GROWTH = 2**17 # প্রতি ইপকে ক্যাশে বৃদ্ধি -CACHE_MULTIPLIER=1024 # ক্যাশের সাপেক্ষে DAG-এর আকার -EPOCH_LENGTH = 30000 # প্রতি ইপকে ব্লক -MIX_BYTES = 128 # মিক্সের প্রস্থ -HASH_BYTES = 64 # বাইটে হ্যাশের দৈর্ঘ্য -DATASET_PARENTS = 256 # প্রতিটি ডেটাসেট উপাদানের প্যারেন্টের সংখ্যা -CACHE_ROUNDS = 3 # ক্যাশে উৎপাদনে রাউন্ডের সংখ্যা -ACCESSES = 64 # হ্যাশিমোটো লুপে অ্যাক্সেসের সংখ্যা +WORD_BYTES = 4 # bytes in word +DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis +DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch +CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis +CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch +CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache +EPOCH_LENGTH = 30000 # blocks per epoch +MIX_BYTES = 128 # width of mix +HASH_BYTES = 64 # hash length in bytes +DATASET_PARENTS = 256 # number of parents of each dataset element +CACHE_ROUNDS = 3 # number of rounds in cache production +ACCESSES = 64 # number of accesses in hashimoto loop ``` ### 'SHA3'-এর ব্যবহার {#sha3} @@ -86,12 +86,12 @@ def get_full_size(block_number): def mkcache(cache_size, seed): n = cache_size // HASH_BYTES - # ক্রমানুসারে প্রাথমিক ডেটাসেট তৈরি করুন + # Sequentially produce the initial dataset o = [sha3_512(seed)] for i in range(1, n): o.append(sha3_512(o[-1])) - # randmemohash এর একটি লো-রাউন্ড সংস্করণ ব্যবহার করুন + # Use a low-round version of randmemohash for _ in range(CACHE_ROUNDS): for i in range(n): v = o[i][0] % n @@ -123,11 +123,11 @@ def fnv(v1, v2): def calc_dataset_item(cache, i): n = len(cache) r = HASH_BYTES // WORD_BYTES - # মিক্স শুরু করুন + # initialize the mix mix = copy.copy(cache[i % n]) mix[0] ^= i mix = sha3_512(mix) - # i-এর উপর ভিত্তি করে অনেক র‍্যান্ডম ক্যাশে নোডের সাথে এটিকে fnv করুন + # fnv it with a lot of random cache nodes based on i for j in range(DATASET_PARENTS): cache_index = fnv(i ^ j, mix[j % r]) mix = map(fnv, mix, cache[cache_index % n]) @@ -150,20 +150,20 @@ def hashimoto(header, nonce, full_size, dataset_lookup): n = full_size / HASH_BYTES w = MIX_BYTES // WORD_BYTES mixhashes = MIX_BYTES / HASH_BYTES - # হেডার+ননসকে একটি 64 বাইট সীডে একত্রিত করুন + # combine header+nonce into a 64 byte seed s = sha3_512(header + nonce[::-1]) - # রেপ্লিকেটেড s দিয়ে মিক্স শুরু করুন + # start the mix with replicated s mix = [] for _ in range(MIX_BYTES / HASH_BYTES): mix.extend(s) - # র‍্যান্ডম ডেটাসেট নোডগুলোতে মিক্স করুন + # mix in random dataset nodes for i in range(ACCESSES): p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes newdata = [] for j in range(MIX_BYTES / HASH_BYTES): newdata.extend(dataset_lookup(p + j)) mix = map(fnv, mix, newdata) - # মিক্স কম্প্রেস করুন + # compress mix cmix = [] for i in range(0, len(mix), 4): cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) @@ -189,7 +189,7 @@ def hashimoto_full(full_size, dataset, header, nonce): ```python def mine(full_size, dataset, header, difficulty): - # একই ডিজিটে হ্যাশের সাথে তুলনা করার জন্য টার্গেটকে জিরো-প্যাড করুন + # zero-pad target to compare with hash on the same digit target = zpad(encode_int(2**256 // difficulty), 64)[::-1] from random import randint nonce = randint(0, 2**64) @@ -223,7 +223,7 @@ _এমন কোনো কমিউনিটি রিসোর্স সম্ ```python import sha3, copy -# লিটল এন্ডিয়ান বিট অর্ডারিং ধরে নেয় (Intel আর্কিটেকচারের মতো) +# Assumes little endian bit ordering (same as Intel architectures) def decode_int(s): return int(s[::-1].encode('hex'), 16) if s else 0 @@ -251,7 +251,7 @@ def serialize_cache(ds): serialize_dataset = serialize_cache -# sha3 হ্যাস ফাংশন, 64 বাইট আউটপুট দেয় +# sha3 hash function, outputs 64 bytes def sha3_512(x): return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)