تكرار الخصوصية

بواسطة جيك يوكوم بيات في 28 غشت 2019

ميزات وخطط خصوصية ديكريد أصبحت جاهزة ليتم الكشف عنها. الهدف من ميزات الخصوصية لدينا هو أن تكون بسيطة، قابلة للتكيف، ومبتكرة.

بدلاً من اتباع الطرق التي أنشأتها المشاريع التي تركز على الخصوصية، على سبيل المثال، ring signatures و zk-SNARKs أو Mimblewimble، قررنا اتباع نهج شبكة الخلط (mixnet)، شبكة الخلط حيث قمنا بدمج mixnet مع نظام الحوكمة لدينا بستخدام إثبات الحصة (“POS”). فحاليا، تشارك ما يزيد قليلاً عن 50٪ من وحدات ديكريد المتداولة في إثبات الحصة، مما يتطلب تدفقا مستمرا لشراء التذاكر. وهذا التدفق الحالي للمعاملات، والذي تنفرد به ديكريد، يعمل كأساس طبيعي لشبكة الخلط mixnet . بالاستفادة من استخدام نظام حوكمة ديكريد إثبات الحصة، ينتج عنه سيناريو “إصطد العديد من العصافير، بحجر واحد”: حيث يكتسب أصحاب الحصص من ذلك عدم الكشف عن هوياتهم، و يقومون في نفس الوقت بإنشاء حجمًا كبيرًا من التداولات الخلفية التي تمكن لهم ولغير أصحاب الحصص بخلط المعاملات المنتظمة. وفيما يلي ملخص عالي المستوى لـ mixnet الخاص بـديكريد:

في بقية هذه المقالة، سأغطي الدافع وراء القرارات التي اتخذتها للوصول إلى هذا النظام، وعمل النظام بالتفصيل وعن الخطوات التالية التي ستأتي بعد هذا الإصدار الأولي.

الحافز

تم إبقاء عمل الخصوصية طي الكتمان منذ منتصف عام 2017، وهذا يستحق بعض التفسير. فحينها، كنت قد قدمت ملاحظة أن في حين كل من المونيرو و زيكاش توفران الخصوصية الكافية، فقد كان لديهما ما اعتبرته مشكلة خطيرة: لا يمكنهم إسقاط المعاملات التاريخية من العقد الكاملة الخاصة بهم، أي تشذيب، لأنه لا يمكن معرفة ما إذا كان قد تم إنفاق مخرج معاملة (“TXO”) أم لا. وعلى الرغم من أنه من الواضح أن كلا المشروعين إرتأوا بأن هذه ليست مشكلة خطيرة، إلا أنني اعتقدت أن هذه ستكون مشكلة ضخمة من أجل الاستدامة على المدى الطويل. وستعاني البلوكشين للعمل كمخزن للقيمة على المدى الطويل إذا كانت متضخمة جدا بحيث لا يمكن تنزيلها ونسخها بسهولة، مما سيقلل من أمنها. يبدو أن معظم الأشخاص الآخرين في فضاء العملات الرقمية لم يشاركوني هذا الرأي، لذا شعرت أنه من الأفضل حجب انتقاداتي، بدلاً من نشرها على الملأ وإلماح شخص آخر لتطبيق حل لها.

إلى جانب هذا القلق من أن كسر التشذيب كان قرارًا هندسيًا سيئًا على المدى البعيد بحيث يمكن أن يؤثر سلبًا على الاستدامة، على الرغم من كونه جيدًا للخصوصية على المدى القريب، فقد كنت قلقًا بشأن التَعَقُّدِيَّة لكلا النهجين. بحيث تحملring signatures تعقيدًا معتدلًا ولدى zk-SNARK درجة عالية من التَعَقُّدِيَّة، مما جعلني أجد طريقة أكثر بساطة لا تكسر التشذيب.

