পাবলিক পরীক্ষা: Ethereum গোপনীয়তা এবং স্কেলেবিলিটি সমাধান

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

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

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

প্লাজমা ক্যাশে মূল প্রক্রিয়া

1. ব্যবহারকারী স্মার্ট কন্ট্রাক্ট ফাংশনকে 'ডিপোজিট' বলে, এতে ইটিএইচের পরিমাণ পাস করে যা তিনি প্লাজমা ক্যাশ টোকেনে জমা করতে চান। স্মার্ট চুক্তি ফাংশন একটি টোকেন তৈরি করে এবং এটি সম্পর্কে একটি ইভেন্ট তৈরি করে।

2. স্মার্ট কন্ট্রাক্ট ইভেন্টগুলিতে সাবস্ক্রাইব করা প্লাজমা ক্যাশ নোডগুলি একটি ডিপোজিট তৈরি করার একটি ইভেন্ট গ্রহণ করে এবং পুলে একটি টোকেন তৈরি করার বিষয়ে একটি লেনদেন যোগ করে।

3. পর্যায়ক্রমে, বিশেষ প্লাজমা ক্যাশ নোডগুলি পুল (1 মিলিয়ন পর্যন্ত) থেকে সমস্ত লেনদেন নেয় এবং তাদের থেকে একটি ব্লক তৈরি করে, মার্কেল ট্রি গণনা করে এবং সেই অনুযায়ী, হ্যাশ। এই ব্লকটি যাচাইয়ের জন্য অন্যান্য নোডে পাঠানো হয়। নোডগুলি মার্কেল হ্যাশ বৈধ কিনা এবং লেনদেনগুলি বৈধ কিনা তা পরীক্ষা করে (উদাহরণস্বরূপ, টোকেনের প্রেরক এর মালিক কিনা)। ব্লক যাচাই করার পর, নোডটি স্মার্ট চুক্তির `submitBlock` ফাংশনকে কল করে, যা ব্লক নম্বর এবং Merkle হ্যাশকে প্রান্ত চেইনে সংরক্ষণ করে। স্মার্ট চুক্তি একটি ইভেন্ট তৈরি করে যা একটি ব্লকের সফল সংযোজন নির্দেশ করে। লেনদেন পুল থেকে সরানো হয়.

4. ব্লক জমা দেওয়ার ইভেন্ট প্রাপ্ত নোডগুলি ব্লকে যোগ করা লেনদেনগুলি প্রয়োগ করতে শুরু করে।

5. কিছু সময়ে, টোকেনের মালিক (বা অ-মালিক) প্লাজমা ক্যাশ থেকে এটি প্রত্যাহার করতে চায়। এটি করার জন্য, তিনি 'startExit' ফাংশনকে কল করেন, এতে টোকেনের শেষ 2টি লেনদেন সম্পর্কে তথ্য প্রেরণ করে, যা নিশ্চিত করে যে তিনি টোকেনের মালিক৷ স্মার্ট চুক্তি, মার্কেল হ্যাশ ব্যবহার করে, ব্লকগুলিতে লেনদেনের উপস্থিতি পরীক্ষা করে এবং প্রত্যাহারের জন্য টোকেন পাঠায়, যা দুই সপ্তাহের মধ্যে ঘটবে।

6. যদি টোকেন প্রত্যাহারের ক্রিয়াকলাপ লঙ্ঘনের সাথে ঘটে থাকে (টোকেনটি প্রত্যাহারের প্রক্রিয়া শুরু হওয়ার পরে ব্যয় করা হয়েছিল বা প্রত্যাহারের আগে টোকেনটি ইতিমধ্যেই অন্য কারও ছিল), টোকেনের মালিক দুই সপ্তাহের মধ্যে প্রত্যাহারটি অস্বীকার করতে পারেন।

গোপনীয়তা দুটি উপায়ে অর্জন করা হয়

1. রুট চেইন চাইল্ড চেইনের মধ্যে তৈরি এবং ফরওয়ার্ড করা লেনদেন সম্পর্কে কিছুই জানে না। কে প্লাজমা ক্যাশ থেকে ETH জমা এবং উত্তোলন করেছে সে সম্পর্কে তথ্য সর্বজনীন রয়ে গেছে।

2. চাইল্ড চেইন zk-SNARK ব্যবহার করে বেনামী লেনদেনের অনুমতি দেয়।

