পোর্টাল নেটওয়ার্ক

ইথেরিয়াম হলো এমন একটি নেটওয়ার্ক যা ইথেরিয়াম ক্লায়েন্ট সফটওয়্যার চালানো কম্পিউটারগুলো নিয়ে গঠিত। এই কম্পিউটারগুলোর প্রতিটিকে একটি 'নোড' বলা হয়। ক্লায়েন্ট সফটওয়্যার একটি নোডকে ইথেরিয়াম নেটওয়ার্কে ডেটা পাঠাতে এবং গ্রহণ করতে দেয় এবং ইথেরিয়াম প্রোটোকল নিয়মগুলোর বিপরীতে ডেটা যাচাই করে। নোডগুলো তাদের ডিস্ক স্টোরেজে প্রচুর ঐতিহাসিক ডেটা রাখে এবং যখন তারা নেটওয়ার্কের অন্যান্য নোড থেকে তথ্যের নতুন প্যাকেট (যা ব্লক হিসেবে পরিচিত) গ্রহণ করে, তখন তা এতে যুক্ত করে। একটি নোডের কাছে নেটওয়ার্কের বাকি অংশের সাথে সামঞ্জস্যপূর্ণ তথ্য আছে কিনা তা সর্বদা পরীক্ষা করার জন্য এটি প্রয়োজনীয়। এর মানে হলো একটি নোড চালানোর জন্য প্রচুর ডিস্ক স্পেসের প্রয়োজন হতে পারে। কিছু নোড অপারেশনের জন্য প্রচুর RAM-ও প্রয়োজন হতে পারে।

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

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

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

আমাদের কেন পোর্টাল নেটওয়ার্ক প্রয়োজন

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

ব্লকচেইনের এই লোকাল কপি এবং এর সাথে যুক্ত স্টেট ও রসিদ ডেটা নোডের হার্ড ডিস্কে প্রচুর জায়গা নেয়। উদাহরণস্বরূপ, একটি কনসেনসাস ক্লায়েন্টের সাথে যুক্ত গো ইথেরিয়াম (geth) (opens in a new tab) ব্যবহার করে একটি নোড চালানোর জন্য 2TB হার্ড ডিস্কের সুপারিশ করা হয়। স্ন্যাপ সিঙ্কিং ব্যবহার করে, যা শুধুমাত্র তুলনামূলকভাবে সাম্প্রতিক ব্লকগুলোর সেট থেকে চেইন ডেটা সংরক্ষণ করে, Geth সাধারণত প্রায় 650GB ডিস্ক স্পেস দখল করে কিন্তু প্রতি সপ্তাহে প্রায় 14GB হারে বৃদ্ধি পায় (আপনি পর্যায়ক্রমে নোডটিকে ছাঁটাই করে আবার 650GB-তে নামিয়ে আনতে পারেন)।

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

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

পোর্টাল নেটওয়ার্ক কীভাবে কাজ করে?

ইথেরিয়াম নোডগুলোর কঠোর প্রোটোকল রয়েছে যা নির্ধারণ করে যে তারা কীভাবে একে অপরের সাথে যোগাযোগ করবে। এক্সিকিউশন ক্লায়েন্টগুলো devp2p নামে পরিচিত সাবপ্রোটোকলগুলোর একটি সেট ব্যবহার করে যোগাযোগ করে, অন্যদিকে কনসেনসাস ক্লায়েন্টগুলো libp2p নামক সাবপ্রোটোকলগুলোর একটি ভিন্ন স্ট্যাক ব্যবহার করে। এগুলো নির্ধারণ করে যে নোডগুলোর মধ্যে কোন ধরনের ডেটা আদান-প্রদান করা যেতে পারে।

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

