كيف تعمل سلاسل ADI Chain L3 المتوافقة؟ نماذج النشر وآلية التسوية

آخر تحديث 2026-07-22 03:21:01
مدة القراءة: 9m
سلاسل ADI Chain L3 المتوافقة هي رول أبس ZK من الطبقة الثالثة تُصفّى على ADI L2، والتي بدورها تُصفّى على Ethereum L1، لتشكّل سلسلة إثبات صلاحية L3→L2→L1. كل L3 لديها Sequencer وProver وDiamond Proxy contract خاص بها، مع مشاركة Bridgehub وStateTransitionManager؛ تُصفّى الدُفعات على L2 من خلال Commit وProve وExecute، وتنتقل النتيجة النهائية إلى الأعلى عبر المكدس.

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

بالنسبة للحكومات والبنوك واتحادات الصناعة، توفر L3 مفهوم "نظام بيئي واحد، قواعد متعددة": حيث تتداول الأصول المنظمة على سلاسل مخصصة، وتعمل التطبيقات المفتوحة على L3 آخر أو على L2، وتتكامل كل الطبقات عبر تمويل مرحلي على L2.

موقع L3 في بنية الطبقات لـADI Chain

تعتمد ADI Chain تسلسل تصفية ثلاثي المستويات L3→L2→L1. تنفذ سلاسل L3 المعاملات محليًا وتحافظ على حالة مستقلة؛ وتتحقق L2 (ADI Chain) من صحة دفعات L3 وتخزن جذور الحالة؛ وتتحقق L1 (Ethereum) من دفعات L2 وتُنهى الحالة النهائية. تنتقل الحماية الأمنية عبر الطبقات من خلال إثباتات صحة بمعرفة صفرية، مما يمنع قبول انتقالات حالة غير صالحة في طبقة أعلى.

على عكس نشر التطبيقات اللامركزية مباشرة على L2، توفر L3 عزلاً فعليًا على مستوى التنفيذ: حيث يمتلك كل L3 متسلسلاً ومثبتًا وعقد Diamond Proxy خاص به، مع حالات لا تتداخل. يمكن نشر عدة سلاسل L3 ضمن نفس النظام البيئي، مع مشاركة عقود البنية التحتية مثل Bridgehub (سجل السلاسل) وStateTransitionManager (STM). تبلغ قدرة ADI L2 حوالي 2,000–10,000 معاملة في الثانية (TPS)، ويمكن زيادة السعة بشكل أكبر بإضافة سلاسل L3 متعددة بحسب التطبيق أو الولاية القضائية.

الطبقة موقع التنفيذ هدف تقديم الإثبات زمن التأكيد المعتاد
سلسلة L3 متسلسل محلي L3 ADI Chain (L2) ثوانٍ (تأكيد مبدئي)
ADI Chain (L2) متسلسل L2 شبكة Ethereum الرئيسية (L1) دقائق (تأكيد L2)
Ethereum (L1) عقود المُحقِّق إنهاء جذر الحالة ساعات (نهائية L1)

يوضح الجدول أن L3 ليست سلسلة عامة مستقلة، بل مجال تنفيذ قابل للتخصيص ضمن ADI L2 وEthereum L1. ترث ADI L2، كرول أب بمعرفة صفرية، أمان Ethereum الاقتصادي؛ بينما تضيف L3 طبقة امتثال مؤسسي إضافية.

بنية الطبقات لسلسلة ADI Chain L3 من L3 إلى L2 إلى Ethereum L1 الشكل 1. موضع سلاسل ADI Chain L3 المتوافقة في بنية الطبقات L3→L2→L1 والعلاقة بين المكونات الأساسية.

المكونات الأساسية لنظام L3 البيئي

ينشر نظام L3 البيئي بنية تحتية مشتركة على طبقة التصفية L2، بالإضافة إلى عقود خاصة بالسلسلة وعُقد تشغيلية على كل L3. يعمل Bridgehub كسجل مركزي، يدير ربط معرف السلسلة بعناوين العقود، وتوجيه الرسائل عبر السلاسل، وتكوين النظام البيئي. يدير StateTransitionManager تسجيل السلاسل الجديدة، وترقيات البروتوكول، وإدارة معلمات التحقق المشتركة. كل سلسلة L3 مزودة بعقد Diamond Proxy يستخدم نمط Facet للترقيات المعيارية، ويتولى إرسال الدفعات والتحقق منها وتخزين جذر الحالة وإدارة المدققين.

