স্টকের প্রমাণে ইথেরিয়ামের রূপান্তর - দ্য মার্জ - কাছাকাছি:devnets দাঁড় করানো হচ্ছে, স্পেসিফিকেশন চূড়ান্ত করা হচ্ছে এবং কমিউনিটির আউটরিচ আন্তরিকভাবে শুরু হয়েছে। Ethereum কীভাবে শেষ ব্যবহারকারী, স্মার্ট চুক্তি এবং ড্যাপসের জন্য কাজ করে তার উপর ন্যূনতম প্রভাব রাখার জন্য মার্জটি ডিজাইন করা হয়েছে। বলেছে, হাইলাইট করার মতো কিছু ছোটখাটো পরিবর্তন আছে। আমরা তাদের মধ্যে ডুব দেওয়ার আগে, সামগ্রিক মার্জ আর্কিটেকচার সম্পর্কে প্রসঙ্গ সরবরাহ করার জন্য এখানে কয়েকটি লিঙ্ক রয়েছে:
এই পোস্টের বাকি অংশ অনুমান করবে পাঠক উপরের সাথে পরিচিত। যারা আরও গভীরে খনন করতে চান তাদের জন্য, The Merge-এর সম্পূর্ণ স্পেসিফিকেশন এখানে উপলব্ধ:
একত্রিত হওয়ার পরে, নেটওয়ার্কে কাজের ব্লকের প্রমাণ আর থাকবে না। পরিবর্তে, কাজের প্রমাণের পূর্ববর্তী বিষয়বস্তু বীকন চেইনে তৈরি ব্লকগুলির একটি উপাদান হয়ে ওঠে। তারপরে আপনি বীকন চেইনটিকে Ethereum-এর স্টেক কনসেনসাস লেয়ারের নতুন প্রমাণ হিসাবে ভাবতে পারেন, কাজের সম্মতি স্তরের আগের প্রমাণটিকে ছাড়িয়ে যাচ্ছে৷ বীকন চেইন ব্লকে ExecutionPayloads থাকবে , যা কাজের শৃঙ্খলের বর্তমান প্রমাণে ব্লকের-পরবর্তী সমতুল্য। নীচের ছবিটি এই সম্পর্ক দেখায়:
শেষ ব্যবহারকারী এবং অ্যাপ্লিকেশন বিকাশকারীদের জন্য, এই ExecutionPayloads যেখানে ইথেরিয়ামের সাথে মিথস্ক্রিয়া ঘটে। এই স্তরের লেনদেনগুলি এখনও এক্সিকিউশন লেয়ার ক্লায়েন্ট (বেসু, এরিগন, গেথ, নেদারমাইন্ড, ইত্যাদি) দ্বারা প্রক্রিয়া করা হবে। সৌভাগ্যবশত, এক্সিকিউশন লেয়ারের স্থায়িত্বের কারণে, মার্জ শুধুমাত্র ন্যূনতম ব্রেকিং পরিবর্তনগুলি প্রবর্তন করে৷
একত্রীকরণের পরে, কাজের ব্লক হেডারের প্রমাণে পূর্বে থাকা বেশ কয়েকটি ক্ষেত্র অব্যবহৃত হয়ে পড়ে কারণ সেগুলি স্টেকের প্রমাণের জন্য অপ্রাসঙ্গিক। টুলিং এবং অবকাঠামোতে বিঘ্ন কমানোর জন্য, এই ক্ষেত্রগুলিকে 0 এ সেট করা হয়েছে, বা তাদের ডেটা স্ট্রাকচারের সমতুল্য, ডাটা স্ট্রাকচার থেকে সম্পূর্ণরূপে সরানোর পরিবর্তে। ব্লক ক্ষেত্রগুলির সম্পূর্ণ পরিবর্তনগুলি EIP-3675 এ পাওয়া যাবে৷
৷ওমারস [] RLP([]) =0xc0 ommersHash 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 =Keccak256(RLP([])) কঠিনতা 0 nonce 0x0000000000000000
যেহেতু স্টেকের প্রমাণ স্বাভাবিকভাবে কাজের প্রমাণের মতো ওমার (ওরফে আঙ্কেল ব্লক) তৈরি করে না, তাই প্রতিটি ব্লকে এইগুলির তালিকা (ওমার ) খালি থাকবে, এবং এই তালিকার হ্যাশ (ommersHash ) একটি খালি তালিকার RLP-এনকোডেড হ্যাশ হয়ে যাবে। একইভাবে, কারণ কঠিনতা এবং nonce কাজের প্রমাণের বৈশিষ্ট্য, এগুলি 0 এ সেট করা হবে , তাদের বাইট-আকারের মানকে সম্মান করার সময়।
মিক্সহ্যাশ , আরেকটি খনন-সম্পর্কিত ক্ষেত্র, 0 তে সেট করা হবে না কিন্তু এর পরিবর্তে বীকন চেইনের RANDAO মান থাকবে। নীচে এই সম্পর্কে আরো.
ব্লকহ্যাশ &কঠিনতা অপকোড পরিবর্তনগুলি
মার্জ-এর পরে, BLOCKHASH অপকোড এখনও ব্যবহারের জন্য উপলব্ধ থাকবে, তবে কাজের হ্যাশিং প্রক্রিয়ার প্রমাণের মাধ্যমে এটি আর জাল করা হবে না, এই অপকোড দ্বারা প্রদত্ত সিউডোর্যান্ডমনেস অনেক দুর্বল হবে৷
সম্পর্কিতভাবে, কঠিনতা opcode (0x44 ) আপডেট করা হবে এবং RANDOM নামকরণ করা হবে . মার্জ করার পরে, এটি বীকন চেইন দ্বারা প্রদত্ত এলোমেলোতা বীকনের আউটপুট ফিরিয়ে দেবে। এই অপকোডটি আরও শক্তিশালী হবে, যদিও এখনও পক্ষপাতদুষ্ট, অ্যাপ্লিকেশন বিকাশকারীদের জন্য BLOCKHASH ব্যবহার করার জন্য এলোমেলোতার উত্স .
RANDOM দ্বারা প্রকাশিত মান ExecutionPayload-এ সংরক্ষণ করা হবে যেখানে মিক্সহ্যাশ , কাজের গণনার প্রমাণের সাথে যুক্ত একটি মান সংরক্ষণ করা হয়েছিল। পেলোডের mixHash ক্ষেত্রটির নামও এলোমেলো হবে৷ .
এখানে কঠিনতা এর একটি দৃষ্টান্ত রয়েছে &RANDOM অপকোডগুলি একত্রিত হওয়ার আগে এবং পরে কাজ করে:
প্রি-মার্জ, আমরা 0x44 দেখতে পাই opcode কঠিনতা প্রদান করে ব্লক হেডারে ক্ষেত্র। মার্জ-পরবর্তী, অপকোড, নাম পরিবর্তন করে RANDOM রাখা হয়েছে , শিরোনাম ক্ষেত্রের দিকে নির্দেশ করে যেখানে পূর্বে mixHash ছিল এবং এখন এলোমেলো সঞ্চয় করে বীকন চেইন অবস্থা থেকে মান।
এই পরিবর্তনটি, EIP-4399-এ আনুষ্ঠানিক, অন-চেইন অ্যাপ্লিকেশনগুলিকে মার্জ হয়েছে কিনা তা মূল্যায়ন করার একটি উপায় প্রদান করে। EIP থেকে:
উপরন্তু, এই EIP দ্বারা প্রস্তাবিত পরিবর্তনগুলি স্মার্ট চুক্তিগুলিকে নির্ধারণ করতে দেয় যে PoS-এ আপগ্রেড ইতিমধ্যেই হয়েছে কিনা। এটি অসুবিধা অপকোডের রিটার্ন মান বিশ্লেষণ করে করা যেতে পারে।
2**64এর থেকে বড় একটি মান নির্দেশ করে যে লেনদেনটি PoS ব্লকে সম্পাদিত হচ্ছে।
মার্জ ইথেরিয়ামের গড় ব্লক সময়কে প্রভাবিত করবে। বর্তমানে কাজের প্রমাণের অধীনে, ব্লক আসে গড়ে প্রতি ~13 সেকেন্ডে প্রকৃত ব্লকের সময়ের মধ্যে ন্যায্য পরিমাণে বৈচিত্র্য সহ। স্টকের প্রমাণের অধীনে, ব্লকগুলি ঠিক প্রতি 12 সেকেন্ডে আসে যখন একটি স্লট মিস হয় কারণ হয় একটি বৈধকারী অফলাইনে থাকে বা তারা সময়মতো একটি ব্লক জমা দেয় না। অনুশীলনে, এটি বর্তমানে <1% স্লটে ঘটে।
এটি নেটওয়ার্কে গড় ব্লক সময়ের ~1 সেকেন্ড হ্রাস বোঝায়। স্মার্ট কন্ট্রাক্ট যেগুলি তাদের গণনায় একটি নির্দিষ্ট গড় ব্লক সময় ধরে নেয় তাদের এটিকে বিবেচনায় নিতে হবে।
কাজের প্রমাণের অধীনে সর্বদা পুনর্গঠনের সম্ভাবনা থাকে। অ্যাপ্লিকেশানগুলি সাধারণত একটি নতুন মাথার উপরে বেশ কয়েকটি ব্লক খনন করার জন্য অপেক্ষা করে এবং এটিকে ক্যানোনিকাল চেইন থেকে অপসারণ বা "নিশ্চিত" হিসাবে বিবেচনা করে। একত্রিত হওয়ার পরে, আমাদের কাছে এর পরিবর্তে চূড়ান্ত করা ধারণা আছে এবং নিরাপদ মাথা ব্লক এই ব্লকগুলি কাজের ব্লকগুলির "নিশ্চিত" প্রমাণের চেয়ে আরও বেশি নির্ভরযোগ্যভাবে ব্যবহার করা যেতে পারে তবে সঠিকভাবে ব্যবহার করার জন্য বোঝার পরিবর্তন প্রয়োজন৷
একটি চূড়ান্ত ব্লক হল এমন একটি যা যাচাইকারীদের 2/3> দ্বারা ক্যানোনিকাল হিসাবে গৃহীত হয়েছে৷ একটি বিরোধপূর্ণ ব্লক তৈরি করতে, একজন আক্রমণকারীকে মোট অংশের কমপক্ষে 1/3 পুড়িয়ে ফেলতে হবে। এই লেখার সময়, এটি Ethereum-এ $10 বিলিয়ন (বা>2.5 মিলিয়ন ETH) প্রতিনিধিত্ব করে৷
একটি নিরাপদ মাথা ব্লক হল এমন একটি যা, স্বাভাবিক নেটওয়ার্ক অবস্থার অধীনে, আমরা ক্যানোনিকাল চেইনের অন্তর্ভুক্ত হওয়ার আশা করি। 4 সেকেন্ডের কম সময়ের জন্য নেটওয়ার্ক বিলম্ব অনুমান করে, একটি সৎ সংখ্যাগরিষ্ঠ বৈধতা এবং ফর্ক-চয়েস নিয়মের উপর কোন আক্রমণ নেই, নিরাপদ মাথা কখনো এতিম হবে না। বিভিন্ন পরিস্থিতিতে কীভাবে নিরাপদ মাথা গণনা করা হয় তার বিশদ বিবরণ এখানে উপলব্ধ। উপরন্তু, নিরাপদ মাথার অনুমান এবং গ্যারান্টি একটি আসন্ন কাগজে আনুষ্ঠানিকভাবে সংজ্ঞায়িত এবং বিশ্লেষণ করা হচ্ছে৷
৷
মার্জ-পরবর্তী, এক্সিকিউশন লেয়ার API (যেমন JSON RPC) নিরাপদ মাথা ফিরিয়ে দেবে ডিফল্টরূপে যখন সর্বশেষ জানতে চাওয়া হয় ব্লক স্বাভাবিক নেটওয়ার্ক অবস্থার অধীনে নিরাপদ মাথা এবং চেইনের আসল টিপ সমতুল্য হবে (শুধুমাত্র কয়েক সেকেন্ডের জন্য নিরাপদ হেড ট্রেলিং সহ)। নিরাপদ মাথা কাজের বর্তমান প্রমাণ সর্বশেষ থেকে পুনর্বিন্যাস হওয়ার সম্ভাবনা কম ব্লক স্টেক চেইনের প্রমাণের আসল টিপ প্রকাশ করতে, একটি অনিরাপদ JSON RPC-তে পতাকা যোগ করা হবে।
চূড়ান্ত ব্লকগুলিও JSON RPC এর মাধ্যমে একটি নতুন চূড়ান্ত করা এর মাধ্যমে প্রকাশ করা হবে পতাকা এইগুলি তখন কাজের নিশ্চিতকরণের প্রমাণের জন্য একটি শক্তিশালী বিকল্প হিসাবে কাজ করতে পারে। নীচের সারণীটি এটিকে সংক্ষিপ্ত করে:
সর্বশেষ আশা করা, যত্ন সঙ্গে ব্যবহার করা আবশ্যক. মাথা স্টেকের প্রমাণ অনিরাপদ আশা করা, যত্ন সঙ্গে ব্যবহার করা আবশ্যক. নিরাপদ মাথা স্টেকের প্রমাণ সর্বশেষ সম্ভব, বড় নেটওয়ার্ক বিলম্ব বা নেটওয়ার্ক আক্রমণ প্রয়োজন. নিশ্চিত৷ কাজের প্রমাণ নেই চূড়ান্ত করা হয়েছে স্টেকের প্রমাণ চূড়ান্ত করা অত্যন্ত অসম্ভাব্য, একটি প্রতিযোগী চেইন চূড়ান্ত করার জন্য> 2/3 যাচাইকারীদের প্রয়োজন যাতে কমপক্ষে 1/3 কাটতে হয়। আমরা আশা করি এই পোস্টটি অ্যাপ্লিকেশন ডেভেলপারদের স্টকের প্রমাণে বহু-প্রত্যাশিত রূপান্তরের জন্য প্রস্তুত করতে সাহায্য করবে৷ আগামী কয়েক সপ্তাহের মধ্যে, বৃহত্তর সম্প্রদায়ের দ্বারা পরীক্ষার জন্য একটি দীর্ঘস্থায়ী টেস্টনেট উপলব্ধ করা হবে। এছাড়াও একটি আসন্ন মার্জ কমিউনিটি কল রয়েছে অবকাঠামো, টুলিং এবং অ্যাপ্লিকেশন ডেভেলপারদের প্রশ্ন জিজ্ঞাসা করতে এবং দ্য মার্জ সম্পর্কে সর্বশেষ প্রযুক্তিগত আপডেট শুনতে। সেখানে দেখা হবে 👋🏻
"সেফ হেড" বিভাগের মূল বিষয়বস্তু প্রদান করার জন্য মিখাইল কালিনিনকে এবং এই পোস্টের খসড়া পর্যালোচনা করার জন্য ড্যানি রায়ান এবং ম্যাট গার্নেটকে ধন্যবাদ৷