প্রযুক্তি স্ট্যাক

• NodeJS
• Redis
• ইথেরিয়াম
• মাটি

পরীক্ষামূলক

প্লাজমা ক্যাশ বিকাশ করার সময়, আমরা সিস্টেমের গতি পরীক্ষা করেছি এবং নিম্নলিখিত ফলাফলগুলি পেয়েছি:

• প্রতি সেকেন্ডে 35 পর্যন্ত লেনদেন পুলে যোগ করা হয়;
• 1 পর্যন্ত লেনদেন একটি ব্লকে সংরক্ষণ করা যেতে পারে।

নিম্নলিখিত 3 সার্ভারে পরীক্ষা করা হয়েছিল:

1. ইন্টেল কোর i7-6700 কোয়াড-কোর স্কাইলেক সহ। NVMe SSD – 512 GB, 64 GB DDR4 RAM
3টি যাচাইকরণ প্লাজমা ক্যাশ নোড উত্থাপিত হয়েছে।

2. AMD Ryzen 7 1700X Octa-core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH নোড উত্থাপিত হয়েছিল।
3টি যাচাইকরণ প্লাজমা ক্যাশ নোড উত্থাপিত হয়েছে।

3. ইন্টেল কোর i9-9900K অক্টা-কোর সহ। NVMe SSD – 1 TB, 64 GB DDR4 RAM
1 প্লাজমা নগদ জমা নোড উত্থাপিত হয়েছে.
3টি যাচাইকরণ প্লাজমা ক্যাশ নোড উত্থাপিত হয়েছে।
প্লাজমা ক্যাশ নেটওয়ার্কে লেনদেন যোগ করার জন্য একটি পরীক্ষা চালু করা হয়েছিল।

মোট: একটি ব্যক্তিগত নেটওয়ার্কে 10টি প্লাজমা ক্যাশ নোড।

পরীক্ষা ১

প্রতি ব্লকে 1 মিলিয়ন লেনদেনের সীমা রয়েছে। অতএব, 1 মিলিয়ন লেনদেন 2টি ব্লকে পড়ে (যেহেতু সিস্টেমটি লেনদেনের অংশ নিতে এবং সেগুলি পাঠানোর সময় জমা দিতে পরিচালনা করে)।

প্রাথমিক অবস্থা: শেষ ব্লক #7; ডাটাবেসে 1 মিলিয়ন লেনদেন এবং টোকেন সংরক্ষণ করা হয়।

00:00 — লেনদেন প্রজন্মের স্ক্রিপ্টের শুরু
01:37 - 1 মিলিয়ন লেনদেন তৈরি করা হয়েছে এবং নোডে পাঠানো শুরু হয়েছে
01:46 — সাবমিট নোড পুল এবং ফর্ম ব্লক #240 থেকে 8k লেনদেন করেছে। আমরা আরও দেখি যে 320 সেকেন্ডের মধ্যে 10k লেনদেন পুলে যোগ করা হয়েছে
01:58 — ব্লক #8 স্বাক্ষরিত এবং যাচাইকরণের জন্য পাঠানো হয়েছে
02:03 — ব্লক #8 যাচাই করা হয়েছে এবং স্মার্ট চুক্তির `submitBlock` ফাংশনটিকে Merkle হ্যাশ এবং ব্লক নম্বর দিয়ে কল করা হয়েছে
02:10 — ডেমো স্ক্রিপ্ট কাজ শেষ করেছে, যা 1 সেকেন্ডে 32 মিলিয়ন লেনদেন পাঠিয়েছে
02:33 - নোডগুলি তথ্য পেতে শুরু করেছে যে ব্লক #8 রুট চেইনে যুক্ত হয়েছে এবং 240k লেনদেন করতে শুরু করেছে
02:40 - 240k লেনদেন পুল থেকে সরানো হয়েছে, যা ইতিমধ্যেই ব্লক #8 এ রয়েছে
02:56 — সাবমিট নোড পুল থেকে অবশিষ্ট 760k লেনদেন নিয়েছে এবং Merkle হ্যাশ এবং সাইনিং ব্লক #9 গণনা করা শুরু করেছে
03:20 - সমস্ত নোডে 1 মিলিয়ন 240k লেনদেন এবং টোকেন রয়েছে
03:35 — ব্লক #9 স্বাক্ষরিত হয়েছে এবং অন্য নোডগুলিতে যাচাইকরণের জন্য পাঠানো হয়েছে
03:41 - নেটওয়ার্ক ত্রুটি ঘটেছে
04:40 — ব্লক #9 যাচাইকরণের অপেক্ষার সময় শেষ হয়েছে
04:54 — সাবমিট নোড পুল থেকে অবশিষ্ট 760k লেনদেন নিয়েছে এবং Merkle হ্যাশ এবং সাইনিং ব্লক #9 গণনা করা শুরু করেছে
05:32 — ব্লক #9 স্বাক্ষরিত হয়েছে এবং অন্য নোডগুলিতে যাচাইকরণের জন্য পাঠানো হয়েছে
05:53 — ব্লক #9 যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
06:17 - নোডগুলি তথ্য পেতে শুরু করেছে যে ব্লক #9 রুট চেইনে যুক্ত হয়েছে এবং 760k লেনদেন করতে শুরু করেছে
06:47 — পুলটি ব্লক #9-এ থাকা লেনদেনগুলি পরিষ্কার করেছে৷
09:06 - সমস্ত নোডে 2 মিলিয়ন লেনদেন এবং টোকেন রয়েছে

