ZK Rollups: الفيل في الغرفة

المؤلف الأصلي: جايهيون ها

تم تجميعها بواسطة: TechFlow

ملخص

• في حين أن أدلة المعرفة الصفرية (ZKPs) تحمل وعدًا لـ أكثر خصوصية وقابلية للتطوير في نظام blockchain البيئي، هناك العديد من جوانب المعرفة الصفرية (ZK) التي يتم فهمها بشكل خاطئ أو تنفيذها بشكل مختلف عما هو شائع.

• هناك جانبان رئيسيان لـ ZKPs: "المعرفة الصفرية" و"الإيجاز". على الرغم من أن هذا البيان ليس خاطئًا، فإن معظم عمليات تجميع ZK تستخدم خاصية الإيجاز فقط، وبيانات المعاملات ومعلومات الحساب ليست خالية من المعرفة أو خاصة تمامًا.

• بالنسبة لأنواع مختلفة من DApps، قد لا تكون مجموعات ZK هي الخيار الأفضل لمجموعات التطوير على سبيل المثال، قد يصبح إنشاء ZKPs بمثابة عنق زجاجة للنهاية السريعة، مما يقلل من أداء ألعاب Web3، في حين أن ضمانات توفر البيانات القائمة على نشر اختلاف الحالة قد تضر بخدمات بروتوكولات إقراض DeFi.

الشكل 1: ZK هي كلمة طنانة رائعة

المصدر: imgflip

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

في سلسلة ZK هذه، سنستكشف الحقائق غير المريحة (العيوب والعيوب) لـ ZK rollups وتطبيقاتها المفيدة. أولاً، سنكشف عن الخاصيتين الأساسيتين لـ ZK proofs (ZKPs) في blockchain: "المعرفة الصفرية" و"الإيجاز". سنناقش بعد ذلك كيف أن عددًا كبيرًا من ZK rollups قيد الخدمة حاليًا لا يستفيد حقًا من جانب "المعرفة الصفرية". بعد ذلك، سننظر في المجالات التي قد يكون فيها تطبيق ZK rollups أكثر ضررًا من الفائدة، وتجنب المشكلات المعروفة مثل تعقيد التنفيذ. أخيرًا، سنسلط الضوء على المشاريع البارزة التي تجسد مبادئ ZK بشكل فعال وتحصل بالفعل على فوائد واضحة من استخدام تقنية ZK.

ملخص: دورة حياة المعاملات في ZK Rollups

Rollup هو حل قابل للتوسع يعالج قيود الإنتاجية L1 من خلال تنفيذ حزم المعاملات خارج السلسلة ثم تخزين بيانات موجزة لأحدث حالة L2 على L1. ومن بين هذه الميزات، الميزة البارزة لـ ZK Rollups هي القدرة على سحب الأموال بسرعة من خلال تقديم دليل على صحة الحسابات خارج السلسلة على السلسلة. قبل أن نتعمق في مشاكل ZK Rollups، دعنا نراجع بإيجاز دورة حياة المعاملات الخاصة بها.

الشكل 2: دورة حياة المعاملات في عمليات التجميع الخاصة بـ ZK

المصدر: مركز بريستو للأبحاث

• يقوم كل مستخدم L2 بإنشاء معاملته وإرسالها إلى المسلسل.

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

• يتم إرسال هذه الدفعة إلى المُثبت، الذي يقوم بإنشاء إثبات صحة (أو ZKP) لتنفيذ الدفعة. ثم يتم إرسال إثبات الصحة هذا إلى العقد الذكي للمُثبت على L1 مع بيانات إضافية (أي جذر الحالة السابقة)، مما يساعد المُثبت على تحديد ما يثبت صحته.

• بعد أن يتحقق عقد المحقق من صحة الإثبات، يتم تحديث حالة التجميع ويتم اعتبار معاملات L2 في الدفعة المرسلة مكتملة.

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

