إثبات المعرفة الصفرية (ZKP) هو مفهوم تشفير يمكن استخدامه لإثبات صحة بيان ما دون الكشف عن أي معلومات محددة حول البيان. في برهان المعرفة الصفرية، يمكن للمحقق أن يثبت للمحقق أن عبارة معينة صحيحة، ولا يحصل المتحقق إلا على نتيجة واحدة: إما قبول العبارة على أنها صحيحة أو رفضها، دون معرفة التفاصيل المحددة للبرهان.
يمكن شرح هذا المفهوم بمثال بسيط. لنفترض أن هناك شخصين، أحدهما هو المثبت والآخر هو المتحقق. يريد المثبت أن يثبت للمدقق أنه يعرف كلمة المرور السرية دون الكشف عن كلمة المرور نفسها. في الطريقة التقليدية، قد يخبر المثبت المدقق ما هي كلمة المرور، ولكن في إثبات المعرفة الصفرية، يمكن للمثبت استخدام بروتوكول خاص ليثبت للمتحقق أنه يعرف صحة كلمة المرور دون الكشف عن كلمة المرور نفسها.
حاليًا، تتضمن خوارزميات نظام إثبات المعرفة الصفرية الشائعة zk-SNARKs وzk-STARKs وBulletProofs وما إلى ذلك.
2. تطبيق ZKP في blockchain
في تقنية blockchain، لدى ZKP مجموعة متنوعة من التطبيقات، مثل تحسين الخصوصية، وتحسين قابلية التوسع والأمان، وما إلى ذلك. فيما يلي بعض التطبيقات الرئيسية لـ ZKP في blockchain:
1 حماية الخصوصية:
إن blockchain عام، مما يعني أنه يمكن لأي شخص عرض جميع المعاملات على السلسلة. ومع ذلك، في بعض الأحيان، قد يرغب المستخدمون في الحفاظ على خصوصية معلومات معاملاتهم. يتيح ZKP للمستخدمين إثبات أن لديهم أموالًا كافية للتداول دون الحاجة إلى الكشف عن إجمالي أموالهم. وهذا يعزز بشكل كبير حماية خصوصية المستخدم. على سبيل المثال، Zcash هي عملة مشفرة تستخدم تقنية إثبات المعرفة الصفرية، والتي تسمح للمستخدمين بإخفاء المرسل والمستلم ومبلغ المعاملة.
2 الضغط الحسابي وتوسيع blockchain:
تمثل قابلية التوسع في تقنية Blockchain تحديًا، خاصة في التطبيقات واسعة النطاق. يمكن استخدام ZKP لتقليل العبء على العقد وتحسين قابلية التوسع للنظام بأكمله. باستخدام ZKP للتحقق من صحة المعاملات، لا تحتاج العقد إلى عرض سجل المعاملات الكامل، وبالتالي تقليل عبء التخزين والمعالجة. ZK Rollup، الأكثر استخدامًا حاليًا، هو حل قابل للتوسع مصمم لتحسين Ethereum ومجالات أخرى. إنتاجية وكفاءة شبكات blockchain. فهو يجمع بين مزايا تقنيات Rollup وZKP لتوفير حلول توسيع التطبيقات اللامركزية (DApps) عالية الأداء. على شبكة إيثريوم التقليدية، يجب التحقق من كل معاملة وتسجيلها على blockchain، مما يؤدي إلى تأخير وارتفاع تكاليف معالجة المعاملات. يقوم ZK Rollup بتجميع وضغط عدد كبير من المعاملات في كتلة واحدة، ويتم استخدام ZKP لإثبات صحة المعاملات المجمعة لضمان صحة وأمن المعاملات.
3 المصادقة:
يمكن استخدام إثباتات المعرفة الصفرية للتحقق من هوية المستخدم دون الكشف عن معلومات شخصية حساسة. على سبيل المثال، يمكن لأي شخص استخدام إثباتات المعرفة الصفرية ليثبت للشبكة أنه يستوفي شرطًا معينًا للعمر أو يمتلك شهادة معينة دون الكشف عن عمره الدقيق أو معلومات تعريفية أخرى.
4 التخزين اللامركزي:
يمكن للخادم أن يثبت للمستخدمين أن بياناتهم محفوظة بشكل آمن وأنه لا يتم تسريب أي محتوى من البيانات.
بشكل عام، **يتمتع إثبات المعرفة الصفرية الخاص بـ blockchain بتطبيقات واسعة في حماية الخصوصية، وضغط الحوسبة وتوسيعها، والتحقق من الهوية، والتخزين اللامركزي، وما إلى ذلك. يوفر المزيد من الوظائف والخيارات لتقنية blockchain ويعزز تطوير وتطبيق blockchain في مختلف المجالات. **
3. هجوم الإنفاق المزدوج في تطبيقات ZKP
zk-SNARK (حجة المعرفة المقتضبة وغير التفاعلية للمعرفة الصفرية) هي تقنية تعتمد على دليل المعرفة الصفرية الذي يمكن أن يثبت صحة البيان دون الكشف عن معلومات حقيقية. إنها تقنية فعالة للغاية لإثبات المعرفة الصفرية ويمكنها إنشاء البراهين والتحقق منها في وقت قصير جدًا مع حماية الخصوصية والأمان، لذلك يتم استخدامها على نطاق واسع. ومع ذلك، مع توسع التطبيقات، اجتذب أمنها المزيد والمزيد من الاهتمام. لقد اكتشفنا ثغرتها العامة منذ وقت ليس ببعيد: إذا لم يتم التحقق من نطاق قيمة إدخال المعلمة في وظيفة التحقق بشكل صحيح في مشروع ZKP، فيمكن للمهاجم تزوير مدخلات متعددة لتمرير التحقق، مما يتسبب في هجوم الإنفاق المزدوج. تأثير هذا الهجوم واسع جدًا، حيث يشمل خوارزميات zk-SNARK المتعددة بما في ذلك: groth16 و plonk وغيرها، وتوجد هذه الثغرة الأمنية في العديد من لغات التطوير مثل Solidity و js. تم اكتشاف هذه الثغرة الأمنية لأول مرة بواسطة poma في مشروع إثبات المعرفة الصفرية Semaphore، وتم تقديم مثالين للمعاملات التي تم تنفيذها بنجاح، كما هو موضح في الشكل أدناه:
مبدأ الهجوم المحدد لهذه الثغرة الأمنية هو أنه إذا كنت تريد إنشاء دليل zk-SNARK والتحقق منه في Ethereum، فأنت بحاجة إلى استخدام دائرة المنحنى الإهليلجي للمجال المحدود F_p-arithmetic، حيث يتم استخدام القيمة p لتحديد النطاق للمجال المحدود للمنحنى الإهليلجي، وبالتالي فإن نطاق قيمة الإدخال للدائرة هو [0,1,...,p-1]. منحنيات مختلفة لها قيم p مختلفة:
منحنى BN254 المحدد في EIP-196 (المعروف أيضًا باسم منحنى ALT_BN128):
قامت Semaphore لاحقًا بتأكيد الثغرة وإصلاحها، كما قامت مكتبات zk مثل ZoKrates وsnarkjs بإجراء إصلاحات طارئة في وقت واحد، ومع ذلك، وجد باحثو الأمن في Beosin أنه لا يوجد حاليًا حل موحد لهذه المشكلة، على سبيل المثال، يكتب بروتوكول Semaphore قيودًا في الاقتران مكتبة. لم يتم التحقق من النطاق الصالح للبيانات بشكل صريح في منطق الأعمال الخارجي؛ كود العقد الذي تم إنشاؤه بواسطة circom وTornado.Cash يتحقق بشكل صريح من SNARK_SCALAR_FIELD في وظيفة التحقق. هذا حل مربك وغير متسق. قد يتسبب في المشاكل والمخاطر الأمنية التي تواجه العديد من أطراف مشروع zk DApp الجديد، لذلك نأمل في استخدام طريقة موحدة لحل هذه المشكلة.
4. هجوم الإنفاق المزدوج في ERC-1922
حاليًا، لدى Ethereum معيار EIP-1922 المتعلق بـ zk، والذي يقدم واجهة التحقق القياسية للعقد للتحقق من zk-SNARK، والرمز المحدد هو كما يلي:
صلابة البراغما ^0.5.6;/// @title EIP-XXXX zk-SNARK Verifier Standard/// @dev راجع /// ملاحظة: معرف ERC-165 لهذه الواجهة هو 0xXXXXXXXX./// ⚠️ TODO: حساب الواجهة identifierinterface ERC1922 /* is ERC165 */ { /// @notice يتحقق من وسيطات الدليل من خلال منحنى إهليلجي /// وظائف الاقتران. /// @dev /// يجب أن يُرجع صحيحًا إذا نجح الدليل في جميع عمليات التحقق (أي أن الدليل /// صالح). /// يجب إرجاع خطأ إذا لم ينجح الدليل في جميع عمليات التحقق (أي إذا كان /// الدليل غير صالح). /// @param إثبات Zk-SNARK. /// @param inputs المدخلات العامة المصاحبة للإثبات. /// @param VerificationKeyId معرف فريد (معروف لهذا المدقق /// العقد) لمفتاح التحقق الذي يتوافق معه الإثبات. ///return result نتيجة حساب التحقق. صحيح /// إذا كان الدليل صالحًا؛ كاذبة خلاف ذلك. التحقق من الوظيفة (uint256[] إثبات بيانات الاتصال، uint256[] مدخلات بيانات الاتصال، التحقق bytes32KeyId) الإرجاعات الخارجية (نتيجة منطقية)؛}
من بينها، أنواع إثبات المعرفة الصفرية ومتغيرات المدخلات هي uint256[].هذا النوع المتغير هو حاليًا عملية المنحنى الإهليلجي الأكثر استخدامًا في خوارزمية ZKP، ومع ذلك، لا تتم إضافة الحماية الأمنية المقابلة إلى هذه الواجهة، لذا مضاعفة -هجمات الإنفاق موجودة أيضًا، وهي تشكل خطرًا كبيرًا على السلامة.
5. حل ERC-7520
بناءً على المشكلات المذكورة أعلاه، اقترح Beosin EIP-7520 لمنع هذا النوع من المخاطر الأمنية، وعلى وجه التحديد، يجب على جميع مشاريع DApp التي تستخدم تقنية zk في النظام البيئي Ethereum تنفيذ هذه الواجهة في عقد التحقق المتوافق لاستخدام معايير موحدة وآمنة. التحقق من نطاق صالح على كافة المدخلات.الواجهة المحددة هي كما يلي:
صلابة pragma ^0.5.6;/// @title EIP-XXXX zk-SNARK public inputs Verifier Standard/// ملاحظة: معرف ERC-165 لهذه الواجهة هو 0xXXXXXXXX./// ⚠️ TODO: حساب معرف الواجهةinterface EIP7520 /* هو ERC165 & ERC1922 */ { /// @notice يتحقق من وجود وسيطات المدخلات داخل الحقل العددي /// @dev /// يجب أن يعود صحيحًا إذا مرت المدخلات بالنطاق (أي أن المدخلات /// صالحة). /// يجب إرجاع خطأ إذا لم تنجح المدخلات في اجتياز فحص النطاق (أي إذا كانت /// المدخلات غير صالحة). /// @param inputs المدخلات العامة المصاحبة للدليل. /// @param p المدخلات العامة المصاحبة للمنحنى. دالة VerePublicInput(uint256[] inputs，uint256 p) عوائد خارجية (نتيجة منطقية)；}
تعد وظيفة VerePublicInput جوهر هذا المعيار، والمعاني المحددة للمعلمات المعنية هي كما يلي:
المدخلات: محددة كنوع uint256[]، تمثل معلمات الإشارة العامة المشاركة في وظيفة التحقق في مشروع ZKP
p: تم تعريفها كنوع uint256، وتتوافق هذه القيمة مع القيمة p للمنحنى الإهليلجي المستخدم في الخوارزمية
فيما يلي مقارنة بين حالتي تنفيذ وعدم تنفيذ واجهة EIP-7520، بهدف تحديد المظاهر المختلفة لهذا الهجوم، للإشارة إلى المخاطر التي يتعرض لها أطراف المشروع:
1 افترض أننا نستخدم رمز عقد التحقق مباشرة للتحقق دون استدعاء VerePublicInput لواجهة eip هذه، الرمز المحدد هو كما يلي:
التحقق من الوظيفة (إدخال الذاكرة uint []، إثبات الذاكرة) إرجاع العرض الداخلي (uint) { VerifyingKey Memory vk = VerifyingKey(); require(input.length + 1 == vk.IC.length,"verifier-bad-input"); // حساب المجموعة الخطية vk_x Pairing.G1Point Memory vk_x = Pairing.G1Point(0, 0); for (uint i = 0; i < input. length; i++) vk_x = Pairing.addition(vk_x, Pairing.scalar_mul(vk.IC[i + 1], input [i] )); vk_x = Pairing.addition(vk_x, vk.IC [0] ); if (!Pairing.pairingProd4( Pairing.negate(proof.A), Proof.B, vk.alfa1, vk.beta2, vk_x, vk.gamma2,proof.C, vk.delta2 )) return 1; العودة 0؛}
لقطة شاشة للنتائج التجريبية الأصلية التي تثبت اجتياز عملية التحقق:
في الوقت نفسه، يمكن تزوير الشهادات الأربع التالية ويمكنها أيضًا اجتياز عملية التحقق، مما يتسبب في هجوم الإنفاق المزدوج:
وباستخدام أحد الأدلة المزورة تكون نتائج التحقق كما هو موضح أدناه:
2 إذا تم استدعاء واجهة VerePublicInput في eip هذا، فسوف يفشل التحقق من الدليل المزور أعلاه. جزء من رمز العقد كما يلي. للحصول على التفاصيل المتبقية، يرجى الرجوع إلى التنفيذ المرجعي:
دالة Verex(uint[] Memory inputs, Proof Memory Proof, bytes32 VerificationKeyId,uint256 p) public return (uint){ require(verifyPublicInput(inputs,p),"verifier-over-snark-scalar-field"); require(verify(inputs,proof,verificationKeyId),"التحقق من الفشل"); return true;}وظيفة VerePublicInput(uint256[] inputs，uint256 p) إرجاع العرض الداخلي (bool) { for (uint i = 0; i < input. length; i++) { require(input < p,"verifier-gte-snark -المجال العددي"); } العودة صحيحة؛}
وتظهر النتائج التجريبية في الشكل أدناه:
باختصار، يمكن العثور على أنه إذا لم يتم استخدام هذه الواجهة للتحقق من صحة نطاق قيمة الإشارة العامة، فقد يكون هناك خطر وقوع هجمات الإنفاق المزدوج. **
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
شرح تفصيلي لمسودة ERC-7520: حماية هجوم تجاوز سعة المدخلات العامة zk-SNARK
المؤلف: خبراء أبحاث الأمن Beosin سايا وبرايس
1. ما هو إثبات المعرفة الصفرية
إثبات المعرفة الصفرية (ZKP) هو مفهوم تشفير يمكن استخدامه لإثبات صحة بيان ما دون الكشف عن أي معلومات محددة حول البيان. في برهان المعرفة الصفرية، يمكن للمحقق أن يثبت للمحقق أن عبارة معينة صحيحة، ولا يحصل المتحقق إلا على نتيجة واحدة: إما قبول العبارة على أنها صحيحة أو رفضها، دون معرفة التفاصيل المحددة للبرهان.
يمكن شرح هذا المفهوم بمثال بسيط. لنفترض أن هناك شخصين، أحدهما هو المثبت والآخر هو المتحقق. يريد المثبت أن يثبت للمدقق أنه يعرف كلمة المرور السرية دون الكشف عن كلمة المرور نفسها. في الطريقة التقليدية، قد يخبر المثبت المدقق ما هي كلمة المرور، ولكن في إثبات المعرفة الصفرية، يمكن للمثبت استخدام بروتوكول خاص ليثبت للمتحقق أنه يعرف صحة كلمة المرور دون الكشف عن كلمة المرور نفسها.
حاليًا، تتضمن خوارزميات نظام إثبات المعرفة الصفرية الشائعة zk-SNARKs وzk-STARKs وBulletProofs وما إلى ذلك.
2. تطبيق ZKP في blockchain
في تقنية blockchain، لدى ZKP مجموعة متنوعة من التطبيقات، مثل تحسين الخصوصية، وتحسين قابلية التوسع والأمان، وما إلى ذلك. فيما يلي بعض التطبيقات الرئيسية لـ ZKP في blockchain:
1 حماية الخصوصية:
إن blockchain عام، مما يعني أنه يمكن لأي شخص عرض جميع المعاملات على السلسلة. ومع ذلك، في بعض الأحيان، قد يرغب المستخدمون في الحفاظ على خصوصية معلومات معاملاتهم. يتيح ZKP للمستخدمين إثبات أن لديهم أموالًا كافية للتداول دون الحاجة إلى الكشف عن إجمالي أموالهم. وهذا يعزز بشكل كبير حماية خصوصية المستخدم. على سبيل المثال، Zcash هي عملة مشفرة تستخدم تقنية إثبات المعرفة الصفرية، والتي تسمح للمستخدمين بإخفاء المرسل والمستلم ومبلغ المعاملة.
2 الضغط الحسابي وتوسيع blockchain:
تمثل قابلية التوسع في تقنية Blockchain تحديًا، خاصة في التطبيقات واسعة النطاق. يمكن استخدام ZKP لتقليل العبء على العقد وتحسين قابلية التوسع للنظام بأكمله. باستخدام ZKP للتحقق من صحة المعاملات، لا تحتاج العقد إلى عرض سجل المعاملات الكامل، وبالتالي تقليل عبء التخزين والمعالجة. ZK Rollup، الأكثر استخدامًا حاليًا، هو حل قابل للتوسع مصمم لتحسين Ethereum ومجالات أخرى. إنتاجية وكفاءة شبكات blockchain. فهو يجمع بين مزايا تقنيات Rollup وZKP لتوفير حلول توسيع التطبيقات اللامركزية (DApps) عالية الأداء. على شبكة إيثريوم التقليدية، يجب التحقق من كل معاملة وتسجيلها على blockchain، مما يؤدي إلى تأخير وارتفاع تكاليف معالجة المعاملات. يقوم ZK Rollup بتجميع وضغط عدد كبير من المعاملات في كتلة واحدة، ويتم استخدام ZKP لإثبات صحة المعاملات المجمعة لضمان صحة وأمن المعاملات.
3 المصادقة:
يمكن استخدام إثباتات المعرفة الصفرية للتحقق من هوية المستخدم دون الكشف عن معلومات شخصية حساسة. على سبيل المثال، يمكن لأي شخص استخدام إثباتات المعرفة الصفرية ليثبت للشبكة أنه يستوفي شرطًا معينًا للعمر أو يمتلك شهادة معينة دون الكشف عن عمره الدقيق أو معلومات تعريفية أخرى.
4 التخزين اللامركزي:
يمكن للخادم أن يثبت للمستخدمين أن بياناتهم محفوظة بشكل آمن وأنه لا يتم تسريب أي محتوى من البيانات.
بشكل عام، **يتمتع إثبات المعرفة الصفرية الخاص بـ blockchain بتطبيقات واسعة في حماية الخصوصية، وضغط الحوسبة وتوسيعها، والتحقق من الهوية، والتخزين اللامركزي، وما إلى ذلك. يوفر المزيد من الوظائف والخيارات لتقنية blockchain ويعزز تطوير وتطبيق blockchain في مختلف المجالات. **
3. هجوم الإنفاق المزدوج في تطبيقات ZKP
zk-SNARK (حجة المعرفة المقتضبة وغير التفاعلية للمعرفة الصفرية) هي تقنية تعتمد على دليل المعرفة الصفرية الذي يمكن أن يثبت صحة البيان دون الكشف عن معلومات حقيقية. إنها تقنية فعالة للغاية لإثبات المعرفة الصفرية ويمكنها إنشاء البراهين والتحقق منها في وقت قصير جدًا مع حماية الخصوصية والأمان، لذلك يتم استخدامها على نطاق واسع. ومع ذلك، مع توسع التطبيقات، اجتذب أمنها المزيد والمزيد من الاهتمام. لقد اكتشفنا ثغرتها العامة منذ وقت ليس ببعيد: إذا لم يتم التحقق من نطاق قيمة إدخال المعلمة في وظيفة التحقق بشكل صحيح في مشروع ZKP، فيمكن للمهاجم تزوير مدخلات متعددة لتمرير التحقق، مما يتسبب في هجوم الإنفاق المزدوج. تأثير هذا الهجوم واسع جدًا، حيث يشمل خوارزميات zk-SNARK المتعددة بما في ذلك: groth16 و plonk وغيرها، وتوجد هذه الثغرة الأمنية في العديد من لغات التطوير مثل Solidity و js. تم اكتشاف هذه الثغرة الأمنية لأول مرة بواسطة poma في مشروع إثبات المعرفة الصفرية Semaphore، وتم تقديم مثالين للمعاملات التي تم تنفيذها بنجاح، كما هو موضح في الشكل أدناه:
مبدأ الهجوم المحدد لهذه الثغرة الأمنية هو أنه إذا كنت تريد إنشاء دليل zk-SNARK والتحقق منه في Ethereum، فأنت بحاجة إلى استخدام دائرة المنحنى الإهليلجي للمجال المحدود F_p-arithmetic، حيث يتم استخدام القيمة p لتحديد النطاق للمجال المحدود للمنحنى الإهليلجي، وبالتالي فإن نطاق قيمة الإدخال للدائرة هو [0,1,...,p-1]. منحنيات مختلفة لها قيم p مختلفة:
منحنى BN254 المحدد في EIP-196 (المعروف أيضًا باسم منحنى ALT_BN128):
ع = 21888242871839275222246405745257275088548364400416034343698204186575808495617
يقدم circom2 عددين أوليين جديدين، منحنيات BLS12-381:
ع = 52435875175126190479447740508185965837690552500527637822603658699938581184513
وبلنك2:
18446744069414584321
قامت Semaphore لاحقًا بتأكيد الثغرة وإصلاحها، كما قامت مكتبات zk مثل ZoKrates وsnarkjs بإجراء إصلاحات طارئة في وقت واحد، ومع ذلك، وجد باحثو الأمن في Beosin أنه لا يوجد حاليًا حل موحد لهذه المشكلة، على سبيل المثال، يكتب بروتوكول Semaphore قيودًا في الاقتران مكتبة. لم يتم التحقق من النطاق الصالح للبيانات بشكل صريح في منطق الأعمال الخارجي؛ كود العقد الذي تم إنشاؤه بواسطة circom وTornado.Cash يتحقق بشكل صريح من SNARK_SCALAR_FIELD في وظيفة التحقق. هذا حل مربك وغير متسق. قد يتسبب في المشاكل والمخاطر الأمنية التي تواجه العديد من أطراف مشروع zk DApp الجديد، لذلك نأمل في استخدام طريقة موحدة لحل هذه المشكلة.
4. هجوم الإنفاق المزدوج في ERC-1922
حاليًا، لدى Ethereum معيار EIP-1922 المتعلق بـ zk، والذي يقدم واجهة التحقق القياسية للعقد للتحقق من zk-SNARK، والرمز المحدد هو كما يلي:
صلابة البراغما ^0.5.6;/// @title EIP-XXXX zk-SNARK Verifier Standard/// @dev راجع /// ملاحظة: معرف ERC-165 لهذه الواجهة هو 0xXXXXXXXX./// ⚠️ TODO: حساب الواجهة identifierinterface ERC1922 /* is ERC165 */ { /// @notice يتحقق من وسيطات الدليل من خلال منحنى إهليلجي /// وظائف الاقتران. /// @dev /// يجب أن يُرجع صحيحًا إذا نجح الدليل في جميع عمليات التحقق (أي أن الدليل /// صالح). /// يجب إرجاع خطأ إذا لم ينجح الدليل في جميع عمليات التحقق (أي إذا كان /// الدليل غير صالح). /// @param إثبات Zk-SNARK. /// @param inputs المدخلات العامة المصاحبة للإثبات. /// @param VerificationKeyId معرف فريد (معروف لهذا المدقق /// العقد) لمفتاح التحقق الذي يتوافق معه الإثبات. ///return result نتيجة حساب التحقق. صحيح /// إذا كان الدليل صالحًا؛ كاذبة خلاف ذلك. التحقق من الوظيفة (uint256[] إثبات بيانات الاتصال، uint256[] مدخلات بيانات الاتصال، التحقق bytes32KeyId) الإرجاعات الخارجية (نتيجة منطقية)؛}
من بينها، أنواع إثبات المعرفة الصفرية ومتغيرات المدخلات هي uint256[].هذا النوع المتغير هو حاليًا عملية المنحنى الإهليلجي الأكثر استخدامًا في خوارزمية ZKP، ومع ذلك، لا تتم إضافة الحماية الأمنية المقابلة إلى هذه الواجهة، لذا مضاعفة -هجمات الإنفاق موجودة أيضًا، وهي تشكل خطرًا كبيرًا على السلامة.
5. حل ERC-7520
بناءً على المشكلات المذكورة أعلاه، اقترح Beosin EIP-7520 لمنع هذا النوع من المخاطر الأمنية، وعلى وجه التحديد، يجب على جميع مشاريع DApp التي تستخدم تقنية zk في النظام البيئي Ethereum تنفيذ هذه الواجهة في عقد التحقق المتوافق لاستخدام معايير موحدة وآمنة. التحقق من نطاق صالح على كافة المدخلات.الواجهة المحددة هي كما يلي:
صلابة pragma ^0.5.6;/// @title EIP-XXXX zk-SNARK public inputs Verifier Standard/// ملاحظة: معرف ERC-165 لهذه الواجهة هو 0xXXXXXXXX./// ⚠️ TODO: حساب معرف الواجهةinterface EIP7520 /* هو ERC165 & ERC1922 */ { /// @notice يتحقق من وجود وسيطات المدخلات داخل الحقل العددي /// @dev /// يجب أن يعود صحيحًا إذا مرت المدخلات بالنطاق (أي أن المدخلات /// صالحة). /// يجب إرجاع خطأ إذا لم تنجح المدخلات في اجتياز فحص النطاق (أي إذا كانت /// المدخلات غير صالحة). /// @param inputs المدخلات العامة المصاحبة للدليل. /// @param p المدخلات العامة المصاحبة للمنحنى. دالة VerePublicInput(uint256[] inputs，uint256 p) عوائد خارجية (نتيجة منطقية)；}
تعد وظيفة VerePublicInput جوهر هذا المعيار، والمعاني المحددة للمعلمات المعنية هي كما يلي:
فيما يلي مقارنة بين حالتي تنفيذ وعدم تنفيذ واجهة EIP-7520، بهدف تحديد المظاهر المختلفة لهذا الهجوم، للإشارة إلى المخاطر التي يتعرض لها أطراف المشروع:
1 افترض أننا نستخدم رمز عقد التحقق مباشرة للتحقق دون استدعاء VerePublicInput لواجهة eip هذه، الرمز المحدد هو كما يلي:
التحقق من الوظيفة (إدخال الذاكرة uint []، إثبات الذاكرة) إرجاع العرض الداخلي (uint) { VerifyingKey Memory vk = VerifyingKey(); require(input.length + 1 == vk.IC.length,"verifier-bad-input"); // حساب المجموعة الخطية vk_x Pairing.G1Point Memory vk_x = Pairing.G1Point(0, 0); for (uint i = 0; i < input. length; i++) vk_x = Pairing.addition(vk_x, Pairing.scalar_mul(vk.IC[i + 1], input [i] )); vk_x = Pairing.addition(vk_x, vk.IC [0] ); if (!Pairing.pairingProd4( Pairing.negate(proof.A), Proof.B, vk.alfa1, vk.beta2, vk_x, vk.gamma2,proof.C, vk.delta2 )) return 1; العودة 0؛}
لقطة شاشة للنتائج التجريبية الأصلية التي تثبت اجتياز عملية التحقق:
في الوقت نفسه، يمكن تزوير الشهادات الأربع التالية ويمكنها أيضًا اجتياز عملية التحقق، مما يتسبب في هجوم الإنفاق المزدوج:
وباستخدام أحد الأدلة المزورة تكون نتائج التحقق كما هو موضح أدناه:
2 إذا تم استدعاء واجهة VerePublicInput في eip هذا، فسوف يفشل التحقق من الدليل المزور أعلاه. جزء من رمز العقد كما يلي. للحصول على التفاصيل المتبقية، يرجى الرجوع إلى التنفيذ المرجعي:
دالة Verex(uint[] Memory inputs, Proof Memory Proof, bytes32 VerificationKeyId,uint256 p) public return (uint){ require(verifyPublicInput(inputs,p),"verifier-over-snark-scalar-field"); require(verify(inputs,proof,verificationKeyId),"التحقق من الفشل"); return true;}وظيفة VerePublicInput(uint256[] inputs，uint256 p) إرجاع العرض الداخلي (bool) { for (uint i = 0; i < input. length; i++) { require(input < p,"verifier-gte-snark -المجال العددي"); } العودة صحيحة؛}
وتظهر النتائج التجريبية في الشكل أدناه:
باختصار، يمكن العثور على أنه إذا لم يتم استخدام هذه الواجهة للتحقق من صحة نطاق قيمة الإشارة العامة، فقد يكون هناك خطر وقوع هجمات الإنفاق المزدوج. **