فيتاليك: ناقش مختلف أنواع إصدارات "ZK-EVM المدمجة" وتحديات التصميم

كلمات: فيتاليك بوتيرين

تجميع: 1912212.eth ، أخبار الاستشراف

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

هذا الموقف ليس مثاليا ، حيث تقوم هذه المشاريع بتكرار الوظائف الموجودة بالفعل في بروتوكول ورشة العمل ETH ، والحوكمة ETH مسؤولة بالفعل عن ترقية الأخطاء وإصلاحها: ZK-EVM هي في الأساس نفس وظيفة التحقق من صحة كتل ورشة عمل ETH من الطبقة 1!بالإضافة إلى ذلك ، في السنوات القادمة ، نتوقع أن يصبح العملاء الخفيفون أكثر قوة ، ويصلون قريبا إلى النقطة التي يتم فيها استخدام ZK-SNARKs للتحقق الكامل من تنفيذ Layer 1 EVM. عند هذه النقطة ، ستقوم شبكة ETH ببناء ZK-EVM المدمج بشكل فعال. لذا ، فإن السؤال الذي يطرح نفسه: لماذا لا تجعل ZK-EVM نفسها مناسبة لعمليات التجميع أيضا؟

في هذه المقالة ، سنلقي نظرة على عدد قليل من إصدارات “ZK-EVM المدمجة” التي يمكن تنفيذها ، ونناقش المقايضات وتحديات التصميم ، بالإضافة إلى أسباب عدم السير في اتجاه معين. يجب موازنة فوائد تنفيذ ميزات البروتوكول مقابل فوائد ترك الأشياء للنظام البيئي والحفاظ على بساطة البروتوكول الأساسي.

ما هي الميزات الرئيسية التي نريدها من ZK-EVM المدمج؟

• الوظيفة الأساسية: التحقق من صحة كتل ETH. يجب أن تقبل وظيفة البروتوكول (التي لم يتضح بعد ما إذا كانت رمز التشغيل أو التحويل البرمجي المسبق أو آلية أخرى) جذرا واحدا على الأقل قبل الحالة وكتلة واحدة وجذرا واحدا بعد الحالة كمدخلات ، والتحقق من أن جذر ما بعد الحالة هو في الواقع نتيجة لتنفيذ الكتلة.
• متوافق مع العديد من عملاء ETH Square. هذا يعني أننا نريد تجنب نظام تصديق واحد فقط وبدلا من ذلك نسمح لعملاء مختلفين باستخدام أنظمة تصديق مختلفة. هذا يؤدي إلى النقاط التالية:
• متطلبات توافر البيانات: بالنسبة لأي تنفيذ EVM يستخدم ZK-EVM المدمج للبراهين ، نريد ضمان توفر البيانات الأساسية حتى يتمكن المثبتون الذين يستخدمون نظام تصديق مختلف من إعادة التصديق على التنفيذ والسماح للعملاء الذين يعتمدون على نظام التصديق هذا بالتحقق من صحة البراهين التي تم إنشاؤها حديثا.
• توجد البراهين خارج هياكل بيانات EVM وقطعها: لا تأخذ ميزة ZK-EVM المضمنة SNARKs كمدخلات داخل EVM ، حيث يتوقع العملاء المختلفون أنواعا مختلفة من SNARKs. بدلا من ذلك ، قد يكون مشابها للتحقق من صحة blob: يمكن أن تتضمن المعاملة مطالبات (ما قبل الحالة ، ونص الكتلة ، وما بعد الحالة) التي تحتاج إلى التصديق ، والتي يمكن الوصول إلى محتوياتها بواسطة رمز التشغيل أو المترجم المسبق ، وستتحقق قواعد الإجماع من جانب العميل من توفر البيانات وإثبات وجودها لكل مطالبة على حدة.
• قابلية التدقيق. إذا تم إثبات أي تنفيذ ، فنحن نريد أن تكون البيانات الأساسية قابلة للاستخدام بحيث يمكن للمستخدمين والمطورين فحصها في حالة حدوث مشكلة. في الواقع ، يضيف هذا سببا آخر لأهمية متطلبات توفر البيانات.
• قابلية الترقية. إذا تم العثور على حل ZK-EVM به خطأ ، فنحن نريد أن نكون قادرين على إصلاحه بسرعة. هذا يعني أنه ليست هناك حاجة لإصلاح الهارد فورك. هذا يضيف إلى سبب وجود البراهين خارج EVM وهياكل بيانات الكتلة.
• يدعم تقريبا جميع EVMs. أحد عوامل الجذب في L2 هو الابتكار في طبقة التنفيذ وتوسيع نطاق EVM. إذا كان الجهاز الظاهري ل L2 معين مختلفا قليلا عن EVM ، فسيكون من الجيد أن يستمر L2 في استخدام ZK-EVM داخل البروتوكول الأصلي في نفس أجزاء EVM ، والاعتماد فقط على الكود الخاص به في أجزاء مختلفة. يمكن تحقيق ذلك من خلال تصميم وظيفة ZK-EVM التي تسمح للمتصل بتحديد حقول البت أو قوائم أو عناوين رمز التشغيل التي يتم التعامل معها بواسطة الجداول المتوفرة خارجيا بدلا من EVM نفسها. يمكننا أيضا جعل تكلفة الغاز مفتوحة للتحرير إلى حد ما.