على مستوى العمليات في L3، تشغل كل سلسلة متسلسلاً ومثبتًا ومجموعة محافظ تشغيلية (تتولى الالتزام، الإثبات، والتنفيذ). في L2، يقوم مثبت L2 بتجميع المعاملات الأصلية لـL2 وتسويات L3 في إثباتات تُرسل إلى L1. يفرض Validator Timelock تأخيرًا بين الالتزام والتنفيذ، ما يمنح فرصة لاكتشاف الشذوذات.

يتيح تصميم Diamond Proxy Facet ترقية منطق التنفيذ والاستعلام والإدارة بشكل مستقل. ويُعد الجمع بين بنية التسجيل المشتركة على L2 مع حالة التنفيذ المعزولة على كل L3 سمة رئيسية تميز ADI Chain عن نموذج L2 التقليدي "سلسلة واحدة، تطبيقات متعددة". في مقارنة ADI Chain مع Arbitrum وBase، يُعد دعم L3 الأصلي ونموذج Bridgehub من أبرز الفروقات.

نماذج النشر الثلاثة لسلاسل L3

تدعم ADI Chain L3 نماذج بنية تحتية مُدارة من ADI أو مشغلة من العميل أو هجينة، لتلبية احتياجات المؤسسات من التشغيل الصفري إلى التحكم الكامل.

النموذج المتسلسل المثبت مفاتيح العقود الأفضل لـ
مُدار من ADI تديره ADI إثباتات تُنشئها ADI ADI تحتفظ بمفاتيح الحوكمة والتشغيل المؤسسات التي تبحث عن نشر جاهز دون عبء البنية التحتية
مشغل من العميل العميل يشغل العقد العميل يشغل عُقد إثبات GPU المفاتيح تُنقل لمحافظ العميل المؤسسات التي تحتاج تحكمًا كاملاً في العمليات وملكية البيانات
هجين العميل أو ADI (قابل للتكوين) العميل أو ADI (قابل للتكوين) الحوكمة للعميل؛ العمليات يمكن تفويضها لـADI المؤسسات التي ترغب بتحكم ذاتي في الحوكمة مع إمكانية الاستعانة بعمليات خارجية

يتم نشر العقود باستخدام تحكم بالوصول قائم على الأدوار: يتولى الحاكم ترقيات البروتوكول، والمدير الإجراءات الطارئة، والمشغل تنفيذ الالتزام الدفعي، ومُثبِّت الإثباتات، ومشغل التنفيذ تنفيذ الدفعات المُثبتة. يمكن نقل الملكية بالكامل إلى محفظة متعددة التوقيعات للعميل أو تسليمها تدريجيًا. يتبع نظام L3 البيئي نهج "نشر مرة واحدة، إضافة السلاسل تدريجيًا": يتم نشر Bridgehub وSTM مرة واحدة على مستوى النظام البيئي، وتنضم سلاسل L3 الجديدة كعقود مستقلة.

في وضع التشغيل من العميل، يتطلب المُثبِّت وحدات معالجة رسومية NVIDIA H100 أو H200 (ذاكرة 70–140 جيجابايت) وذاكرة نظام 64 جيجابايت أو أكثر؛ بينما يتطلب المتسلسل 8 أنوية CPU على الأقل و32 جيجابايت RAM ونقطة نهاية معاملات عامة. يجب أن تحتوي محافظ المشغلين على رموز $ADI كرسوم L2 للعمليات على السلسلة عبر الالتزام، الإثبات، والتنفيذ.

تدفق التصفية Commit-Prove-Execute

عند تصفية دفعات L3 إلى L2، تمر بمراحل الالتزام، الإثبات، والتنفيذ. يقوم المتسلسل بتجميع معاملات L3 في دفعات؛ ويقدم المشغل معاملة الالتزام إلى L2 حاملة فروق الحالة (تغييرات خانات التخزين)، ومعلومات نشر العقود، وتجميع تجزئات الرسائل L2→L3، وليس لقطات الحالة الكاملة، ما يقلل من تكلفة البيانات.

