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

ما هي ZK-SNARKS؟

تخيل وجود مدخل عام x، ومدخل خاص w، ووظيفة (عامة) f (x، w) → {True,False}، والتي تتحقق من صحة المدخلات. باستخدام zk-SNARks، يمكن للمرء أن يثبت أنه يعرف w، بحيث بالنسبة لـ f و x، f (x، w) = صحيح، كل ذلك دون الكشف عن ماهية w في الواقع. علاوة على ذلك، يمكن للمدققين المصادقة على الإثبات بشكل أسرع بكثير مما يمكنهم من حساب f (x، w) حتى لو كانوا يعرفون w.

هذا يمنح zk-SNARks سمتين: الخصوصية وقابلية التوسع. كما ذكرنا، ستركز الأمثلة في هذه المقالة بشكل أساسي على جانب الخصوصية.

إثبات العضوية

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

الإدخال الخاص (w): عنوانك A، عنوانك، المفتاح الخاص k

الإدخال العام (x): مجموعة عناوين لجميع ملفات تعريف إثبات الإنسانية التي تم التحقق منها {H1…Hn}

وظيفة التحقق (f (x، w):

قم بتفسير w كزوج (A، α) و x كقائمة ملفات تعريف صالحة {H1…Hn}

تحقق من أن A هو أحد العناوين في {H1…Hn}

تأكيد العنوان الخاص (k) = A

إذا تم اجتياز كلا التحققين، فأرجع True. في حالة فشل أي منها، قم بإرجاع False.

يقوم الموفر بإنشاء العنوان A والمفتاح المرتبط k، مع توفير w= (A، k) كمدخل خاص لـ f. يحصلون على المدخلات العامة، وهي المجموعة الحالية من ملفات تعريف إثبات الإنسانية التي تم التحقق منها {H1…Hn}، من السلسلة. ثم يقومون بتشغيل خوارزمية إثبات zk-SNARK، والتي (بافتراض صحة الإدخال) تنتج إثباتًا. يتم إرسال هذا الإثبات إلى المدقق، بالإضافة إلى ارتفاع الكتلة حيث جلبوا قائمة الملفات الشخصية التي تم التحقق منها.

يقرأ المدقق أيضًا السلسلة، ويحصل على القائمة {H1…Hn} من الارتفاع المحدد بواسطة المُثبت، ويتحقق من الإثبات. في حالة نجاح عملية التحقق، يعتقد المدقق أن المُثبت يمتلك ملفًا شخصيًا تم التحقق منه لإثبات الإنسانية.

قبل الخوض في أمثلة أكثر تعقيدًا، أوصي بشدة بفهم المثال أعلاه بشكل كامل.

جعل براهين العضوية أكثر كفاءة

أحد عيوب نظام الإثبات المذكور أعلاه هو أن المدقق يجب أن يكون على دراية بمجموعة ملفات التعريف بأكملها {H1…Hn}، والتي تتطلب وقت O (n) «لإدخال» هذه المجموعة في آلية zk-SNARK. يمكن معالجة هذه المشكلة باستخدام جذر Merkle على السلسلة، والذي يشمل جميع الملفات الشخصية، كمدخل عام (من المحتمل أن يكون جذر الولاية فقط). نضيف مدخلًا خاصًا آخر، وهو Merkle proof M، مما يؤكد أن حساب المُثبت A موجود في الجزء ذي الصلة من الشجرة.

يعد Caulk بديلاً حديثًا للغاية وأكثر كفاءة لبراهين Merkle لأدلة عضوية ZK. في المستقبل، قد تنتقل بعض حالات الاستخدام هذه إلى حلول مشابهة لـ Caulk.

سنارك وعملات Zk

تمكننا مشاريع مثل Zcash و Tornado.cash من امتلاك عملات تحمي الخصوصية. الآن، قد يعتقد المرء أنه يمكنهم استخدام «أدلة ZK البشرية» المذكورة، ولكن الأمر لا يتعلق بإثبات الوصول إلى براهين الملف الشخصي البشري؛ يتعلق الأمر بإثبات الوصول إلى العملات المعدنية. هنا تكمن المشكلة: يجب علينا معالجة كل من الخصوصية والإنفاق المزدوج في وقت واحد. وهذا يعني أننا لا ينبغي أن ننفق نفس العملة مرتين.

إليك كيفية حلها: أي شخص يمتلك عملة معدنية لديه «أسرار» خاصة. يقومون بحساب «leaf» l=hash (s,1) محليًا، والذي يتم نشره على السلسلة، ليصبح جزءًا من الحالة، n=hash (s,2)، والتي نسميها المُبطل. يتم تخزين الولاية في شجرة Merkle.

لإنفاق عملة معدنية، يجب على المرسل إنتاج ZK-SNARK حيث:

• تتضمن المدخلات العامة المُبطل N، وجذر Merkle الحالي أو الأخير R، والورقة الجديدة L' (المخصصة للمستلم الذي لديه سر 'تم تمريره إلى المرسل باسم l'=hash (s',1)).

