الوجبات السريعة الرئيسية
في نوفمبر 2022، أصدرت Binance نظام إثبات الاحتياطيات الخاص بها باستخدام تشفير شجرة Merkle للسماح للمستخدمين بالتحقق من ممتلكاتهم.
قامت Binance الآن بتحسين حلها من خلال تطبيق zk-SNARKs، وهو شكل من أشكال إثبات المعرفة الصفرية.
يمكن للمستخدمين الآن التحقق من أن إجمالي صافي الرصيد لكل حساب ليس سالبًا وأن جميع أصول المستخدم هي جزء من إجمالي صافي رصيد أصول المستخدم الذي تطالب به Binance - بطريقة خاصة وآمنة.
ألق نظرة على حل Binance الجديد لإثبات الاحتياطيات. من خلال الجمع بين معلومات zk-SNARKs وشجرة Merkle، فإنه يمنح المستخدمين طريقة جديدة ومحسنة للتحقق من حالة احتياطيات Binance.
على مدى الأشهر القليلة الماضية، كان فريق مطوري بينانس يعمل بجد على بناء حلول متقدمة لإثبات الملاءة. أصبحت هذه الأدوات ضرورية لأسواق تبادل العملات الرقمية المركزية في ظل أزمة الثقة التي اجتاحت الصناعة بعد انهيار FTX. إن أموال المستخدمين المخزنة لدى بينانس مدعومة بنسبة 1:1، بالإضافة إلى الاحتياطيات، وأصبح إيجاد طريقة لإثبات ذلك للعامة بسلاسة جزءًا كبيرًا من خطة بينانس لاستعادة ثقة الصناعة.
في نوفمبر 2022، أطلقنا نظام إثباتات الاحتياطيات لدينا باستخدام تقنية تشفير تعتمد على شجرة ميركل للسماح للمستخدمين بالتحقق من ممتلكاتهم لدى بينانس. وعلى الرغم من كون هذا تقدمًا في دفع بينانس نحو شفافية أموال المستخدمين، فقد كان للتصميم الأول لهذا الحل عيبان:
للحفاظ على خصوصية المستخدمين، كانت العقد الورقية في إثبات ميركل تمثل تجزئة ممتلكات المستخدمين—وبالتالي لم يكن بإمكان جذر شجرة ميركل أن يعكس مجموع معلومات الأرصدة الخاصة بعقده الورقية.
قد تتمكن الجهة التي يجري التحقق من احتياطياتها من إضافة رصيد سالب ضمن حساب وهمي في مكان ما داخل الشجرة، بهدف جعل إجمالي الاحتياطيات المطلوبة يبدو أصغر. تُظهر المخطط التالي من مدونة فيتاليك بوتيرين مثالًا على شجرة ميركل خبيثة من هذا النوع (رغم أنه في هذه الحالة، يعكس الجذر مجموع الأرصدة لجميع العقد الورقية، ما قد يُدخل مشكلات خصوصية).
لدينا الآن حل يمكنه معالجة هذه العيوب وبالتالي تعزيز نظام إثباتات الاحتياطيات لدى بينانس. بالاعتماد على بروتوكولات إثبات المعرفة الصفرية، يمكننا عبر zk-SNARK أن نثبت أن:
جميع العقد الورقية في شجرة ميركل ساهمت في إجمالي رصيد المستخدم الذي تدّعيه بينانس لكل أصل.
لا يوجد مستخدم بإجمالي رصيد صافي سالب (وهو قيمة إجمالية بالدولار لجميع الأصول التي يمتلكها المستخدم) مدرج ضمن شجرة ميركل.
كلمة حول الأرصدة السالبة والأداء
نظرًا لأن بينانس توفر منتجات مثل الهامش والقروض المشفرة وتداول العقود الآجلة، فقد يتكون رصيد كل مستخدم لكل أصل تشفير من أصول وخصوم. يمكن أن يكون رصيد المستخدم لأصل تشفير معيّن سالبًا، لكن إجمالي رصيده الصافي عبر جميع الأصول المشفرة يجب ألا يكون سالبًا (لأن جميع القروض مدعومة بالكامل بضمانات).
في هذا السيناريو الافتراضي، لنفترض أن أليس أودعت 10,000 BUSD لدى بينانس، ثم استخدمت 4,000 BUSD كضمان للاقتراض بمقدار 2 BNB (بسعر 1 BNB = 1,000 BUSD، مع افتراض أن بينانس تقوم دائمًا بالإفراط في الضمان). يوضح الجدول التالي ميزان أليس (قائمة المركز المالي).
BNB (السعر: 1000 BUSD) | BUSD (السعر: 1 BUSD) | إجمالي الرصيد الصافي (BUSD) | |||
الأصول | الخصوم | الأصول | الخصوم | ||
أليس | 2 | 2 | 10000 | 0 | 10000 |
إذا كانت أليس ستقوم بتبادل 1 BNB مقابل 1,000 BUSD مع بوب (وكان قد أودع أيضًا 10,000 BUSD)، فسيبدو ميزانها (قائمة المركز المالي) كالتالي بعد تنفيذ الصفقة وتمت مطابقتها:
BNB (السعر: 1000 BUSD) | BUSD (السعر: 1 BUSD) | إجمالي الرصيد الصافي (BUSD) | |||
الأصول | الخصوم | الأصول | الخصوم | ||
أليس | 1 | 2 | 11000 | 0 | 10000 |
بوب | 1 | 0 | 9000 | 0 | 10000 |
في هذه الحالة، ستكون حصة أليس من BNB بقيمة -1، وهو ليس عقدة صالحة في شجرة ميركل ولا يغطي إلا أصلًا واحدًا: BNB. ومع ذلك، إذا كنا ننظر إلى إجماليات الأرصدة الصافية، فإن أليس ما زالت عند 10,000.
تتمثل تحديات أخرى في الحجم الهائل لقاعدة مستخدمي بينانس. يجب أن يتيح حلٌّ قابل للتطبيق توليد إثبات المستخدم وإثبات zk-SNARK لعشرات الملايين من المستخدمين، وقد يحمل بعضهم أكثر من 300 أصل تشفير في منصتنا.
بشكل عام، نريد تقديم الإثباتات الخاصة بالحقائق التالية ضمن إطار زمني معقول:
تُعد أصول كل مستخدم من مستخدمي بينانس جزءًا من إجمالي رصيد المستخدم الذي نقوم بادعائه والمُشار إليه في اللقطة (snapshot). يمكن للمستخدمين التحقق من إجمالي رصيد المستخدم الذي ندّعيه مقابل الأصول الموجودة في العناوين التي تتحكم بها بينانس باستخدام مستكشف بلوكتشين (مثل Etherscan لمحافظ Ethereum أو BscScan لمحافظ BNB Chain).
يجب أن يكون إجمالي الرصيد الصافي لكل مستخدم غير سالب، ما يعني أن بينانس لم تُنشئ حسابات وهمية بأرصدة سالبة لتقليل حجم احتياطياتنا المُتحقق منها بشكل مصطنع.
ما هي zk-SNARKs؟
قبل أن نتعمق في تفاصيل حلّنا، يلزم تقديم نظرة عامة سريعة عن آلية إثبات المعرفة الصفرية. تتيح بروتوكولات المعرفة الصفرية مثل zk-SNARK لطرفٍ واحد (مقدّم الإثبات) أن يثبت لطرفٍ آخر (المدقق) أنه نفّذ حسابات معيّنة بدقة باستخدام مدخلات معيّنة ضمن قيود معيّنة، دون الكشف عن المدخلات. قد تكون عملية الحساب نفسها تستغرق وقتًا، لكن الآلية الرياضية الكامنة يمكن أن تساعد المدقق على التحقق من الإثبات بسرعة وأمان.
يبدأ مقدّم الإثبات (Binance) بتحديد مجموعة من القيود الخاصة بالحساب الذي يريد إثباته. تُعرَّف هذه القيود داخل دوائر (circuits) يمكن التعبير عنها بلغة برمجة عالية المستوى (وفي حالتنا، نسخة معدلة ومتشعبة من gnark.)
بعد ذلك ينفّذ مقدّم الإثبات الحساب المكثف، ويقوم بتجزئة (hashing) جميع معرفات المستخدمين وقوائم مراكزهم المالية، وينشئ إثباتًا يطابق القيود المحددة مسبقًا. وللقيام بذلك، يستخدم أثر الحساب (witness) وكذلك مدخلات عامة أو خاصة.
يحصل المدقق (المستخدم) على الإثبات ويتحقق منه باستخدام المدخل العام للدائرة (circuit)، ليتأكد من أن الحساب تم تنفيذه بدقة وأن جميع القيود قد تمت تلبيتها. تستغرق عملية التحقق وقتًا قصيرًا جدًا مقارنةً بوقت إنشاء الإثبات. إذا لم يُنشئ مقدّم الإثبات الإثبات ضمن الدوائر المحددة مسبقًا، فلن يستطيع إنتاج إثبات صالح لتمرير عملية التحقق.
لإلقاء نظرة أعمق تحت غطاء zk-SNARKs، يمكنك الرجوع إلى سلسلة المقالات هذه.
حلّنا
يظل المكوّن الأساسي لبناء حل إثباتات الاحتياطيات المحدث هو شجرة ميركل. وبالنسبة للمثال أعلاه، سيبدو الأمر كما يلي:
بالإضافة إلى شجرة ميركل، نحتفظ أيضًا بحالة عالمية تمثل قائمة إجماليات الأرصدة الصافية لكل أصل يحتفظ به كل عميل من عملاء بينانس.
لإثبات احتياطياتنا، سننشئ إثبات zk-SNARK لبناء شجرة ميركل. وبالنسبة لمجموعة رصيد كل مستخدم – وهي عقدة ورقية (leaf node) في شجرة ميركل – ستضمن دائرتنا (circuit) ما يلي:
يتم تضمين رصيد كل أصل لهذا المستخدم ضمن القائمة الخاصة بالحالة العالمية المذكورة أعلاه.
يجب ألا يكون إجمالي الرصيد الصافي للمستخدم سالبًا.
يجب أن يكون التغير في جذر شجرة ميركل صالحًا بعد تحديث معلومات هذا المستخدم في تجزئة عقدته الورقية.
يرجى الرجوع إلى هذا الوصف الفني التفصيلي وكود المصدر الخاص بنا للدائرة (القيود) للحصول على تفاصيل التنفيذ.
في كل مرة نقوم فيها بإثبات احتياطياتنا، سننشر:
1. إثبات ميركل: التجزئات الخاصة بكل مستخدم (بالنسبة لأليس، يتم تمثيلها بالعقد الزرقاء في الصورة أعلاه).
2. إثباتات zk-SNARK والمدخلات العامة (وهي تجزئة لقائمة إجماليات الأرصدة الصافية لكل أصل وجذر ميركل) الخاصة بالدائرة لجميع المستخدمين.
من خلال التحقق من إثبات ميركل، يمكن للمستخدمين التأكد من أن كشف حسابهم (ميزانهم) مدرج ضمن جذر شجرة ميركل. ومن خلال التحقق من إثبات zk-SNARK، يمكن للمستخدمين التأكد من أن بناء شجرة ميركل يلتزم بالقيود المحددة في الدائرة.
تعتمد أمان هذه الحل بشكل كبير على إعداد مفتاح الإثبات ومفتاح التحقق. نحن نعمل على إعداد لا مركزي للمفاتيح. وعند الحديث عن دورات الإعداد المعتمدة (trusted setup) اللامركزية القائمة، تُعدّ مراسم Ethereum مثالًا مناسبًا. نحن قريبون جدًا من امتلاك حل قائم على MPC يجعل الإعداد بلا ثقة (trustless).
الأداء
نظرًا لعدد مستخدمي بينانس الذين يجب تضمين أرصدتهم ضمن الإثبات، لا توجد طريقة للحصول على إثبات واحد لبناء شجرة ميركل يغطي جميع المستخدمين مرة واحدة. تتمثل إحدى الحلول في تقسيم المستخدمين إلى مجموعات (batches) مكونة من 864 مستخدمًا لكل مجموعة، بحيث تكون الدائرة أصغر نطاقًا وإجراءات إنشاء الإثبات يمكن تنفيذها بالتوازي.
بالنسبة لمجموعة تحتوي 864 مستخدمًا، حيث يملك كل مستخدم 350 أصلًا مختلفًا، وعلينا أن نفترض أن رصيد كل أصل ضمن النطاق [0, 2^64-1]. باستخدام خادم 32 نواة وذاكرة 128GB، تبلغ مدة إنشاء إثبات zk حوالي 110 ثوانٍ، وتبلغ مدة التحقق من الإثبات أقل من 1 ميلي ثانية.
ستبدأ بينانس 1000 منشئ إثبات (provers) في نفس الوقت من أجل توليد الإثبات لجميع الحسابات خلال ساعتين. تبلغ تكلفة خادم منشئ الإثبات لمدة ساعة واحدة حوالي 0.56 دولار أمريكي، لذا ستكون التكلفة الإجمالية لتوليد جميع إثباتات zk التي تغطي جميع المستخدمين حوالي 1000 دولار أمريكي.
الخلاصة
سنوفّر النسخة الأولى من إثبات المستخدمين الناتجة عن هذا الحل الجديد في إعلان لاحق عن إثباتات الاحتياطيات. كما أننا قمنا بإتاحة معالج بيانات المستخدمين ومولّد الإثبات (prover) والدائرة (circuit) والمدقق (verifier) كمصدر مفتوح، بحيث يمكن لأي بورصة مركزية تعتمد نفس النموذج الذي نعتمده نحن أن تُنتج إثباتات لمستخدميها وأصولها بسهولة.
نأمل أن يكون هذا مفيدًا في دفع شفافية صناعة الأصول الرقمية إلى مستوى جديد. كما أننا نعمل على تنفيذ الحل المذكور في مدونة فيتاليك لتحقيق أداء أفضل، ما سيسمح لنا بتقديم الإثبات بشكل أكثر تكرارًا وبتكلفة أقل.
وبما أن هذا هو الإصدار الأول من zk-SNARK لدينا، فإننا نتطلع إلى تلقي ملاحظات من المجتمع حتى نواصل تحسين النظام.
الكود والقراءة الإضافية
كود المصدر الخاص بنا
إثباتات احتياطيات بينانس: ما هي شجرة ميركل
أكاديمية بينانس - تحسين شفافية العملات الرقمية عبر إثباتات المعرفة الصفرية
مدونة فيتاليك: امتلاك CEX آمن: إثبات الملاءة وما وراء ذلك