লাইট ক্লায়েন্টরা বর্তমানে devp2p বা libp2p-এর মাধ্যমে চেইন ডেটার নির্দিষ্ট অংশগুলোর জন্য অনুরোধ করতে পারে না কারণ সেই প্রোটোকলগুলো শুধুমাত্র চেইন সিঙ্কিং এবং ব্লক ও লেনদেনের গসিপিং সক্ষম করার জন্য ডিজাইন করা হয়েছে। লাইট ক্লায়েন্টরা এই তথ্য ডাউনলোড করতে চায় না কারণ এটি তাদের "লাইট" হওয়া থেকে বিরত করবে।

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

পোর্টাল নেটওয়ার্কের উদ্দেশ্য হলো বিদ্যমান ইথেরিয়াম ক্লায়েন্টগুলোর ডিজাইনের সীমাবদ্ধতার বাইরে, বিশেষভাবে হালকা হওয়ার জন্য তৈরি করে পুরো ডিজাইনটি নিয়ে নতুন করে ভাবা।

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

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

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

এর লক্ষ্য হলো হালকা পোর্টাল ক্লায়েন্টগুলোর একটি বিকেন্দ্রীকৃত নেটওয়ার্ককে নিম্নলিখিত কাজগুলো করার অনুমতি দেওয়া:

• চেইনের হেড ট্র্যাক করা
• সাম্প্রতিক এবং ঐতিহাসিক চেইন ডেটা সিঙ্কিং করা
• স্টেট ডেটা পুনরুদ্ধার করা
• লেনদেন সম্প্রচার করা
• EVM ব্যবহার করে লেনদেন কার্যকর করা

এই নেটওয়ার্ক ডিজাইনের সুবিধাগুলো হলো:

• কেন্দ্রীভূত প্রদানকারীদের ওপর নির্ভরতা কমানো
• ইন্টারনেট ব্যান্ডউইথের ব্যবহার কমানো
• সিঙ্কিং কমানো বা শূন্য করা
• কম-রিসোর্স সম্পন্ন ডিভাইসে অ্যাক্সেসযোগ্য (<1 GB RAM, <100 MB ডিস্ক স্পেস, 1 CPU)

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

পোর্টাল নেটওয়ার্কগুলো

ডিফল্টরূপে ক্লায়েন্ট বৈচিত্র্য

পোর্টাল নেটওয়ার্ক ডেভেলপাররা প্রথম দিন থেকেই চারটি আলাদা পোর্টাল নেটওয়ার্ক ক্লায়েন্ট তৈরি করার ডিজাইনের সিদ্ধান্ত নিয়েছিলেন।

পোর্টাল নেটওয়ার্ক ক্লায়েন্টগুলো হলো:

• Trin (opens in a new tab): Rust-এ লেখা
• Fluffy (opens in a new tab): Nim-এ লেখা
• Ultralight (opens in a new tab): TypeScript-এ লেখা
• Shisui (opens in a new tab): Go-তে লেখা

একাধিক স্বাধীন ক্লায়েন্ট বাস্তবায়ন থাকা ইথেরিয়াম নেটওয়ার্কের স্থিতিস্থাপকতা এবং বিকেন্দ্রীকরণ বাড়ায়।

যদি একটি ক্লায়েন্ট সমস্যা বা দুর্বলতার সম্মুখীন হয়, তবে অন্যান্য ক্লায়েন্টগুলো সুচারুভাবে কাজ চালিয়ে যেতে পারে, যা ব্যর্থতার একক বিন্দু (single point of failure) প্রতিরোধ করে। উপরন্তু, বৈচিত্র্যময় ক্লায়েন্ট বাস্তবায়ন উদ্ভাবন এবং প্রতিযোগিতাকে উৎসাহিত করে, যা ইকোসিস্টেমের মধ্যে উন্নতি সাধন করে এবং মনোকালচার ঝুঁকি হ্রাস করে।

আরও পড়ুন

• পোর্টাল নেটওয়ার্ক (ডেভকন বোগোটায় পাইপার মেরিয়াম) (opens in a new tab)।
• পোর্টাল নেটওয়ার্ক ডিসকর্ড (opens in a new tab)
• পোর্টাল নেটওয়ার্ক ওয়েবসাইট (opens in a new tab)