• تشتمل المدخلات الخاصة على حرف s السري والورقة L وفرع Merkle M.

تتحقق وظيفة التحقق من:

• M هو فرع Merkle صالح، مما يثبت أن L عبارة عن ورقة شجرة متجذرة في R، حيث R هو جذر Merkle للحالة الحالية.

• هاش (س،1) =L وهاش (s,2) =N.

تحتوي المعاملة على المبطل N والورقة الجديدة L'. نحن لا نثبت فعليًا أي شيء عن L '، ولكنه «مختلط» في الدليل لمنع التعديل من قبل أطراف ثالثة أثناء المعاملة. للتحقق من صحة المعاملة، تتحقق السلسلة من ZK-SNARK وتتحقق مما إذا كان N قد تم استخدامه في المعاملات السابقة. في حالة النجاح، تتم إضافة N إلى مجموعة أدوات إلغاء الاستخدام المستهلكة، مما يجعلها غير قابلة للاستخدام مرة أخرى. تمت إضافة L إلى شجرة Merkle.

باستخدام zk-SNARks، نربط قيمتين: L (تظهر على السلسلة عند سك العملة) و N (تظهر عند الإنفاق)، دون الكشف عن L الذي يتصل بأي N. لا يمكن تمييز الاتصال بين L و N إلا عندما تعرف الأسرار التي تولدها. يمكن استخدام كل عملة مسكوكة مرة واحدة (حيث لا يوجد سوى N واحد صالح لكل L)، ولكن تظل العملة المحددة المستخدمة في أي وقت مخفية.

هذه طريقة بدائية مهمة يجب فهمها. تعتمد العديد من الآليات التي وصفناها أدناه على هذا، ولكن لأغراض متنوعة.

عملات معدنية بأرصدة عشوائية

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

ZK مكافحة الحرمان من الخدمة

أداة مثيرة للاهتمام لمكافحة DOS: تخيل أن لديك بعض الهوية على السلسلة التي لا يمكن إنشاؤها بسهولة؛ يمكن أن يكون ملفًا شخصيًا مقاومًا للبشر أو 32 مدققًا من ETH، أو مجرد حساب برصيد ETH غير صفري. يمكننا إنشاء شبكة نظير إلى نظير أكثر مقاومة لـ DoS من خلال قبول الرسائل التي تثبت أن المرسل لديه ملف تعريف فقط. سيتم السماح لكل ملف تعريف بما يصل إلى 1000 رسالة في الساعة. إذا قام المرسل بالغش، تتم إزالة ملفه الشخصي من القائمة. ولكن كيف نضمن الخصوصية؟

أولاً، الإعداد: اجعل k هو المفتاح الخاص للمستخدم، و A=privtoAddr (k) العنوان المقابل. قائمة العناوين الصالحة عامة (على سبيل المثال، سجل على السلسلة). حتى الآن، يعكس هذا المثال الدليل البشري: يجب أن تثبت أنك تحتفظ بالمفتاح الخاص لعنوان دون الكشف عن العنوان. لكننا لا نريد فقط إثبات أنك على القائمة. نحتاج إلى بروتوكول يتيح لك إثبات وجودك في القائمة ولكنه يحد من البراهين الخاصة بك.

