سيرافيس وجامتيس في Monero: شرح القفزة البروتوكولية المقبلة لعام 2026

عندما دمج مختبر أبحاث Monero بهدوء أول فرع مدقَّق من مكتبة Seraphis في فرع الاختبار في أواخر عام 2025، كان ذلك تأكيدًا لما يتتبعه مراقبو البروتوكول منذ ما يقارب أربع سنوات: Monero يستعد لأعمق إعادة كتابة لطبقة المعاملات منذ إطلاق RingCT في عام 2017. Seraphis ليس مجرد تحسين لميزة قائمة، بل هو استبدال كامل لبروتوكول المعاملات، وللإثباتات التشفيرية التي تحمي إخفاء هوية المُرسِل، ولنظام العنونة الذي يراه المستخدمون على مستوى المحفظة. أما Jamtis، طبقة العنونة المصممة للعمل فوق Seraphis، فإنها تُحيل صيغة العناوين الفرعية (subaddress) — التي رست عليها كل محافظ Monero لنصف عقد — إلى التقاعد.

يفكك هذا الدليل البروتوكولَين معًا: ما هما، ولماذا قضى الباحثون الرئيسيون (koe وjberman وUkoeHB) آلاف الساعات في بنائهما، وما الذي سيتغير للمستخدم العادي، وكيف ستتعامل خدمة بلا KYC مثل MoneroSwapper مع هذه الهجرة دون إجبار العملاء على إعادة تعلّم الإنفاق الخاص من الصفر. إذا سبق لك أن أرسلت أو استلمت XMR، فإن العنوان الذي استخدمته سيُلغى تدريجيًا. فهم الترقية الآن أرخص بكثير من التخبط في يوم التفعيل.

لماذا احتاج Monero إلى Seraphis أصلًا؟

بروتوكول المعاملات الحالي في Monero هو ترقيع متعدد الطبقات. الإثبات الأساسي، CLSAG، حلّ محل MLSAG في التشعّب الصلب في أكتوبر 2020 وقلّص حجم توقيع الحلقة بنحو 25%، لكنه لا يزال يعمل على حلقة ثابتة من ستة عشر مَخدَعًا (decoy) تُؤخذ من المخرجات الحديثة. ستة عشر من بين كثيرين يبدو رقمًا قويًا ظاهريًا، لكن الإحصاءات الاستدلالية، وتحليل التوقيت، وما يُعرف بهجمة "EAE" (eve-alice-eve) تنهش جميعها من إخفاء هوية المُرسِل في النماذج الخصمية. ونشر باحثون منذ عام 2019 عدة أوراق محكَّمة تُبيّن كيف يستطيع محلل ذو تمويل جيد ورؤية واسعة على mempool أن يكشف هوية جزء غير تافه من المخرجات بطريقة احتمالية.

حجة قابلية الاستبدال (fungibility) تُفاقم المشكلة. كل حلقة CLSAG تتضمن إنفاقًا حقيقيًا واحدًا وخمسة عشر مَخدَعًا، لكن هذه المخادع نفسها هي مخرجات من معاملات سابقة. إذا أشارت معاملتان إلى بعضهما البعض كمخادع، واستطاع تحليل السلسلة استبعاد أحد الاحتمالات، فإن ذلك يُحدّد الاحتمال الآخر بدقة أعلى. النظام قوي إجمالًا لكنه يُسرّب من الهوامش. Seraphis يُغلق هذا التسريب عبر توسيع مجموعة عدم التمييز توسيعًا كبيرًا، مع إعادة هيكلة الإثبات بحيث تنفصل العضوية عن الملكية.

