تعد البراهين / الحجج التي لا تُعرف بالمعرفة الصفرية هي تقنية تشفير ناشئة تعد بتقريبنا من الكأس المقدسة من blockchain: توفير خصوصية البيانات وقابلية المراجعة.
تشمل التطبيقات المحتملة للمعرفة الصفرية ، على سبيل المثال لا الحصر:
تطبيق آخر لبراهين المعرفة الصفرية يساعد في
توسيع نطاق المجموعات. تسمح ZKPs بـ "ضغط" العمليات الحسابية للمعاملات blockchain دون التضحية بالأمان.
في هذه المقالة ، وصفنا كيف يمكن تطبيق المعرفة الصفرية (على وجه التحديد ، Bulletproofs ) لإنشاء خدمة تركز على الخصوصية باستخدام منصة Bitfury's Exonum.
تحليل الموقف
من الممكن تحقيق مستوى معين من خصوصية البيانات في تطبيقات blockchain باستخدام نهج "walled garden" ، حيث يتم إخفاء البيانات لأن الوصول إليها مقيد بمساعدة جدران الحماية ، والتحكم في الوصول المستند إلى الأدوار ،
والخنادق وغيرها من تدابير الأمان المحيطة . قد يتم تشفير البيانات الحساسة في blockchain (ربما ، باستخدام نظام تشفير بالمفتاح العام ، مع المفاتيح العامة ذات الصلة التي تديرها نفس blockchain) و / أو تخزينها خارج blockchain (في هذه الحالة ، يخزن blockchain بصمات التجزئة فقط من البيانات). يتم استخدام هذا النهج في العديد من أطر عمل دفتر الأستاذ الموزعة.
ومع ذلك ، فإن مساوئ نهج "الحديقة المسورة" أصبحت واضحة بشكل متزايد. بعبارة صريحة ، فإن النهج يتناقض مع أحد نقاط البيع الرئيسية في blockchain - القدرة على التدقيق. إذا كان يتعذر تدقيق البيانات الموجودة على blockchain من خلال الرجوع إلى منطق العقد الذكي ، فإن blockchain يصبح خدمة ذات
طابع زمني مرتبط تمجيد. حقيقة أن هناك بعض البيانات على blockchain لم يعد يعني أن هذه البيانات صالحة وفقا لقواعد العقد الذكية. العيب الرئيسي الثاني لنهج الحديقة المسورة هو أنه لا يتوسع. على سبيل المثال ، قام CTO ريتشارد براون ، من شركة R3 ،
بمقارنة نموذج الخصوصية بحلها مع قنوات سلاك - من الصعب أن تضيف أو تزيل المشاركين بأمان من الحديقة ، حتى أكثر من ذلك عندما لا تكون هناك توقعات سابقة بشأن عدد وهويات هذه المشاركون.
هذا هو المكان
الذي يمكن أن تكون فيه
المعرفة الصفرية ذات قيمة. حسب التصميم ، تثبت أدلة وحجج المعرفة الصفرية بشكل مقنع بيان حول البيانات الخاصة دون الكشف عن أي شيء عن البيانات باستثناء البيان الذي يتم إثباته. من السهل جعل إثباتات المعرفة الصفرية قابلة للتحقق
عالميًا ، دون التضحية بأي خصوصية! ² هذه الميزة هي بالضبط ما يلزم لبناء نظام يحافظ على الخصوصية وقابل للتدقيق في نفس الوقت.
بحثنا
لإثبات استخدام أدلة عدم المعرفة ، سنقوم بإنشاء خدمة
عملة مشفرة ذات وظائف مماثلة للخدمات التعليمية في
وثائق Exonum . تتيح الخدمة إمكانية تسجيل المستخدمين والمحافظ (توفير رصيد رمزي أولي كمكافأة) ونقل الرموز بين الأطراف المسجلة. تتم مصادقة جميع المعاملات بمساعدة نظام تشفير التوقيع الرقمي ، Ed25519 ، والذي تم تضمينه في خدمات Exonum. لا نخفي هويات أطراف التداول (أي مفاتيحهم العامة) ، لكننا نخفي عدد الرموز التي يتم تداولها ورصيد كل حساب في النظام. نناقش أيضًا كيف يمكننا تحسين الخدمة لإخفاء كيانات المعاملات في نهاية المقالة.
الخدمة مفتوحة المصدر بالكامل ويمكن الوصول إليها
هنا .
خلفية التشفير
من أجل فهم كيفية عمل الخدمة ، نحتاج أولاً إلى تقديم أنفسنا إلى قواعد التشفير الأساسية التي تدعم أساسيات الرصاص - وهو مفهوم يسمى
التزامات Pedersen . يشبه نظام الالتزام بالتشفير نوعًا ما دالة دالة هاش: يقوم شخص ما بإدخال بيانات سرية (الافتتاح) ويحصل على الإخراج الذي يتم خلطه بشكل غير معروف (الالتزام). يمكن للمرء بعد ذلك الكشف عن الفتحة لإثبات أن القيمة الملتزمة تتوافق معها.
يتمثل الاختلاف في وظائف التجزئة في أنه إلى جانب كونه
ملزمًا (لا يمكن لأحد إنشاء فتحتين مختلفتين ينتجان نفس الالتزام) ، فمن المتوقع أيضًا أن يكون مخطط الالتزام
مختبئًا (من المستحيل عكس المخطط وإنتاج فتح معطى التزامًا). يتم إخفاء دالة التجزئة إذا تم توزيع مدخلاتها بشكل موحد حول مساحة الإدخال بأكملها ، ولكن هذا الافتراض في أغلب الأحيان لا ينطبق على الالتزامات (في الواقع ، يجب أن يكون من الممكن الالتزام بقيمة من مجموعة صغيرة جدًا ، مثل Boolean). على هذا النحو ، يحتوي الافتتاح ، إلى جانب الحمولة ، على
عامل التعمية الذي يجعله (على الأقل إحصائيًا) غير محتمل لتخمين الحمولة النافعة نظرًا للالتزام.
يستخدم مخطط التزام Pedersen مجموعة
من الأوامر الأولية ، حيث يُعتقد أن
مشكلة اللوغاريتم المنفصل (DLP) صعبة ، مع اثنين من المولدات ،
G و
H. يجب اختيار
G و
H بطريقة تجعل علاقة السجل المنفصلة بينهما غير معروفة ؛ بمعنى آخر ، لا أحد يعرف
k بحيث
H = kG .³ الفتحة هي زوج
(x ، r) ، حيث
x هي القيمة الملتزمة و
r هي عامل التعمية ؛ كلاهما عدديان جماعيان (في الأساس ، أعداد صحيحة مع "overflow" أقرب إلى أنواع عدد صحيح محدد تستخدم في معظم لغات البرمجة). يتم حساب الالتزام كـ
Comm (x؛ r) = xG + rH . يمكن إثبات أنه إذا كان DLP في المجموعة صعبًا ، فإن التزام Pedersen ملتزم حسابيًا ويختبئ تمامًا. perfectly
الخاصية الحاسمة لالتزامات Pedersen هي أنها مضافة: مجموع (أو فرق) الالتزامات 2 هو التزام بمجموع (أو فرق) القيم الملتزم بها. في الواقع ،
C1 = x1 G + r1 H; C2 = x2 G + r2 H => C1 + C2 = (x1 + x2) G + (r1 + r2) H = Comm(x1 + x2; r1 + r2).
لا ندرج التفاصيل هنا حول كيفية بناء المواد المضادة للرصاص والتحقق منها ، ولكن يمكن العثور على مزيد من المعلومات في الموارد التالية - [
1 ] و [
2 ]. يكفي أن نلاحظ أن الحد الأعلى للنطاق
M يفترض أن يكون له شكل
2 ^ (2 ^ n) ، الأمر الذي يؤدي إلى بناء أكثر فعالية.
بناء الخدمة
مع علمنا ، يمكننا إخفاء أرصدة الحسابات ونقل المبالغ بأمان بمساعدة التزامات Pedersen. باستخدام أدلة النطاق ، يمكننا إثبات / التحقق من صحة عملية النقل:
- المبلغ المحول ايجابي
- المرسل لديه رصيد كاف في حسابه.
كإثبات أول ، نلتزم بمبلغ التحويل ،
C_a (وهو موجود مباشرة في معاملة التحويل) ، وتحقق من أن القيمة التي تم الالتزام بها في
C_a-Comm (1؛ 0) تقع في النطاق
[0 ، M) . في الواقع ، هذا يعادل إثبات أن
C_a يتوافق مع قيمة في النطاق
[1 ، M] . يمكن للمرسل أن يقدم هذا الدليل ، لأنه يعرف المبلغ المحول
أ .
بالنسبة للإثبات الثاني ، نحتاج إلى الالتزام بالتوازن الحالي للمرسل ،
C_s ، والتحقق من أن القيمة التي تم الالتزام بها في
C_s-C_a تقع في النطاق
[0 ، M) . مرة أخرى ، يمكن للمرسل إنتاج هذا الدليل حيث يعرف / تفتح كل من
C_s و
C_a .
لتطبيق التحويل على حالة
blockchain ، نطالب بالتزام المبلغ
C_a من التزام المرسل بالتوازن (كما
تحققنا ، لا يمكن أن يؤدي ذلك إلى رصيد سلبي ، أو إلى زيادة رصيد المرسل) ، ثم نضيف
C_a إلى المتلقي التزام التوازن.
التفاصيل الرئيسية
من المهم ملاحظة أن هناك بعض الشروط التي يمكن أن تجعل الخدمة المنفذة أكثر تعقيدًا.
يجب أن يكتشف متلقي النقل فتحة
C_a من مكان ما ؛ خلاف ذلك ، لم يعد هو / هو يعرف الانفتاح على رصيده / رصيدها ولم يعد بإمكانه فعل أي شيء باستخدام محفظته. الافتتاح غير موجود في النص العادي لمعاملة التحويل (والذي هو بيت القصيد).
يمكن أن نفترض أن المتلقي يحصل بشكل موثوق على الفتح عبر قناة خارج السلسلة (على سبيل المثال ، يتم إرسالها من قبل المرسل عبر Telegram) ، لكن هذا ليس سيناريو توضيحي. لذا ، بدلاً من ذلك ، نقوم بتشفير الفتح باستخدام تشفير المفتاح العمومي المكون من طرفين استنادًا إلى تبادل مفتاح Diffie-Hellman (يستدعي libsodium هذا النوع من
مربع التشفير). من أجل الفائدة الإضافية ، يمكن تحويل مفاتيح Curve25519 المطلوبة لروتين
الصندوق من مفاتيح Ed25519 ، لذلك قد نواصل استخدام زوج مفاتيح واحد لكل مستخدم بدلاً من إدخال مفاتيح تشفير منفصلة.
بمجرد تقديم التشفير ، لم يعد بإمكاننا تطبيق النقل على نحو تلقائي. في الواقع ، يمكن للمرسل أن يقدم بشكل غير مقصود أو عن غير قصد القمامة بدلاً من تشفير الافتتاح ، ولن يتمكن منطق blockchain من معرفة أن هذا هو الحال. ⁶ لذلك ، نطلب من المتلقي قبول النقل بشكل صريح عبر معاملة منفصلة.
قبل قبول النقل ، فإنه يعدل التزام المرسل بالتوازن (وإلا ، فسنسمح بالإنفاق المزدوج!) ، ولكن ليس التزام المتلقي.
بمجرد تأكيد معاملة القبول من قبل شبكة blockchain ، يتم تحديث رصيد المتلقي ، ويكتمل النقل.
لمنع حدوث حالة توقف تام ، يحدد النقل تأخيرًا في قفل الوقت (في الارتفاع النسبي لكتلة المفاتيح ،
ملف CSV الخاص بـ Bitcoin) للمستقبل للإشارة إلى القبول. إذا انتهت صلاحية قفل الوقت ، فسيتم رد التحويل تلقائيًا إلى المرسل (يسمح Exonum بذلك عبر
خطاف Service :: beforeCommit () ).
قضية أخرى هي أكثر تعقيدا. من أجل تقديم دليل على وجود توازن كاف ، يحتاج المرسل إلى معرفة رصيده الحالي ، وهو ما قد لا يكون عليه الحال دائمًا. قد تؤدي معاملة القبول أو الاسترداد الضائع إلى زيادة رصيد المرسل إليه عن غير قصد ؛ في هذه الحالة ، ستفشل عملية النقل في التحقق ، وسيتم إحباط المرسل بشكل معقول.
للتخفيف من هذه المشكلة ، نسمح بالتحويلات للإشارة إلى ما يعتقده المرسل هو حالة المحفظة الحالية (بشكل أكثر دقة ، يأخذ المرجع شكل عدد الأحداث التي تغير رصيد الحساب - التحويلات والمبالغ المستردة). عند التحقق من إثبات وجود رصيد كاف ، نستخدم الحالة المرجعية للحصول على التزام المرسل بالتوازن. بالإضافة إلى ذلك ، نتحقق من عدم حدوث تحويلات صادرة منذ الحالة المشار إليها. إذا كان هذا هو الحال ، فيمكننا التأكد من أننا إذا طرحنا مبلغ التحويل من الرصيد
الحالي للمرسل ، فسننتهي بقيمة غير سالبة. في الواقع ، يمكن للأحداث في سجل الحساب بعد النقطة المرجعية (التحويلات الواردة والمبالغ المستردة) أن تزيد فقط الرصيد! ⁷
مع وجود نقاط مرجعية في مكانها ، لا يزال المرسل مقيدًا إلى حد ما ؛ يجب ألا يكون لديه أي عمليات نقل معلقة عند إنشاء عملية نقل جديدة. ومع ذلك ، فإن هذا التقييد أقل تقييدًا بكثير من شرط معرفة حالة حساب الشخص في لحظة النقل ؛ في الأساس ، نجعل المرسل يعتمد على ما فعله سابقًا ، ولكن ليس على تصرفات الآخرين.
التنفيذ
نستخدم مكتبة مضادة للرصاص مكتوبة
بصدأ نقي ، والتي وصلت مؤخرًا إلى
مرحلة ما قبل النشر . نظرًا لأن منصة Exonum مكتوبة باللغة Rust ، فهي تتكامل مع المكتبة بسلاسة. على سبيل المكافأة ، على عكس إصدار المواد المضادة للرصاص الموضحة في الورقة البيضاء الأصلية (التي يتم تطويرها في
C وتستخدم منحنى القطع البيضاوي secp256k1 في Bitcoin) ، تعتمد المكتبة التي نستخدمها على Curve25519 ، والذي يستخدم بالفعل في Exonum كمكون رئيسي في Ed25519 توقيع التشفير الرقمي.
تنفيذ الخدمة بناءً على الوصف أعلاه واضح ومباشر. كان الجزء الأكثر صعوبة هو إنشاء براهين Merkle التي تقوم بتوثيق المعلومات التي يتم إرجاعها إلى المستخدم حتى لا يضطر / يثق بثقة في عقد Exonum. يعد تحسين تجربة مطوري الخدمات في هذا الصدد أحد الأهداف الرئيسية
لإصدار Exonum 1.0 .
الخطوات التالية
الخدمة التي بنيناها لا تخفي هويات المرسل ومتلقي التحويلات ، وهو قيد رئيسي للتطبيقات الواقعية. لحسن الحظ ، هناك طرق لحل هذه المشكلة.
تعتمد التقنية العامة المستخدمة في
zCash (ولكن تنطبق بشكل أساسي على حالات الاستخدام الأخرى ، مثل
Ethereum ) على إنشاء
شجرة Merkle لحالة النظام. على سبيل المثال ، تقوم zCash بإنشاء
شجرة التزام الملاحظة ، والتي تعادل تقريبًا مخرجات المعاملات التي تم إنشاؤها في Bitcoin. تشمل براهين المعرفة الصفرية مسارات المصادقة (تُعرف أيضًا باسم فروع Merkle) في هذه الشجرة ، وتكشف عن شيء ما حول عنصر من عناصر الشجرة دون الكشف عن العنصر المشار إليه. الجانب السلبي لهذا النهج هو أن وظائف تجزئة التشفير المستخدمة لبناء أشجار Merkle يصعب نقلها إلى عالم المعرفة الصفرية ؛ تصبح البراهين الناتجة مكلفة من الناحية الحسابية - يمكن أن يستغرق إثبات واحد ثوانٍ أو حتى دقائق لإنشاء. إن البحث عن المزيد من وظائف تجزئة التشفير "الصديقة لل ZKP" هو مجال البحث النشط.
إذا اعترفنا بوجود قيود إضافية ، فقد يكون هناك حل أسهل. على سبيل المثال ، ورقة حديثة من إعداد
نارولا وآخرون . يصف نظامًا به عدد محدود ومعروف مسبقًا من المشاركين ، والذي يمكنه التعامل فيما بينهم دون الكشف عن المشاركين أو المبالغ المحولة لأي معاملة. (فكر في شبكة blockchain تركز على الخصوصية للتحويلات بين البنوك.)
في ملاحظة أكثر واقعية ، من المحتمل أن يكون هناك العديد من التحسينات التقنية التي يمكن أن تتمتع بها الخدمة المتقدمة: المزيد من تغطية الاختبار ، وفصل مفاتيح التوقيع والتشفير ، والقياس ، إلخ. سيكون هناك تحسن كبير في خدمة UX هو تمكين الترتيب الحاسم للمعاملات الناشئة من نفس المستخدم ، والتي نخطط لحلها بعد وقت قصير من إطلاق Exonum 1.0.
الخاتمة
لقد وصفنا كيفية إنشاء cryptotoken القائم على الحساب مع خصوصية قوية ممكنة من قبل البراهين المعرفة صفر (على وجه التحديد ، مقاومة للرصاص). تم تطبيق منطق الرمز المميز كخدمة Exonum. على الرغم من أن الخدمة في الوقت الحالي هي مجرد دليل على المفهوم ، إلا أنها تعرض كيف يمكن استخدام منصة Exonum لبناء أوليات تشفير معقدة مع حمل منخفض للغاية تفرضه بيئة التنفيذ.
- هناك تمييز معقد بين البراهين والحجج ، والتي لن ندخلها هنا. من أجل البساطة ، سنشير إلى جميع إنشاءات المعرفة الصفرية في هذه المقالة كدليل على المعرفة الصفرية حتى لو لم يكن هذا صحيحًا دائمًا من الناحية النظرية.
- يمكن تحقيق ذلك من خلال تقنية عامة جدًا تُعرف باسم تحويل Fiat - Shamir ، والذي يحول بروتوكول إثبات تفاعلي إلى بروتوكول غير تفاعلي يمكن التحقق منه عالميًا. التضحية بالدقة العلمية مرة أخرى ، لن نوضح بشكل صريح أن البراهين على المعرفة الصفرية التي نستخدمها غير تفاعلية.
- يتم اختيار المولدات الكهربائية عادةً باستخدام طريقة "لا شيء على الإطلاق". على سبيل المثال ، قد تكون G جزءًا من مواصفات المجموعة لاستخدامها في تشفير المفتاح العام ، وتستمد H من G عبر دالة هاش: H ~ hash (G) .
- هذا الأخير يعني أنه حتى الخصوم ذو القدرة الحاسوبية اللانهائية لا يمكن أن يستنتج ما يلتزم به الالتزام ؛ بالفعل ، إذا تم كسر DLP في المجموعة ، يمكن فتح كل التزام بأي قيمة ممكنة.
- هذا جزئيًا قرار إثبات المفهوم ؛ بشكل عام ، إعادة استخدام المفاتيح لأغراض مختلفة هي فكرة سيئة.
- من الناحية النظرية ، من الممكن تقديم دليل على المعرفة الصفرية للقيمة المشفرة بما يعادل الرصيد الملتزم ؛ ومع ذلك ، فإنه سيزيد من تعقيد نظام التعقيد.
- تجدر الإشارة إلى أن بعض عمليات النقل التي تخرق قاعدة "لا يوجد تحويلات صادرة منذ الحالة المشار إليها" يمكن أن تظل صحيحة ؛ ليس لدينا طريقة للتحقق من ذلك.