EIP-1271: স্মার্ট কন্ট্রাক্ট স্বাক্ষর সাইন এবং যাচাই করা
EIP-1271 (একটি নতুন ট্যাবে খোলে) স্ট্যান্ডার্ড স্মার্ট কন্ট্রাক্টগুলোকে স্বাক্ষর যাচাই করার অনুমতি দেয়।
এই টিউটোরিয়ালে, আমরা ডিজিটাল স্বাক্ষর, EIP-1271 এর পটভূমি এবং Safe (একটি নতুন ট্যাবে খোলে) (পূর্বে Gnosis Safe) দ্বারা ব্যবহৃত EIP-1271 এর নির্দিষ্ট ইমপ্লিমেন্টেশনের একটি ওভারভিউ দেব। সব মিলিয়ে, এটি আপনার নিজের কন্ট্রাক্টগুলোতে EIP-1271 ইমপ্লিমেন্ট করার জন্য একটি প্রারম্ভিক বিন্দু হিসেবে কাজ করতে পারে।
স্বাক্ষর কী?
এই প্রেক্ষাপটে, একটি স্বাক্ষর (আরও স্পষ্টভাবে, একটি "ডিজিটাল স্বাক্ষর") হলো একটি বার্তা এবং সাথে এমন এক ধরণের প্রমাণ যা নিশ্চিত করে যে বার্তাটি কোনো নির্দিষ্ট ব্যক্তি/প্রেরক/ঠিকানা থেকে এসেছে।
উদাহরণস্বরূপ, একটি ডিজিটাল স্বাক্ষর দেখতে এমন হতে পারে:
- বার্তা: "আমি আমার ইথেরিয়াম ওয়ালেট দিয়ে এই ওয়েবসাইটে লগ ইন করতে চাই।"
- স্বাক্ষরকারী: আমার ঠিকানা হলো
0x000… - প্রমাণ: এখানে কিছু প্রমাণ রয়েছে যে আমি,
0x000…, আসলে এই সম্পূর্ণ বার্তাটি তৈরি করেছি (এটি সাধারণত ক্রিপ্টোগ্রাফিক কিছু হয়ে থাকে)।
এটি মনে রাখা গুরুত্বপূর্ণ যে একটি ডিজিটাল স্বাক্ষরে "বার্তা" এবং "স্বাক্ষর" উভয়ই অন্তর্ভুক্ত থাকে।
কেন? উদাহরণস্বরূপ, আপনি যদি আমাকে স্বাক্ষর করার জন্য একটি কন্ট্রাক্ট দেন, এবং তারপর আমি স্বাক্ষরের পৃষ্ঠাটি কেটে ফেলি এবং কন্ট্রাক্টের বাকি অংশ ছাড়াই আপনাকে কেবল আমার স্বাক্ষরগুলো ফেরত দিই, তবে কন্ট্রাক্টটি বৈধ হবে না।
একইভাবে, একটি সংশ্লিষ্ট বার্তা ছাড়া ডিজিটাল স্বাক্ষরের কোনো অর্থ নেই!
EIP-1271 কেন বিদ্যমান?
ইথেরিয়াম-ভিত্তিক ব্লকচেইনগুলোতে ব্যবহারের জন্য একটি ডিজিটাল স্বাক্ষর তৈরি করতে, আপনার সাধারণত একটি গোপন প্রাইভেট কী প্রয়োজন যা অন্য কেউ জানে না। এটিই আপনার স্বাক্ষরকে আপনার নিজস্ব করে তোলে (গোপন কী-এর জ্ঞান ছাড়া অন্য কেউ একই স্বাক্ষর তৈরি করতে পারে না)।
আপনার ইথেরিয়াম অ্যাকাউন্টের (অর্থাৎ, আপনার এক্সটার্নালি-ওনড অ্যাকাউন্ট/EOA) সাথে একটি প্রাইভেট কী যুক্ত থাকে, এবং যখন কোনো ওয়েবসাইট বা বিকেন্দ্রীকৃত অ্যাপ্লিকেশন (dapp) আপনার কাছে একটি স্বাক্ষর চায় (যেমন, "Log in with Ethereum" এর জন্য), তখন সাধারণত এই প্রাইভেট কী-টিই ব্যবহৃত হয়।
একটি অ্যাপ ethers.js এর মতো থার্ড-পার্টি লাইব্রেরি ব্যবহার করে আপনার তৈরি করা স্বাক্ষর যাচাই করতে পারে (একটি নতুন ট্যাবে খোলে) আপনার প্রাইভেট কী না জেনেই (একটি নতুন ট্যাবে খোলে) এবং নিশ্চিত হতে পারে যে আপনিই স্বাক্ষরটি তৈরি করেছেন।
আসলে, যেহেতু EOA ডিজিটাল স্বাক্ষরগুলো পাবলিক-কী ক্রিপ্টোগ্রাফি ব্যবহার করে, তাই এগুলো অফচেইন তৈরি এবং যাচাই করা যেতে পারে! এভাবেই গ্যাসবিহীন DAO ভোটিং কাজ করে — অনচেইন ভোট জমা দেওয়ার পরিবর্তে, ক্রিপ্টোগ্রাফিক লাইব্রেরি ব্যবহার করে অফচেইন ডিজিটাল স্বাক্ষর তৈরি এবং যাচাই করা যেতে পারে।
যদিও EOA অ্যাকাউন্টগুলোর একটি প্রাইভেট কী থাকে, স্মার্ট কন্ট্রাক্ট অ্যাকাউন্টগুলোর কোনো ধরণের প্রাইভেট বা গোপন কী থাকে না (তাই "Log in with Ethereum" ইত্যাদি স্মার্ট কন্ট্রাক্ট অ্যাকাউন্টগুলোর সাথে নেটিভভাবে কাজ করতে পারে না)।
EIP-1271 যে সমস্যার সমাধান করতে চায়: স্মার্ট কন্ট্রাক্টের যদি এমন কোনো "গোপন" কিছু না থাকে যা এটি স্বাক্ষরে অন্তর্ভুক্ত করতে পারে, তবে আমরা কীভাবে বলতে পারি যে একটি স্মার্ট কন্ট্রাক্ট স্বাক্ষর বৈধ?
EIP-1271 কীভাবে কাজ করে?
স্মার্ট কন্ট্রাক্টগুলোর কোনো প্রাইভেট কী নেই যা বার্তা সাইন করতে ব্যবহার করা যেতে পারে। তাহলে আমরা কীভাবে বুঝব যে একটি স্বাক্ষর আসল?
আচ্ছা, একটি ধারণা হলো আমরা কেবল স্মার্ট কন্ট্রাক্টকে জিজ্ঞাসা করতে পারি যে একটি স্বাক্ষর আসল কিনা!
EIP-1271 যা করে তা হলো এটি একটি প্রদত্ত স্বাক্ষর বৈধ কিনা তা স্মার্ট কন্ট্রাক্টকে "জিজ্ঞাসা করার" এই ধারণাটিকে প্রমিত করে।
যে কন্ট্রাক্ট EIP-1271 ইমপ্লিমেন্ট করে তার অবশ্যই isValidSignature নামের একটি ফাংশন থাকতে হবে যা একটি বার্তা এবং একটি স্বাক্ষর গ্রহণ করে। এরপর কন্ট্রাক্টটি কিছু ভ্যালিডেশন লজিক চালাতে পারে (স্পেসিফিকেশন এখানে নির্দিষ্ট কিছু প্রয়োগ করতে বাধ্য করে না) এবং তারপর স্বাক্ষরটি বৈধ কিনা তা নির্দেশ করে এমন একটি মান রিটার্ন করতে পারে।
যদি isValidSignature একটি বৈধ ফলাফল রিটার্ন করে, তবে এর মানে হলো কন্ট্রাক্টটি বলছে "হ্যাঁ, আমি এই স্বাক্ষর + বার্তা অনুমোদন করি!"
ইন্টারফেস
এখানে EIP-1271 স্পেসিফিকেশনের সঠিক ইন্টারফেসটি দেওয়া হলো (আমরা নিচে _hash প্যারামিটার সম্পর্কে কথা বলব, তবে আপাতত, এটিকে যাচাই করা হচ্ছে এমন বার্তা হিসেবে ধরে নিন):
pragma solidity ^0.5.0;
contract ERC1271 {
// bytes4(keccak256("isValidSignature(bytes32,bytes)")
bytes4 constant internal MAGICVALUE = 0x1626ba7e;
/**
* @dev প্রদানকৃত হ্যাশের জন্য প্রদানকৃত স্বাক্ষরটি বৈধ কিনা তা রিটার্ন করা উচিত
* @param _hash স্বাক্ষর করা হবে এমন ডেটার হ্যাশ
* @param _signature _hash এর সাথে যুক্ত স্বাক্ষর বাইট অ্যারে
*
* ফাংশনটি পাস হলে অবশ্যই bytes4 ম্যাজিক ভ্যালু 0x1626ba7e রিটার্ন করতে হবে।
* স্টেট পরিবর্তন করা যাবে না (solc < 0.5 এর জন্য STATICCALL, solc > 0.5 এর জন্য view মডিফায়ার ব্যবহার করে)
* এক্সটার্নাল কল অবশ্যই অনুমোদন করতে হবে
*/
function isValidSignature(
bytes32 _hash,
bytes memory _signature)
public
view
returns (bytes4 magicValue);
}
EIP-1271 ইমপ্লিমেন্টেশনের উদাহরণ: Safe
কন্ট্রাক্টগুলো অনেক উপায়ে isValidSignature ইমপ্লিমেন্ট করতে পারে — স্পেসিফিকেশনটি সঠিক ইমপ্লিমেন্টেশন সম্পর্কে খুব বেশি কিছু বলে না।
EIP-1271 ইমপ্লিমেন্ট করে এমন একটি উল্লেখযোগ্য কন্ট্রাক্ট হলো Safe (পূর্বে Gnosis Safe)।
Safe এর কোডে, isValidSignature এমনভাবে ইমপ্লিমেন্ট করা হয়েছে (একটি নতুন ট্যাবে খোলে) যাতে স্বাক্ষরগুলো দুটি উপায়ে (একটি নতুন ট্যাবে খোলে) তৈরি এবং যাচাই করা যায়:
- অনচেইন বার্তা
- তৈরি করা: একজন safe মালিক একটি বার্তায় "স্বাক্ষর" করার জন্য একটি নতুন safe ট্রানজ্যাকশন তৈরি করেন, যেখানে বার্তাটিকে ট্রানজ্যাকশনের ডেটা হিসেবে পাস করা হয়। মাল্টিসিগ থ্রেশহোল্ডে পৌঁছানোর জন্য পর্যাপ্ত মালিক ট্রানজ্যাকশনে স্বাক্ষর করলে, ট্রানজ্যাকশনটি ব্রডকাস্ট করা হয় এবং চালানো হয়। ট্রানজ্যাকশনে, (
signMessage(bytes calldata _data)) নামের একটি safe ফাংশন রয়েছে যা বার্তাটিকে "অনুমোদিত" বার্তাগুলোর একটি তালিকায় যুক্ত করে। - যাচাইকরণ: Safe কন্ট্রাক্টে
isValidSignatureকল করুন, এবং যাচাই করার জন্য বার্তাটিকে বার্তা প্যারামিটার হিসেবে এবং স্বাক্ষর প্যারামিটারের জন্য একটি খালি মান (একটি নতুন ট্যাবে খোলে) (অর্থাৎ,0x) পাস করুন। Safe দেখতে পাবে যে স্বাক্ষর প্যারামিটারটি খালি এবং ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষর যাচাই করার পরিবর্তে, এটি বুঝতে পারবে যে বার্তাটি "অনুমোদিত" বার্তাগুলোর তালিকায় আছে কিনা তা পরীক্ষা করতে হবে।
- তৈরি করা: একজন safe মালিক একটি বার্তায় "স্বাক্ষর" করার জন্য একটি নতুন safe ট্রানজ্যাকশন তৈরি করেন, যেখানে বার্তাটিকে ট্রানজ্যাকশনের ডেটা হিসেবে পাস করা হয়। মাল্টিসিগ থ্রেশহোল্ডে পৌঁছানোর জন্য পর্যাপ্ত মালিক ট্রানজ্যাকশনে স্বাক্ষর করলে, ট্রানজ্যাকশনটি ব্রডকাস্ট করা হয় এবং চালানো হয়। ট্রানজ্যাকশনে, (
- অফচেইন বার্তা:
- তৈরি করা: একজন safe মালিক অফচেইন একটি বার্তা তৈরি করেন, তারপর মাল্টিসিগ অনুমোদনের থ্রেশহোল্ড অতিক্রম করার জন্য পর্যাপ্ত স্বাক্ষর না হওয়া পর্যন্ত অন্যান্য safe মালিকদের দিয়ে বার্তাটিতে আলাদাভাবে স্বাক্ষর করান।
- যাচাইকরণ:
isValidSignatureকল করুন। বার্তা প্যারামিটারে, যাচাই করার জন্য বার্তাটি পাস করুন। স্বাক্ষর প্যারামিটারে, প্রতিটি safe মালিকের আলাদা স্বাক্ষরগুলো একসাথে যুক্ত করে পাস করুন। Safe পরীক্ষা করবে যে থ্রেশহোল্ড পূরণ করার জন্য পর্যাপ্ত স্বাক্ষর রয়েছে কিনা এবং প্রতিটি স্বাক্ষর বৈধ কিনা। যদি তাই হয়, তবে এটি সফল স্বাক্ষর যাচাইকরণ নির্দেশ করে এমন একটি মান রিটার্ন করবে।
_hash প্যারামিটারটি আসলে কী? কেন পুরো বার্তাটি পাস করা হয় না?
আপনি হয়তো লক্ষ্য করেছেন যে EIP-1271 ইন্টারফেসে (একটি নতুন ট্যাবে খোলে) isValidSignature ফাংশনটি বার্তাটি নিজে গ্রহণ করে না, বরং একটি _hash প্যারামিটার গ্রহণ করে। এর মানে হলো isValidSignature-এ সম্পূর্ণ ইচ্ছামতো দৈর্ঘ্যের বার্তা পাস করার পরিবর্তে, আমরা বার্তার একটি 32-বাইট হ্যাশ (সাধারণত keccak256) পাস করি।
কল ডেটার প্রতিটি বাইট — অর্থাৎ, স্মার্ট কন্ট্রাক্ট ফাংশনে পাস করা ফাংশন প্যারামিটার ডেটা — এর জন্য 16 গ্যাস খরচ হয় (শূন্য বাইট হলে 4 গ্যাস) (একটি নতুন ট্যাবে খোলে), তাই বার্তাটি দীর্ঘ হলে এটি প্রচুর গ্যাস বাঁচাতে পারে।
পূর্ববর্তী EIP-1271 স্পেসিফিকেশন
বাস্তবে এমন কিছু EIP-1271 স্পেসিফিকেশন রয়েছে যেগুলোতে isValidSignature ফাংশনের প্রথম প্যারামিটারটি bytes টাইপের (নির্দিষ্ট দৈর্ঘ্যের bytes32 এর পরিবর্তে ইচ্ছামতো দৈর্ঘ্যের) এবং প্যারামিটারের নাম message। এটি EIP-1271 স্ট্যান্ডার্ডের একটি পুরানো সংস্করণ (একটি নতুন ট্যাবে খোলে)।
আমার নিজের কন্ট্রাক্টগুলোতে EIP-1271 কীভাবে ইমপ্লিমেন্ট করা উচিত?
স্পেসিফিকেশনটি এখানে বেশ উন্মুক্ত। Safe ইমপ্লিমেন্টেশনে কিছু ভালো ধারণা রয়েছে:
- আপনি কন্ট্রাক্টের "মালিকের" কাছ থেকে আসা EOA স্বাক্ষরগুলোকে বৈধ হিসেবে বিবেচনা করতে পারেন।
- আপনি অনুমোদিত বার্তাগুলোর একটি তালিকা সংরক্ষণ করতে পারেন এবং কেবল সেগুলোকেই বৈধ হিসেবে বিবেচনা করতে পারেন।
পরিশেষে, কন্ট্রাক্ট ডেভেলপার হিসেবে এটি আপনার ওপর নির্ভর করে!
উপসংহার
EIP-1271 (একটি নতুন ট্যাবে খোলে) হলো একটি বহুমুখী স্ট্যান্ডার্ড যা স্মার্ট কন্ট্রাক্টগুলোকে স্বাক্ষর যাচাই করার অনুমতি দেয়। এটি স্মার্ট কন্ট্রাক্টগুলোর জন্য EOA-এর মতো আরও বেশি কাজ করার দরজা খুলে দেয় — উদাহরণস্বরূপ স্মার্ট কন্ট্রাক্টগুলোর সাথে "Log in with Ethereum" কাজ করার একটি উপায় প্রদান করে — এবং এটি অনেক উপায়ে ইমপ্লিমেন্ট করা যেতে পারে (বিবেচনা করার জন্য Safe-এর একটি গুরুত্বপূর্ণ এবং আকর্ষণীয় ইমপ্লিমেন্টেশন রয়েছে)।