• مجموعة عدم تمييز أكبر: صُمِّم Seraphis ليدعم إثباتات العضوية فوق 128 أو 256 مَخرَجًا (أو أكثر، حسب المنحنى ونظام الإثبات المختار وقت التفعيل)، بدلًا من 16. والرياضيات لوغاريتمية في حجم الإثبات، أي أن 128-من-كُثُر تكلّف عددًا هامشيًا فقط من البايتات الإضافية مقارنة بـ 16-من-كُثُر تحت CLSAG.
• فصل أنظف للمسؤوليات: اليوم، إثبات CLSAG الواحد يدمج "أنا أملك أحد هذه المخرجات" مع "لم أُنفقه من قبل". Seraphis يفصل هذين الادعاءين إلى إثبات عضوية (membership proof) وإثبات تركيب (composition proof). كل واحد منهما يمكن تحسينه وتدقيقه وترقيته بشكل مستقل.
• جراحة على مفتاح العرض: مفتاح العرض الحالي يكشف كل مخرج وارد لمن يحوزه. المدققون، والمنصات، والمحاسبون الضريبيون كلهم يحصلون على الخرطوم نفسه. Seraphis يُقدّم مفاتيح عرض مُتدرّجة، بحيث يستطيع المستخدم منح وصول للقراءة فقط على الإيصالات دون كشف مخرجات الفكة (change) أو الإنفاق الذاتي.
• إثباتات قابلة للتبديل: معمارية Seraphis تتعامل مع إثباتات العضوية على أنها قابلة للاستبدال. الهدف الحالي هو FCMP++ (Full-Chain Membership Proofs Plus Plus)، الذي سيسمح لأي مخرج على السلسلة بأن يخدم كمَخدَع محتمل. هذه قفزة دالّيّة من رقم ستة عشر.

لا يعني أيٌّ من هذا أن CLSAG معطوب اليوم. بل يعني أن فضاء التصميم تقدّم، وأن التشفير الأكاديمي نضج، وأن ثقافة البحث في Monero ترفض القبول بـ"جيد بما يكفي" حين يتوفر "أفضل بإثبات رياضي". الكلفة هي التعقيد الهندسي وانتقال يمتد لسنوات؛ والمكسب هو وضع خصوصية يصمد أمام عقد كامل قادم من أدوات التحليل.

كيف يُعيد Seraphis تشكيل المعاملات

Seraphis بروتوكول معاملات، لا بدائيّة (primitive) واحدة. لفهم ما يتغير، يفيد أن نمشي خطوة بخطوة عبر ما يحدث حين ترسل XMR اليوم، ونقابله بمعادله في Seraphis. الفروق دقيقة في تجربة المستخدم، لكنها عميقة تحت الغطاء.

من CLSAG إلى إثباتات التركيب والعضوية

تحت CLSAG، تختار محفظتك خمسة عشر مَخدَعًا من السلسلة، وتبني حلقة من ستة عشر، وتوقّع إثباتًا يؤكد أن أحد هؤلاء الستة عشر يخصك وأنك لم تُنفقه مزدوجًا. تحت Seraphis، تبني محفظتك إثباتين متمايزين. إثبات التركيب يقول: "أنا أملك مخرجًا محددًا في هذه المجموعة بشكل مشروع، وهنا صورة المفتاح (key image) المطابقة لإثبات أنني لم أُنفقه من قبل." وإثبات العضوية يقول: "المخرج الذي أشير إليه موجود فعلًا داخل هذه المجموعة الأكبر لعدم التمييز على السلسلة." الإثباتان مرتبطان تشفيريًا لكن يُولَّدان بشكل مستقل، وهذا ما يجعل مجموعة عدم التمييز قابلة للتوسعة لاحقًا دون إعادة تصميم الصيغة الكاملة للمعاملة.

صور المفاتيح نفسها تخضع لإعادة تصميم. صورة المفتاح اليوم مُشتقّة بشكل حتمي من مفتاح المخرج لمرة واحدة ومفتاح الإنفاق — تركيب ذكي، لكنه ظل محورًا لأبحاث الحالات الحدية لسنوات. Seraphis يُقدّم صيغة جديدة لصورة المفتاح متوافقة قُدُمًا مع FCMP++، نظام إثبات العضوية الذي يأمل باحثو Monero أن يسمح في النهاية بأن تمتد مجموعة عدم التمييز لتشمل مجموعة UTXO الكاملة للسلسلة.

Carrot: طبقة ترميز المخرجات

