EIP-1271: स्मार्ट कॉन्ट्रॅक्ट सह्यांवर सही करणे आणि त्या सत्यापित करणे

EIP-1271 (opens in a new tab) मानक स्मार्ट कॉन्ट्रॅक्ट्सना सह्या सत्यापित करण्याची परवानगी देते.

या ट्युटोरियलमध्ये, आम्ही डिजिटल सह्या, EIP-1271 ची पार्श्वभूमी आणि Safe (opens in a new tab) (पूर्वीचे Gnosis Safe) द्वारे वापरलेल्या EIP-1271 च्या विशिष्ट अंमलबजावणीचा आढावा देतो. एकत्रितपणे, हे तुमच्या स्वतःच्या कॉन्ट्रॅक्टमध्ये EIP-1271 लागू करण्यासाठी एक प्रारंभ बिंदू म्हणून काम करू शकते.

सही म्हणजे काय?

या संदर्भात, सही (अधिक अचूकपणे सांगायचे तर, “डिजिटल सही”) म्हणजे एक संदेश आणि तो संदेश एका विशिष्ट व्यक्ती/प्रेषक/ॲड्रेसकडून आला आहे याचा काही प्रकारचा पुरावा.

उदाहरणार्थ, डिजिटल सही अशी दिसू शकते:

1. संदेश: “मला माझ्या Ethereum वॉलेटने या वेबसाइटवर लॉग इन करायचे आहे.”
2. सही करणारा: माझा ॲड्रेस 0x000… आहे
3. पुरावा: हा काही पुरावा आहे की मी, 0x000…, हा संपूर्ण संदेश खरोखर तयार केला आहे (हे सहसा काहीतरी क्रिप्टोग्राफिक असते).

हे लक्षात घेणे महत्त्वाचे आहे की डिजिटल सहीमध्ये "संदेश" आणि "सही" दोन्ही समाविष्ट असतात.

का? उदाहरणार्थ, जर तुम्ही मला सही करण्यासाठी एखादा कॉन्ट्रॅक्ट दिला आणि मी त्यातील सहीचे पान कापून बाकीच्या कॉन्ट्रॅक्टशिवाय केवळ माझ्या सह्या तुम्हाला परत दिल्या, तर तो कॉन्ट्रॅक्ट वैध ठरणार नाही.

त्याचप्रमाणे, संबंधित संदेशाशिवाय डिजिटल सहीला काहीही अर्थ नाही!

EIP-1271 का अस्तित्वात आहे?

Ethereum-आधारित ब्लॉकचेनवर वापरण्यासाठी डिजिटल सही तयार करण्याकरिता, तुम्हाला सामान्यतः एका गुप्त प्रायव्हेट की ची आवश्यकता असते, जी इतर कोणालाही माहीत नसते. यामुळेच तुमची सही ही तुमचीच असते (गुप्त की च्या माहितीशिवाय इतर कोणीही तीच सही तयार करू शकत नाही).

तुमच्या Ethereum अकाउंटशी (म्हणजे, तुमच्या एक्सटर्नली-ओन्ड अकाउंट/EOA) एक प्रायव्हेट की जोडलेली असते, आणि हीच ती प्रायव्हेट की आहे जी सामान्यतः एखादी वेबसाइट किंवा dapp तुम्हाला सहीसाठी विचारते तेव्हा वापरली जाते (उदा., "Ethereum ने लॉग इन करा" साठी).

एखादे ॲप ethers.js सारख्या थर्ड-पार्टी लायब्ररीचा वापर करून, तुम्ही तयार केलेली सही सत्यापित करू शकते (opens in a new tab), आणि तेही तुमची प्रायव्हेट की माहीत नसताना (opens in a new tab), आणि तुम्हीच ती सही तयार केली आहे याची खात्री बाळगू शकते.

खरं तर, EOA डिजिटल सह्या पब्लिक-की क्रिप्टोग्राफी वापरत असल्यामुळे, त्या ऑफचेन तयार आणि सत्यापित केल्या जाऊ शकतात! गॅसलेस DAO मतदान असेच कार्य करते — ऑनचेन मते सबमिट करण्याऐवजी, क्रिप्टोग्राफिक लायब्ररी वापरून डिजिटल सह्या ऑफचेन तयार आणि सत्यापित केल्या जाऊ शकतात.

EOA अकाउंट्सकडे प्रायव्हेट की असली तरी, स्मार्ट कॉन्ट्रॅक्ट अकाउंट्सकडे कोणत्याही प्रकारची प्रायव्हेट किंवा गुप्त की नसते (त्यामुळे "Ethereum ने लॉग इन करा", इत्यादी स्मार्ट कॉन्ट्रॅक्ट अकाउंट्ससोबत मूळतः काम करू शकत नाहीत).

