ভূমিকা

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

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

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

PVRB বাস্তবায়নের দুটি উপায়

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

স্বতন্ত্র চুক্তি

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

স্বতন্ত্র-চুক্তি সহ বিকল্পটি ভাল:

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

এর অসুবিধাও রয়েছে:

• কম্পিউটিং সংস্থান, লেনদেনের পরিমাণ এবং সঞ্চয়স্থানের উপর শক্তিশালী সীমাবদ্ধতা (অন্য কথায়, cpu/mem/io)
• চুক্তির মধ্যে ক্রিয়াকলাপের উপর নিষেধাজ্ঞা (সমস্ত নির্দেশাবলী উপলব্ধ নয়, বহিরাগত লাইব্রেরি সংযোগ করা কঠিন)
• লেনদেনের চেয়ে দ্রুত মেসেজিং সংগঠিত করতে অক্ষমতা ব্লকচেইনের অন্তর্ভুক্ত

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

ঐক্যমত্য-সমন্বিত

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

নেটওয়ার্ক কনসেনসাস লেভেলে PVRB বাস্তবায়নের বর্ণনা দেওয়ার সময়, কেউ কোনোভাবেই চূড়ান্ত সমস্যা এড়াতে পারে না। চূড়ান্ততা হল এমন একটি প্রক্রিয়া যা নির্ধারক সম্মতিতে ব্যবহৃত হয় যা একটি ব্লকে লক করে (এবং এটির দিকে নিয়ে যাওয়া চেইন) যা চূড়ান্ত এবং কখনোই ফেলে দেওয়া হবে না, এমনকি যদি একটি সমান্তরাল কাঁটা দেখা দেয়। উদাহরণ স্বরূপ, বিটকয়েনে এমন কোন প্রক্রিয়া নেই - আপনি যদি বেশি জটিলতার একটি চেইন প্রকাশ করেন, তবে এটি চেইনের দৈর্ঘ্য নির্বিশেষে যেকোনো কম জটিল একটিকে প্রতিস্থাপন করবে। এবং ইওএস-এ, উদাহরণস্বরূপ, চূড়ান্তগুলি হল তথাকথিত শেষ অপরিবর্তনীয় ব্লক, যা গড়ে প্রতি 432টি ব্লকে উপস্থিত হয় (12*21 + 12*15, প্রি-ভোট + প্রি-কমিট)। এই প্রক্রিয়াটি মূলত 2/3 ব্লক-প্রযোজকদের (এর পরে বিপি হিসাবে উল্লেখ করা হয়েছে) স্বাক্ষরের জন্য অপেক্ষা করছে। যখন কাঁটাগুলি দেখা যায় যেগুলি শেষ LIB থেকে পুরানো, তখন সেগুলিকে ফেলে দেওয়া হয়। এই প্রক্রিয়াটি গ্যারান্টি দেওয়া সম্ভব করে যে লেনদেনটি ব্লকচেইনে অন্তর্ভুক্ত করা হয়েছে এবং আক্রমণকারীর কাছে যে সম্পদই থাকুক না কেন তা কখনই ফিরিয়ে আনা হবে না। এছাড়াও, চূড়ান্ত ব্লকগুলি হাইপারলেজার, টেন্ডারমিন্ট এবং অন্যান্য pBFT-ভিত্তিক সম্মতিতে 2/3 BP দ্বারা স্বাক্ষরিত ব্লক। এছাড়াও, চূড়ান্ততা নিশ্চিত করার জন্য একটি প্রোটোকল তৈরি করা বোধগম্য হয় একটি ঐক্যমতের জন্য একটি অ্যাড-অন, যেহেতু এটি ব্লকগুলির উত্পাদন এবং প্রকাশনার সাথে অ্যাসিঙ্ক্রোনাসভাবে কাজ করতে পারে। এখানে একটি ভাল এক একটি নিবন্ধ Ethereum মধ্যে চূড়ান্ত সম্পর্কে.

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

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

ঐকমত্য-সংহত বিকল্পটি ভাল:

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

এর অসুবিধাও রয়েছে:

• পরীক্ষা এবং উন্নয়নে অসুবিধা - আপনাকে নেটওয়ার্ক ত্রুটি, অনুপস্থিত নোড, নেটওয়ার্ক হার্ড ফর্ক অনুকরণ করতে হবে
• বাস্তবায়ন ত্রুটি একটি নেটওয়ার্ক hardfork প্রয়োজন

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

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

PVRB এবং ব্লক ভেরিয়েবল।

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

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

কিন্তু এমনকি পোস্ট-কোয়ান্টাম সুরক্ষিত হ্যাশ যথেষ্ট নয়, হায়। গোপন PVRB এর প্রয়োজনীয়তার মধ্যে রয়েছে, আমাকে আগের নিবন্ধ থেকে সেগুলি মনে করিয়ে দিতে দিন:

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

এই ক্ষেত্রে, শুধুমাত্র প্রয়োজন 1 পূরণ করা হয়, এবং প্রয়োজন 2 পূরণ করা হয় না। ব্লক থেকে অপ্রত্যাশিত মান হ্যাশ করার মাধ্যমে, আমরা একটি অভিন্ন বিতরণ এবং ভাল র্যান্ডম পাব। তবে বিপির অন্তত "ব্লক প্রকাশ করুন বা না" করার বিকল্প রয়েছে। এইভাবে, BP কমপক্ষে দুটি র্যান্ডম বিকল্প থেকে বেছে নিতে পারে: "নিজের" এবং অন্য কেউ ব্লক তৈরি করলে যেটি পরিণত হবে। BP আগে থেকে "স্নুপ" করতে পারে যদি সে একটি ব্লক প্রকাশ করে তাহলে কি হবে, এবং সহজভাবে সিদ্ধান্ত নেয় যে এটি করা বা না করা হবে। এইভাবে, খেলার সময়, উদাহরণস্বরূপ, "জোড়-বিজোড়" বা "লাল/কালো" রুলেটে, তিনি একটি ব্লক প্রকাশ করতে পারেন যদি তিনি একটি জয় দেখেন। এটি ব্যবহার করার কৌশলটিকেও করে তোলে, উদাহরণস্বরূপ, একটি ব্লক হ্যাশ "ভবিষ্যত থেকে" অকার্যকর। এই ক্ষেত্রে, তারা বলে যে "র্যান্ডম ব্যবহার করা হবে, যা বর্তমান ডেটা এবং ভবিষ্যতের ব্লকের হ্যাশের একটি উচ্চতা সহ প্রাপ্ত করা হয়, উদাহরণস্বরূপ, N + 42, যেখানে N হল বর্তমান ব্লকের উচ্চতা। এটি স্কিমটিকে কিছুটা শক্তিশালী করে, কিন্তু তবুও BP-কে অনুমতি দেয়, যদিও ভবিষ্যতে, ব্লক রাখা বা প্রকাশ করা হবে কিনা তা বেছে নিতে।

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

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

PVRB এবং কমিট-প্রকাশ.

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

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

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

PVRB এবং নির্ধারক স্বাক্ষর।

