قد تكون قد لاحظت أن تقريبًا كل مطور يشارك ويعيد تغريد مراسم KZG، فما هي مراسم KZG؟

بعبارات بسيطة، فإن مراسم KZG هي إعداد الثقة لالتزام KZG الخاص بـ EIP-4844، و EIP-4844 هو الإصدار المسبق لتقسيم إيثريوم الكامل.

1. التقسيم: حل طويل الأمد لزيادة قدرة إيثريوم

  • بينما تعمل التجميعات على زيادة قدرة إيثريوم من طبقة التنفيذ، فإن التقسيم يُحسن من قابلية إيثريوم للتوسع وسعتها من منظور توفر البيانات.

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

  • اعتبارًا للأمان وتعقيد التنفيذ، يتم تقسيم التجزئة إلى عدة مراحل، وتشمل proto-danksharding وdanksharding. يمكن أن تستغرق العملية برمتها عدة سنوات.

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

2. EIP-4844: عائد قصير الأمد ملحوظ، وهو نسخة مبدئية (pre-release) للتجزئة الكاملة في Ethereum

EIP-4844 = Proto-Danksharding؛

بما أن التنفيذ الكامل للتجزئة ما زال معقدًا جدًا وقد يستغرق سنوات، فإن proto-danksharding هو أفضل خطة وسيطة لتخفيف ازدحام Ethereum على المدى القصير.

2.1 ملخص Proto-danksharding

يُدخل Proto-Danksharding نوع معاملة جديدًا يُسمى blob-carrying transaction. وبفضل هذا التحديث، يمكن للـ rollups استخدام “blob” لنقل البيانات إلى L1 وتخزينها مؤقتًا بتكلفة أقل نسبيًا. حجم الـ blob أكبر بكثير من calldata الحالي.

حول blob:

  • يمكن لكل معاملة حمل ما يصل إلى 2 blobs كحد أقصى

  • عادةً تحمل كل كتلة 8 blobs، بسعة 1MB لكل منها.

يمكن للكتلة حمل 16 blob، ما يؤدي إلى حجم كتلة يبلغ 2MB.

  • لا يتم تخزين الـ blob بشكل دائم كـ سجل تاريخي مثل calldata.

  • في تصميم proto-danksharding، لا تزال العقد بحاجة إلى تنزيل المحتوى الكامل للبيانات والتحقق من إتاحة البيانات.

2.2 blob-carrying transaction بتفصيل

الوظائف

وظيفة blob بيانات مشابهة لـ calldata، مما يسمح للـ rollup بنقل بيانات المعاملات والإثباتات إلى L1.

التكلفة

النية الأصلية من الـ blob هي دعم TPS مرتفع في الـ rollups. بالمقارنة مع calldata الذي يستخدم التخزين على السلسلة، فإن بيانات blob هذه يتم تنزيلها وتخزينها فقط لمدة زمنية. لذلك ستكون مصروفات الغاز لتأمين إتاحة البيانات للـ rollups أقل بشكل متوقع.

السعة

حجم كل blob هو 125 كيلوبايت.

2.3 قيمة وتحدي blob-carrying transaction

القيمة

من المؤكد أن ظهور الـ blobs يجعل بيانات المعاملات تصبح نوعًا من التخزين المؤقت (cache)، ما يقلل المزيد من متطلبات عتاد التخزين للعقد، ويخفض رسوم الغاز عبر تزويد Ethereum بقدرة تخزين بيانات إضافية.

التحدي: لنحسب متطلبات العتاد

والحقيقة أن حجم الكتلة الحالي يبلغ حوالي 90 كيلوبايت، لكن يمكن أن يصل حجم الـ blob إلى 125 كيلوبايت

وفقًا لتصميم EIP-4844، فإن حجم كل شريحة عادةً هو 1 ميجابايت، وهذا يعني أنه يمكن حساب إجمالي حجم البيانات كما يلي:

1 ميجابايت/كتلة * 5 كتل/دقيقة * 43200 دقيقة/شهر * 12 شهر/سنة = 2.47 تيرابايت سنويًا

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

ما الذي يمكن تحسينه؟

باختصار، في المدى القصير لا يزال كل عقدة بحاجة إلى تخزين المحتوى الكامل للبيانات التاريخية، لكن طبقة الإجماع مطبقة بآلية يتم فيها حذف بيانات الـ blob بعد فترة زمنية معينة (30 يومًا أو سنة واحدة، TBD).