EIP-1271 ज्या समस्येचे निराकरण करण्याचे उद्दिष्ट ठेवते ती ही आहे: जर स्मार्ट कॉन्ट्रॅक्टकडे सहीमध्ये समाविष्ट करण्यासाठी कोणतेही “गुपित” नसेल, तर स्मार्ट कॉन्ट्रॅक्टची सही वैध आहे हे आपण कसे ओळखू शकतो?

EIP-1271 कसे कार्य करते?

स्मार्ट कॉन्ट्रॅक्ट्सकडे प्रायव्हेट की नसतात ज्यांचा वापर संदेशांवर सही करण्यासाठी केला जाऊ शकतो. मग एखादी सही अस्सल आहे की नाही हे आपण कसे ओळखू शकतो?

तर, एक कल्पना अशी आहे की आपण थेट स्मार्ट कॉन्ट्रॅक्टलाच विचारू शकतो की एखादी सही अस्सल आहे की नाही!

EIP-1271 हेच करते की, दिलेली सही वैध आहे की नाही हे स्मार्ट कॉन्ट्रॅक्टला “विचारण्याच्या” या कल्पनेला ते प्रमाणित करते.

EIP-1271 लागू करणाऱ्या कॉन्ट्रॅक्टमध्ये isValidSignature नावाचे फंक्शन असणे आवश्यक आहे, जे एक संदेश आणि एक सही इनपुट म्हणून घेते. त्यानंतर कॉन्ट्रॅक्ट काही व्हॅलिडेशन लॉजिक चालवू शकतो (स्पेक येथे काहीही विशिष्ट लागू करत नाही) आणि मग सही वैध आहे की नाही हे दर्शवणारे एक मूल्य परत करू शकतो.

जर isValidSignature ने वैध निकाल परत केला, तर त्याचा अर्थ असा होतो की कॉन्ट्रॅक्ट म्हणत आहे, “होय, मी या सही + संदेशाला मान्यता देतो!”

इंटरफेस

EIP-1271 स्पेक मधील अचूक इंटरफेस येथे आहे (आपण खाली _hash पॅरामीटरबद्दल बोलू, पण आतासाठी, त्याचा विचार सत्यापित केला जाणारा संदेश म्हणून करा):

1pragma solidity ^0.5.0;
2
3contract ERC1271 {
4
5  // bytes4(keccak256("isValidSignature(bytes32,bytes)")
6  bytes4 constant internal MAGICVALUE = 0x1626ba7e;
7
8  /**
9   * @dev प्रदान केलेली सही, प्रदान केलेल्या हॅशसाठी वैध आहे की नाही हे परत करावे
10   * @param _hash      सही करायच्या डेटाचा हॅश
11   * @param _signature _hash शी संबंधित सही बाइट ॲरे
12   *
13   * फंक्शन पास झाल्यावर bytes4 मॅजिक व्हॅल्यू 0x1626ba7e परत करणे आवश्यक आहे.
14   * स्टेटमध्ये बदल करणे आवश्यक नाही (solc < 0.5 साठी STATICCALL वापरून, solc > 0.5 साठी व्ह्यू मॉडिफायर वापरून)
15   * एक्सटर्नल कॉल्सना परवानगी देणे आवश्यक आहे
16   */
17  function isValidSignature(
18    bytes32 _hash,
19    bytes memory _signature)
20    public
21    view
22    returns (bytes4 magicValue);
23}
सर्व दाखवा

EIP-1271 अंमलबजावणीचे उदाहरण: Safe

कॉन्ट्रॅक्ट्स isValidSignature अनेक प्रकारे लागू करू शकतात — स्पेक अचूक अंमलबजावणीबद्दल फारसे काही सांगत नाही.

EIP-1271 लागू करणारा एक उल्लेखनीय कॉन्ट्रॅक्ट म्हणजे Safe (पूर्वीचा Gnosis Safe).

Safe च्या कोडमध्ये, isValidSignature अंमलात आणले आहे (opens in a new tab) जेणेकरून सह्या दोन प्रकारे (opens in a new tab) तयार आणि सत्यापित केल्या जाऊ शकतात:

1. ऑनचेन संदेश
   1. निर्मिती: एक safe मालक संदेशावर “सही” करण्यासाठी एक नवीन safe व्यवहार तयार करतो, आणि संदेशाला डेटा म्हणून त्या व्यवहारात पास करतो. एकदा मल्टिसिग थ्रेशोल्डपर्यंत पोहोचण्यासाठी पुरेसे मालक व्यवहारावर सही करतात, तेव्हा तो व्यवहार प्रसारित केला जातो आणि चालवला जातो. त्या व्यवहारामध्ये, (signMessage(bytes calldata _data)) नावाचे एक सेफ फंक्शन आहे जे संदेशाला “मान्यताप्राप्त” संदेशांच्या यादीत जोडते.
   2. सत्यापन: Safe कॉन्ट्रॅक्टवर isValidSignature कॉल करा आणि सत्यापित करायचा संदेश हा संदेश पॅरामीटर म्हणून पास करा आणि सही पॅरामीटरसाठी एक रिकामे मूल्य पास करा (opens in a new tab) (म्हणजे, 0x). Safe बघेल की सही पॅरामीटर रिकामा आहे आणि सहीचे क्रिप्टोग्राफिकली सत्यापन करण्याऐवजी, तो संदेश “मान्यताप्राप्त” संदेशांच्या यादीत आहे की नाही हे तपासेल.