في مرحلة الإثبات، يُولد المثبت إثبات صحة باستخدام نظام Airbender (FRI/STARK → FFLONK SNARK)، ما يضمن تشفيريًا أن انتقالات الحالة تتوافق مع قواعد تنفيذ L3. في مرحلة التنفيذ، وبعد تحقق L2 من الإثبات، يُسجل جذر الحالة الجديد لـL3 في عقد سلسلة Diamond Proxy وتُعتبر الدفعة نهائية.

المرحلة المشغل المحتوى المقدم نتيجة L2
الالتزام المشغل فروق الحالة، معلومات النشر، تجزئات الرسائل بيانات الدفعة على السلسلة، بانتظار الإثبات
الإثبات مُثبِّت الإثبات إثبات صحة بمعرفة صفرية إثبات تم التحقق منه بعقد المُحقِّق
التنفيذ مشغل التنفيذ تنفيذ الدفعة المُثبتة تحديث جذر حالة L3، إنهاء الدفعة

تستهلك دورة التصفية الكاملة تقريبًا 747,000 Gas إجمالاً (الالتزام ~136,000، الإثبات ~494,000، التنفيذ ~117,000)، مع دفع كل مرحلة من محافظ المشغلين بـ$ADI. في بيئة الإنتاج، يمكن تشغيل مُثبِّتي FRI وSNARK بالتوازي على أقسام GPU منفصلة، مما يحسّن إنتاجية الدفعات بنسبة تقريبية %15–%20؛ يدعم مُثبِّت واحد في التكوين المستهدف حوالي 15–20 معاملة في الثانية.

تدفق تصفية Commit Prove Execute لسلسلة ADI Chain L3 مع Airbender prover الشكل 2. التدفق من تجميع المعاملات حتى الالتزام والإثبات والتنفيذ على L2 لدفعة L3.

التكوين الموصى به للمُثبِّت هو NVIDIA H200 (ذاكرة 140 جيجابايت)، مع 2 مُثبِّت FRI متوازي و1 مُثبِّت SNARK مخصص (~33 جيجابايت VRAM). يجب على المؤسسات في وضع التشغيل من العميل التخطيط لمجموعات GPU واتصالات L2 RPC منخفضة الكمون مسبقًا للحفاظ على وتيرة إرسال الدفعات.

انتقال النهائية من L3 إلى Ethereum

تتطور أنواع تأكيد معاملات L3 على طول سلسلة L3→L2→L1 مع تقدم التصفية. بعد أن يدرج متسلسل L3 معاملة في كتلة، يحصل المستخدمون على تأكيد مبدئي في ثوانٍ ويمكنهم استخدام الأصول فورًا؛ ويعتمد هذا التأكيد على أمانة المتسلسل ولا يمنح نهائية تشفيرية بعد.

عند التزام دفعة L3 إلى L2، تدخل مرحلة تأكيد L2 (عادة دقائق). بعد اكتمال الإثبات والتنفيذ على L2، يُكتب جذر حالة L3 في عقد سلسلة L2 ولا يمكن التراجع عنه. ثم يثبت مُثبِّت L2 حالة L2، بما في ذلك تسويات L3، إلى Ethereum L1؛ وبعد تأكيد عقود المُحقِّق على L1، تصل السلسلة إلى نهائية L1 (عادة ساعات).

ينصح بالانتظار لتأكيد L2 أو L1 في التسويات الكبيرة أو السحوبات عبر السلاسل؛ بينما يمكن الاعتماد على التأكيد المبدئي في التفاعلات اليومية. يقدم Validator Timelock تأخيرًا قابلًا للتهيئة بين الالتزام والتنفيذ، ما يمنح فرصة لاكتشاف الشذوذات.

حالات استخدام سلاسل L3 المتوافقة