للمصلحة طويلة الأمد، يجب تنفيذ EIP-4444، ما يشير إلى أنه لم تعد هناك حاجة لتخزين البيانات الكاملة. بدلًا من ذلك، تتم اعتماد آلية جديدة تسمح للعقد بتخزين أجزاء فقط من البيانات لمدة زمنية محددة، بالاستناد إلى ما يُعرف بخطة انتهاء صلاحية السجل (history expiry).

2.4 التزام KZG

التزام KZG هو مخطط التزام متعدد الحدود يعتمد في بروتوكول EIP-4844 proto-danksharding

مراسم KZG هي عملية إعداد الثقة الخاصة بالالتزام KZG، وهي تجذب أكثر من 30,000 مشارك.

2.4.1 ما هو التزام KZG

KZG اختصار لـ Aniket Kate وGregory M. Zaverucha وIan Goldberg، الذين نشروا ورقة الالتزام متعدد الحدود بعنوان “Constant-Size Commitments to Polynomials and Their Applications” في عام 2010. يُستخدم التزام KZG على نطاق واسع في بروتوكول zk-snark بنمط plonk.

بالاستناد إلى المخطط في عرض Dankrad، فإن جذر KZG مشابه لجذر Merkle، باستثناء أن جذر KZG يلتزم متعددة حدود، حيث تقع كل موضع على هذا المتعدد. وبناءً على سيناريو proto-danksharding، يلتزم جذر KZG بمجموعة بيانات، يمكن التحقق من كل نقطة بيانات ضمنها على أنها جزء من المجموعة الكاملة.

نظرة سريعة على كيفية عمل التزام KZG داخليًا

  • المرسل/المثبت (Prover): مسؤول عن حساب الالتزام. لأسباب تتعلق بالسلامة، لا يمكن للمرسل تعديل متعدد الحدود المعطى، ولا يكون الالتزام صالحًا إلا للمتعدد الحالي؛

  • المدقق (Verifier): مسؤول عن التحقق من الالتزام المُرسل من المرسل.

2.4.2 مراسم KZG (إعداد الثقة)

عملية مراسم KZG

يمكن للجميع الانضمام كمشارك في مراسم KZG والمساهمة بالسر. سيتم خلط السر المضاف حديثًا مع الناتج السابق لتكوين نتيجة جديدة، وأخيرًا يتم توليد SRS لإعداد ثقة الالتزام KZG. (راجع المخطط المرفق من Vitalik لفهم أفضل)

إعداد الثقة

  • مراسم KZG هي إعداد ثقة متعدد المشاركين مستخدم على نطاق واسع يُسمى power-of-tau؛

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

أهمية مراسم KZG

  • يمكن تفسير قيمة إعداد الثقة للالتزام KZG كما يلي: لتوليد معامل ضروري لكل تنفيذ منفصل للبروتوكول التشفيري

  • عندما يقوم المرسل بحساب الالتزام، يكون التزام KZG C = f(s)g1، حيث f هي دالة التقييم، وs هي النتيجة النهائية لإعداد ثقة KZG. لذلك فإن السر النهائي الناتج عن مراسم KZG الحالية يعد أمرًا حاسمًا للتنفيذ اللاحق للتجزئة (sharding).

2.4.3 ميزة التزام KZG

  • التكلفة

  • يمتلك التزام KZG تعقيدًا أقل ويمكن التحقق منه بكفاءة.

  • لا يلزم إثبات إضافي، مما يؤدي إلى تكلفة أقل ويقلل متطلبات عرض النطاق الترددي.

  • تكلفة أقل أيضًا بالاستفادة من نقطة التقييم precompile.

  • الأمان

  • إذا حدث فشل، فإن الأمر يؤثر فقط على الـ blob المقابلة للالتزام الحالي، ولا يوجد أي أثر متسلسل إضافي.

  • التوافق

  • يتوافق التزام KZG بشكل أفضل مع DAS، ما يتجنب التكرار في التطوير.

2.5 فائدة EIP-4844

التجميع (Rollup)

كما هو موضح في الصورة أدناه، يحتاج الـ rollup إلى تقديم فرق الحالة (state delta) وهاش KZG المُؤطر بالإصدار (versioned hash) عبر calldata (ولا يزال zk-rollup يحتاج إلى رفع zkp).

بعد تنفيذ EIP-4844، لن يحمل calldata المكلف إلا بيانات صغيرة مثل state delta والالتزامات، بينما توضع البيانات الكبيرة مثل حزمة المعاملات (transaction batch) في الـ blob.

  • تقليل التكلفة;

  • تقليل استخدام مساحة تخزين الكتل.

