لقد اهتممنا بموضوع عدم الكشف عن هويته في العملات المشفرة لفترة طويلة ونحاول متابعة تطور التقنيات في هذا المجال. لقد ناقشنا بالفعل في مقالاتنا بالتفصيل مبادئ التشغيل في مونيرو، ونفذت أيضا التقنيات الموجودة في هذا المجال. ومع ذلك، فإن جميع العملات المشفرة المجهولة اليوم مبنية على نموذج البيانات الذي اقترحته Bitcoin - مخرجات المعاملات غير المنفقة (المشار إليها فيما بعد بـ UTXO). بالنسبة لسلاسل الكتل القائمة على الحسابات مثل Ethereum، فإن الحلول الحالية لتنفيذ إخفاء الهوية والسرية (على سبيل المثال، أو ) حاول تكرار نموذج UTXO في العقود الذكية.
في فبراير 2019، قام مجموعة من الباحثين من جامعة ستانفورد وشركة Visa Research صدر "Zether: نحو الخصوصية في عالم العقود الذكية." كان المؤلفون أول من اقترح نهجًا لضمان عدم الكشف عن الهوية في سلاسل الكتل القائمة على الحسابات، وقدموا نسختين من العقد الذكي: للمعاملات السرية (إخفاء الأرصدة ومبالغ التحويل) والمعاملات المجهولة (إخفاء المستلم والمرسل). نجد أن التكنولوجيا المقترحة مثيرة للاهتمام ونرغب في مشاركة تصميمها، وكذلك التحدث عن سبب اعتبار مشكلة إخفاء الهوية في blockchain القائمة على الحسابات صعبة للغاية وما إذا كان المؤلفون قد تمكنوا من حلها بالكامل.
حول هيكل نماذج البيانات هذه
في نموذج UTXO، تتكون المعاملة من "المدخلات" و"المخرجات". التماثل المباشر لـ "المخرجات" هو الفواتير الموجودة في محفظتك: كل "مخرجات" له فئة معينة. عندما تدفع لشخص ما (من خلال معاملة)، فإنك تنفق واحدًا أو أكثر من "المخرجات"، وفي هذه الحالة تصبح "مدخلات" للمعاملة، وتضع blockchain علامة عليها على أنها منفقة. في هذه الحالة، يتلقى متلقي دفعتك (أو أنت نفسك، إذا كنت بحاجة إلى التغيير) "المخرجات" التي تم إنشاؤها حديثًا. يمكن تمثيل ذلك بشكل تخطيطي مثل هذا:
يتم تنظيم blockchain القائم على الحساب بشكل يشبه إلى حد كبير حسابك المصرفي. إنهم يتعاملون فقط مع المبلغ الموجود في حسابك ومبلغ التحويل. عندما تقوم بتحويل مبلغ ما من حسابك، فإنك لا تحرق أي "مخرجات"، ولا تحتاج الشبكة إلى تذكر العملات المعدنية التي تم إنفاقها وتلك التي لم يتم إنفاقها. في أبسط الحالات، يتم التحقق من المعاملة من خلال التحقق من توقيع المرسل والمبلغ الموجود في رصيده:
تحليل التكنولوجيا
بعد ذلك، سنتحدث عن كيفية إخفاء Zether لمبلغ المعاملة والمستلم والمرسل. عندما نصف مبادئ عملها، سنلاحظ الاختلافات في الإصدارات السرية والمجهولة. نظرًا لأنه من الأسهل بكثير ضمان السرية في سلاسل الكتل القائمة على الحسابات، فإن بعض القيود التي يفرضها إخفاء الهوية لن تكون ذات صلة بالنسخة السرية من التكنولوجيا.
- إخفاء الأرصدة وتحويل المبالغ
يتم استخدام نظام التشفير لتشفير الأرصدة ونقل المبالغ في Zether . يعمل على النحو التالي. عندما تريد أليس أن ترسل بوب b العملات المعدنية حسب العنوان (مفتاحها العام) Y، اختارت رقمًا عشوائيًا r ويقوم بتشفير المبلغ:
حيث C - المبلغ المشفر، D - القيمة المساعدة اللازمة لفك هذا المبلغ، G - نقطة ثابتة على المنحنى الإهليلجي، عند ضربها بالمفتاح السري يتم الحصول على المفتاح العمومي.
عندما يتلقى بوب هذه القيم، فإنه ببساطة يضيفها إلى رصيده المشفر بنفس الطريقة، وهذا هو السبب في أن هذا المخطط مناسب.
وبالمثل، تطرح أليس نفس القيم من رصيدها، فقط كما Y يستخدم مفتاحك العام.
إخفاء المستلم والمرسل
يعود خلط "المخرجات" في UTXO إلى الأيام الأولى للعملات المشفرة ويساعد على إخفاء المرسل. للقيام بذلك، يقوم المرسل نفسه، عند إجراء التحويل، بجمع "مخرجات" عشوائية في blockchain ويمزجها مع مخرجاته الخاصة. بعد ذلك، يقوم بتوقيع "المخرجات" بتوقيع حلقة - وهي آلية تشفير تسمح له بإقناع المدقق بأن عملات المرسل موجودة بين "المخرجات" المعنية. وبطبيعة الحال، لا يتم إنفاق العملات المختلطة نفسها.
ومع ذلك، لن نتمكن من إنشاء مخرجات زائفة لإخفاء المستلم. لذلك، في UTXO، كل "مخرجات" لها عنوان فريد خاص بها، وهي مرتبطة بشكل مشفر بعنوان مستلم هذه العملات. في الوقت الحالي، لا توجد طريقة لتحديد العلاقة بين عنوان الإخراج الفريد وعنوان المستلم دون معرفة مفاتيحه السرية.
في النموذج القائم على الحساب، لا يمكننا استخدام عناوين لمرة واحدة (وإلا سيكون بالفعل نموذج "مخارج"). لذلك، يجب أن يتم الخلط بين المستلم والمرسل بين الحسابات الأخرى في البلوكشين. في هذه الحالة، يتم خصم 0 عملة مشفرة من الحسابات المختلطة (أو تتم إضافة 0 إذا كان المستلم مختلطًا)، دون تغيير رصيده الحقيقي فعليًا.
نظرًا لأن كلاً من المرسل والمستلم لديهم دائمًا عنوان دائم، يصبح من الضروري استخدام نفس المجموعات للخلط عند النقل إلى نفس العناوين. من الأسهل النظر إلى هذا بمثال.
لنفترض أن أليس قررت المساهمة في مؤسسة بوب الخيرية، ولكنها تفضل أن تظل عملية النقل مجهولة المصدر لمراقب خارجي. ومن ثم، لكي تتنكر في حقل المرسل، تدخل أيضًا في حسابات آدم وأديل. ولإخفاء بوب، أضف حسابات بن وبيل في حقل المستلم. من خلال المساهمة التالية، قررت أليس أن تكتب Alex وAmanda بجانبها، وبروس وBenjen بجانب Bob. في هذه الحالة، عند تحليل blockchain، يوجد في هاتين المعاملتين زوج واحد فقط من المشاركين المتقاطعين - Alice وBob، الذي يقوم بإلغاء إخفاء هوية هذه المعاملات.
سباقات المعاملات
كما ذكرنا سابقًا، لإخفاء رصيدك في الأنظمة القائمة على الحسابات، يقوم المستخدم بتشفير رصيده ومبلغ التحويل. وفي الوقت نفسه، يجب عليه أن يثبت أن الرصيد في حسابه لا يزال غير سلبي. المشكلة هي أنه عند إنشاء معاملة، يقوم المستخدم ببناء دليل بشأن حالة حسابه الحالي. ماذا يحدث إذا أرسل بوب معاملة إلى أليس، وتم قبولها قبل تلك التي أرسلتها أليس؟ بعد ذلك، سيتم اعتبار معاملة أليس غير صالحة، حيث تم إنشاء إثبات الرصيد قبل قبول معاملة بوب.
القرار الأول الذي يأتي في مثل هذه الحالة هو تجميد الحساب حتى يتم تنفيذ المعاملة. لكن هذا النهج غير مناسب، لأنه بالإضافة إلى تعقيد حل مثل هذه المشكلة في نظام موزع، في مخطط مجهول لن يكون من الواضح حساب من سيتم حظره.
ولحل هذه المشكلة، تفصل التكنولوجيا بين المعاملات الواردة والصادرة: للإنفاق تأثير فوري على الميزانية العمومية، في حين أن للإيصالات تأثير مؤجل. للقيام بذلك، تم تقديم مفهوم "العصر" - مجموعة من الكتل ذات حجم ثابت. يتم تحديد "العصر" الحالي عن طريق قسمة ارتفاع الكتلة على حجم المجموعة. عند معالجة معاملة ما، تقوم الشبكة على الفور بتحديث رصيد المرسل وتخزين أموال المستلم في خزان تخزين. ولا تتاح الأموال المتراكمة للمستفيد إلا عندما يبدأ "عصر" جديد.
ونتيجة لذلك، يمكن للمستخدم إرسال المعاملات بغض النظر عن عدد مرات استلام الأموال (بالقدر الذي يسمح به رصيده بالطبع). يتم تحديد حجم العصر بناءً على مدى سرعة انتشار الكتل عبر الشبكة ومدى سرعة دخول المعاملة إلى الكتلة.
يعمل هذا الحل بشكل جيد مع التحويلات السرية، ولكن مع المعاملات المجهولة، كما سنرى لاحقًا، فإنه يخلق مشاكل خطيرة.
الحماية ضد هجمات الإعادة
في سلاسل الكتل القائمة على الحساب، يتم توقيع كل معاملة بواسطة المفتاح الخاص للمرسل، مما يقنع المدقق بأن المعاملة لم يتم تعديلها وتم إنشاؤها بواسطة مالك هذا المفتاح. ولكن ماذا لو اعترض المهاجم الذي كان يستمع إلى قناة الإرسال هذه الرسالة وأرسل نفس الرسالة الثانية بالضبط؟ وسيقوم المدقق بالتحقق من توقيع المعاملة والاقتناع بمؤلفها، وستقوم الشبكة بشطب نفس المبلغ من رصيد المرسل مرة أخرى.
ويسمى هذا الهجوم هجوم الإعادة. في نموذج UTXO، مثل هذه الهجمات ليست ذات صلة، حيث سيحاول المهاجم استخدام المخرجات المستهلكة، والتي في حد ذاتها غير صالحة وترفضها الشبكة.
ولمنع حدوث ذلك، يتم تضمين حقل يحتوي على بيانات عشوائية في المعاملة، وهو ما يسمى nonce أو ببساطة "salt". عند إعادة إرسال معاملة بالملح، يبحث المدقق لمعرفة ما إذا كان الرقم قد تم استخدامه من قبل، وإذا لم يكن الأمر كذلك، يعتبر المعاملة صالحة. من أجل عدم تخزين سجل تسجيلات المستخدم بالكامل في blockchain، عادةً ما يتم تعيينه على صفر في المعاملة الأولى، ثم يتم زيادته بمقدار واحد. يمكن للشبكة فقط التحقق من أن عدد المعاملة الجديدة يختلف عن المعاملة السابقة تلو الأخرى.
في نظام النقل المجهول، تنشأ مشكلة التحقق من صحة المعاملات. لا يمكننا ربط الرقم صراحةً بعنوان المرسل، حيث من الواضح أن هذا يؤدي إلى إلغاء إخفاء هوية عملية النقل. لا يمكننا أيضًا إضافة واحدة إلى الأرقام غير الموجودة في جميع الحسابات المشاركة، لأن هذا قد يتعارض مع عمليات النقل الأخرى التي تتم معالجتها.
يقترح مؤلفو Zether إنشاء الرقم nonce بطريقة مشفرة، اعتمادًا على "العصر". على سبيل المثال:
ومن x هو المفتاح السري للمرسل، و جيبوش - مولد إضافي للعصر، يتم الحصول عليه عن طريق تجزئة سلسلة من النموذج "Zether +". الآن يبدو أن المشكلة قد تم حلها - فنحن لا نكشف عن رقم المرسل ولا نتدخل في أرقام المشاركين غير المشاركين. لكن هذا النهج يفرض قيودًا خطيرة: لا يمكن لحساب واحد أن يرسل أكثر من معاملة واحدة لكل "عصر". لسوء الحظ، لا تزال هذه المشكلة دون حل، وتجعل النسخة المجهولة من Zether، في رأينا، غير مناسبة للاستخدام حاليًا.
تعقيد البراهين المعرفة الصفرية
في UTXO، يجب على المرسل أن يثبت للشبكة أنه لا ينفق مبلغًا سلبيًا، وإلا يصبح من الممكن توليد عملات معدنية جديدة من لا شيء (لماذا هذا ممكن، كتبنا في أحد المواقع السابقة) ). وأيضا قم بتوقيع "المدخلات" بالتوقيع الدائري لإثبات أن من بين العملات التي يتم خلطها هناك أموال تخصه.
في النسخة المجهولة من blockchain القائمة على الحساب، تكون تعبيرات الإثبات أكثر تعقيدًا. يثبت المرسل أن:
- المبلغ المرسل إيجابي.
- ويبقى الرصيد غير سلبي.
- قام المرسل بتشفير مبالغ التحويل بشكل صحيح (بما في ذلك الصفر)؛
- يتغير الرصيد الموجود في الرصيد فقط للمرسل والمستلم؛
- يمتلك المرسل المفتاح الخاص لحسابه وهو موجود بالفعل في قائمة المرسلين (من بين المشاركين)؛
- تم تكوين Nonce المستخدم في المعاملة بشكل صحيح.
لمثل هذا الدليل المعقد، يستخدم المؤلفون خليطًا (بالمناسبة، شارك أحد المؤلفين في إنشائه) و والتي تسمى رصاصات سيجما. يعد الإثبات الرسمي لمثل هذا البيان مهمة صعبة إلى حد ما، كما أنه يحد بشكل كبير من عدد الأشخاص المستعدين لتطبيق هذه التكنولوجيا.
النتيجة؟
في رأينا، يمكن الآن استخدام جزء Zether الذي يوفر الخصوصية لسلاسل الكتل القائمة على الحساب. لكن في الوقت الحالي، تفرض النسخة المجهولة من التكنولوجيا قيودًا خطيرة على استخدامها، وتعقيدًا على تنفيذها. ومع ذلك، لا ينبغي أن نستبعد أن المؤلفين أصدروه قبل بضعة أشهر فقط، وربما يجد شخص آخر حلاً للمشاكل الموجودة اليوم. بعد كل شيء، هذه هي الطريقة التي يتم بها العلم.
المصدر: www.habr.com