أنظمة متعددة العملاء “مفتوحة” و “مغلقة”

ربما تكون “فلسفة العملاء المتعددين” هي المطلب الأكثر ذاتية في هذه القائمة. هناك خيار للتخلي عنها والتركيز على مخطط ZK-SNARK ، والذي سيبسط التصميم ، ولكن على حساب كونه “نقطة تحول فلسفية” أكبر ل ETH Workshop (لأنه يتخلى فعليا عن فلسفة ورشة العمل متعددة العملاء طويلة الأمد ETH) وإدخال مخاطر أكبر. في المستقبل ، عندما تصبح تقنية التحقق الرسمية أفضل ، قد يكون من الأفضل اختيار هذا المسار ، ولكن يبدو الآن أن الخطر كبير جدا.

خيار آخر هو نظام مغلق متعدد العملاء حيث تعرف مجموعة ثابتة من أنظمة التصديق في البروتوكول. على سبيل المثال ، قد نقرر استخدام ثلاثة ZK-EVM: PSE ZK-EVM و Polygon ZK-EVM و Kakarot. تتطلب الكتلة إثباتا يقدمه اثنان من هؤلاء الثلاثة ليكون صالحا. هذا أفضل من نظام إثبات واحد ، لكنه يجعل النظام أقل قابلية للتكيف لأنه يتعين على المستخدمين الاحتفاظ بمدققين لكل نظام إثبات موجود ، وستكون هناك حتما عمليات حوكمة سياسية لدمج أنظمة إثبات جديدة ، إلخ.

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

ما هي الخصائص الرئيسية التي نريد الحصول عليها من تطبيق ZK-EVM؟

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

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

كيف قد تبدو ميزة ZK-EVM داخل البروتوكول؟

على غرار معاملات EIP-4844 blob ، قدمنا نوعا جديدا من المعاملات يحتوي على مطالبات ZK-EVM:

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

في طبقة الإجماع، أضفنا قاعدة تحقق لا تقبل كتلة إلا إذا رأى العميل دليلا صالحا على كل مطالبة في الكتلة. يجب أن يكون الدليل ZK-SNARK ، يثبت أن تسلسل المعاملة _and_witness_blobs هو تسلسل زوج (كتلة ، شاهد) ، وأن الكتلة يتم تنفيذها مع pre_state_root على الشاهد

(i) صحيح، و

(ii) إخراج المنشور الصحيح _state_root. ربما ، يمكن للعميل اختيار انتظار أنواع متعددة من إثبات M-of-N.

من المهم أن نلاحظ هنا أن تنفيذ الكتلة نفسه يمكن اعتباره ببساطة أحد الثلاثيات التي يجب التحقق منها جنبا إلى جنب مع الثلاثيات المتوفرة في كائن ZKEVMClaimTransaction (σpre ، σpost ، Proof). نتيجة لذلك ، يمكن أن يحل تطبيق ZK-EVM الخاص بالمستخدم محل عميل التنفيذ الخاص به ؛ سيستمر تنفيذ عميل التنفيذ

(ط) البروفرز وبناة الكتل و:

و (ii) العقد التي تهتم بفهرسة البيانات وتخزينها للاستخدام المحلي.

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

التحقق وإعادة التصديق

لنفترض أن هناك عميلين ETH ، أحدهما يستخدم PSE ZK-EVM والآخر يستخدم Polygon ZK-EVM ، في هذه المرحلة ، تطور كلا التطبيقين إلى النقطة التي يمكنهما فيها إثبات تنفيذ كتلة ETH في أقل من 5 ثوان ، ولكل نظام إثبات ، هناك عدد كاف من المتطوعين المستقلين الذين يقومون بتشغيل الأجهزة لإنشاء البراهين.

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

لنفترض أن شخصا ما نشر ZKEvmClaimNetworkTransaction ، لكنه ينشر فقط دليلا على إصدار PSE ZK-EVM. ترى عقدة إثبات المضلع ZK-EVM هذا ، وتحسب الكائن وتعيد نشره ، جنبا إلى جنب مع إثبات المضلع ZK-EVM.