تحسين الأمان

  • إتاحة البيانات: يتم تخزين الـ blob في سلسلة الإشارات (beacon chain)، والتي تشارك نفس مستوى الأمان مع Ethereum L1.

  • البيانات التاريخية: تقوم العقد فقط بتخزين الـ blobs لمدة زمنية محددة، بينما يكون rollup في الطبقة 2 مسؤولًا عن التخزين الدائم للبيانات، ما يعني أن أمان البيانات التاريخية يعتمد على الـ rollup.

التكلفة

يمكن لميزة انخفاض تكلفة معاملة تحمل الـ blob تحسين التكلفة الإجمالية بمقدار من x10 إلى x50.

وفي الوقت نفسه، يقدم EIP-4844 رسومًا خاصة بالـ blob.

  • سيكون للغاز والـ blob أسعار وحدود غاز قابلة للتعديل بشكل منفصل؛

  • وحدة سعر الـ blob هي الغاز، وستتذبذب كمية الغاز وفقًا لحركة الشبكة، بهدف الحفاظ على العدد الذي يحمل كل كتلة (8 في المتوسط).

تنفيذ precompile

يمكن لتنفيذ EVM أن يرى فقط الالتزام الخاص بـ blob الذي يُنشئه المرسل (prover)، ولا يمكنه الوصول إلى بيانات الـ blob مباشرة. لذلك يحتاج الـ rollup إلى استخدام آلية precompile للتحقق من صحة الالتزام.

هناك خوارزميتان precompile مذكورتان في EIP-4844

  • precompile لتقييم النقطة

  • إثبات أن عدة التزامات (commitments) ملتزمة بنفس مجموعة البيانات.

  • يتم اعتماد precompile لتقييم النقطة بشكل أساسي بواسطة zk-rollup، ويحتاج الـ rollup إلى توفير التزامين: التزام KZG والتزام zk-rollup.

  • أما بالنسبة للـ optimistic rollup، فقد تبنّت معظمها إثباتات احتيال متعددة الجولات (multi-round fraud-proof)، والجولة الأخيرة من إثبات الاحتيال تحتفظ بحجم بيانات أصغر، مما يعني أنها يمكنها أيضًا استخدام precompile لتقييم النقطة بتكلفة أقل.

  • precompile للتحقق من الـ blob

  • إثبات أن الـ versioned hash صالح بالنسبة للـ blob المقابلة

  • يحتاج optimistic rollup إلى الوصول إلى البيانات الكاملة عند تقديم إثبات الاحتيال، لذا من المنطقي التحقق من صحة الـ versioned hash ثم التحقق من إثبات الاحتيال.

3. Danksharding: خطوة حاسمة نحو التجزئة الكاملة

التوسع

فضلًا عن تصميم نوع المعاملات الجديد في proto-danksharding الذي يقدم blob للبيانات، تحصل كل كتلة الآن على ذاكرة تخزين مؤقت إضافية قدرها 1MB. سيزداد هذا الرقم بمقدار 16 إلى 32 مرة بعد تنفيذ danksharding.

إتاحة البيانات: تخزين بيانات والتحقق عالي الأداء

مقارنة بـ proto-danksharding، حيث يُطلب من العقد تخزين المحتوى الكامل للبيانات التاريخية، تسمح danksharding للعقد بتخزين البيانات فقط بعد أخذ عينات.

DAS

استفادةً من تقنية ترميز الحذف (erasure coding)، تجعل مقترحات danksharding من السهل (أن كل عقدة تحتاج فقط لتنزيل أجزاء من البيانات) على العقد اكتشاف فقد البيانات.

الأمان: شبه مطابق

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

على الرغم من أن مخطط الاعتماد بنقطة واحدة أكثر أمانًا من الاعتماد متعدد النقاط، إلا أن عدد العقد في شبكة Ethereum أكبر بكثير بما يكفي لتحقيق هدف ضمان إتاحة البيانات.

تحدٍ جديد: متطلبات أعلى لبنّائي الكتل

في حين أن المدققين (validators) لا يقومون إلا بتنزيل وتخزين أجزاء من البيانات الكاملة، لا يزال من الضروري على بنّاء الكتلة رفع المحتوى الكامل للبيانات وهو الـ blob الذي يحتوي على جميع بيانات المعاملات.

وفقًا للمخطط من شرائح Dankrad، يمكننا رؤية كيف يساعد PBS (فصل المُقترح/البنّاء proposer/builder separation)، المصمم أصلاً لمكافحة MEV، في تقليل متطلبات عرض النطاق الترددي أثناء بناء الكتل.

4. مخطط تجزئة آخر: التجزئة الديناميكية للحالة من Shardeum