পরীক্ষা ১

ব্লক প্রতি 350k একটি সীমা আছে. ফলস্বরূপ, আমাদের 3 টি ব্লক রয়েছে।

প্রাথমিক অবস্থা: শেষ ব্লক #9; 2 মিলিয়ন লেনদেন এবং টোকেন ডাটাবেসে সংরক্ষিত আছে

00:00 — লেনদেন প্রজন্মের স্ক্রিপ্ট ইতিমধ্যেই চালু করা হয়েছে
00:44 - 1 মিলিয়ন লেনদেন তৈরি করা হয়েছে এবং নোডে পাঠানো শুরু হয়েছে
00:56 — সাবমিট নোড পুল এবং ফর্ম ব্লক #320 থেকে 10k লেনদেন করেছে। আমরা আরও দেখি যে 320 সেকেন্ডের মধ্যে 10k লেনদেন পুলে যোগ করা হয়েছে
01:12 — ব্লক #10 স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডগুলিতে পাঠানো হয়েছে
01:18 — ডেমো স্ক্রিপ্ট কাজ শেষ করেছে, যা 1 সেকেন্ডে 34 মিলিয়ন লেনদেন পাঠিয়েছে
01:20 — ব্লক #10 যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
01:51 - সমস্ত নোড রুট চেইন থেকে তথ্য পেয়েছে যে ব্লক #10 যোগ করা হয়েছে এবং 320k লেনদেন প্রয়োগ করা শুরু করেছে
02:01 - ব্লক #320 এ যোগ করা 10k লেনদেনের জন্য পুলটি সাফ হয়েছে
02:15 — জমা নোড পুল থেকে 350k লেনদেন করেছে এবং ব্লক #11 ফর্ম করেছে
02:34 — ব্লক #11 স্বাক্ষরিত হয় এবং যাচাইকরণের জন্য অন্যান্য নোডগুলিতে পাঠানো হয়
02:51 — ব্লক #11 যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
02:55 — শেষ নোড ব্লক #10 থেকে লেনদেন সম্পন্ন করেছে
10:59 — ব্লক #9 জমা দেওয়ার সাথে লেনদেনটি রুট চেইনে খুব দীর্ঘ সময় নেয়, কিন্তু এটি সম্পূর্ণ হয়েছিল এবং সমস্ত নোড এটি সম্পর্কে তথ্য পেয়েছিল এবং 350k লেনদেন করতে শুরু করেছিল
11:05 - ব্লক #320 এ যোগ করা 11k লেনদেনের জন্য পুলটি সাফ হয়েছে
12:10 - সমস্ত নোডে 1 মিলিয়ন 670k লেনদেন এবং টোকেন রয়েছে
12:17 — জমা নোড পুল থেকে 330k লেনদেন করেছে এবং ব্লক #12 ফর্ম করেছে
12:32 — ব্লক #12 স্বাক্ষরিত হয় এবং যাচাইকরণের জন্য অন্যান্য নোডগুলিতে পাঠানো হয়
12:39 — ব্লক #12 যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
13:44 - সমস্ত নোড রুট চেইন থেকে তথ্য পেয়েছে যে ব্লক #12 যোগ করা হয়েছে এবং 330k লেনদেন প্রয়োগ করা শুরু করেছে
14:50 - সমস্ত নোডে 2 মিলিয়ন লেনদেন এবং টোকেন রয়েছে

