---
title: "ব্লক"
description: "ইথেরিয়াম ব্লকচেইনে ব্লকের একটি ওভারভিউ – এগুলোর ডেটা স্ট্রাকচার, কেন এগুলো প্রয়োজন এবং কীভাবে এগুলো তৈরি হয়।"
lang: bn
---

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

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

ব্লক খুব শিক্ষানবিস-বান্ধব একটি বিষয়। তবে এই পৃষ্ঠাটি আরও ভালোভাবে বুঝতে সাহায্য করার জন্য, আমরা সুপারিশ করছি যে আপনি প্রথমে [অ্যাকাউন্ট](/developers/docs/accounts/), [ট্রানজ্যাকশন](/developers/docs/transactions/) এবং আমাদের [ইথেরিয়াম পরিচিতি](/developers/docs/intro-to-ethereum/) পড়ুন।

## ব্লক কেন? {#why-blocks}

[ইথেরিয়াম](/) নেটওয়ার্কের সমস্ত অংশগ্রহণকারী যাতে একটি সিঙ্ক্রোনাইজড স্টেট বজায় রাখে এবং ট্রানজ্যাকশনের সঠিক ইতিহাসে একমত হয় তা নিশ্চিত করতে, আমরা ট্রানজ্যাকশনগুলোকে ব্লকে ব্যাচ করি। এর মানে হলো ডজন ডজন (বা শত শত) ট্রানজ্যাকশন একসাথে কমিট করা হয়, একমত হওয়া হয় এবং সিঙ্ক্রোনাইজ করা হয়।

![A diagram showing transaction in a block causing state changes](./tx-block.png)
_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) থেকে গৃহীত ডায়াগ্রাম_

কমিটগুলোর মধ্যে সময় দিয়ে, আমরা নেটওয়ার্কের সমস্ত অংশগ্রহণকারীকে ঐক্যমতে পৌঁছানোর জন্য পর্যাপ্ত সময় দিই: যদিও ট্রানজ্যাকশনের অনুরোধ প্রতি সেকেন্ডে ডজন ডজন বার ঘটে, ইথেরিয়ামে ব্লকগুলো প্রতি 12 সেকেন্ডে একবার তৈরি এবং কমিট করা হয়।

## ব্লক কীভাবে কাজ করে {#how-blocks-work}

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

নেটওয়ার্কে এলোমেলোভাবে নির্বাচিত একজন ভ্যালিডেটর দ্বারা একটি ব্লক একত্রিত হওয়ার পর, এটি নেটওয়ার্কের বাকি অংশে ছড়িয়ে দেওয়া হয়; সমস্ত নোড এই ব্লকটিকে তাদের ব্লকচেইনের শেষে যুক্ত করে এবং পরবর্তী ব্লক তৈরি করার জন্য একজন নতুন ভ্যালিডেটর নির্বাচন করা হয়। সঠিক ব্লক-অ্যাসেম্বলি প্রক্রিয়া এবং কমিটমেন্ট/ঐক্যমত প্রক্রিয়া বর্তমানে ইথেরিয়ামের "প্রুফ-অফ-স্টেক (PoS)" প্রোটোকল দ্বারা নির্দিষ্ট করা হয়েছে।

## প্রুফ-অফ-স্টেক প্রোটোকল {#proof-of-stake-protocol}

প্রুফ-অফ-স্টেক (PoS) বলতে নিচের বিষয়গুলোকে বোঝায়:

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

[প্রুফ-অফ-স্টেক সম্পর্কে আরও জানুন](/developers/docs/consensus-mechanisms/pos)

## একটি ব্লকে কী থাকে? {#block-anatomy}

একটি ব্লকের মধ্যে প্রচুর তথ্য থাকে। সর্বোচ্চ স্তরে একটি ব্লকে নিচের ফিল্ডগুলো থাকে:

| ফিল্ড            | বিবরণ                                           |
| :--------------- | :---------------------------------------------------- |
| `slot`           | ব্লকটি যে স্লটের অন্তর্গত                         |
| `proposer_index` | ব্লক প্রস্তাবক ভ্যালিডেটরের আইডি           |
| `parent_root`    | আগের ব্লকের হ্যাশ                       |
| `state_root`     | স্টেট অবজেক্টের রুট হ্যাশ                     |
| `body`           | নিচে সংজ্ঞায়িত বেশ কয়েকটি ফিল্ড সম্বলিত একটি অবজেক্ট |