Carrot هو مخطط ترميز المخرجات المصمَّم جنبًا إلى جنب مع Seraphis. حيث تستخدم مخرجات اليوم عنوانًا خفيًا (stealth address) مُشتقًّا من مفتاح العرض العام للمستلم وسرّ مشترك خاص بالمعاملة، تُضيف مخرجات Carrot حقولًا جديدة لأشياء مثل مفاتيح عرض-الرصيد، وعلامات داخلي-مقابل-خارجي، وتلميحات السرية الأمامية (forward secrecy). النتيجة العملية هي أن مسح المحفظة يصبح أسرع (لأن المخرجات الداخلية — الفكة التي ترسلها لنفسك — يمكن التعرف عليها دون فك تشفير كامل)، وتدقيق مفتاح العرض يصبح أكثر أمانًا (لأن المدقق يرى فقط ما يأذن به المستخدم).

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

حجم المعاملة والرسوم

يسأل المنتقدون كثيرًا: هل يعني Seraphis معاملات أكبر ورسومًا أعلى؟ الجواب الصادق: على الأرجح نعم، باعتدال، على المدى القصير — وعلى الأرجح لا، في النهاية. إثباتات Seraphis الأولية أكبر من CLSAG، ربما بمعامل 1.5 إلى 2 بحسب التهيئة المختارة عند التفعيل. لكن حجم الكتلة الديناميكي في Monero يجعل الرسوم تتوسع مع الازدحام لا مع عدد البايتات الخام، وقد قلّصت Bulletproofs+ بالفعل إثباتات النطاق (range proofs) بشكل عدواني في عام 2022. وبمجرد هبوط FCMP++ واتساع مجموعة عدم التمييز إلى مستوى السلسلة بأكملها، تنخفض كلفة البايت لكل وحدة من الخصوصية انخفاضًا جذريًا مقارنة باليوم.

Jamtis: طبقة العنونة التي ستراها فعلًا

Seraphis هو المحرك. Jamtis هو لوحة القيادة. معظم المستخدمين لن يقرأوا إثبات تركيب أبدًا، لكن كل مستخدم سينسخ ويُلصق عنوان Monero. Jamtis يُعيد تصميم ذلك العنوان — والمفاتيح خلفه — بحيث تنعكس مكاسب الخصوصية التي يقدمها Seraphis في كيفية تفاعل المحافظ والمنصات والتجار مع الشبكة.

عناوين Monero الحالية هي 95 حرفًا بترميز base58، تبدأ بـ"4" لعناوين الشبكة الرئيسية الأساسية أو بـ"8" للعناوين الفرعية. وهي تُرمّز مفتاح إنفاق عام ومفتاح عرض عام، وهذا في الجوهر كل شيء. عناوين Jamtis أقصر قليلًا أو مماثلة في الطول (الصيغة النهائية لا تزال قيد الإقرار على مستوى البروتوكول)، لكنها تُرمّز بنية أغنى بكثير: مؤشر عنوان، علم لنوع العنوان (رئيسي، منصة، مدمج، أو "ثانوي")، ووسوم مصادقة (authentication tags) تمنع أصنافًا معينة من هجمات التصيّد والاستبدال.

تدرّج مفاتيح العرض يستحق اهتمامًا خاصًا لأنه يحل ألمًا حقيقيًا في الواقع. اليوم، إذا أعطيت مفتاح العرض الخاص بك لمحاسبك، فسيرى كل مخرج تلقّيته في حياتك — بما في ذلك الفكة من إنفاقك الخاص، والمدفوعات بين عناوينك الفرعية، وأي دخل ثانوي. Jamtis يسمح لك بمنح الطبقة المحددة فقط التي يحتاجها المدقق. مفتاح "إيجاد-المستلم" يكشف المدفوعات الواردة دون مبالغ. مفتاح "عرض-الوارد" يكشف المدفوعات الواردة مع المبالغ ولكن دون الفكة. مفتاح "عرض-الرصيد" يكشف الرصيد القابل للإنفاق لأغراض الإفصاح التنظيمي دون كشف المعاملات الفردية. فقط مفتاح "عرض-الكل"، الذي يحتفظ به المستخدم خاصًّا، يرى كل شيء.

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

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

مسار الهجرة: كيف تُحضِّر محفظتك

التشعّب الصلب لـ Seraphis لم يُجدوَل بعد وقت كتابة هذا الدليل؛ ومختبر أبحاث Monero والفريق الأساسي محافظون عمدًا بشأن تواريخ التفعيل، ويفضّلون "جاهز حين يكون جاهزًا" على المواعيد التقويمية. منحت تشعّبات Monero السابقة المستخدمين ما بين شهرين وستة أشهر من الإشعار، وSeraphis سيقع شبه مؤكد في الطرف الأطول من ذلك المدى بالنظر إلى التعقيد. هنا قائمة تحضير عملية تصمد بصرف النظر عن أسبوع التفعيل الدقيق.