RP-কে একটি ছদ্ম-এলোমেলো নম্বর প্রদান করতে বাধ্য করার আরেকটি উপায় আছে যা "প্রি-ইমেজ" প্রদান করা হলে এটি প্রভাবিত করতে পারে না - এটি একটি নির্ধারক স্বাক্ষর। যেমন একটি স্বাক্ষর, উদাহরণস্বরূপ, RSA, এবং ECS নয়। যদি RP-এর কাছে একজোড়া কী থাকে: RSA এবং ECC, এবং তিনি তার ব্যক্তিগত কী দিয়ে একটি নির্দিষ্ট মান স্বাক্ষর করেন, তাহলে RSA-এর ক্ষেত্রে তিনি এক এবং শুধুমাত্র একটি স্বাক্ষর পাবেন এবং ECS-এর ক্ষেত্রে তিনি যেকোনো সংখ্যা তৈরি করতে পারবেন। বিভিন্ন বৈধ স্বাক্ষর। এর কারণ হল একটি ECS স্বাক্ষর তৈরি করার সময়, একটি এলোমেলো নম্বর ব্যবহার করা হয়, যা স্বাক্ষরকারীর দ্বারা নির্বাচিত হয়, এবং এটি যেকোনো উপায়ে নির্বাচন করা যেতে পারে, যা স্বাক্ষরকারীকে একাধিক স্বাক্ষরের মধ্যে একটি বেছে নেওয়ার সুযোগ দেয়৷ RSA এর ক্ষেত্রে: "এক ইনপুট মান" + "একটি কী জোড়া" = "একটি স্বাক্ষর"। অন্য RP কী স্বাক্ষর পাবে তা পূর্বাভাস দেওয়া অসম্ভব, তাই একই মান স্বাক্ষরকারী বেশ কয়েকটি অংশগ্রহণকারীদের RSA স্বাক্ষর একত্রিত করে একটি PVRB নির্ধারণমূলক স্বাক্ষর সংগঠিত করা যেতে পারে। উদাহরণস্বরূপ, আগের র্যান্ডম. এই স্কিম অনেক সম্পদ সংরক্ষণ করে, কারণ স্বাক্ষর উভয়ই প্রোটোকল অনুসারে সঠিক আচরণের নিশ্চিতকরণ এবং এলোমেলোতার উত্স।

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

PVRB এবং গোপন শেয়ারিং স্কিম

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

যদি এফএসএসএস (ফিয়াট-শামির সিক্রেট শেয়ারিং) স্কিমটি তার বিশুদ্ধ আকারে প্রযোজ্য হয় তবে এটি একটি অবিনশ্বর PVRB হবে। এর সহজতম আকারে, প্রোটোকলটি এইরকম দেখতে পারে:

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

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

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

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

PVRB এবং থ্রেশহোল্ড স্বাক্ষর

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

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

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

থ্রেশহোল্ড BLS স্বাক্ষর সহ একটি স্কিমে, প্রতিটি অংশগ্রহণকারী BLS ব্যবহার করে কিছু স্বাক্ষর করে (উদাহরণস্বরূপ, আগের এলোমেলো), এবং সাধারণ থ্রেশহোল্ড স্বাক্ষরটি কাঙ্ক্ষিত র্যান্ডম। BLS স্বাক্ষরগুলির ক্রিপ্টোগ্রাফিক বৈশিষ্ট্যগুলি এলোমেলো মানের জন্য প্রয়োজনীয়তাগুলিকে সন্তুষ্ট করে, থ্রেশহোল্ড অংশটি "শেষ-অভিনেতা" থেকে রক্ষা করে এবং কীগুলির অনন্য সমন্বয় এটিকে আরও অনেক আকর্ষণীয় অ্যালগরিদম প্রয়োগ করা সম্ভব করে যা উদাহরণস্বরূপ, প্রোটোকল বার্তাগুলির দক্ষ একত্রিতকরণের অনুমতি দেয় .

সুতরাং, আপনি যদি আপনার ব্লকচেইনে PVRB তৈরি করেন, তাহলে আপনি সম্ভবত BLS থ্রেশহোল্ড স্বাক্ষর স্কিমটি শেষ করবেন, বেশ কয়েকটি প্রকল্প ইতিমধ্যেই এটি ব্যবহার করছে। উদাহরণস্বরূপ, DFinity (এখানে বেঞ্চমার্ক যে সার্কিট বাস্তবায়ন করে, এবং এখানে যাচাইযোগ্য গোপন ভাগ করে নেওয়ার উদাহরণ বাস্তবায়ন), বা Keep.network (এখানে তাদের র্যান্ডম বীকন রয়েছে হলুদ কাগজ, কিন্তু উদাহরণ প্রোটোকল পরিবেশনকারী স্মার্ট চুক্তি)।

PVRB বাস্তবায়ন