على عكس عمليات التجميع المتفائلة، بفضل ZKPs (مثل ZK-SNARKs أو ZK-STARKs)، يمكن لـ ZK Rollups التحقق من صحة تنفيذ آلاف المعاملات من خلال التحقق من إثبات بسيط دون إعادة تشغيل جميع المعاملات. إذن، ما هو ZKP هذا وما هي خصائصه؟

خاصيتان لـ ZKPs: صفر المعرفة والبساطة

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

ماذا لو كانت هناك عملية تحقق حيث يمكن لأليس التحقق بسرعة من الوصول إلى الكمبيوتر دون أن يكشف بوب عن كلمة مروره؟ على سبيل المثال، يمكن لبوب إلغاء قفل الكمبيوتر المحمول الخاص به باستخدام التعرف على بصمات الأصابع أمام أليس، كما هو موضح في الشكل 3 (لاحظ أن هذا ليس مثالاً مثاليًا لـ ZKP). هنا يمكن لأليس وبوب الاستفادة من خاصيتين رئيسيتين لـ ZKPs: خاصية المعرفة الصفرية وخاصية البساطة.

الشكل 3: الحدس عالي المستوى للمعرفة الصفرية والبساطة

المصدر: imgflip

المعرفة الصفرية (ZK)

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

بساطة

تشير الخاصية المختصرة إلى قدرة ZK على إنشاء دليل قصير وقابل للتحقق السريع من بيان كبير الحجم، بعبارة أخرى، تقوم بضغط شيء كبير في شكل مضغوط. في blockchain، يعد هذا مفيدًا بشكل خاص لعمليات التجميع. باستخدام ZKPs، يمكن للمحقق في L2 المطالبة بالتنفيذ الصحيح لمعاملة من خلال تقديم دليل مختصر إلى محقق في L1 (يمكن تمثيل صحة معاملة بحجم TB بواسطة دليل 10 ~ 100 كيلوبايت). يمكن للمحقق بعد ذلك تأكيد صحة التنفيذ بسهولة في وقت قصير (أي 10 مللي ثانية إلى ثانية واحدة) من خلال التحقق من الدليل المختصر بدلاً من إعادة تشغيل جميع المعاملات.

ZK Rollup رائع، لكنه لا يعني الخصوصية

إن خصائص ZK Rollups الموضحة أعلاه مستخدمة بشكل جيد في ZK Rollups. وبينما لا يستطيع المحققون استنتاج بيانات المعاملات الأصلية من ZKPs التي تلقوها من المزودين، فإن التحقق من الأدلة المختصرة يسمح لهم بالتحقق بشكل فعال من ادعاءات المزودين (أي حالة L2 الجديدة). ومع ذلك، فمن المضلل أن نزعم أن ZK Rollups الحالية تلتزم تمامًا بخصائص عدم المعرفة والإيجاز. قد يكون هذا صحيحًا عند التركيز على التفاعل بين المزودين والمحققين، ولكن هناك مكونات أخرى في ZK Rollups مثل أجهزة التسلسل والمزودين وعقد التجميع. لذا، هل يتم ضمان مبدأ عدم المعرفة أيضًا لهم؟

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

الشكل 4: تسرب الخصوصية في عمليات التجميع الخاصة بـ ZK

المصدر: أبحاث بريستو

في معظم عمليات التجميع الرئيسية لـ ZK، يمكن للمُسلسل أو الموفر (أو أي كيان مركزي آخر يتمتع بأذونات قوية) رؤية تفاصيل المعاملة بوضوح، بما في ذلك مبالغ التحويل وتحديثات رصيد الحساب ونشر العقد وتنفيذه. كمثال بسيط، يمكنك بسهولة ملاحظة جميع التفاصيل المذكورة من خلال زيارة أي متصفح كتلة ZK Rollup. ليس هذا فقط، ضع في اعتبارك موقفًا يتوقف فيه المُسلسل المركزي عن الخدمة لسبب ما وتحاول عقدة تجميع أخرى استرداد حالة التجميع. ستستخرج المعلومات من بيانات L2 التي تم إصدارها علنًا بواسطة طبقة DA (في معظم الحالات، L1 Ethereum) وإعادة بناء حالة L2. في هذه العملية، يمكن لأي عقدة يمكنها إعادة تشغيل معاملات L2 المخزنة بواسطة طبقة DA استرداد المعلومات حول حالة حساب كل مستخدم.

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