1. دقّق صيغة بذرتك. إذا كانت محفظتك لا تزال تستخدم بذرة الـ 25 كلمة القديمة، فكّر في الهجرة إلى محفظة مدعومة بـ Polyseed من 16 كلمة قبل الترقية. Polyseed متوافق قُدُمًا مع مسارات اشتقاق Jamtis؛ أما البذرة القديمة فستتطلب خطوة تحويل من جانب المحفظة وقت التشعّب.
2. حدّث برمجية محفظتك مرتين على الأقل قبل التشعّب. فِرَق Monero GUI وCLI وFeather Wallet وCake Wallet تُطلق عادةً عدة إصدارات قبل-التشعّب. تابع ملاحظات إصدار Monero الرسمية وسجل تغييرات محفظتك من الشهر السابق للتفعيل — ولا تعتمد على التحديثات التلقائية وحدها، فبعض المحافظ تبوّب الترقيات الكبرى خلف تأكيد يدوي.
3. تدرّب على استعادة كاملة من البذرة على جهاز احتياطي. قبل أي ترقية بروتوكول كبرى، أعلى ضوابط المخاطر قيمةً على الإطلاق هو التحقق من أن بذرتك المكتوبة تستعيد أموالك فعلًا. شغّل Monero CLI نظيفًا أو Feather Wallet على جهاز منفصل، استعد من البذرة، وأكّد أن الرصيد يطابق. افعل ذلك مرتين. افعل ذلك كل ستة أشهر حتى خارج أوقات الترقيات.
4. حدّد وقلّل من تشعُّب عناوينك الفرعية. المستخدمون الذين استخدموا عشرات العناوين الفرعية لأغراض تنظيمية (واحد لكل طرف مقابل، واحد لكل تاجر، إلخ) ستكون هجرتهم أعقد قليلًا. توحيد الأموال في مجموعة أصغر من العناوين الفرعية قبل التشعّب — مع تسمية كل واحد منها بوضوح في محفظتك — يجعل النموذج الذهني بعد التشعّب أبسط بكثير.
5. وثّق علاقات مشاركة مفتاح العرض لديك. إذا شاركت مفتاح العرض الخاص بك مع محاسب أو منصة أو أداة تدقيق، اكتب من يملكه ولماذا. بعد تفعيل Jamtis، ستحتاج على الأرجح إلى تدوير تلك العلاقات لاستخدام المفاتيح المتدرجة الجديدة بدلًا من مفتاح العرض الكامل القديم.
6. راقب توجيهات "الكنس بعد التشعّب". تطلّبت ترقيات Monero الماضية أحيانًا من المستخدمين "كنس" المخرجات من الصيغة القديمة إلى الصيغة الجديدة قبل أن تصبح قابلة للإنفاق. سينشر الفريق الأساسي لـ Monero تعليمات صريحة إذا كان ذلك مطلوبًا لـ Seraphis؛ لا تتصرف بناءً على إشاعات من المنتديات أو وسائل التواصل الاجتماعي.

بالنسبة لمستخدمي خدمات التبادل بلا KYC، يكون التأثير التشغيلي ضئيلًا عادةً. خدمة مصمَّمة جيدًا تُجرّد انتقال البروتوكول: أنت تعطيها العنوان، وهي تعطيك XMR، وتتولى صيغ المخرجات قبل-Seraphis ومع-Seraphis في الخلفية. MoneroSwapper مثلًا تتعامل مع نسخة بروتوكول عنوان الوجهة كقرار توجيه (routing) لا كتعقيد يواجه العميل. يستطيع العملاء الاستمرار في استخدام سير العمل نفسه الذي اعتادوا عليه دائمًا.

مثال عملي: استقبال مبادلة في ظل النموذج الجديد