سيؤدي ذلك إلى زيادة إجمالي الحد الأقصى للتأخير بين أقدم عقدة صادقة تقبل كتلة وأحدث عقدة صادقة تقبل نفس الكتلة من δ إلى 2δ + Tprov (بافتراض Tprove<5s هنا).

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

التمديد: دعم “تقريبا EVMs”

الهدف المرغوب فيه لميزة ZK-EVM هو دعم “EVMs تقريبا”: EVMs مع ميزات إضافية. يمكن أن يشمل ذلك التجميع المسبق الجديد ، أو أكواد التشغيل الجديدة ، أو العقود التي يمكن أن تكون EVM أو أجهزة افتراضية مختلفة تماما (على سبيل المثال في Arbitrum Stylus) ، أو حتى العديد من EVMs المتوازية مع الاتصال المتبادل المتزامن.

يمكن دعم بعض التعديلات بطريقة بسيطة: يمكننا تحديد لغة تسمح ل ZKEVMClaimTransaction بتمرير الوصف الكامل لقاعدة EVM المعدلة. يمكن استخدام هذا في المواقف التالية:

1. جدول تكلفة الغاز المخصص (لا يسمح للمستخدمين بتقليل تكاليف الغاز ، لكن يمكنهم زيادتها)
2. تعطيل بعض رموز التشغيل
3. قم بتعيين رقم الكتلة (وهذا يعني أن هناك قواعد مختلفة اعتمادا على الهارد فورك)
4. قم بتعيين العلامة لتنشيط المجموعة الكاملة من تغييرات EVM التي تم توحيدها بالفعل ل L2 ولكن ليس لاستخدام L1 ، أو تغييرات أخرى أبسط

من أجل السماح للمستخدمين بإضافة وظائف جديدة بطريقة أكثر انفتاحا ، على سبيل المثال عن طريق تقديم مترجم مسبق جديد (أو رمز تشغيل) ، يمكننا إضافة طريقة لتضمين سجلات الإدخال / الإخراج المترجمة مسبقا في قسم blob في ZKEVMClaimNetworkTransaction:

فئة PrecompileInputOutputTran (حاوية): المستخدمة \ _precompile \ _addresses: قائمة[Address][VersionedHash]المدخلات_commitments: قائمة[Bytes]المخرجات: قائمة

سيتم تعديل تنفيذ EVM على النحو التالي. ستتم تهيئة صفيف يسمى المدخلات على أنه فارغ. عندما يتم استدعاء العنوان المستخدم \ _precompile \ _addresses ، نضيف كائن InputsRecord (callee \ _address ، Gas ، input \ _calldata) إلى المدخلات وتعيين RETURNDATA المسمى إلى المخرجات[i]。 أخيرا ، نتحقق من أن المستخدم \ _precompile \ _addresses كان يسمى len (outputs) إجمالي المرات ، وأن المدخلات \ _commitments تتطابق مع نتيجة التزام النقطة الناتجة بتسلسل SSZ للمدخلات. الغرض من كشف المدخلات_commitments هو تمكين SNARK الخارجي من إثبات العلاقة بين المدخلات والمخرجات.

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

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

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

يمكن دعم وظائف مثل Arbitrum Stylus عن طريق إعداد used_precompile_addresses لتضمين قائمة بعناوين الحسابات العادية مع تعيين علامة معينة في كائن حسابهم في الحالة ، وإنشاء SNARKs التي تثبت أنها مبنية بشكل صحيح ، حيث يمكن للعقد كتابة رمزه في EVM أو WASM (أو VM آخر). يمكن استخدام المعاملات المميزة للسماح لحسابات WASM بمعاودة الاتصال ب EVM.

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

يمكن أن يعمل ZK-EVM من النوع 4 من خلال وجود تطبيقات متعددة: واحد يحول Solidity أو لغة أخرى ذات مستوى أعلى مباشرة إلى VM صديق ل SNARK ، وآخر يقوم بتجميعها في كود EVM وينفذها في ZK-EVM المحدد. لا يمكن تشغيل التنفيذ الثاني (والأبطأ حتما) إلا إذا أرسل البروفير الفاشل معاملة تدعي وجود خطأ ، وإذا كان قادرا على عرض أن يتعامل الاثنان مع معاملات مختلفة ، فيمكن جمع المكافأة.

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

تمديد: دعم إثبات الدولة

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