في البداية ، كنت قد خططت لتنفيذ TumbleBit من ورقة بَحْث “TumbleBit: مركز دفع مجهول غير موثوق به متوافق مع البتكوين” بواسطة Heilman وAlShenibr وBaldimtsi وScafuro وGoldberg. وبين شتاء عام 2017 وربيع عام 2018، كان لدي ميخائيل بيلوبوهوف، مطور لديه خبرة كبيرة في العمل في مشاريع هندسة التشفير، قام بتنفيذ TumbleBit ب Go. وبمجرد اكتمال تنفيذه الأولي، وحان الوقت لدمج الكود، أصبحت أكثر إدراكا لأوجه القصور في TumbleBit، فخادم الخلط معرض لهجمات تعطيل تقديم الخدمة (“DoS”)، و الإجراء المضاد ضد هذا (قسائم رسوم مجهولة المصدر) يعني المزيد من التعليمات البرمجية كما سيتعين إضافة المزيد من التعقيد. وعلى الرغم من عدم دمج كود TumbleBit في ديكريد، فإننا قمنا بإصدار هذا الكود من أجل المنفعة العامة.

في هذه المرحلة ظننت أنه من الأفضل إلقاء نظرة فاحصة على بروتوكول ++CoinShuffle المأخوذ من ورقة بحث “المزج بين النظراء ومعاملات البتكوين غير القابلة للربط” بواسطة Ruffing و Moreno-Sanchez و Kate، والذي وجدته أقل تعقيدا من TumbleBit. بحيث يعتمد ++CoinShuffle على بدائل تشفير أولية، على سبيل المثال مفتاح التبادلات، مفاتيح الجلسة، وظائف الهاش، التوقيعات، وحساب المجال المحدود. بعد إلقاء نظرة فاحصة على ++CoinShuffle، كان واضحا أنه كان أبسط وأكثر مقاومة لتعطيل تقديم الخدمة DoS من TumbleBit، لذا تحولنا وواصلنا بحثنا في ++CoinShuffle. فالكود البسيط والأولويات البسيطة تعني عددًا أقل من الأشياء التي تتعطل أو تفشل. ونظرا للقيود المفروضة على الموارد الهندسية، لم يبدأ هذا العمل حتى دجنبر 2018، وهو الآن جاهز للنشر بعد عدة أشهر من العمل.

لا يعالج ++CoinShuffle سوى عنصر تعقب الخصوصية، دون معالجة مسألة مبالغ المعاملات. ونظرًا لأن ++CoinShuffle لم يتطلب أي تغييرات في خوارزمية الإجماع، فقد كان من الممكن إكمال هذا العمل في سرية. ولا يمكن أن يقال الشيء نفسه عن تقنيات التمويه على مبالغ المعاملات. فمن أجل تمويه مبالغ المعاملات، يجب أن تحدث تغييرات في خوارزميةالإجماع، ويجب أن تحدث تلك التغييرات كجزء من عملية مكشوفة مع ديكريد وفقًا لإرادة أصحاب الحصص.

بنيت ديكريد على مبادئ أمن سلسلة الكتل، والحوكمة المدمجة، ومكافأة التمويل الذاتي التي تجعل منها مخزن متفوق للقيمة.

وبوجود هذه الأسس، فإننا حريصون على بناء سمات الخصوصية التي ستعزز أمن مستخدمينا. على الرغم من أن العملية المكشوفة مطلب لإضافة خاصية التمويه على مبالغ المعاملات، إلا أنني أرى أن مسألة التتبع أمرا أكثر أهمية بكثير عندما يتعلق الأمر بأمن أصحاب الحصص لدينا، الذين سيجنون نتيجة لذلك مكاسب كبيرة في مجال الخصوصية.

كيف تعمل

قامت ديكريد بتنفيذ أحد تنويعات ++CoinShuffle في محفظتها. على الرغم من أنه من الممكن القيام بهذه العملية على نحو كامل بين النظراء (“P2P”)، والتي تتجاهل القيود التي تأتي من التوجيه عبر الإنترنت العام، فقد قمنا بإنشاء خادم، csppserver، ودمجنا العميل في dcrwallet. لإعطاء فهم أعمق لكيفية عمل ++CoinShuffle، سنعمل على مثال بسيط يوضح المفهوم الكامن وراء العملية. فبالإضافة إلى ما يرد وصفه في ورقة البَحْث، يوجد هنالك قيمة اسمية قوية ومناولة تغيير مدمجة في المحفظة، وهي معدة للتعامل مع المعاملات العادية وشراء التذاكر على حد سواء. هناك بعض القيود البارزة لهذا الإصدار الأولي نظرًا لأنه يستخدم عن طريق واجهة سطر الأوامر فقط، ويتطلب إعدادا للتحصيص الفردي أو لا-تحصيص، ويمكن إزالة الاختلاطات من قبل مهاجم يستطيع كسر مشكلة اللوغاريتم المنفصلة (“DLP”). ومن المتوقع أن ما يقرب من 12.5 ٪ من جميع ديكريد المتداولة ستستفيد من الخصوصية في غضون بضعة أشهر. يتطلب إعداد dcrwallet لاستخدام الخصوصية بعضا من تعديل ملف التكوين.