পরীক্ষা ১

প্রথম এবং দ্বিতীয় সার্ভারে, একটি যাচাইকরণ নোড একটি জমা নোড দ্বারা প্রতিস্থাপিত হয়েছিল।

প্রাথমিক অবস্থা: শেষ ব্লক #84; 0 লেনদেন এবং টোকেন ডাটাবেসে সংরক্ষিত

00:00 — 3টি স্ক্রিপ্ট চালু করা হয়েছে যা প্রতিটি 1 মিলিয়ন লেনদেন তৈরি করে এবং পাঠায়
01:38 — 1 মিলিয়ন লেনদেন তৈরি করা হয়েছে এবং নোড #3 জমা দেওয়ার জন্য পাঠানো শুরু হয়েছে
01:50 — জমা দিন নোড #3 পুল থেকে 330k লেনদেন করেছে এবং ব্লক #85 (f21) ফর্ম করেছে। আমরা আরও দেখি যে 350 সেকেন্ডের মধ্যে 10k লেনদেন পুলে যোগ করা হয়েছে
01:53 — 1 মিলিয়ন লেনদেন তৈরি করা হয়েছে এবং নোড #1 জমা দেওয়ার জন্য পাঠানো শুরু হয়েছে
01:50 — জমা দিন নোড #3 পুল থেকে 330k লেনদেন করেছে এবং ব্লক #85 (f21) ফর্ম করেছে। আমরা আরও দেখি যে 350 সেকেন্ডের মধ্যে 10k লেনদেন পুলে যোগ করা হয়েছে
02:01 — জমা দিন নোড #1 পুল থেকে 250k লেনদেন করেছে এবং ব্লক #85 (65e) ফর্ম করেছে
02:06 — ব্লক #85 (f21) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডে পাঠানো হয়েছে
02:08 — সার্ভার #3 এর ডেমো স্ক্রিপ্ট, যা 1 সেকেন্ডে 30 মিলিয়ন লেনদেন পাঠিয়েছে, কাজ শেষ করেছে
02:14 — ব্লক #85 (f21) যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
02:19 — ব্লক #85 (65e) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডে পাঠানো হয়েছে
02:22 — 1 মিলিয়ন লেনদেন তৈরি করা হয়েছে এবং নোড #2 জমা দেওয়ার জন্য পাঠানো শুরু হয়েছে
02:27 — ব্লক #85 (65e) যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
02:29 — সাবমিট নোড #2 পুল থেকে 111855 লেনদেন করেছে এবং ব্লক #85 (256) ফর্ম করেছে।
02:36 — ব্লক #85 (256) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডগুলিতে পাঠানো হয়েছে
02:36 — সার্ভার #1 এর ডেমো স্ক্রিপ্ট, যা 1 সেকেন্ডে 42.5 মিলিয়ন লেনদেন পাঠিয়েছে, কাজ শেষ করেছে
02:38 — ব্লক #85 (256) যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
03:08 — সার্ভার #2 স্ক্রিপ্ট কাজ শেষ করেছে, যা 1 সেকেন্ডে 47 মিলিয়ন লেনদেন পাঠিয়েছে
03:38 - সমস্ত নোড রুট চেইন থেকে তথ্য পেয়েছে যা ব্লক #85(f21), #86(65e), #87(256) যোগ করা হয়েছে এবং 330k, 250k, 111855 লেনদেন প্রয়োগ করতে শুরু করেছে।
03:49 - পুলটি 330k, 250k, 111855 লেনদেনে সাফ করা হয়েছে যা ব্লক #85 (f21), #86(65e), #87(256) এ যোগ করা হয়েছে
03:59 — জমা দিন নোড #1 পুল থেকে 888145টি লেনদেন করেছে এবং ব্লক #88 (214) ফর্ম করেছে, জমা নোড #2 পুল থেকে 750k লেনদেন করেছে এবং ব্লক #88 (50a) ফর্ম করেছে, জমা নোড #3 থেকে 670k লেনদেন করেছে পুল এবং ফর্ম ব্লক #88 (d3b)
04:44 — ব্লক #88 (d3b) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডে পাঠানো হয়েছে
04:58 — ব্লক #88 (214) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডগুলিতে পাঠানো হয়েছে
05:11 — ব্লক #88 (50a) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডে পাঠানো হয়েছে
05:11 — ব্লক #85 (d3b) যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
05:36 — ব্লক #85 (214) যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
05:43 - সমস্ত নোড রুট চেইন থেকে তথ্য পেয়েছে যা ব্লক #88 (d3b), #89(214) যোগ করা হয়েছে এবং 670k, 750k লেনদেন প্রয়োগ করা শুরু করছে
06:50 — যোগাযোগের ব্যর্থতার কারণে, ব্লক #85 (50a) যাচাই করা হয়নি
06:55 — জমা নোড #2 পুল থেকে 888145টি লেনদেন করেছে এবং ব্লক #90 (50a) ফর্ম করেছে
08:14 — ব্লক #90 (50a) স্বাক্ষরিত হয়েছে এবং যাচাইকরণের জন্য অন্যান্য নোডে পাঠানো হয়েছে
09:04 — ব্লক #90 (50a) যাচাই করা হয়েছে এবং রুট চেইনে পাঠানো হয়েছে
11:23 - সমস্ত নোড রুট চেইন থেকে তথ্য পেয়েছে যে ব্লক #90 (50a) যোগ করা হয়েছে এবং 888145 লেনদেন প্রয়োগ করা শুরু করেছে। একই সময়ে, সার্ভার #3 ইতিমধ্যে ব্লক #88 (d3b), #89 (214) থেকে লেনদেন প্রয়োগ করেছে
12:11 - সমস্ত পুল খালি
13:41 — সার্ভার #3-এর সমস্ত নোডে 3 মিলিয়ন লেনদেন এবং টোকেন রয়েছে
14:35 — সার্ভার #1-এর সমস্ত নোডে 3 মিলিয়ন লেনদেন এবং টোকেন রয়েছে
19:24 — সার্ভার #2-এর সমস্ত নোডে 3 মিলিয়ন লেনদেন এবং টোকেন রয়েছে