Shardeum هو بلوك تشين من المستوى الأول متوافق مع EVM، يستخدم التجزئة الديناميكية للحالة لتحسين قابلية التوسع والأمان. وفي الوقت نفسه، يمكن لشبكة shardeum ضمان مستوى أعلى من اللامركزية.

التجزئة الديناميكية للحالة

المزايا

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

التنفيذ

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

الملخص

المنتج

بالاستناد إلى فكرة “فرق تسد” (divide and conquer)، تقسم التجزئة الديناميكية للحالة في Shardeum عبء العمل الخاص بالحساب والتخزين، ما يسمح بمستوى أعلى من التوازي. لذلك تستطيع الشبكة استيعاب عدد أكبر من العقد، مما يحسن المزيد من الإنتاجية ومستوى اللامركزية.

الفريق

يتمتع فريق Shardeum بخبرة قوية في التسويق والقدرة على صياغة السرد. كما لديهم فهم عميق لتفاصيل التقنية، خصوصًا التجزئة الديناميكية للحالة.

التكنولوجيا

يمكن لفريق التقنية تصميم مخطط تجزئة مناسب وخوارزمية إجماع فعّالة (Proof of Stake + Proof of Quorum) بناءً على فهمهم للسيناريو، بحيث يجعل التوسع والإنتاجية في المقام الأول ويضمن الأمان ومستوى اللامركزية قدر الإمكان.

التقدم

تم إطلاق Betanet في 2023–02–02.

5. النظرة المستقبلية

  • التجزئة هي حل طويل الأمد للتوسع في Ethereum، ولها قيمة كبيرة وأهمية عميقة للشبكة بأكملها. ليس جيدًا أن نوليها اهتمامًا قليلًا، لأن تنفيذ التجزئة عملية من التكرار (iteration). يمكن ترقية/تعديل جميع المقترحات الحالية، بما فيها proto-danksharding وdanksharding.

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

  • من المهم معرفة أن التجزئة مصطلح عام يصف مجموعة من تقنيات التوسع، وهناك مخططات تطبيق مختلفة بحسب سيناريوهات محددة. على سبيل المثال، قد يناسب تصميم danksharding Ethereum فقط، وقد يؤدي إلى تأثير سلبي إذا طُبق على سلاسل L1 أخرى، لأن الأمان يحتاج إلى ضمانه بكمية ضخمة من العقد في الشبكة.

  • يمكن لمزيج عقلاني بين التجزئة وحلول التوسع الأخرى أن يحقق تأثيرًا مضاعفًا. لن يعمل مقترح danksharding الحالي وحده؛ بدلًا من ذلك، تكمل الـ rollups وdanksharding بعضها البعض لتحسين قابلية توسع Ethereum وسعته بشكل أفضل.

المراجع

https://notes.ethereum.org/@dankrad/kzg_commitments_in_proofs

https://notes.ethereum.org/@dankrad/new_sharding

https://vitalik.ca/general/2022/03/14/trustedsetup.html

https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Why-use-the-hash-of-the-KZG-instead-of-the-KZG-directly

https://ethresear.ch/t/easy-proof-of-equivalence-between-multiple-polynomial-commitment-schemes-to-the-same-data/8188

https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html

https://eips.ethereum.org/EIPS/eip-4844

https://www.eip4844.com/

https://biquanlibai.notion.site/Data-Availability-caa896aae59d489b98f2448f17b01640

https://ethresear.ch/t/a-design-of-decentralized-zk-rollups-based-on-eip-4844/12434

حول Foresight Ventures

تكرّس Foresight Ventures لدعم الابتكار الثوري في بلوكتشين على مدار العقود القليلة القادمة. نحن ندير عدة صناديق: صندوق VC، وصندوق ثانوي مُدار بنشاط، وFOF متعدد الاستراتيجيات، وصندوق سوق ثانوي خاص، بإجمالي أصول مُدارة (AUM) يتجاوز 400 مليون دولار. تلتزم Foresight Ventures بمعتقد “Unique, Independent, Aggressive, Long-Term mindset” وتقدم دعمًا واسعًا لشركات محفظتها ضمن منظومة نامية. يتكون فريقنا من مخضرمين من شركات مالية وتقنية رائدة مثل Sequoia Capital وCICC وGoogle وBitmain وغيرها الكثير.

الموقع: https://www.foresightventures.com/

تويتر: https://twitter.com/ForesightVen

Medium: https://foresightventures.medium.com

Substack: https://foresightventures.substack.com

Discord: https://discord.com/invite/maEG3hRdE3

Linktree: https://linktr.ee/foresightventures