بالإضافة إلى ذلك ، لا يطلب من EVMs ذات الحالة تقديم بيانات الشهود. في كلتا الحالتين ، المبدأ هو نفسه: إنه مضيعة لطلب إتاحة البيانات عندما نعلم بالفعل أن البيانات متاحة لأنه تم إدخالها أو إنتاجها من خلال تنفيذ سابق ل EVM. **

إذا أردنا جعل ميزة ZK-EVM ذات حالة ، فلدينا خياران:

يتطلب أن تكون σpre إما فارغة ، أو قائمة معلنة مسبقا بالمفاتيح والقيم التي تتوفر لها البيانات ، أو بعض σpost التي تم تنفيذها مسبقا.

أضف التزام blob إلى مجموعة (σpre ، σpost ، proof) للإيصال R الذي تم إنشاؤه بواسطة الكتلة. أي التزامات blob تم إنشاؤها أو استخدامها مسبقا والتي يمكن الرجوع إليها في ZKEVMClaimTransaction والوصول إليها أثناء تنفيذها ، بما في ذلك الالتزامات التي تمثل الكتل أو الشهود أو الإيصالات أو حتى معاملات EIP-4844 blob العادية (قد تكون هناك بعض الحدود الزمنية ، والتي يمكن الرجوع إليها من خلال سلسلة من التعليمات: “أدخل البايت N من الالتزام i في الموضع j من بيانات الكتلة + الشاهد … N+k-1”)

(1) المعنى الأساسي هو: بدلا من إنشاء التحقق من EVM عديم الجنسية ، سننشئ سلسلة أطفال EVM.

و (2) ينشئ بشكل أساسي الحد الأدنى من خوارزمية ضغط الحالة المضمنة التي تستخدم نقطة مستخدمة مسبقا أو تم إنشاؤها كقاموس. كلاهما يضع عبئا على عقدة prover ، وعقدة prover فقط لتخزين المزيد من المعلومات ؛

في الحالة (2) ، يكون من الأسهل تحديد هذا العبء زمنيا ، بينما في الحالة (1) يكون الأمر أكثر صعوبة.

الحجج للأنظمة المغلقة متعددة المحاور والبيانات خارج السلسلة

يتجنب النظام المغلق متعدد المحاور ، الذي يوجد فيه عدد ثابت من البراهين في هيكل M-of-N ، الكثير من التعقيد الموصوف أعلاه. على وجه الخصوص ، لا يحتاج نظام متعدد الشهادات المغلق إلى القلق بشأن ضمان وجود البيانات على السلسلة. بالإضافة إلى ذلك ، سيسمح نظام الاختبار المتعدد المغلق بتنفيذ إثباتات ZK-EVM خارج السلسلة ، مما يجعلها متوافقة مع حلول البلازما EVM.

ومع ذلك ، فإن الأنظمة المغلقة متعددة الشهادات تزيد من تعقيد الحوكمة وتضعف قابلية التدقيق ، وهي تكلفة عالية يجب موازنتها مقابل هذه المزايا.

إذا قمنا ببناء ZK-EVM وجعلناها ميزة بروتوكول ، فما هو الدور المستمر لمشروع L2؟

سيتم التعامل مع وظائف التحقق من صحة EVM التي يتم تنفيذها حاليا من قبل فريق L2 أنفسهم بواسطة البروتوكول ، لكن مشروع L2 سيظل مسؤولا عن عدد من الوظائف المهمة:

• تأكيد مسبق سريع: يمكن أن تؤدي نهائية الفتحة الواحدة إلى إبطاء فتحات L1 ، بينما يوفر L2 بالفعل للمستخدمين خدمة مدعومة بتأكيد مسبق مع أمانها الخاص ، مع زمن انتقال أقل بكثير من فتحة واحدة. ستظل هذه الخدمة مسؤولية L2 وحدها.
• استراتيجيات التخفيف من MEV: قد يشمل ذلك ميزات مثل mempools المشفرة ، والاختيار المتسلسل القائم على السمعة ، وما إلى ذلك ، والتي يتردد L1 في تنفيذها.
• امتدادات ل EVM: يمكن لمشاريع المستوى 2 تقديم امتدادات كبيرة إلى EVM توفر قيمة كبيرة لمستخدميها. وهذا يشمل “EVMs تقريبا” وأساليب مختلفة تماما ، مثل دعم WASM من Arbitrum Stylus ولغة القاهرة الصديقة ل SNARK.
• الراحة للمستخدمين والمطورين: تبذل فرق المستوى 2 الكثير من الجهد لجذب المستخدمين والمشاريع إلى نظامهم البيئي وجعلهم يشعرون بالترحيب ؛ يتقاضون رواتبهم من خلال التقاط رسوم MEV والازدحام داخل شبكتهم. هذه العلاقة موجودة لتبقى.