تخيّل سيناريو نموذجيًا من منتصف عام 2026، بافتراض أن Seraphis قد جرى تفعيله بحلول ذلك الوقت. مستخدم في الإمارات أو السعودية يريد مبادلة Bitcoin بـ Monero دون KYC. يذهب إلى خدمة تبادل مثل MoneroSwapper، يُلصق عنوان استقبال Jamtis الخاص به (مولَّدًا بواسطة محفظة محدّثة كـ Feather أو Monero GUI الرسمي)، ويُرسل Bitcoin إلى عنوان الإيداع المقدَّم.

خلف الكواليس، توجّه خدمة التبادل الـ Bitcoin عبر مجمّع السيولة لديها، تحصل على Monero، وتبني معاملة Seraphis ترسل المبلغ المتفَق عليه إلى عنوان Jamtis الخاص بالمستخدم. تتضمن المعاملة إثبات تركيب، وإثبات عضوية يستند إلى مجموعة عدم تمييز من 128 مخرجًا (أو أكبر)، ومخرجًا مُرمَّزًا بـ Carrot تستطيع محفظة المستخدم تحديده في مسح واحد. يرى المستخدم الأموال في محفظته خلال نافذة التأكيد المعتادة من 10 إلى 20 دقيقة.

ماذا تغيّر من منظور المستخدم؟ لا شيء مرئي. وماذا تغيّر تحت الغطاء؟ نمت مجموعة عدم التمييز بمقدار رتبة عشرية كاملة، وبات ترميز المخرج يقاوم هجمات Janus على مستوى البروتوكول، ولم تتلقَ خدمة التبادل أبدًا مفتاحًا يسمح لها بتعلّم أي شيء عن نشاط Monero الأوسع للمستخدم. أنجز النظام مزيدًا من عمل الخصوصية، بشكل شفاف. هذا هو هدف ترقية بروتوكول مُحكمة التنفيذ: غير مرئية للمستخدم، أقوى بشكل قابل للإثبات لدى المدقق.

أما المستخدمون القادمون من خارج منظومة Monero — بِتكوينيُّون فضوليون بشأن الخصوصية، أو متبنّون جدد لعملات الخصوصية — فعلى الأرجح ستكون حقبة Seraphis هي أول تعرّض لهم. لن يعرفوا أبدًا كيف كانت الحياة مع تواقيع حلقية بستة عشر-من-كُثُر، تمامًا كما أن مستخدمي اليوم نادرًا ما يتذكرون أيام ما قبل RingCT حين كانت مبالغ المعاملات علنية على السلسلة. هكذا ينبغي أن تشعر بترقيات البروتوكول: تحسين هادئ يصبح المعيار الجديد.

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

متى سيُفعَّل Seraphis وJamtis على الشبكة الرئيسية لـ Monero؟

لم يُعلن عن تاريخ ثابت. مختبر أبحاث Monero والفريق الأساسي صرّحا مرارًا بأن التفعيل يعتمد على اكتمال التدقيقات التشفيرية، وتقوية المكتبات، وتكامل المحافظ عبر التطبيقات الرئيسية، ودورة testnet كاملة واحدة على الأقل. تقديرات علنية من المساهمين في أواخر 2025 تراوحت بين أواخر 2026 ومنتصف 2027، لكن ثقافة المشروع ترفض صراحةً الإطلاق المدفوع بالتقويم لترقيات حرجة أمنيًا. تابع ملاحظات إصدار Monero الرسمية وسجلات اجتماعات مختبر أبحاث Monero للحصول على التوقيت الموثوق.

هل سيظل عنوان Monero الحالي الخاص بي يعمل بعد الترقية؟

نعم، لفترة انتقالية. تشعّبات Monero الصلبة تضمنت تاريخيًا معالجة عناوين متوافقة مع الإصدارات السابقة، بحيث تصل الأموال المرسَلة إلى العناوين القديمة. على المدى الأطول، ستشجع برمجية المحافظ المستخدمين على الهجرة إلى عناوين Jamtis، وفي النهاية قد تتوقف المحافظ الجديدة عن توليد العناوين القديمة كليًا. لا يوجد خطر "موعد نهائي" مباشر للأموال المحتفظ بها في العناوين الحالية، لكنك ستحتاج إلى تحديث برمجية محفظتك حول وقت التشعّب.

هل يُغيّر Seraphis الانبعاث الذيلي (tail emission) لـ Monero أو جدول الإمداد؟