تتناسب L3 مع منطق "عزل القواعد، أمان مشترك": حيث تدير البنوك سكك عملات مستقرة سيادية، ويطلق مديرو الأصول عقود أصول العالم الحقيقي (RWA) بوصول مقيد بالتحقق من الهوية (KYC)، ويمكن للحكومات ترميز البيانات حسب الولاية القضائية. في النشر المشغل من العميل، يتحمل العميل مسؤولية مجموعات GPU وقوائم RPC البيضاء؛ بينما في النشر المُدار من ADI، تنتقل العمليات إلى ADI.

الملخص

تعتمد سلاسل ADI Chain L3 المتوافقة بنية رول أب ZK ثلاثية الطبقات L3→L2→L1، ما يمنح المؤسسات أمان Ethereum مع مجالات تنفيذ مستقلة وقواعد امتثال مخصصة حسب الولاية. يوفر Bridgehub وStateTransitionManager بنية تحتية مشتركة للتسجيل والترقيات؛ وتحافظ كل L3 على عزل الحالة عبر Diamond Proxy ومتسلسل ومثبت مستقلين. تتم تصفية الدفعات على L2 عبر الالتزام، الإثبات، والتنفيذ؛ يدعم نظام الإثبات Airbender وبنية GPU (H100/H200) توليد إثباتات الصحة؛ وتنتقل النهائية من تأكيد مبدئي في L3 إلى نهائية تشفيرية في L2 وL1. تدعم ثلاثة نماذج نشر احتياجات التشغيل والحوكمة المختلفة، لتناسب العملات المستقرة السيادية، أصول العالم الحقيقي، المدفوعات عبر الحدود، وترميز بيانات الحكومات.

الأسئلة الشائعة

ما هي L3 على ADI Chain؟

L3 هي رول أب من الطبقة الثالثة بمعرفة صفرية تُصفى على ADI Chain (L2)، ما يتيح للمؤسسات أو الحكومات أو اتحادات الصناعة تشغيل سلاسل مستقلة حسب الولاية القضائية مع سياسات امتثال مخصصة. لكل L3 متسلسل ومثبت وعقد Diamond Proxy خاص بها، وترث أمان ثنائي الطبقات عبر L2 وEthereum، وتشارك بنية Bridgehub للتسجيل مع سلاسل L3 الأخرى في النظام البيئي.

ما العلاقة بين ADI Chain وEthereum؟

تعمل ADI Chain كرول أب L2 بمعرفة صفرية على Ethereum؛ تتطلب انتقالات حالة دفعات L2 عقود المُحقِّق على L1 للتحقق من إثباتات ZK قبل الإنهاء. تُصفى سلاسل L3 على ADI L2، مكونة سلسلة إثبات صحة ثلاثية الطبقات L3→L2→L1. يمكن للأصول التحرك بين L1 وL2 وL3 عبر الجسور، مع وراثة نموذج الأمان الاقتصادي لـEthereum في كل طبقة.

هل ADI Chain آمنة؟

تستخدم ADI Chain إثباتات صحة بمعرفة صفرية، لذا لا يمكن قبول حالة غير صالحة على L1؛ ويجب أن تمر دفعات L3 أيضًا بالتحقق على L2 قبل الإنهاء. يوفر المتسلسل تأكيدًا مبدئيًا في ثوانٍ؛ وتتطلب النهائية التشفيرية تحقق الإثباتات على L2 وL1. يجب على المستخدمين والمؤسسات الانتباه لمخاطر العقود الجسرية، وإدارة المفاتيح التشغيلية، وبنية GPU الذاتية التشغيل لـL3، والفترة بين التأكيد المبدئي ونهائية L1.

ما هي نماذج النشر المتاحة لسلاسل L3؟

تدعم ADI Chain L3 ثلاثة نماذج: مُدار من ADI (تشغل ADI المتسلسل والمثبت وعمليات العقود)، مشغل من العميل (تشغل المؤسسة العقد وبنية إثبات GPU وتمتلك المفاتيح)، وهجين (تظل الحوكمة لدى العميل بينما يمكن تعيين المتسلسل والمثبت بشكل مرن). يعتمد الاختيار على توازن المؤسسة بين عبء التشغيل وسيادة التحكم ومرونة الامتثال.

ما هو تدفق Commit-Prove-Execute لدفعات L3؟