لهذا السبب، تشير بعض ZK Rollups، مثل Starknet، إلى نفسها باسم "Validity Rollups" لتجنب الارتباك، في حين أن البعض الآخر الذي يضمن خصوصية ZK الحقيقية، مثل Aztec، يطلق على نفسه اسم ZK-ZK rollups.

اعتبارات أعمق حول جدوى ZK Rollups

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

النقطة 1: يمكن أن يكون إنشاء نقاط المعرفة الخاصة بالمنطقة (ZKPs) بمثابة عنق زجاجة للنهاية السريعة

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

ولكن هل يمكن اعتبار ZK Rollups حقًا أفضل مجموعة تقنيات للألعاب؟ لتحقيق هذه الغاية، نحتاج إلى التفكير بشكل أعمق في مفهوم النهاية السريعة في ZK Rollups. تخيل أن المستخدم يستمتع بلعبة Web3 تعمل على مجموعة تقنيات تعتمد على ZK Rollup. يتاجر المستخدم بعناصر داخل اللعبة مقابل عملات اللعبة ويحاول سحب الأصل من اللعبة.

لسحب الأصول، يجب إتمام المعاملات داخل اللعبة. وهذا يعني أنه يجب تضمين المعاملة في التزام حالة Rollup جديد، ويجب تقديم ZKP المقابل إلى L1، ومن الضروري انتظار اكتمال الإثبات في L1 Ethereum لضمان عدم التراجع عن المعاملة. إذا كان من الممكن حدوث كل هذه العمليات على الفور، فيمكننا تحقيق تأكيد المعاملة الفوري الذي تروج له ZK Rollups غالبًا، مما يسمح للمستخدمين بسحب الأصول على الفور.

لكن الواقع بعيد كل البعد عن ذلك. وفقًا لإحصائيات وقت النهاية لمختلف عمليات ZK Rollups المقدمة بواسطة L2beat يستغرق zkSync Era حوالي ساعتين، ويستغرق Linea 3 ساعات، ويستغرق Starknet حوالي 8 ساعات في المتوسط. وذلك لأن الأمر يستغرق وقتًا لإنشاء ZKP، ويستغرق أيضًا وقتًا إضافيًا لتضمين المزيد من المعاملات في دفعة واحدة (أي، دليل واحد) لتقليل رسوم المعاملات. بعبارة أخرى، فإن سرعة إنشاء الأدلة وإرسالها تشكل عقبة محتملة لتحقيق النهاية السريعة لـ ZK Rollups، مما قد يقلل من تجربة المستخدم في ألعاب Web3.

الشكل 5: يمكن أن يكون إنشاء ZKP بمثابة عنق زجاجة محتمل لإنهاء عمليات تجميع ZK بسرعة

المصدر: imgflip

من ناحية أخرى، تضمن السلاسل المحسّنة للألعاب مثل Ronin (التي تدعم ألعاب Web3 مثل Pixels وAxie Infinity) نهائية فائقة السرعة، مما يضحي باللامركزية والأمان. Ronin ليست سلسلة تعتمد على ZK أو Rollup: إنها سلسلة كتلة EVM تعمل بموجب خوارزمية إجماع PoA (إثبات السلطة) + DPoS (إثبات الحصة المفوضة). تختار 22 محققًا بناءً على عدد الحصص المفوضة، ثم يقوم هؤلاء المحققون بإنشاء الكتل والتحقق منها بطريقة PoA (أي عملية تصويت بين المحققين الـ 22 فقط). ونتيجة لذلك، على Ronin، تكون المعاملات قادرة على الانتهاء بسرعة، ويتم تضمينها في الكتل دون أي تأخير تقريبًا، ولديها وقت تحقق منخفض. بعد شوكة Shillin الصعبة، استغرق الأمر في المتوسط 10 دقائق فقط. 6 ثواني لإتمام كل معاملة. يحقق Ronin كل هذا دون الحاجة إلى ZKP.