++CoinShuffle

CoinShuffle ++ هي عملية غير مقيدة لإنشاء معاملات CoinJoin، حيث يتم إخفاء عناوين المخرجات من خلال mixnet. تسمى العملية التي يتم بها إخفاء الهوية لعناوين المخرجات DiceMix Light، وهو تكرار من عملية DiceMix ل Ruffing المقترحة أصلاً في ورقة بحث ++CoinShuffle. لاحظ أن CoinJoin التي تحدث تسرب المدخلات و العناوين المتغيرة تنتمي الى أي نظير للخادم ولكن ليس إلى النظراء الآخرين المشاركين في المزيج. فعناوين المخرجات مجهولة بالكامل، بحيث لا أحد من النظراء أو الخادم يمكنه معرفة أي من المخرجات تنتمي إلى النظير. تحدث الخلطات بشكل متقطع في دورات، مع ضبط حقبة الشبكة الرئيسية الأولية على 20 دقيقة (1200 ثانية).

التصميم البنائى

تُعد بنية خادم العميل التي اخترناها طريقة شائعة للبنية الأساسية للشبكة، ويرجع ذلك أساسًا إلى أن ترجمة عنوان الشبكة تعني أنك قد لا تكون قادرًا على الوصول مباشرة إلى نظرائك الآخرين الذين تختلط معهم. هذه مشكلة شائعة جدًا وتتعلق بمسألة إعادة توجيه المنافذ أو ما إذا كان تثقيب فتحة بروتوكول حزم بيانات المستخدم UDP هو نهج مقبول، وهو ما نعتقد أنه يضيف قدرا أكبر من التعقيد. إضافة إلى ذلك، فإن الاستخدام المباشر لنظير إلى نظير يعني أن كل نظير يستطيع أن يري عنوان آي بي العام للنظراء الآخرين، وهذا ليس جيدا للخصوصية. يتطلب الخادم، csppserver، وصول JSON-RPC إلى dcrd، البرنامج الخفي لخوارزمية إجماع ديكريد، للتحقق من أن مخرجات المعاملات TXO لم يتم إنفاقها بالفعل.

سيتم استضافة csppserver الأولي على cspp.decred.org، لكن من الممكن تشغيل الخادم الخاص بك. تشغيل الخادم الخاص بك سيكون له فائدة محدودة لأن الهدف هو الحصول على أكبر عدد ممكن من النظراء في كل مزيج، لذلك نوصي بعدم القيام بذلك. هناك خطط لإتاحة الخادم على نطاق أوسع في المستقبل.

مثال مبسط ل DiceMix

لفهم كيفية عمل بروتوكول DiceMix، من المفيد العمل من خلال خوارزمية مبسطة تسمى المجموع الآمن “Secure Sum”. ويستخدم هذا المثال 3 نظراء، ولكن من السهل توسيع نطاق هذه العملية لتشمل عددا عشوائيًا من النظراء.

افترض أن لكلٍّ من أليس وبوب وكارول رقمًا ويريدون حساب مجموع كل هذه الأرقام، لكن كل منهم يريد تجنب معرفة أي نظير ما هية أرقام النظراء الآخرين. تقسم أليس رقمها إلى A1+A2+A3، ويقسم بوب رقمه إلى B1+B2+B3، بينما تقسم كارول رقمها إلى C1+C2+C3. ثم ترسل أليس A2 إلى بوب و A3 إلى كارول، و بوب يرسل B1 إلى أليس و B3 إلى كارول، و كارول ترسل C1 إلى أليس و C2 إلى بوب. أليس تحسب A1+B1+C1, بوب يحسب A2+B2+C2, كارول تحسب A3 + B3 + C3، ثم يذيعون جميع المبالغ الجزئية الخاصة بهم إلى النظراء الآخرين. يمكن لكل منهم الآن حساب مجموع جميع الأرقام عن طريق إضافة المبالغ الجزئية، ولا يعرف أي نظير ما هو رقم النظير الآخر، على افتراض أنه لا يوجد تواطؤ.