يجمع متسلسل L3 المعاملات في دفعات؛ يلتزم المشغل بفروق الحالة إلى L2؛ يُولد المثبت إثبات صحة بمعرفة صفرية عبر نظام Airbender ويقدم معاملة إثبات؛ وبعد تحقق L2، ينفذ مشغل التنفيذ الدفعة، ويكتب جذر حالة L3 في عقد السلسلة وينهي الدفعة. تستهلك المراحل الثلاث تقريبًا 747,000 Gas إجمالاً، تُدفع بـ$ADI.

ما هي متطلبات العتاد لتشغيل مُثبِّت L3؟

تتطلب بيئات الإنتاج وحدات معالجة رسومية NVIDIA H100 أو H200 بذاكرة لا تقل عن 70 جيجابايت (140 جيجابايت موصى بها)، وذاكرة نظام 64 جيجابايت أو أكثر، وتخزين NVMe SSD لبيانات الشهود. يتضمن التكوين الموصى به 2 مُثبِّت FRI متوازي و1 مُثبِّت SNARK مخصص (~33 جيجابايت VRAM)، ويستهدف تقريبًا 15–20 معاملة في الثانية. يتطلب المتسلسل 8 أنوية CPU على الأقل و32 جيجابايت RAM ونقطة نهاية معاملات عامة.

المؤلف: Jayne
إخلاء المسؤولية
* لا يُقصد من المعلومات أن تكون أو أن تشكل نصيحة مالية أو أي توصية أخرى من أي نوع تقدمها منصة Gate أو تصادق عليها .
* لا يجوز إعادة إنتاج هذه المقالة أو نقلها أو نسخها دون الرجوع إلى منصة Gate. المخالفة هي انتهاك لقانون حقوق الطبع والنشر وقد تخضع لإجراءات قانونية.

المقالات ذات الصلة

ما هي العناصر الرئيسية لبروتوكول 0x؟ استعراض معماري Relayer وMesh وAPI
مبتدئ

ما هي العناصر الرئيسية لبروتوكول 0x؟ استعراض معماري Relayer وMesh وAPI

يؤسس بروتوكول 0x بنية تحتية متقدمة للتداول اللامركزي من خلال مكونات رئيسية تشمل Relayer، وMesh Network، و0x API، وExchange Proxy. يتولى Relayer إدارة بث الأوامر خارج السلسلة، وتتيح Mesh Network مشاركة الأوامر، بينما يوفر 0x API واجهة موحدة لعروض السيولة، ويتولى Exchange Proxy تنفيذ التداولات على السلسلة وتوجيه السيولة بكفاءة. تُمكّن هذه المكونات مجتمعةً من بناء هيكل يجمع بين نشر الأوامر خارج السلسلة وتسوية التداولات على السلسلة، ما يمنح المحافظ، وDEXs، وتطبيقات التمويل اللامركزي (DeFi) إمكانية الوصول إلى سيولة متعددة المصادر عبر واجهة موحدة واحدة.
2026-04-29 03:06:50
كيف تتيح Pharos تحويل الأصول الحقيقية (RWA) إلى على السلسلة؟ استعراض معمّق للمنهجية التي تستند إليها بنية RealFi التحتية لديها
متوسط

كيف تتيح Pharos تحويل الأصول الحقيقية (RWA) إلى على السلسلة؟ استعراض معمّق للمنهجية التي تستند إليها بنية RealFi التحتية لديها

تتيح Pharos (PROS) دمج الأصول الواقعية (RWA) على السلسلة عبر بنية طبقة أولى عالية الأداء وبنية تحتية محسّنة للسيناريوهات المالية. من خلال التنفيذ المتوازي، والتصميم المعياري، والوحدات المالية القابلة للتوسع، تلبي Pharos متطلبات إصدار الأصول، وتسوية التداولات، وتدفق رأس المال المؤسسي، مما يسهل ربط الأصول الحقيقية بالنظام المالي على السلسلة. في جوهرها، تبني Pharos بنية تحتية RealFi تربط الأصول التقليدية بالسيولة على السلسلة، لتوفر شبكة أساسية مستقرة وفعالة لسوق RWA.
2026-04-29 08:04:57
كاردانو مقابل إيثيريوم: التعرف على الاختلافات الأساسية بين اثنتين من أبرز منصات العقود الذكية
مبتدئ