ব্লক `body`-এ নিজস্ব বেশ কয়েকটি ফিল্ড রয়েছে:

| ফিল্ড                | বিবরণ                                      |
| :------------------- | :----------------------------------------------- |
| `randao_reveal`      | পরবর্তী ব্লক প্রস্তাবক নির্বাচন করতে ব্যবহৃত একটি মান   |
| `eth1_data`          | ডিপোজিট কন্ট্রাক্ট সম্পর্কে তথ্য           |
| `graffiti`           | ব্লক ট্যাগ করতে ব্যবহৃত আরবিট্রারি ডেটা                |
| `proposer_slashings` | স্ল্যাশিং করা হবে এমন ভ্যালিডেটরদের তালিকা                 |
| `attester_slashings` | স্ল্যাশিং করা হবে এমন অ্যাটেস্টারদের তালিকা                  |
| `attestations`       | আগের স্লটগুলোর বিপরীতে করা সত্যায়নের তালিকা |
| `deposits`           | ডিপোজিট কন্ট্রাক্টে নতুন ডিপোজিটের তালিকা     |
| `voluntary_exits`    | নেটওয়ার্ক থেকে বেরিয়ে যাওয়া ভ্যালিডেটরদের তালিকা           |
| `sync_aggregate`     | লাইট ক্লায়েন্টদের পরিষেবা দিতে ব্যবহৃত ভ্যালিডেটরদের সাবসেট |
| `execution_payload`  | এক্সিকিউশন ক্লায়েন্ট থেকে পাস করা ট্রানজ্যাকশন    |

`attestations` ফিল্ডে ব্লকের সমস্ত সত্যায়নের একটি তালিকা থাকে। সত্যায়নের নিজস্ব ডেটা টাইপ রয়েছে যাতে বেশ কিছু ডেটা থাকে। প্রতিটি সত্যায়নে থাকে:

| ফিল্ড              | বিবরণ                                                    |
| :----------------- | :------------------------------------------------------------- |
| `aggregation_bits` | এই সত্যায়নে কোন কোন ভ্যালিডেটর অংশগ্রহণ করেছে তার একটি তালিকা    |
| `data`             | একাধিক সাবফিল্ড সম্বলিত একটি কন্টেইনার                            |
| `signature`        | `data` অংশের বিপরীতে একদল ভ্যালিডেটরের সামগ্রিক স্বাক্ষর |

`attestation`-এর `data` ফিল্ডে নিচের বিষয়গুলো থাকে:

| ফিল্ড               | বিবরণ                                                     |
| :------------------ | :-------------------------------------------------------------- |
| `slot`              | সত্যায়নটি যে স্লটের সাথে সম্পর্কিত                             |
| `index`             | সত্যায়নকারী ভ্যালিডেটরদের সূচক                                |
| `beacon_block_root` | চেইনের হেড হিসেবে দেখা বিকন ব্লকের রুট হ্যাশ |
| `source`            | সর্বশেষ জাস্টিফাইড চেকপয়েন্ট                                   |
| `target`            | সর্বশেষ ইপক বাউন্ডারি ব্লক                                 |

`execution_payload`-এ ট্রানজ্যাকশনগুলো এক্সিকিউট করলে গ্লোবাল স্টেট আপডেট হয়। নতুন স্টেটটি নতুন ব্লকের `state_root` ফিল্ডের সাথে মিলে কিনা তা নিশ্চিত করতে সমস্ত ক্লায়েন্ট `execution_payload`-এর ট্রানজ্যাকশনগুলো পুনরায় এক্সিকিউট করে। এভাবেই ক্লায়েন্টরা বুঝতে পারে যে একটি নতুন ব্লক বৈধ এবং তাদের ব্লকচেইনে যুক্ত করা নিরাপদ। `execution payload` নিজেই বেশ কয়েকটি ফিল্ড সম্বলিত একটি অবজেক্ট। এছাড়াও একটি `execution_payload_header` রয়েছে যাতে এক্সিকিউশন ডেটা সম্পর্কে গুরুত্বপূর্ণ সারসংক্ষেপ তথ্য থাকে। এই ডেটা স্ট্রাকচারগুলো নিচের মতো করে সাজানো হয়েছে:

`execution_payload_header`-এ নিচের ফিল্ডগুলো থাকে:

| ফিল্ড               | বিবরণ                                                         |
| :------------------ | :------------------------------------------------------------------ |
| `parent_hash`       | প্যারেন্ট ব্লকের হ্যাশ                                            |
| `fee_recipient`     | ট্রানজ্যাকশন ফি প্রদান করার অ্যাকাউন্ট ঠিকানা                      |
| `state_root`        | এই ব্লকে পরিবর্তনগুলো প্রয়োগ করার পর গ্লোবাল স্টেটের রুট হ্যাশ |
| `receipts_root`     | ট্রানজ্যাকশন রিসিট ট্রাই-এর হ্যাশ                               |
| `logs_bloom`        | ইভেন্ট লগ সম্বলিত ডেটা স্ট্রাকচার                                |
| `prev_randao`       | এলোমেলো ভ্যালিডেটর নির্বাচনে ব্যবহৃত মান                            |
| `block_number`      | বর্তমান ব্লকের নম্বর                                     |
| `gas_limit`         | এই ব্লকে অনুমোদিত সর্বোচ্চ গ্যাস                                   |
| `gas_used`          | এই ব্লকে ব্যবহৃত গ্যাসের প্রকৃত পরিমাণ                         |
| `timestamp`         | ব্লক টাইম                                                      |
| `extra_data`        | র (raw) বাইট হিসেবে আরবিট্রারি অতিরিক্ত ডেটা                              |
| `base_fee_per_gas`  | ভিত্তি ফি-এর মান                                                  |
| `block_hash`        | এক্সিকিউশন ব্লকের হ্যাশ                                             |
| `transactions_root` | পেলোডে থাকা ট্রানজ্যাকশনগুলোর রুট হ্যাশ                        |
| `withdrawal_root`   | পেলোডে থাকা উত্তোলনগুলোর রুট হ্যাশ                         |

`execution_payload`-এ নিচের বিষয়গুলো থাকে (লক্ষ্য করুন যে এটি হেডারের মতোই, তবে ট্রানজ্যাকশনগুলোর রুট হ্যাশের পরিবর্তে এতে ট্রানজ্যাকশন এবং উত্তোলনের তথ্যের প্রকৃত তালিকা অন্তর্ভুক্ত থাকে):

| ফিল্ড              | বিবরণ                                                         |
| :----------------- | :------------------------------------------------------------------ |
| `parent_hash`      | প্যারেন্ট ব্লকের হ্যাশ                                            |
| `fee_recipient`    | ট্রানজ্যাকশন ফি প্রদান করার অ্যাকাউন্ট ঠিকানা                      |
| `state_root`       | এই ব্লকে পরিবর্তনগুলো প্রয়োগ করার পর গ্লোবাল স্টেটের রুট হ্যাশ |
| `receipts_root`    | ট্রানজ্যাকশন রিসিট ট্রাই-এর হ্যাশ                               |
| `logs_bloom`       | ইভেন্ট লগ সম্বলিত ডেটা স্ট্রাকচার                                |
| `prev_randao`      | এলোমেলো ভ্যালিডেটর নির্বাচনে ব্যবহৃত মান                            |
| `block_number`     | বর্তমান ব্লকের নম্বর                                     |
| `gas_limit`        | এই ব্লকে অনুমোদিত সর্বোচ্চ গ্যাস                                   |
| `gas_used`         | এই ব্লকে ব্যবহৃত গ্যাসের প্রকৃত পরিমাণ                         |
| `timestamp`        | ব্লক টাইম                                                      |
| `extra_data`       | র (raw) বাইট হিসেবে আরবিট্রারি অতিরিক্ত ডেটা                              |
| `base_fee_per_gas` | ভিত্তি ফি-এর মান                                                  |
| `block_hash`       | এক্সিকিউশন ব্লকের হ্যাশ                                             |
| `transactions`     | এক্সিকিউট করা হবে এমন ট্রানজ্যাকশনের তালিকা                                 |
| `withdrawals`      | উত্তোলন অবজেক্টের তালিকা                                          |