الحيلة المستخدمة في المثال أعلاه هي أن مجموع المبالغ الأفقية يساوي مجموع المبالغ العمودية، وهو واضح إذا قمت بكتابة الأجزاء:

مع DiceMix، يتم إضافة تعقيد إضافي، ولكن يبقى المفهوم الأساسي كما هو. بحيث ينطوي على أن كل نظير يقوم بإنشاء متجهة أسية لعنوان الدفع الخاص به، وإضافة مصطلحات التغطية إلى كل متجهة تستند إلى المفاتيح الزوجية للجلسة من عملية التبادل الرئيسية، وتلخيص هذه المتجهات من كل نظير لإنشاء نظام من المعادلات، و وبعد ذلك حل نظام المعادلات لعناوين الدفع. الحيلة هنا هي أنه قد تم إختيار شروط التغطية لتلغى بحيث يتم جمعها عبر جيمع متجهات النظراء. وبمجرد أن نتوفر على قائمة مجهولة الهوية لعناوين الدفع، يحدث إجراء قياسي ل CoinJoin مع النظراء.

قيم العملة و التعامل مع التغييرات

يقوم DiceMix بإخفاء هوية عناوين المخرجات لمعاملة CoinJoin، ولكنه لا يجعل المخرجات غير قابلة للتمييز. فلجعل المخرجات غير قابلة للتمييز، يجب أن يكون لها فئة ثابتة لكل مزيج. وقد تمت الإشارة إلى الحاجة إلى المخرجات الثابتة لقيمة العملة في الورقة البيضاء ل CryptoNote في عام 2012، وبالتالي فإن الحاجة إلى كميات مخرجات متطابقة للحفاظ على الخصوصية من الأمور المعروفة جيداً. قيمة العملة المستخدمة في ديكريد هي سعر التذكرة الحالي (بالإضافة إلى رسم) والعديد من قيم العملة الثابتة التي تقل عن سعر التذكرة. يتغير سعر التذكرة كل 144 كتلة، أي كل 12 ساعة تقريبًا، لذلك تتغير قيمة العملة بمرور الوقت. إذا تغير سعر التذاكر خلال فترة زمنية ما، يلغى المزيج ويشترك النظراء في المزيج التالي.

كما هو معتاد في عالم التشفير والخصوصية، فإن “الشيطان يكمن في التفاصيل”، والتغيير من خلائط ++CoinShuffle ليس مستثنى من هذه القاعدة. بحيث تقوم ++CoinShuffle بعمل جيد في إخفاء عناوين المخرجات، ولكن إذا لم يتم التعامل مع التغيير بعناية، فإنها يمكن أن تربط مخرجات المعاملات المختلطة وغير المنفقة. وفي كثير من الحالات، يمكن ربط مخرجات التغيير بمدخلاتها بإجراء تحليل جزئي للمبلغ الإجمالي، على سبيل المثال مجموعة فرعية من المدخلات تبلغ 12.34، ونواتج مجهولة تبلغ 10، ورسم قدره 0.001، وتغيير قدره 2.339. هذا يعني أنه إذا تم تضمين التغيير في 2.339 كمدخل مع مخرجات مجهولة المصدر، فإنه ينشئ رابطًا بين المدخلات التي تصل إلى 12.34 وتلك المخرجات مجهولة المصدر، مما يقلل أو يزيل الخصوصية التي عملنا على إنشائها بالكامل. للتعامل مع هذا التهديد، تغيير يحدث لمزج التدفقات إلى حساب محفظة منفصل، حيث يتم خلطها إلى قيم عملات أصغر حتى يصبح التغيير أقل من أصغر قيمة عملة ممزوجة.