كاردانو مقابل إيثيريوم: التعرف على الاختلافات الأساسية بين اثنتين من أبرز منصات العقود الذكية

يكمن الفرق الجوهري بين Cardano وEthereum في نماذج السجلات وفلسفات التطوير لكل منهما. تعتمد Cardano على نموذج Extended UTXO (EUTXO) المستمد من Bitcoin، وتولي أهمية كبيرة للتحقق الرسمي والانضباط الأكاديمي. في المقابل، تستخدم Ethereum نموذجًا معتمدًا على الحسابات، وبصفتها رائدة في مجال العقود الذكية، تركز على سرعة تطور النظام البيئي والتوافق الشامل.
2026-03-24 22:08:15
بروتوكول 0x مقابل Uniswap: ما الفرق بين بروتوكولات دفتر الطلبات ونموذج AMM؟
متوسط

بروتوكول 0x مقابل Uniswap: ما الفرق بين بروتوكولات دفتر الطلبات ونموذج AMM؟

تم تصميم كل من 0x Protocol وUniswap لتداول الأصول بشكل لامركزي، لكن كلاهما يعتمد آليات تداول مميزة. يستند 0x Protocol إلى بنية دفتر الطلبات خارج السلسلة مع تسوية على السلسلة، حيث يقوم بتجميع السيولة من مصادر متعددة لتوفير بنية تحتية للتداول للمحافظ ومنصات DEX. في المقابل، يتبنى Uniswap نموذج صانع السوق الآلي (AMM)، ما يتيح مبادلات الأصول على السلسلة من خلال مجمعات السيولة. يكمن الفرق الأساسي بينهما في تنظيم السيولة؛ إذ يركز 0x Protocol على تجميع الطلبات وتوجيه التداول بكفاءة، ما يجعله مثاليًا لدعم السيولة الأساسية للتطبيقات. بينما يستخدم Uniswap مجمعات السيولة لتقديم خدمات المبادلة المباشرة للمستخدمين، ليبرز كمنصة قوية لتنفيذ التداولات على السلسلة.
2026-04-29 03:48:20
دور Render في AI: كيف يعزز معدل التجزئة اللامركزي الابتكار في الذكاء الاصطناعي
مبتدئ

دور Render في AI: كيف يعزز معدل التجزئة اللامركزي الابتكار في الذكاء الاصطناعي

على عكس المنصات التي تركز فقط على قوة التجزئة في مجال الـ AI، تبرز Render بفضل شبكتها المعتمدة على GPU وآلية التحقق من المهام ونموذج الحوافز القائم على رمز RENDER. يمنح هذا التكامل Render توافقًا ومرونة طبيعية في حالات استخدام AI المختارة، ولا سيما تلك المرتبطة بالحوسبة الرسومية.
2026-03-27 13:12:58
Render و io.net و Akash: مقارنة الفروقات الأساسية بين شبكات معدل التجزئة DePIN
مبتدئ

Render و io.net و Akash: مقارنة الفروقات الأساسية بين شبكات معدل التجزئة DePIN

تُعد Render وio.net وAkash أكثر من مجرد منافسين يقدمون حلولًا متشابهة؛ فهي تمثل ثلاثة مشاريع رائدة في قطاع قوة التجزئة DePIN، حيث يسلك كل مشروع منها مسارًا تقنيًا خاصًا: معالجة الرسومات باستخدام GPU، وتنظيم قوة التجزئة للذكاء الاصطناعي، والحوسبة السحابية اللامركزية. تركز Render على تنفيذ مهام معالجة الرسومات عالية الجودة عبر GPU، مع إعطاء أولوية للتحقق من النتائج وبناء منظومة قوية للمنشئين. أما io.net فتركز على تدريب نماذج الذكاء الاصطناعي وعمليات الاستدلال، وتكمن ميزتها الأساسية في تنظيم GPU على نطاق واسع وكفاءة التكلفة. بينما طورت Akash متجر سحابة لامركزي للأغراض العامة يوفّر موارد حوسبة منخفضة التكلفة عبر عملية تقديم عروض تنافسية.
2026-03-27 13:18:02