বাধা

প্লাজমা ক্যাশের বিকাশের সময়, আমরা নিম্নলিখিত সমস্যার সম্মুখীন হয়েছি, যা আমরা ধীরে ধীরে সমাধান করেছি এবং সমাধান করছি:

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

2. ডেটা স্থানান্তর খরচ কমিয়ে কিভাবে বিপুল সংখ্যক লেনদেন পাঠাতে হয় তা অবিলম্বে পরিষ্কার ছিল না।

3. উচ্চ ফলাফল অর্জনের জন্য কীভাবে এবং কোথায় ডেটা সংরক্ষণ করতে হবে তা পরিষ্কার ছিল না।

4. নোডগুলির মধ্যে একটি নেটওয়ার্ক কীভাবে সংগঠিত করা যায় তা পরিষ্কার ছিল না, যেহেতু 1 মিলিয়ন লেনদেন সহ একটি ব্লকের আকার প্রায় 100 এমবি নেয়।

5. একক-থ্রেডেড মোডে কাজ করা নোডগুলির মধ্যে সংযোগ বিচ্ছিন্ন করে যখন দীর্ঘ গণনা ঘটে (উদাহরণস্বরূপ, একটি মার্কেল গাছ তৈরি করা এবং এর হ্যাশ গণনা করা)।

কিভাবে আমরা এই সব মোকাবেলা?

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

1. বেশ কয়েকটি নোডজেএস প্রসেস চালু করুন, যার প্রতিটি নির্দিষ্ট ফাংশন সম্পাদন করে।

2. worker_threads ব্যবহার করুন এবং কোডের কিছু অংশ থ্রেডে সঞ্চালন করুন।

ফলস্বরূপ, আমরা একই সময়ে উভয় বিকল্প ব্যবহার করেছি: আমরা যৌক্তিকভাবে একটি নোডকে 3 টি অংশে বিভক্ত করেছি যা আলাদাভাবে কাজ করতে পারে, কিন্তু একই সময়ে সিঙ্ক্রোনাসভাবে

1. জমা নোড, যা পুলে লেনদেন গ্রহণ করে এবং ব্লক তৈরি করে।

2. একটি বৈধ নোড যা নোডের বৈধতা পরীক্ষা করে।

3. API নোড - ডেটা অ্যাক্সেস করার জন্য একটি API প্রদান করে।