وقد اختيرت قيمة العملة الثابتة لموازنة متوسط حجم تخزين المعاملات على السلسلة، ونوعية المزيج، وسهولة تنفيذ عمليات الضرب. فإذا افترضنا أن قيمة العملة تستخدم الأساس N وهناك قيمة العملة M، ففي أسوأ الحالات، ستكون هناك مخرجات N-1 من قيمة عملة معينة، والمخرجات الإجمالية (1-N) × M من إدخال تغيير واحد. بالنسبة للقاعدة 10، هذا يعني أن مقدار التغيير البالغ 99.999 سيتطلب ما يصل إلى 5 × (10 - 1) = 45 مخرجا مختلطًا، لذلك يمكنك توقع زيادة تقريبية ب 22x في تخزين المعاملات على السلسلة. لقد اخترنا العمل في قاعدة 4، مع 8 فئات أقل من حجم التذكرة، لذلك فإن تغيير الحالة الأسوأ سيتطلب 8 × (4 - 1) = 24 مخرجا، مما يؤدي إلى زيادة 12x تقريبًا في التخزين على السلسلة. تم تضمين فئتين إضافيتين أعلى من سعر التذكرة، لكننا نتوقع أن تحصل على استخدام محدود. وأصغر فئة هي 4^9 ذرات = 0.00262144 والنوع الذي يقل عن حجم التذاكر الحالي هو 4^16 ذرات = 42.94967296.

القيود

يدعم هذا الكود الأولي فقط لمحفظة واجهة سطر الأوامر و dcrwallet و المحصصين المنفردين، أي أنه لا يعمل مع مقدمي خدمات التصويت (“VSP”)، والمعاملات العادية. ومن الواضح أننا حريصون على تقديم الدعم للخصوصية لمحافظ واجهة المستخدم الرسومية، على سبيل المثال ديكريديتون، وجعلها تعمل مع مقدمي خدمات التصويت. التحدي الذي يواجه محافظ واجهة المستخدم الرسومية هو تجربة المستخدم (“UX”) لأن عملية الخلط بين المدفوعات المستلمة حديثا أو التغيير تتطلب فتح المحفظة لفترات زمنية أطول، مثلا 10 دقائق. ويخلق مقدمو خدمات التصويت تحديا أكبر لأنهم لديهم فكرة عن هوية المستخدمين عندما يسجلون حسابا لدى إحدى مقدمي خدمات التصويت ولكل حساب نص محدد متعدد التوقيعات من 1 إلى 2. وفي حال تمكن مهاجم من كسر مشكلة اللوغاريتم المنفصلة DLP وسجل بصورة سلبية جميع الاتصالات بين عملاء المزيج والخادم، يمكنهم الكشف عن الصلة بين المدخلات والمخرجات والتغيير. لاحظ أنه لا يوجد خطر من أن هذا المهاجم سيسبب تضخما صامتا.

التوقعات

من الجوانب الهامة لأي سمة من سمات الخصوصية ما يمكن للمستخدمين أن يتوقعوا الإستفادة منه، ولا سيما في سياق اختيار الخصوصية. وفقًا لسعر التذكرة الحالي البالغ DCR 128 تقريبًا، تتطلب الحالة المستقرة لشراء التذاكر أن ينفق أصحاب الحصص لدينا تذاكر بقيمة 128 × 5 DCR لكل كتلة × 288 كتلة في اليوم = 184,320 DCR في اليوم. يتم تداول حاليا ما يقارب 10,282,000 DCR، و بالتالي فإن الحالة المستقلة للشراء تمثل حوالي 1.8% من إجمالي الإصدار الذي يتم استخدامه لشراء التذاكر كل يوم. يتم التحصيص الفردي لما يقارب 50 ٪ من جميع التذاكر، ويقدر أن 50٪ من التحصيص الفردي سيستفيد من الخصوصية، وحوالي 50٪ من مجموع ديكريد يتم تحصيصه، وهذا يعني أن نسبة تقديرية ب 12.5% من مجموع ديكريد ستستخدم الخصوصية عبر هذا الإصدار الأولي للخصوصية. ومن المرجح أن تستغرق المشاركة بضعة أشهر للوصول إلى هذا المستوى لأن التذاكر تستدعى للتصويت ببطء بمرور الوقت، ويمكن فقط للتذاكر الجديدة الاشتراك في استخدام الخصوصية.

يمكن لكل من أصحاب الحصص وغير أصحاب الحصص استخدام نظام الخصوصية والثقة في مزج التدفق المستمر للمعاملات لأننا قمنا بدمج هذه المعاملات مع التدفق المستمر لشراء التذاكر من نظام حوكمتنا. وحسب النظام الموصوف أعلاه، سيتمكن المستخدمون الذين يختارون الخصوصية من تلقي المدفوعات وإنفاقها مع إمكانية إخلاء المسؤولية المعقولة، ولن تتحسن الوضعية إلا بتحسين المعاملة غير المنفقة وزيادة مستوى المشاركة. سيكون بإمكان المراقبين الخارجيين الغير فعالين رؤية مجموعات من مخرجات المعاملات غير المنفقة المختلطة التي تم إنفاقها، لكنهم لن يتمكنوا من ربط تلك المعاملات بالهوية.