2. ऑफचेन संदेश:
   1. निर्मिती: एक safe मालक ऑफचेन एक संदेश तयार करतो, आणि मल्टिसिग मान्यता थ्रेशोल्ड पार करण्यासाठी पुरेशा सह्या मिळेपर्यंत इतर safe मालकांकडून त्या संदेशावर वैयक्तिकरित्या सही घेतो.
   2. सत्यापन: isValidSignature कॉल करा. संदेश पॅरामीटरमध्ये, सत्यापित करायचा संदेश पास करा. सही पॅरामीटरमध्ये, प्रत्येक safe मालकाच्या वैयक्तिक सह्या एकामागोमाग एक जोडून पास करा. Safe हे तपासेल की थ्रेशोल्ड पूर्ण करण्यासाठी पुरेशा सह्या आहेत आणि प्रत्येक सही वैध आहे. तसे असल्यास, ते यशस्वी सही सत्यापनाचे सूचक मूल्य परत करेल.

_hash पॅरामीटर नेमके काय आहे? संपूर्ण संदेश का पास करू नये?

तुमच्या लक्षात आले असेल की EIP-1271 इंटरफेस (opens in a new tab) मधील isValidSignature फंक्शन संदेश स्वतः न घेता, त्याऐवजी एक _hash पॅरामीटर घेते. याचा अर्थ असा आहे की, isValidSignature ला संपूर्ण अनियंत्रित-लांबीचा संदेश पास करण्याऐवजी, आपण त्याऐवजी संदेशाचा ३२-बाइट हॅश (सामान्यतः keccak256) पास करतो.

calldata च्या प्रत्येक बाइटला — म्हणजे, स्मार्ट कॉन्ट्रॅक्ट फंक्शनला पास केलेल्या फंक्शन पॅरामीटर डेटाला — १६ गॅस (शून्य बाइट असल्यास ४ गॅस) खर्च येतो (opens in a new tab), त्यामुळे संदेश मोठा असल्यास भरपूर गॅस वाचू शकतो.

मागील EIP-1271 स्पेसिफिकेशन्स

वापरात अशी EIP-1271 स्पेसिफिकेशन्स आहेत ज्यात isValidSignature फंक्शन आहे, ज्याचा पहिला पॅरामीटर bytes प्रकाराचा (निश्चित-लांबीच्या bytes32 ऐवजी अनिश्चित-लांबीचा) आहे आणि पॅरामीटरचे नाव message आहे. ही EIP-1271 मानकाची एक जुनी आवृत्ती (opens in a new tab) आहे.

माझ्या स्वतःच्या कॉन्ट्रॅक्ट्समध्ये EIP-1271 कसे लागू करावे?

येथे स्पेक खूपच लवचिक आहे. Safe अंमलबजावणीमध्ये काही चांगल्या कल्पना आहेत:

• तुम्ही कॉन्ट्रॅक्टच्या "मालका"कडून आलेल्या EOA सह्या वैध मानू शकता.
• तुम्ही मान्यताप्राप्त संदेशांची यादी संग्रहित करू शकता आणि केवळ त्यांनाच वैध मानू शकता.

शेवटी, कॉन्ट्रॅक्ट डेव्हलपर म्हणून हे तुमच्यावर अवलंबून आहे!

निष्कर्ष

EIP-1271 (opens in a new tab) हे एक बहुउपयोगी मानक आहे जे स्मार्ट कॉन्ट्रॅक्ट्सना सह्या सत्यापित करण्याची परवानगी देते. हे स्मार्ट कॉन्ट्रॅक्ट्सना EOA सारखे अधिक वागण्यासाठी मार्ग खुले करते — उदाहरणार्थ, "Ethereum ने लॉग इन करा" ला स्मार्ट कॉन्ट्रॅक्ट्ससोबत काम करण्याचा मार्ग प्रदान करणे — आणि ते अनेक प्रकारे लागू केले जाऊ शकते (Safe कडे विचारात घेण्यासारखी एक गुंतागुंतीची, मनोरंजक अंमलबजावणी आहे).

पृष्ठ अखेरचे अद्यतन: १६ जानेवारी, २०२६

x (opens in a new tab)

p (opens in a new tab)

m (opens in a new tab)

+4

योगदानकर्ता पहा