দুর্ভাগ্যবশত, আমরা এখনও PVRB ব্লকচেইনে বাস্তবায়িত একটি তৈরি প্রোটোকল দেখতে পাচ্ছি না যা এর নিরাপত্তা এবং স্থিতিশীলতা প্রমাণ করেছে। যদিও প্রোটোকলগুলি নিজেই প্রস্তুত, প্রযুক্তিগতভাবে তাদের বিদ্যমান সমাধানগুলিতে প্রয়োগ করা সহজ নয়। কেন্দ্রীভূত সিস্টেমের জন্য, PVRB এর কোন মানে হয় না, এবং বিকেন্দ্রীকৃতগুলি কঠোরভাবে সমস্ত কম্পিউটিং সংস্থানগুলিতে সীমাবদ্ধ: CPU, মেমরি, স্টোরেজ, I/O। একটি PVRB ডিজাইন করা হল বিভিন্ন প্রোটোকলের সংমিশ্রণ যাতে এমন কিছু তৈরি করা যায় যা অন্তত কিছু কার্যকর ব্লকচেইনের জন্য সমস্ত প্রয়োজনীয়তা পূরণ করে। একটি প্রোটোকল আরও দক্ষতার সাথে গণনা করে, কিন্তু RP-এর মধ্যে আরও বার্তার প্রয়োজন হয়, অন্যটির জন্য খুব কম বার্তার প্রয়োজন হয়, তবে একটি প্রমাণ তৈরি করা এমন একটি কাজ হতে পারে যা কয়েক মিনিট বা এমনকি ঘন্টাও নেয়।

একটি মানসম্পন্ন PVRB নির্বাচন করার সময় আপনাকে যে বিষয়গুলি বিবেচনা করতে হবে তা আমি তালিকাভুক্ত করব:

• ক্রিপ্টোগ্রাফিক শক্তি. আপনার PVRB অবশ্যই কঠোরভাবে নিরপেক্ষ হতে হবে, এক বিট নিয়ন্ত্রণ করার ক্ষমতা নেই। কিছু স্কিমে এটি হয় না, তাই একজন ক্রিপ্টোগ্রাফারকে কল করুন
• "শেষ অভিনেতা" সমস্যা. আপনার PVRB অবশ্যই আক্রমণ প্রতিরোধী হতে হবে যেখানে এক বা একাধিক RPs নিয়ন্ত্রণকারী আক্রমণকারী দুটি ফলাফলের মধ্যে একটি বেছে নিতে পারে।
• প্রোটোকল নাশকতা সমস্যা. আপনার PVRB অবশ্যই আক্রমণ প্রতিরোধী হতে হবে যেখানে একজন বা একাধিক RPs নিয়ন্ত্রণকারী আক্রমণকারী সিদ্ধান্ত নেয় যে র্যান্ডম হবে কি না এবং হয় গ্যারান্টি দেওয়া যেতে পারে বা এটিকে প্রভাবিত করার প্রদত্ত সম্ভাবনা সহ
• বার্তার সংখ্যা সমস্যা. আপনার RP-এর উচিত ব্লকচেইনে ন্যূনতম বার্তা পাঠানো এবং যতটা সম্ভব সিঙ্ক্রোনাস অ্যাকশন এড়ানো উচিত যেমন পরিস্থিতি যেমন "আমি কিছু তথ্য পাঠিয়েছি, আমি একজন নির্দিষ্ট অংশগ্রহণকারীর প্রতিক্রিয়ার জন্য অপেক্ষা করছি।" p2p নেটওয়ার্কে, বিশেষ করে ভৌগলিকভাবে ছড়িয়ে ছিটিয়ে থাকা নেটওয়ার্কগুলিতে, আপনার দ্রুত প্রতিক্রিয়ার উপর নির্ভর করা উচিত নয়
• গণনাগত জটিলতার সমস্যা. PVRB অন-চেইনের যেকোনো পর্যায়ের যাচাইকরণ অত্যন্ত সহজ হওয়া উচিত, কারণ এটি নেটওয়ার্কের সমস্ত সম্পূর্ণ ক্লায়েন্ট দ্বারা সঞ্চালিত হয়। যদি বাস্তবায়ন একটি স্মার্ট চুক্তি ব্যবহার করে সম্পন্ন করা হয়, তাহলে গতির প্রয়োজনীয়তাগুলি খুব কঠোর
• অ্যাক্সেসযোগ্যতা এবং সজীবতার সমস্যা. আপনার PVRB-কে এমন পরিস্থিতিতে স্থিতিস্থাপক হওয়ার চেষ্টা করা উচিত যেখানে নেটওয়ার্কের কিছু অংশ নির্দিষ্ট সময়ের জন্য অনুপলব্ধ হয়ে যায় এবং RP-এর কিছু অংশ কাজ করা বন্ধ করে দেয়।
• বিশ্বস্ত সেটআপ এবং প্রাথমিক কী বিতরণের সমস্যা. যদি আপনার PVRB প্রোটোকলের প্রাথমিক সেটআপ ব্যবহার করে, তাহলে এটি একটি আলাদা বড় এবং গুরুতর গল্প। এখানে উদাহরণ. প্রোটোকল শুরু করার আগে যদি অংশগ্রহণকারীদের একে অপরকে তাদের কী বলতে হয়, তবে অংশগ্রহণকারীদের গঠন পরিবর্তন হলে এটিও একটি সমস্যা।
• উন্নয়ন সমস্যা. প্রয়োজনীয় ভাষায় গ্রন্থাগারের প্রাপ্যতা, তাদের নিরাপত্তা এবং কর্মক্ষমতা, প্রচার, জটিল পরীক্ষা ইত্যাদি।