إعدادات

مع كل هذا الحديث عن كيفية عمل الخصوصية، فبعض القراء بالتأكيد متحمسون لإعدادها و تشغيلها. يجب تعيين العديد من الخيارات الجديدة في dcrwallet.conf:

بالإضافة إلى إعداد هذه الخيارات الجديدة في dcrwallet.conf، يجب إنشاء حسابين جديدين: مختلط وغير مختلط. يمكن إنشاء حساب التصويت محليًا، إذا صوتت محفظة شراء التذاكر ticketbuyer الخاصة بك أيضًا، أو يمكنك استيراد مفتاح عام pubkey لحساب التصويت من محفظة تصويت خارجية.

سيرغب أصحاب الحصص الذين يديرون مشتر التذاكر ticketbuyer في إعداد مشتر تذاكر ثان الذي سيتم تشغيله بشكل متوازٍ، حيث تم وضع الإعدادات كالتالي: التذاكر المشتراة حديثا في المحفظة الأولى لها حساب مختلط في المحفظة الثانية فرع 0 يتم تعيينها ك mixedaccount. وقد يتطلب الأمر عددا كبيرا من أصحاب الحصص حتى انتهاء صلاحية التذكرة الكاملة التي تبلغ 4.7 أشهر تقريبًا للانتقال بالكامل إلى المحفظة المختلطة الجديدة. ويمكن لغير أصحاب الحصص تعيين هذه الخيارات، مع ترك حساب الشراء purchaseaccount، والمشاركة في الخلط دون شراء تذاكر. لتلقي المدفوعات، قم بإنشاء عناوين جديدة من الحساب غير المختلط، ثم سيتم خلط هذه المدفوعات في الحساب المختلط.

لاحظ أن عملية الخلط تتطلب إلغاء قفل المحفظة لفترات زمنية أطول، حتى تتمكن من المشاركة في عملية المزج، و التي تحدث كل 20 دقيقة. يتم تشغيل محافظ Ticketbuyer وهي مفتوحة، لكن سيتعين ترك المحافظ التي لا تستعمل التحصيص مفتوحة لفترة طويلة بما يكفي لإكمال مزجها.

الأعمال المستقبلية

هناك قدر كبير من العمل الإضافي الذي يتعين القيام به لتحسين الخصوصية، سواء من حيث تحسين الإصدار الأولي للخصوصية أو تحسين تجربة المستخدم لمحافظ واجهة المستخدم الرسومية، على سبيل المثال ديكريديتون، تتطلب الإدماج في كل من مكونات واجهة المستخدم الرسومية و dcrwallet. كما تتطلب إعادة تجهيز مقدمي خدمة التصويت ليكونوا متوافقين مع الخصوصية بالانتقال من نظام قائم على الحساب إلى نظام قائم على التذاكر، وهذا يستوجب تعديل كل من dcrstakepool و dcrwallet. يعتمد هذا الإصدار الأولي على تجهيز خادم واحد، لكننا يمكن أن نستبدل هذا الخادم المفرد إما بمجموعة أو بمزيج ميمبول في dcrd. بعد رؤية التعقيد الذي ينشأ عن معالجة التغيير، فإن إضافة دعم المعاملة السرية (“CT”) سيكون خطوة طبيعية تالية، تستلزم تغييرًا في خوارزمية الإجماع. ونظرًا لعدم حدوث عملية الخلط على السلسلة، فمن الممكن تعديل DiceMix لدعم تشفير ما بعد الكم (“PQ”)، مما يجعل الخلط آمنًا ضد المهاجم الذي يمكن أن يكسر مشكلة لوغاريتم منفصلة (“DLP”).

إدماج محفظة واجهة المستخدم الرسومية