بالطبع، لدى Ronin أيضًا عيوب. نظرًا لأنه يتم إدارته بواسطة محققين مركزيين، فإنه أكثر عرضة نسبيًا لخطر هجوم 51%. بالإضافة إلى ذلك، نظرًا لأنه لا يستخدم Ethereum كطبقة تسوية، فلا يمكنه أن يرث أمان Ethereum. هناك أيضًا مخاطر أمنية في استخدام الجسور عبر السلسلة. ولكن من منظور المستخدمين: هل يهتمون بهذه؟ تعاني ZK Rollups الحالية بدون ترتيب لامركزي أيضًا من مشاكل نقطة الفشل الفردية (SPOF). توفر لهم Ethereum ضمانات لأنها تقلل من احتمالية التراجع عن المعاملات، ولكن يمكن أن تتجمد ZK Rollups أيضًا إذا فشل التسلسل المركزي أو المحقق. لاحظ مرة أخرى أن ZK في ZK Rollups يستخدم فقط للتحقق من صحة التنفيذ. إذا كان هناك مشروع آخر يوفر نفس الوظيفة ولكن بشكل أسرع وأرخص، فقد لا تعتبر ZK Rollups بعد الآن مجموعة التكنولوجيا المفضلة لمستخدمي ومطوري ألعاب Web3.

النقطة 2: الاختلافات في حالة الإصدار هي سلاح ذو حدين

هناك نقطة أخرى تتعلق بالتطبيق العملي لبروتوكول ZK Rollup. ومن بين هذه النقاط، نركز هنا على نشر اختلافات الحالة، وهي إحدى الطرق لضمان توفر البيانات في عمليات التجميع ZK (انظر فتح ترقية Dencun: الحقيقة غير المرئية حول توسيع طبقات DA ، جايهيون ها، 12 أبريل 24).

تتمثل إحدى الطرق البسيطة لفهم مدى توفر البيانات في عمليات التجميع في تخيل متسلق هاوٍ يثبت ويوثق صعوده إلى جبل إيفرست. وأبسط طريقة للقيام بذلك هي تسجيل كل خطوة من المعسكر الأساسي إلى القمة على الفيديو. ورغم أن ملف الفيديو قد يكون كبيرًا، إلا أنه يمكن لأي شخص التحقق من صعود المتسلق وإعادة تشغيل التسجيل. ويمكن مقارنة هذا الاستعارة بنهج نشر بيانات المعاملات الأصلية لضمان توفر البيانات. تتبع عمليات التجميع المتفائلة هذا النهج حتى يتمكن المتحدون الفرديون من إعادة التشغيل والتحقق من التنفيذ الصحيح لأن التزامات حالة التسلسل لا يمكن الوثوق بها. في عمليات التجميع ZK، تتبع Polygon zkEVM وScroll هذا النهج، حيث تخزن بيانات المعاملات L2 الأصلية في شكل مضغوط على L1 حتى يتمكن أي شخص من إعادة تشغيل معاملات L2 لاستعادة حالة التجميع عند الحاجة.