উদাহরণস্বরূপ, থ্রেশহোল্ড বিএলএস স্বাক্ষরগুলির একটি উল্লেখযোগ্য সমস্যা রয়েছে - কাজ শুরু করার আগে, অংশগ্রহণকারীদের অবশ্যই একে অপরের কাছে কী বিতরণ করতে হবে, একটি গ্রুপ সংগঠিত করতে হবে যার মধ্যে থ্রেশহোল্ড কাজ করবে। এর মানে হল যে একটি বিকেন্দ্রীভূত নেটওয়ার্কে অন্তত এক রাউন্ডের বিনিময়ের জন্য অপেক্ষা করতে হবে, এবং প্রদত্ত যে জেনারেটেড র্যান্ড, উদাহরণস্বরূপ, গেমগুলিতে প্রয়োজনীয়, প্রায় বাস্তব সময়ে, এর অর্থ হল এই পর্যায়ে প্রোটোকলের নাশকতা সম্ভব। , এবং থ্রেশহোল্ড স্কিমের সুবিধাগুলি হারিয়ে গেছে। এই সমস্যাটি পূর্ববর্তীগুলির তুলনায় ইতিমধ্যেই সহজ, তবে এখনও থ্রেশহোল্ড গ্রুপ গঠনের জন্য একটি পৃথক পদ্ধতির বিকাশের প্রয়োজন, যা অনুসৃত অংশগ্রহণকারীদের কাছ থেকে আমানত এবং তহবিল উত্তোলনের মাধ্যমে (স্ল্যাশিং) অর্থনৈতিকভাবে রক্ষা করতে হবে। প্রোটোকল এছাড়াও, একটি গ্রহণযোগ্য স্তরের নিরাপত্তা সহ BLS যাচাইকরণ সহজভাবে মাপসই হয় না, উদাহরণস্বরূপ, একটি স্ট্যান্ডার্ড EOS বা Ethereum লেনদেনে - যাচাইকরণের জন্য পর্যাপ্ত সময় নেই। চুক্তি কোড হল WebAssembly বা EVM, একটি ভার্চুয়াল মেশিন দ্বারা সম্পাদিত। ক্রিপ্টোগ্রাফিক ফাংশনগুলি স্থানীয়ভাবে (এখনও) প্রয়োগ করা হয় না এবং প্রচলিত ক্রিপ্টোগ্রাফিক লাইব্রেরির তুলনায় দশগুণ ধীর গতিতে কাজ করে। অনেক প্রোটোকল কেবল কী ভলিউমের উপর ভিত্তি করে প্রয়োজনীয়তা পূরণ করে না, উদাহরণস্বরূপ RSA-এর জন্য 1024 এবং 2048 বিট, Bitcoin এবং Ethereum-এ স্ট্যান্ডার্ড লেনদেনের স্বাক্ষরের চেয়ে 4-8 গুণ বড়।