كما ذكر أعلاه، هناك بعض التغييرات التي يجب إجراؤها على dcrwallet بحيث تكون المعاملة غير المنفقة المتمثلة في الاختلاط مع ديكريديتون مقبولة. المشكلة هنا هي أن فترة زمنية مدتها 20 دقيقة تتطلب محفظة خلط لتكون جاهزة للتوقيع على معاملة CoinJoin لمدة لا تقل عن هذا الوقت. الخيار البسيط هنا هو ترك المحفظة بأكملها مفتوحة لفترة طويلة، لكن هذه ممارسة أمنية سيئة. مع بعض العمل، من الممكن جعل dcrwallet تفتح حساب واحد فقط في كل مرة، على سبيل المثال الحساب غير المختلط، وإجراء جميع المكالمات عن بعد إلى المحفظة التي تتضمن التوقيع و تتطلب عبارة المرور. بمجرد إجراء هذه التغييرات، يجب أن يكون دمج دعم الخصوصية في ديكريديتون بسيطًا.

تغييرات مقدمي خدمات التصويت

يعمل مزودو خدمات التصويت حاليًا على كل حساب على حدة، فعلى سبيل المثال لديك تسجيل دخول، وعنوان واحد من 2 ثابت لهذا الحساب، ومجموعة واحدة من تفضيلات التصويت، ولكن لدعم الخصوصية بشكل صحيح، يجب أن يعمل مقدمو خدمات التصويت على كل تذكرة على حدة. يستدعي هذا من المستخدمين إرسال مفتاح فردي خاص لكل تذكرة إلى مزود خدمة التصويت، ودفع رسوم مقدم خدمة التصويت عن طريق الدفع المباشر، وتفضيلات التذاكر المحددة على أساس كل تذكرة على حدى. بالإضافة إلى ذلك، سيكون من المثالي أن يتم تفويض التذاكر لمقدمي خدمات التصويت عبر تور أو ما شابه ذلك. يقتضي هذا تغييرات على كل من dcrwallet و dcrstakepool. ونظرًا لأن حوالي 50٪ من التذاكر يحتفظ بها مقدمو خدمات التصويت، فهذا يعني مضاعفة تقريبية لاستخدام الخصوصية، من 12.5٪ إلى 25٪ من ديكريد المتداولة.

خلاط خادم التجميع

من السهل تشغيل خادم خلط واحد، ولكنه ليس إعدادا مرنا على وجه الخصوص، حتى وإن كان كافيا للتعامل مع حجم كبير من المعاملات. قد يكون الإعداد الأطول أجلا و الأكثر مرونة هو تجميع متوافر بدرجة عالية، أو حتى دمج الخادم في dcrd، مما يؤدي إلى إنشاء ذاكرة خلط. وقد تكون هناك أسباب لعدم إدماج ذلك في dcrd، ولذلك يلزم إجراء مزيد من التحقيق هنا.

المعاملات السرية

يعتبر التعقيد وزيادة تخزين المعاملات على السلسلة اللازمة لمعالجة التغيير على نحو سليم باستخدام عملة ++CoinShuffle حافزا جيدا للنظر في إضافة التمويه على مبالغ المعاملات. تتسبب كميات التمويه في إبطال تحليل المجموع الجزئي بأكمله والخلط القائم على أساس قيمة العملة. يؤدي ذلك إلى معاملة خلط واحدة لكل حقبة، بدلاً من عدة معاملات خلط منفصلة من قيم عملات مختلفة. وبشكل ملائم، هناك ورقة بحث “مزج المعاملات السرية: خصوصية المعاملات الشاملة للبتكوين” بواسطة Ruffing و Moreno-Sanchez، والتي تغطي بالضبط هذا التحسن. و إذا ما تم إستخدام Bulletproofs (“BPs”)، فإن حجم المعاملات التي تستخدم معاملات سرية من شأنها أن تقلل على الأرجح من متطلبات تخزين المعاملات على السلسلة.

أحد الشواغل الصحيحة المتعلقة بالمعاملات السرية هو أن المهاجم الذي يمكنه كسر مشكلة اللوغاريتم المنفصلة يمكن أن يخلق تضخمًا صامتًا، وهو ما سيكون كارثيا على نظام حوكمة إثبات الحصة الصادر عن ديكريد و قدرتها على أن تكون بمثابة مخزن للقيمة. في حين أن هناك حجج صحيحة تستند إلى معلومات عامة تفيد بأن الكمبيوتر الكمي الذي يعمل على نطاق واسع لا يزال على بعد سنوات عديدة، إلا أن هناك حافزًا كبيرًا لحكومات الدول القومية الأكبر لتطوير هذه التكنولوجيا في السر واستخدامها لفك تشفير مجموعة واسعة من البيانات المشفرة. يقترح مؤلفو BPs في القسم 4.9 أنه من الممكن تنفيذ BPs المخفية حسابيًا والملزمة تمامًا، بدلاً من BPs المخفية تمامًا والملزمة حسابيًا. سنحقق في هذا الخيار لأن وضع الفشل في التضخم الصامت سيضر بشدة بديكريد.