سنقسم الوقت إلى فترات: تستغرق كل منها 3.6 ثانية (أي 1000 فترة في الساعة). هدفنا هو السماح لكل مستخدم بإرسال رسالة واحدة فقط في كل فترة؛ إذا أرسلوا رسالتين في نفس الفترة، فسيتم القبض عليهم. وللسماح بحدوث رشقات نارية من حين لآخر، يمكنهم استخدام الفترات الأخيرة. لذلك، إذا كان لدى المستخدم 500 فترة غير مستخدمة، فيمكنه إرسال 500 رسالة دفعة واحدة.

بروتوكول

لنبدأ بإصدار أساسي باستخدام أدوات إلغاء الإبطال. يقوم المستخدم بإنشاء أداة إلغاء باستخدام (N =\ text{hash}(k, e)) حيث (k) هو مفتاحه، و (e) عبارة عن رقم حقبة، ثم ينشره بالرسالة (m). يقوم ZK-SNARK بعد ذلك بتعتيم (\ text{hash}(m)). لم يتم التحقق من أي شيء يتعلق بـ (m) في هذه العملية، وبالتالي ربط الدليل برسالة واحدة. إذا قام المستخدم بربط دليلين برسالتين متميزتين باستخدام نفس المبطل، فإنه يخاطر بأن يتم القبض عليه.

الآن، ننتقل إلى إصدار أكثر تعقيدًا. في هذا السيناريو، يكشف البروتوكول اللاحق عن مفتاحهم الخاص بدلاً من مجرد تأكيد ما إذا كان شخص ما قد استخدم نفس الحقبة مرتين. تعتمد تقنيتنا المحورية على مبدأ «نقطتان تحددان الخط». إن الكشف عن نقطة واحدة على الخط يكشف القليل، لكن كشف نقطتين يكشف عن الخط بأكمله.

لكل حقبة (e)، نختار سطرًا (L_e (x) =\ text{hash}(k، e)\ times x + k). منحدر الخط هو (\ text{hash}(k, e))، وتقاطع y هو (k)، وكلاهما غير معروف للجمهور. لإنتاج شهادة للرسالة (m)، يقدم المرسل (y = l_e (\ text{hash}(m)) =\ text{hash}(k, e)\ times\ text{hash}(m) + k)، إلى جانب دليل ZK-SNARK على أن حساب (y) دقيق.

بإيجاز، ZK-SNARK هو كما يلي:

المدخلات العامة:

• ({A_1…A_n}): قائمة الحسابات الصالحة

• (M): الرسالة التي يتم التحقق من صحتها بواسطة الشهادة

• (E): رقم عصر الشهادة

• (Y): تقييم وظيفة الخط

الإدخال الخاص:

• (K): مفتاحك الخاص

وظيفة التحقق:

• تحقق مما إذا كان (\ text{privtoaddr}(k)) موجودًا في ({A_1…A_n})

• تأكيد (y =\ النص{hash}(k، e)\ times\ text{hash}(m) + k)

ولكن ماذا لو استخدم شخص ما حقبة مرتين؟ سيكشفون عن قيمتين (m_1) و (m_2) جنبًا إلى جنب مع قيم الشهادات الخاصة بهم (y_1 =\ text{hash}(k، e)\ times\ text{hash}(m_1) + k) و (y_2 =\ text{hash}(k، e)\ times\ text{hash}(m_2) + k). يمكننا بعد ذلك استخدام هاتين النقطتين لاستعادة الخط وبالتالي التقاطع y، وهو المفتاح الخاص.

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

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

سمعة ZK السلبية

تخيل إنشاء 0chan، وهو منتدى عبر الإنترنت مثل 4chan يوفر إخفاء الهوية بالكامل (ليس لديك حتى أسماء دائمة)، ولكن مع نظام سمعة للترويج لمحتوى عالي الجودة. يمكن أن يحتوي مثل هذا النظام على DAO للحوكمة للإبلاغ عن المشاركات التي تنتهك قواعد النظام، مع إدخال آلية ثلاثية الضربات.

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

