Loading...
في استطلاع حاملي العملات NU7 الذي أُغلق في 14 سبتمبر 2026، صوّت نحو 2,397,669 ZEC لصالح ZIP 218، فيما صوّت 141.6 ZEC ضده، بنسبة 99.9%. لخّصت معظم التغطيات الأمر بعبارة: «تصبح كتل Zcash أسرع». وهذا صحيح، لكنه يستثني معظم ما يفعله الاقتراح ومعظم ما يُبقيه عمداً دون تغيير.
تشرح هذه الصفحة ZIP 218 اعتماداً على نصه نفسه: ما الذي يتغير، وما الذي لا يتغير، وما تكلفته.
| اليوم | بعد ZIP 218 | |
|---|---|---|
| التباعد الزمني المستهدف للكتل | 75 ثانية | 25 ثانية |
| الكتل يومياً | 1,152 | 3,456 |
| دعم الكتلة (في حقبة التنصيف الحالية) | 1.5625 ZEC | 0.52083333 ZEC |
| ZEC الجديدة يومياً | دون تغيير | دون تغيير |
| فترة التنصيف | 1,680,000 كتلة | 5,040,000 كتلة |
| الحدود على الإجراءات المحمية لكل كتلة | لا توجد (فقط حد الحجم البالغ 2 MB) | 330 إجمالاً، مع حدود لكل مجمع |
| إنتاجية Orchard (معاملات ذات إجراءين) | نحو 2.9 في الثانية | نحو 6.6 في الثانية |
ثلاثة أضعاف عدد الكتل، مع دفع ثلث المبلغ لكل منها. ويبقى جدول المعروض كما هو.
الهدف الرئيسي هو خفض وقت الانتظار. اليوم، تنتظر الدفعة 75 ثانية في المتوسط لتأكيدها الأول، مهما كان حمل الشبكة. وعند 25 ثانية، ينخفض ذلك إلى 25 ثانية في المتوسط. يسمي ZIP المدفوعات في نقاط البيع، وإيداعات المنصات، والجسور عبر السلاسل كاستخدامات تشعر بهذا أكثر من غيرها.
هناك نقطتان في ZIP جديرتان بالتذكر:
يشير ZIP أيضاً إلى أنه كان يمكن تحقيق إنتاجية أعلى وحدها من خلال حجم كتلة أكبر. أما تقليل زمن الاستجابة فهو سبب اختيار الكتل الأقصر بدلاً من ذلك.
إن مضاعفة عدد الكتل ثلاث مرات ستضاعف الإصدار اليومي ثلاث مرات لو لم يتغير شيء آخر. ويمنع ZIP 218 ذلك بقسمة دعم كل كتلة على عامل إضافي قدره ثلاثة بمجرد تفعيل NU7.
في حقبة التنصيف الحالية، ينخفض دعم الكتلة بذلك من 1.5625 ZEC إلى 0.52083333 ZEC (52,083,333 zatoshi). ولأن 156,250,000 zatoshi لا تقبل القسمة بالتساوي على ثلاثة، يُقرّب كل دعم كتلة نزولاً بمقدار ثلث zatoshi. وعلى امتداد فترة تنصيف كاملة من 5,040,000 كتلة، يبلغ ذلك نحو 0.0168 ZEC إجمالاً.
الدعم هو إجمالي ZEC الجديدة المُنشأة لكل كتلة. وتُقتطع منه حصة التمويل التطويري القائمة كما هي، لذلك يتلقى المعدّنون أقل من الرقم الكامل، تماماً كما اليوم.
ملاحظة بشأن رقم 0.26041666 ZEC. تطبع الملاحظة التفسيرية في مسودة ZIP دعم ما بعد NU7 على أنه floor(156250000 / 6) = 0.26041666 ZEC، وكررت بعض التغطيات الإخبارية ذلك. هذه الملاحظة خاطئة بعامل اثنين: إذ إن 156,250,000 zatoshi هو بالفعل دعم ما بعد Blossom، ولذلك فإن قسمته على ستة تطبق عامل Blossom البالغ اثنين مرة ثانية فوق عامل NU7 البالغ ثلاثة. وتعطي الصيغة المعيارية floor(1,250,000,000 / (2 · 3 · 4)) = 52,083,333 zatoshi عند مؤشر التنصيف الحالي. تسجل مسألة التنفيذ في Zebra الخاصة بهذا التغيير (#11463) أن الملاحظة احتسبت عامل Blossom مرتين، وتطلب من المنفذين «تنفيذ الصيغة، لا الملاحظة»، وتقول إن تصحيحاً قُدّم بشأن ZIP. الرقم الصحيح عند التفعيل هو 0.52083333 ZEC.
تتضاعف فترة التنصيف ثلاث مرات من 1,680,000 كتلة إلى 5,040,000 كتلة. ولأن الكتل تصل ثلاث مرات بوتيرة أسرع، تظل عمليات التنصيف تحدث تقريباً في نفس النقطة الزمنية التي كانت ستحدث فيها من دون التغيير. ولا يتأثر الحد الأقصى لإجمالي المعروض.
وهذا منفصل عن سؤال الإصدار الآخر في استطلاع NU7، حيث صوّت حاملو العملات للإبقاء على عمليات التنصيف بدلاً من استبدالها بمنحنى مُنعّم. يعمل ZIP 218 مع نموذج التنصيف القائم ولا يغيره.
يضيف ZIP 218 حدوداً لكمية النشاط المحمي التي يمكن أن تحتويها كتلة واحدة:
| الحد | الحد الأقصى لكل كتلة |
|---|---|
| جميع المجمعات المحمية مجتمعة | 330 (كل JoinSplit في Sprout يُحتسب كإجرائين) |
| إجراءات Orchard | 330 |
| مدخلات Sapling ومخرجاتها | 300 |
| JoinSplits في Sprout | 25 |
لا تتأثر الأجزاء الشفافة من المعاملات، ويستمر تطبيق حد حجم الكتلة البالغ 2 MB.
توجد هذه الحدود لأن زيادة عدد الكتل كانت ستعني، لولا ذلك، مزيداً من العمل للمحافظ والعقد. ومع وجود الحدود، تصبح الحالة الأسوأ أفضل فعلياً من اليوم، رغم ثلاثة أضعاف عدد الكتل:
إن حدود Sapling وSprout مشددة عن قصد. ففي مايو 2026، احتوى Orchard على 87.9% من ZEC المحمية، وSapling على 11.6%، وSprout على 0.5%، لذا تحصل المجمعات الأصغر على مساحة كافية لاستخدامها الفعلي مع منح المهاجم مجالاً أقل للإساءة. ولأن رسوم ZIP 317 تفرض الرسوم نفسها لكل إجراء منطقي في كل مجمع، فلا يكسب المهاجم شيئاً من إغراق مجمع واحد بدلاً من آخر.
مع 330 إجراء Orchard لكل كتلة، تتسع المعاملة القياسية ذات الإجراءين Orchard لعدد ⌊330 / 2⌋ = 165 مرة في الكتلة. وعند كتلة كل 25 ثانية، يساوي ذلك نحو 6.6 معاملة في الثانية، ارتفاعاً من نحو 2.9 اليوم — ويصف ZIP ذلك بأنه زيادة قدرها 2.3× في إنتاجية Orchard العادية. وتبلغ Sapling نحو 3.0 في الثانية، ولا تزال أعلى مما تديره Orchard اليوم.
تُحسب خوارزمية الصعوبة كمعدل على نافذة من الكتل الحديثة. ويرفع ZIP 218 تلك النافذة من 17 كتلة إلى 102، بحيث تظل تغطي نحو 2,550 ثانية من الزمن الحقيقي، وهي نفس المدة التي غطتها عندما أُطلق Zcash بكتل مدتها 150 ثانية. ويقدم ZIP سببين: تجنب جعل هجمات التلاعب بالصعوبة أسهل (إذ يستشهد بحادثة MWEB في Litecoin في أبريل 2026)، وتنعيم التغيرات القصيرة الأجل في أزمنة الكتل.
مباشرة بعد التفعيل، ستحتاج أزمنة الكتل إلى بعض الوقت للاستقرار عند الهدف الجديد. وهذا متوقع ويشابه ما حدث عند Blossom، حين انتقل Zcash من 150 إلى 75 ثانية.
هذه توصيات للمنفذين وليست قواعد إجماع:
الكتل الأسرع ليست مجانية. الكتلة القديمة هي كتلة صالحة تخسر السباق إلى الإدراج في السلسلة لأن كتلة أخرى وصلت إلى الشبكة أولاً. وكلما قصرت الفجوة بين الكتل، تكرر ذلك أكثر، ويربط ZIP معدل الكتل القديمة بانتشار الكتل، ووقت التحقق، ومخاطر تمركز التعدين.
هناك تكلفتان أصغر أيضاً. تنزّل المحافظ الخفيفة نحو 200 KB إضافية يومياً من رؤوس الكتل المدمجة. ولأن عدد الكتل ثلاثة أضعاف، فإن العقدة الكاملة التي كانت غير متصلة تحتاج إلى معالجة كتل أكثر عند اللحاق بالشبكة، رغم أن التحقق من كل كتلة أرخص. ويقبل ZIP كليهما.