تشفير ما بعد الكم

أحد الفوائد الرئيسية لـ ++CoinShuffle وبروتوكول DiceMix المقترن به هو أنه يمكن تعديله لدعم تشفير ما بعد الكم، مما يجعل عملية الخلط آمنة ضد المهاجمين الذين يمكنهم كسر مشكلة لوغاريتم منفصلة DLP. يتطلب DiceMix من النظراء المشاركين إجراء تبادل للمفاتيح الزوجية، والذي يقترحون القيام به كتبادل مفتاح غير تفاعلي بغرض البساطة لأن تبادل المفاتيح التفاعلي سيخلق جولات إضافية من الاتصالات. وبإضافة جولة إضافية من الاتصالات، من الممكن استخدام تشفير ما بعد الكم لتأمين عملية تبادل المفاتيح. لدى الشركة 0 تطبيق حالي لأحد أفضل أنظمة التشفير بعد الكم الموجودة، Streamlined NTRU Prime 4591 ^ 761 ، استنادًا إلى عمل Bernstein و Chuengsatiansup و Lange و van Vredendaal، لذلك سيكون هذا اختيارًا طبيعيًا لمثل هذا التطبيق. ونظرًا لأن عملية الخلط تحدث خارج السلسلة، فإن اعتبارات حجم المعاملة المعتادة لاستخدام تشفير ما بعد الكم ليست ذات صلة، فعلى سبيل المثال، غالبًا ما يكون حجم المفاتيح العمومية المنشورة بعد 1 كيلو بايت أو أكبر. لاحظ أن هذا لن يمنع المهاجم الذي يمكن أن يكسر مشكلة اللوغاريتم المنفصلة من سرقة الأموال حيث تم الكشف عن المفتاح العمومي، ولكنه سيمنعهم من إلغاء المزج بطريقة سلبية لسلب الخصوصية.

##,خاتمة

من الجيد أن نجعل هذا العمل علنيا وأن نوفر إصدار أولي من الخصوصية لأصحاب الحصص بطريقة يمكن أن تعود بالنفع على جميع مستخدمي ديكريد.تتوفر هذه الميزات كطلب سحب ل dcrwallet على GitHub، ونحن نشجع المستخدمين التقنيين على اختبار هذاالكود معنا.لقد تلقى هذا الكود اختبارات كبيرة على الشبكة التجريبية طوال عملية تطويره، لذلك يجب أن يكون ثابتًا بالفعل.بعد إجراء بعض الاختبارات الإضافية، سيصبح هذا الكود جزءًا من الفرع الرئيسي وسيتم تضمينه في الإصدار التالي، 1.5.0.نحن نبحث دائمًا عن المطورين الموهوبين، لذا إذا كانت هذه الخصوصية تهمك، شاركنا في الدردشة وأعلمنا بذلك.

في حين أن العمل المنجز بالفعل موضوعي، لا يزال هناك الكثير مما يجب عمله. لقد سعينا إلى الحفاظ على كود الخصوصية بسيطًا، سواء من حيث بدائل التشفير أو قيوده الضمنية على بلوكشين ديكريد.ستستمر ديكريد في التكرار والتكيف مع تغير بيئة الخصوصية المتغير من حولنا، مع دمج ميزات جديدة حسب الضرورة، وفقًا لإرادة أصحاب الحصص، للتعامل مع التهديدات عند ظهورها. وكما هو الحال دائمًا، نحن نسعى جاهدين لتحقيق أقصى قدر من الأمان من البلوكشين لدينا ومستخدميها، وسنفعل ذلك بشكل مستدام، لجعل ديكريد مخزنًا عالي القيمة على المدى الطويل.

تمشيا مع مقالة الخصوصية السابقة، أضفنا الآن ديكريد إلى الرسم البياني أدناه.

رابط النص الأصلي: Iterating Privacy

تمت الترجمة إلى اللغة العربية بواسطة: arij@، قام بالمراجعة abdulrahman4@.