منشور مرتبط: المعرفة الأساسية

يمكن لأي شخص النشر عن طريق إرسال رسالة على السلسلة التي تحتوي على المنشور، مصحوبة بـ ZK-SNARK. يُعد ZK-SNARK هذا بمثابة دليل على (1) أنك تمتلك هوية خارجية فريدة تمنحك الإذن بإنشاء حساب، أو (2) أنك نشرت منشورات محددة مسبقًا. على وجه التحديد، تعمل ZK-SNARK على النحو التالي:

المدخلات العامة:

• المبطل، N

• أحدث جذر لحالة بلوكتشين، R

• نشر المحتوى («ممزوج» في الدليل لربطه بالمنشور، دون أي حسابات عليه)

المدخلات الخاصة:

• مفتاحك الخاص،

• هوية خارجية (العنوان A) أو المبطل، Nprev، المستخدم في المنشور السابق

• دليل ميركل، M، على أن السلسلة تحتوي على A أو Nprev

• المنشور الذي نشرته باستخدام هذا الحساب

وظيفة التحقق:

1. تأكد من أن M هو فرع Merkle صالح، مما يثبت أن (A أو Nprev، أيهما يتم توفيره) عبارة عن ورقة شجرة ذات جذر R.

2. تحقق من N = enc (i، k) حيث تكون enc دالة تشفير (على سبيل المثال، AES).

3. إذا كانت i=0، تحقق من A=privToAddr (k)، وإلا تحقق من nprev=enc (i−1، k).

إلى جانب التحقق من صحة الإثبات، تتحقق السلسلة أيضًا من (1) أن R هو في الواقع جذر حالة حديث، و (2) أن المبطل N لم يتم استخدامه من قبل. حتى هذه اللحظة، تشبه العملات التي تم وصفها سابقًا للحفاظ على الخصوصية، لكننا أضفنا عملية «سك» الحسابات الجديدة وأزلنا القدرة على «إرسال» حسابك إلى مفاتيح مختلفة. بدلاً من ذلك، يتم إنشاء جميع أدوات إلغاء الاستخدام باستخدام المفتاح الأصلي. نحن نستخدم enc هنا لجعل المبطل قابلاً للعدول. إذا كان لديك مفتاح k، فيمكنك فك تشفير أي مُبطل محدد على السلسلة؛ إذا كانت النتيجة عبارة عن فهرس صالح وليس هراء عشوائي (على سبيل المثال، يمكننا فقط التحقق من dec (N) < 2^64)، فستعرف أن المُبطل قد تم إنشاؤه باستخدام المفتاح k.

إضافة السمعة:

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

لقد قمنا بتوسيع البيانات المخزنة على السلسلة لكل منشور. بدلاً من تخزين المُبطل N فقط، نقوم بتخزين {N, h¯, u¯} حيث:

• h169.= hash (h, r) حيث يمثل h ارتفاع كتلة جذر الحالة المشار إليه في الإثبات.

• u169.= hash (u, r) حيث u هي درجة سمعة الحساب (بدءًا من 0 للحسابات الجديدة).

R هنا قيمة عشوائية مضافة لمنع العثور على h و u من خلال البحث بالقوة الغاشمة. من حيث التشفير، فإن إضافة R تجعل التجزئة التزامًا مخفيًا.

افترض أن المنشور يستخدم الجذر R ويخزن {N, h¯, u¯}. ضمن إثباته، فإنه يرتبط بمنشور سابق قام بتخزين البيانات {Nprev, h¯prev, u¯prev}. يجب أن يجتاز إثبات المنشور أيضًا جميع إدخالات السمعة المنشورة بين hprev و h. بالنسبة لكل مُبطل N، تقوم وظيفة التحقق بفك تشفير N باستخدام مفتاح المستخدم k. إذا كان فك التشفير ينتج فهرسًا صالحًا، فإنه يقوم بتطبيق تحديث السمعة. إذا كان إجمالي جميع تحديثات السمعة يساوي δ، فهذا يثبت u = uprev + δ.