`withdrawals` তালিকায় নিচের মতো করে সাজানো `withdrawal` অবজেক্ট থাকে:

| ফিল্ড            | বিবরণ                        |
| :--------------- | :--------------------------------- |
| `address`        | উত্তোলন করা অ্যাকাউন্ট ঠিকানা |
| `amount`         | উত্তোলনের পরিমাণ                  |
| `index`          | উত্তোলনের সূচক মান             |
| `validatorIndex` | ভ্যালিডেটর সূচক মান              |

## ব্লক টাইম {#block-time}

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

এই বাস্তবায়নটি প্রুফ-অফ-ওয়ার্ক (PoW) ভিত্তিক সিস্টেমগুলো থেকে আলাদা যেখানে ব্লক টাইমগুলো সম্ভাব্য এবং প্রোটোকলের লক্ষ্য মাইনিং কাঠিন্য দ্বারা টিউন করা হয়। ইথেরিয়ামের [গড় ব্লক টাইম](https://etherscan.io/chart/blocktime) এর একটি নিখুঁত উদাহরণ, যার মাধ্যমে নতুন 12 সেকেন্ডের ব্লক টাইমের ধারাবাহিকতার ওপর ভিত্তি করে প্রুফ-অফ-ওয়ার্ক থেকে প্রুফ-অফ-স্টেকে রূপান্তর স্পষ্টভাবে অনুমান করা যায়।

## ব্লকের আকার {#block-size}

একটি চূড়ান্ত গুরুত্বপূর্ণ বিষয় হলো ব্লকগুলোর আকার সীমাবদ্ধ। প্রতিটি ব্লকের লক্ষ্য আকার হলো 30 মিলিয়ন গ্যাস, তবে নেটওয়ার্কের চাহিদা অনুযায়ী ব্লকের আকার বাড়বে বা কমবে, যা 60 মিলিয়ন গ্যাস (লক্ষ্য ব্লকের আকারের 2 গুণ) ব্লক লিমিট পর্যন্ত হতে পারে। ব্লক গ্যাস লিমিট আগের ব্লকের গ্যাস লিমিট থেকে 1/1024 ফ্যাক্টর দ্বারা বাড়ানো বা কমানো যেতে পারে। ফলস্বরূপ, ভ্যালিডেটররা ঐক্যমতের মাধ্যমে ব্লক গ্যাস লিমিট পরিবর্তন করতে পারে। ব্লকের সমস্ত ট্রানজ্যাকশন দ্বারা ব্যয় করা মোট গ্যাসের পরিমাণ অবশ্যই ব্লক গ্যাস লিমিটের চেয়ে কম হতে হবে। এটি গুরুত্বপূর্ণ কারণ এটি নিশ্চিত করে যে ব্লকগুলো ইচ্ছামতো বড় হতে পারে না। যদি ব্লকগুলো ইচ্ছামতো বড় হতে পারত, তবে কম পারফরম্যান্সের ফুল নোডগুলো স্পেস এবং গতির প্রয়োজনীয়তার কারণে ধীরে ধীরে নেটওয়ার্কের সাথে তাল মিলিয়ে চলতে অক্ষম হয়ে পড়ত। ব্লক যত বড় হবে, পরবর্তী স্লটের জন্য সময়মতো সেগুলো প্রসেস করতে তত বেশি কম্পিউটিং শক্তির প্রয়োজন হবে। এটি একটি কেন্দ্রীভূত করার শক্তি, যা ব্লকের আকার সীমাবদ্ধ করার মাধ্যমে প্রতিরোধ করা হয়।

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

_আপনাকে সাহায্য করেছে এমন কোনো কমিউনিটি রিসোর্স সম্পর্কে জানেন? এই পৃষ্ঠাটি সম্পাদনা করুন এবং এটি যুক্ত করুন!_

## সম্পর্কিত বিষয়গুলো {#related-topics}

- [ট্রানজ্যাকশন](/developers/docs/transactions/)
- [গ্যাস](/developers/docs/gas/)
- [প্রুফ-অফ-স্টেক (PoS)](/developers/docs/consensus-mechanisms/pos)

<QuizWidget quizKey="blocks" />