لقد كنا مهتمين منذ فترة طويلة بموضوع عدم الكشف عن هويته في العملات المشفرة ومحاولة متابعة تطور التقنيات في هذا المجال. في مقالاتنا ، درسنا بالفعل بالتفصيل مبادئ تشغيل
المعاملات السرية في Monero ، وأجرينا أيضًا
مراجعة مقارنة للتقنيات الموجودة في هذا المجال. ومع ذلك ، فإن جميع العملات المشفرة المجهولة اليوم مبنية على نموذج البيانات المقترح من Bitcoin - مخرجات المعاملات غير المنفقة (المشار إليها فيما يلي بـ UTXO). بالنسبة للحظائر القائمة على الحساب مثل Ethereum ، حاولت الحلول الحالية لتطبيق إخفاء الهوية والخصوصية (على سبيل المثال ،
Mobius أو
Aztec ) تكرار نموذج UTXO في العقود الذكية.
في فبراير 2019 ، مجموعة من الباحثين من جامعة ستانفورد وأبحاث فيزا
صدر عن "بريزيد": نحو الخصوصية في عالم العقود الذكية. اقترح المؤلفون أولاً نهجًا لضمان عدم الكشف عن هويتهم في قيود الحظر القائمة على الحساب وقدموا خيارين لعقد ذكي: للمعاملات السرية (إخفاء الأرصدة ومبالغ التحويل) والمعاملات المجهولة (إخفاء المستلم والمرسل). نجد أن التقنية المقترحة مثيرة للاهتمام ونود أن نشاركها مع الجهاز ، وكذلك نتحدث عن سبب اعتبار مشكلة عدم الكشف عن هويتك في قيود الكتل القائمة على الحساب معقدة للغاية وما إذا كان المؤلفون تمكنوا من حلها بالكامل.
حول الجهاز من هذه النماذج البيانات
في نموذج UTXO ، تتكون المعاملة من "المدخلات" و "المخرجات". التماثل المباشر لـ "المخارج" هو الأوراق النقدية في محفظتك: لكل "منفذ" فئة معينة. عندما تدفع مع شخص ما (شكل معاملة) ، فأنت تنفق "مخرجات" واحدة أو أكثر ، بينما تصبح "مدخلات" للمعاملة ، ويصنفها blockchain بأنها مستهلكة. في الوقت نفسه ، يتلقى متلقي دفعتك (أو نفسك ، إذا كنت بحاجة إلى تغيير) "المخرجات" التي تم إنشاؤها حديثًا. من الناحية التخطيطية ، يمكن تمثيل ذلك على النحو التالي:
يتم هيكلة السلاسل المستندة إلى الحساب مثل حسابك المصرفي. أنها تعمل فقط على المبلغ في حسابك ومبلغ التحويل. عندما تقوم بتحويل مبلغ معين من حسابك ، فلن تحرق أي "مخارج" ، فلا تحتاج الشبكة إلى تذكر العملات التي يتم إنفاقها والتي لا يتم إنفاقها. في أبسط الحالات ، يتم تقليل التحقق من معاملة ما للتحقق من توقيع المرسل والمبلغ في ميزانيته العمومية:
تحليل التكنولوجيا
بعد ذلك ، سنتحدث عن كيفية إخفاء Zether لمقدار المعاملات والمستلم والمرسل. في سياق وصف مبادئ عمله ، سنلاحظ الاختلافات في النسخة السرية والمجهولة. نظرًا لأنه من الأسهل كثيرًا ضمان السرية في قيود المجموعات المستندة إلى الحساب ، فإن بعض القيود المفروضة بواسطة إخفاء الهوية لن تكون ذات صلة بإصدار سري من التكنولوجيا.
إخفاء الأرصدة ومبالغ التحويل
يستخدم Zether نظام التشفير
El Gamal لتشفير الأرصدة ونقل المبالغ. وهي تعمل على النحو التالي. عندما تريد Alice إرسال عملات Bob
b على العنوان (مفتاحه العام)
Y ، تختار رقم عشوائي
r وتشفير المبلغ:
حيث
C هي المجموع المشفر ،
D هي القيمة الإضافية اللازمة لفك تشفير هذا المجموع ،
G هي النقطة الثابتة في المنحنى الإهليلجي ، عند ضرب المفتاح السري الذي يتم به الحصول على المفتاح العمومي.
عندما يتلقى بوب هذه القيم ، فإنه ببساطة يضيفها إلى رصيده ، مشفرًا بنفس الطريقة ، وهو مناسب لهذا المخطط.
وبالمثل ، تقوم Alice بطرح نفس القيم من ميزانيتها ، ولا تستخدم
Y إلا كمفتاح عام لها.
إخفاء المرسل إليه والمرسل
ظهر خلط "المخارج" في UTXO في فجر العملات المشفرة ويساعد على إخفاء المرسل. للقيام بذلك ، يقوم المرسل ، عند إجراء النقل ، بجمع "مخارج" عشوائية في blockchain ويعجنها بمفرده. ثم يوقع على "المخارج" بتوقيع الخاتم - آلية تشفير تسمح له بإقناع المدقق بأنه من بين "المخارج" المعنية هناك عملات معدنية مرسلة. العملات المعدنية المتورطة ، بالطبع ، لا تضيع.
ومع ذلك ، لإخفاء المتلقي ، لن نتمكن من توليد "مخرجات" وهمية. لذلك ، في UTXO ، يكون لكل "مخرج" عنوان فريد خاص به ، ويرتبط بشكل تشفير بعنوان المستلم لهذه العملات. في الوقت الحالي ، لا توجد طريقة لتحديد العلاقة بين عنوان "الخروج" الفريد وعنوان المستلم دون معرفة مفاتيحه السرية.
في نموذج قائم على الحساب ، لا يمكننا استخدام عناوين لمرة واحدة (وإلا فسيكون بالفعل نموذجًا "للمخارج"). لذلك ، يجب أن يعجن المستلم والمرسل بين حسابات أخرى في blockchain. في الوقت نفسه ، يتم خصم العملات المعدنية المشفرة من الحسابات المتعجن (أو تتم إضافة 0 - في حالة عجن المستلم) ، دون تغيير رصيدها الحقيقي فعليًا.
نظرًا لأن المرسل والمستلم لهما دائمًا عنوان دائم ، هنا يصبح من الضروري استخدام نفس المجموعات للخلط إلى نفس العناوين. من الأسهل التفكير في هذا بمثال.
لنفترض أن Alice قررت المساهمة في مؤسسة Bob الخيرية ، لكنها تفضل أن تظل عملية النقل مجهولة بالنسبة للمراقب الخارجي. ثم ، من أجل إخفاء نفسها في مجال المرسل ، تدخل أيضًا في حسابات آدم وأديل. ولإخفاء Bob - في حقل المستلم بالإضافة إلى حسابات Ben و Bill. عند إجراء الدفعة التالية ، قررت أليس إدخال أليكس وأماندا بجانبها ، وبروس وبنجن بجوار بوب. في هذه الحالة ، عند تحليل blockchain في هاتين المعاملتين ، لا يوجد سوى زوج واحد متقاطع من المشاركين - Alice and Bob ، الذي يعيد تحديد هوية هذه المعاملات.
سباق المعاملات
كما ذكرنا من قبل ، من أجل إخفاء رصيده في الأنظمة القائمة على الحساب ، يقوم المستخدم بتشفير رصيده ومبلغ التحويل. علاوة على ذلك ، يجب عليه أن يثبت أن الرصيد في حسابه لا يزال غير سالب. المشكلة هي أنه عند تكوين معاملة ، يقوم المستخدم ببناء دليل بخصوص حالته الحالية للحساب. وماذا يحدث إذا أرسل بوب معاملة إلى Alice ، وسيتم قبولها في وقت أبكر من إرسال Alice؟ عندها ستعتبر معاملة Alice غير صالحة ، لأن إثبات التوازن بني قبل اعتماد المعاملة Bob.
الحل الأول الذي يأتي في مثل هذه الحالة هو تجميد حسابك قبل المعاملة. لكن هذا النهج غير مناسب ، لأنه بالإضافة إلى تعقيد حل مثل هذه المشكلة في نظام موزع ، في نظام مجهول لن يكون من الواضح من سيحجب حسابه.
لحل هذه المشكلة ، تفصل التكنولوجيا عن المعاملات الواردة والصادرة: إن إنفاق الأموال له تأثير فوري على الميزانية العمومية ، ويتم تأجيل الدخل. لهذا ، تم تقديم مفهوم "العصر" - مجموعة من الكتل ذات الحجم الثابت. يتم تحديد "العصر" الحالي عن طريق قسمة ارتفاع الكتلة على حجم المجموعة. معالجة المعاملة ، تقوم الشبكة بتحديث رصيد المرسل على الفور ، وتضيف أموال المستلم إلى محرك الأقراص. تتوفر الأموال المتراكمة للمستفيد فقط عندما يبدأ "عصر" جديد.
نتيجة لذلك ، يمكن للمستخدم إرسال المعاملات بغض النظر عن عدد مرات تلقي الأموال (بقدر ما يسمح رصيده ، بالطبع). يتم تحديد حجم الحقبة بناءً على مدى سرعة انتشار الكتل عبر الشبكة ومدى سريان المعاملة في الكتلة.
يعمل هذا الحل بشكل جيد في حالة عمليات النقل السرية ، ولكن مع المعاملات المجهولة ، كما سنرى لاحقًا ، فإنه يخلق مشاكل خطيرة.
إعادة حماية الهجوم
في عمليات الحظر القائمة على الحساب ، يتم توقيع كل معاملة بواسطة المفتاح الخاص للمرسل ، الأمر الذي يقنع المدقق بأنه لم يتم تغيير المعاملة وتم إنشاؤه بواسطة مالك هذا المفتاح. ولكن ماذا لو اعترض المهاجم الذي كان يستمع إلى قناة الإرسال هذه الرسالة وأرسل نفس الثانية بالضبط؟ سيتحقق المدقق من توقيع المعاملة ويكون مقتنعا بتأليفها ، وستقوم الشبكة بخصم المبلغ نفسه من رصيد المرسل مرة أخرى.
هذا الهجوم يسمى هجوم الإعادة. في نموذج UTXO ، هذه الهجمات ليست ذات صلة ، لأن المهاجم سيحاول استخدام المخرجات المستهلكة ، والتي في حد ذاتها غير صالحة ويتم رفضها من قبل الشبكة.
لمنع حدوث ذلك ، يتم إدخال حقل بيانات عشوائي في المعاملة ، والتي تسمى nonce أو ببساطة "ملح". عند إعادة تقديم المعاملة بالملح ، يتطلع المراجع إلى معرفة ما إذا كان قد تم استخدام هذا العقد من قبل ، وإذا لم يكن كذلك ، يعتبر هذه المعاملة صالحة. من أجل عدم تخزين السجل الكامل للمستخدمين غير المستخدمين على blockchain ، عادة ما يتم اعتباره صفرًا في المعاملة الأولى ، ثم يتم زيادتها بواحد. لا يمكن للشبكة سوى التحقق من أن nonce المعاملة الجديدة يختلف عن الماضي من جانب واحد.
في نظام ترجمة مجهول ، تنشأ مشكلة التحقق من صحة المعاملات غير التقليدية. لا يمكننا ربط عنوان nonce بشكل صريح بعنوان المرسل ، لأنه من الواضح أن هذا يعيد تسمية الترجمة. لا يمكننا أيضًا إضافة حساب إلى حسابات جميع الحسابات المشاركة ، لأن ذلك قد يتعارض مع الترجمات الأخرى التي تتم معالجتها.
يقترح مؤلفو Zether توليد nonce بشكل تشفير - اعتمادًا على "العصر". على سبيل المثال:
هنا
x هو المفتاح السري للمرسل ، و
G epoch هو مولد إضافي للعصر ، تم الحصول عليه عن طريق تجزئة سلسلة من النموذج "Zether +". الآن ، يبدو أن المشكلة يتم حلها - نحن لا نكشف عن غرابة المرسل ولا نتدخل في عدم مشاركة المشاركين غير المشاركين. ولكن هذا النهج يفرض قيودًا شديدة: لا يمكن لأحد الحسابات إرسال أكثر من معاملة واحدة في "العصر". هذه المشكلة ، للأسف ، لا تزال دون حل ، وتقوم حاليًا بعمل نسخة مجهولة من Zether ، في رأينا ، بالكاد مناسبة للاستخدام.
أدلة الثقة الصفرية
في UTXO ، يجب أن يثبت المرسل للشبكة أنه لا ينفق مبلغًا سالبًا ، وإلا يصبح من الممكن إنشاء عملات معدنية جديدة من الجو (لماذا كان ذلك ممكنًا ، فقد كتبنا في إحدى
المقالات السابقة). وقم أيضًا بتوقيع "المدخلات" مع توقيع الخاتم لإثبات أنه من بين العملات المعدنية العجن هناك أموال مملوكة له.
في الإصدار المجهول من blockchain المستند إلى الحساب ، تكون التعبيرات للإثبات أكثر تعقيدًا. يثبت المرسل أن:
- المبلغ المرسلة هو إيجابي.
- يبقى الرصيد غير سالب.
- قام المرسل بتشفير مقدار عمليات النقل بشكل صحيح (بما في ذلك الصفر) ؛
- يتم تغيير الرصيد فقط من قبل المرسل والمستلم ؛
- يمتلك المرسل المفتاح السري من حسابه وهو بالفعل في قائمة المرسلين (بين المشاركين) ؛
- تتكون nonce المستخدمة في المعاملة بشكل صحيح.
لمثل هذا الدليل المعقد ، يستخدم المؤلفون خليطًا من
الرصاص (أحد المشاركين ، بالمناسبة ، شارك في إنشائه)
وبروتوكول Sigma ، والذي يطلق عليه Sigma-bullet. يمثل الإثبات الرسمي لمثل هذا البيان مهمة صعبة إلى حد ما ، وهو يحد بشدة من عدد الأشخاص الذين يرغبون في تنفيذ التكنولوجيا.
ما هي النتيجة؟
في رأينا ، قد يتم استخدام جزء Zether ، الذي يضيف الخصوصية إلى قيود الحظر القائمة على الحساب ، الآن. ولكن في الوقت الحالي ، تفرض نسخة مجهولة من التكنولوجيا قيودًا شديدة على استخدامها وتعقيدها في التنفيذ. ومع ذلك ، لا تنسَ أن المؤلفين أصدروها منذ بضعة أشهر فقط ، وربما سيجد شخص آخر حلاً للمشاكل اليوم. في الواقع ، هذه هي الطريقة التي يتم بها العلم.