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

EIP-1271 (opens in a new tab) मानक स्मार्ट कॉन्ट्रॅक्ट्सना स्वाक्षऱ्या पडताळण्याची अनुमती देते.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ची अंमलबजावणी केली जाते (opens in a new tab) जेणेकरून स्वाक्षऱ्या दोन प्रकारे (opens in a new tab) तयार आणि पडताळल्या जाऊ शकतात:

1. ऑनचेन संदेश
   1. निर्मिती: एक safe मालक संदेशावर "स्वाक्षरी" करण्यासाठी एक नवीन safe व्यवहार तयार करतो, संदेशाला डेटामध्ये व्यवहारात पास करतो. एकदा मल्टीसिग थ्रेशोल्ड गाठण्यासाठी पुरेशा मालकांनी व्यवहारावर स्वाक्षरी केली की, व्यवहार प्रसारित केला जातो आणि चालवला जातो. व्यवहारात, (signMessage(bytes calldata _data)) नावाचे एक safe फंक्शन असते जे संदेशाला "मंजूर" संदेशांच्या सूचीमध्ये जोडते.
   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 ला पूर्ण अनियंत्रित-लांबीचा संदेश पास करण्याऐवजी, आम्ही त्याऐवजी संदेशाचा 32-बाइट हॅश (साधारणपणे keccak256) पास करतो.

कॉल डेटाच्या प्रत्येक बाइटसाठी — म्हणजेच, स्मार्ट कॉन्ट्रॅक्ट फंक्शनला पास केलेला फंक्शन पॅरामीटर डेटा — 16 गॅस खर्च येतो (शून्य बाइट असल्यास 4 गॅस) (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 प्रमाणे अधिक कार्य करण्यासाठी दरवाजे उघडते — उदाहरणार्थ "इथेरियमसह लॉग इन करा" ला स्मार्ट कॉन्ट्रॅक्ट्ससह कार्य करण्याचा मार्ग प्रदान करणे — आणि त्याची अनेक प्रकारे अंमलबजावणी केली जाऊ शकते (Safe मध्ये विचार करण्यासारखी एक महत्त्वपूर्ण, मनोरंजक अंमलबजावणी आहे).