لا. Seraphis هو ترقية بروتوكول على طبقة المعاملات. لا يمس السياسة النقدية. الانبعاث الذيلي البالغ 0.6 XMR لكل كتلة يستمر دون تغيير. منحنى الانبعاث الإجمالي، وديناميكيات مكافأة الكتلة، وخوارزمية إثبات العمل RandomX، كلها منفصلة عن Seraphis وغير متأثرة بالترقية.

هل سيكسر Seraphis التوافق مع محافظ الأجهزة مثل Trezor وLedger؟

سيحتاج بائعو محافظ الأجهزة إلى تحديث الـ firmware لديهم لدعم صيغ الإثبات الجديدة ومسارات اشتقاق المفاتيح. تاريخيًا، أصدر كل من Trezor وLedger تحديثات firmware لـ Monero متماشية مع جداول التشعّب الصلب، وإن كان أحيانًا بتأخير من أسابيع أو شهور. المستخدمون الذين يعتمدون على محافظ الأجهزة لا يجب أن يُحدِّثوا firmware جهازهم بشكل أعمى وقت التشعّب — بل ينتظرون تأكيدًا صريحًا من البائع بأن الـ firmware الجديد يدعم نسخة بروتوكول Monero النشطة، ويحتفظون بقدرة محفظة برمجية احتياطية لفترة الانتقال.

كيف يقارن Seraphis بمقاربات مشاريع الخصوصية الأخرى؟

Zcash يستخدم zk-SNARKs للمعاملات المحجوبة بالكامل، التي تُقدّم خصوصية نظرية أقوى لكنها تطلّبت تاريخيًا حفل إعداد موثوقًا (trusted setup) ولها تبنّي أدنى بكثير (معظم حجم Zcash شفاف). سلاسل Mimblewimble مثل Grin تستخدم نموذجًا مختلفًا جوهريًا قائمًا على تجميع المخرجات، الذي يضحّي ببعض قابلية التدقيق مقابل الإحكام. Seraphis يبقى داخل نموذج Monero القائم — التواقيع الحلقية والعناوين الخفية — لكنه يدفع التصميم إلى أقصاه عمليًا. المفاضلة هي تعقيد هندسي مقابل عدم وجود إعداد موثوق وتجربة مستخدم سلسة متواصلة مع Monero اليوم.

هل يمكنني التبادل إلى عناوين Jamtis على MoneroSwapper قبل تفعيل التشعّب؟

لا، لأن عناوين Jamtis ليست قابلة للتوليد حتى الآن بواسطة المحافظ الإنتاجية الحالية. بمجرد تفعيل البروتوكول وطرح المحافظ الكبرى مثل Monero GUI وFeather وCake Wallet دعمَ Jamtis، ستقبل خدمات التبادل صيغة العنوان الجديدة جنبًا إلى جنب مع العناوين القديمة خلال نافذة الانتقال. حتى ذلك الحين، يستمر عنوان Monero الحالي الخاص بك في العمل بشكل طبيعي لجميع نشاط التبادل.

خلاصة

Seraphis وJamtis يُمثّلان التزام Monero بأن يبقى متقدّمًا على منحنى التحليل بدلًا من ردّ الفعل عليه. الترقية ليست استعراضية، ولن تُنتج سرديةً تدفع السعر، ولن تُغيّر بشكل جذري ما يفعله المستخدمون يومًا بيوم. ما ستفعله هو رفع أرضية الخصوصية في الشبكة بشكل ملحوظ، ومنح المستخدمين تحكمًا أدق بما يكشفونه ولمن، ووضع الأساس التشفيري لعقد كامل قادم من تطوير Monero. إذا كنت تحتفظ بـ XMR أو تستخدمها لمدفوعات يومية تحافظ على الخصوصية، خصّص الستة إلى الاثني عشر شهرًا القادمة لتحديث صيغة بذرتك، وتجديد عادات برمجية محفظتك، والتحقق من عملية الاستعادة. حين يهبط التشعّب، تريده أن يكون لا-حدثًا. لبدء استخدام Monero اليوم عبر خدمة تبادل بلا KYC وبلا حساب ستتولى انتقال Seraphis بشفافية، توجّه إلى MoneroSwapper وبادل عملاتك المشفرة الحالية بـ XMR في دقائق.