وبالعودة إلى مثال المتسلق الهواة، قد تكون طريقة أخرى للتحقق هي أن يتسلق متسلق مشهور جبل إيفرست مع المتسلق الهواة لإثبات للعالم أن التسلق قد تم بالفعل. وبما أن التسلق تم تأكيده من قبل فرد موثوق به، فإن المتسلق لم يعد بحاجة إلى تسجيل كل خطوة لحفظ السجلات. إن مجرد التقاط صورة عند نقطة البداية وفي أعلى الجبل سيسمح للآخرين بالاعتقاد بأن المتسلق قد وصل إلى القمة. يعكس هذا الاستعارة نهج اختلاف الحالة تُستخدم لضمان توفر البيانات. في ZK Rollups، يتبنى zkSync Era وStarkNet هذا النهج، حيث يتم تخزين فرق الحالة فقط قبل وبعد تنفيذ معاملة L2 على L1، بحيث يمكن لأي شخص حساب فرق الحالة من الحالة الأولية لاستعادة حالة Rollup إذا لزم الأمر.

الشكل 6: إصدار المعاملة الأصلية وإصدار اختلاف الحالة

المصدر: أبحاث بريستو

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

لنأخذ على سبيل المثال Compound، وهو بروتوكول إقراض DeFi، ونفترض أنه مبني على مجموعة ZK Rollup القائمة على التفاضل بين الحالات. تتطلب هذه البروتوكولات سجل معاملات كامل لحساب أسعار العرض والإقراض كل ثانية. ومع ذلك، إذا فشل مُسلسل ZK Rollup، فماذا يحدث عندما تحاول عقد Rollup الأخرى استعادة أحدث حالة؟ قد يستعيد الحالة، لكن سيتم استعادة سعر الفائدة بشكل غير دقيق لأنه لا يمكنه تتبع سوى اللقطات بين الدفعات بدلاً من كل معاملة وسيطة.

ختاماً

إن التأكيد الرئيسي لهذه المقالة هو لا يوجد "ZK" في معظم ZK Rollups اليوم، وهناك العديد من الأماكن في DApps حيث قد لا يكون استخدام ZKPs وإجراءات ZK هو الخيار الأفضل. قد تبدو تقنية ZK بريئة من الاتهامات لأنها لا تحتوي على أي خطأ في حد ذاتها، ولكنها قد تؤدي إلى تدهور محتمل في أداء التطبيقات اللامركزية في عملية الاستفادة من تقدمها التكنولوجي. ومع ذلك، هذا لا يعني أن تقنية ZK عديمة الفائدة للصناعة. عندما تنضج ZKPs وZK rollups في النهاية، يمكنها بالتأكيد تقديم حلول أفضل لمعضلة blockchain. في الواقع، هناك بالفعل مشاريع تعتمد على ZK تحافظ على خصوصية ZK، وهناك العديد من أنواع التطبيقات اللامركزية التي تستفيد بشكل فعال من ZKPs وZK convolutions.

الرابط الأصلي

تم الحصول على هذه المقالة من الإنترنت: ZK Rollups: The Elephant in the Room

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

في 24 أبريل، وفقًا للأخبار الرسمية، أعلنت شركة إدارة الأصول الصينية (هونج كونج) اليوم أن صندوق الاستثمار المتداول في الصين لإدارة الأصول بيتكوين وصندوق الاستثمار المتداول في إدارة الأصول الصينية إيثريوم قد تمت الموافقة عليهما من قبل لجنة الأوراق المالية والعقود الآجلة (SFC) في هونج كونج ومن المقرر أن يتم إصدارهما. تم إصدارها في 29 أبريل 2024 وتم إدراجها في منصة التداول في هونج كونج في 30 أبريل 2024. وهذه هي المرة الأولى التي يتم فيها إطلاق مثل هذه المنتجات في السوق الآسيوية. تم تصميم هذين النوعين من المنتجات لتوفير عوائد استثمارية مرتبطة بالأسعار الفورية للبيتكوين والإيثريوم. وقد جذبت هذه الخطوة الكبرى الانتباه مرة أخرى إلى مفهوم هونغ كونغ. في بداية هذا العام، ارتفعت CFX، الشركة الرائدة في مفهوم هونج كونج، من US$0.19 إلى US$0.52 في شهرين.