এই ক্ষেত্রে, আপনি cli ব্যবহার করে একটি ইউনিক্স সকেটের মাধ্যমে প্রতিটি নোডের সাথে সংযোগ করতে পারেন।

আমরা ভারী ক্রিয়াকলাপগুলিকে সরিয়ে নিয়েছি, যেমন মার্কেল গাছের গণনা, একটি পৃথক থ্রেডে।

এইভাবে, আমরা সমস্ত প্লাজমা ক্যাশ ফাংশন একই সাথে এবং ব্যর্থতা ছাড়াই স্বাভাবিক অপারেশন অর্জন করেছি।

সিস্টেমটি কার্যকর হয়ে গেলে, আমরা গতি পরীক্ষা করা শুরু করেছিলাম এবং দুর্ভাগ্যবশত, অসন্তোষজনক ফলাফল পেয়েছি: প্রতি সেকেন্ডে 5 লেনদেন এবং প্রতি ব্লকে 000 পর্যন্ত লেনদেন। কি ভুলভাবে বাস্তবায়িত হয়েছে তা আমাকে খুঁজে বের করতে হয়েছিল।

শুরুতে, আমরা সিস্টেমের সর্বোচ্চ ক্ষমতা খুঁজে বের করতে প্লাজমা ক্যাশের সাথে যোগাযোগের প্রক্রিয়া পরীক্ষা করা শুরু করেছি। আমরা আগে লিখেছিলাম যে প্লাজমা ক্যাশ নোড একটি ইউনিক্স সকেট ইন্টারফেস প্রদান করে। প্রাথমিকভাবে এটি পাঠ্য-ভিত্তিক ছিল। json অবজেক্টগুলি `JSON.parse()` এবং `JSON.stringify()` ব্যবহার করে পাঠানো হয়েছিল।

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

আমরা এই ধরনের বস্তুর স্থানান্তর গতি পরিমাপ করেছি এবং প্রতি সেকেন্ডে ~ 130k পেয়েছি। আমরা json এর সাথে কাজ করার জন্য স্ট্যান্ডার্ড ফাংশনগুলি প্রতিস্থাপন করার চেষ্টা করেছি, কিন্তু কর্মক্ষমতা উন্নত হয়নি। V8 ইঞ্জিন অবশ্যই এই অপারেশনগুলির জন্য ভালভাবে অপ্টিমাইজ করা উচিত।

আমরা ক্লাসের মাধ্যমে লেনদেন, টোকেন এবং ব্লক নিয়ে কাজ করেছি। এই ধরনের ক্লাস তৈরি করার সময়, কর্মক্ষমতা 2 গুণ কমে যায়, যা নির্দেশ করে যে OOP আমাদের জন্য উপযুক্ত নয়। আমাকে সম্পূর্ণরূপে কার্যকরী পদ্ধতিতে সবকিছু পুনরায় লিখতে হয়েছিল।

ডাটাবেসে রেকর্ডিং

প্রাথমিকভাবে, রেডিসকে ডাটা স্টোরেজের জন্য সবচেয়ে বেশি উৎপাদনশীল সমাধান হিসেবে বেছে নেওয়া হয়েছিল যা আমাদের প্রয়োজনীয়তা পূরণ করে: কী-ভ্যালু স্টোরেজ, হ্যাশ টেবিলের সাথে কাজ করা, সেট। আমরা redis-benchmark চালু করেছি এবং 80 পাইপলাইনিং মোডে প্রতি সেকেন্ডে ~1k অপারেশন পেয়েছি।

উচ্চ কর্মক্ষমতার জন্য, আমরা রেডিসকে আরও সূক্ষ্মভাবে টিউন করেছি:

• একটি ইউনিক্স সকেট সংযোগ স্থাপন করা হয়েছে।
• আমরা ডিস্কে স্টেট সংরক্ষণ করা অক্ষম করেছি (নির্ভরযোগ্যতার জন্য, আপনি একটি প্রতিরূপ সেট আপ করতে পারেন এবং একটি পৃথক রেডিসে ডিস্কে সংরক্ষণ করতে পারেন)।

রেডিস-এ, একটি পুল হল একটি হ্যাশ টেবিল কারণ আমাদের এক প্রশ্নের মধ্যে সমস্ত লেনদেন পুনরুদ্ধার করতে এবং একের পর এক লেনদেন মুছে ফেলতে সক্ষম হতে হবে। আমরা একটি নিয়মিত তালিকা ব্যবহার করার চেষ্টা করেছি, কিন্তু সম্পূর্ণ তালিকা আনলোড করার সময় এটি ধীর হয়।