إذا كنا نرغب في تنفيذ قاعدة «الضربات الثلاث وستخرج»، فإن ZK-SNARK ستضمن أيضًا u > -3. إذا أردنا قاعدة تتلقى فيها مشاركة ذات مندوب ≥ 100 علامة «منشور عالي السمعة» خاصة، فيمكن القيام بذلك أيضًا.

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

مساءلة الأطراف المركزية

في بعض الأحيان، هناك حاجة لتصميم نظام باستخدام «مشغل» مركزي. قد تختلف أسباب ذلك: في بعض الأحيان، يتعلق الأمر بقابلية التوسع، وفي حالات أخرى، يتعلق الأمر بالخصوصية، وخاصة خصوصية البيانات التي يحتفظ بها المشغل. على سبيل المثال، يتطلب نظام التصويت المقاوم للإكراه من MACI من الناخبين تقديم أصواتهم عبر السلسلة، مشفرة بمفتاح يحتفظ به مشغل مركزي. يقوم هذا المشغل بفك تشفير جميع الأصوات على السلسلة، وحصرها، وعرض النتيجة النهائية. يستخدمون ZK-SNARK لإثبات أن كل ما فعلوه كان دقيقًا. يعد هذا التعقيد الإضافي أمرًا بالغ الأهمية لضمان الخصوصية القوية (المعروفة باسم المقاومة القسرية): لا يمكن للمستخدمين أن يثبتوا لأي شخص كيف صوتوا، حتى لو أرادوا ذلك. بفضل blockchain و ZK-SNARK، يظل مستوى ثقتنا في المشغل ضئيلًا. يمكن للمشغلين الضارين خرق المقاومة القسرية، ولكن بما أن الأصوات يتم نشرها على بلوكتشين، فلا يمكنهم الغش من خلال الرقابة على الأصوات. ونظرًا لأنه يجب عليهم توفير ZK-SNARK، فلا يمكنهم الغش عن طريق حساب النتائج بشكل خاطئ.

الجمع بين ZK-SNARKS مع MPC

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

ما الذي لا يمكننا جعله خاصًا؟

تعتبر zk-SNARks فعالة للغاية في إنشاء أنظمة يكون فيها للمستخدمين حالات خاصة. ومع ذلك، لا يمكنها الحفاظ على دولة خاصة لا يعرفها أحد. لكي يتم إثبات المعلومات، يجب أن يعرفها المُثبت بنص عادي. Uniswap هو مثال يصعب خصخصته. في Uniswap، هناك «كيان» منطقي مركزي - حساب مزود السيولة، الذي لا ينتمي إلى أي شخص، وجميع معاملات Uniswap تحدث مع هذا الحساب. لا يمكنك إخفاء حالة هذا الحساب نظرًا لأن شخصًا ما يحتاج إلى الاحتفاظ بهذه الحالة بنص عادي لإثبات ذلك، وستتطلب كل معاملة مشاركته النشطة. يمكنك استخدام دوائر ZK-SNARK المشوهة لإنشاء إصدار مركزي وآمن وخاص من Uniswap، ولكن من غير الواضح ما إذا كانت الفوائد ستفوق التكاليف. قد لا تقدم حتى أي فوائد حقيقية: تحتاج العقود إلى إبلاغ المستخدمين بأسعار الأصول، ويمكن أن تكشف تحولات الأسعار لكل كتلة عن نشاط المعاملات. يمكن لـ Blockchains عولمة معلومات الدولة، ويمكن لـ ZK-SNARKS خصخصتها، ولكن لا توجد طريقة قوية لعولمة وخصخصة معلومات الدولة في وقت واحد.

وضع الأوليات معًا

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

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [Foresightnews]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [جاكوب كو]. إذا كانت هناك اعتراضات على إعادة الطباعة هذه، فيرجى الاتصال بفريق Gate Learn، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. يقوم فريق Gate Learn بترجمة المقالة إلى لغات أخرى. ما لم يُذكر، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.