বিভিন্ন প্রোগ্রামিং ভাষায় বাস্তবায়নের উপস্থিতিও একটি ভূমিকা পালন করে - যার মধ্যে কয়েকটি রয়েছে, বিশেষ করে নতুন প্রোটোকলের জন্য। ঐকমত্যের সাথে একীকরণের বিকল্পটির জন্য প্ল্যাটফর্মের ভাষায় একটি প্রোটোকল লেখার প্রয়োজন, তাই আপনাকে গো ফর গেথে, রাস্ট ফর প্যারিটিতে, EOS-এর জন্য C++-এ কোড খুঁজতে হবে। প্রত্যেককে জাভাস্ক্রিপ্ট কোড খুঁজতে হবে, এবং যেহেতু জাভাস্ক্রিপ্ট এবং ক্রিপ্টোগ্রাফি বিশেষভাবে ঘনিষ্ঠ বন্ধু নয়, তাই WebAssembly সাহায্য করবে, যা এখন নিশ্চিতভাবে পরবর্তী গুরুত্বপূর্ণ ইন্টারনেট স্ট্যান্ডার্ড বলে দাবি করে।

উপসংহার

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

বাই, ব্লকচেইনে আমাদের PVRB ডেভেলপ করা হচ্ছে Haya,, আমরা থ্রেশহোল্ড BLS স্বাক্ষর ব্যবহার করার বিষয়ে স্থির হয়েছি, আমরা সর্বসম্মত স্তরে PVRB বাস্তবায়নের পরিকল্পনা করছি, যেহেতু একটি গ্রহণযোগ্য স্তরের নিরাপত্তা সহ স্মার্ট চুক্তিতে যাচাইকরণ এখনও সম্ভব নয়। এটা সম্ভব যে আমরা একসাথে দুটি স্কিম ব্যবহার করি: প্রথমত, দীর্ঘমেয়াদী র্যান্ডম_সিড তৈরি করতে ব্যয়বহুল গোপন ভাগাভাগি, এবং তারপরে আমরা এটিকে নির্ধারক থ্রেশহোল্ড বিএলএস স্বাক্ষর ব্যবহার করে উচ্চ-ফ্রিকোয়েন্সি র্যান্ডম জেনারেশনের ভিত্তি হিসাবে ব্যবহার করি, সম্ভবত আমরা নিজেদেরকে শুধুমাত্র সীমাবদ্ধ রাখব। স্কিমগুলির মধ্যে একটি। দুর্ভাগ্যবশত, প্রোটোকলটি কী হবে তা আগে থেকে বলা অসম্ভব; একমাত্র ভাল জিনিস হল, বিজ্ঞানের মতো, ইঞ্জিনিয়ারিং সমস্যাগুলির ক্ষেত্রেও একটি নেতিবাচক ফলাফল হয় এবং সমস্যা সমাধানের প্রতিটি নতুন প্রচেষ্টা অন্য একটি পদক্ষেপ। সমস্যার সাথে জড়িত প্রত্যেকের গবেষণা। ব্যবসায়িক প্রয়োজনীয়তা পূরণের জন্য, আমরা একটি নির্দিষ্ট ব্যবহারিক সমস্যা সমাধান করি - এনট্রপির একটি নির্ভরযোগ্য উৎস সহ গেমিং অ্যাপ্লিকেশন সরবরাহ করা, তাই আমাদেরকে ব্লকচেইনের দিকেও মনোযোগ দিতে হবে, বিশেষ করে চেইন চূড়ান্ততা এবং নেটওয়ার্ক পরিচালনার বিষয়গুলিতে।

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

সুতরাং, আপনি যখন বিকেন্দ্রীভূত এলোমেলো ডিজাইনিং প্রোগ্রামারের সাথে দেখা করেন, তখন মনোযোগী হন এবং যত্নশীল হন এবং প্রয়োজনে মনস্তাত্ত্বিক সহায়তা প্রদান করুন :)

উত্স: www.habr.com