স্ট্যান্ডার্ড নোডজেএস ব্যবহার করার সময়, রেডিস লাইব্রেরিগুলি প্রতি সেকেন্ডে 18k লেনদেনের কার্যক্ষমতা অর্জন করেছে। গতি 9 বার কমেছে।

যেহেতু বেঞ্চমার্ক আমাদের দেখিয়েছে যে সম্ভাবনাগুলি স্পষ্টভাবে 5 গুণ বেশি, আমরা অপ্টিমাইজ করতে শুরু করেছি। আমরা লাইব্রেরিটিকে ioredis-এ পরিবর্তন করেছি এবং প্রতি সেকেন্ডে 25k পারফরম্যান্স পেয়েছি। আমরা `hset` কমান্ড ব্যবহার করে একের পর এক লেনদেন যোগ করেছি। তাই আমরা রেডিসে অনেক প্রশ্ন তৈরি করছিলাম। লেনদেনগুলিকে ব্যাচগুলিতে একত্রিত করার এবং একটি কমান্ড `hmset` দিয়ে সেগুলি পাঠানোর ধারণাটি উদ্ভূত হয়েছিল। ফলাফল প্রতি সেকেন্ডে 32k।

বিভিন্ন কারণে, যা আমরা নীচে বর্ণনা করব, আমরা `Buffer` ব্যবহার করে ডেটা নিয়ে কাজ করি এবং দেখা যাচ্ছে, যদি আপনি লেখার আগে এটিকে টেক্সটে (`buffer.toString('hex')`) রূপান্তর করেন, তাহলে আপনি অতিরিক্ত পেতে পারেন কর্মক্ষমতা. এইভাবে, গতি প্রতি সেকেন্ডে 35k বৃদ্ধি করা হয়েছিল। এই মুহুর্তে, আমরা আরও অপ্টিমাইজেশন স্থগিত করার সিদ্ধান্ত নিয়েছি।

আমাদের একটি বাইনারি প্রোটোকল এ স্যুইচ করতে হয়েছিল কারণ:

1. সিস্টেমটি প্রায়শই হ্যাশ, স্বাক্ষর ইত্যাদি গণনা করে এবং এর জন্য এটির `বাফারে ডেটা প্রয়োজন।

2. পরিষেবাগুলির মধ্যে পাঠানো হলে, বাইনারি ডেটা পাঠ্যের চেয়ে কম ওজনের হয়৷ উদাহরণস্বরূপ, 1 মিলিয়ন লেনদেনের সাথে একটি ব্লক পাঠানোর সময়, পাঠ্যের ডেটা 300 মেগাবাইটের বেশি নিতে পারে।

3. ক্রমাগত ডেটা রূপান্তর কর্মক্ষমতা প্রভাবিত করে।

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

ফলস্বরূপ, আমরা নিম্নলিখিত ডেটা কাঠামো পেয়েছি:

- লেনদেন

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

- টোকেন

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

- ব্লক

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

সাধারণ কমান্ডের সাহায্যে `BD.encode(block, Protocol).slice();` এবং `BD.decode(বাফার, প্রোটোকল)` আমরা Redis-এ সংরক্ষণ বা অন্য নোডে ফরোয়ার্ড করার জন্য ডেটাকে `Buffer`-এ রূপান্তর করি এবং পুনরুদ্ধার করি। তথ্য ফিরে.

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

- ইউনিক্স সকেটের মাধ্যমে প্লাজমা নোডের সাথে ইন্টারঅ্যাকশনের জন্য প্রোটোকল

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

যেখানে:

• `টাইপ` — যে ক্রিয়াটি সম্পাদিত হবে, উদাহরণস্বরূপ, 1 — প্রেরণ লেনদেন, 2 — getTransaction;
• `পেলোড` - উপযুক্ত ফাংশনে পাস করা দরকার এমন ডেটা;
• `মেসেজ আইডি` — বার্তা আইডি যাতে প্রতিক্রিয়া সনাক্ত করা যায়।

- নোডের মধ্যে মিথস্ক্রিয়া জন্য প্রোটোকল

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

যেখানে:

• `কোড` — বার্তা কোড, উদাহরণস্বরূপ 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
• `সংস্করণ প্রোটোকল` — প্রোটোকল সংস্করণ, যেহেতু বিভিন্ন সংস্করণ সহ নোডগুলি নেটওয়ার্কে উত্থাপিত হতে পারে এবং তারা ভিন্নভাবে কাজ করতে পারে;
• `seq` - বার্তা সনাক্তকারী;
• `কাউন্টচাঙ্ক` и `খণ্ড সংখ্যা` বড় বার্তা বিভক্ত করার জন্য প্রয়োজনীয়;
• `দৈর্ঘ্য` и `পেলোড` দৈর্ঘ্য এবং ডেটা নিজেই।

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

আমরা যদি গতিতে পৌঁছাতে সক্ষম হতাম 35 000 প্রতি সেকেন্ডে লেনদেন, আমাদের সর্বোত্তম সময়ে সেগুলি প্রক্রিয়া করতে হবে। যেহেতু আনুমানিক ব্লক গঠনের সময় লাগে 30 সেকেন্ড, আমাদের ব্লকে অন্তর্ভুক্ত করতে হবে 1 000 000 লেনদেন, যার অর্থ আরও পাঠানো 100 MB ডেটা।

প্রাথমিকভাবে, আমরা নোডগুলির মধ্যে যোগাযোগের জন্য `ethereumjs-devp2p` লাইব্রেরি ব্যবহার করেছি, কিন্তু এটি এত বেশি ডেটা পরিচালনা করতে পারেনি। ফলস্বরূপ, আমরা `ws` লাইব্রেরি ব্যবহার করেছি এবং ওয়েবসকেটের মাধ্যমে বাইনারি ডেটা পাঠানো কনফিগার করেছি। অবশ্যই, আমরা বড় ডাটা প্যাকেট পাঠানোর সময় সমস্যার সম্মুখীন হয়েছিলাম, কিন্তু আমরা সেগুলিকে খণ্ডে ভাগ করেছি এবং এখন এই সমস্যাগুলি চলে গেছে।

এছাড়াও একটি Merkle গাছ গঠন এবং হ্যাশ গণনা 1 000 000 লেনদেন সম্পর্কে প্রয়োজন 10 ক্রমাগত গণনার সেকেন্ড। এই সময়ের মধ্যে, সমস্ত নোডের সাথে সংযোগ বিরতি পরিচালনা করে। এই গণনাটি একটি পৃথক থ্রেডে সরানোর সিদ্ধান্ত নেওয়া হয়েছিল।

সিদ্ধান্তে:

প্রকৃতপক্ষে, আমাদের অনুসন্ধানগুলি নতুন নয়, তবে কিছু কারণে অনেক বিশেষজ্ঞ বিকাশের সময় তাদের সম্পর্কে ভুলে যান।

• অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের পরিবর্তে ফাংশনাল প্রোগ্রামিং ব্যবহার করলে উৎপাদনশীলতা উন্নত হয়।
• মনোলিথ একটি উত্পাদনশীল নোডজেএস সিস্টেমের জন্য একটি পরিষেবা আর্কিটেকচারের চেয়ে খারাপ।
• ভারী গণনার জন্য `worker_threads` ব্যবহার করা সিস্টেমের প্রতিক্রিয়াশীলতাকে উন্নত করে, বিশেষ করে i/o অপারেশনগুলির সাথে ডিল করার সময়।
• ইউনিক্স সকেট http অনুরোধের তুলনায় আরো স্থিতিশীল এবং দ্রুত।
• আপনি যদি নেটওয়ার্কের মাধ্যমে দ্রুত বড় ডেটা স্থানান্তর করতে চান, তাহলে ওয়েবসকেটগুলি ব্যবহার করা এবং বাইনারি ডেটা পাঠানো ভাল, খণ্ডে বিভক্ত, যা না পৌঁছালে ফরোয়ার্ড করা যেতে পারে এবং তারপরে একটি বার্তায় একত্রিত করা যেতে পারে।

আমরা আপনাকে পরিদর্শন করার আমন্ত্রণ জানাই GitHub প্রকল্প: https://github.com/opporty-com/Plasma-Cash/tree/new-version

নিবন্ধটি সহ-লিখিত আলেকজান্ডার নাশিভান, সিনিয়র ডেভেলপার Clever Solution Inc.

উত্স: www.habr.com